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

Component-Based Software Engineering

and Software Assurance

SSW-540, Unit 12

The final exam

• Will occur next week, on December 9th

• 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 Topics 2


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

Component-Based Software Engineering

Main issues:• assemble systems out of (reusable) components• compatibility of components


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.www.wileyeurope.com/college/van 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.www.wileyeurope.com/college/van 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.www.wileyeurope.com/college/van vliet SSW-540 Special Topics 8


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.www.wileyeurope.com/college/van vliet


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



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



Managing quality in CBSE

• Who manages the quality: the component, or the execution platform

• Scope of management: per-collaboration, or system-wide



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


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



Development process in CBSE

• Two separate development processes:– Development of components– Development of systems out of components

• Separate process to assess components



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


Component assessment

• Find components

• Verify components

• Store components in repository



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.

www.wileyeurope.com/college/van vliet


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



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


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


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


Stages of risk-based analysis


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


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


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


The risk triangle

Unacceptable regionRisk cannot be tolerated

Risk tolerated only ifrisk reduction is impracticalor excessively expensive

Acceptableregion

ALARPregion

$


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


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


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


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


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


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


Threat and control analysis in a preliminary risk assessment report

Threat Probability

Control Feasibility

Unauthorized user gains access as system manager and makes system unavailable

Low Only 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

High Require 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.


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


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


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


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

The final exam is next week

• Thursday, December 9th

• 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


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!

Documents

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