Early Life Cycle Risk Analysis: Planning for Software Assurance

Early Life Cycle Risk Analysis: Planning for Software Assurance Carol Woody, Ph.D. Software Engineering Institute 2014 Carnegie Mellon University

Copyright 2014 Carnegie Mellon University and IEEE This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL 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. This material has been approved for public release and unlimited distribution. This material 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 Institute at permission@sei.cmu.edu. DM-0001031 2

Agenda Introduction Mission Threads Evaluating Security Risks Summary 3

Software Assurance Mission success for software-reliant systems requires software assurance Software assurance: implementing software with a level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software, throughout the life cycle Section 933 of National Defense Appropriation Act 2013 Mission success requires the capability to engineer software assurance into the acquisition and development life cycle. 4

High Security Risk in Software-reliant Systems Security is not typically engineered into software-reliant systems Engineering focuses on cost, schedule, and functional requirements Security decisions can be delayed to later life-cycle activities Security controls are mandated (passwords, encryption, etc.) instead of security requirements Primary causes of operational security vulnerabilities: Design weaknesses Implementation/coding vulnerabilities System configuration errors Design weaknesses are not easily addressed during operations. 379 of the 940 common weakness enumerations (CWEs) are design weaknesses (http://cwe.mitre.org/) 19 of the top 25 are linked to design weaknesses(http://cwe.mitre.org/top25/) *http://cwe.mitre.org/top25/) 5

Example Design Weakness: Wireless Emergency Alerts (WEA) Spoofing Attack Threat An outside attacker with malicious intent gets a WEA certificate through social engineering and sends a WEA alert intended to incite panic in a crowd. Consequence Health, safety, legal, financial, and reputation consequences could result. Attack 1. Threat actor performs social engineering to get certificate. 2. Threat actor develops illegitimate wireless alert. 3. Threat actor sends illegitimate wireless alert to IPAWS-OPEN gateway. 4. IPAWS-OPEN gateway sends illegitimate wireless alert through WEA pipeline. 5. Recipients receive illegitimate wireless alert and take action. Mitigation: Confirm intent to send message with Alert Originator. 2014 Carnegie Mellon University 6

Primary Causes of Design Weaknesses Poor, incomplete, or non-existent security requirements Failure to consider security impacts beyond an individual system Failure to evaluate mission dependencies on multi-system interactions 7

Primarily Focused on Data Security (Information Assurance) Information Assurance Manage risks related to the use, processing, storage, and transmission of data. Enforce security policies; control and audit access. Protect data; encrypt communications and data stores. From TACP-M VCS TRD dated January 2008 8

Software Assurance Focuses on the Mission Success Mission Success requires acceptable software behavior over a spectrum of operational conditions, including attacker-created events. Software Assurance methods support this objective. From TACP-M VCS TRD dated January 2008 9

Current Practice for Early Life Cycle Security Risk Identification techniques are ad hoc Notation for expressing a security event/risk is incomplete Approaches rely on software engineers tacit knowledge of operational context and security risks Risk analysis is focused on a single system Single system scope Standalone (i.e., single system) models have been developed Risk analysis considers the exploit of an individual vulnerability within a single system Security risk identification techniques do not consider: Compositions of multiple vulnerabilities Cross-system security events/risks Impacts beyond the exploit of a single system (to the mission and organization) 2014 Carnegie Mellon University 10 10

Agenda Introduction Mission Threads Evaluating Security Risks Summary 11

Mission Threads Establish functioning as intended for the mission then look for ways things can go wrong and make sure mitigations are sufficient Analysis Framework Process 1. Identify a critical mission thread. 2. Define successful completion for the mission. 3. Describe critical steps required to complete the mission process (end to end) sequenced activities, participants, and technology. 4. Define ways that execution can be compromised at each critical step (execution failure, attack, etc.). 5. Evaluate the effectiveness of response and recovery. http://www.cert.org/sse/saf.html 12

Example: Mission Thread for WEA 13

Example: Mission Thread Steps for WEA AOS Step Alert Originating System (AOS) operator attempts to log on to the AOS. AOS logon activates auditing of the operator s session. AOS converts message to Common Alerting Protocol (CAP) compliant format. Supporting Technologies Server (valid accounts/authentication information) Logon application Communications between logon software/ server/aos Auditing application Communications from accounts to auditing application Local/remote storage devices Conversion application AOS transmits message to the IPAWS-OPEN Gateway. Application that securely connects to IPAWS- OPEN AOS and IPAWS-OPEN 14

Mission Step Failure Analysis People Involved Manual Intervention Coordination across multiple systems Previous Step Can the system adapt if not all expected conditions are met? Resources Mission Step Required Sources for failures Mission impact Recovery options Next Step Automatic 15

Identifying Threats using STRIDE Threat modeling tool used by Microsoft to help non-security experts consider security issues Threat Property we want Spoofing Authentication Tampering Integrity Repudiation Nonrepudiation Information Disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization http://msdn.microsoft.com/en-us/library/ee823878%28v=cs.20%29.aspx 16

Example: Security Analysis of Mission Step Step AOS operator attempts to log on to the alert origination system. Technology and People - One person - Server (valid accounts/ authentication information) - Logon procedure - Logon application - Username/password data in database - Communications between logon software/ server/aosp STRIDE Threat Identification Examples S: Unidentified individual attempts to logon with AOSP operator s information T: (none identified) R: AOSP operator denies having logged on I: Capture of logon info using key logger or packet sniffer D: AOSP operator s account not registered / servers are down E: Successful log on by an unidentified and unauthorized individual [1] S: Spoofing; T: Tampering with data; R: Repudiation; I: Information disclosure; D: Denial of service; E: Elevation of privilege. 17

Agenda Introduction Mission Threads Evaluating Security Risks Summary 18

Security Engineering Risk Analysis (SERA) Mission Threads 1. Establish operational context. Mission Thread Worksheet Risk Identification Worksheet 2. Identify risk. Risk Evaluation Criteria Risk Analysis Worksheet 3. Analyze risk. Control Approach Worksheet 4. Determine control approach. Control Plan Worksheet 5. Develop control plan. 19

Use Case Scenario Data Items involved Technology Security Controls/Relevant Step Actor and Action Standards and Regulations 1 AOS operator logs on to the AOS using account and authentication information [Note: operator log on and session auditing Authentication information AO Desktop Firewall Account information AOS Client User authentication (next step) are performed by team at start of shift] Procedures Server USB? 2 AOS logon activates auditing of the AOS operator s session Session log Session log software starting the session log. Backup of session log Server 3 AOS operator enters the approved alert message (text and Alert message optional audio/visual) including the relevant command alert, Command (which is incorporated cancel, or update message with status of actual 1 indicating into CAP-compliant message) this is an actual alert or command. [also includes the distribution channels via FEMA, of which wireless is the only relevant Alert scripts Procedures channel, and the actual geographic distribution for the alert] Session log data record of input and all the sources it went to (in addition to wireless) 4 AOS converts alert message to CAP-compliant format. Alert message (original format, AOS Database server text piece) AOS server Alert message in CAP-compliant format Backup or saved version of CAP-compliant message Session log data 5 AOS transmits alert message to the IPAWS-OPEN Gateway. Alert message (CAP-compliant format) Session log data IPAWS certificate 6 IPAWS-OPEN Gateway verifies 2 alert message using authentication information and logs the receipt of message in IPAWS Status message Alert message log. Authentication information Message validation scripts IPAWS log 7 AOS operator pulls the IPAWS receipt status from IPAWS log. IPAWS log/ipaws Receipt Status Procedures for checking IPAWS log 1 Other status values include test and system. Test will be addressed in an another use case. 2 In this table, message verification includes authenticating the message and ensuring that it is in the correct format. Multi-System Mission Security Risk Framework Threat Identification Models Consequence Analysis Models Use-Case View Data View Workflow View Stakeholder View Data Requirements Data Element Form Confidentiality Integrity Availability Initiator alert request Verbal or There are no restrictions on who can The data element must be correct and This data element must be available Electronic view this data element. (public data) complete. (high data integrity) when needed. (high availability) Alert message content Verbal, There are no restrictions on who can The data element must be correct and This data element must be available Electronic, or view this data element. (public data) complete. (high data integrity) when needed. (high availability) Physical CAP-compliant alert Electronic There are no restrictions on who can The data element must be correct and This data element must be available message view this data element. (public data) complete. (high data integrity) when needed. (high availability) IPAWS certificate Electronic Only authorized people can view this The data element must be correct and This data element must be available data element. (sensitive but complete. (high data integrity) when needed. (high availability) unclassified) IPAWS receipt status Electronic There are no restrictions on who can The data element must be correct and No availability requirement for this data view this data element. (public data) complete. (high data integrity) element. Commercial Federal Mobile Service Emergency Initiator (e.g., Recipients Alert Originator (AO) Providers Management First Responder) (CMSP) Agency (FEMA) Stakeholder View Stakeholder Mission Interest First responders Get content to the AOS operator within a required timeframe AOS operators Enter alert message into AOS in the required timeframe AO managers Maintain their organization s authority to operate, including applying for and maintaining certificate for their AOS FEMA Transmit alert messages to CMSP within a requires timeframe and maintain trust in WEA and the overall emergency alert system CMSP Get alert messages to their customers as rapidly as possible without adversely affecting customer satisfaction Recipients (residents of given area Indirectly provide funding to the AO funding source covered by WEA) Receive and act on wireless alert messages in the area where they reside Recipients (transient population Receive and act on wireless alert messages within the given area covered by the visiting an area) AO Providers and maintainers of AOS Maintain trust in the services provided and in the security of their equipment AO funding source (e.g., Provide funding to operate the WEA service government) AO community Promote the value of the WEA service. Share information related to the WE service (e.g., problems, lessons learned) Network View Threat Actor Motive Attack Outcome Consequences Workflow Consequences Stakeholder Consequences Attack Attack Library Type Action Potential Damage Candidate Mitigation Requirements External Attack An external attacker spoofs a legitimate user of the system and enters false information into the system. Incorrect information is processed by the Implement mechanisms to authenticate system. (Integrity) users. Physical View Action 1 Vulnerabilities Action 2 Vulnerabilities Action 3 Vulnerabilities Action 4 Vulnerabilities... Action N Vulnerabilities Communication The primary communication channel for the system fails (e.g., The system cannot transmit data to other Implement a backup communication Failure unavailable internet service provider). systems. (Availability) channel that is not redundant with the primary communication channel. Insider Attack An insider destroys important information on the system. Important information is deleted or Perform periodic backups of system data. destroyed. (Availability) Recover lost data from latest backup. Insider Attack An insider modifies or changes system information. Incorrect information is processed by the Perform periodic backups of system data. system. (Integrity) Recover lost data from latest backup. Insider Attack An insider enters false information into the system. Incorrect information is processed by the Perform periodic backups of system data. system. (Integrity) Recover lost data from latest backup. Eavesdropping An attacker installs a sniffer on the network (i.e., an application or System information is collected by the Implement encryption to protect network device that can read, monitor, and capture network data exchanges attacker. (Confidentiality) communication. and read network packets). Network communications occur in an unsecured or "cleartext" format, which allows an attacker who has gained access to data paths in the network to "listen in" or interpret (read) the traffic sent by the system. Repudiation An insider denies taking an action. --- Implement monitoring and logging [This action can be coupled with other mechanisms to keep track of users insider actions.] actions. Elevated An insider has been granted access to more information and --- Implement mechanisms to control access Privileges services than he or she needs. [This action can be coupled with other to information and services based on insider actions.] role. Use access control mechanisms to restrict aces to information and services based on role. Defined semantics for expressing a security event/risk Library of attack primitives to support threat identification Models to support threat identification Models to support consequence analysis 2014 Carnegie Mellon University 20 20

Security Risk Components Threat Consequence Enablers 21

Task 1: Mission Thread for WEA 22

Example: AOS Network Topology 23

Example: AO Computer Room Physical Layout AOS Clients AO Servers AO Desktop with AOS management capability AO Manager s Office Mobile AO capability Hotline with initiators. C M AO Operator Room Note: Keypad access is required for entry. AO Desktops Note: Door can be locked using physical key. AO Server Room Note: The door to the server room is open during business hours. A physical key is required for entry outside of business hours. AO System Administration Computer AO System Administrators Office 24

Task 2: Example Threat An outside attacker with malicious intent obtains a valid certificate and uses it to send an illegitimate CAP-compliant message that sends people to a dangerous location. Threat components : Actor a person with an outsider s knowledge of the organization Motive malicious intent Action the actor obtains a valid certificate and uses it to send an illegitimate CAP-compliant message that sends people to a dangerous location 25

Example: Enablers A valid certificate could be captured by an attacker. Certificates are sent to recipients in encrypted email. This email is replicated in many locations, including Computers of recipients Email servers Email server/recipient computer back-ups Off-site storage of backup tapes The attacker could compromise the Emergency Operations Center or vendor to gain access to the certificate (e.g., through social engineering). Limited control over the distribution and use of certificates could enable an attacker to obtain access to a certificate. Unencrypted certificates could be stored on recipient s systems. Management of certificates is performed manually. 26

Example: Threat Sequence 1. The threat actor performs reconnaissance to determine who to target for social engineering. 2A. The threat actor obtains an AOS certificate from an employee at the AO (through social engineering). The employee provides an electronic copy of the certificate to the threat actor. 2B. The threat actor finds information about constructing CAP-compliant messages from public documents. 3. The threat actor creates an illegitimate CAP-compliant message intended to incite panic in a crowd that a bomb is about to explode in their location (e.g., an alert message of a bomb in Times Square on New Year s Eve). 4. The threat actor sends the illegitimate CAP-compliant message and certificate to the IPAWS-OPEN gateway. 27

Example: Workflow Consequences Threat An outside attacker with malicious intent gets a WEA certificate through social engineering and sends a WEA alert intended to incite panic in a crowd. IPAWS-OPEN processes the alerts and forwards it to commercial mobile service providers Commercial mobile service providers distribute the message to people s smart phones. People receive and read the illegitimate alert on their smart phones. 28

Example: Stakeholder Consequences Recipients Some people will ignore the message and take no action. Some people will believe the message, panic, and decide to leave the area. People could be put in harm s way leading to injuries and death. Alert Originators Alert originators could be held liable for damages. The reputations of alert originators could be damaged. FEMA The reputation of WEA could be damaged. Alert originators could decide not to use WEA Commercial Mobile Service Providers (CMSP) The reputation of service providers could be damaged. Alert Originators/FEMA/Commercial Mobile Service Providers Future attacks could become more likely (i.e., copy-cat attacks). 29

Example: Mitigation Option Threat An outside attacker with malicious intent gets a WEA certificate through social engineering and sends a WEA alert intended to incite panic in a crowd. Mitigation Confirm intent to send message with Alert Originator. IPAWS-OPEN processes the alerts and forwards it to commercial mobile service providers Commercial mobile service providers distribute the message to people s smart phones. People receive and read the illegitimate alert on their smart phones. 30

Security Engineering Risk Analysis (SERA) 1. Establish operational context. Mission Thread Worksheet Risk Identification Worksheet 2. Identify risk. Risk Evaluation Criteria Risk Analysis Worksheet 3. Analyze risk. Control Approach Worksheet 4. Determine control approach. Control Plan Worksheet 5. Develop control plan. 31

Task 3: Analyze Risk Each risk is analyzed in relation to predefined criteria. Sub-tasks: Establish probability. Establish impact. Determine risk exposure. 32

Probability Criteria Value Definition Context/Guidelines/Examples Frequent (5) Likely (4) Occasional (3) Remote (2) Rare (1) The scenario occurs on numerous occasions or in quick succession. It tends to occur quite often or at close intervals. The scenario occurs on multiple occasions. It tends to occur reasonably often, but not in quick succession or at close intervals. The scenario occurs from time to time. It tends to occur once in a while. The scenario can occur, but it is not likely to occur. It has "an outside chance" of occurring. The scenario infrequently occurs and is considered to be uncommon or unusual. It is not frequently experienced. one time per month ( 12 / year) ~ one time per 6 months (~ 2 / year) one time every 3 years (.33 / year) 33

Impact Criteria Value Maximum (5) High (4) Medium (3) Low (2) Minimal (1) Definition The impact on the organization is severe. Damages are extreme in nature. Mission failure has occurred. Stakeholders will lose confidence in the organization and its leadership. The organization either will not be able to recover from the situation, or recovery will require an extremely large investment of capital and resources. Either way, the future viability of the organization is in doubt. The impact on the organization is large. Significant problems and disruptions are experienced by the organization. As a result, the organization will not be able to achieve its current mission without a major re-planning effort. Stakeholders will lose some degree of confidence in the organization and its leadership. The organization will need to reach out to stakeholders aggressively to rebuild confidence. The organization should be able to recover from the situation in the long run. Recovery will require a significant investment of organizational capital and resources. The impact on the organization is moderate. Several problems and disruptions are experienced by the organization. As a result, the organization will not be able to achieve its current mission without some adjustments to its plans. The organization will need to work with stakeholders to ensure their continued support. Over time, the organization will be able to recover from the situation. Recovery will require a moderate investment of organizational capital and resources. The impact on the organization is relatively small, but noticeable. Minor problems and disruptions are experienced by the organization. The organization will be able to recover from the situation and meet its mission. Recovery will require a small investment of organizational capital and resources. The impact on the organization is negligible. Any damages can be accepted by the organization without affecting operations or the mission being pursued. No stakeholders will be affected. Any costs incurred by the organization will be incidental. 34

35 Risk Exposure Matrix Risk Exposure Matrix Probability Rare (1) Remote (2) Occasional (3) Probable (4) Frequent (5) Impact Maximum (5) Medium (3) Medium (3) High (4) Maximum (5) Maximum (5) High (4) Low (2) Low (2) Medium (3) High (4) Maximum (5) Medium (3) Minimal (1) Low (2) Low (2) Medium (3) High (4) Low (2) Minimal (1) Minimal (1) Minimal (1) Low (2) Medium (3) Minimal (1) Minimal (1) Minimal (1) Minimal (1) Minimal (1) Low (2)

Task 4: Determine Control Approach A strategy for controlling each risk is determined based on Predefined criteria Current constraints (e.g., resources and funding available for control activities) Control approaches for security risks include: Accept If a risk occurs, its consequences will be tolerated. Transfer A risk is shifted to another party (e.g., through insurance or outsourcing). Avoid Activities are restructured to eliminate the possibility of a risk occurring. Mitigate Actions are implemented in an attempt to reduce or contain a risk. Sub-tasks: Prioritize risks. Select control approach. 36

Example: Risk Spreadsheet with Control Approach ID Risk Statement Impact Prob Risk Exp Control Approach 1 If an outside attacker with malicious intent obtains a valid certificate and uses it to send an illegitimate CAP-compliant message that directs people to a dangerous location, then health, safety, legal, financial, and reputation consequences could result. High-Max Rare Low-Med Mitigate 3 If an insider with malicious intent spoofs the identity of a colleague and sends an illegitimate CAP-compliant message, then individual and organizational reputation consequences could result. Med Rare- Remote Min-Low Mitigate 2. If malicious code prevents an operator from entering an alert into the Alert Originating System (AOS), then health, safety, legal, financial, and productivity consequences could result. 4 If the internet communication channel for the AOS is unavailable due to a cybersecurity attack on the internet service provider, then health and safety consequences could result. Low-Med Remote Min-Low Mitigate Low-Med Remote Min-Low Mitigate 37

Task 5: Develop Control Plan A control plan is defined and documented for all security risks that are not accepted (i.e., risks that will be mitigated, transferred, or avoided). Sub-tasks: Review data. Establish control requirements. 38

Establish Control Requirements Transfer: What can be done to transfer the risk? How can the risk be shifted to another party? How will you know that the transfer works? Will you be adversely affected if the other party ignores the transfer? Avoid: What can be done to avoid the risk? How can activities be restructured [or requirements altered] to eliminate the possibility of the risk occurring? Mitigate: What can be done to mitigate the risk? Which actions can be implemented to reduce or contain the risk? Monitor and Respond Protect/Resist Recover 39

Agenda Introduction Mission Threads Evaluating Security Risks Summary 40

SERA: Key Points Provides decision makers with the information they need when they need it in a usable form Assesses operational security risks early in the software life cycle. Requirements Architecture Design Applies structured, systematic risk analysis to handle the complex nature of security risk identify and address design weaknesses early in the life cycle 41

Summary Mission Threads value: Provides a connection between technology and mission Provides visibility for mission dependencies on actions across systems and components that are independently designed and developed to optimize local needs Supports failure identification and mission impact analysis of interacting systems and components Security Risk Analysis Identifies gaps in system requirements through the evaluation of potential mission failure and needed mitigations Provides a communication structure among system engineers, software engineers, stakeholders, and security experts Helps management understand the value in planning for security attacks Provides a structure for evaluating various mitigation options (recognize, resist, recover) 42

Publications and Resources Cyber Security Engineering (CSE) Team Web Page http://www.cert.org/cybersecurity-engineering/ Woody, C., Mission Thread Security Analysis: A Tool for Systems Engineers to Characterize Operational Security Behavior, INCOSE/INSIGHT, July 2013, Vol. 16, Issue 2 Ellison, R. & Woody, C., Survivability Analysis Framework, CMU/SEI-2010-TN-013. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2010. Alberts, Christopher & Dorofee, Audrey. Mission Risk Diagnostic (MRD) Method Description (CMU/SEI-2012-TN-005). Software Engineering Institute, Carnegie Mellon University, 2012. http://www.sei.cmu.edu/reports/12tn005.pdf 43

Contact Information Carol Woody (412) 268-9137 cwoody@cert.org Web Resources (CERT/SEI) http://www.cert.org/ http://www.sei.cmu.edu/ 44

Acronyms AO Alert Originator AOS Alert Originating System AOSP Alert Originator Service Provider CAP Common Alerting Protocol (emergency alert message format) CMAC Cipher based MAC used for block cypher-based message authentication protocols CMSP Commercial Mobile Service Provider FEMA Federal Emergency Management Agency IPAWS-OPEN Gateway for Federal emergency alert input SERA Security Engineering Risk Analysis STRIDE Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege Threat Model WEA Wireless Emergency Alerts 45