Software Architectural Risk Analysis (SARA) Frédéric Painchaud Robustness and Software Analysis Group

Transcription

1 Software Architectural Risk Analysis (SARA) Frédéric Painchaud Robustness and Software Analysis Group Defence Research and Development Canada Recherche et développement pour la défense Canada Canada

2 Agenda Introduction Break Architectural Risk Analysis Break Risk Mitigation Continual Evaluation and Assessment Conclusion PAGE 2

3 Introduction Risk? The net negative impact of the exercise of a vulnerability, considering both the probability and the impact of occurrence. A function of the likelihood of a given threat-source s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. Risk Management? The process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level. Gary Stoneburner, Alice Goguen and Alexis Feringa, Risk Management Guide for Information Technology Systems, NIST, Special Publication PAGE 3

4 Introduction The three processes of Risk Management: Risk assessment (aka Risk analysis) Risk mitigation Evaluation and assessment Why? To forecast potential problems; Risk assessment Evaluation and assessment To develop and implement appropriate controls to avoid identified problems; To plan the actions to be taken if the controls go wrong, if uncontrolled identified problems arise (residual risk) and if unforeseen problems happen. Risk mitigation PAGE 4

5 Introduction Architectural Risk Analysis (ARA)? An adaptation of general Risk Assessment (Analysis), the first step of Risk Management. ARA and Risk Management in general are more an art than a science. Their processes are defined but practice and experience tailor them to the particular organization. PAGE 5

6 Introduction Going back to Risk Management, for IT systems, it must be integrated into the Software Development Life Cycle (SDLC) to be effective. The risk management methodology is (roughly) the same regardless of the SDLC phase for which the assessment is being conducted. PAGE 6

7 Introduction Phase 1: Initiation SDLC Phases Phase 2: Development or acquisition Phase 3: Implementation (in the environment) Phase 4: Operation and maintenance Phase 5: Disposal Support from Risk Management activities System risk identification System requirements incl. security System CONOPS Architecture design Coding practices e.g., security (CERT C, ISO C) Testing e.g., security testing Validation w.r.t. the requirements and operational environment Continual evaluation and assessment Proper disposal and system migration PAGE 7

8 Introduction Participation in the risk management process is the business of many key players in organizations, including senior managers, business operations and IT procurement managers, IT security program managers and computer security officers, IT administrators and trainers. PAGE 8

9 Break PAGE 9

10 Architectural Risk Analysis Architectural Architecture Risk documentation Analysis Step 1. System characterization One-page overview Step 2. Threat identification History of system attacks Sources of intelligence Step 3. Vulnerability identification Security testing results Step 4. Control analysis Planned controls Step 6. Impact analysis Threat statement Vulnerability statement List of controls Step 5. Attack likelihood determination Attack likelihood rating Impact rating Step 7. Risk determination Rated risks One-page overview Step 8. Control recommendations Step 9. Results documentation Recommended controls or modifications Architectural Risk Analysis Report PAGE 10

11 Step 1. System Characterization Architecture documentation Mostly design diagrams Questionnaires, on-site interviews, tools, Step 1. System characterization Update or create design diagrams (validate against operational system) Merge the views and abstract the design levels to produce a one-page overview (ambiguity analysis can help) One-page overview The basis for the entire architectural risk analysis PAGE 11

12 Software Architecture Recovery Tools When your architectural documentation is incomplete, outof-date or inexistent and when you have the source code, there are robust tools available to help. Refer to Philippe Charland s presentation. PAGE 12

13 Software Architecture Recovery Tools These tools are useful when you have the source code. When you only have the binary, there are currently two choices: 1. you use decompilers to generate source code of varying quality from the binary and then you use these tools or 2. you manually analyze the binary with the help of specialized tools to accelerate the process. These tools are useful to accomplish step 1 of the Architectural Risk Analysis process. When it comes to managing the whole process, a solution like KDM Workbench (seen during the tutorial) is more appropriate. PAGE 13

14 Step 2. Threat Identification One-page overview History of system attacks Sources of intelligence OPS, ASIC, Darknets/Blacknets, CAPEC, Security design patterns, STRIDE, SANS Top Cyber Security Risks, Step 2. Threat identification Misuse and abuse cases (add the time you take for use cases) Attack resistance analysis Distributed architectures, dynamic code generation and interpretation, APIs across stateless protocols, rich internet applications, service-oriented architectures, Threat statement Identifies threats, their level of motivation, their capacities and their likelihood OPS: Operations ASIC: All-Source Intelligence Centre CAPEC: Common Attack Pattern Enumeration and Classification, STRIDE: Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege, PAGE 14

15 PAGE 15

