Risk Management CSCE 489/689 (Software Security) Fall 2018 Philip Ritchey Department of Computer Science and Engineering SSBSI Chapter 2

If you remember nothing else… Security is Risk Management. A RMF is a philosophy for software security. Identify, Rank, and Track security risk over time The RMF is a Multilevel Loop. Iterate it at every level. Measurement is critical. Measure early, measure often. No such thing as 100% secure. There is only Try Harder. To manage risk is to try harder.

The Five Stages of Activity Understand the business context Identify the business and technical risks Synthesize and prioritize the risks, producing a ranked set Define the risk mitigation strategy Carry out the required fixes and validate they are correct Applied in a loop and at several levels (project, SDLC, artifact). The most important bits are: identify, prioritize (rank), validate (and track) Loop  iterate

Understand the Context Key Question: Who cares? And why, why, why, why, why? What kinds of software risks are most important? Web app  web security, binary protection What business goals are most important? Usually all to do with money Compliance: HIPAA, FERPA, PCI-DSS, etc. 4 steps to problem solving: Understand the problem Make a plan Execute the plan Review the results This is part of step 1: understand the problem

Threaten business goals Impacts typically financial and legal Identify Risks Business risks Threaten business goals Impacts typically financial and legal Technical risks “a situation that runs counter to the planned design or implementation of the system under consideration” Threaten requirements (functional goals, security goals) Impacts typically time & effort, quality, security Essential to link technical risks to business risks Remember: Who cares? 4 steps to problem solving: Understand the problem Make a plan Execute the plan Review the results This is part of step 1: understand the problem Identifying risks part of risk analysis / threat modeling. e.g. STRIDE for technical risks Document risks identified, e.g. in a database, spreadsheet, text file.

Any system of non-trivial size will have very many risks Rank Risks Any system of non-trivial size will have very many risks Every risk must be handled Avoid / Transfer / Mitigate / Accept Limited resources to handle risks Key question: what is the best allocation of resources in terms of risk mitigation activities? Prioritize risks with high index (impact * probability) Try to do something for every risk Do more for top priority, less for low priority 4 steps to problem solving: Understand the problem Make a plan Execute the plan Review the results This is part of step 2: make a plan Avoid: eliminate the risk by not doing the thing that introduces the risk. E.g. feature X requires Internet access (assume no other feature does). There’s a lot of risk from the Internet. So, don’t implement feature X. Transfer: Move the risk to be someone else’s responsibility (external to business). E.g. never roll your own crypto. Software vendors are loathe to let this happen to them (take on risk as the vendor), hence EULAs and “as is, no warranty” clauses. For software security to be meaningful, the developers must be accountable for their software. It’s a can of worms, but it’s one I think needs to be opened and dealt with so we can move forward. Mitigate: reduce the impact or probability (or both) of the risk. E.g. SQL injections are a high impact risk. Reduce the probability of a SQL injection by using prepared statements. Accept: any risk which is not avoided, transferred, or mitigated must be accepted. E.g. DDoS protection is expensive (Azure charge ~$3000 / month). If you can’t afford it, you have to accept the risk of a DDoS attack. Risk avoidance vs. Risk reduction (mitigation):https://www.investopedia.com/ask/answers/040315/what-difference-between-risk-avoidance-and-risk-reduction.asp “Risk acceptance is for 2%ers and t-sips” - Ritchey

Define Mitigation Strategy Problems are relatively easy to find compared to fixing them “easier to break something than to design something that can’t be broken” - Dan Geer Limited resources to mitigate risks Mitigation activities must take into account cost, time, likelihood of success, completeness, impact on other risks May be many ways to mitigate a risk, pick the one(s) that are most efficient and effective Must directly identify validation techniques to demonstrate that risks are properly mitigated If you can’t measure it, it doesn’t meaningfully exist 4 steps to problem solving: Understand the problem Make a plan Execute the plan Review the results This is part of step 2: make a plan Goal is to mitigate risks down to an acceptable level.

Validate and Track Risk Mitigation Apply the validations from the risk mitigation strategy a la Test-Driven Development Fix the problems identified Requirements, design, coding, QA tests Possibly refactor Apply the validations from the risk mitigation strategy again Verify that the risks are being mitigated Rinse and repeat Track progress in terms of completeness against the risk mitigation strategy E.g. number of unmitigated risks remaining, level of risk mitigation, new risks identified 4 steps to problem solving: Understand the problem Make a plan Execute the plan Review the results This is steps 3 and 4: execute the plan and review the results Some companies make Risk Management software Some people just use a spreadsheet Relevant xkcd: https://xkcd.com/1739/ Also this: 99 little bugs in the code 99 little bugs Take one down, patch it around 127 little bugs in the code

Measurement is critical “Measures and metrics matter. They are central to understanding strategic planning and progress.” https://www.credohighered.com/blog/2013/8/9/qualitative-metrics How secure is my software? Am I better off now than before? Am I making an impact? How much? How much risk do I have? How much can be avoided? transferred? Requires numerical data Measurements made early and often Examples: # of risks by {priority, type, impact}, risk mitigation by {priority, type, impact} as {#,% of total} That article is about qualitative metrics… which are important (read the article), but we need quantitative metrics. When you have numerical data, you can make dope plots. Give the project manager a plot. Project managers love plots.

Thanks and Gig ‘em! WHOOP!