Your SlideShare is downloading. ×
0
EngineeringSafety- and Security-RelatedRequirementsDonald FiresmithSoftware Engineering InstituteCarnegie Mellon Universit...
Tutorial GoalsTo familiarize safety, security, and requirements engineers with the:  • Common challenges they face  • Comm...
Intended AudiencesPrimary audience: • Safety engineers • Security engineers • Requirements engineersSecondary audience: • ...
HistoryWork began in 2002Presented as conference tutorials and in journal articles   (see http://donald.firesmith.net/home...
Where We AreRelated Disciplines ◄ChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and...
Safety Engineering – Traditional DefinitionSafety    freedom from accidental harm to people, property, and the environment...
Security Engineering – Traditional DefinitionsSecurity (of information and services) is often defined in terms of specific...
Defensibility Engineering – New DefinitionsSafety Engineering the systems engineering discipline concerned with lowering t...
Safety/Security Similarities and DifferencesSimilarities:  • Systems engineering rather than software engineering  • Lower...
Requirements EngineeringRequirements Engineering    the engineering discipline within systems/software engineering concern...
Where We AreRelated DisciplinesChallenges ◄Common ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and...
Challenges1Requirements engineering, safety engineering, and security engineeringhave different: • Communities • Disciplin...
Challenges2Safety and security engineering are:  • Typically treated as secondary specialty engineering disciplines  • Per...
Challenges3Separation of requirements engineering, safety engineering, and securityengineering causes: • Poor safety- and ...
Challenges4How much safety and security is enough? • Insufficient defensibility is dangerous. • Excessive defensibility wa...
Challenges5Many mandated security “requirements” are actually constraints such as: • Security subsystems • Industry “best ...
Challenges6Current separate methods for performing requirements, safety, andsecurity engineering are inefficient and ineff...
Challenges7Current state-of-the-practice cries out for improvement:  • Better consistency between safety and security engi...
Where We AreRelated DisciplinesChallengesCommon Example ◄Free, Open-Source ToolRequirements Engineering OverviewSafety and...
Common Example use throughout TutorialProblem: How to enable large numbers of zoo patrons to quickly andconveniently tour ...
Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source Tool ◄Requirements Engineering OverviewSafety and...
Free, Open-Source ToolFree and open-source toolDeveloped to:  • Support the collaborative defensibility engineering method...
Initial Screen                 Engineering Safety- & Security-Related                 Requirements                        ...
Prepare to Analyze Safety and Security Menu                                 Engineering Safety- & Security-Related        ...
Analyze Safety and Security Menu                                   Engineering Safety- & Security-Related                 ...
Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering Overview ◄Safety and...
Requirements Engineering TasksBusiness Analysis (i.e., Customer, Competitor, Market, Technology, and User Analysis aswell ...
Requirements Engineering Work ProductsBusiness analysesStakeholder profilesVision statement • Capabilities and GoalsConcep...
Difficulty of Requirements Engineering“The hardest single part of building a software system is deciding preciselywhat to ...
GoalsGoal an informally documented perceived need of a legitimate stakeholderGoals are: • Not requirements. • Drive the id...
Representative ZATS GoalsZATS will take passengers on leisurely tours that provide excellent viewingof the zoo habitats.ZA...
Use Case Models and Mission ThreadsUsage Scenario   a specific functionally cohesive sequence of interactions between user...
Use Case ModelsUse case paths: • Can be either:   —   Normal (Sunny Day or Happy Path)   —   Exceptional (Rainy Day) • Sho...
Characteristics of Good RequirementsAll Types of Requirements   Active VoiceCorrect                     Configuration Cont...
Poor Requirements Cause Accidents1“For the 34 (safety) incidents analyzed, 44% had inadequatespecification as their primar...
Poor Requirements Cause Accidents2“Erroneous specification is a major source of defects and subsequentfailure of safety-cr...
Poor Requirements Cause Accidents3“Software-related accidents are usually caused by flawed requirements.Incomplete or wron...
The Many Types of Requirements                                   Business       Industry     Laws and      Natural    Orga...
Product RequirementsA product requirement is a requirement for a product (e.g., system,subsystem, software application, or...
Quality Models               Architectural               Components                                       define the      ...
Quality Characteristics (Operational)                                                           Quality Characteristics   ...
Performance Attributes             Jitter                                                        Problem           Latency...
Defensibility Quality Attributes       Occurrence of Unauthorized Harm                                                    ...
Different Types of Defensibility Requirements                                                         Problem Type Quality...
Components of a Quality Requirement         state stakeholders’                                          Quality Goals    ...
Example Quality RequirementHazard prevention safety requirement:“Under normal operating conditions, ZATS shall not move wh...
Importance of Measurement ThresholdMeasurement threshold is:  •   Critical  •   Difficult (but not impossible) to determin...
Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and S...
Fundamental Safety and Security ConceptsSafety and security as quality characteristics with associated qualityattributesSt...
Safety as a Quality CharacteristicSafety is the subclass of defensibility capturing the degree to which:  • The following ...
Security as a Quality CharacteristicSecurity is the subclass of defensibility capturing the degree to which:  • The follow...
Where We AreThree DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Sec...
Types of Safety- and Security-Related RequirementsToo often only a single type of requirements is considered.Not just:  • ...
Types of Requirements                                   Business       Industry     Laws and      Natural    Organizationa...
Different Types of Defensibility Requirements                                                         Problem Type Quality...
Types of Defensibility-Related Requirements – 1                                                          Safety      Secur...
Types of Defensibility-Related Requirements – 2                               Safety/Security-            Safety/Security ...
Types of Defensibility-Related Requirements – 3      Safety/Security   Assurance Level (SAL)                              ...
1) Safety and Security RequirementsSafety and security requirements are quality requirements.Quality requirements are prod...
Safety and Security RequirementsQuality requirements should be:  • Scalar (how well or how much)  • Based on a quality mod...
Example Safety Requirement TemplatesWhen in mode V, the system shall limit the occurrence of accidental harmof type W to d...
Example Security Requirement TemplatesWhen in mode V, the system shall limit the occurrence of malicious harmof type W to ...
2) Defensibility-Significant Requirements – 1Defensibility-significant requirement    a requirement with significant safet...
Defensibility-Significant Requirements – 2                                             Safety/Security-Upper 3 circles    ...
Safety/Security Assurance Levels (SALs)      Safety/Security   Assurance Level (SAL)                                     D...
Example Safety-Significant RequirementsFiring missiles from military aircraft requirements:  • When to arm missiles  • Whe...
Example Security-Significant RequirementsAccess control requirements:  • Identification, authentication, and authorization...
3) Defensibility Function/Subsystem Rqmts – 1Defensibility function/subsystem requirements are requirements forfunctions o...
Defensibility Function/Subsystem Rqmts – 2                                             Safety/Security-Bottom circle      ...
Example Safety Functions/SubsystemsAutomobile functions or subsystems added strictly for safety: • Adaptive Cruise Control...
Example Security Functions/Subsystems – 1Automobile functions or subsystems added strictly for security: • Car Alarm Syste...
Example Security Functions/Subsystems – 2Functions or subsystems strictly added for security:  • Access control  • Antivir...
Example Safety Function/Subsystem RqmtsExcept when the weapons bay doors are open or have been open withinthe previous 90 ...
Example Security Function/Subsystem RqmtsAccess Control Function: • The Access Control Function shall require at least 99....
4) Defensibility Constraints – 1A constraint is any engineering decision that has been chosen to bemandated as a requireme...
Defensibility Constraints – 2                                                   Safety/Security-Right circle              ...
Example Safety ConstraintsThe system shall use hardware interlocks to prevent users from physicallycoming into contact wit...
Example Security ConstraintsThe system shall user use IDs and passwords for identification andauthentication.The system sh...
Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and S...
Desired Method PropertiesHelp meet challenges listed at start of tutorialPromote close collaboration among safety, securit...
Overall Defensibility Engineering Method                                 Defensibility                                    ...
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Engineering Safety and Security-Related Requirements
Upcoming SlideShare
Loading in...5
×

