Key approaches for effective security risk management & prioritization
2020年10月27日
0 分で読めますThere’s no easy way of being 100% secure, and although you can become more secure, there definitely isn’t one way of getting there. “The safest thing is to do nothing” is a great cliche, but in the case of software security, this is almost never the case. Starting with the very first line of code we write, the line has been crossed—we have introduced security risk that needs to be managed.
“Risk management” is an umbrella term and incorporates a wide variety of different approaches. I’m a big believer in naming things—it’s easier to be effective when you have a clear way of explaining (and measuring) your goals. What we’ll do in this article is introduce some key approaches and, since we are big believers in actionability here at Snyk, also provide you with ways of implementing these approaches.
One note before we dive into the different approaches. Determining the security risk level for a vulnerability can only occur once ALL the different influencing factors have been considered—from severity to exploitability, vulnerability type, reachability, and other environmental and business factors. Calculating risk accurately without any false-positives is a huge challenge but in this article, we are assuming you are able to do so (and if not, yes, you can use Snyk!).
Approaches to security risk management
Approach A: risk-centricIn this approach, your key concern is risk. If the risk is high—the vulnerability needs to be fixed ASAP, no matter the effort. You are less bothered if the risk is low, even if the required effort is low.
Approach B: ROI-centricIt’s all about effectiveness—time is money! When deciding upon the action to take, the “effort-to-fix” ratio is your top consideration. Easy-to-fix medium-risk? Yes please! Very-hard-to-fix high-risk? Perhaps not right now. Maybe if we wait a bit, the vulnerability will be easier to fix.
Approach C: high-level trendIt’s less about the details for you, and more about the overall trend—the total attack surface. Let’s make sure the teams have fewer vulnerabilities as times go by. Whether they choose to fix three highs or four mediums this week, really doesn’t matter. As long as we’re fixing and reducing that attack surface. (Don’t take this to the extreme :) This doesn’t mean you need to fix all lows and ignore all criticals!)
Approach D: complianceSometimes, we just need to get things done. Compliance comes in many forms, from an annual security audit by a 3rd party, to a “badge” we want to show. This approach differs from Approach A by being more strict with certain properties. If in approach A you only care about critical risk, here you might get asked to fix all critical-severity vulnerabilities, even if you’ve triaged them and are sure they don’t pose a risk (because, for instance, they are not reachable in your context).
Which security risk management approach would you choose?
Say you have these two vulnerabilities, what would you fix and why?
Approach A: Fix the critical risk. Do whatever you want with the medium
Approach B: Fix the medium. Hope the critical becomes easier to fix soon. Eventually fix that too.
Approach C: Stop thinking so much and just fix one of them now and the other one later. It’s all about reducing the attack surface.
Approach D: Let me see how defines these two vulnerabilities. And what’s the required threshold there.
Would you use more than one approach, or just wondering which approach is “the right approach”?
There’s no wrong approach, but there are a variety of routes you can take to become more secure. As the Cheshire Cat in Alice in Wonderland says: “That depends a good deal on where you want to get to”.
If you are onboarding a new team, we’d suggest approach B–ROI centric, with a bias towards quick wins, quick value. It’s a good way to get developer buy-in and avoid asking anything too strenuous before they’re engaged.
If you’re dealing with a veteran under-staffed team working a time-critical task, perhaps approach A is better, as you want to make sure they keep their focus whilst still reducing the risk in priority order.
If you’re getting ready for your annual compliance audit, approach D is your friend—you probably know what’s coming and you may as well try and get ahead of it!
If you’re a CISO in a large company, perhaps you are mostly interested in approach C (but your AppSec team should perhaps use a different approach).
There’s value in each, just choose what suits you best, and let Snyk help you from there!
How Snyk helps with security risk management
In reality, no business we speak to is fixated on only one approach. Teams vary, depending on qualities such as experience, project type, and workload. And while the CISO and AppSec teams may share an approach, encouraging adoption across all teams consistently is a challenge in any company.
Snyk helps you and your teams to take vulnerabilities beyond theory—adding the context that allows for an accurate assessment of the risk in your project—this is critical when it comes to intelligent prioritization.
Here’s a whistle-stop tour of some of Snyk’s useful functionalities:
Got a service that’s not reachable externally? Give it an attribute of “internal” and use a Security Policy to recategorize the severity DDoS to low.
Snyk Exploit Maturity tells you whether an exploit exists—this can make a huge impact on the risk that it actually poses.
Snyk assesses the called code paths to work out whether you’re dealing with Reachable Vulnerabilities ? or not ?
These are just a few of the factors Snyk uses to help prioritization, and while each offers fantastic data, it’s intelligence you need. Snyk offers this in the form of the relatively new Snyk Priority Score. Using the above insights, as well as other factors such as the age of the vulnerability and the availability of a fix, Snyk provides a 0-1000 score where the higher the score, the higher the priority to fix that vulnerability. This allows you to apply security effort in an order that’s going to offer the most value in terms of risk reduction and provides enough insight into how the score was calculated to ensure it can be trusted.