Safety- and Security-Related Requirements for

Transcription

1 Engineering - and -Related for Software-Intensive t Systems Presented at SSTC 2010 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Donald Firesmith, Terry Roberts & Stephen Blanchette, Jr. 27 April 2010

2 Report Documentation Page Form Approved OMB No Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 27 APR REPORT TYPE 3. DATES COVERED to TITLE AND SUBTITLE Engineering - and -Related for Software-Intensive Systems 5a. CONTRACT NUMBER 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Carnegie Mellon University,Software Engineering Institute,Pittsburgh,PA, PERFORMING ORGANIZATION REPORT NUMBER 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR S ACRONYM(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 11. SPONSOR/MONITOR S REPORT NUMBER(S) 13. SUPPLEMENTARY NOTES Presented at the 22nd Systems and Software Technology Conference (SSTC), April 2010, Salt Lake City, UT. Sponsored in part by the USAF. U.S. Government or Federal Rights License 14. ABSTRACT 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT a. REPORT unclassified b. ABSTRACT unclassified c. THIS PAGE unclassified Same as Report (SAR) 18. NUMBER OF PAGES 48 19a. NAME OF RESPONSIBLE PERSON Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

3 This work was created in the performance of Federal Government Contract Number FA C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government 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 or permit others to do so, for government purposes pursuant to the copyright license under the clause at This Presentation may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering g Institute at permission@sei.cmu.edu. NO WARRANTY THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. 2

4 Contents Three Disciplines Challenges Fundamental Concepts - and -Related Collaboratively Conclusion 3

5 Three Disciplines:,, and Engineering 4

6 Three Related Disciplines Engineering the engineering g discipline within systems engineering g concerned with lowering the risk of unintentional unauthorized harm to valuable assets to a level that is acceptable to the system s stakeholders by preventing, detecting, and reacting to such harm, mishaps (i.e., accidents and incidents), hazards, vulnerabilities, and safety risks Engineering the engineering discipline within systems engineering concerned with lowering the risk of intentional unauthorized harm to valuable assets to a level that is acceptable to the system s stakeholders by preventing, detecting, and reacting to such harm, misuses (i.e., attacks and incidents), id threats, t vulnerabilities, and security risks Engineering g 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) 5

7 Challenges: Combining,, and Engineering 6

8 Challenges 1 engineering, safety engineering, and security engineering have different: Communities Disciplines with different training, books, journals, and conferences Professions with different job titles Fundamental underlying concepts and terminologies Tasks, techniques, and tools 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, etc.) 7

9 Challenges 2 Current separate methods for performing requirements, safety, and security engineering are inefficient and ineffective. Separation of requirements engineering, safety engineering, and security engineering: Causes poor safety- and security-related requirements that are often: Vague/unverifiable/unfeasible architectural and design constraints Capabilities or goals rather than requirements Inadequate and too late to drive architecture development and test planning Makes it unnecessarily difficult to achieve certification and accreditation for safe/secure operations 8

10 Challenges 3 Poor requirements are a primary cause of more than half of all project failures (defined in terms of): Major Cost Overruns Major Schedule Overruns Major Functionality not delivered Cancelled Projects Delivered Systems that are never used Poor requirements are a major root cause of many (or most) accidents involving i software-intensive t i systems. requirements often mandated (e.g., Industry Best Practices, Functions) Often, these are not derived into meaningful requirements at the engineering level 9

11 Challenges 4 Constant tension: How safe and secure is safe and secure enough? What is needed: 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 g With requirements engineering Better safety- and security-related requirements 10

12 Fundamental Concepts: A Foundation for Understanding 11

13 Quality Model Architectural Components System defines the meaning of the quality of a Quality Model defines the meaning of a specific type of quality of a Quality Characteristics Quality Attributes are measured along Quality Measurement Scales measure quality along Quality Measurement Methods are measured using Internal Quality Characteristics External Quality Characteristics 12

14 Quality Characteristics (External) Quality Characteristic Internal Quality Characteristic External Quality Characteristic Configurability Efficiency Functionality Interoperability Serviceability Compliance Dependability Environmental Habitability Operability Compatibility Usability Robustness Performance Soundness Availability Correctness Predictability Occupational Health Survivability Capacity Reliability Stability 13

15 1 the quality characteristic capturing the degree to which the system: Properly prevents, detects, reacts to, and adapts to: Unintended and unauthorized harm to valuable assets due to the occurrence of Abuses enabled by the existence of Dangers Has defensibility risks that are acceptably low to its stakeholders Valuable Assets may be people, organizations, property, services, or environments Harm may be direct or indirect, intentional or unintentional, authorized or unauthorized 14

16 2 and security aspects of defensibility are defined in a similar il manner by replacing: Abuse with either mishap (safety) or misuse (security) Danger with either hazard (safety) or threat (security) risks with safety risks and security risks 15

