4 Steps to Centralized Security Tooling

A couple of facts struck me as at odds with each other in, “Reaching the Tipping Point of Web Application and API Security,” the new report we released last week in partnership with ESG Research. Respondents say they use, on average, 11 different web app and API security tools; yet 93% say they plan to adopt or are interested in a consolidated approach to their security tooling. With so many tools being used yet a clear desire for a consolidated approach, clearly there’s a chasm to cross here.

And I get it — it’s hard to look at your 11 tools and think about reducing tech debt and improving your security stack and practices. But it’s even harder to recover from a major security breach. 

The good news is, it doesn’t all have to be overhauled at once. I recommend taking a “prove it” approach to a security tool overhaul — start with one small project, like applying Okta across your organization, and prove that although there may be an initial loss in speed, sticking with the wrong solution results in a perpetual loss of speed, as well as a higher risk of something going wrong. Once you have that buy in, and the trust is built between the CEO or CFO and the CISO, you repeat the process. 

Here are the four repeatable steps I recommend to help pay down that security technical debt, make your apps and APIs more secure, and move toward consolidated security tooling.

Although there may be an initial loss in speed, sticking with the wrong solution results in a perpetual loss of speed, as well as a higher risk of something going wrong.

1. Take an inventory

You can’t protect what you can’t see. Shadow IT refers to the use of technology not approved by the IT department, and according to Statista, 42% of people they talked to engage in it. For example, developers are interested in moving quickly, so they may not always tell IT teams about new APIs or AWS instances. But even if you have the most sophisticated security tools on the market, if a developer launches an unknown API, it isn’t covered.

Part of the problem is siloed work. It’s human nature to want to solve a problem right away, but not every tool a developer uses has been created and/or blessed by the security org. The best place to start is by inventorying and understanding the software delivery workflows in your organization. What are the commonalities in tech or process? Which components serve as centralization points or have access across your IT footprint? From there, you can work with engineering leaders to identify the best way to treat these categories of risk rather than playing whack-a-mole with an ever-expanding list of specific tools or vendors.

2. Assign risk and prioritize

Once you have a list of everything you need to ensure is secure, you can assign risk ratings to each item. First, it’s essential to understand which services or tools are most critical to successful software delivery. What ensures that production services stay highly available to users? Which components store or process sensitive data? What tools have privileged hooks into other tools or components? Basically, consider what parts of your software systems would most disrupt or damage revenue generation and delivery to users.

Then, you can consider where low-hanging fruit for attackers can be pruned so that there isn’t an easy way to attack those high-priority resources. This is where something like the OWASP Top 10 can come in handy. The top three attack threats listed for 2021 are injection, broken authentication, and sensitive data exposure. You probably want anything that might be exposed to those three threat risks to lead the way in your overhaul. 

Once you’ve assigned risk and prioritized your list, get to work in small increments. Don’t try to do everything at once. Start serially — maximize or replace one, then move to the next.

3. Implement secure DevOps in parallel

As you’re working on consolidating your security tools and practices bit by bit, don’t sleep on your processes. When devs are deploying multiple times a day, they can’t run every new instance through the security team. So, really, secure DevOps is building tooling into the product — as it’s being developed, it’s being tested for security in a way that avoids disrupting development productivity or velocity. 

Development and security teams need to work together so when there’s a new API created, for example, security policies are applied. Then the security team can manage the policy as new threats come up or vulnerabilities come up, and apply to everything built on that API. 

It’s not just your teams that need to talk to each other though. The concept of defense in depth is well understood. It’s just in practice where things get hairy: there are specific tools that are good at protecting against specific threats, but if none of them integrate, you’ve got a problem. You need visibility against a spectrum of threats because attackers are testing multiple places for vulnerabilities or ways to abuse functionality. Having an end-to-end view of your threats and traffic across security and development is all part of secure DevOps.

4. Wash, rinse, repeat.

Once you have your new tool or practice in place, test it. Then continue to test it in production. You can’t just set it and forget it; attackers will be delighted to discover forgotten or abandoned tools that minimize their chances of being caught (or make a cozy resting place for persistence). Your goal is to gain continuous, provable confidence in each solution in order of priority to the business; this ensures you are maximizing your return on investment while also empowering your teams with dependable tools they feel comfortable using in their workflows through repeated practice. 

The idea of overhauling your stack for more unified security solutions can be daunting, but the return on your investment is priceless — reduction in blind spots, reduced false positives, simplicity, cost savings, and more. By taking a “prove it” approach, consolidating your solutions is within reach.

Download the complete report for more information on how and why security tooling is at a tipping point.