1. Discussing “Risk Analysis in Software Design” 1 FEB 2006 - Joe Combs

2. Risk Analysis Defined …a business-level decision-support tool: it’s a way of gathering the requisite data to make a good judgement call based on knowledge about vulnerabilities, threats, impacts and probability

3. Key Risk Analysis Concepts Asset - object to be protected Risk - probability an asset will suffer an event of a given negative impact Threat - danger source and malicious agent’s motivation Vulnerability - defect or weakness in procedure, design, implementation or internal control that can be exploited by an attacker

4. Key Risk Analysis Concepts Countermeasures - management, operational and technical controls that protect the system’s confidentiality, integrity and availability Impact - what happens if the risk is realized? Probability - likelihood an event will occur, usually expressed as a percentile

5. Calculating Risk Annualized Loss Expectancy = Single Loss Expectancy X Annualized Rate of Occurrence often just a ballpark figure but useful for making relative judgements other calculations get much more subjective - how do you quantify a soiled reputation?

6. Risk Analysis in the Lifecycle Continuous process, not a single stage Fits with requirements, design & testing 50% of security problems result from design flaws

7. Risk Analysis Activities 1. Learn as much as possible about the analysis target 2,3. Discuss security issues surrounding the software, determine the probability of compromise 4. Perform impact analysis, rank risks

8. Risk Analysis Activities 6,7. Report findings, leading the organization to make changes Note the feedback loop in the process, showing the iterative/ongoing nature of risk analysis

9. Required Knowledge Need to build up a consistent view of the system at a reasonably high level What impact does a methodology like Extreme Programming’s “the code is the design” viewpoint have on the limited reach of code-level analysis

10. Risk Analysis & Requirements SecureUML - role-based access control models security requirements for well-behaved applications in predictable environments

11. Risk Analysis & Requirements UMLsec - enables modeling of confidentiality, access control and other security related features

12. Risk Analysis & Requirements Abuse Cases - means of understanding how applications might respond to threats in a less controllable environment

13. Understanding Business Impact Broad categories: Regulatory Financial considerations Contractual obligations Categorize requirements as must have, should have, and nice but not necessary laws & regulations are always must haves unless you’re a goodfella careful analysis of potential impact & probability allows you to categorize financial and contractual obligations

14. Limitations The ALE calculation is an informed guess, not an all knowing Oracle Traditional risk-analysis techniques don’t cover all potential threats at a component/environment level Modern applications span multiple boundaries of trust

15. A Practical Approach Take a forest-level view of the system: don’t get lost in the trees Consider: threat in each tier’s env vulnerabilities within each component as well as dataflows business impact of such technical risks probability of risk being realized feasibility of countermeasures

16. An Example SSL might seem to offer protection between client and web server Need to prevent eavesdropping within and between these 2 tiers as well Might suggest alternate approaches like message level encryption

17. Conclusions Risk analysis focuses on assets, risks, threats, vulnerabilities, countermeasures, impact and probability Risk analysis applies to requirements, design and testing Requires analyst to gain an in-depth understanding of the system Take advantage of tools & techniques like SecureUML, UMLsec, and abuse cases

18. Conclusions Categorize requirements as must have, should have, nice to have regulatory issues are must haves financial and contractual obligations are where the analysis plays a key role System level view can help understand risks in a distributed application