• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Engineering Safety and Security-Related Requirements
 

Engineering Safety and Security-Related Requirements

on

  • 344 views

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

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

Statistics

Views

Total Views
344
Views on SlideShare
344
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Engineering Safety and Security-Related Requirements Engineering Safety and Security-Related Requirements Presentation Transcript

    • EngineeringSafety- and Security-RelatedRequirementsDonald FiresmithSoftware Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 1521318 June 2012Half-Day Tutorial © 2012 Carnegie Mellon University
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Initial Screen Engineering Safety- & Security-Related Requirements 23 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Prepare to Analyze Safety and Security Menu Engineering Safety- & Security-Related Requirements 24 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Analyze Safety and Security Menu Engineering Safety- & Security-Related Requirements 25 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Defensibility Analysis System Safety Team Security Team Defensibility Safety and collaborates Analysis Security Requirements with Engineering Engineering SMEs Stakeholder Defensibility Requirements Team Analysis performs Safety Relevant Laws,Regulations, and Asset Requirements Standards Analysis performs Security Organizational Requirements and Project Abuse Defensibility Analysis Policies Defensibility Defensibility- Defensibility Requirements Analysis Related Reusable Analysis Development Vulnerability Work Products RequirementsSafety & Security Work Products Analysis Requirements Safety- Contractual Validation Significant Documents Abuser Requirements AnalysisSafety & Security Security- Program Plans support perform Significant Danger Requirements Requirements Engineering Analysis Subject Work Products Safety and Security Safety Security Matter Team Team Experts Stakeholders Certification Architectural Repositories Risk Engineering Analysis Work Products Significance Analysis Engineering Safety- & Security-Related Requirements 82 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • System Defensibility Analysis Safety Team Security Team Requirements collaborates Engineering with Requirements Requirements Models Team Understand Requirements Requirements Documents performs Requirements System Defensibility Analysis Architecture Team Architecture Model Understand Architecture Safety and Architecture Security Documents Engineering Architecture Engineering Engineering Safety- & Security-Related Requirements 83 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Stakeholder Defensibility Analysis Safety Team Security Team collaborates with Safety and Security Subject Matter Experts Engineering (SMEs) provide input Requirements during Teams performs Preparation Stakeholders provide input Stakeholder Updated during Identification Stakeholder List Stakeholder Defensibility Analysis Updated Contractual Documentation Stakeholder (RFP, Contract) Profiles Stakeholder Modeling Requirements Defensibility Work Products Stakeholder (Vision Statement, ConOps, Interests Table Initial Stakeholder List, Stakeholder Profiles, Initial Draft Requirements Models, Initial Goal Safety and Security Specifications, and Identification Goals Repositories) Existing Documentation (Organizational Defensibility Policies and Legacy Hazard Safety and Security and Threat Analyses, Certification Mishap and Misuse Reports, Repositories and Stakeholder Lists) Engineering Safety- & Security-Related Requirements 84 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Stakeholders Human play Organizational play Direct Stakeholders Stakeholders Stakeholders Indirect Human Organization Stakeholders Roles Roles Attackers Stakeholders Legitimate Stakeholders have desire to Asset System harm the Stakeholders Stakeholders primarily have primarily have have a interest in interest in legitimate and value other and value the interest in the must Defended defend System Assets must meet Stakeholder Needs Engineering Safety- & Security-Related Requirements 85 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Stakeholders Entry/Edit Form Engineering Safety- & Security-Related Requirements 86 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Stakeholders Report Engineering Safety- & Security-Related Requirements 87 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example Stakeholder Safety/Security Analysis Safety/Security Analysis of PMI Corporate Management General Responsibilities: – Ensure the short- and long-term profitability of PMI. – Ensure the marketability of PMI automated people movers (APM). – Ensure customer and user satisfaction with PMI APMs. – Ensure the quality of PMI APMs (e.g., capacity, maintainability, reliability, usability). Safety/Security Responsibilities: – Provide leadership in safety and security matters. – Ensure that PMI APM vehicles will operate safely. – Ensure that PMI APM systems will be secure against attack (e.g., cybercrime and theft). – Ensure that PMI proprietary information will be secure from corporate espionage. – Ensure that effective safety and security policies will exist and be enforced. – Provide oversight of PMI projects with regard to safety and security. Context: – PMI is subject to very stiff competition from both domestic and foreign competitors. – PMI’s ability to create APMs that enable large numbers of small vehicles to safely share guideways with minimal headway is a cutting-edge technology that provides a competitive edge over some of PMI’s rivals. – Corporate management is primarily trained in business management and does not understand the technology, especially the importance of software to achieving technical requirements. – PMI’s previous smaller and simpler APMs have not suffered serious accidents or security attacks. – ZATS is PMI’s current flagship APM. Actual or Potential Process Model Defects: – Has underestimated the maturity and risk of the new technology. – Has assumed that ZATS development productivity will be the same or better than previous projects. – Believes that the large number of failures found and fixed during initial prototyping indicate that the major problems are all solved and are not indicative of future failures once full scale development starts and ZATS has been placed into operation. Actual or Potential Dangerous Decisions and Actions: – Has pushed ZATS project management to lower their estimates of the cost of ZATS development and the time required for ZATS development in order to win the contract. – Is counting on the project future income from ZATS, even though ZATS is likely to suffer from both cost and schedule overruns. – May let safety and security policies and requirements be violated in order to meet project budget, schedule, and functionality goals. – May provide inadequate oversight of the ZATS project with regard to safety and security. Engineering Safety- & Security-Related Requirements 88 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Asset Analysis Subject Matter Safety Team Security Team Experts collaborates Requirements Engineering with Asset-Harm Prevention Standard / Reusable Requirements Team provide Requirements Asset-HarmStakeholders input Requirements Asset-Harm during performs Detection Preparation Requirements provide input Asset Value Asset-Harm during performs Reaction Categorization Asset Requirements ZATS Contractual Asset Identification Documentation Analysis Harm Severity Categorization ZATS Requirements Asset Requirements Asset-Harm Work Products Modeling Asset Development Requirements Descriptions ZATS Architectural Asset-Harm Representations Asset Goal Asset-Harm Requirements Safety Identification Goals Validation Requirements Project-External Documentation Asset Asset-Harm ZATS Defensibility Work Product perform Security Work Products V&V support Requirements Generic Reusable Requirements Safety Security Documentation Safety and Security Team Support Team Team SMEs Stakeholders Certification Repositories Safety and Security Engineering Engineering Safety- & Security-Related Requirements 89 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Defended Assets Ownerless Objects value Unauthorized Privately Owned Harm Stakeholders Intangible Objects Objects can happen to have an Publically Owned Physical Objects interest in the Objects must defend Inanimate Objects Defended System Living Objects Assets Objects Atmosphere play Roles Things Biosphere Electromagnetic Roles Played play Spectrum People Environment By People Hydrosphere Roles Played By play Lithosphere Organizations Services Organizations Outer Space Prime Contractor Customer Developer Subcontractors Maintainer Operator Supplier / Vendor Owner Regulator Sustainer User Engineering Safety- & Security-Related Requirements 90 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS AssetsPeople: • Passengers - people who are riding ZATS taxisOrganizations: • Metropolitan Zoo Authority (MZA) - the organization that operates the Metropolitan Zoo and acquires ZATSProperty: • ZATS line replaceable units (LRUs) - ZATS architectural components (data, hardware, software, subsystem) that can be repaired or replaced by the maintainer after ZATS has been placed in operationEnvironment: • Atmosphere - the layer of gas surrounding the earth that is retained by gravity and subject to both air and noise pollutionService: • Taxi service - transportation by ZATS taxis of passengers and their personal property around the zoo Engineering Safety- & Security-Related Requirements 91 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Defended Assets Entry/Edit Form Engineering Safety- & Security-Related Requirements 92 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Defended Assets Report Engineering Safety- & Security-Related Requirements 93 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Unintentional Safety (Accidental)Types of Harm Harm Unauthorized Authorized e.g., caused to enemy forces by Harm Harm Intentional weapons systems Security and (Malicious) Survivability Harm can Direct Harm happen to Defended Assets Harm Indirect Harm Harm to Harm to Harm to Harm to the Harm to a People Organizations Objects Environment Service Being Bankruptcy Corruption Contami- Accidental Loss Kidnapped nation of Service Legal Conse- Damage Corruption quences Damage Corruption (bribery or Destruction extortion) Loss of Destruction Denial of Market Share Lost Value Service (DOS) Death Loss of Use Loss of Loss of Trust Theft or Disability Reputation Pollution Piracy Repudiation of Financial Loss of Unauthorized Wildlife Transaction Hardship Trained Staff Access Death, Injury, or Unauthorized Lost Illness Illness Unauthorized Usage (Theft) Opportunity Disclosure Costs Injury Lost Profits Loss of Anonymity, Identity, or Privacy Loss of Employment Engineering Safety- & Security-Related Requirements 94 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Security Characteristics as Types of Harm Accountability Nonrepudiation Data Integrity Availability (Defensibility) Document Integrity Desired Tamper System Security Integrity Hardware Integrity Resistence Characteristic Personal Integrity Software Integrity Immunity depends on Confidentiality Anonymity Identification Access Control Authentication Safety Authorization (degree qualified) Authorization Security Authorization (degree trusted) Engineering Safety- & Security-Related Requirements 95 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Harm SeverityHarm severity is an appropriate categorization of the amount of harm: • Potential harm • Actual harm • Maximum credible harmHarm severity categories can be standardized (ISO, military, industry-wide) or endeavor-specific.Harm severity categories need to be: • Clearly identified. • Appropriately and unambiguously defined.Note that some standards confuse harm severity with hazard “severity”(i.e., categorization of hazard based on the severity of harm that itsaccidents can cause) Engineering Safety- & Security-Related Requirements 96 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative Harm to a ZATS Defended AssetPerson: • Death • Injury – minor, major, and disability (physical and psychological) • Occupational illness (maintainer) • Loss of money – various amounts • Lost of confidentiality of sensitive information (passenger identity theft) • Loss of reputation (managers, developers) Engineering Safety- & Security-Related Requirements 97 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Defended Asset Types Report Engineering Safety- & Security-Related Requirements 98 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • The ZATS Harm Severity CategoriesCatastrophic: Potential ZATS lifespan harm that is unacceptable to authoritative stakeholders (loss of priceless defended asset)Major: Potential five-year harm that is only acceptable to authoritative stakeholders after major actions have been taken to lower its risk (loss of extremely defended asset)Minor: Potential yearly harm that is acceptable to authoritative stakeholders after minor action has been taken to lower its risk (loss of moderate or low value asset)Negligible: Potential yearly harm that is acceptable to authoritative stakeholders but that does not justify any action to lower its risk (loss of inconsequential asset) Engineering Safety- & Security-Related Requirements 99 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • The ZATS Harm Likelihood CategoriesFrequent: An average of once or more times every monthProbable: Less than an average of once every month (but more than occasional)Occasional: Less than an average of once every year (but more than remote)Remote: Less than an average of once every 5 years (but more than implausible)Implausible: Less than a 10% chance of happening during the entire ZATS 30 year planned lifespan Engineering Safety- & Security-Related Requirements 100 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATSAsset-Harm Safety and Security GoalsAsset-Harm Prevention Safety Goal: • ZATS will not accidentally kill or injure its passengers.Asset-Harm Detection Security Goal: • ZATS will detect infection of its data and software files by malware.Asset-Harm Reaction Security Goal: • On detecting malware infection, ZATS will quarantine the infected file and notify the operator and maintainer. Engineering Safety- & Security-Related Requirements 101 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATSAsset-Harm Safety and Security RequirementsAsset-Harm Prevention Safety Requirement: • Passenger death prevention: ZATS shall ensure that the expected frequency with which it accidentally kills a passenger does not exceed 0.1 passenger during the projected 30 year system lifespan.Asset-Harm Detection Security Requirement: • Malware detection: ZATS shall detect infection of its data and software files by at least 99% of known malware.Asset-Harm Reaction Security Requirement: • Malware reaction: On detecting malware infection, ZATS shall quarantine the infected file and notify the operator and maintainer at least 99.9% of the time. Engineering Safety- & Security-Related Requirements 102 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Abuse (Misuse and Mishap) Analysis Subject Safety and Matter Safety Team Security Team Requirements Experts collaborates Security Engineering with Engineering Abuse Prevention Requirements Team Requirements provide input Abuse Stakeholders during Preparation Detection Requirements perform provide Abuse input performs Abuse Abuse Reaction during Identification Profiles Requirements AbuseRequirements & Architecture AnalysisWork Products: Abuse Graphical Requirements Abuse- RFP and Contract- ConOps Modeling Models Development Requirements- Rqmts Repository- Architecture Abuse (Mishap) Abuse Goal Abuse Requirements SafetyProject-Specific Identification Goals Validation RequirementsWork Products:- Asset Profiles Abuse Abuse (Misuse)- Asset Value Categorization Work Product support perform Security- Harm Severity Categorization V&V RequirementsGeneric Reusable SubjectWork Products: Safety Security Matter- Abuse Lists & Tables Requirements Team Team Experts Stakeholders- Abuse Cases & Trees Team Support- Abuse Goals- Enterprise and Reference Safety and Security Architectures Certification Repositories Engineering Safety- & Security-Related Requirements 103 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Abuses (Mishaps and Misuses)Abuse (defensibility) a series (or network) of one or more unwanted events that cause (or can cause) unauthorized harm to one or more defended assetsMishap (safety) an accidental abuseMisuse (security or survivability) a intentional (malicious) abuse Engineering Safety- & Security-Related Requirements 104 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Abuses is a network of Defensibility Abuses Events Mishaps Misuses Security Survivability Misuses Misuses Safety Civilian Security Enemy Military Survivability Accidents Incidents Attacks Incidents Attacks Incidents Successful Probes Successful Civilian Enemy Military Attacks Attacks cause Unauthorized can occur to Defended Harm Assets Engineering Safety- & Security-Related Requirements 105 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Importance of Accidents (Safety)Accidents can have expensive and potentially fatal repercussions: • Ariane 5 maiden launch — Reuse of Ariane 4 software not matching Ariane 5 specification • Mars Climate Orbiter ($125 million) — English vs. Metric units mismatch • Mars Polar Lander — Missing requirement concerning touchdown sensor behavior • Patriot Missile Battery misses SCUD missile — Missing availability (uptime) requirement • Sheffield sinking during Falkland War — Radar misidentifies incoming Argentinean missile as “friendly” • Therac–25 Radiation Therapy Machine — Timing of rare input sequence results in race condition and extreme radiation doses Engineering Safety- & Security-Related Requirements 106 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Importance of Attacks (Security)Largest unauthorized disclosure of confidential information: 150,000,000 customer records on 17 March 2012, Shanghai Roadway D&B Marketing Services Co. LtdPredator and Reaper unauthorized disclosure of confidential video feeds In 2009, Iraqi insurgents were able to intercept the unencrypted video feeds from Predator and Reaper drones. No security requirements to protect sensitive video feed information during transmission.Stuxnet (cyber warfare) In 2010, the computer worm infected the supervisory control and data acquisition (SCADA) software on the programmable logic controllers (PLCs) that controlled Iran’s uranium enrichment centrifuges. Stuxnet commanded excessive rotational speeds while displaying fake normal sensor data to the operators. No security requirements to address malware, to check for valid speed inputs, or to ensure the integrity of sensor values. Engineering Safety- & Security-Related Requirements 107 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example ZATS Security Abuse (Attack) Tree Steal ZATS Legend Industrial wants to Attack Spy Attacker Intellectual Goal Instantiation (is a) Property Inheritance (is a kind of) achieves performs Industrial Aggregation (is part of) Attack Espionage Association Nation State Spy Insider Dumpster Internet Plant Physical Social Recruitment Diving Access Spy Access Engineering Domain Name Control Facility Current or Blackmail Break-in Determination Access Former Employee Bribery Impersonation ZATS Firewall Maintenance Extortion Exploit Facility Access PMI Web Server Employee Janitor Taxi Access Exploit Recruitment Safety / Security Zoo Control Server Maintainer Accreditor Administration Exploit Recruitment Office Access Safety Operator Inspector Recruitment Engineering Safety- & Security-Related Requirements 108 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Safety Abuse (Mishap) Tree Cave or Mine Ocean Building Electrical Fire and Smoke Structural Water Wind Collapse Damage Damage Damage Damage Damage Hurricane RiverSnowStorm Destroy or Damage “wants” to Natural Maintenance / Mishap Legend Storm Disaster Operations Facility “Goal” and Taxi Stations Instantiation (is a) Thunder achieves Inheritance (is a kind of) Storm Sun performs Abuse of Association Mishap ZATS BuildingTornado Tectonic Fault Cave in / Flying Heavy High Voltage Storm Wild Earthquake Sinkhole Debris Snow Spike (EMP) Surge Fire Volcano Coastal High Lightning Volcanic Flood Hail Erosion Winds Strike Ash Fall Engineering Safety- & Security-Related Requirements 109 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example ZATS Abuse (Misuse) Cases Steal from Travel Card Vending threatens Machine Buy Travel Card Steal from Bank Passenger Steal Card Server Bank Card Add Funds to Data Steal from Network Travel Card threatens Steal from threatens Passenger Ride Taxi Thief Steal from Passengers threatens Steal from Vending Machine threatens Steal Cash Steal from Service threatens Maintainer Maintainers Vending Machine Steal from Safe threatens Steal Equipment threatens Service Taxis Steal ZATS Steal Tools threatens Controller Property Steal Hardware threatens Control ZATS Steal Software threatens Engineering Safety- & Security-Related Requirements 110 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative Potential Types ofZATS Safety Abuses (Mishaps)Accident: • Rear-end Collision One taxi rear-ends another taxi causing damage to one or both of the taxis.Safety Incidents: • Bumping Bumpers One taxi lightly bumps into another taxi without causing damage to one or both taxis. • Inadequate Headway (tailgating) The distance between two adjacent taxis becomes less than the minimum safe braking distance. Starting to tailgate (event) is an safety incident (near miss), whereas Tailgating (condition) is a hazard. Engineering Safety- & Security-Related Requirements 111 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative Potential Types ofZATS Security Abuses (Misuses)Successful attacks: • Arson of Taxi Station An arsonists starts a fire in a taxi station. • Denial of Service (DoS) A cybercriminal uses signal jamming to mount a successful DoS attack against the ZATS taxis.Security Incidents: • Unsuccessful Malware Infection Software malware (e.g., worms and viruses) fails to infect a ZATS computer (e.g., because of the existence of properly installed antivirus software with current virus definitions). • Undetected Probe A cybercriminal’s attempt to identify computer vulnerabilities (e.g., open ports) goes undetected. Engineering Safety- & Security-Related Requirements 112 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Abuse (Mishap and Misuse)RequirementsMishap prevention requirement: Taxi collisions: Under normal operating conditions, ZATS shall ensure that the rate of major collisions between taxis* is less than X per [Y trips | time unit]. * Terms must be properly defined. For example, a major taxi collision could be defined as one with a relative speed of at least 10 mph. It could also be defined in terms of cost but…Misuse prevention requirement: Denial of service: ZATS shall detect Internet launched denial of service attacks within 2 minutes at least 99% of the time. Engineering Safety- & Security-Related Requirements 113 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Abuses Entry/Edit Form Engineering Safety- & Security-Related Requirements 114 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Abuses Report Engineering Safety- & Security-Related Requirements 115 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Vulnerability Analysis Architects, Designers, and Safety and Requirements Team Requirements Implementers Safety Team Security Team Security collaborates Engineering Engineering Generic / Reusable with Vulnerability Requirements Safety and Constraints Vulnerability Preparation Requirements performs Quality Engineers, Security provide Testers, and input Vulnerability Maintainers performs Vulnerability Vulnerability during Requirements Identification Table provide Vulnerability input Vulnerability and Abuse during Table Requirements Vulnerability Vulnerability Requirements Analysis Modeling Development Concept of VulnerabilityOperations (ConOps) and Defense Vulnerability Table Constraints Requirements, Vulnerability Requirements Glossaries, and Vulnerability Validation Goal Domain Models Goals Safety Identification VulnerabilitySystem Architectural Constraints support perform Representations Abuse Table Safety and Security Security Subject Vulnerability Certification Safety Security Abuse Cases Matter Constraints Repository Team Team Stakeholders Experts Abuse Trees Engineering Safety- & Security-Related Requirements 116 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • VulnerabilitiesVulnerability a potential or actual system-internal weakness or defect in the system that enables or causes: — A danger (hazard or threat) to exist. — An abuse (mishap or misuse) to occur.Ways to identify vulnerabilities include: • Analyze historical data • Identify and analyze plausible “defects”: — Requirements defects (missing, ambiguous, incomplete, or incorrect requirements) — Component internal defects (component fails to meet its requirements) — Component interaction defects (components meet individual requirements) • Consider human issues beyond “user error”: — Human limitations, financial and schedule pressures, psychology, etc. Engineering Safety- & Security-Related Requirements 117 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Vulnerabilities Data Missing Management Vulnerabilities Component Vulnerabilities Vulnerabilities Energy Safety Requirements Vulnerabilities Component- Vulnerabilities Vulnerabilities Ergonomic Internal Architectural Vulnerabilities Vulnerabilities Security Vulnerabilities Vulnerabilities Facility Component Design Defective Vulnerabilities Interaction Survivability Vulnerabilities Materials Vulnerabilities Vulnerabilities Hardware Implementation Hazardous Vulnerabilities Vulnerabilities Biologicals Material Integration Vulnerabilities Vulnerabilities Vulnerabilities Hazardous Chemicals Procedural Manufacturing Hazardous Vulnerabilities Vulnerabilities Physical Software Actual Potential Configuration Materials Vulnerabilities Vulnerabilities Vulnerabilities Vulnerabilities Subsystem Maintenance Vulnerabilities Vulnerabilities Known Unknown Vulnerabilities Vulnerabilities Engineering Safety- & Security-Related Requirements 118 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Vulnerabilities(Potential or Actual)Defensibility vulnerability: • Lack of or defective fire detection and suppression system in the ZATS buildingsSafety vulnerability: • Defect (accidentally incorporated) in the software of the LIDAR proximity detection subsystemSecurity vulnerability: • Lack of or defect in the encryption/decryption software • Incorporation of a backdoor, logic bomb, time bomb, or Trojan horse Engineering Safety- & Security-Related Requirements 119 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Vulnerabilities Entry/Edit Form Engineering Safety- & Security-Related Requirements 120 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Vulnerabilities Report Engineering Safety- & Security-Related Requirements 121 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Ways to Identify VulnerabilitiesAnalyze historical data: • Published lists of commonly occurring vulnerabilities and vulnerability typesBrainstorm plausible “defects”: • Requirements defects (missing, ambiguous, incomplete, or incorrect requirements) • Component internal defects (component fails to meet its requirements) • Component interaction defects (components meet individual requirements)Consider human issues beyond “user error”: • Human limitations, financial and schedule pressures, psychology, etc. Engineering Safety- & Security-Related Requirements 122 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • RepresentativeZATS Safety Vulnerability RequirementsVulnerability: Taxi Doors Cannot Lock: A ZATS taxi cannot lock its closed doors when moving.Vulnerability prevention requirement: Lock Taxi Doors: When its doors are closed, each ZATS taxi shall be able to lock and unlock its doors with a success rate of at least 99.99%.Vulnerability detection requirement: Detection of Unlocked Taxi Doors: When it is moving and its doors are closed, each ZATS taxi shall be able to determine if its doors are unlocked at least 99.99% of the time.Vulnerability reaction requirement: Reaction to Unlocked Taxi Doors: If any ZATS taxi is moving and detects that its doors are not locked, then the taxi shall : • Notify the ZATS operator within 5 seconds at least 99.99% of the time • Warn the taxi passengers to stay away from the doors until the taxi has berthed at the next taxi station within 1 second at least 99.99% of the time Engineering Safety- & Security-Related Requirements 123 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • RepresentativeZATS Security Vulnerability RequirementsVulnerability: Server Infected with Malware: A ZATS server is infected with malware.Vulnerability prevention requirement: Malware Infection Prevention: ZATS servers shall not be infected with known malware at least 99.99% of the time.Vulnerability detection requirement: Malware Infection Detection: Each ZATS shall detect when it is infected with known malware at least 99.99% of the time.Security vulnerability reaction requirement: Malware Infection Reaction : When a ZATS server detects that it is infected by malware, it shall: • Delete the malware at least 95% of the time • Quarantine any malware it could not remove at least 99% of the time • Notify the ZATS operator of the infection and the status (i.e., malware deleted, malware quarantined, or malware unaffected) at least 99% of the time Engineering Safety- & Security-Related Requirements 124 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Abuser AnalysisSubject Matter Safety Team Security Team Requirements Team Experts collaborates Generic / Reusable with Abuser Abuser-Related Requirements Protection Requirements provide Preparation Abuser AbuserStakeholders input Table Detection during Requirements performs Abuser Abuser performs provide Profiles Identification Abuser input Reaction during Asset Abuser Requirements Project Documentation Abuser Table Requirements(RFP, Contract, ConOps) Analysis Abuser Development Abuser- Abuser Modeling Related Abuse Asset Generic / Reusable Harm Table Requirements Abuser Lists Requirements Abuser- Validation Abuser Goal Safety Generic / Reusable Related Development Abuser Abuser Profiles Goals Requirements perform support Generic / Reusable Safety and Security Security Abuser-Related Goals Certification Abuser Repositories Subject Requirements Safety Security Matter Team Team Experts Stakeholders Safety and Security Requirements Engineering Engineering Engineering Safety- & Security-Related Requirements 125 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Abusers Foreign Disgruntled Intelligence Dishonest Script Professional Malicious Agencies Employees Kiddies Criminals Hackers Phishers & Botnet Industrial Hactivists Terrorists Spammers Operators Spies Hazardous Hazardous Hazardous Zombies Materials Parts of Nature Systems create Malware and use Zombie Systems Armies Hazardous Hazardous Hazardous Hardware Attackers Malware Energies Objects People Malware Adware Software Logic Bombs Malware Malvertisements can Unintentional Abusers Intentional Abusers can Ransomware cause (Safety) (Security) cause Root Kits Direct Actual Scareware Abusers Abusers Spyware Abusers Time Bombs Potential Indirect Abusers Abusers Trojan Horses can cause can can harm exploit Worms Abuses Vulnerabilities Viruses can harm can enable Defended Assets Safety Security Abuses Abuses Engineering Safety- & Security-Related Requirements 126 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Abuser ProfilesAbuser Profile a description of a specific type of abuser, typically including: • Means including tools, training, expertise, support, and time • Motive including both desired harm and risk aversion (for attackers) • Opportunity including access to system and defended assets • External influences such as project cost and schedule pressures, personal financial pressures • Abuser weaknesses such as human mental and physical limitations, untreated addictions and mental illnessProfiles are highly reusable.Profiles more commonly used for attackers than non-malicious abusers,but are useful for both. Engineering Safety- & Security-Related Requirements 127 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative Potential ZATS AbusersAccidental human abuser: • Maintainers (who make mistakes if inattentive, careless, or fatigued)Accidental external system abuser: • Electrical power grid (which may provides current or voltage spikes and surges, sustained overvoltage or undervoltage, complete power loss, random noise, or electromagnetic interference)Accidental environmental abuser: • Storm (which may provide high winds, hail, heavy snow, ice, etc.)Attacker (malicious human abuser): • Industrial spy (who may steal proprietary data)Malware (malicious nonhuman abuser): • Adware, ransomware, scareware, spyware, virus, or worm Engineering Safety- & Security-Related Requirements 128 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Abusers Entry/Edit Form Engineering Safety- & Security-Related Requirements 129 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Abusers Report Engineering Safety- & Security-Related Requirements 130 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Abuser RequirementsSafety abuser prevention requirement: ZATS shall ensure that its operations and maintenance facility is beyond reach of the nearby river, even in the event of 100 year floods.Security abuser prevention requirement: ZATS shall prevent attackers of type X with profile Y from successfully causing the loss of confidentiality and integrity of sensitive information Z by preventing attacks lasting no more than 8 total hours at least 99% of the time. Engineering Safety- & Security-Related Requirements 131 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Danger Analysis Safety Team Security Team collaborates Subject Matter with Safety and Security Requirements Experts Engineering Engineering Requirements Team Danger Protection Requirements Preparation Generic / Reusable Hazard and Threat Danger provide Danger Requirements Stakeholders Danger (Hazard Detection input Identification & Threat) Requirements during performs performs List provide Danger Danger input Profiling Reaction Danger during Requirements Task ProfilesSystem Safety and Analysis Requirements Danger Security Development Analysis Danger Documentation Cause Danger Requirements Analysis Cause &Generic / Reusable Effects Danger Requirements Danger Lists Diagrams Modeling Root Validation Cause(s) Safety HazardGeneric / Reusable Analysis Requirements Danger Profiles perform FMECA support Common Tables Security Generic / Reusable Cause ThreatDanger Probabilities Analysis Subject Requirements HAZOP Safety Security Matter Danger Tables Team Team Experts Stakeholders Safety and Effects Security Analysis Certification Danger Goal Danger Requirements Repositories Identification Goals Engineering Engineering Safety- & Security-Related Requirements 132 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Components of Dangers are simultaneous and co-located combinations of dangerous Dangers Conditions increase the Existence Existence of probability of of Abusers Defended Assets Existence of Other can Vulnerabilities Conditions cause Abuses Abusers can cause Unauthorized Vulnerabilities Harm can exist in can happen to abuse System Defended Assets must defend Engineering Safety- & Security-Related Requirements 133 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Dangers Acoustic Business Hazards Hazards Biological Malware Hazards Computational Security Survivability Chemical Hazards Hazards Threats Threats Electrical Hazards Environmental Computational Fire Hazards Threats HazardsGravitational Human Hazards Threats Hazards Hazards Kinetic Human Hazards Threats Material Physical Hazards Hazards Dangers Mechanical Hazards Procedural Radiation Attackers Hazards Hazards Thermal Hazards Actual PotentialMiscellaneous Dangers Dangers Hazards Engineering Safety- & Security-Related Requirements 134 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • DangersDanger a potential or actual situation that increases the likelihood of one or more related abusesHazard a danger that increases the likelihood of mishaps (safety)Threat a danger that increases the likelihood of misuses (security)A danger consists of one or more conditions concerning the existence of: • Vulnerable defended assets that can be harmed by abuses • System-internal vulnerabilities or other system-internal conditions, states, or modes • System-external abusers or other system-external conditions, states, or modesDangers are sets of concurrent conditions, whereas abuses are networksof events. Engineering Safety- & Security-Related Requirements 135 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Identifying Dangers (Hazards and Threats)Several approaches exist that can be used to identify dangers: • Abuse-Based Identification – Consider each identified abuse to identify the associated dangers that increase the probability of the abuse occurring. • Abuser-Based Identification – Consider each identified abuser to identify the associated dangers that include the existence of the abuser as a component condition. This is especially useful for identifying security threats based on generic types of attackers and malware. • Asset-Based Identification – Consider each defended asset to identify the dangerous conditions that can lead to that asset being harmed. • Task-Based Identification – Consider each task performed by a “user” of the system to identify the relevant dangers that can exist. Observe the users while performing their tasks. • Use-Case-Based Identification – Consider each use case and use case flow to identify the associated dangers. • Vulnerability-Based Identification – Consider each vulnerability to identify the associated dangers. Engineering Safety- & Security-Related Requirements 136 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Traditional Hazard Analysis (Safety)1As used in the safety community, hazard analysis usuallyimplies the analysis of assets, harm, incidents, hazards, andrisks.Hazard analysis often occurs multiple times before variousmilestones: • Preliminary Hazard Analysis (PHA) • System Hazard Analysis (SHA)Hazard analysis should probably be performed continuously. Engineering Safety- & Security-Related Requirements 137 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Traditional Hazard Analysis (Safety)2Traditional hazard analysis techniques: • Come from reliability analysis • Concentrate on individual component failures • Do not address all (or even most) safety concerns • Are inadequate for software and “human error”Traditional techniques borrowed from reliability include: • Event Tree Analysis (ETA) • Fault Tree Analysis (FTA) • Hazard Cause and Effect Analysis (HCEA) • Failure Mode Effects Criticality Analysis (FMECA) Engineering Safety- & Security-Related Requirements 138 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example ZATS Hazard, Events, Harm, and Assets Door Passenger Taxi Starts Unexpectedly Falls Out of Taxi Passenger Passenger Hits Head Moving Starts Opening (accident Lands On Guideway on Guideway (normal event) (hazardous event) trigger) (harm event) (harm event) Passenger is Passenger is Passenger is Dead Passenger is Okay Falling (abnormal Rolling and Injured (abnormal (normal condition) condition) (abnormal condition) condition) Taxi is Moving Taxi is Moving (normal condition) (abnormal condition when taxi door is open) Taxi Door Taxi Door is Open is Closed (abnormal condition when taxi is moving) (normal condition) Taxi Cabin Contains one Passenger Taxi Cabin is Empty (normal condition) (abnormal condition during habitat tour or passenger trip) Taxi Control Software (SW) is Defective (failure causes door to open inappropriately) (vulnerability) Passenger is in Moving Taxi with Passenger is Killed Open Door and Falling From Moving Taxi Defective SW (accident) (hazard) Time Engineering Safety- & Security-Related Requirements 139 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example Fault Tree Passenger falls out of open door of moving taxi Passenger inattentive and near taxi door Door opens on Train starts moving moving taxi with open door Warning is Taxi Taxi door is Door motor ineffective Taxi door fails to close starts to unlocked opens taxi door move A Taxi Taxi door lock Taxi Taxi door Taxi Taxi door Taxi motor Taxi fails computer motor fails computer motor fails computer fails computer unlocked fails open fails open fails on fails Taxi door Taxi door sensor fails lock sensor closed fails locked Engineering Safety- & Security-Related Requirements 140 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example Event Tree Taxi Door Taxi Taxi Taxi Speed Position Door Brakes Speaker Sensor Sensor Motor closes door Passenger is protected. detects issues open door stops warning taxi Passenger may fall out of stopped taxi. fails Passenger likely to fall out of stopped taxi. detects fails motion issues Passenger is warning fails Passenger may fall out of stopped taxi.near open dooron a moving taxi fails Passenger likely to fall out of stopped taxi. fails Passenger likely to fall out of stopped taxi. fails Passenger likely to fall out of stopped taxi. Engineering Safety- & Security-Related Requirements 141 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Example ZATS FMECA TableComponent Failure Failure Failure Failure Failure Criticality Safety that fail Mode Cause Effect Severity Likelihood (Risk) Controls Hardware No data, Bad Excessive redundancy, data (0, last Hardware failure, acceleration orAccelerometer High-reliability value, loss of electrical deceleration Minor Low Moderate(Taxi sensor) COTS maximum power, wiring fails causing passenger component, SW value) injury fault tolerance Taxi not controllable Hardware CPU, electrical (e.g., braking, redundancy, Loss of power (loss or power, steering), High-reliability Computer function spike), hard drive, collision between COTS Hardware (complete or Severe Moderate Critical motherboard, or taxis, collision with components, (Taxi) intermittent), RAM failure, guideway, temperature bad data high temperature unexpected or sensor, SW emergency braking fault tolerance SEAL 1 applied Loss of Taxi not controllable (e.g., SW fault function CPU, electrical (e.g., braking, tolerance, real- (complete or power (loss or power, steering), time operating Computer intermittent), spike), hard drive, collision between system, safe Software Severe High Critical incorrect motherboard, or taxis, collision with language (Taxi) function, bad RAM failure, guideway, subset, formal timing of high temperature unexpected or specification of function emergency braking core functions, etc.) Engineering Safety- & Security-Related Requirements 142 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Hazard Analysis (Safety) – A Relook1Safety and reliability are not the same: • Unreliable systems can be safe (failsafe systems – failures do not cause harm) • Reliable systems can be unsafe (poor requirements lead to accidents) Reliability-based safety analysis assumes: • Accidents are due to the independent failures of individual components • Defective components fail to meet their requirementsHowever, most accidents are due to: • Poor (missing, ambiguous, incomplete, or incorrect) requirements • Component interaction defects, whereby the individual components meet their requirements and are thus reliable • Software, that glues complex components together • Human causes of accidents beyond “user” errors: — Management and developer rather than operator (e.g., pilot) errors — Unavoidable human limitations, financial and schedule pressures, psychology, sociology, etc. Engineering Safety- & Security-Related Requirements 143 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Hazard Analysis (Safety) – A Relook2Modern Hazard Analysis: • Add requirements defects to component defects. • Add component interaction failures to individual component failures. • View safety and security as emergent system characteristics arising from the interaction among system components and the system’s environment rather than the characteristics of individual system components in isolation. • Emphasize software and humans over hardware.Danger Analysis: • Emphasize safe and secure interfaces. • View safety and security not as a reliability problem but rather as a problem of controlling dangers by enforcing safety- and security-related requirements. • Address indirect and systemic causes of accidents and successful attacks. Engineering Safety- & Security-Related Requirements 144 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Hazard - OverspeedPrimary Condition: • Taxi exceeds the speed limit.Existence of one or more Vulnerable Assets: • Guideways • One or more passengers • Passenger property • Taxis • Taxi stationsExistence of one or more system Vulnerabilities: • Defective speed sensor • Defective power braking system • Defective taxi processor • Defective associated softwareExistence of one or more Non-malicious Abusers: • None (taxi speed is automatically controlled by the taxi) Engineering Safety- & Security-Related Requirements 145 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Hazard Requirements -OverspeedOverspeed Requirements: • ZATS taxis shall not exceed the speed limit by more than one mile an hour more than 0.001 % of the time. • ZATS taxis shall not exceed the speed limit by more than five miles an hour more than 0.0001 % of the time. • ZATS taxis shall not exceed the speed limit by more than one mile an hour for durations longer than 10 seconds more than 0.0001 % of the time. Engineering Safety- & Security-Related Requirements 146 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Threat(Bank Card Confidentiality)Primary Condition: • Travel Card Vending Machine computer connected to Internet via Operations Facility ServerExistence of one or more Vulnerable Assets: • Passengers’ bank card informationExistence of one or more system Vulnerabilities: • Lack of encryption during transmission • Lack of encryption during storage • Weak encryption • Lack of firewalls or firewalls improperly configuredExistence of one or more Malicious Abusers: • Cyber-thief: — Means: Expertise plus relevant hacking tools — Motive: Greed — Opportunity: Computer access to the Internet Engineering Safety- & Security-Related Requirements 147 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Threat RequirementsThreat Requirements: • ZATS shall encrypt all passenger bank card information while stored within ZATS. • ZATS shall not store passenger bank card information in the travel card vending machines. • ZATS shall encrypt all passenger’s bank card information sent to the bank card processing gateway. Rationale: to make the bank card information unusable by cyberthieves if accessed. Engineering Safety- & Security-Related Requirements 148 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Dangers Entry/Edit Form Engineering Safety- & Security-Related Requirements 149 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Dangers Report Engineering Safety- & Security-Related Requirements 150 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Defensibility Risk Analysis Safety Team Security Team Requirements Team Safety and Risk collaborates Requirements Subject with Security Protection Matter Engineering Requirements Engineering Experts Standard / Reusable Risk Detection Defensibility Risk Requirements Requirements performs performs Preparation provide Risk ReactionStakeholders input Requirements during Risk Risk provide Identification Lists Requirements input Risk Development Analysis Risk Risk-Related during Risk Requirements Definition Modeling TablesGeneric / Reusable Requirements Risk Tables Validation Risk Goal Defensibility Safety Risk Identification Risk Goals Requirements Abuse Table perform support Abuse Trees Security Risk Requirements Subject Abuse Cases Safety Security Matter Team Team Experts Stakeholders Danger Profiles Safety and SecurityDanger Cause and CertificationEffects Diagrams Repositories Engineering Safety- & Security-Related Requirements 151 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Defensibility RisksRisk the expected or maximum credible amount of unauthorized harmTraditionally calculated as the product of the: • probability that harm will occur • the amount or severity of the harmDefensibility Risks the expected or maximum credible amount of unauthorized harm that can occur • To [a type of] defended assets • Due to a specific [type] of abuse • Due to the existence of [a type of] vulnerability, abuser, or danger Engineering Safety- & Security-Related Requirements 152 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Estimating Safety and Security RiskSafety Risk the expected or maximum credible amount of unintentional unauthorized harm • Probability accident occurs x harm severity • Probability hazard exists x conditional probability accident occurs given hazard exists x harm severitySecurity Risk the expected or maximum credible amount of intentional unauthorized harm • Probability attack occurs x conditional probability/rate attack is successful x harm severity • Probability threat exists x conditional probability attack occurs given threat exists x conditional probability attack is successful x harm severity Engineering Safety- & Security-Related Requirements 153 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • are due to DefensibilityDefensibility Risks can be estimated in Risks are estimated terms of in terms of Harm HarmExpected amount of harm are the Likelihoods Severities likelihoodsto defended assets of the can be estimated occurrences of in terms of DangersMaximum credible amount Danger Harm Event Conditionalof harm to defended Likelihoods Likelihoods increase theassets probability ofDetermining harm Hazard Threat Accident Successful Attack Likelihoods Likelihoods Likelihoodslikelihoods very difficult Likelihoodswith software are the conditional likelihoods given danger of occurrence of Abuses can cause categorize amount of Unauthorized Harm correspond to the “expected” amount of can happen to Defended Assets Engineering Safety- & Security-Related Requirements 154 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • The ZATS Safety Risk MatrixSafety risk matrix defines safety risk as a function of: • Harm severity • Frequency of harm occurrence, abuse occurrence or danger existence ZATS Safety/Security Risk Matrix Frequency of Harm / Abuse / Danger Harm Severity Frequent Probable Occasional Remote Implausible Catastrophic Intolerable Intolerable Intolerable High Medium Critical Intolerable Intolerable High Medium Medium Major High High Medium Medium Low Minor High Medium Low Negigible Negligible Negligible Medium Low Negligible Negligible Negligible Engineering Safety- & Security-Related Requirements 155 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Risks Entry/Edit Form Engineering Safety- & Security-Related Requirements 156 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Defensibility Risk Goals andRequirementsDefensibility Risk Goal • The risk of fires in ZATS buildings will be acceptable to zoo management and the Metropolitan Zoo Authority.Defensibility Risk Requirement • The risk of fires in ZATS buildings shall be less than or equal to the fire risk to other zoo buildings. Engineering Safety- & Security-Related Requirements 157 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Defensibility Significance Analysis Safety Team Security Team Requirements Team collaborates Subject with Matter Requirements Experts Engineering Preparation performs provide performs SAL input Category Stakeholders during Definition Requirements Requirements Identification provide SAL Repository input Significance Categorization during Analysis Requirements SEAL Analysis Safety and Security Category Goals Definition Standard Reusable SEAL Architecture Architecture Safety and Security Allocation Representations Verification Safety and Security Assurance Level (SAL) Certification Definitions Repositories perform produces Standard Reusable Safety and Security collaborate Evidence Assurance Subject in the Architecture Safety Security Level (SEAL) Definitions Matter performance Team Team Team Stakeholders Experts of Safety and Security Architecture Engineering Engineering Engineering Safety- & Security-Related Requirements 158 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Safety/Security Assurance Levels (SALs)Safety/Security Assurance Level (SAL) a category of requirements based on their defensibility (i.e., safety/security) relevance.SALs are used to categorize the safety/security relevance of thesubsystems to which they are allocated.SALs can be determined for: • Individual requirements. • Groups of related requirements (e.g., features or functions) SALs should be clearly and unambiguously defined. Engineering Safety- & Security-Related Requirements 159 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Five Ways to Categorize SALsThere are five ways to categorize defensibility relevance (in decreasingorder of goodness): 1. Risk – Increased risk increases SAL (best but labor intensive) 2. Harm severity – increased harm severity increases SAL (good but not quite as labor intensive as risk) 3. Ad hoc – intuitively assigned based on experience of requirements, safety, or security engineer (usually adequate and low labor) 4. Degree of software control – Increased degree of software control increases SAL (NOT recommended) 5. Degree of software control x harm severity – analogous to risk (NOT recommended) Engineering Safety- & Security-Related Requirements 160 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • SAL in terms of Software Degree of Control categorize SAL is a function is a function of of Defensibility Software Harm Requirements Degrees of Control Severity specify the is software’s control categorizes required amounts over occurrence of amount of of defensibility needed by the System Unauthorized Harm may occur to Valuable Assets Engineering Safety- & Security-Related Requirements 161 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Common Categories of Degrees of Software ControlAutonomous Time-Critical: Software completely controls time-critical potentially dangerous system behavior, whereby there is no time for a human user/operator to override the software and either eliminate the danger or prevent the abuse. For example, software failure can directly lead to the existence of the danger or the occurrence of the abuse.Autonomous Allowing Intervention: Software completely controls potentially dangerous system behavior, but there is sufficient time for either a safety/security system or a human user/operator to override the software and either eliminate the danger or prevent the abuse. The software warns the user/operator that immediate action is required.Information Generated: Software generates information that a human user/operator uses to make a decision with safety or security ramifications. Immediate user/operator action is not required.Autonomous Requiring Human Completion: Software primarily controls potentially dangerous system behavior, but a human user/operator must issue a command before the behavior is completed.No Defensibility Significance: Software either controls system behavior or provides information that has negligible safety or security significance. Adequate safeguards or countermeasures exist and have been successfully verified so that any residual safety or security risks are acceptable. Engineering Safety- & Security-Related Requirements 162 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • SAL Definition Table – Degrees of Software Control ZATS Safety/Security Assurance Level Harm Severity (SAL) Definition Table Catastrophic Major Minor Negligible Autonomous Time-Critical SAL = 3 SAL = 3 SAL = 2 SAL = 1SW ControlDegrees of Autonomous Allowing Human Intervention SAL = 3 SAL = 3 SAL = 2 SAL = 1 Defensibility Information Generated SAL = 3 SAL = 2 SAL = 1 SAL = 0 Autonomous Requiring Human Completion SAL = 2 SAL = 1 SAL = 1 SAL = 0 No Defensibility Significance SAL = 1 SAL = 0 SAL = 0 SAL = 0 Engineering Safety- & Security-Related Requirements 163 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • SEALsSafety/security evidence assurance level (SEAL) a category of architectural components based on the highest SAL of the allocated and derived requirements they implementSEALs categorize architectural components to which defensibility-relatedrequirements are allocated.SEALs define increasingly strict associated development methods neededto assure fulfillment of the highest associated SAL requirement.SEALs should be clearly and unambiguously defined. Engineering Safety- & Security-Related Requirements 164 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • SAL versus SEAL Categorized Categorized Architectural Requirements Components SAL = 0 Component 1 R1 SEAL = 0 SAL = {0} Requirements R3 R7 R1 Component 2 R11 SEAL = 1 R2 R13 SAL = {0,1} R3 R4 SAL = 1 Component 3 R5 R2 SEAL = 2 R6 R5 SAL = {0,1,2} R7 R12 R8 R15 Component 4 SEAL = 2 R9 SAL = {0,1,2} SAL = 2 R10 R4 R11 R6 Component 5 Refactored SEAL = 3 R12 R9 Architectural SAL = {1,2,3} Components R13 R10 R14 Component 7 R15 SAL = 3 SEAL 2 R14 SAL = {2} R16 Component 6 R16 SEAL = 4 R17 Component 8 R17 SAL = {2,3,4} R18 SEAL 3 R18 SAL = {2,3} SAL = 4 R8 Engineering Safety- & Security-Related Requirements 165 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Safety/Security Evidence Assurance Level (SEAL)High SEALs require more rigorous development method(including better requirements and architecture engineering): • Formal specification of requirements • Fagan inspections of requirements • Quality assessments of the architectureOften SEALs only apply to design, coding, and testing: • Design inspections • Formal derivation of code and proof of correctness • Model-Based Development (MBD) of software from models • Safe subset of programming language • Extra testing (test types and test completion criteria)Because of the added cost and schedule, architects often attempt tominimize the scope of components having high SEALs. Engineering Safety- & Security-Related Requirements 166 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Defensibility-Related Requirements (SAL = 1 - 5) 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 167 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Defense Determination collaborate with SMEs Safety and Security Requirements Safety Security Architecture Engineering Engineering Team Team Team Requirements Team Safety Defensibility Existing Subsystem / Laws and Defenses Function Regulations Analysis Existing Requirements Relevant Safety Defenses Table Security and Security Defense Subsystem / Policies performs Needs performs Function Analysis Requirements RequirementsEngineering Work Defense Products Defense Defensibility- Gap Analysis Goals Requirements Defense RelatedSafety & Security Development Determination Potential Requirements Assurance Defenses Potential Level (SAL) Table Defense Allocations Requirements Identification Safety Defense Validation Architecture Constraints Vendor Trade Engineering Potential Studies Work Products Defense Security Evaluation Defense support perform Constraints Safety andDefense Analysis Product Security Work Products Evaluation Certification Defense Subject Reports Repositories Selection Safety Security Matter Documentation Architecture Team Team Experts Stakeholders of Existing Authoritative Stakeholders Represen- Defenses Residual tations Catalogues of perform Risks Updated with Standard Acceptance Defenses Defenses Engineering Safety- & Security-Related Requirements 168 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Types of Defenses Safety Security Survivability Active Operational Defenses increase increase Defenses Passive Safeguards Countermeasures Technical Defenses Defenses Defenses (a.k.a., Controls) prevent or help to mandate the eliminate use of specific lessen the meet the or lower frequency of prevent or Defensibility-related Defensibility eliminate lessen the Requirements Constraints severity of Defensibility Abuses Risks Unauthorized Vulnerabilities Harm Engineering Safety- & Security-Related Requirements 169 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Defenses Entry/Edit Form Engineering Safety- & Security-Related Requirements 170 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • ESSR Tool – Defenses Report Engineering Safety- & Security-Related Requirements 171 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Safety ConstraintsEach ZATS taxi shall contain a taxi door subsystem consisting of twodoors, two door position sensors, two door locks, two door lock sensors,one door motor, and associated computer hardware and software.ZATS guideways shall be constructed from pre-stressed reinforcedconcrete that can support at least 150% of the maximum expected loading. Rationale: This constraint practically prevents the risk of guideway collapse due to credible excessive loading.The bottom of ZATS guideways shall be a minimum of 17 feet aboveground level. Rationale: Elevation of the guideways provides patrons with good visibility of the animals in their habitats, safely separates zoo patrons from the animals, eliminates the possibility of taxis running down patrons on zoo walkways, and eliminates the possibility of collision between taxis and patrons’ vehicles in the parking lots. The minimum height of the bottom of the guideway was also chosen to exceed the American Zoological Association (AZA) recommendation of 16 feet. Engineering Safety- & Security-Related Requirements 172 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Representative ZATS Security ConstraintsZATS shall use a COTS public key encryption/decryption product toprotect sensitive data. Rationale: Encryption and decryption is the most effective countermeasure for ensuring the confidentiality of sensitive data. Using a COTS product is best in terms of cost and schedule, and COTS products tend to use public key encryption.ZATS shall use of a COTS antivirus product to prevent server infection bymalware. Rationale: ZATS servers are threatened by the existence of software malware (e.g., viruses, worms, and Trojans). COTS antivirus products maintain current definitions of such malware and are of higher quality and much less expensive than developing and maintaining such a subsystem in-house. Engineering Safety- & Security-Related Requirements 173 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Where We AreRelated DisciplinesChallengesCommon ExampleFree, Open-Source ToolRequirements Engineering OverviewSafety and Security Engineering OverviewSafety- and Security-related RequirementsCollaborative Defensibility Engineering MethodConclusion ◄ Engineering Safety- & Security-Related Requirements 174 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Conclusion1Engineering safety- and security-related requirements requires appropriate: • Concepts • Methods • Techniques and tools • ExpertiseThere are four types of safety- and security-related requirements: • Safety and security quality requirements • Safety- and security-significant requirements • Safety and security function/subsystem requirements • Safety and security constraintsThese different types of requirements need to be identified, analyzed, andspecified differently. Engineering Safety- & Security-Related Requirements 175 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • Conclusion2Processes for requirements engineering, safety engineering, and securityengineering need to be: • Properly interwoven. • Consistent with each other. • Performed collaboratively and in parallel (i.e., overlapping in time). Engineering Safety- & Security-Related Requirements 176 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • RecommendationsEnsure close collaboration among safety, security, and requirementsteams.Better integrate safety and security methods: • Concepts and terminology • Techniques and work products • Provide cross trainingBetter integrate defensibility methods with requirements method: • Early during development cycle (build safety/security in) • Clearly define team responsibilities • Provide cross trainingDevelop all types of safety- and security-related requirements.Ensure that these requirements have the proper characteristics. Engineering Safety- & Security-Related Requirements 177 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • For More InformationThis tutorial is taken from Engineering Safety- and Security-relatedRequirements, which will be published in Summer 2011 by Auerbach.Donald Firesmith U.S. Mail:Senior Member of the Tech. Staff Software Engineering InstituteAcquisition Support Program Customer RelationsTelephone: +1 412-268-6874 4500 Fifth AvenueEmail: dgf@sei.cmu.edu Pittsburgh, PA 15213-2612 USAWorld Wide Web: Customer Relationswww.sei.cmu.edu Email: customer-relations@sei.cmu.eduwww.sei.cmu.edu/contact.html SEI Phone: +1 412-268-5800 SEI Fax: +1 412-268-6257 Engineering Safety- & Security-Related Requirements 178 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University
    • This work was created in the performance of Federal Government Contract NumberFA8721-05-C-0003 with Carnegie Mellon University for the operation of the SoftwareEngineering Institute, a federally funded research and development center. TheGovernment of the United States has a royalty-free government-purpose license to use,duplicate, or disclose the work, in whole or in part and in any manner, and to have orpermit others to do so, for government purposes pursuant to the copyright license underthe clause at 252.227-7013.This Presentation may be reproduced in its entirety, without modification, and freelydistributed in written or electronic form without requesting formal permission. Permissionis required for any other use. Requests for permission should be directed to the SoftwareEngineering Institute at permission@sei.cmu.edu.NO WARRANTYTHIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWAREENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIEMELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSEDOR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTYOF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTSOBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOESNOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROMPATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Engineering Safety- & Security-Related Requirements 179 Donald Firesmith, 18 June 2012 © 2012 Carnegie Mellon University