12 Ways Cloud Upended IT Security (And What You Can Do About It)

This article was originally published on Fugue's blog here.

By Andrew Wright, Co-founder & Vice President of Communications, Fugue

The cloud represents the most disruptive trend in enterprise IT over the past decade, and security teams have not escaped turmoil during the transition. It’s understandable for security professionals to feel like they’ve lost some control in the cloud and feel frustrated while attempting to get a handle on the cloud “chaos” in order to secure it from modern threats.

Here, we take a look at the ways cloud has disrupted security, with insights into how security teams can take advantage of these changes and succeed in their critical mission to keep data secure.

1. The cloud relieves security of some big responsibilities

Organizations liberate themselves from the burdens of acquiring and maintaining physical IT infrastructure when they adopt cloud, and this means security is no longer responsible for the security of physical infrastructure. The Shared Security Model of Cloud dictates that Cloud Service Providers (CSPs) such as AWS and Azure are responsible for the security of the physical infrastructure. CSP customers (that’s you!) are responsible for the secure use of cloud resources. There’s a lot of misunderstanding out there about the Shared Responsibility Model however, and that brings risk.

2. In the cloud, developers make their own infrastructure decisions

Cloud resources are available on-demand via Application Programming Interfaces (APIs). Because the cloud is self-service, developers move fast, sidestepping traditional security gatekeepers. When developers spin up cloud environments for their applications, they’re configuring the security of their infrastructure. And developers can make mistakes, including critical cloud resource misconfigurations and compliance policy violations.

3. And developers change those decisions constantly

Organizations can innovate faster in the cloud than they ever could in the datacenter. Continuous Integration and Continuous Deployment (CI/CD) means continuous change to cloud environments. And it’s easy for developers to change infrastructure configurations to perform tasks like getting logs from an instance or troubleshoot an issue. So, even if they got the security of their cloud infrastructure is correct on day one, a misconfiguration vulnerability may have been introduced on day two (or hour two).

4. The cloud is programmable and can be automated

Because cloud resources can be created, modified, and destroyed via APIs, developers have ditched web-based cloud “consoles” and taken to programming their cloud resources using infrastructure-as-code tools like AWS CloudFormation and Hashicorp Terraform. Massive cloud environments can be predefined, deployed on-demand, and updated at will--programmatically and with automation. These infrastructure configuration files include the security-related configurations for critical resources.

5. There’s more kinds of infrastructure in the cloud to secure

In certain respects, security in the datacenter is easier to manage. You have your network, firewalls, and servers on racks. The cloud has those too, in virtualized form. But the cloud also produced a flurry of new kinds of infrastructure resources, like serverless and containers. AWS alone has introduced hundreds of new kinds of services over the past few years. Even familiar things like networks and firewalls operate in unfamiliar ways in the cloud. All require new and different security postures.

6. There’s also more infrastructure in the cloud to secure

There’s simply more cloud infrastructure resources to track and secure, and due to the elastic nature of cloud, “more” varies by the minute. Teams operating at scale in the cloud may be managing a dozens of environments across multiple regions and accounts, and each may involve tens of thousands of resources that are individually configured and accessible via APIs. These resources interact with each other and require their own identity and access control (IAM) permissions. Microservice architectures compound this problem.

7. Cloud security is all about configuration—and misconfiguration

Cloud operations is all about the configuration of cloud resources, including security-sensitive resources such as networks, security groups, and access policies for databases and object storage. Without physical infrastructure to concern yourself with, security focus shifts to the configuration of cloud resources to make sure they’re correct on day one, and that they stay that way on day two and beyond.

8. Cloud security is also all about identity

In the cloud, many services connect to each other via API calls, requiring identity management for security rather than IP based network rules, firewalls, etc. For instance, a connection from a Lambda to an S3 bucket is accomplished using a policy attached to a role that the Lambda takes on—its service identity. Identity and Access Management (IAM) and similar services are complex and feature rich, and it’s easy to be overly permissive just to get things to work. And since these cloud services are created and managed with configuration, see #7.

9. The nature of threats to cloud are different

Bad actors use code and automation to find vulnerabilities in your cloud environment and exploit them, and automated threats will always outrun manual or semi-manual defenses. Your cloud security must be resilient against modern threats, which means they must cover all critical resources and policies, and recover from any misconfiguration of those resources automatically, without human involvement. The key metric here is Mean Time to Remediation (MTTR) for critical cloud misconfiguration. If yours is measured in hours, days, or (gasp!) weeks, you’ve got work to do.

10. Datacenter security doesn’t work in the cloud

By now, you’ve probably concluded that many of the security tools that worked in the datacenter aren’t of much use in the cloud. This doesn’t mean you need to ditch everything you’ve been using, but learn which still apply and which are obsolete. For instance, application security still matters, but network monitoring tools that rely on spans or taps to inspect traffic don’t because CSPs don't provide direct network access. The primary security gap you need to fill is concerned with cloud resource configuration.

11. Security can be easier and more effective in the cloud

You’re probably ready for some good news. Because the cloud is programmable and can be automated, the security of your cloud is also programmable and can be automated. This means cloud security can be easier and more effective than it ever could be in the datacenter. In the midst of all this cloud chaos lies opportunity!

Monitoring for misconfiguration and drift from your provisioned baseline can be fully automated, and you can employ self-healing infrastructure for your critical resources to protect sensitive data. And before infrastructure is provisioned or updated, you can run automated tests to validate that infrastructure-as-code complies with your enterprise security policies, just like you do to secure your application code. This lets developers know earlier on if there are problems that need to be fixed, and it ultimately helps them move faster and keep innovating.

12. Compliance can also be easier and more effective in the cloud

There’s good news for compliance analysts as well. Traditional manual audits of cloud environments can be incredibly costly, error-prone, and time-consuming, and they’re usually obsolete before they’re completed. Because the cloud is programmable and can be automated, compliance scanning and reporting can be as well. It’s now possible to automate compliance audits and generate reports on a regular basis without investing a lot of time and resources. Because cloud environments change so frequently, a gap between audits that’s longer than a day is probably too long.

Where to start with cloud security

1. Learn what your developers are doing.
   What cloud environments are they using, and how are they separating concerns by account (i.e. dev, test, prod)? What provisioning and CI/CD tools are they using? Are they currently using any security tools? The answers to these questions will help you develop a cloud security roadmap and identify ideal areas to focus.
2. Apply a compliance framework to an existing environment.
   Identify violations and then work with your developers to bring it into compliance. If you aren’t subject to a compliance regime like HIPAA, GDPR, NIST 800-53, or PCI, then adopt the CIS Benchmark. Cloud providers like AWS and Azure have adapted it to their cloud platforms to help remove guesswork on how they apply to what your organization is doing.
3. Identify critical resources and establish good configuration baselines.
   Don’t let the forest cause you to lose sight of the really important trees. Work with your developers to identify cloud resources that contain critical data, and establish secure configuration baselines for them (along with related resources like networks and security groups). Start detecting configuration drift for these and consider automated remediation solutions to prevent misconfiguration from leading to an incident.
4. Help developers be more secure in their work.
   Embrace a “Shift Left” mentality by working with developers to bake in security earlier in the software development lifecycle (SLDC). DevSecOps approaches such as automated policy checks during development exist to help keep innovation moving fast by eliminating slow, manual security and compliance processes.

The key to an effective and resilient cloud security posture is close collaboration with your development and operations teams to get everyone on the same page and talking the same language. In the cloud, security can’t operate as a stand-alone function.

Read more industry insights from the team at Fugue here!