1. Risk Analysis in Software Design Author: Verdon, D. and McGraw, G. Presenter: Chris Hundersmarck

2. 1.What is risk analysis and why do it? 2.Modern Risk analysis methodologies and themes, and an example 3.Risk Analysis Limitations and how to overcome them. 4.A practical Solution to the problems inherent in Risk Analysis

3. The “Black Art”  Part fortune telling, part mathematics.  A business-level decision-support tool A way of gathering the requisite data to make a good judgment call based on knowledge about:  Vulnerabilities  Threats  Impacts  Probability

4. What’s the big deal?  Roughly 50% of security problems are the result of design flaws.

5. Risk-analysis methodologies  Commercial Microsoft’s STRIDE Sun’s ACSM/SAR Insight’s CRAMM Cigital’s SQM  Standards Based National Institute of Standards and Technology’s ASSET Software Engineering Institute’s OCTAVE

6. Knowledge Requirement  Design level analysis is knowledge intensive Microsoft’s STRIDE  Threat categories Cigital’s SQM  Attack patterns and exploit graphs  Design principles  Knowledge of frameworks and software components.

7. An example of how to calculate a “value” for risk.  Express risk as a financial loss  ALE = SLE x ARO SLE: single loss expectancy ARO: annualized rate of occurrence.  Example

8. Common Themes (which run through risk-analysis processes)  Continuous Process  Best not to be performed solely by design team.  Knowledge and Experience

9. Basic steps of a prototypical analysis  Learn as much as possible about the analysis target.  Discuss security issues.  Determine the probability of compromise  Perform impact analysis  Rank risks  Develop a mitigation strategy  Report findings

10. Limitations  Difficult to apply to modern software design  Do traditional risk-analysis techniques provide an easy guide of all potential vulnerabilities and threats?  Many applications today rely on protection at the transport layer only.

11. Overcoming limitations  A Large Knowledge Base and Experience is invaluable.  Start looking at software risk analysis on multiple levels: Component-by-component Tier-by-tier Environment-by-environment

12. A Practical Solution  Building up a consistent view of the target system at a high level. Appropriate level: whiteboard view of boxes and arrows. Code-level description of software is NOT sufficient for spotting design problems. See the forest, don’t get lost in the trees.

13.  We use high level design to consider: Each tier’s environment Component Vulnerabilities Business impact Probabilities Countermeasures High level design

15. Conclusions  Decomposition – a natural way to partition a system.  However, Composition is the tricky part.  Evolution

16. Reference  Denis Verdon and Gary McGraw, Risk Analysis in Software Design, IEEE Vol. 2 Issue 4, Jul-Aug 2004, pg. 79- 84.

17. ?’s/Comments