Our world is driven by software. Our phones, homes, cars, commerce, and communication all depend on it. The marvelous conveniences of our on-demand economy have also created large attack surfaces for our adversaries. An always-on connected-everywhere world doesn’t just put digital data at risk anymore. The cyber/physical boundaries are quickly disappearing. And if you subscribe to the theory that there is no safety without security (as I do) you’ll understand why we have a dire need to get serious about software security.
Leaders looking to decode cybersecurity need to understand which products, systems, and teams are putting their business at most risk so they can deploy appropriate action plans. Trying to do so without considering software risks is akin to driving a car blindfolded.
Business requirements and concerns come in many forms, all of which need to be considered: regulatory and compliance mandates, customer and legal obligations, 3rd-party services, supply chain dependencies, intellectual property protection, critical systems where safety may depend upon cyber/software security, and so on. The lack of systematic and adaptive risk management approaches to understand and measure software security risk and protect software systems poses major challenges to business around worldwide.
High-risk software systems require more security controls and more rigor – and organizations struggle with this calibration. The approach I recommend will assist in identifying and prioritizing the highest risk applications through risk analysis and threat modeling. This enables accurate assessment of software risks and leads to the development of a customized remediation roadmap that will help manage the business more effectively (security engineering activities, policies and procedures, tools, training, etc.). I call the approach SToRM, for Software Total Risk Management.
Conventional approaches to software security are not risk-based, typically encompassing no more than vulnerability scanning. This approach frequently fails to address each application’s unique code-, system-, business logic- and workflow-level vulnerabilities. More importantly, it provides little practical guidance on prioritizing threat remediation or creating a roadmap to guide enterprise software security posture improvements.
SToRM represents a new approach – one that enables enterprises to more accurately assess software risks, prioritize them correctly, and develop a customized remediation roadmap that will help manage the business more effectively. The value of understanding security risks is only realized when you can decide whether or not to dive deeper into specific problems and where to take appropriate risk mitigation actions.
- Asset Rating: This is a discovery phase wherein you document critical assets – consider it a portfolio analysis if you will. Prioritize business applications and rate them on a scale that makes sense to you (1 to 10, A to F, whatever – so long as there is a relative scale.) These ratings are likely to change after you complete the next step, but this gives you a fine starting point.
- SDLC Gap Analysis: For those systems built internally, this is a must. This can be as simple as a questionnaire whose results are compared against an acceptable standard, e.g., PCI Secure Software Lifecycle requirements published at pcisecuritystandards.org.
- Risk discovery and assessment: This entails the review of application or systems-level technical specifications in order to understand exactly how the technical system in question has been designed and deployed. Different modeling techniques can be used to ensure a 360-degree view. I prefer STRIDE however you may find PASTA or others listed here more to your liking.
- Application Re-ordering: When threat modeling is completed, it’s time to re-assess the risk ranking of your applications. I find it simplest to create 3 tiers of application: High, Medium, and Low risk. Define a set of criteria (data sensitivity, lifespan, compliance requirements, customer/internet-facing, etc.) and score each criteria, e.g., 0 (low risk) to 5 (high risk.) Each application’s score is the sum of its criteria scores and can be grouped into your 3 tiers accordingly. Note, this exercise is highly contextual to each organization.
- Security Test Calibration: You are now ready to construct a security testing framework. For each application tier, choose an appropriate test frequency and depth. The objective is to apply your limited staff and budget wisely.
There is no standard formula for Risk Assessment but this sets you on the path. The by-product associated with the SToRM activities above will ensure that product and security teams are equipped with the necessary framework to implement repeatable software security and development best practices.
