Lecture 14 – Security Engineering

Part 1

Lecture 14 Security Engineering 1

Topics covered

 Security engineering and security management

 Security engineering concerned with applications; security
management with infrastructure.
 Security risk assessment
 Designing a system based on the assessment of security risks.
 Design for security
 How system architectures have to be designed for security.

Lecture 14 Security Engineering 2

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.
 Assumes background knowledge of dependability and
security concepts (Lecture 10) and security requirements
specification (Lecture 12)

Lecture 14 Security Engineering 3

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 Lecture is application security.

Lecture 14 Security Engineering 4

System layers where security may be
compromised

Lecture 14 Security Engineering 5

System security management

 User and permission management

 Adding and removing users from the system and setting up
appropriate permissions for users
 Software deployment and maintenance
 Installing application software and middleware and configuring
these systems so that vulnerabilities are avoided.
 Attack monitoring, detection and recovery
 Monitoring the system for unauthorized access, design
strategies for resisting attacks and develop backup and recovery
strategies.

Lecture 14 Security Engineering 6

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
 Operational risk assessment

Lecture 14 Security Engineering 7

Preliminary risk assessment

Lecture 14 Security Engineering 8

Misuse cases

 Misuse cases are instances of threats to a system

 Interception threats
 Attacker gains access to an asset
 Interruption threats
 Attacker makes part of a system unavailable
 Modification threats
 A system asset if tampered with
 Fabrication threats
 False information is added to a system

Lecture 14 Security Engineering 9

 Asset analysis

Asset Value Exposure

The High. Required to support all High. Financial loss as clinics may have
information clinical consultations. Potentially to be canceled. Costs of restoring system.
system safety-critical. Possible patient harm if treatment cannot
be prescribed.

The patient High. Required to support all High. Financial loss as clinics may have
database clinical consultations. Potentially to be cancelled. Costs of restoring system.
safety-critical. Possible patient harm if treatment cannot
be prescribed.

An individual Normally low although may be Low direct losses but possible loss of
patient record high for specific high-profile reputation.
patients.

Lecture 14 Security Engineering 10

 Threat and control analysis
Threat Probability Control Feasibility

Unauthorized user Low Only allow system Low cost of implementation but
gains access as system management from care must be taken with key
manager and makes specific locations distribution and to ensure that
system unavailable that are physically keys are available in the event of
secure. an emergency.

Unauthorized user High Require all users to Technically feasible but high-cost
gains access as system authenticate solution. Possible user resistance.
user and accesses themselves using a
Simple and transparent to
confidential biometric
implement and also supports
information mechanism.
recovery.
Log all changes to
patient information
to track system
usage.
Lecture 14 Security Engineering 11
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.

Lecture 14 Security Engineering 12

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.

Lecture 14 Security Engineering 13

Life-cycle risk analysis

Lecture 14 Security Engineering 14

Design decisions from use of COTS

 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.

Lecture 14 Security Engineering 15

Vulnerabilities associated with technology
choices

Lecture 14 Security Engineering 16

Security requirements

 A password checker shall be made available and shall

be run daily. Weak passwords shall be reported to
system administrators.
 Access to the system shall only be allowed by approved
client computers.
 All client computers shall have a single, approved web
browser installed by system administrators.

Lecture 14 Security Engineering 17

Operational risk assessment

 Continuation of life cycle risk assessment but with

additional information about the environment where the
system is used.
 Environment characteristics can lead to new system
risks
 Risk of interruption means that logged in computers are left
unattended.

Lecture 14 Security Engineering 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?

Lecture 14 Security Engineering 19

Architectural design

 Two fundamental issues have to be considered when

designing an architecture for security.
 Protection
• How should the system be organised so that critical assets can be
protected against external attack?
 Distribution
• How should system assets be distributed so that the effects of a
successful attack are minimized?
 These are potentially conflicting
 If assets are distributed, then they are more expensive to protect.
If assets are protected, then usability and performance
requirements may be compromised.

Lecture 14 Security Engineering 20

Protection

 Platform-level protection
 Top-level controls on the platform on which a system runs.
 Application-level protection
 Specific protection mechanisms built into the application itself
e.g. additional password protection.
 Record-level protection
 Protection that is invoked when access to specific information is
requested
 These lead to a layered protection architecture

Lecture 14 Security Engineering 21

A layered protection architecture

Lecture 14 Security Engineering 22

Distribution

 Distributing assets means that attacks on one system do

not necessarily lead to complete loss of system service
 Each platform has separate protection features and may
be different from other platforms so that they do not
share a common vulnerability
 Distribution is particularly important if the risk of denial of
service attacks is high

Lecture 14 Security Engineering 23

Distributed assets in an equity trading system

Lecture 14 Security Engineering 24

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

Lecture 14 Security Engineering 25

Lecture 14 – Security Engineering

Part 2

Lecture 14 Security Engineering 26

Topics covered

 Design guidelines for security

 Guidelines that help you design a secure system
 Design for deployment
 Design so that deployment problems that may introduce
vulnerabilities are minimized
 System survivability
 Allow the system to deliver essential services when under attack

Lecture 14 Security Engineering 27

Design guidelines for security engineering

 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. Security is considered when design decisions
are made.
 They can be used as the basis of a review checklist that is
applied during the system validation process.
 Design guidelines here are applicable during software
specification and design

Lecture 14 Security Engineering 28

Design guidelines for secure systems
engineering

Security guidelines
Base security decisions on an explicit security policy

Avoid a single point of failure

Fail securely

Balance security and usability

