Field Notes

Avoiding security tool sprawl as you scale

Balancing the usefulness of security tools with your team’s ability to actually use them is a major challenge for many organizations. Often, security tools outnumber the people using them by multiples a VC would love.

Avoiding security tool sprawl as you scale

Balancing the usefulness of security tools with your team’s ability to actually use them is a major challenge for many organizations. Often, security tools outnumber the people using them by multiples a VC would love.

Some tools enable teams to cover far more surface than would otherwise be possible. Others end up a massive time suck that drains not only your budget but your most valuable resource - time.

Implementing new tools incurs ongoing costs via maintenance and support that needs to be accounted for. Commercial or open source, the effort required to implement and maintain tools often isn’t fully considered. In the long run, this leads to underutilized, ill-configured systems that, like my Peloton, sit to the side, longing to be used.

Without mindful awareness of capacity, it’s easy to end up with a fine piece of shelfware that is no longer spoken of until renewal time approaches. Then, on your next sync with the CFO, you can highlight the selflessly aggressive cost cutting measures you are making by cutting it.

Some things to consider:

👷 Smaller teams often benefit more from a smart hire than from a new tool because a strong hire can often address the root cause of an issue and then move onto the next one, compounding their impact over time.

⚖️  As the platform grows, so does the need for tools to effectively manage it. This requires mindful balance between team capacity, the need for additional tools that improve coverage, and the commitment required to effectively utilize them.

⏰  Some tools are more hands-on than others. Ensure you account for the time investment your team will need to commit to between training, installation, configuration and ongoing maintenance.

🩹  Is the tool solving the problem or is it just a band-aid on an underlying issue? In most cases, solving the root cause rather than addressing symptoms pays off in the long run. Solving for frequent, automated updates is a better first step than rolling out a new tool to alert you when ca-certificates_20230311ubuntu0.22.04.1_all.deb needs to be bumped.

Monetary costs fit neatly into a cell on a budgeting spreadsheet. Predicting the impact of the time your team will spend over the next year tuning the ruleset in a new platform over the next year is much fuzzier and error prone.

Just because you don't have an exact figure doesn’t mean you should leave it out of the equation though. Talk with peers outside your company. Ask for references from the vendor. Put the time in to research and embrace the remaining uncertainty to improve your decision making.

It’s better to be roughly right than precisely oblivious.