Staying Secure in the Cloud-Adoption Aftermath

By now, most organizations have adopted cloud. Increased and widespread adoption as well as expansion of existing deployments are reflected in surveys such as the 2013 Future of Cloud Computing Survey from North Bridge Venture Partners and GigaOm. This suggests that if you’re a technology pro and your organization is like most, you’ve already spent considerable time addressing how to field cloud in a secure way.

As critical as it is to ensure initial secure cloud adoption, it’s important that organizations understand it’s a first step along a longer path. After the push to deploy securely has come and gone, there will still be longer-term activities that remain to ensure that a system stays secure. It’s with this longer “stretch” of maintenance and support that many organizations struggle.

Why the struggle? It’s not hard to understand when viewed in light of business dynamics, which make the short-term adoption push easier than long-term operation vigilance. Consider a typical adoption: It’s easy to prioritize the adoption when business partners are pushing hard to bring the service in and budget requests for due diligence are in the context of projected cost savings overall.

What about longer-term maintenance, though? Instead of business-critical, it approaches business-invisible: The business already has the capability it wanted, so why push? And budget requests? They’re no longer part of a larger cost-reduction strategy, so now they’re additional overhead.

Despite the challenging business dynamics, the maintenance aspects are vitally important to security efforts. If you’re not convinced of that, consider an analogy from traditional IT: fielding a new end-user platform. There are things you probably do at the outset to secure the platform: remove unneeded services; deploy software; patch the OS; etc. What would happen if you did all that and then just walked away? What if you didn’t patch, update software, or monitor the device? That’d be a pretty bad move, right? The same principle applies to cloud.

In point of fact, it can be worse in a cloud deployment, because there are business dynamics in addition to technical ones that make security more challenging to maintain.

Business Dynamics

Now, I want to be clear from the outset that I’m glossing over the maintenance and operation of technical controls that you’ve put in place to support cloud security. It’s not because they’re not important — obviously, they are. I’m not addressing them as thoroughly, though, because they’re less likely to catch security teams unawares. Because those teams were likely instrumental in selecting those controls, the chances of them failing to maintain them appropriately are slim. The business issues, on the other hand, can sneak up on security organizations — particularly when those teams are removed from business activities.

The first issue here is proliferation of services. To see this in action, consider how many organizations adopt cloud: Business teams may engage cloud services under the radar and without assistance from the technology office. This happens more frequently when barriers to engage are low: small — or no — initial financial commitments coupled with instant-on service.

When that happens, deployments tend to start small and grow; the result is multiple cloud deployments filling similar niches. For example, maybe the marketing team has test servers in EC2, while the accounting team independently moved test servers to Rackspace.

From a security standpoint, this redundancy can be painful. Why? Aside from the business issues that can arise — e.g., loss of ability to negotiate volume pricing — redundant instances of overlapping technology increase security overhead. Somebody has to vet those services periodically, track their compliance status, monitor their security profile, etc. As adoption continues, each engagement adds incrementally to the overall resource drag on the security team.

This happens at the same time that usage and context tend to expand over time as well. For example, the accounting team hosting test images at an IaaS? Maybe they decide down the road to host the general ledger there too. An environment that might be vetted for a non-sensitive use today could expand to include more sensitive uses tomorrow. This might not be something business teams think to discuss explicitly with security teams ahead of time but it can absolutely have an impact.

Service Changes

Keep in mind that services themselves are not static. Service providers can and do change their services over time in response to customer demand and in response to market conditions — for example, to control costs.

Many organizations don’t realize that service provider maintenance bulletins, dashboards, and other service notification outlets convey security-relevant information — so it might not occur to security teams to read these bulletins. However, consider what happens if a service provider issues a notice about an outage that impacts a security control or advises that it’s replacing a security control with another one? Would your team know about it? Probably not, if you’re not reading the notifications.

In practice, you’d be surprised how often security organizations aren’t aware of critical security changes because the service provider technical bulletins aren’t on their radar.

Building a Program

Given these issues, the question becomes how security organizations can structure their activities to address post-cloud security hygiene — and the answer isn’t always an easy one. One effective strategy is to build a program specifically around this.

Charter a specific security function focused on keeping cloud deployments secure over the long haul; give that program the mandate to track and monitor which services are in use, how they’re used, and what their security and risk profile is over time. Of course, saying this is often easier than putting it into practice.

Aside from the obvious logistical issues that need to be worked through — budget, structure within the existing hierarchy, etc. — there’s also the practical matter of what that program will need in order to succeed. In that regard, the most critical ingredient is communication: communication with business teams; communication with your existing governance structures; and communication with vendors and service providers.

In terms of input, the program will need information from business areas. Specifically, it needs to know when new cloud services come in, what’s in place already, and how those services are used. Existing business outreach channels — such as business-aligned information security officers — can help gather this information, so make sure there’s a strong working relationship with those folks.

It’s also helpful for them to work closely with the points of contact you’ve established to manage particular vendor relationships — you’ll want them to be in the loop on vendor notifications and service correspondence.

As output, the focus should be on concrete, quantifiable output like operational overhead and risk. The data gathered should tie together cause and effect — for example, “Operational costs have increased because of redundant services in xyz and abc business areas.” Lastly, data gathered needs to be “living” — that is, updated frequently and kept accurate.

The point of all this is that there’s a Step 2 after you’ve embraced cloud. Thinking about it as a longer-term program — rather than as a short-term initiative with a defined end-state — will help ensure that the hard work undertaken during deployment will stay relevant.