Transcript
Mark Nunnikhoven [0:07]
The cloud is an interesting place to build solutions for customers. It provides easy access to levels of technology that simply weren't available a decade ago. You can now launch the equivalent of an entire data center with a single command. This power has been a huge amplifier for teams around the world. The assumption was that without amplification, the security challenges that we see on premises would grow as well. Teams should be struggling with zero days, vulnerability chains, and shadow IT. It turns out, they aren't, at least those issues are nowhere near the top of their list of concerns. The top security challenge for builders in the cloud is actually very straightforward. Their biggest challenge is making mistakes that come in the form of service misconfigurations. Now I know that at least a few of you have probably raised your eyebrows at that statement and I will back it up in a minute, but first let's look at the evidence around the initial assumption that most people make about cloud security. They assume that the cloud service providers themselves are a big risk. The data doesn't support this at all. Each of the four hyperscale service providers, Alibaba Cloud, AWS, Google Cloud, and Microsoft Azure have had two security breaches over the past five years combined. Now, before I explain each of these it's important to note that each of the Big Four have had to deal with a ton of security vulnerabilities over this timeframe, a large number of cloud services are simply managed service offerings of popular commercial or open-source projects. These projects have had various security issues that the providers have had to deal with. The advantage for users, the builders, is how operations work in the cloud. All operational work, and make no mistake that security is operational work, done in the cloud follows the shared responsibility model. It's very straightforward. There are six primary areas where daily operational work is required and depending on the type of service that you're using in the cloud, your responsibilities shift. If you're using instances or virtual machines, you're responsible for the operating system the applications running on that OS and your data. And as you move to entirely managed services, you're responsible just for the data that you process in store with that service, but for all types of cloud services you are responsible for the Service Configuration. Now despite having a clear line of responsibilities the providers actually offer a number of features that help you meet your responsibilities and adjust the service to suit your needs.
Mark Nunnikhoven [2:39]
Now looking back at those two security issues from the providers over the past five years. The first one we'll look at is from March 2020. In this case, Google Cloud paid out $100,000 reward through their bug bounty program to a security researcher who found a privilege escalation in Google Cloud Shell. This is a service that provides a browser-based interface to the command line of a virtual machine running in your account, and under the covers the shell is a simple container running an application that provides the required access the researcher noticed that they were able to use a socket connection in that container to compromise the host machine and escalate their access. The root cause, misconfiguration in the access to that socket. The second example is from October 2020 for this one we turned to Microsoft Azure. Here an issue was reported in the Microsoft app services offering this vulnerability allowed an attacker to escape the expected boundaries of the service and access a limited scope deployment server with elevated privileges. The reason, a misconfiguration in the open-source tool that provides that provided the web hosting service in this app. Now, in both cases, the vulnerabilities were disclosed quickly and responsibly, and the issue was fixed without any reported customer impacts, but both of these cases were in higher level cloud services. These are services that the providers teams built using other services on that platform. So as a result, and in line with the shared responsibility model, they were at risk of a service misconfiguration, even the hyperscale providers face this challenge. Now there's more evidence to support the fact that misconfigurations are the biggest issue in cloud security. Security researchers in the community that study cloud issues have all published findings that align with this premise that whether that's from other security vendors, or industry organizations the findings all agree, 65 - 70% of all security issues in the cloud start with a misconfiguration, but surveys and targeted research projects, only go so far.
Mark Nunnikhoven [4:40]
What does the publicly available evidence say? Well, if you filter out all the reports of cloud hacks and breaches to remove incidents that were not cloud specific. So those were the issue wasn't related to the cloud the service just happened to be hosted in the cloud. There's still over 2 billion sensitive records that have been exposed to a breach in cloud security. Let's take this even further and remove every single breach from the list that wasn't due to a single misconfiguration. Yes, single, one wrong setting, one incorrect permission, one simple mistake, caused all of these breaches. That leaves just the Capital One breach. This is a more complicated event that was caused by, two misconfigurations and a bug. And after in-depth analysis, this bug was actually inconsequential to the overall impact, which was 100 million customer records being exposed. Now what's more is that Capital One is a very mature cloud user. They're a reference customer for AWS, they've been a huge advocate for cloud within the community, and they were even the incubator for the very popular open-source security governance and management tool called Cloud custodian. This is a team that knows what they're doing. And yet they still made a mistake. And that's really what misconfigurations are, at their heart their mistakes, sometimes those mistakes or oversights, other times in incorrect choice made due to a lack of awareness. It all comes back to the power made accessible by the cloud, reducing these barriers has had a commensurate increase in the pace of innovation teams are moving faster, and as these teams mature, they're able to actually maintain a high rate of innovation, with a low failure rate. In fact, 43% of teams who have adopted a DevOps philosophy are able to deploy at least once a week while maintaining a failure rate under 15% critically, when they do encounter failure, they're able to resolve it within the day more impressively 46% of those teams resolve those issues within the hour. But as we all know cybercriminals don't need a day. Any opening can be enough to gain a foothold creating an incident. So, what about teams that aren't at this pace. Well, the other 57% of teams, the majority of which are at large enterprises, often feel that their lack of pace provides a bit of protection. Moving cautiously in the cloud allows them to take a more measured approach and reduce their error rates. And while this may be true, there's no evidence to support or disprove this assumption, change is still happening around them. The cloud service providers themselves are moving at a rapid clip. In 2020 alone the big four hyperscale providers released over 5000 new features for their services for a single cloud user that means almost two new features a day at a minimum, and for the growing set of multi cloud users, the pace of change only increases. So even if your team is moving slowly, the ground underneath them is shifting rapidly. The goal of cybersecurity is actually quite simple. The goal is to ensure that whatever is built works as intended, and only as intended. And in a traditional on premises environment. This standard approach is a strong perimeter with deep visibility across the enterprise. That doesn't work in the cloud. The pace of change is too rapid both internally and with the provider smaller teams are building more and more and quite often by design these teams act outside of the central CIO infrastructure. This requires that security is treated as another aspect of building well, not a standalone activity. Now this all sounds like a monumental task. It's not. It starts with two key questions. What else can this do? And are you sure? For example, this container running the code that creates the financial reports. What else can I do? Can it access other types of data? Are you even sure it's the right container? This is where security controls provide the most value. Most of the time when we talk about security controls, we talk about what they stop using an intrusion prevention system can stop worms and other types of network attacks. Anti-malware controls can stop ransomware crypto miners and other malicious behaviors. For every security control we have a list of things that it stops. Now this is excellent, don't get me wrong and it works really, really well with subject matter experts, aka the security team, but builders have a different perspective, builders want to build. And when framed in the proper context, it's easy to show how security controls can help them build better. Posture management helps them ensure that settings, stay set regardless of how many times the team deploys within the week network controls can assure teams that only valid traffic ever reaches their code, and things like container admission control can make sure that the right container is deployed at the right time, security controls do so much more than just stop things from happening. They provide answers to the critical questions that builders are starting to ask, what else can this do? Very little thanks to these security controls. Are you sure? Yes, I have this control in place to make sure. Security is an accelerator for cloud innovation. When done well and make no mistake, Trend Micro delivers products that do this well security controls help teams build better in the cloud.