Why do you need to prioritize risk?
Risk prioritization is important because it allows you to:
Distinguish between Critical, High, Medium, and Low risk-level vulnerabilities
Understand and own your organization's Cyber Security status
Manage and monitor the security posture of your organization by a unified cyber-risk regulation and exception policy that you determine
Prioritize your most-important remediation areas
Allocate your resources effectively and efficiently to remediate vulnerabilities
Bring your business context into the Vulcan Platform
Organizations aren’t all the same regarding vulnerabilities management - your business context impacts the risk calculation and determines the remediation prioritization.
There is no one single go-to risk prioritization or calculation that plays out well for all organizations. We at Vulcan acknowledge the significance of customized vulnerability management that targets the security needs of your particular organization.
The vulnerabilities-assets relationship is correlated, consolidated, and contextualized to impact priority.
Let's assume there is a critical vulnerability on one of your low-priority/test assets. The same exact vulnerability also exists on one of your top-priority production assets. Which vulnerability instance would you remediate first? and how you would map out and categorize all this data when you have hundreds or thousands of assets and vulnerability instances? This is why we’ve built a systematic methodology to align the risks with your specific organizational environment. Vulcan Cyber offers customization capabilities that let you bring your business context into the Vulcan Platform.
In other words, the Vulcan Platform correlates between vulnerabilities, assets, and SPR to produce a customized risk calculation so you can prioritize risks and remediation resources.
The Asset-Vulnerability-SPR-SLA correlation
The Vulcan Platform offers a whole set of features that aim to help you attach Business Context to an Asset. We urge you to utilize the capabilities of Tagging (Asset tags), creating Business Groups, configuring Risk Weights, determining SLA per Business Group and risk level, and more, to fully optimize and utilize the Vulcan Platform.
To fully utilize the business-context capabilities, there are 4 important main factors to retrieve, understand and define: Vulnerability data, Asset Data, SPR, and SLA. Once all is set in the Vulcan Platform, the risk calculation becomes customized to reflect the cyber security needs of your organization and business context.
Let's see what each factor brings to the table and how you can bring your business context into the configuration:
Vulnerability data is retrieved from the connectors and is cataloged into the following components: Vulnerability with/without CVE, Severity/CVSS, Threat tags, and Threat Intelligence. The data is merged in the Vulcan Platform through a process of consolidation and aggregation. Each component has a default risk-affecting weight set by the Vulcan Platform.
Modify the default risk weight of each component to affect the final risk score of a vulnerability.
Asset Data (and impact)
On top of the retrieved asset data from the connectors, the Vulcan Platform lets you attach Business Context to assets. Organizational business context is applied through Asset tags and Business Groups.
Asset tags and their impact are partially retrieved from the connectors and can be manually defined and created.
Create Business Groups and define their impact.
SPR threshold is the percentage of scanned assets complying with a defined threshold for maximum risk. When you define your SPR, you basically define when assets are considered compliant vs. non-compliant.
The SLA (Service Level Agreement) policy lets you set standards of vulnerability remediation times for your team. They're like a target, or a deadline, within which your team is expected to respond and resolve vulnerabilities.
So what happens when the 4 factors above are properly retrieved and defined? Prioritizing remediation becomes strongly associated with the assets in the organization, the defined SPR, the purpose they serve (Production, Internal vs. External, DevOps, etc.), and the teams they serve (AKA Business Groups).