16 Step 3. Vulnerability Identification One-page overview History of system attacks Sources of intelligence OPS, ASIC, Darknets/Blacknets, seven pernicious kingdoms, 19 deadly sins, OWASP Top 10, CWE, Open Source vulnerability database, CVE, questionnaires, on-site interviews, tools, Security testing results Assess evidences that controls are working properly Step 3. Vulnerability identification Underlying framework weakness analysis System s dependencies Ambiguity analysis (in requirements and design) Trust modeling (security zones) Data sensitivity modeling (privacy and integrity) Vulnerability statement Identifies vulnerabilities and their exploitability Seven pernicious kingdoms: Brian Chess and Gary McGraw s taxonomy, 19 deadly sins: Michael Howard s list, OWASP: Open Web Application Security Project, CWE: Common Weakness Enumeration, CVE: Common Vulnerabilities and Exposures, PAGE 16

17 PAGE 17

18 Step 4. Control Analysis One-page overview Planned controls Must be considered for future assessments Security testing results Assess evidences that controls are working properly Step 4. Control analysis Controls are technical or non-technical Controls are preventive or detective Ambiguity analysis (in requirements and design) Trust modeling (security zones) Data sensitivity modeling (privacy and integrity) List of controls Identifies current and future controls and their effectiveness PAGE 18

19 Step 5. Attack Likelihood Determination Threat statement Vulnerability statement List of controls Step 5. Attack likelihood determination No black magic: a function of threat and vulnerability likelihood, the latter being dependent on controls Ambiguity analysis (in requirements and design) Threat modeling (attack surface) Attack likelihood rating Identifies the likelihood of threats exercising vulnerabilities, that is, the likelihood of attack scenarios PAGE 19

20 Step 5. Attack Likelihood Determination Vulnerability likelihood Threat likelihood High Medium Low High High High Medium Medium High Medium Low Low Medium Low Low

21 Step 6. Impact Analysis One-page overview Step 6. Impact analysis Needs key players: senior management, business operations managers and IT security program managers Interviews Impacts can be measured quantitatively or qualitatively Examples: lost revenue, maintenance cost, loss of public confidence, Impact rating Identifies the magnitude of impacts PAGE 21

22 Step 7. Risk Determination Attack likelihood rating Impact rating Step 7. Risk determination Again, no black magic: a function of attack likelihood and impact Associates attacks with impacts Rated risks Identifies the risks with their associated levels PAGE 22

23 Step 7. Risk Determination Impact Attack likelihood High Medium Low High High High Medium Medium High Medium Low Low Medium Low Low

24 Step 8. Control Recommendations Rated risks Step 8. Control recommendations Risks prioritization (cost-benefit analysis) For each risk, recommend one or more new controls or system modifications that will eliminate or mitigate that risk and are appropriate to the organization s operations Recommended controls or modifications PAGE 24

25 Step 9. Results Documentation One-page overview Threat statement Rated risks Recommended controls or modifications Step 9. Results documentation A report that describes the architecture, the identified threats, the risks with their associated levels, exploited vulnerabilities and impacts, and the final recommendations on controls and modifications to implement Architectural Risk Analysis Report PAGE 25

26 Architectural Risk Analysis and Risk Management in Practice Cigital s ARA Methodology (seen during the tutorial and mapped on the processes presented here) Microsoft s STRIDE Threat Model (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege) Security Risk Management Guide Sun s Adaptive Countermeasure Selection Mechanism/Security Adequacy Review (ACSM/SAR) Discussed in Secure Coding: Principles and Practices, Mark G. Graff & Kenneth R. van Wyk, 2003, ISBN PAGE 26

27 Architectural Risk Analysis and Risk Management in Practice Department of Homeland Security Build Security In website, NIST s Recommended Security Controls for Federal Information Systems and Organizations, Special Publication Rev. 3, August DRAFT Managing Risk from Information Systems: An Organizational Perspective, Special Publication , April DRAFT Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach, Special Publication Rev. 1, November Risk Management Guide for Information Technology Systems, Special Publication , July PAGE 27

28 Architectural Risk Analysis and Risk Management in Practice SEI s Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) ISACA s Control Objectives for Information and Related Technology (COBIT) splay.cfm&tplid=55&contentid=7981 SEI: Software Engineering Institute ISACA: Information Systems Audit and Control Association PAGE 28

29 Break PAGE 29

30 Risk Mitigation A few options: Acknowledgment and research: acknowledge threats and vulnerabilities and research for controls to lower risk Risk limitation: lower or minimize risk by implementing controls Risk planning: prioritize (cost-benefit analysis, operational impact and feasibility), implement and maintain controls and plan for residual risk Risk avoidance: eliminate risk cause and/or consequence, if possible Risk transference: transfer risk to other party, e.g., purchase insurance Risk assumption: accept the potential risk (if at an acceptable level) PAGE 30

31 Continual Evaluation and Assessment Do not forget: Threats and the system change over time: risk management is ongoing and evolving! Plan for re-evaluation and re-assessment! PAGE 31

32 Conclusion Keys for success in ARA: Senior management s commitment Full support and participation of the IT team Competence of the risk analysis team: Architectural risk analysis process Threats and vulnerabilities (the attacker s perspective) System and controls (the defender s perspective) Support of the user community: Participation in risk analysis Compliance to controls Ongoing evaluation and assessment PAGE 32

33 PAGE 33