1 / 18

Discussing “Risk Analysis in Software Design”

Discussing “Risk Analysis in Software Design”. 1 FEB 2006 - Joe Combs. 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.

harry
Télécharger la présentation

Discussing “Risk Analysis in Software Design”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related