©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering 2.

Slides:



Advertisements
Similar presentations
TWO STEP EQUATIONS 1. SOLVE FOR X 2. DO THE ADDITION STEP FIRST
Advertisements

Requirements Engineering Process
Chapter 27 Software Change.
Chapter 26 Legacy Systems.
Critical Systems Specification
Distributed Systems Architectures
Chapter 10 Architectural Design.
Software Re-engineering
Chapter 26 Legacy Systems.
Chapter 7 System Models.
Requirements Engineering Process
Chapter 24 Quality Management.
Software Re-engineering
Chapter 8 Software Prototyping.
Chapter 27 Software Change.
Chapter 24 Quality Management.
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
ASYCUDA Overview … a summary of the objectives of ASYCUDA implementation projects and features of the software for the Customs computer system.
1 Introduction to Safety Management April Objective The objective of this presentation is to highlight some of the basic elements of Safety Management.
Objectives To introduce software project management and to describe its distinctive characteristics To discuss project planning and the planning process.
0 - 0.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
MULTIPLYING MONOMIALS TIMES POLYNOMIALS (DISTRIBUTIVE PROPERTY)
Addition Facts
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design 1.
Configuration management
Software change management
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Software testing.
Defect testing Objectives
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering.
Legacy Systems Older software systems that remain vital to an organisation.
Software Requirements
Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Chapter 10 Software Testing
Addition 1’s to 20.
25 seconds left…...
Week 1.
12 Financial Management 12-1 Financial Planning
Database Administration
1 Unit 1 Kinematics Chapter 1 Day
1 PART 1 ILLUSTRATION OF DOCUMENTS  Brief introduction to the documents contained in the envelope  Detailed clarification of the documents content.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering 1.
Chapter 14 – Security Engineering
Internal Analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 5 Slide 1 Project management.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
©Ian Sommerville 2006Critical Systems Slide 1 Critical Systems Engineering l Processes and techniques for developing critical systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
CS 220 – Software Engineering© Binayak Bhattacharyya CS Software Engineering Instructor: Binayak Bhattacharyya
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering 1.
Figures – Chapter 14. Figure 14.1 System layers where security may be compromised.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 5 Slide 1 Risk management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 3 Slide 1 Critical Systems 1.
 Chapter 14 – Security Engineering 1 Chapter 12 Dependability and Security Specification 1.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
©Ian Sommerville 2000Dependability Slide 1 Chapter 16 Dependability.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
Design for Security Pepper.
Software Qualities II.
Chapter 13 – Security Engineering
Security Engineering.
Software Qualities.
Presentation transcript:

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering 2

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 2 Design for security l Architectural design - how do architectural design decisions affect the security of a system? l Good practice - what is accepted good practice when designing secure systems? l 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 2006Software Engineering, 8th edition. Chapter 30 Slide 3 Architectural design l Protection How should the system be organised so that critical assets can be protected against external attack? l Distribution How should system assets be distributed so that the effects of a successful attack are minimised? l Potentially conflicting If assets are distributed, then they are more expensive to protect.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 4 Protection l Platform-level protection l Application-level protection l Record-level protection

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 5 Layered protection

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 6 A distributed equity system

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 7 Design guidelines l Design guidelines encapsulate good practice in secure systems design l 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 2006Software Engineering, 8th edition. Chapter 30 Slide 8 Design guidelines 1 l Base security decisions on an explicit security policy l Avoid a single point of failure l Fail securely l Balance security and usability l Be aware of the possibilities of social engineering

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 9 Design guidelines 2 l Use redundancy and diversity to reduce risk l Validate all inputs l Compartmentalise your assets l Design for deployment l Design for recoverability

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 10 Design for deployment l Deployment involves configuring software to operate in its working environment, installing the system and configuring it for the operational platform. l Vulnerabilities may be introduced at this stage as a result of configuration mistakes. l Designing deployment support into the system can reduce the probability that vulnerabilities will be introduced.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 11 System deployment

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 12 Deployment support l Include support for viewing and analysing configurations l Minimise default privileges and thus limit the damage that might be caused l Localise configuration settings l Provide easy ways to fix security vulnerabilities

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 13 System survivability l 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 l Survivability analysis and design should be part of the security engineering process

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 14 Service availability l Which system services are the most critical for a business? l How might these services be compromised? l What is the minimal quality of service that must be maintained? l How can these services be protected? l If a service becomes unavailable, how quickly can it be recovered?

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 15 Survivability strategies l Resistance Avoiding problems by building capabilities into the system to resist attacks l Recognition Detecting problems by building capabilities into the system to detect attacks and failures and assess the resultant damage l Recovery Tolerating problems by building capabilities into the system to deliver services whilst under attack

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 16 System survivability method

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 17 Key activities l System understanding Review golas, requirements and architecture l Critical service identification Identify services that must be maintained l Attack simulation Devise attack scenarios and identify components affected l Survivability analysis Identify survivability strategies to be applied

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 18 Equity trading system

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 19 Trading system survivability l User accounts and equity prices replicated across servers so some provision for survivability made l Key capability to be maintained is the ability to place orders for stock l Orders must be accurate and reflect the actual sales/purchases made by a trader

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 20 Survivability analysis

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 21 Key points l Design for security involves architectural design, following good design practice and minimising the introduction of system vulnerabilities l Key issues when designing a secure architecture include organising the structure to protect assets and distributing assets to minimise losses l General security guidelines sensitise designers to security issues and serve as review checklists l System survivability reflects the ability of a system to deliver services whilst under attack or after part of the system has been damaged.