There’s no denying that we’re living in a time where the cybersecurity threat landscape is increasingly dynamic and complex. The landscape includes cloud-native environments, Infrastructure-as-Code (IaC), containers, secrets management, remote work—and that’s just to name a few.
These new technologies and practices logically require security tooling to help address potential vulnerabilities and respond to threats and incidents when they do occur. However, there is a cost associated with the increased tool introduction and use.
Studies have shown that despite the rampant growth in security tooling, there are some concerning metrics that suggest the tools aren’t having the desired impact. For example, Ponemon reports that organizations on average have over 40 security tools, with team members admitting they don’t know how well they are actually working. And a study from Market Cube points out that teams are adding tools faster than they can effectively use them. And, ironically, the burden of tool maintenance is compromising threat response and ultimately security postures.
There’s no single thing to blame for this reality. One factor is the well known cybersecurity talent shortfall. Organizations and the industry as a whole don’t have the number of qualified and competent cybersecurity professionals necessary to meet their security needs. Another is the never-ending onslaught of vendor pitches that IT and security leaders are facing, coupled with their need to scramble to try and cover the ever-increasing threat landscape. There’s also the issue that many of these tools aren’t very interoperable and often require their own unique implementation, along with dashboards and outputs.
With the introduction of each tool comes an increase in the overall cognitive load placed on a team of individuals. It takes time to learn the tool, provision and configure it, and then monitor it to make actionable use of its telemetry.
So, where can we as security leaders begin to address these challenges and let our security teams operate more effectively, and ultimately be better positioned to address organizational risks?
Cognitive Load
One topic that is beginning to gain more traction is the recognition that technology teams have cognitive load limitations. Cognitive load recognizes that individuals can only hold and handle so much information in their brain at a given time, and this applies to teams that are collections of individuals.
This applies to your security team as well. You cannot continue to throw an indefinite amount of tooling and technologies at a fixed set of team members and expect them to fully master and operationalize them, due to the reality that cognitive load limitations do exist. If you are a security leader that continues to add security tooling to your security program and enterprise environment without considering a parallel growth in the number of people required to operate and maintain the tooling, you may be setting yourself and your organization up for failure.
As studies have shown, that approach ultimately leaves organizations less secure in the long run. It also leads to team burnout and attrition, resulting in the need to bring in new folks to learn the tools again. It can become a vicious rinse and repeat cycle.
Tool Rationalization
We’ve acknowledged that there is a valid need for new security tooling. Whether it is being driven by advances in technologies that you must secure or by more modern and robust tooling with new features and automation, the demand can be real.
However, as you look at your portfolio of tooling and introduce tools, you should also be looking to rationalize and retire tooling where appropriate. Failing to do so leaves the team with an outsized portfolio of tools to maintain and distracts them from the most relevant threats and alerts. The reality is that some security vendors simply haven’t kept pace with modern threats and technologies, in which case those tools may need to be put out to pasture.
Vendor Recommendations
If you’re on the vendor side of the scenario, you can be assured that security leaders are increasingly going to be asking about your application and products’ ability to integrate with others.
Does your application have robust APIs where it can be queried and pulled into other tools or destinations, such as a security data lake, SIEM, or others? Perhaps they want a method where the information can be queried and aggregated without the need to have the team access yet another UI. If you’re a security leader considering vendor solutions, you can also ask these questions to help drive the organizational and industry change necessary to mitigate tool sprawl.
Lastly, there are vendors gaining attention who have set out to address this issue through Unified Vulnerability Management solutions, such as Nucleus Security and others. Their goal is to create unified assets, vulnerabilities, and associated data, making it easier for teams to understand their risk posture and make actionable security decisions.
