Security Engineering
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 1
Objectives




To introduce issues that must be considered in
the specification and design of secure software
To discuss security risk management and the
derivation of security requirements from a risk
analysis
To describe good design practice for secure
systems development.
To explain the notion of system survivability and
to introduce a method of survivability analysis.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 2
Topics covered




Security concepts
Security risk management
Design for security
System survivability
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 3
Security engineering


Tools, techniques and methods to support the
development and maintenance of systems that
can resist malicious attacks that are intended to
damage a computer-based system or its data.
A sub-field of the broader field of computer
security.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 4
System layers
Application
Reus able components and libraries
Middlew are
Databas e management
Generic, shared applic ations (Brow sers, e--mail, etc )
Operating Sys tem
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 5
Application/infrastructure security



Application security is a software engineering
problem where the system is designed to resist
attacks.
Infrastructure security is a systems management
problem where the infrastructure is configured to
resist attacks.
The focus of this chapter is application security.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 6
Security concepts
Term
Asset
Exposure
Vulnerability
Att ack
Threats
Control
©Ian Sommerville 2006
Definition
A system resource that has a value and has to be protected.
The possible loss or harm that could result from a successful
attack. This can be loss or damage to data or can be a loss
of time and effort if recovery is n ecessary after a se curity
breach.
A weakness in a computer-based system that may be
exploited to cause loss or harm.
An exploitation of a s ystemÕ
s vulnerability. Generally, this is
from outside the system and is a deliberate attempt to cause
some damage.
Circumstances that have potential to cause loss or harm. You
can think of these as a system v ulnerability that is subjected
to an attack.
A protective measure that reduces a s ystemÕ
s vulnerability.
Encryption would be an example of a control that reduced a
vulnerability of a weak access control system.
Software Engineering, 8th edition. Chapter 30
Slide 7
Examples of security concepts
Term
Asset
Exposure
Vulnerability
Att ack
Threat
Control
©Ian Sommerville 2006
Definition
The records of each patient that is receiving or has received
treatment.
Potential financial loss from future patients who do not seek
treatment because they do not trust the clinic to maintain
their data. Financial loss from legal action by the sports star.
Loss of reputation.
A weak password system which makes it easy for u sers to
set guessable passwords. User ids that are the same as
names.
An impersonation of an authorised user.
An unauthorised user will gain access to th e system by
guessin g the credentials (login name and password) of a n
authorised user.
A password checking system that disallo ws passwords that
are set by users which are proper names or words that are
normally included in a dictionary.
Software Engineering, 8th edition. Chapter 30
Slide 8
Security threats



Threats to the confidentiality of a system or its
data
Threats to the integrity of a system or its data
Threats to the availability of a system or its data
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 9
Security controls



Controls that are intended to ensure that attacks
are unsuccessful. This is analagous to fault
avoidance.
Controls that are intended to detect and repel
attacks. This is analagous to fault detection and
tolerance.
Controls that are intended to support recovery
from problems. This is analagous to fault
recovery.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 10
Security risk management



Risk management is concerned with assessing the
possible losses that might ensue from attacks on the
system and balancing these losses against the costs of
security procedures that may reduce these losses.
Risk management should be driven by an organisational
security policy.
Risk management involves
•
•
Preliminary risk assessment
Life cycle risk assessment
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 11
Preliminary risk assessment
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 12
Asset analysis
Asset
Value
Exposure
The information
system
High. Required to support all
clinical consultations.
Potentially safety critical.
High. Financial loss as c linics may have to be
cancelled. Costs of r estoring system. Possible
patient harm if treatment cannot be prescribed.
The patient
database
High. Required to support all
clinical consultations.
Potentially safety critical.
High. Financial loss as c linics may have to be
cancelled. Costs of r estoring system. Possible
patient harm if treatment cannot be prescribed.
An individual
patient record
Normally low although may
be high for specific highprofile patients
Low direct
reputation.
©Ian Sommerville 2006
losses but possible
Software Engineering, 8th edition. Chapter 30
Slide 13
loss
of
Threat and control analysis
Threat
Unauthorised user
gains access as
system manager and
makes system
unavailable
Unauthorised user
gains access as
system user and
accesses confidential
information
Probability
Low
Control
Only allow system
management from
specific locations which
are physically secure.
High
Require all users to
authenticate
themselves using
biometric mechanism.
Log all changes to
patient information to
track system usage.
©Ian Sommerville 2006
Feasibil ity
Low cost of i mplementation
but care must be taken with
key distribution and to e nsure
that keys are available in the
event of an emergency.
Technically feasible but high
cost solution. Possible user
resistance.
Simple and transparent to
implement and also supports
recovery.
Software Engineering, 8th edition. Chapter 30
Slide 14
Security requirements



Patient information must be downloaded at the
start of a clinic session to a secure area on the
system client that is used by clinical staff.
Patient information must not be maintained on
system clients after a clinic session has finished.
A log on a separate computer from the database
server must be maintained of all changes made
to the system database.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 15
Life cycle risk assessment



Risk assessment while the system is being
developed and after it has been deployed
More information is available - system platform,
middleware and the system architecture and
data organisation.
Vulnerabilities that arise from design choices
may therefore be identified.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 16
Examples of design decisions



System users authenticated using a
name/password combination.
The system architecture is client-server with
clients accessing the system through a standard
web browser.
Information is presented as an editable web
form.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 17
Technology vulnerabilities
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 18
Design for security



Architectural design - how do architectural
design decisions affect the security of a system?
Good practice - what is accepted good practice
when designing secure systems?
Design for deployment - what support should be
designed into a system to avoid the introduction
of vulnerabilities when a system is deployed for
use?
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 19
Architectural design

