Cloud native. What does this mean to you?
My personal definition goes something like this: An application is cloud native when it is crafted from day one to organically make use of API-driven platforms. This is the complete opposite of "lift and shift."
How has this move to cloud native impacted the risk to organizations? We recently explored that question in an industry-first survey (which provides a view into what people think) of over 3,000 professionals. We dug deep into the State of Cloud Native Security. There are three interesting parallels I’ve found with this survey when compared to our threat research (which provides a view into what organizations actually put into practice).
Scaling and Automation
The survey found that 45% of the companies we rated highly prepared have embedded security into DevOps processes. By contrast, 21% of the least-prepared companies have embedded security in DevOps.
Security professionals often tell me they are unable to scale. It seems that no matter how many people and tools they try to throw at the problem of securing their organizations, DevOps projects always grow disproportionately faster. Here’s the truth: even in the most well-resourced security teams, this will almost certainly continue to be the case – as long as security teams remain under-invested in automation.
According to the Cloud Native Computing Foundation, there are an estimated 4.7 million cloud native developers around the globe. (ISC)2 found only 2.8 million cybersecurity professionals worldwide. We have a numbers problem.
DevOps teams make heavy use of automation because it allows them to scale without proportional headcount. One way to achieve this is by utilizing Infrastructure as Code (IaC) templates. For the uninitiated, IaC templates replace the manual process of creating cloud infrastructure.
The beauty is that once you’ve defined the architecture of your application in an IaC template, you can reuse it an unlimited number of times. Each time, you’ll get the same environment. This approach scales. The downside is that if you create a template with a misconfiguration (like exposing a sensitive service to the entire internet), you also recreate that vulnerability every time the template is used. This is where security automation comes in.
Proof point: In the Spring 2020 Cloud Threat Report, Unit 42 researchers found that 42% of all CloudFormation (CFT) files contained at least one insecure configuration. Don’t use CFTs? The researchers also found that 22% of all Terraform files contained at least one insecure configuration.
Bottom line: DevOps teams are using IaC and other forms of automation to scale. The security team needs to do the same while embedding more security touchpoints into the software development lifecycle.
The survey found that highly prepared companies recognize that more security tools make it harder to prioritize risks and prevent threats.
In other words, more security tools do not equal less risk (I would argue that there’s actually an inverse relationship). Along the same lines, in a talk I did at RSA, I made the assertion that point products are killing us. In a separate, informal and non-scientific survey of security tools inclusive of on-premises and cloud, I found that many small businesses have up to 20 security tools. Medium businesses tipped the scale at 60, and the largest (think large financial services companies) topped out around 130!
While the numbers specific to cloud are disproportionately smaller – 42% of respondents use 11 or more cloud security vendors – this number is bound to grow over time. The reason is that most security teams attempt to address every new cyber challenge with yet another tool. This approach is unsustainable, and it will not scale in the cloud.
Proof point: Unit 42 threat researchers found that 65% of cloud security incidents are the result of customer misconfigurations. Not zero-days.
Bottom line: When security teams are busy managing 99+ security tools, they lose risk clarity. In the words of W. Edwards Deming (the father of Total Quality Management), “End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.”
Less complexity equals greater risk clarity.
Companies with high cloud adoption and big cloud budgets do not always use the most platforms.
Those who use the cloud the most are highly focused on which platforms they use. This has perfect parallels to manufacturing. The most cost-effective producers almost always look to share parts across product lines. What’s standardized can be automated and made more cost-effective. We need to view cloud and cloud security the same way.
When an organization is new to cloud, there is a rush to adopt as much cloud as possible. People get excited and want to try every platform and form factor. But as organizations crystalize their cloud strategy and grow more cost-conscious and mature, they often pull back and focus on fewer cloud platforms. This pullback doesn’t mean they are doing less in the cloud – quite the opposite. They are actually doing more with less cloud platform complexity.
Proof point: The majority of high cloud adopters, 61%, use just one to five cloud platforms.
Bottom line: When it comes to cloud and cloud security, less complexity is the hallmark of mature cloud organizations.
Things to Remember
Between the Spring 2020 Cloud Threat Report and our State of Cloud Native Security 2020 survey, there are several key takeaways:
- Embrace Infrastructure as Code.
- Look for natural places to insert cloud native security platforms into the software development pipeline.
- Focus on comprehensive cloud native security platforms over individual tools to reduce complexity.
- Fall into the trap of believing more tools equals less risk.
- Use more cloud platforms than your organizational maturity is ready for.
- Try to solve scalability problems with headcount. Use automation instead.
For the complete set of insights, check out the full State of Cloud Native Security 2020.