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

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.

3. 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

4. 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

5. 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.

6. 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):
“Risk acceptance is for 2%ers and t-sips” - Ritchey

7. 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.

8. 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:
Also this:
99 little bugs in the code
99 little bugs
Take one down, patch it around
127 little bugs in the code

9. Measurement is critical
“Measures and metrics matter. They are central to understanding strategic planning and progress.”
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.

10. Thanks and Gig ‘em!
WHOOP!