Protection
•

Distribution
•

How should the system be organised so that critical
assets can be protected against external attack?
How should system assets be distributed so that the
effects of a successful attack are minimised?
Potentially conflicting
•
If assets are distributed, then they are more
expensive to protect.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 20
Protection



Platform-level protection
Application-level protection
Record-level protection
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 21
Layered protection
Platfor m leve l pr ote ctio n
Sys tem
authentication
Sys tem
authorisation
File integrity
management
Applicationlevel protection
Databas e
login
Databas e
authorisation
Transaction
management
Databas e
rec ov ery
Recor d leve l pr ote ctio n
Record access
authorisation
Record
encry ption
Record integrity
management
Patient rec ords
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 22
A distributed equity system
Authentic ation and authorisation
New York trading sy stem
US us er acc ounts
US trading
his tory
International
equity pric es
International
user ac counts
US equity data
US funds data
Authentic ation and authorisation
Frankfurt trading sy stem
European us er
acc ounts
Euro. trading
his tory
International
equity pric es
©Ian Sommerville 2006
International
user ac counts
Euro. equity data
Euro. funds data
Authentic ation and authorisation
London trading s ys tem
UK us er acc ounts
UK trading
his tory
International
equity pric es
International
user ac counts
UK equity data
UK funds data
Authentic ation and authorisation
Hong Kong trading sy stem
HK us er acc ounts
International
user ac counts
HK trading
his tory
As ian equity data
International
equity pric es
As ian funds data
Software Engineering, 8th edition. Chapter 30
Slide 23
Design guidelines


Design guidelines encapsulate good practice in
secure systems design
Design guidelines serve two purposes:
•
•
They raise awareness of security issues in a
software engineering team.
They can be used as the basis of a review checklist
that is applied during the system validation process.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 24
Design guidelines 1





Base security decisions on an explicit security
policy
Avoid a single point of failure
Fail securely
Balance security and usability
Be aware of the possibilities of social
engineering
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 25
Design guidelines 2





Use redundancy and diversity to reduce risk
Validate all inputs
Compartmentalise your assets
Design for deployment
Design for recoverability
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 26
Design for deployment



Deployment involves configuring software to
operate in its working environment, installing the
system and configuring it for the operational
platform.
Vulnerabilities may be introduced at this stage as
a result of configuration mistakes.
Designing deployment support into the system
can reduce the probability that vulnerabilities will
be introduced.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 27
System deployment
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 28
Deployment support




Include support for viewing and analysing
configurations
Minimise default privileges and thus limit the
damage that might be caused
Localise configuration settings
Provide easy ways to fix security vulnerabilities
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 29
System survivability


Survivability is an emergent system property that
reflects the systems ability to deliver essential
services whilst it is under attack or after part of
the system has been damaged
Survivability analysis and design should be part
of the security engineering process
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 30
Service availability





Which system services are the most critical for a
business?
How might these services be compromised?
What is the minimal quality of service that must
be maintained?
How can these services be protected?
If a service becomes unavailable, how quickly
can it be recovered?
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 31
Survivability strategies

Resistance
•

Recognition
•

Avoiding problems by building capabilities into the
system to resist attacks
Detecting problems by building capabilities into the
system to detect attacks and failures and assess the
resultant damage
Recovery
•
Tolerating problems by building capabilities into the
system to deliver services whilst under attack
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 32
System survivability method
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 33
Key activities

System understanding
•

Critical service identification
•

Identify services that must be maintained
Attack simulation
•

Review golas, requirements and architecture
Devise attack scenarios and identify components
affected
Survivability analysis
•
Identify survivability strategies to be applied
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 34
Trading system survivability



User accounts and equity prices replicated
across servers so some provision for survivability
made
Key capability to be maintained is the ability to
place orders for stock
Orders must be accurate and reflect the actual
sales/purchases made by a trader
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 35
Survivability analysis
Attack
Unauthorised user
places malicious
orders
Resistance
Require dealing
password to place
orders that is
different from
login password.
Recognition
Send copy of order by
email to authorised user
with contact phone
number (so that they can
detect malicious orders)
Maintain userÕ
s order
history and check for
unusual trading patterns.
Corruption of
transactions
database
Require privi leged
users to be
authorised using a
stronger
authentication
mechanism, such
as digital
certificates.
Maintain read-only
copies of transactions for
an office on an
international server.
Periodically compare
transactions to check for
corruption.
Maintain cryptographic
checksum with all
transaction records to
detect corruption.
©Ian Sommerville 2006
Recovery
Provide mechanism to
automatically ŌundoÕ
trades and restore user
accounts.
Refund users for losses
that are due to malicious
trading.
Insure against
consequential losses.
Recover database from
backup copies.
Provide a mechanism to
replay trades from a
specified time to recreate
transactions database.
Software Engineering, 8th edition. Chapter 30
Slide 36
Key points




Security engineering is concerned with how to develop
systems that can resist malicious attacks
Security threats can be threats to confidentiality, integrity
or availability of a system or its data
Security risk management is concerned with assessing
possible losses from attacks and deriving security
requirements to minimise losses
Design for security involves architectural design,
following good design practice and minimising the
introduction of system vulnerabilities
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 37
Key points




Key issues when designing a secure architecture include
organising the structure to protect assets and distributing
assets to minimise losses
General security guidelines sensitise designers to
security issues and serve as review checklists
Configuration visualisation, setting localisation, and
minimisation of default privileges help reduce deployment
errors
System survivability reflects the ability of a system to
deliver services whilst under attack or after part of the
system has been damaged.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 30
Slide 38