Component-Based Software Engineering and Software Assurance SSW-540, Unit 12.

Slides:



Advertisements
Similar presentations
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
Advertisements

Chapter 4 Quality Assurance in Context
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 24 Slide 1 Critical Systems Validation 2.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Figures – Chapter 12.
Critical Systems Specification
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Security Engineering II. Problem Sources 1.Requirements definitions, omissions, and mistakes 2.System design flaws 3.Hardware implementation flaws, such.
SWE Introduction to Software Engineering
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 9 Slide 1 Critical Systems Specification.
Stephen S. Yau CSE , Fall Security Strategies.
©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.
CIS 376 Bruce R. Maxim UM-Dearborn
Verification and Validation
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 1.
Introduction to Network Defense
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
SEC835 Database and Web application security Information Security Architecture.
S/W Project Management
CSCE 548 Secure Software Development Risk-Based Security Testing.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
Chapter 2 The process Process, Methods, and Tools
CLEANROOM SOFTWARE ENGINEERING.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Management & Development of Complex Projects Course Code - 706
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1 Component-based development l Building software from reusable components l Objectives.
Chapter 12 – Dependability and Security Specification
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 3 Slide 1 Critical Systems 1.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
ISO 9001:2008 to ISO 9001:2015 Summary of Changes
CSCE 522 Secure Software Development Best Practices.
Main Requirements on Different Stages of the Licensing Process for New Nuclear Facilities Module 4.5/1 Design Geoff Vaughan University of Central Lancashire,
Safety-Critical Systems 7 Summary T V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 1.
CSCE 548 Secure Software Development Security Operations.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
CSCE 201 Secure Software Development Best Practices.
Smart Home Technologies
The common structure and ISO 9001:2015 additions
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 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Erman Taşkın. Information security aspects of business continuity management Objective: To counteract interruptions to business activities and to protect.
Chapter 4 – Requirements Engineering Lecture 1 The hardest part of the software task is arriving at a complete and consistent specification, and much of.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
©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.
Security Development Lifecycle (SDL) Overview
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
CSCE 548 Secure Software Development Risk-Based Security Testing
Design for Security Pepper.
Chapter 4 – Requirements Engineering
Critical Systems Specification
Software Qualities II.
Chapter 13 – Security Engineering
Security Engineering.
Component-Based Software Engineering
Critical Systems Specification
Chapter 17 - Component-based software engineering
Presentation transcript:

Component-Based Software Engineering and Software Assurance SSW-540, Unit 12

The final exam Will occur next week, on December 9 th Will cover entire course, with a bit more emphasis on the second half of the course Similar to mid-term in structure –Open-book, open-notes; do not consult one another! –Available on eLearn/WebCT –Extended hours of availability: noon until 10 p.m. –Two hour limit to answer all the questions –Blank “question” at end for your comments and explanations regarding any of the questions SSW-540 Special Topics2

Tonight’s topics Component-Based Software Engineering –Importance of reusable parts –Interchangeability of software components Software Assurance –Risk-driven specification –Safety specification –Security specification –Security testing SSW-540 Special Topics3

Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components

SSW-540 Special Topics 5 LEGO analogy Set of building blocks in different shapes and colors Can be combined in different ways Composition through small stubs in one and corresponding holes in another building block  LEGO blocks are generic and easily compose-able LEGO can be combined with LEGO, not with Meccano or Tinker Toys or Erector sets

6 Why CBSE? CBSE increases quality, especially evolve-ability and maintainability CBSE increases productivity CBSE shortens development time ©2008 John Wiley & Sons Ltd. vliet SSW-540 Special Topics

7 Component model Defines the types of building block, and the recipe for putting them together More precisely, a component model defines standards for: –Properties individual components must satisfy –Methods and mechanisms for composing components Consequently, a component has to conform to some component model ©2008 John Wiley & Sons Ltd. vliet SSW-540 Special Topics

A software component: Implements some functionality Has explicit dependencies through “provides” and “requires” interfaces Communicates through its interfaces only Has structure and behavior that conforms to a component model ©2008 John Wiley & Sons Ltd. vliet SSW-540 Special Topics8