Log user actions

Use redundancy and diversity to reduce risk

Validate all inputs

Compartmentalize your assets

Design for deployment

Lecture 14 Security Engineering 29
Design for recoverability
Design guidelines 1-3

 Base decisions on an explicit security policy

 Define a security policy for the organization that sets out the
fundamental security requirements that should apply to all
organizational systems.
 Avoid a single point of failure
 Ensure that a security failure can only result when there is more
than one failure in security procedures. For example, have
password and question-based authentication.
 Fail securely
 When systems fail, for whatever reason, ensure that sensitive
information cannot be accessed by unauthorized users even
although normal security procedures are unavailable.

Lecture 14 Security Engineering 30

Design guidelines 4-6

 Balance security and usability

 Try to avoid security procedures that make the system difficult to
use. Sometimes you have to accept weaker security to make the
system more usable.
 Log user actions
 Maintain a log of user actions that can be analyzed to discover
who did what. If users know about such a log, they are less likely
to behave in an irresponsible way.
 Use redundancy and diversity to reduce risk
 Keep multiple copies of data and use diverse infrastructure so
that an infrastructure vulnerability cannot be the single point of
failure.

Lecture 14 Security Engineering 31

Design guidelines 7-10

 Validate all inputs

 Check that all inputs are within range so that unexpected inputs
cannot cause problems.
 Compartmentalize your assets
 Organize the system so that assets are in separate areas and
users only have access to the information that they need rather
than all system information.
 Design for deployment
 Design the system to avoid deployment problems
 Design for recoverability
 Design the system to simplify recoverability after a successful
attack.
Lecture 14 Security Engineering 32
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.

Lecture 14 Security Engineering 33

Software deployment

Lecture 14 Security Engineering 34

Configuration vulnerabilities

 Vulnerable default settings

 Attackers can find out the default settings for software. If these
are weak (often to increase usability) then they can be exploited
by users when attacking a system.
 Development rather than deployment
 Some configuration settings in systems are designed to support
development and debugging. If these are not turned off, they can
be a vulnerability that can be exploited by attackers.

Lecture 14 Security Engineering 35

Deployment support 1

 Include support for viewing and analyzing configurations

 Make sure that the system administrator responsible for
deployment can easily view the entire configuration. This makes
it easier to spot omissions and errors that have been made.
 Minimize default privileges and thus limit the damage
that might be caused
 Design the system so that the default privileges for an
administrator are minimized. This means that if someone gains
admin access, they do not have immediate access to the
features of the system.

Lecture 14 Security Engineering 36

Deployment support 2

 Localize configuration settings

 When setting up a system, all information that is relevant to the
same part or component of a system should be localized so that
it is all set up at once. Otherwise, it is easy to forget to set up
related security features.
 Provide easy ways to fix security vulnerabilities
 When problems are detected, provide easy ways, such as auto-
updating, to repair security vulnerabilities in the deployed
systems.

Lecture 14 Security Engineering 37

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

Lecture 14 Security Engineering 38

Importance of survivability

 Our economic and social lives are dependent on

computer systems
 Critical infrastructure – electricity, gas, telecommunications,
transport
 Healthcare
 Government
 Loss of business systems for even a short time can have
very severe economic effects
 Airline reservation systems
 E-commerce systems
 Payment systems

Lecture 14 Security Engineering 39

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?

Lecture 14 Security Engineering 40

Survivability strategies

 Resistance
 Avoiding problems by building capabilities into the system to
resist attacks
 Recognition
 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

Lecture 14 Security Engineering 41

Stages in survivability analysis

Lecture 14 Security Engineering 42

Key activities

 System understanding
 Review golas, requirements and architecture
 Critical service identification
 Identify services that must be maintained
 Attack simulation
 Devise attack scenarios and identify components affected
 Survivability analysis
 Identify survivability strategies to be applied

Lecture 14 Security Engineering 43

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

Lecture 14 Security Engineering 44

Survivable ordering service

 The critical service that must survive is the ability for

authorized users to place orders for stock
 This requires 3 components of the system to be
available and operating reliability:
 User authentication, allowing authorized users to log on to the
system
 Price quotation, allowing buying and selling prices to be quoted
 Order placement, allowing buy and sell orders to be made

Lecture 14 Security Engineering 45

Possible attacks

 Malicious user masquerades as a legitimate user and

places malicious orders for stock, with the aim of causing
problems for the legitimate user
 An unauthorized user corrupts the database of
transactions thus making reconciliation of sales and
purchases impossible

Lecture 14 Security Engineering 46

 Survivability analysis in an equity trading
system
Attack Resistance Recognition Recovery
Unauthorized Require a dealing Send copy of order by e-mail to Provide mechanism to
user places password that is authorized user with contact phone automatically ‘undo’
malicious different from the number (so that they can detect trades and restore user
orders login password to malicious orders). accounts.
place orders. Maintain user’s order history and Refund users for
check for unusual trading patterns. losses that are due to
malicious trading.
Insure against
consequential losses.
Corruption of Require privileged Maintain read-only copies of Recover database from
transactions users to be transactions for an office on an backup copies.
database authorized using a international server. Periodically Provide a mechanism
stronger compare transactions to check for to replay trades from a
authentication corruption. specified time to re-
mechanism, such Maintain cryptographic checksum create the transactions
as digital with all transaction records to database. 47
certificates. detect corruption.
Key points

 General security guidelines sensitize designers to

security issues and serve as review checklists
 Configuration visualization, setting localization, and
minimization 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.

Lecture 14 Security Engineering 48