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!