17 - and -Related 16

18 There s More Than One Type Too often, only a single type of requirements is considered when there are many types that need consideration: Special non-functional requirements: and security requirements are quality requirements - and security-significant requirements (functional, data, and interface) and security functions/subsystems requirements and security constraints: Architectural and design constraints Mandated defensibility controls (i.e., safeguards and countermeasures) Separation of safety/security/requirements engineering almost assures gaps in requirements gaps in requirements Gaps in Lead to Shortcomings in Delivered Systems 17

19 Four Types of -Related Constraints Constraints Constraints Functional Quality Data Interface Constraints Intolerable Risk SAL = 4 High Risk SAL = 3 Moderate Risk SAL = 2 - Significant SAL = Independent SAL = 0 System Primary Mission Supporting Function / Subsystem Low Risk SAL = 1 / Assurance Level (SAL) Function / Subsystem Function / Subsystem 18

20 Example - and -Related / Requirement When in mode V, the system shall limit the occurrence of accidental harm of type W to valuable assets of type X to an average rate of no more than Y asset value per Z time duration. When in mode X, the system shall detect misuses of type Y an average age of at least Z percent of the time. / Significant Requirement The system shall automatically ti transport t passengers between stations. ti The system shall enable users to update their personal information. / Function / Subsystem Requirement The system shall include a fire detection and suppression subsystem. The system shall support the encryption/decryption of sensitive data. / Constraint The system shall not contain any of the hazardous materials in Table X. The system shall use passwords for user authentication. 19

21 Collaboratively Engineering - & -Related e e 20

22 Stovepipes are Typical Team System Engineering Engineering System Team Stakeholder Stakeholder Asset Asset Abuse Abuser Work Products Work Products Abuse Abuser Vulnerability Vulnerability Danger Danger Risk Vague Need * Gap * Risk Significance Vague Need Significance Defense To Engineering Defense 21

23 A Better Way Ensure close collaboration among,, and Teams Better Integrate and Methods: Concepts and Terminology Techniques and Work Products Provide Cross Training Better Integrate t and Methods with Methods: Early during Development Cycle Clearly define Team Responsibilities Provide Cross Training Develop all types of - and -relatedrelated Ensure that these have appropriate Properties 22

24 An Overall Engineering Method Monitoring Abuse Investigation Program Planning Policy Development Compliance Assessment Certification & Accreditation 23

25 Reqts Engineering Reqts Engineering Team collaborates with Team System and Engineering Team Engineering Stakeholder Asset Abuse Abuser Work Products Identification - Related Vulnerability Validation Verification Danger perform perform Risk Stakeholders Subject Matter Experts Team Team Significance Defense 24

26 Conclusion 25

27 Summary Engineering safety- and security-related requirements requires appropriate Concepts / Methods / Techniques & Tools / Expertise These must come from the respective experts in: engineering (safety- and security-related requirements) engineering (analysis and safety goals) engineering (analysis and security goals) BUT, // Engineering need to be: Properly interwoven. Consistent with each other. Performed collaboratively and in parallel (i.e., overlapping in time). A collaborative process will advance and Engineering to 1 st class efforts Ultimately, collaboration will improve the safety and security aspects of delivered systems 26

28 Contact Information Donald Firesmith Senior Member of the Tech. Staff Acquisition Support Program Telephone: World Wide Web: edu U.S. mail: Software Engineering Institute Customer Relations 4500 Fifth Avenue Pittsburgh, PA USA Customer Relations SEI Phone: SEI Fax:

29 Backup 28

30 Quality Attributes Occurrence of Unauthorized Harm Occurrence of Abuse (Mishap, Misuse, or Incident) Existence of External Abuser Existence of Internal Vulnerability Existence of Danger (Hazard or Threat) Existence of Risk Problem Prevention Problem Detection Problem Reaction Problem Adaptation Harm Arrest Mitigation Recovery Counterattack () Robustness Occupational Health Problem Type Solution Type Attribute Attribute Attribute measures quality along a Survivability Quality Characteristic Quality Attribute is measured along a Quality Measurement Scale Quality Measurement Method Quality Model defines the meaning of the quality of a System 29

31 Unauthorized Harm to Valuable Assets Stakeholders have an interest in the must defend System value Unauthorized Harm may occur to Valuable Assets People Organizations Property Environment Services Human Beings Development Tangible Property Private Property Roles Played Owner Supplier Intangible Property Public Property User Commercial Property 30

