At first blush, “prioritization” and “risk findings” somehow “seem” like they have to go hand-in-hand. We have to prioritize the findings because we’ll never get through them otherwise, right? Thinking about it further, we always talk about the need to prioritize because we’re almost always in firefighting mode, trying to stay effective within scarce resources and an inefficient process. It turns out that operating in a constant firefighting mode prevents us from scaling our processes.
Every day our security testing tools dashboards offer us a long list of new findings that we add to our old findings. Realizing the list has grown out of control, we naturally conclude there’s no other choice but to start prioritizing. Sadly, when it comes to cyber risk remediation and the processes most of us have built, by the time we reach the point of needing to prioritize, it’s already too late. For example, if there are already exploits in the wild for a finding, we prioritize it above others. However, if the vulnerability is already weaponized, then we are starting the fix process too late. That’s a perfect example of “firefighting.” Much more desirable is a scalable process that makes our organizations more resilient. With that, the next time we find an exploit in the wild, we’re already covered.
How do we get into such a frenzy? It’s a function of scarce resources. It’s expensive to remediate even a single finding. We need to analyze the finding, make the triage decision that it requires remediation, open a ticket, copy-paste from the tool that made the finding to the ticket, and find the owner to execute the fix. The more money it costs to perform the remediation process, the more we need to prioritize. This high cost of the security administration work alone forces us to only focus on ultra-critical findings and fix less, which in turn prevents us from being proactive in our remediation process.
It’s only once we stop and break the remediation process down into its constituent parts that we come to appreciate more fully that fixing a finding does not just require applying a patch, it’s an entire project that we have to manage: it’s about the full process from vulnerability analysis, to making the decision about its relevance, to preparing for the fix, executing the fix process, and verifying that the fix worked.
If we can focus on and improve the inefficient and ineffective project management aspects, and reduce the cost of each item, then we are in a position to free up time both for security and remediation teams, and consequently form the foundation for a scalable process.
We need to reduce the administrative overhead, but before we can scale our processes fully, we need to make another mental shift. Think about times when the team has have two critical tasks it has to get done. There’s always a need to prioritize between the two so the team knows what to do first. But what if they could be done in parallel? What if the security team could solve them with two separate workflows, two different teams?
Consider these two tools, each presents its own findings and gets prioritized by the security team to provide the fixer:
- External Attack Surface Management (EASM). The EASM tool discovered unpatched resources exposed to the internet. It also showed that the company’s website has an out-of-date version of WordPress.
- Static Application Security Testing (SAST). The SAST tool found that the company’s web application has a SQL injection vulnerability. Plus, another web application the company has uses an API prone to data leakage.
In these examples, a better prioritization method won’t necessarily help. EASM and SAST tools each offer their own findings prioritization, based on their own methodology that factors in thousands of data points and best practices.
As these scenarios exemplify, the problem is that ironically, the security team became the bottleneck for remediation since they’re working off of one queue when eventually these findings most likely will go to two separate remediation teams. The security manager then wants to get these items off his desk as soon as possible so fixing is done in a parallel manner.
Putting all this together, to transition then from a firefighting mode to a scaling mode, the team needs to do the following: reduce the price of the fix; understand where the team has gotten “stuck” in security administration work; and finally, recognize whether items are a competing priority for engineering teams. Based on that knowledge, security teams can then work towards removing the bottlenecks to achieve effective project management.
Ravid Circus, co-founder and CPO, Seemplicity