9 A component technology Is the implementation of a component model, by means of: –Standards and guidelines for the implementation and execution of software components –Executable software that supports the implementation, assembly, deployment, execution of components Examples: EJB, COM+,.NET, CORBA ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics10 Component forms Component goes through different stages: development, packaging, distribution, deployment, execution Across these stages, components are represented in different forms: –During development: UML, e.g. –When packaging: in a.zip file, e.g. –In the execution stage: blocks of code and data ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics11 Component specification vs component interface Specification describes properties to be realized: realization contract Interface describes how components interact: usage contract Different in scope as well: specification is about the component as a whole, while an interface might be about part of a component only ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics12 Managing quality in CBSE Who manages the quality: the component, or the execution platform Scope of management: per-collaboration, or system-wide ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics13 Managing quality in CBSE Approach A left to the designers (e.g. when integrating COTS components) Approach B model provides standardized facilities for managing qualities Approach C component only addresses functionality; quality in surrounding container Approach D similar to C, but container interacts with platform on quality issues

SSW-540 Special Topics14 Common features of component models Infrastructure mechanisms, for binding, execution, etc Instantiation Binding (design time, compile time, …) Mechanisms for communication between components Discovery of components Announcement of component capabilities (interfaces) Development support Language independence Platform independence Analysis support Support for upgrading and extension Support for quality properties ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics15 Development process in CBSE Two separate development processes: –Development of components –Development of systems out of components Separate process to assess components ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics16 CBSE system development process Requirements: must also consider availability of components (like in COTS) Analysis and design: similar to what we normally do Implementation: less coding, focus on selection of components, provision of glue code Integration: largely automated Testing: verification of components is necessary Release: as in classical approaches Maintenance: replace components

SSW-540 Special Topics17 Component assessment Find components Verify components Store components in repository ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics18 Component maintenance Who is responsible: producer or consumer? Root cause analysis: relation between manifestation of a fault and its cause, e.g. –Component A requires more CPU time –As a consequence, B does not complete in time –As required by C, so –C issues a time-out error to its user –Analysis: goes from C to B to A to input of A –Who does the analysis, if producers of A,B,C are different? ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics19 Architecture and CBSE Architecture-driven: top-down: components are identified as part of an architectural design Product line: family of similar products, with one architecture COTS-based: bottom-up, architecture is secondary to components found ©2008 John Wiley & Sons Ltd. vliet

SSW-540 Special Topics20 CBSE Summary To enable composition, components must be compatible: achieved by component model Separation of development process for components from that of assembling systems out of components Architectural plan organizes how components fit together and meet quality requirements ©2008 John Wiley & Sons Ltd. vliet

Software Assurance Main points: Software must insure that critical systems are available, safe to use, dependable and secure Software in trustworthy critical systems doesn’t fail and doesn’t admit intrusions Software Assurance is what software engineers do to create truly trustworthy systems

Risk-driven specification Critical systems specifications should be risk- driven A widely used approach in safety and security- critical systems The aim of the specification process should be to understand the risks (safety, security, etc.) faced by the system and to define requirements that reduce these risks SSW-540 Special Topics22

Software Assurance requirements Functional requirements to define error checking and recovery facilities and protection against system failures Non-functional requirements defining the required reliability and availability of the system Excluding requirements that define states and conditions that must not arise SSW-540 Special Topics23

Stages of risk-based analysis SSW-540 Special Topics24

Phased risk analysis Preliminary risk analysis –Identifies risks from the systems environment. Aim is to develop an initial set of system security and dependability requirements Life cycle risk analysis –Identifies risks that emerge during design and development e.g. risks that are associated with the technologies used for system construction. Requirements are extended to protect against these risks Operational risk analysis –Risks associated with the system user interface and operator errors. Further protection requirements may be added to cope with these SSW-540 Special Topics25

Safety specification Goal is to identify protection requirements that ensure that system failures do not cause injury or death or environmental damage Risk identification = Hazard identification Risk analysis = Hazard assessment Risk decomposition = Hazard analysis Risk reduction = safety requirements specification SSW-540 Special Topics26

Hazard assessment The process is concerned with understanding the likelihood that a risk will arise and the potential consequences if an accident or incident should occur Risks may be categorized as: –Intolerable. Must never arise or result in an accident –As low as reasonably practical(ALARP). Must minimise the possibility of risk given cost and schedule constraints –Acceptable. The consequences of the risk are acceptable and no extra costs should be incurred to reduce hazard probability SSW-540 Special Topics27

The risk triangle SSW-540 Special Topics28 Unacceptable region Risk cannot be tolerated Risk tolerated only if risk reduction is impractical or excessively expensive Acceptable region ALARP region $

