The Cybersecurity Tool Lifecycle

So your organization just purchased a fancy new tool which promises to consolidate your existing tools, be a one-stop-shop for all <<insert security domain here>> issues, and integrate seamlessly with your current tech stack and processes.

Six months later it’s spitting out so many alerts that your team is ignoring them, there’s a half-working Jira integration, and any attempts to insert it into the development or IT lifecycle are furiously opposed by the other teams. Thankfully this isn’t a new phenomenon and it doesn’t mean you must purchase a separate tool to do the job.

The Security Tool Lifecycle

Below is the typical lifecycle for many security tools.

Don’t despair — there’s a way to end this cycle of wasted time, effort, and money. By revisiting your approach to security tool implementation, even subpar tools can be made effective. This iterative process can be applied to the same tool or as new ones are introduced

Get Full Coverage

Firstly, confirm your tool is installed correctly and collecting the necessary data. This might seem obvious, but many organizations leave tools half-installed — creating only the initial integration and not digging deeper into optimization. Examples include:

• Cloud configuration monitoring tools: Are these deployed across all organization’s accounts?
• Container scanning tools: Are all images in the registry being scanned?
• EDR: Is it installed on all endpoints?

Full coverage might not be possible due to cost, so you may need to narrow down success criteria, such as ‘all production endpoints should have our EDR agent’. Regardless, ensure tools are installed where needed and functioning correctly. A poor installation leads to unreliable data and decisions.

Filter to Actionable Issues

After achieving a comprehensive, well-functioning installation, you’ll likely be swamped with alerts and warnings. The 80/20 rule states that 20% of causes generate 80% of outcomes — in this case, one fifth of your tool’s findings will likely pose the highest risk to your business.

Combine the 80/20 rule with threat modeling to focus on immediate, actionable alerts that your team can handle without constant crises.

Consider this example with a Software Composition Analysis (SCA) tool:

• The SCA tool identifies 1,000 vulnerabilities.
• Filter those vulnerabilities appearing on internet-facing services.
• Further filter to only vulnerabilities with known exploits.
• Sort vulnerabilities based on severity.
• Identify which vulnerabilities can be remotely exploited.

This funneling process should help you pinpoint the most pressing risks to your organization and actionable tasks for your engineering, IT, or security teams.

Try to automate this filtering and notification process as much as possible within the tool.

Identify Relevant Subdivisions and Owners of Issues

To illustrate why many tools are never fully operationalized, consider this common scenario: your cloud security tool reveals numerous critical and high vulnerabilities in a production application container. Who should remediate them? Did the base image introduce these vulnerabilities? Who maintains approved base images: your DevOps team or engineers?

While it may seem straightforward, many organizations fail to assign responsibility for significant parts of their tech stack, leading to wasted hours in blame-game meetings. Tools and strategies are valuable, but a proper technology inventory is crucial for success.

Grant the Relevant Visibility

Now that you’ve determined ownership for issues and components in your tech stack, ensure each relevant team understands their responsibilities. Merely informing teams of numerous high severity vulnerabilities in their application image is unproductive if they don’t know where they are introduced or how to resolve them.

I frequently aim to provide technical and compliance teams with broad, read-only access to our security tools. This diminishes distrust between security and other teams while boosting developer productivity through self-service. Granted, certain sensitive information shouldn’t be fully accessible, but many security issues don’t fall into this category.

Empower Issue Owners

Often, PMs or security engineers involved in vulnerability management projects try to prioritize remediation efforts for engineers. Though seemingly helpful, it ultimately wastes time and creates friction between teams.

Engineers and IT staff have a deeper understanding of their tech stack than the security engineer reporting vulnerabilities. Allow them to determine the most efficient approach to address as many vulnerabilities as quickly as possible.

Collaborate to Shift Left

As developers adapt to the new process and remediation time for vulnerabilities decreases, security-conscious developers will likely advocate for a ‘shift-left’ approach — addressing issues before they reach production.

Just as the security team creates tickets for developers, ensure your security team implements workflows for engineering improvements. Introducing security tools earlier in the SDLC, in collaboration with engineers, not only reduces vulnerability remediation time but also fosters trust and partnership between the departments.

Iterate

Unfortunately, like all security tools, this isn’t a ‘one-and-done’ cycle; it necessitates continuous maintenance, fine-tuning, and improvement. However, each iteration is simpler than the one before and gets your organization closer to a best practice implementation.