Fast forward to today and it seems the IT industry’s rush to invest in a vast array of 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, following every major breach, to buy yet another tool to fix that particular issue. This is problematic for two reasons:
1. Security teams are not growing proportionally to the tools they purchase. And…
2. 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.
Before jumping into this project, it is absolutely imperative to know exactly where you want to end up. If you, as a 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.
Whether the security and IT teams know it or not, every organisation 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 organisation pushes code (application and infrastructure) into the cloud. If this is not well-defined in your organisation, then it is highly likely that focusing here may yield the greatest opportunity for improvement i.e. risk reduction through quality control.
While it’s tempting to think your organisation 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 organisation 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 organisations often have more than 130 (think financial services). A 2020 study reinforced these observations, revealing that 78% of IT and security specialists leverage more than 50 different tools, while 37% of organisations rely on more 1001. 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:
1. Why the tool was originally purchased or created.
2. The risk(s) it was purported to reduce or mitigate.
3. It’s native ability to consume and integrate with cloud provider APIs.
4. The openness of its API (how easy is it to get data out of the tool).
5. Its ability to generate and share contextual threat intelligence (closely related to #4).
6. 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).
Many organisations use control frameworks such as the Centre for Internet Security’s CIS-20, NIST Cybersecurity Framework or the Australian Cyber Security Centre’s Essential 8. If your organisation 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 organisation 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, organisations 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.
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. 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.
Learn more on Palo Alto and DevSecOps today, book an appointment with a Data#3 specialist.
1. Oracle (2020). Oracle Cloud Threat Report 2020. [Online] Available at: https://www.oracle.com/a/ocom/docs/cloud/oracle-cloud-threat-report-2020.pdf
