My colleague Doug Cahill and I have been following the development of cloud security for the past few years. What we’ve noticed is that many organizations tend to track through a pattern of actions as their organization embraces public cloud computing. The sequence goes through the following order:
1. The pushback phase. During this period, CISOs resist cloud computing, claiming that workloads won’t be adequately protected in the public cloud. This behavior may still occur for late-comers or very conservative firms but the cloud computing ship has definitely sailed at most large enterprises. In other words, CISOs aren’t given an out clause--rather, they must figure out how to secure cloud-based workloads whether they like it or not.
2. The traditional security phase. When organizations toe-dip with public cloud computing, security teams tend to try and secure cloud-based workloads using the same security monitoring and enforcement tools they use internally – firewalls, proxies, AV software, network analytics, etc. According to ESG research from 2016, 92% of enterprise organizations use their existing security tools for cloud security to some extent. The problem here is obvious – traditional security technologies were designed for physical devices, on-premises logs, system-centric software, and ingress/egress network traffic, rather than the ephemeral constructs of public cloud computing. This mismatch generally results in outright failure – 32% of enterprises have abandoned traditional security technologies because they couldn’t be used effectively for cloud security.
3. The cloud monitoring phase. Once organizations move beyond cloud security experiments with existing controls, they tend to retreat and embrace that old management maxim, ‘you can’t manage what you can’t measure.’ During this phase, security teams deploy monitoring tools to get a complete picture of cloud-based applications, data, and workloads, as well as the connections amongst all cloud-based assets. This can be quite enlightening, as few organizations have a clear, concise, and complete understanding on what’s running in the cloud at all.
4. The cloud affinity phase. Armed with a map of all cloud-based assets, smart security teams make sure that further security actions align with cloud computing “owners” – software developers, DevOps staff, and data center operations. The goal? Coordinate security technologies with development models, provisioning, and orchestration tools like Chef and Puppet so security can keep up with the pace and dynamic nature of cloud computing. Note that this phase is a bit of a detour from pure cloud security monitoring and policy enforcement but leading organizations claim it is a worthwhile diversion for establishing collaboration and security best practices.
5. The cloud security controls phase. Security groups then work with cloud developers and operations in order to include security controls into provisioning and operations. Security tends to start with workload segmentation and move on to more advanced controls (host-based security, threat detection, deception, etc.). It is worth noting that some innovative cloud security tools are bridging the controls phase and the monitoring phase. They monitor the cloud, profile all assets, and then suggest policies based upon application type, data sensitivity, or logical connections. This bridge can really help accelerate cloud security policy management.
6. The central policy phase. We’ve only seen this from leading edge organizations but it’s likely a sign of things to come. Once organizations get accustomed to the flexibility and dynamic nature of software-defined cloud security technologies, they move on to:
a. Aggregating cloud security tools. For example, they may choose one tool (rather than two specialty tools) for micro-segmentation and host-based controls. This reduces complexity and provides central policy and control.
b. Replace traditional tools with software-defined tools. For example, we’ve seen organizations abandon traditional firewalls within data centers in favor of software-defined micro-segmentation tools. This strategy can lead to millions of dollars in capital cost savings while centralizing all segmentation policies. I’ve seen a few enterprise network segmentation projects with the goal of using software-defined micro-segmentation to replace firewall rules, switch-based ACLs, etc. Ambitious? Yes, but successful projects could simplify security operations and save lots of dough.
A few final pointers based upon what we’ve learned: Enterprise organizations would be wise to avoid dead ends and skip directly to phase 3. This could save months of frustration and help security teams catch up to cloud owners quickly. For technology providers, the goal should be a consolidated cloud security technology portfolio with strong, enterprise-class central management capabilities.
Jon Oltsik is an ESG senior principal analyst and the founder of the firm’s cybersecurity service. Read more ESG blogs here.