32 Types of Harm Survivability e.g., caused to enemy forces by weapons systems Unintentional (Accidental) Harm Attacker-Caused (Malicious) Harm Authorized Harm Unauthorized Harm Valuable Assets may occur to Harm Direct Harm Indirect Harm Harm to People Harm to Organizations Harm to Property Harm to the Environment Harm to a Service Death Bankruptcy Destruction Destruction Corruption Injury Illness Kidnap Corruption (bribery or extortion) Hardship Lost Market Share Lost Profits Loss of Reputation Damage Corruption Theft Unauthorized Access Unauthorized Disclosure Damage Loss of Use Unauthorized Usage (Theft) Accidental Loss of Service Denial of Service (DOS) Repudiation of Transaction 31

33 Types of Abuses Abuses Events Mishaps () Misuses () Survivability Abuses Accidents Incidents Successful Civilian Attacks Incidents Military Attacks Survivability Incidents cause cause Unauthorized Harm Unsuccessful Attacks Probes 32

34 Types of Abusers System Developer System Maintainer Non-malicious Human Abuser System Operator User Non-malicious External System Arsonist Cracker Aspect of the Natural Environment Non-malicious Abuser () Disgruntled Employee Identity Thief Mugger Foreign Industrial Professional Government Spy Criminal Attacker creates and uses Malware Malicious Abuser () Rapist Software Malware Hardware Malware Malware System Terrorist Backdoor Spyware Trojan Worm Virus may include existence of Abuser is the ultimate cause of a Abuse Event System-External Condition System-Internal Condition are partially defined in terms of the existence of system-external Condition Danger may result in exploits Accident () Incident Attack () Incident Hazard () Threat () Vulnerability 33

35 Vulnerabilities Defenses Dangers eliminate or mitigate are partially defined in terms of the existence of system-internal Vulnerabilities exploit may cause Abusers typically cause Abuses may cause Nonmalicious Abusers Malicious Abusers desire Stakeholders have have an interest in the must meet Stakeholder Needs exist in the System must defend Unauthorized Harm may occur to define types of quality of the Quality Factors value Valuable Assets 34

36 Dangers Risks is the expected amount of are partially defined in terms of vulnerable are partially defined in terms of the existence of system-internal Vulnerabilities may cause or enable can be estimated using the probability of Dangers may enable the occurrence of Abuses are partially defined in terms of the existence of system-external Abusers typically cause Nonmalicious Abusers Malicious Abusers exploit Stakeholders have have an interest in the must meet exist in the System must defend may cause Unauthorized Harm may occur to define types of quality of the desire Quality Factors Stakeholder Needs value Valuable Assets 35

37 Risks is due to can be estimated in terms of Risk are estimated in terms of Dangers is the likelihood of the occurrence of Harm Likelihood can be estimated in terms of Harm Severity Danger Likelihood Harm Event Conditional Likelihood may result in Hazard Threat Accident Successful Likelihood Likelihood Likelihood Attack Likelihood Abuses is the conditional likelihood given danger of occurrence of may cause Unauthorized Harm categorizes amount of corresponds to the expected amount of may occur to Valuable Assets 36

38 Risk in terms of Software Degree of Control is due to Risk Dangers may result in Abuses can be estimated in terms of Software Degree of Control is software s control over occurrence of Harm Severity is estimated in terms of may cause Unauthorized Harm categorizes amount of corresponds to the expected amount of may occur to Valuable Assets 37

39 Types of Positive (shall) Business Facility Data Contractual (Stakeholder) Derived (Developer) Operational Maintenance Sustainment Training Retirement Negative (shall not) Process (Method) Quality Functional Software Hardware People Product Data Non-Functional Interface Entity Procedure Documentation System/ Subsystem Primary Mission Supporting Constraints Object Material Architecture Constraints Design Constraints t Implementation Constraints Integration Constraints Configuration Constraints 38

40 Types of -Related - Significant Function/Subsystem Constraints t - Significant Function/Subsystem Constraints - Significant Function/Subsystem Constraints System - Related -Related -Related 39

41 Systems and Engineering Engineering Vision Statement Team Team collaborates with Context Diagram Understand Goals ConOps Scenarios Team Use Cases System Models Specifications Understand Architecture Architecture Model Architecture Documentation Architecture Team 40

42 Asset Subject Matter Experts Stakeholders provide input during provide input during Project Documentation (RFP, Contract, ConOps) Generic / Reusable Asset Tables ZATS Asset Value and Harm Severity Categories Generic / Reusable Asset Value and Harm Tables Standard / Reusable Asset-Harm Goals Team Team collaborates with Asset Compliance Repository Preparation Asset Identification Asset to Stakeholder Mapping Asset Use Value Harm Team Support Standard d / Reusable Asset-Harm Asset Table Asset Stakeholder Table Asset Usage Table Asset Value and Harm Table Asset-Harm Goals Stakeholders Team Identification Validation Subject Matter Experts perform Team Team Engineering Asset-Harm Prevention Asset-Harm Detection Asset-Harm Reaction Asset-Harm Asset-Harm Asset-Harm and Engineering 41