Social acceptability of risk The acceptability of a risk is determined by human, social and political considerations In most societies, the boundaries between the regions are pushed upwards with time i.e. society is less willing to accept risk –For example, the costs of cleaning up pollution may be less than the costs of preventing it but this may not be socially acceptable Risk assessment is subjective –Risks are identified as probable, unlikely, etc. This depends on who is making the assessment SSW-540 Special Topics29

Risk reduction The aim of this process is to identify dependability requirements that specify how the risks should be managed and ensure that accidents/incidents do not arise Risk reduction strategies –Risk avoidance –Risk detection and removal –Damage limitation SSW-540 Special Topics30

Key points Risk analysis is an important activity in the specification of security and dependability requirements. It involves identifying risks that can result in accidents or incidents A hazard-driven approach may be used to understand the safety requirements for a system. You identify potential hazards and decompose these to discover their root causes Safety requirements should be included to ensure that hazards and accidents do not arise or, if this is impossible, to limit the damage caused by system failure SSW-540 Special Topics31

Security specification Security specification has some commonality with safety requirements specification – in both cases, your concern is to avoid something bad happening Four major differences –Safety problems are accidental – the software is not operating in a hostile environment. In security, you must assume that attackers have knowledge of system weaknesses –When safety failures occur, you can look for the root cause or weakness that led to the failure. When failure results from a deliberate attack, the attacker may conceal the cause of the failure –Shutting down a system can avoid a safety-related failure. Causing a shut down may be the aim of an attack –Safety-related events are not generated from an intelligent adversary. An attacker can probe defenses over time to discover weaknesses SSW-540 Special Topics32

Types of security requirements Identification requirements Authentication requirements Authorization requirements Immunity requirements Integrity requirements Intrusion detection requirements Non-repudiation requirements Privacy requirements Security auditing requirements System maintenance security requirements SSW-540 Special Topics33

Security risk assessment Attack assessment –Decompose threats into possible attacks on the system and the ways that these may occur Control identification –Propose the controls that may be put in place to protect an asset Feasibility assessment –Assess the technical feasibility and cost of the controls Security requirements definition –Define system security requirements. These can be infrastructure or application system requirements SSW-540 Special Topics34

Threat and control analysis in a preliminary risk assessment report ThreatProbabilityControlFeasibility Unauthorized user gains access as system manager and makes system unavailable LowOnly allow system management from specific locations that are physically secure. Low cost of implementation but care must be taken with key distribution and to ensure that keys are available in the event of an emergency. Unauthorized user gains access as system user and accesses confidential information HighRequire all users to authenticate themselves using a biometric mechanism. Log all changes to patient information to track system usage. Technically feasible but high- cost solution. Possible user resistance. Simple and transparent to implement and also supports recovery. SSW-540 Special Topics35

Security policy An organizational security policy applies to all systems and sets out what should and should not be allowed E.g., a defense department policy might be: –Readers may only examine documents whose classification is the same as or below the readers vetting level A security policy sets out the conditions that must be maintained by a security system and so helps identify system security requirements SSW-540 Special Topics36

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. Usually, it is not 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 Static analysis may be used to guide the testing team to areas of the program that may include errors and vulnerabilities 37SSW-540 Special Topics

Security validation Security validation is difficult because security requirements often state what should not happen in a system, rather than what should. Furthermore, system attackers are intelligent and may have more time to probe for weaknesses than is available for security testing Security validation may be carried out using experience-based analysis, tool-based analysis or ‘tiger teams’ that simulate attacks on a system Bottom line: It is important to have a well-defined, certified process for safety-critical systems development. The process must include the identification and monitoring of potential hazards and the testing and validation of mitigation strategies 38SSW-540 Special Topics

In sum… Software Assurance of safety and dependability requires a complete understanding of the hazards and other risks arising –From the systems environment –From the technologies used for system construction –From the errors that can arise during operation Some risks are socially acceptable, others are not Risk exposure is the product of the cost of the damage and the probability of occurrence Security risks are hardest to analyze and security levels are hardest to test and validate 39SSW-540 Special Topics

The final exam is next week Thursday, December 9 th Comprehensively covers the course Open-book, open-notes On eLearn/WebCT from noon until 10 p.m. Two hours to complete the exam Don’t forget the “question” at end for your comments and explanations regarding any of the other questions SSW-540 Special Topics40

Now, you can do one more thing… Please fill out the course evaluation “assessment” on eLearn next week Your feedback will be heeded and appreciated! Help cultivate and nurture this course!