Software Security Risk Management Philosophy
A philosophy for software security emphasizing Risk Management Framework (RMF) principles. Iterative process of Identify, Rank, and Track risks at multiple levels. Measurement and continuous improvement essential for effective risk mitigation strategies. Focus on understanding business context, identifying technical risks, prioritizing mitigation efforts, and linking technical risks to business impacts.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Risk Management CSCE 413/713 - Software Security Spring 2020 Philip Ritchey Department of Computer Science and Engineering CSCE 413/713 - Software Security 1
If you remember nothing else Security is Risk Management. A RMF is a philosophy for software security. Identify Identify, Rank Rank, and Track 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. Track security risk over time CSCE 413/713 - Software Security 2
The Five Stages of Activity Understand the business context Identify Identify the business and technical risks Synthesize and prioritize prioritize the risks, producing a ranked set Define the risk mitigation strategy Carry out the required fixes and verify & validate verify & validate they are correct Applied in a loop and at several levels (project, SDLC, artifact). CSCE 413/713 - Software Security 3
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, NIST, etc. CSCE 413/713 - Software Security 4
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? CSCE 413/713 - Software Security 5
Rank Risks Any system of non-trivial size will have very many risks Every risk must be handled Prevent / Mitigate / Transfer / 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 CSCE 413/713 - Software Security 6
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 CSCE 413/713 - Software Security 7
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 CSCE 413/713 - Software Security 8
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} CSCE 413/713 - Software Security 9
Thanks and Gig em! WHOOP! CSCE 413/713 - Software Security 10