43 Abuse (Misuse and Mishap) Subject Matter Experts Team Team collaborates with Stakeholders provide input during provide input during Project Documentation (RFP, Contract, ConOps) Asset Table Asset Value and Harm Table Generic / Reusable Abuse Type Lists Generic / Reusable Abuse Table Standard / Reusable Abuse Likelihood Categories Abuse Compliance Repository Preparation Abuse Identification Abuse Tree Abuse Case Abuse Goal Identification Team Support and Engineering Abuse Table Abuse Trees Abuse Cases Abuse Goals Stakeholders Team Identification Validation Subject Matter Experts perform Team Team Engineering Abuse Prevention Abuse Detection Abuse Reaction Abuse Abuse (Mishap) Abuse (Misuse) Generic / Reusable Abuse Goals 42

44 Vulnerability Architects, Designers, and Implementers Quality Engineers, Testers, and Maintainers Actual / Proposed System Architecture t Actual / Proposed System Design Actual / Proposed System Implementation Asset Value and Harm Table Failure Mode Effect Criticality (FMECA) Table provide input during provide input during Team collaborates with Vulnerability Compliance Repository Team Preparation Vulnerability Identification System Vulnerability Operational Vulnerability Vulnerability Goal Identification Team Support and Engineering Vulnerability Table Vulnerability Goals Architects, Designers, and Implementers Team Identification Validation Quality Engineers, Testers, and Maintainers Team Engineering Team Vulnerability Vulnerability Vulnerability Vulnerability Constraints Vulnerability Constraints Vulnerability Constraints 43

45 Abuser Subject Matter Experts Stakeholders provide input during provide input during Project Documentation (RFP, Contract, ConOps) Generic / Reusable Abuser Lists Generic / Reusable Abuser Profiles Generic / Reusable Abuser-Related Goals Team Team collaborates with Abuser Compliance Repository and Engineering Preparation Abuser Identification Abuser Profiling Abuser Occurrence Abuser Goal Development Team Support Standard / Reusable Abuser-Related Potential Abuser List Abuser Profiles Abuser Occurrence Table Abuser- Related Abuser- Related Goals Stakeholders Subject Matter Experts Team Identification Validation Team Team Abuser Protection Abuser Detection Abuser Reaction Abuser Abuser Engineering 44

46 Danger Team Team collaborates Subject Matter with Experts and Engineering Team Engineering Stakeholders System and Documentation Other System Documentation Non-System Documentation Generic / Reusable Danger Lists provide input during provide input during Danger Preparation Danger Identification Danger Profiling Danger Cause Danger Effects Danger Likelihood Cause Root Cause Common Cause Danger (Hazard & Threat) Profiles Danger (Hazard & Threat) Cause and Effects Diagrams Identification Validation Generic / Reusable Hazard and Threat Danger Hazard Threat Generic / Reusable Danger Profiles Generic / Reusable Danger Likelihoods Compliance Repository Danger Goal Identification Team Support Danger Goals Stakeholders Subject Matter Experts Team Team 45

47 Risk Subject Matter Experts Team Team collaborates with Asset Risk Table Team Engineering Standard / Reusable Risk Stakeholders Generic / Reusable Risk Tables provide input during provide input during Risk Preparation Risk Determination Harm Risk Table Abuse Risk Table Danger Risk Table Identification Risk Risk Risk Abuse Table Risk Goal Identification Risk Goals Validation Abuse Trees Abuse Cases Compliance Repository Team Support Danger Profiles Danger Cause and Effects Diagrams and Engineering Stakeholders Subject Matter Experts Team Team 46

48 Significance Subject Matter Experts Team Team collaborates with Engineering Team Stakeholders and Goals provide input during provide input during Significance SAL Categorization SEAL Definition Repository Identification Project-Specific and Assurance Level (SAL) Definitions Project-Specific and Evidence Assurance Level (SEAL) Definitions Compliance Repository and Architecture Engineering Engineering g SEAL Allocation collaborate in the performance of Architecture Representations produces Architecture Team Stakeholders Architecture Verification perform Subject Matter Experts Team Team 47

49 Defense Subject Matter Experts Stakeholders and Generic / Reusable Safeguard and Countermeasure Lists Standard Defense Functionality and Constraint and Risks provide input during provide input during Team Team collaborates with Defense Compliance Repository Defense Type Identification Defense Functionality Identification Market Research Defense Selection Defense Adequacy collaborate in the performance of Architecting and Engineering Architecture Team Countermeasure and Safeguard Type Lists List of Defense Functions / Subsystems Vendor Trade Studies Countermeasure and Safeguard Selection Reports Stakeholders Team Identification Validation Subject Matter Experts Team Team Function/ Subsystem Function/ Subsystem Defense Function / Subsystem Defense Constraints Constraints t Constraints Engineering 48