Before You Buy Another Security Tool: Fix Governance and Process

Cybersecurity maturity, especially in the context of enterprise or corporate security, can quickly become too focused on the deployment of tools. The sheer number of product categories, with their ever-growing list of catchy acronyms (SIEM, SOAR, SASE, EDR, XDR, PAM just to name a few), makes it easy to fall into this trap.

It's easy to understand why cybersecurity leaders become so tool-focused. The marketing for these products is both effective and relentless. The green/yellow/red dashboards, and the accompanying "pew pews," look great in executive updates. Plus, it's easy to plug a tool in, check a box, and say, "X technology solves Y problem."

Cybersecurity tools are force multipliers. They allow for scale, automation, demonstration of compliance, and can speed up time to detect and remediate. However, the most effective cybersecurity leaders, those who see the greatest return on investment and build programs that truly align with business objectives, follow a different path:

Cybersecurity leaders focus first on governance and risk identification, then on tool-agnostic and repeatable processes, and then on implementing tooling.

Tools reflect maturity, but they do not create it.

Think about these common scenarios, which I've seen countless times in my career:

1. During an Incident Investigation: The SIEM is missing critical log sources, making it unreliable. Identities and asset names aren't standardized, hindering the ability to attribute actions. Event descriptions are meaningless without context.
2. Assessing a Security Program (e.g., during an acquisition): You are provided with a list of industry-known tools for every security function; impressive at first. But you quickly discover there are no procedures for how the tools are operationalized, no clear ownership for their outputs, and no defined understanding of the greatest business risks they are supposed to mitigate.

Investing in an XDR tool without clear detection objectives, triage runbooks, and application/data ownership defined is a fast track to converting money into noisy, unmanageable alerts. Without documented playbooks, standards, and review cadences, even the most sophisticated platforms will simply generate unanalyzed or unusable data.

Further, an overly "product-focused" security approach creates its own risks. It often amounts to a "spray-and-pray" approach where analysts spend time switching between dashboards, hoping the bad things are being caught. This tool sprawl increases complexity, integration risks, and creates hard-to-see blind spots between systems.

A Pragmatic Path to Cybersecurity Maturity

Tooling should always be framed as a necessary investment to help mature and automate processes that mitigate cybersecurity risks understood by the business.

The formula is clear:

Governance > Risk Identification > Process > Tooling

Proper Governance defines cybersecurity as a business function. Frameworks like NIST and COBIT treat technology as a means to execute a defined risk management strategy, not the strategy itself. With NIST's recent update to the Cybersecurity Framework (Version 2.0), they explicitly made "Govern" a core function, emphasizing strategy, roles, policies, and oversight as the foundation for all technical activity.

A Scenario: A shift to strategic controls

Imagine you are the first dedicated cybersecurity hire for a healthcare technology company. The CTO celebrates that you're here to help roll out their new EDR (Endpoint Detection and Response) solution—something everyone assumes the organization needs.

1. Governance First

Before committing to any vendor, you clarify risk and system ownership. You identify regulatory obligations, notably HIPAA compliance, customer BAAs, and a SOC 2 commitment. You align with executive leadership on a core set of risk scenarios that are most important, which include:

• Unauthorized access to ePHI;
• Unmanaged data stores containing ePHI.

2. Risk Identification

Instead of jumping to EDR deployment, you perform a focused risk assessment on the production databases storing ePHI. You discover critical issues:

• Shared admin accounts and passwords in collaboration spaces;
• Long-lived API keys;
• CSVs containing ePHI scattered across shared drives;
• No true ownership or procedure for ensuring production database configurations are secure.

The immediate gaps are in account management and configuration management around these cloud-hosted databases. Additionally, the new EDR tool would only tangentially mitigate these specific, high-priority risks.

3. Process Mapping

You define a small number of process-oriented solutions that do not require new technology to start:

• A joiner-mover-leaver process for access to ePHI systems;
• A set of change management standards for managing ePHI systems;
• A monthly access review process.

Defining owners, configuration requirements, and access procedures can be started manually. This effort gets management of the data stores under control and in alignment with policy. 

The future tools will simply enable this go-forward management with much less manual effort.

4. Targeted Controls (Implementation of Technology)

Now that you have clear governance, an understanding of the risk, and defined processes, issuing an RFP is effective. You can articulate the exact use cases you need to solve.

The project may now result in:

• Bringing on a new identity management provider specializing in user and API access to databases; and
• Implementing a configuration scanning utility that can continuously scan for, alert on, and even correct unauthorized configuration changes.

This path ensures your investments are laser-focused on the risks that matter most to the business. Following the completion of this project, you will be able to demonstrate clear risk reduction to your leadership team.

Cybersecurity Leadership Takeaways

If you cannot describe the decision process or the technical problem a tool will automate, you are not ready to buy it. You should be able to sketch your process on a whiteboard before you are talking to a vendor about how they fit into that process.

The need for a particular tool should become self-evident based on how you define risk. When the manual effort and time to control for a specific risk, multiplied by its expected occurrence, becomes a significant cost, the business case for tool investment becomes trivial.

Avoid the pitfall of implementing a shiny tool first and then searching for the problem it is meant to solve.

This Governance > Risk Identification > Process > Tooling mindset will help any cybersecurity leader better prioritize their efforts and ensure they obtain the necessary executive buy-in for procurement because the need has been clearly and strategically demonstrated.

As always, let me know what your own experiences have been, what has worked, what has been a challenge, and what lessons you have learned.