Engineering Safety and Security-Related Requirements

577

Published on

Half-day tutorial presented at the The 11th IASTED International Conference on Software Engineering (SE 2012) in Crete, Greece on 18 June 2012.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
577
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
30
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Engineering Safety and Security-Related Requirements"

  1. 1. EngineeringSafety- and Security-RelatedRequirementsDonald FiresmithSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 1521318 June 2012Half-Day Tutorial © 2012 Carnegie Mellon University
  2. 2. Tutorial GoalsTo familiarize safety, security, and requirements engineers with the: • Common challenges they face • Common foundational concepts underlying each other’s disciplines • Useful reusable techniques from each other’s disciplines • Different types of safety- and security-related requirementsTo provide safety, security, and requirements engineers with a commonconsistent method for engineering these requirements and thereby: • Improve collaboration • Engineer better safety- and security-related requirements • Decrease the incidence of accidents and successful attacks due to poor safety- and security-related requirements Engineering Safety- & Security-Related Requirements 2 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  3. 3. Intended AudiencesPrimary audience: • Safety engineers • Security engineers • Requirements engineersSecondary audience: • Project managers (acquisition, development, or sustainment) • Lead system engineers and system architects • System, software, and hardware engineers • Safety and security SMEs and consultants • Safety and security trainers and academic educators and researchers • Specialty engineers (e.g., human factors and reliability) • Any other stakeholders in safety and security Engineering Safety- & Security-Related Requirements 3 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  4. 4. HistoryWork began in 2002Presented as conference tutorials and in journal articles (see http://donald.firesmith.net/home/publications)Taught at 5 NASA Centers (2008) and US Army ASSIP ProgramPresented to nuclear engineers at:• System Engineering Challenges International Workshop in Russia (RuSEC 2010) in Moscow, Russia on 23 September 2010• Kärnteknik-2011 (Nuclear Technology 2011) Nordic Symposium in Stockholm Sweden on 8 December 2011Free Open Source Tool began Fall 2011http://donald.firesmith.net/home/safety-and-security-analysis-toolBook to be published Winter 2012 Engineering Safety- & Security-Related Requirements 4 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  5. 5. Where We AreRelated Disciplines ◄ChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 5 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  6. 6. Safety Engineering – Traditional DefinitionSafety freedom from accidental harm to people, property, and the environmentSafety Engineering the process of ensuring that a system is safe to operateMajor Limitations: • No nontrivial system is free from hazards that can cause accidental harm. • It is always a matter of degree and risk management. • Not just harm, but also accidents, vulnerabilities, and hazards • In spite of best efforts, accidents can (and sometimes do) happen. • It is important to address not just the prevention of accidental harm (and accidents, vulnerabilities, hazards, and risks), but also detecting their existence/occurrence, and reacting properly. Engineering Safety- & Security-Related Requirements 6 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  7. 7. Security Engineering – Traditional DefinitionsSecurity (of information and services) is often defined in terms of specificproperties, whereby a system is secure when it exhibits these properties inspite of attack: • Access Control (including identification, authentication, and authorization) • Availability • Confidentiality (including both privacy and anonymity) • Integrity (including data and software) • Non-repudiation (of transactions)Security Engineering the process of ensuring that a system is sufficiently secure to operateMajor limitations: • No nontrivial system is free from threats that can cause malicious harm. • It is always a matter of degree and risk management. • Not just harm, but also attacks, vulnerabilities, and threats • In spite of best efforts, attacks can (and typically will) happen. • It is important to address not just the prevention of malicious harm (and attacks, vulnerabilities, threats, and risks), but also detecting their existence/occurrence, and reacting properly. Engineering Safety- & Security-Related Requirements 7 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  8. 8. Defensibility Engineering – New DefinitionsSafety Engineering the systems engineering discipline concerned with lowering the risk of unintentional (i.e., accidental) unauthorized harm to defended assets to a level that is acceptable to the system’s stakeholders by preventing, detecting, and properly reacting to such harm, mishaps (i.e., accidents and safety incidents), system-internal vulnerabilities, system- external unintentional abusers, hazards, and safety risksSecurity Engineering the systems engineering discipline concerned with lowering the risk of intentional (i.e., malicious) unauthorized harm to defended assets to a level that is acceptable to the system’s stakeholders by preventing, detecting, and properly reacting to such harm, civilian misuses (i.e., attacks and security incidents), system-internal vulnerabilities, system-external intentional civilian abusers, threats, and security risksSurvivability Engineering the systems engineering discipline concerned with lowering the risk of intentional (i.e., malicious) unauthorized harm to defended assets to a level that is acceptable to the system’s stakeholders by preventing, detecting, and properly reacting to such harm, military misuses (i.e., attacks and survivability incidents), system-internal vulnerabilities, system-external intentional military abusers, threats, and survivability risks Engineering Safety- & Security-Related Requirements 8 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  9. 9. Safety/Security Similarities and DifferencesSimilarities: • Systems engineering rather than software engineering • Lower risks to acceptable levels: — Never zero – never perfectly safe, secure, or survivable • Prevention, detection, and reaction: — Unauthorized harm to defended assets (people, property, environment, services) — Abuses (safety mishaps and security misuses) — System-internal vulnerabilities — System-external abusers (exploit vulnerabilities to cause harm) — Dangers (safety hazards and security threats) — Risks (safety and security)Differences: • Unintentional (safety) vs. intentional (security and security) • Terminology Engineering Safety- & Security-Related Requirements 9 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  10. 10. Requirements EngineeringRequirements Engineering the engineering discipline within systems/software engineering concerned with identifying, analyzing, reusing, specifying, managing, verifying, and validating goals and requirements (including safety- and security-related requirements)Safety- and security-related requirements are primarily system-levelrequirements. Engineering Safety- & Security-Related Requirements 10 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  11. 11. Where We AreRelated DisciplinesChallenges ◄Common ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 11 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  12. 12. Challenges1Requirements engineering, safety engineering, and security engineeringhave different: • Communities • Disciplines with different training, books, journals, and conferences • Professions with different job titles • Foundational concepts and terminologies • Tasks, techniques, and work productsSome of these differences are unnecessary and represent detrimentalredundancies: • Underlying concepts and terminologies • Tasks and techniques • Work products (models and documents) Engineering Safety- & Security-Related Requirements 12 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  13. 13. Challenges2Safety and security engineering are: • Typically treated as secondary specialty engineering disciplines • Performed separately from, largely independently of, and lagging behind the primary engineering workflow: (requirements, architecture, design, implementation, integration, testing, deployment, sustainment)Safety and security are too often tested into existing systems (reactively)rather than adequately built into systems during development (proactively) Engineering Safety- & Security-Related Requirements 13 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  14. 14. Challenges3Separation of requirements engineering, safety engineering, and securityengineering causes: • Poor safety- and security-related requirements that are often: — Vague, unverifiable, and infeasible capabilities or goals rather than true requirements — Potentially inappropriate architectural and design constraints — Inadequate to drive architecture, design, and implementation — Specified and managed separately from all other requirements — Relegated to “second class” “supplementary” specifications — Often ignored by requirements engineers and architects — Produced too late to drive architecture and testing • Safety and security are too often iterated and tested into existing systems (reactively) – “find and fix” – rather than adequately built into systems during development (proactively). Engineering Safety- & Security-Related Requirements 14 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  15. 15. Challenges4How much safety and security is enough? • Insufficient defensibility is dangerous. • Excessive defensibility wastes scarce project resources. • Current requirements lack practical and precise thresholds. • Defenses (safeguards and countermeasures) should be commensurate with risk. — Goldilocks rule: not too little and not too big. • Without well-defined thresholds, how can: — Architects perform engineering trade-offs? — Testers set test completion criteria for the testing of safety- and security- related requirements? Engineering Safety- & Security-Related Requirements 15 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  16. 16. Challenges5Many mandated security “requirements” are actually constraints such as: • Security subsystems • Industry “best practices”What about safety and security requirements for preventing, detecting, andreacting to: • Harm to defended assets? • Abuses (safety mishaps and security misuses)? • Vulnerabilities? • Abusers (unintentional and intentional)? • Dangers (safety hazards and security threats)? • Risks (safety and security)? Engineering Safety- & Security-Related Requirements 16 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  17. 17. Challenges6Current separate methods for performing requirements, safety, andsecurity engineering are inefficient and ineffective.Poor requirements are a primary cause of more than half of all projectfailures (defined in terms of): • Major cost overruns • Major schedule overruns • Major functionality not delivered • Large number of defects delivered • Delivered systems that are never usedPoor requirements are a major “root cause” of many (or most) accidentsinvolving software-intensive systems. Engineering Safety- & Security-Related Requirements 17 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  18. 18. Challenges7Current state-of-the-practice cries out for improvement: • Better consistency between safety and security engineering — More consistent concepts and terminology — Reuse of techniques across disciplines — Less unnecessary overlap and avoidance of redundant work • Better collaboration: — Between safety and security engineering — With requirements engineering • Easier certification and accreditation • Better safety- and security-related requirements • Fewer accidents and successful attacks that cause less harm to defended assets Engineering Safety- & Security-Related Requirements 18 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  19. 19. Where We AreRelated DisciplinesChallengesCommon Example ◄Free, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 19 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  20. 20. Common Example use throughout TutorialProblem: How to enable large numbers of zoo patrons to quickly andconveniently tour the habitats of a huge new zoo?Proposed solution: the Zoo Automated Taxi System (ZATS) • Numerous small family-sized automated taxis: — Leisurely tours of habitats and fast transport between habitats — Inexpensive to operate (no driver salaries and benefits) — Reliable, easy to use, safe, and secure — Green (electric to minimize air and noise pollution) • Elevated concrete guideways: — Separate passengers from animals — Provide good views — Avoid collisions of taxis with pedestrians and vehicles in parking lot • Conveniently located taxi stations • Operations and maintenance facility in zoo back lots Engineering Safety- & Security-Related Requirements 20 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  21. 21. Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source Tool ◄Requirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 21 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  22. 22. Free, Open-Source ToolFree and open-source toolDeveloped to: • Support the collaborative defensibility engineering method • Store the complete analysis results of the ZATS common exampleExists in two forms: • Empty database for new project use • Populated database storing the “complete” analysis results of common example: ZATSImplemented using Microsoft AccessFree download from: http://donald.firesmith.net/home/safety-and-security-analysis-tool Engineering Safety- & Security-Related Requirements 22 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  23. 23. Initial Screen Engineering Safety- & Security-Related Requirements 23 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  24. 24. Prepare to Analyze Safety and Security Menu Engineering Safety- & Security-Related Requirements 24 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  25. 25. Analyze Safety and Security Menu Engineering Safety- & Security-Related Requirements 25 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  26. 26. Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering Overview ◄Safety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 26 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  27. 27. Requirements Engineering TasksBusiness Analysis (i.e., Customer, Competitor, Market, Technology, and User Analysis aswell as Stakeholder Identification and Profiling)VisioningRequirements Identification (a.k.a., Elicitation)Requirements AnalysisRequirements SpecificationRequirements ManagementRequirements ValidationScope Management (Management)Change Control (Configuration Management)Quality Control (Quality Engineering) Engineering Safety- & Security-Related Requirements 27 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  28. 28. Requirements Engineering Work ProductsBusiness analysesStakeholder profilesVision statement • Capabilities and GoalsConcept of Operations (ConOps) or operational concept document(OCD) • Mission threads • Use cases • Usage scenariosRequirements repository and published specifications • Actual requirementsRequirements prototypesDomain modelGlossary Engineering Safety- & Security-Related Requirements 28 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  29. 29. Difficulty of Requirements Engineering“The hardest single part of building a software system is deciding preciselywhat to build. No other part of the conceptual work is as difficult asestablishing the detailed technical requirements, including all theinterfaces to people, to machines, and to other software systems. No otherpart of the work so cripples the resulting system if done wrong. No otherpart is more difficult to rectify later.” Fred Brooks, No Silver Bullet, IEEE Computer, 1987 Engineering Safety- & Security-Related Requirements 29 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  30. 30. GoalsGoal an informally documented perceived need of a legitimate stakeholderGoals are: • Not requirements. • Drive the identification and analysis of the requirements. • Typically ambiguous and/or unrealistic (i.e. impossible to guarantee).Major problems with safety and security goals: • Ambiguous • Stated as absolutes • Not 100% feasible • Not verifiableTypically documented in a vision statement. Engineering Safety- & Security-Related Requirements 30 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  31. 31. Representative ZATS GoalsZATS will take passengers on leisurely tours that provide excellent viewingof the zoo habitats.ZATS will take passengers rapidly to their desired taxi stations in the zooand its parking lot.ZATS will prevent animals from reaching passengers in taxis and taxistations.ZATS will never injure or kill a passenger.ZATS will not cause air and noise pollution.ZATS will be easy and intuitive for all of its passengers to use.ZATS will allow passengers to use securely use bank cards to pay fortrips. Engineering Safety- & Security-Related Requirements 31 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  32. 32. Use Case Models and Mission ThreadsUsage Scenario a specific functionally cohesive sequence of interactions between user(s), the system, and potentially other actors that provides value to a stakeholderUse Case a general way to perform a function a functionally cohesive class of usage scenariosUse Case Path (a.k.a., flow and course) an equivalence set of usage scenarios that follow the same course through a use caseMission Thread an end-to-end sequence of use case paths that together achieves one of the system’s missions Engineering Safety- & Security-Related Requirements 32 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  33. 33. Use Case ModelsUse case paths: • Can be either: — Normal (Sunny Day or Happy Path) — Exceptional (Rainy Day) • Should have their own preconditions, triggers, and postconditions • Are often documented with text, sequence diagrams, or activity diagramsUse cases, use case paths, and usage scenarios: • Typically documented in a ConOps or operational concept document (OCD) • Drive the identification and analysis of the [primarily functional] requirements • Often include potential architectural and design informationUse cases are far more than merely use case diagrams. Engineering Safety- & Security-Related Requirements 33 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  34. 34. Characteristics of Good RequirementsAll Types of Requirements Active VoiceCorrect Configuration Controlled Consistent (internally and with other requirements)Cohesive (individual) Differentiated from Non-requirementsComplete Externally observableConcise Grammatically Correct and no TyposFeasible Managed (in requirements repository)Mandatory (necessary) Prioritized (for scheduling implementation) Properly SpecifiedNormal and Exceptional RationalizedRelevant ScheduledUnique Stakeholder-centricUnambiguous Situation-specific (to mode, state, and/or event)Validatable Traced (to source and to architecture) Uniquely identifiedVerifiable Usable by stakeholdersWhat or how well, not how http://www.jot.fm/issues/issue_2003_07/column7 Engineering Safety- & Security-Related Requirements 34 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  35. 35. Poor Requirements Cause Accidents1“For the 34 (safety) incidents analyzed, 44% had inadequatespecification as their primary cause.” Health and Safety Executive (HSE), Out of Control: Why Control Systems Go Wrong and How to Prevent Failure (2nd Edition), 1995“Almost all accidents related to software components in the past 20years can be traced to flaws in the requirements specifications, such asunhandled cases.” Grady Lee, Jeffry Howard, and Patrick Anderson, “Safety-Critical Requirements Specification and Analysis using SpecTRM”, Safeware Engineering, 2002 Engineering Safety- & Security-Related Requirements 35 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  36. 36. Poor Requirements Cause Accidents2“Erroneous specification is a major source of defects and subsequentfailure of safety-critical systems. Many failures occur in systems usingsoftware that is perfect, it is just not the software that is neededbecause the specification is defective.” John C. McKnight, “Software Challenges in Aviation Systems,” Proceedings of the 21st International Conference on Computer Safety, Reliability and Security, 2002“Software-related accidents almost always are due tomisunderstandings about what the software should do.” Kathryn Anne Weiss, “An Analysis of Causation in Aerospace Accidents,” Proceedings of the 2001 Digital Avionics Systems Conference, updated 7 September 2004 Engineering Safety- & Security-Related Requirements 36 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  37. 37. Poor Requirements Cause Accidents3“Software-related accidents are usually caused by flawed requirements.Incomplete or wrong assumptions about the operation of the controlledsystem can cause software related accidents, as can incomplete or wrongassumptions about the required operation of the computer. Frequently,omitted requirements leave unhandled controlled-system states andenvironmental conditions.” Nancy G. Leveson, Safeware: System Safety and Computers, 2003“Software-related accidents are almost all caused by flawedrequirements: • Incomplete or wrong assumptions about the operation of the controlled system or required operation of the computer • Unhandled controlled-system states and environmental conditions.” Nancy G. Leveson, A new Approach to Ensuring Safety in Software and Human Intensive Systems, July 2009 Engineering Safety- & Security-Related Requirements 37 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  38. 38. The Many Types of Requirements Business Industry Laws and Natural Organizational Rules Standard Regulations Laws Policies Innovative Rules Requirements Positive (shall) Documentation Entity Data * Requirements Requirements Requirements Requirements Stakeholder Facility Hardware Object Negative Requirements Requirements Requirements Requirements (shall not) Requirements Derived People (Role) Procedure Material (Technical) Requirements Requirements Requirements Requirements Requirements Software System / Development Requirements Subsystem Environment Requirements Requirements Architecture Process Constraints Manufacturing Product (Method) Requirements Requirements Primary Mission Design Requirements Requirements Constraints Operational Requirements Supporting Implementation Requirements Constraints Training Requirements “Pure” Integration Maintenance Constraints Requirements Constraints Requirements Non-Functional Requirements Manufacturing Sustainment Requirements Constraints Retirement Functional Entity (Data *) Interface Quality Deployment Requirements Requirements Requirements Requirements Requirements Constraints Engineering Safety- & Security-Related Requirements 38 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  39. 39. Product RequirementsA product requirement is a requirement for a product (e.g., system,subsystem, software application, or component). • A functional requirement is a product requirement than specifies a mandatory function (i.e., behavior) of the product. • A data requirement is a product requirement that specifies mandatory [types of] data that must be manipulated by the product. • An interface requirement is a product requirement that specifies a mandatory interface with (or within) the product. • A quality requirement is a product requirement that specifies a mandatory amount of a type of product quality (characteristic or attribute). • A constraint is a property of the product (e.g., architecture or design decision) that would ordinarily not be a requirement but which is being mandated as if it were a normal requirement Engineering Safety- & Security-Related Requirements 39 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  40. 40. Quality Models Architectural Components define the meaning of the quality of Quality Systems Models define the meaning of a specific type of quality of are measure measured quality along Quality along Quality Quality Quality Measurement Measurement Characteristics Attributes Scales Methods are measured using Developmental Operational Quality Quality Characteristics Characteristics Engineering Safety- & Security-Related Requirements 40 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  41. 41. Quality Characteristics (Operational) Quality Characteristics Developmental Operational Quality Characteristics Quality Characteristics Configurability Efficiency Functionality Interoperability Serviceability Usability Compliance Dependability Environmental Habitability Operability Transportability CompatibilityRobustness Defensibility Performance Soundness Safety Survivability Availability Correctness Predictability Security Capacity Reliability Stability Engineering Safety- & Security-Related Requirements 41 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  42. 42. Performance Attributes Jitter Problem Latency Prevention Harm Arrest Response Time Problem Detection Schedualability Harm Mitigation Problem Failure Analysis Throughput Reaction Failure Recovery Problem Type Solution Type Performance Attributes Performance Attributes System Adaptation measure quality along Performance Performance Attributes are measured along Quality Quality Quality Quality Measurement Measurement Characteristics Attributes Scales Methods define the meaning of the Quality quality of Models Systems Engineering Safety- & Security-Related Requirements 42 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  43. 43. Defensibility Quality Attributes Occurrence of Unauthorized Harm Harm Arrest Occurrence of Abuse Harm Mitigation (Safety Mishap or Security Misuse) Problem Abuse Analysis Existence of System-Internal Vulnerability Prevention Abuse Recovery Existence of System-External Abuser Problem Detection System Existence of Danger (Hazard or Threat) Adaptation Problem Existence of Defensibility Risk Reaction Counterattack (Security and Survivability) Problem Type Solution Type Defensibility Attributes Defensibility Attributes Safety measure quality along Security Defensibility Defensibility Attributes Survivability are measured along Quality Quality Quality Quality Measurement Measurement Characteristics Attributes Scales Methods define the meaning of the Quality quality of Models Systems Engineering Safety- & Security-Related Requirements 43 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  44. 44. Different Types of Defensibility Requirements Problem Type Quality Attributes DefensibilityQuality Attributes Harm to Defensibility Abuse Abuser Vulnerability Danger Valuable Asset Risk Prevent Prevent Prevent Prevent Prevent Prevent Prevention Occurrence Occurrence Existence Existence of Existence ExistenceQuality Attributes Solution Type of Harm of Abuse of Abuser Vulnerability of Danger of Risk Detect Detect Detect Detect Detect Detect Detection Occurrence Occurrence Existence Existence of Existence Existence of Harm of Abuse of Abuser Vulnerability of Danger of Risk React to React to React to React to React to React to Reaction Occurrence Occurrence Existence Existence of Existence Existence of Harm of Abuse of Abuser Vulnerability of Danger of Risk Engineering Safety- & Security-Related Requirements 44 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  45. 45. Components of a Quality Requirement state stakeholders’ Quality Goals importance of achieving specify achievement of define stakeholders’ minimum acceptable levels of quality for a Quality Requirements System are applicable shall Conditions during or at System-Specific exceed Quality Thresholds or Events Quality Criteria indirectly state directly state are measured are measured existence of existence of along using Quality Quality Quality Quality Measurement Measurement Characteristics Attributes Scales Methods Quality define the meaning of the quality of a Models Engineering Safety- & Security-Related Requirements 45 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  46. 46. Example Quality RequirementHazard prevention safety requirement:“Under normal operating conditions, ZATS shall not move when it’s doorsare open at an average rate higher than once every 10,000 trips.”Component parts: • Condition: “Under normal operating conditions” • Mandatory system-specific quality criterion: “ZATS shall not move when it’s doors are open” • Measurement threshold: “at an average rate higher than once every 10,000 trips.”Definitions needed to avoid ambiguity: • Moving – traveling faster than 0.1 cm per second • Open – open more than 1 cm between doors • Normal operating conditions – neither during maintenance nor a fire • Trip – travel with passengers from a starting taxi station to the associated destination taxi station Engineering Safety- & Security-Related Requirements 46 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  47. 47. Importance of Measurement ThresholdMeasurement threshold is: • Critical • Difficult (but not impossible) to determine • Often left out of quality requirements • Needed to avoid ambiguityStates how much quality is necessary (sufficient)Enables architects and architecture evaluators to: • Determine if architecture is adequate • Make engineering tradeoffs between competing quality characteristics and attributesEnables tester to determine the: • Test completion criteria • Number and types of test cases Engineering Safety- & Security-Related Requirements 47 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  48. 48. Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering Overview ◄Safety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 48 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  49. 49. Fundamental Safety and Security ConceptsSafety and security as quality characteristics with associated qualityattributesStakeholdersDefended assetsUnauthorized harm to defended assetsAbuses (accidents, attacks, and incidents)Vulnerabilities (system-internal weaknesses or defects)Abusers (external and internal, malicious and non-malicious)Dangers (hazards and threats)Defensibility risks (safety and security)Goals, policies, and requirementsDefenses (safeguards and counter measures) Engineering Safety- & Security-Related Requirements 49 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  50. 50. Safety as a Quality CharacteristicSafety is the subclass of defensibility capturing the degree to which: • The following safety problems: — Accidental harm to defended assets — Safety abuses (mishaps such as accidents and safety incidents) — Safety abusers (people, systems, and the environment) — Safety vulnerabilities — Safety dangers (hazards) including the existence (conditions) of non-malicious abusers who unintentionally exploit system vulnerabilities to accidentally harm vulnerable defended assets — Safety risks • Have safety solutions: — Prevented (eliminated, mitigated, keep acceptably low) — Detected — Reacted to Engineering Safety- & Security-Related Requirements 50 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  51. 51. Security as a Quality CharacteristicSecurity is the subclass of defensibility capturing the degree to which: • The following security problems: — Malicious harm to defended assets — Security abuses (misuses such as attacks and security incidents) — Security abusers (attackers and malware – systems, software, and hardware) — Security vulnerabilities — Security dangers (threats) including the existence (conditions) of malicious abusers who can exploit system vulnerabilities to harm vulnerable defended assets — Security risks • Are security solutions: — Prevented (eliminated, mitigated, keep acceptably low) — Detected — Reacted to Engineering Safety- & Security-Related Requirements 51 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  52. 52. Where We AreThree DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related Requirements ◄Collaborative Defensibility Engineering MethodConclusion Engineering Safety- & Security-Related Requirements 52 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  53. 53. Types of Safety- and Security-Related RequirementsToo often only a single type of requirements is considered.Not just: • Specific types of non-functional requirements (NFRs): — Safety and security requirements are quality requirements • Functional, data, and interface requirements with safety or security ramifications • Architecture and design constraints • Safety and security functions/subsystems • Software requirements • Constraints on functional requirementsReason for presentation title: Safety- and security-related requirements for software-intensive systems Engineering Safety- & Security-Related Requirements 53 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  54. 54. Types of Requirements Business Industry Laws and Natural Organizational Rules Standard Regulations Laws Policies Innovative Rules Requirements Positive (shall) Documentation Entity Data * Requirements Requirements Requirements Requirements Stakeholder Facility Hardware Object Negative Requirements Requirements Requirements Requirements (shall not) Requirements Derived People (Role) Procedure Material (Technical) Requirements Requirements Requirements Requirements Requirements Software System / Development Requirements Subsystem Environment Requirements Requirements Architecture Process Constraints Manufacturing Product (Method) Requirements Requirements Primary Mission Design Requirements Requirements Constraints Operational Requirements Supporting Implementation Requirements Constraints Training Requirements “Pure” Integration Maintenance Constraints Requirements Constraints Requirements Non-Functional Requirements Manufacturing Sustainment Requirements Constraints Retirement Functional Entity (Data *) Interface Quality Deployment Requirements Requirements Requirements Requirements Requirements Constraints Engineering Safety- & Security-Related Requirements 54 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  55. 55. Different Types of Defensibility Requirements Problem Type Quality Attributes DefensibilityQuality Attributes Harm to Defensibility Abuse Abuser Vulnerability Danger Valuable Asset Risk Prevent Prevent Prevent Prevent Prevent Prevent Prevention Occurrence Occurrence Existence Existence of Existence ExistenceQuality Attributes Solution Type of Harm of Abuse of Abuser Vulnerability of Danger of Risk Detect Detect Detect Detect Detect Detect Detection Occurrence Occurrence Existence Existence of Existence Existence of Harm of Abuse of Abuser Vulnerability of Danger of Risk React to React to React to React to React to React to Reaction Occurrence Occurrence Existence Existence of Existence Existence of Harm of Abuse of Abuser Vulnerability of Danger of Risk Engineering Safety- & Security-Related Requirements 55 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  56. 56. Types of Defensibility-Related Requirements – 1 Safety Security Safety-Significant Safety Function/Subsystem Requirements Requirements Constraints Requirements Security- Security Security Security Significant Function/Subsystem Requirements Constraints Requirements Requirements Defensibility- Defensibility Defensibility Defensibility Significant Function/Subsystem Requirements Constraints Requirements Requirements Safety-Related System Defensibility- Requirements Requirements Related Requirements Security-Related Requirements Engineering Safety- & Security-Related Requirements 56 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  57. 57. Types of Defensibility-Related Requirements – 2 Safety/Security- Safety/Security Significant Safety/Security Requirements Requirements Constraints Safety/Security Requirements that All Requirements Function/Subsystem are neither safety- Requirements nor security-related Engineering Safety- & Security-Related Requirements 57 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  58. 58. Types of Defensibility-Related Requirements – 3 Safety/Security Assurance Level (SAL) Defensibility Quality Intolerable Requirements Requirements Defensibility-Related Requirements SAL = 5 Defensibility Function / Supporting Critical Subsystem Requirements Defensibility-Related Requirements Requirements SAL = 4 Defensibility Constraints Constraints Major Defensibility-Related Other Requirements Defensibility- SAL = 3 Related Functional Requirements Requirements Moderate Defensibility-Related Quality Requirements Defensibility-Related Requirements SAL = 2 Requirements SAL = 1 - 5 System Data Minor Requirements Requirements Defensibility-Related Requirements SAL = 1 Interface Requirements Defensibility-Independent Requirements Constraints SAL = 0 Engineering Safety- & Security-Related Requirements 58 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  59. 59. 1) Safety and Security RequirementsSafety and security requirements are quality requirements.Quality requirements are product requirements that specify a mandatoryminimum amount of a type of product quality: • Quality characteristic (generally) • Quality attributes (specifically)Safety and security requirements: • Are typically negative requirements • Specify what the system shall not cause, enable, or allow to: — Occur (e.g., unauthorized harm to defended assets, accidents, attacks) — Exist (e.g., vulnerabilities, threats, abusers, hazards, risks) Engineering Safety- & Security-Related Requirements 59 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  60. 60. Safety and Security RequirementsQuality requirements should be: • Scalar (how well or how much) • Based on a quality model defining the specific types of quality and how their measurement scales • Stored in requirements repositories and specified in requirements specifications, NOT just in: — Secondary specifications — Safety/security documentsQuality requirements are critically important drivers of the architecture andtesting. Engineering Safety- & Security-Related Requirements 60 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  61. 61. Example Safety Requirement TemplatesWhen in mode V, the system shall limit the occurrence of accidental harmof type W to defended assets of type X to an average rate of no more thanY asset value per Z time duration.When in mode W, the system shall not cause mishaps of type X with anaverage rate of more than Y mishaps per Z trips.When in mode X, the system shall not cause hazard Y to exist for morethan an average of Z percent of the time.When in mode X, the system shall not have a residual safety risk level of Yor above.When in mode X, the system shall detect accidents of type Y an averageof at least Z percent of the time.Upon detecting an accident of type W when in mode X, the system shallreact by performing functions Y an average of at least Z percent of thetime. Engineering Safety- & Security-Related Requirements 61 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  62. 62. Example Security Requirement TemplatesWhen in mode V, the system shall limit the occurrence of malicious harmof type W to defended assets of type X to an average rate of less than Yasset value per Z time duration.When in mode W, the system shall prevent the first successful attacks oftype X for a minimum of Z time duration.When in mode X, the system shall not have security vulnerability Y formore than an average of Z percent of the time.When in mode X, the system shall not have a security risk level of Y.When in mode X, the system shall detect misuses of type Y an average ofat least Z percent of the time.Upon detecting a misuse of type W when in mode X, the system shallreact by performing functions Y an average of at least Z percent of thetime. Engineering Safety- & Security-Related Requirements 62 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  63. 63. 2) Defensibility-Significant Requirements – 1Defensibility-significant requirement a requirement with significant safety or security ramificationsAre identified based on safety or security (e.g., hazard or threat) analysisCan be any kind of product requirements: • Functional, data, interface, quality, and constraints • Pure safety and security requirements • Safety and security function/subsystem requirements • Safety and security constraints Engineering Safety- & Security-Related Requirements 63 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  64. 64. Defensibility-Significant Requirements – 2 Safety/Security-Upper 3 circles Safety/Security Significant Safety/Security Requirements Requirements ConstraintsHorizontal linesNot all of thesafety/securityfunction/subsystemrequirements Safety/Security Requirements that All Requirements Function/Subsystem are neither safety- Requirements nor security-related Engineering Safety- & Security-Related Requirements 64 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  65. 65. Safety/Security Assurance Levels (SALs) Safety/Security Assurance Level (SAL) Defensibility Quality Intolerable Requirements Requirements Defensibility-Related Requirements SAL = 5 Defensibility Function / Supporting Critical Subsystem Requirements Defensibility-Related Requirements Requirements SAL = 4 Defensibility Constraints Constraints Major Defensibility-Related Other Requirements Defensibility- SAL = 3 Related Functional Requirements Requirements Moderate Defensibility-Related Quality Requirements Defensibility-Related Requirements SAL = 2 Requirements SAL = 1 - 5 System Data Minor Requirements Requirements Defensibility-Related Requirements SAL = 1 Interface Requirements Defensibility-Independent Requirements Constraints SAL = 0 Engineering Safety- & Security-Related Requirements 65 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  66. 66. Example Safety-Significant RequirementsFiring missiles from military aircraft requirements: • When to arm missiles • When not to arm missiles (e.g., detecting weight-on-wheels) • Controlling doors before and after firing missilesChemical plant requirements: • Mixing and heating toxic chemicals • Controlling exothermic reactions • Detecting and controlling temperature, pressure, and flow-rateZATS requirements: • Taxi starting, accelerating, cruising, decelerating, and stopping • Opening and closing doors (taxi, taxi station safety wall, taxi station elevator) Engineering Safety- & Security-Related Requirements 66 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  67. 67. Example Security-Significant RequirementsAccess control requirements: • Identification, authentication, and authorizationAccountability (e.g., non-repudiation requirements): • Creation, storage, and transmission of financial transactionsAvailability (under attack) requirements: • Services subject to denial-of-services attacksConfidentiality requirements: • Storage and transmission of sensitive information • Confidential intellectual property in the software or its documentationIntegrity requirements: • Storage and transmission of sensitive data • Software that might get Infected by malware Engineering Safety- & Security-Related Requirements 67 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  68. 68. 3) Defensibility Function/Subsystem Rqmts – 1Defensibility function/subsystem requirements are requirements forfunctions or subfunctions that exist strictly to improve defensibility (asopposed to support the primary mission requirements). • Safety function/subsystem requirements are requirements for safety functions or subsystems. • Security function/subsystem requirements are requirements for security functions or subsystems. Engineering Safety- & Security-Related Requirements 68 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  69. 69. Defensibility Function/Subsystem Rqmts – 2 Safety/Security-Bottom circle Safety/Security Significant Safety/Security Requirements Requirements ConstraintsVertical linesOverlaps other 3typesNot all of thesafety/securityfunction/subsystemrequirements aresafety/securitysignificant Safety/Security Requirements that All Requirements Function/Subsystem are neither safety- Requirements nor security-related Engineering Safety- & Security-Related Requirements 69 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  70. 70. Example Safety Functions/SubsystemsAutomobile functions or subsystems added strictly for safety: • Adaptive Cruise Control (ACC) • Forward Collision Warning Systems • Adaptive Headlights • Intelligent Parking Assist Systems (IPAS) • Airbag Systems • Lane Departure Warning Systems • Anti-lock Braking Systems (ABS) • On-Board Diagnostics (OBD) • Automatic Braking • On-Board Prognostics (OBP) • Automatic Crash Response • Reverse Backup Sensors Systems • Seat Belt Systems • Automotive Night Vision Systems • Tire Pressure Monitoring Systems • Backup Cameras • Traction Control Systems (TCS) • Backup Collision Intervention Systems • Electronic Brakeforce Distribution (EBD) • Electronic Stability Control (ESC) • Emergency Brake Assist (EBA) Engineering Safety- & Security-Related Requirements 70 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  71. 71. Example Security Functions/Subsystems – 1Automobile functions or subsystems added strictly for security: • Car Alarm Systems • Door Locks • Ignition Key Systems • Stolen Vehicle Recovery Systems Engineering Safety- & Security-Related Requirements 71 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  72. 72. Example Security Functions/Subsystems – 2Functions or subsystems strictly added for security: • Access control • Antivirus / antispyware / antispam / antiphishing subsystems • Encryption/decryption subsystem • Firewalls • Intrusion detection subsystem (IDS) / intrusion prevention subsystem (IPS)All requirements for such functions/subsystems are security-related.Look in the Common Criteria (ISO/IEC 15408) for many generic reusablesecurity function requirements. Engineering Safety- & Security-Related Requirements 72 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  73. 73. Example Safety Function/Subsystem RqmtsExcept when the weapons bay doors are open or have been open withinthe previous 90 seconds, the weapons bay cooling subsystem shallmaintain the temperature of the air in the weapons bay at or below X° C.The Fire Detection and Suppression Subsystem (FDSS) shall detectsmoke above X ppm in the weapons bay within 2 seconds at least 99.9%of the time.The FDSS shall detect temperatures above X° C in the weapons baywithin 2 seconds at least 99% of the time.Upon detection of smoke or excess temperature, the FDSS shall begin firesuppression within 1 second at least 99.9% of the time. Engineering Safety- & Security-Related Requirements 73 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  74. 74. Example Security Function/Subsystem RqmtsAccess Control Function: • The Access Control Function shall require at least 99.99% of users to identify themselves before enabling them to perform the following actions: … • The Access Control Function shall require at least 99.99% of users to successfully authenticate their claimed identity before enabling them to perform the following actions: … • The Access Control Function shall authorize the system administrators to configure the maximum number of unsuccessful authentication attempts between the range of 1 and X. • The Access Control Function shall perform the following actions when the maximum number of unsuccessful authentication attempts has been exceeded: … Engineering Safety- & Security-Related Requirements 74 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  75. 75. 4) Defensibility Constraints – 1A constraint is any engineering decision that has been chosen to bemandated as a requirement. For example: • Architecture constraints • Design constraints • Implementation constraints (e.g., coding standards, safe language subset, and nonhazardous materials) • Integration constraints • Deployment or configuration constraintsA safety constraint is any constraint primarily intended to ensure aminimum level of safety (e.g., a mandated safeguard).A security constraint is any constraint primarily intended to ensure aminimum level of security (e.g., a mandated countermeasure).Safety and security standards often mandate industry best practices asconstraints. Engineering Safety- & Security-Related Requirements 75 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  76. 76. Defensibility Constraints – 2 Safety/Security-Right circle Safety/Security Significant Safety/Security Requirements Requirements ConstraintsDiagonal linesOverlaps only 2 ofthe other typesAll of the defensibilityconstraints aresafety- or security-significant Safety/Security Requirements that All Requirements Function/Subsystem are neither safety- Requirements nor security-related Engineering Safety- & Security-Related Requirements 76 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  77. 77. Example Safety ConstraintsThe system shall use hardware interlocks to prevent users from physicallycoming into contact with moving parts.The system shall not have a single point of failure that can cause anaccident unless the associated risk is acceptable to authoritativestakeholders.The system shall use a safe subset of C++.The system shall not contain any of the hazardous materials in Table X inconcentrations in excess of those listed in the table: • Biologically Hazardous Materials (e.g., infectious agents or toxins) • Chemically Hazardous Materials (e.g., carcinogens, corrosives, heptatoxins, irritants, mutagens, nephratoxins, neurotoxins, poisons, or teratogens) • Physically Hazardous Materials (e.g., combustible chemicals, compressed gases, explosives, flammable chemicals, oxidizers, or pyrophorics) Engineering Safety- & Security-Related Requirements 77 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  78. 78. Example Security ConstraintsThe system shall user use IDs and passwords for identification andauthentication.The system shall incorporate COTS firewalls to protect servers.The system shall incorporate the latest version of Norton Antivirus formalware detection and removal.The system shall use public key encryption to protect confidentialinformation.The system shall use digital signatures to provide nonrepudiation. Engineering Safety- & Security-Related Requirements 78 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  79. 79. Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering Method ◄Conclusion Engineering Safety- & Security-Related Requirements 79 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  80. 80. Desired Method PropertiesHelp meet challenges listed at start of tutorialPromote close collaboration among safety, security, and requirementsteamsBetter integrate safety and security methods: • Based on common foundational concepts and terminology • Reuse of techniques and work products • Based on defensibility (safety and security) analysisBetter integrate safety and security engineering with requirementsengineering: • Clearly defined role and team responsibilities • Early input to requirements engineering • Develop all types of safety- and security-related requirements • Ensure these requirements have the proper characteristics Engineering Safety- & Security-Related Requirements 80 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  81. 81. Overall Defensibility Engineering Method Defensibility Defensibility Defensibility Policy Monitoring Event Handling DevelopmentDefensibility Defensibility Program Planning Analysis Defensibility Defensibility Defense Compliance Certification and Determination Assessment Accreditation Engineering Safety- & Security-Related Requirements 81 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×