The bulk of today’s security programs are reactive. We focus on events. On alerts. The flashing screens. Hyped vulnerabilities stemming from news articles. We swat at mosquitos that have already bitten us after forgetting to apply bug spray. Focusing on proactive security behaviors will relieve the constant itch of intrusions that reactive teams must scratch.
A proactive approach is not controversial. But it is a misunderstood objective. Security programs have entire teams and programs dedicated to proactive approaches like posture management. But proactive teams, like vulnerability risk management, and reactive teams, like the SOC, remain overwhelmed.
The current wide array of proactive solutions adds to the confusion. Thanks to new acronyms and changing product definitions from vendors and other industry influencers (ahem), a security leader’s email inbox resembles more of a word search than an inbox. Trying to make sense of what solutions provide proactive or reactive solutions, or how or why it would even benefit your program is more difficult than ever.
If you’re wondering how or if a given security technology supports your proactive program, ask yourself these four questions:
- Does it give me visibility into what I have in my organization that needs to be protected? When we ask organizations if they think they properly inventory assets, they overwhelmingly think they do. But – when we ask more questions about details of the asset – we hear admittance that several don’t know the context of why some assets even exist in an environment. Even identifying who uses an asset, and who is responsible for remediating it, can be difficult. So inventorying assets like endpoints, cloud workloads, and code repos is just a starting point. Organizations also need to have visibility into important context surrounding the assets.
- Does it help me prioritize my remediations? There are several factors to consider for prioritizing remediations. Asset context is one of the most important albeit one of the most difficult to obtain. Security teams must also be aware of threats most likely to impact assets within an attack path and which vulnerabilities are most likely to be exploited. This typically takes a reactive approach, by prioritizing vulnerabilities that are known to be exploited in the wild, often leveraging the Cybersecurity and Infrastructure Agency’s Known Exploited Vulnerability catalogue (CISA KEV). A less common, but increasing, approach is to factor in the strength and effectiveness of compensating controls, so organizations can obtain a complete residual risk view for prioritization.
- Does it help me orchestrate remediations? When you know what weaknesses are present and know what should be fixed, you need a process to fix it. This usually takes the form of opening tickets for remediation owners (If the ownership is even clear). But different workflows may be needed for different types of asset owners, and varying degrees of risk and timelines. Automating remediation can reduce potential risk stemming from a vulnerability exploit, but introduce other types of risk, such as availability and accessibility of systems.
- Does it help me report on my proactive program? Reporting needs to accompany all three of the aforementioned components. The ones I most commonly see are service level adherence, and Mean Time to Remediation (MTTR) – but these only support remediation reporting. Organizations also need to report on how visible assets are, if remediation owners and key context is missing on assets, and factors detailing the remediation prioritization strategy.
If you or the sales rep cannot provide coherent answers and examples to answer these questions, then the solution is not part of a proactive security solution suite (and it could be vaporware or snake oil).
To learn more about how to activate proactive security, register to attend Security and Risk Forum here.
This post was written by Senior Analyst Erik Nost and it originally appeared here.
Read the full article here
