While cost reduction and tool management bandwidth concerns might be why you are considering Security Tool Consolidation – the Hacker has a different agenda. They are counting on you to NOT consolidate your security tools – indeed their hacking success is highly dependent on you continuing with tool proliferation for a lot of reasons. Here are Five from the perspective of the Hacker:
Reason 1 – Don’t Bother with Us – Focus on Compiling Reports
It is good to set goals. Imagine how impressive it will be if your team dedicates itself manually compiling reports from all of your security scanning tools for each layer of the IT stack and you invest weeks if not months of time ensuring each scanning tool siloed results is contextualized against your other IT stack siloed results. Imagine how impressed your management will be that you have managed this quarter to hobble together a report smoothing over the fragmented picture of your Security Posture. And the great news is you get to do it all again next quarter. That’s the point of your security team isn’t it – compiling reports across your siloed point scanning tools, right? Us hackers can be out of sight and out of mind respectfully while you accomplish this important task.
Reason 2 – Tool Proliferation Noise is not a Distraction – It’s Your Day Job
We know scanning tools create a lot of noise – false positives. We know that having different scanning tools for every IT layer generates exponentially even more noise. But if you want accuracy, then you have to owe up to the fact that you are going to be spending the bulk of your time ruling out false positives. Sorry, that’s your day job. And sorry if that takes the focus off our creative entrepreneurial activities. If that handicaps you against actually catching real vulnerabilities that we can exploit – we are ok with that.
Reason 3 – Automated Scanning Tools Spit out Alerts – Interpreting Broken Business Logic is Messy
We are hackers. We are humans. It’s not easy finding ways to hack corporate systems. We have to think through how seemingly innocent exposures to say, a moth-balled application exposed to the public internet, combined with some creative thinking how small logical steps can gain us access to our prize. We do not want you to think about the logic. We want you 100% reliant on scanning tool reports. Even worse, we do not want you to bring in security expertise to anticipate how real attack surface vulnerabilities can be exploited. Focus on acquiring and managing more scanning point tools and enjoy the scale of alert generation and we will focus on breaking the business logic. Leave the messy human interpretation stuff to us.
Reason 4 – All Vulnerabilities are Created Equal
If through a single full-stack integrated solution, you have access to a “single touchstone of truth”, then that’s not really fair. Your traditional procedure of stacking up all the discovered vulnerabilities from each of your security tool-generated alerts with no regard to their business significance helps make it an even playing field. Your attendance to vulnerabilities that do not really matter or better yet are not even actual vulnerabilities, gives us a chance to seize on those small windows of opportunities that really matter. If you consolidate your layered security tools into a single platform that can laser focus on those vulnerabilities that really matter across the entire attack surface continuously, then that takes us out of the game. And if you can automate business-ranked vulnerability alerts while ruling out false positives, then you are really taking the fun out of the game. So we say categorically “No” – in the spirit of fairness – keep the disparate tools, keep a generic list of all discovered vulnerabilities and manage them one by one and leave it to us to find things that really matter.
Reason 5 – Promptly Closing Vulnerability Tickets with All of Your Tool-Generated Alerts is Not Your Job
It’s enough with your day job to manage the overhead of multiple security tools and discovering vulnerabilities themselves – surely you cannot be shouldering resolving the vulnerabilities themselves? That’s IT and Operations job. All you have to is take all of the vulnerability reports individually from each of your many scanning tool across your IT stack and individually send them to your IT and Operations team. They are perfectly equipped to sleuth through the hundreds, if not thousands of alerts generated with each tool, discern what requires the most attention and know exactly how to resolve them, including any broken business logic that could lead to a serious incident. And you can be rest assured that the IT and Operational Support Team primary job is NOT to optimizing business process and technologies to achieving their business goals and resolving their own user IT tickets. No, they live to pour through your heaps and heaps of multiple tool vulnerability reports and figure out how to resolve things that really matter. And while we wait for the fixes to happen across all of your tool-generated alerts between you and IT, we are certainly content to creatively leverage those important vulnerabilities that are not resolved. That lengthy step between vulnerability identification and remediation is what we live for. And if the step is longer when burdened with too many tools – all the better.
The hacker is a huge fan of your multiple point solution approach. Tears of happiness were shed when Gartner confirmed that in 2021 “78% of Enterprises have 16 tools or more and 12% have 46 or more.”
Taking a step back and taking on the perspective of the hacker does make it more obvious that burdening your Vulnerability Management team (and your IT team) with a plethora of security tools gives the hacker unnecessary advantages to advancing their efforts. And yet Gartner tells us that Enterprises today simply have too many tools. The good news is that there are solutions and approaches that make Security Tool Consolidation and all its inherent benefits available today.
If you would like to learn more how to achieve tool consolidation today, click Read Whitepaper