The 1980s gave us many good things, such as U2, Metallica and Bon Jovi (questionable). But from a security perspective, this hair-band era is where the proliferation of security tools began.
Fast forward to today and it seems the IT industry’s rush to invest in security tools was not a good idea. We also haven’t learned from our mistakes. Although research has shown that 65% of cloud incidents were the result of customer misconfigurations, there is still a knee-jerk reaction, with every major breach, to buy yet another tool to fix that particular issue. This is problematic for two reasons:
- Security teams are not growing proportionally to the tools they purchase. And…
- Cryptographer Bruce Schneier was right: Security tools don’t make us more secure, processes do.
- Figure 1: Evolution of Cybersecurity Tools.
Given that there are many security requirements across every cloud technology, security teams must focus on streamlining their security portfolios. How can we avoid the sins of the past? The answer lies not in yet another seemingly sexy point product, but rather DevSecOps as a well-defined process.
- Figure 2: Five Steps to Implement DevSecOps.
Step 1: Define Your Future
Before jumping into this project, it is absolutely imperative to know exactly where you want to end up. If you as the security leader cannot clearly define what the end result should look like, your team will struggle. This isn’t about the technical details of how or the method by which it gets done (this is why you have a team) but rather the outcome you want to achieve. Key items include a few statements on what success looks like, accountability, responsibility, resources and milestones. Expect your strategy to mature over time and don’t spend too much time trying to make it “perfect.” Iteration over time is a key component of a DevSecOps mindset.
Step 2: Discover Code Movement
Whether the security and IT teams know it or not, every organization has a process by which code and changes make their way into the cloud (public or private). The trick for the security team is discovering what the process looks like today. This is about mapping out the who, what, when and where of how your organization pushes code (application and infrastructure) into the cloud. If this is not well-defined in your organization, then it is highly likely focusing here may yield the greatest opportunity for improvement i.e., risk reduction through quality control.
Step 3: Inventory Security Tools
While it’s tempting to think your organization can jump to a DevSecOps model, it is not possible without first understanding what is already in your security portfolio. When I ask security teams if they have a list of all security tools in use a vast majority of the time the answer is no. This isn’t surprising as the size of your organization has historically been proportional to your number of security tools. From what I’ve seen, small businesses can have as few as 20 tools while the largest of organizations often have more than 130 (think financial services). In this step, your team will create an inventory of all existing tools, commercial, homegrown and open source. Beyond just a list of tools it is important to track, at a minimum, the following key items:
- Why the tool was originally purchased or created.
- The risk(s) it was purported to reduce or mitigate.
- It’s native ability to consume and integrate with cloud provider APIs.
- The openness of its API (how easy is it to get data out of the tool).
- Its ability to generate and share contextual threat intelligence (closely related to #4).
- Annual cost (be sure to include hard dollars paid to the vendor as well as an approximate estimate of the cost to support the tool with personnel).
Step 4: Assess the Gaps
Many organizations use control frameworks such as the Center for Internet Security’s CIS-20, NIST Cybersecurity Framework or the Australian Cyber Security Centre’s Essential 8. If your organization uses one of these or perhaps relies instead on a risk-based framework, this next step involves overlaying this information with your inventory of tools as well as the code movement patterns discovered in step two.
However, no matter which framework your organization uses, it is important to base your gap analysis on an industry standard. This analysis should yield multiple outcomes. First, it will help you understand which tools you own, manage and pay for today. Second, and most importantly, it will give you a direct line of sight into both control gaps as well as overlaps. And finally, it will help you identify how you are invested across the security vendor landscape.
As the leaders in this space have consolidated point products into comprehensive cloud security platforms, organizations can save real dollars. They can also use these platforms to reduce complexity that improved operational efficiencies offer. Critical to achieving DevSecOps is moving from a tangled web of disjointed solutions to comprehensive platforms that support the execution of your chosen framework.
Step 5: Iterate Quickly
The “final” step of the process (okay, it’s not actually final, as DevSecOps requires constant iteration) has two distinct parts. The first is taking what you learned in the gap analysis and applying it to your code pipeline, while the second is investigating and acquiring platform-based cloud security controls that support the execution of your DevSecOps strategy. It is likely that this analysis will mean saying goodbye to many of the point products that have overburdened your team for years. Key outcomes for this step include working closely with development and IT to insert security processes and platforms into the least-disruptive areas of your code pipeline. This is done effectively through the rapid addition of security guardrails (not gates) along the way.
Taking a continuous improvement driven approach, fueled by an industry standards-driven gap analysis will generate ample opportunities for improvement. All without requiring 99+ security tools. Teams following this process will be well on their way to implementing DevSecOps. Start small. Ramp quickly. Iterate continuously.
To connect directly with security thought leaders, Cloud Native Security Live, 2020 Virtual Summit is your opportunity to engage and interact with other developers, DevOps pros and IT leaders who all have so much at stake in container technologies and DevSecOps. Hosted by Palo Alto Networks in partnership with The New Stack, join us on Feb. 11, 2020, for a full day of discussions about cloud native security — brought to you live online wherever you may be.
Feature image via Pixabay.
The New Stack is a wholly owned subsidiary of Insight Partners. TNS owner Insight Partners is an investor in the following companies: Real.