Security Engineering
1
Topics covered
• Secure systems design
• Security testing and assurance
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.
3
Security
• The security of a system is a system property that
reflects the system’s ability to protect itself from
accidental or deliberate external attack.
• Security is essential as most systems are networked
so that external access to the system through the
Internet is possible.
• Security is an essential prerequisite for availability,
reliability and safety.
4
Security dimensions
• Confidentiality
– Information in a system may be disclosed or made accessible to
people or programs that are not authorized to have access to
that information.
• Integrity
– Information in a system may be damaged or corrupted making it
unusual or unreliable.
• Availability
– Access to a system or its data that is normally available may not
be possible. 5
Security levels
• Infrastructure security, which is concerned with maintaining
the security of all systems and networks that provide an
infrastructure and a set of shared services to the
organization.
• Application security, which is concerned with the security of
individual application systems or related groups of systems.
• Operational security, which is concerned with the secure
operation and use of the organization’s systems.
6
Secure systems design
7
Secure systems design
• Security should be designed into a system – it is
very difficult to make an insecure system secure
after it has been designed or implemented
• Architectural design
– how do architectural design decisions affect the security
of a system?
• Good practice
– what is accepted good practice when designing secure
systems?
8
Design compromises
• Adding security features to a system to enhance its
security affects other attributes of the system
• Performance
– Additional security checks slow down a system so its response
time or throughput may be affected
• Usability
– Security measures may require users to remember information
or require additional interactions to complete a transaction. This
makes the system less usable and can frustrate system users.
9
Protection requirements
• Protection requirements may be generated when
knowledge of information representation and system
distribution
• Separating patient and treatment information limits the
amount of information (personal patient data) that needs
to be protected
• Maintaining copies of records on a local client protects
against denial of service attacks on the server
– But these may need to be encrypted
10
Vulnerabilities associated with technology
choices
11
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.
12
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.
13
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
14
A layered protection architecture
15
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
16
Distributed
assets in an
equity
trading
system
17
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
Specify the format of all system inputs
Compartmentalize your assets
Design for deployment
Design for recoverability 18
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.
19
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.
20
Design guidelines 7-10
• Specify the format of all system inputs
– If input formats are known then you can check that all inputs are within range so
that unexpected inputs don’t 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.
21
Dependable programming guidelines
Dependable programming guidelines
1. Limit the visibility of information in a program
2. Check all inputs for validity
3. Provide a handler for all exceptions
4. Minimize the use of error-prone constructs
5. Provide restart capabilities
6. Check array bounds
7. Include timeouts when calling external components
8. Name all constants that represent real-world values
22
Aspects of secure systems programming
• Vulnerabilities are often language-specific.
– Array bound checking is automatic in languages like Java so this is
not a vulnerability that can be exploited in Java programs.
– However, millions of programs are written in C and C++ as these
allow for the development of more efficient software so simply
avoiding the use of these languages is not a realistic option.
• Security vulnerabilities are closely related to program
reliability.
– Programs without array bound checking can crash so actions taken
to improve program reliability can also improve system security.
23
Security testing and assurance
24
Security testing
• Testing the extent to which the system can protect itself from
external attacks.
• Problems with security testing
– Security requirements are ‘shall not’ requirements i.e. they
specify what should not happen. It is not usually possible to
define security requirements as simple constraints that can
be checked by the system.
– The people attacking a system are intelligent and look for
vulnerabilities. They can experiment to discover
weaknesses and loopholes in the system.
25
Security validation
• Experience-based testing
– The system is reviewed and analysed against the types of attack that are known to the
validation team.
• Penetration testing
– A team is established whose goal is to breach the security of the system by simulating
attacks on the system.
• Tool-based analysis
– Various security tools such as password checkers are used to analyse the system in
operation.
• Formal verification
– The system is verified against a formal security specification.
26