Throughout my career in cybersecurity, I've often heard other practitioners advocate for the idea of a "single pane of glass." While this concept can be valuable in some contexts, it often breaks down when security leaders force the concept onto other teams demonstrating a fundamental misunderstanding of how the teams they support actually work.
When the Single Pane Works
For security analysts, a single pane of glass makes sense. Tools like SIEMs (Security Information and Event Management) or GRC platforms can serve as centralized dashboards to ensure nothing is missed. This consolidation works because it's tailored to the analyst's workflow. It's their primary tool. Their single pane of glass.
Where It Falls Apart
Problems manifest when the concept is forced upon others in an organization, such as development teams and system owners. Unlike security analysts, who require a holistic view of the environment to better understand overall risk, these folks don't live in the security tools. They have their actual job to do. Asking them to adopt a new "pane of glass", even if it's consolidated, creates friction. This friction prevents issues from being resolved. These teams are not looking for one more dashboard to check. They want fewer distractions, not more.
Consider a security organization that decides to provide fix teams with a single pane of glass to view all of their issues. Better one centralized tool than n scattered ones. It's logical. However, it overlooks a critical issue. Teams don't operate in that system. Developers use tools like Jira. System owners may use ServiceNow to track issues. Adding another tool to their workflow is still an extra step. For them, even a single pane of glass can feel like a burden if it's not where they are already working.
Recent hype tools, like Attack Surface Posture Management (ASPM) platforms, have attempted to address this challenge. While these tools can offer value (if properly built and maintained), especially for providing high-level overviews of risk and exposure to security teams, they are less effective for tactical, day-to-day issue resolution.
Meet Teams Where They Are
So what should we do? Rather than forcing developers and system owners into yet another system, security teams should focus efforts on integrating findings into the tools and workflows these teams already use. For example:
- Developers - Send vulnerability findings to their code repository or CI/CD pipelines. Allow developers to fetch their issues and consume them however they'd like.
- System Owners - Push issues into their operational platforms like ticketing systems and monitoring tools.
By meeting teams where they already are, security teams can drive engagement, improve response times, and reduce friction in addressing security issues. Simple.