In our first post, we highlighted the top ways the cloud impacts security operations, but we stayed at a high level and largely avoided getting into specific mechanics. Diving a little deeper, some additional characteristics of the cloud directly impact SecOps and can guide how we can expand our core capabilities to support program modernization.

Let’s dig into the details to identify where we should look at making our technology changes to support cloud-modernized processes.

Cloud Disruptions

The best way to think about cloud computing is as a completely alien technology on the inside that looks the same on the outside. Yes, the cloud is built on the same technical building blocks as your own data centers, and many of the things we build in the cloud look, on the surface, the same. But the layers of abstraction in the middle create something wholly original that works completely differently once you scratch the surface.

These create behavioral and structural differences that can guide how we build our SecOps support infrastructure and capabilities:

• Velocity: Cloud deployments change continuously. And by continuously, we mean continuously. Resources are commonly created, destroyed and reconfigured every few minutes, if not seconds. That server with that IP address might not be the server that had that IP address tied to an indicator of attack in the logs. By the time an admin or responder sees an alert, that resource might no longer exist or will look completely different than it did when the issue was detected. However fast you think the cloud moves, it moves faster.
• Distribution: An average small or mid-sized organization early in its cloud journey can typically have 10-15 different cloud deployments (our word to include provider-specific environments like AWS accounts, Azure subscriptions or Google projects). Resources are scattered across these deployments; sometimes connected, sometimes isolated. Larger organizations can easily manage hundreds or thousands of deployments managed by dozens or hundreds of different teams. While these all share a management plane, they won’t automatically share a single top-down view, security telemetry plane or security and management tooling. No central team manages everything, distributing core architectural and practical knowledge across teams.
• Identity is the Perimeter: Attackers don’t need to break into servers and networks; they can use stolen and exposed credentials to directly access the management plane and re-wire those servers, networks and more with a few API calls or clicks in a console. When an attacker steals cloud credentials, you can’t stop them with a firewall or by shutting down access to a server.
• The internet is always a click away: Public cloud is a place to build things when you might want to make them public. While most providers default resources to being private, nearly all resources can be made public with minimal effort. This is an inherent characteristic of the public cloud. Combined with the velocity of the cloud, the potential for instantaneous public exposures is quite high.
• Cloud providers update constantly: The major cloud providers each support a range of 200 different services. There are multiple feature updates across this portfolio on a daily basis. Customers can choose when and where they use some of these features, but they don’t get to choose when the provider enables them across all customers.
• Knowledge is local: The average cloud application stack will use dozens of a cloud provider’s different services, all using tuned configurations. The entire stack, from the front end to the network configuration, can be built and customized to meet the needs of a single application. This results in greater contextual application knowledge with the local team and lower knowledge within central teams.

Things move fast, are highly distributed, locally managed and on the internet. Contrast this with a data center where change is slower, more centralized and behind a perimeter. Once you internalize that, understanding how to update operational security processes becomes more straightforward.

From Core Principles to Core Capabilities

Now that we’ve narrowed the general impacts of the cloud—at least major ones that affect security—we can distill out some guiding principles to help determine the core technical capabilities we need to support SecOps:

• Operate in real-time: SecOps has never been the domain for the tardy, but the speed of change of cloud combined with the proximity of the internet means issues may need to be detected and managed within minutes or less, not hours. Speed matters, and tooling needs to run as close to real-time as possible.
• Treat configuration changes as indicators-of-compromise (IoCs): When an attacker compromises credentials, they will use their management plane access to execute attack activity. This will result in configuration changes, not exploiting some zero-day cloud provider vulnerability. The line between a misconfiguration and an attack comes down to the intent of the holder of the credentials. Tools need to track configurations and identify misconfigurations, while the SecOps team needs to treat misconfigurations as potential indicators of attack.
• Collaborate: Local teams, those app and cloud teams that manage their own deployments, will have the knowledge to know if something is a mistake, an attack or a required configuration. They will also know the best way to remediate the issue without breaking their stack. For example, and related to configuration changes, a security team might detect a new public S3 bucket or Azure Blob. The cloud logs will let them know who made the change, but how do they know if it was a mistake, an attack using stolen credentials or a required configuration for that application? Security won’t have the answers, but the answer is a quick ChatOps message away.
• Focus on IAM first: The vast majority of cloud-native attacks involve identity and access management (IAM) failures—lost, stolen or exposed credentials. Yes, attackers still compromise vulnerabilities on exposed resources, but we know how to deal with hacked servers and networks. Once the attacker gets their hands on cloud credentials, they effectively break out of the matrix and can rewire your infrastructure. SecOps needs to shift their focus to start with identity-related issues and activities, with playbooks and tools that support them.
• Optimize your Feeds and Speeds: Cloud platforms bring a new range of security telemetry sources. These can be an incredible boon for security due to their broad and deep coverage of nearly all administrative actions, but this does require knowing which feeds to collect, the difference between saved logs and real-time events, when to use which and how to integrate them into tooling without introducing delays that force responders to work with stale data.
• Automate: SecOps should adopt automation to support and speed up their processes. For example, response playbooks can be highly automated to prioritize and filter, enrich data, communicate with the cloud team, run default queries and even automate some containment actions. Humans are still involved in the process; the automation is just there to give them a speed and efficiency boost.

This isn’t an exhaustive list of everything possible. We’ve stayed at a high level, but by understanding the impact of the cloud, you can see how these core capabilities allow a SecOps team to operate more effectively and efficiently. In our next post, we will show you how to adapt your SecOps processes using these core capabilities before our final post details real-world implementation examples.