Avoiding Unpleasant Cloud Surprises

For most technologists in the enterprise nowadays, cloud is a pretty big deal — and securing it can be an even bigger deal still. Security was the top concern of 46 percent of respondents to a recent survey by North Bridge Venture Partners (The Future of Cloud Computing). While this number is actually down from last year’s 55 percent, it does underscore the relative importance of security in these efforts.

This is a natural reaction. It is human nature for people to view as more risky what they cannot control directly, an arrangement many cloud efforts require. So despite some recent evidence that service provider environments might not be as problematic as folks have thought (i.e., data from Alert Logic demonstrating a lower threat diversity and lower incident occurrence rates in service provider environments), the fact of the matter is that the proposition is still pretty scary. Recent events like the revelation of the NSA PRISM program haven’t helped in this regard.

Because of this, one reaction from some technology decision makers is to adopt a “no cloud” posture — meaning they’ve attempted to prohibit, disallow or otherwise discourage cloud adoption within their enterprises. While this is an understandable reaction, it’s also one that — as a practical matter — merits some degree of caution. Why? Because the dynamics are such that adoption can sometimes continue, even when specifically disallowed by policy. This can make the situation much worse than it might otherwise be.

Note that this isn’t just as a result of nefarious staffers actively trying to circumvent policy — though in fairness, that sometimes happens too. Instead, it could be as simple as executives bringing it in unknowingly. This can happen, for example, if they don’t recognize a cloud technology as such (i.e., they don’t understand the specific workings of a service they champion) or when existing, already-purchased services “upgrade” to an “as a Service” model.

Whether nefarious or not, the end result is the same: increased risk. As a consequence, therefore, it’s important for technology decision makers to recognize the realities of these adoption patterns — either so they can put ancillary enforcement in place, or so they can decide if there might be other ways to meet the same goals.

‘Surprise’ Cloud Adoption

Looking at adoption dynamics, we already know — most of us from personal experience — that there’s quite a bit of “shadow IT” going on when it comes to cloud adoption. For example, for every cloud initiative known to the CIO, there could be three to six that aren’t, indicated research from Forrester. This could include “as a Service” adoption by business leaders, public Infrastructure as a Service relationships engaged in by developers for testing (small enough to go under the radar), or any number of other scenarios.

This might not be because these folks are actively trying to circumvent the policy. Recall that one of the benefits of cloud (particularly Software as a Service) is to abstract end-users away from the underlying implementation details of the service they’re using. While this can be advantageous — for example, allowing technology changes to happen behind the curtain — it can also mean that a cloud service might go unrecognized as such by non-technical personnel.

Also, business leaders may not understand the definition of “cloud” itself. They might, for example, equate “cloud” only with services like EC2 — and therefore not understand that the new SaaS CRM system they’re deploying is just as much a cloud service as something like Gmail is.

Technical folks can fall victim to similar scenarios. For example, they might not anticipate that a vendor-provided service (historically delivered as an on-premises solution) might have an upgrade path that ends in an “as a Service” deployment model. Lastly, consider that a vendor or partners might also cause “surprise cloud” to happen — like, for example, if one a partner or vendor pushes your data to the cloud as a course of providing its services.

From a practical standpoint, there are a few reasons why this matters. First, because adoption is under the radar, there may not be a feedback mechanism to get security-relevant technical guidance to the adoption team. That is, because there’s not supposed to be any cloud in the first place, there’s nobody evaluating the specific technical and operational ramifications. Second, consider that when there’s a policy specifically prohibiting cloud, any rogue deployment can represent a potential audit or disciplinary issue. When corporate policy isn’t being followed — knowingly or otherwise — it’s not a good situation.

What to Do About It

Now, I’m not saying here that every organization needs to embrace the cloud. There are some very legitimate and practical reasons why your organization might choose not to. Ultimately, the decision should be based on your own risk tolerance, business context and operating principles.

What I’m saying is that if you do decide to adopt a “no fly” posture, you may want to also consider these deployment realities so as to save yourself unexpected headaches down the road. That is, if you do decide that you’re not ready to embrace cloud — and you set a policy that codifies that decision — recognition of these dynamics may cause you to adopt other mechanisms at the same time to help you enforce your choice. In that regard, you have a few options.

You might first choose to establish processes that identify cloud technologies as they arise in new business initiatives. You can do this by working directly with the business — always a good idea — or through courting partners, such as purchasing or internal counsel, to help flag offerings that might violate the policy.

Note, however, that you may need to do some education here to help non-technologists understand what specifically you’re looking for. You might extend that to business partners themselves — for example, by educating them on cloud and the governing policy, so that they don’t unknowingly bring it in.

You might consider altering contract language, employee education efforts, or any number of other internal processes to raise awareness and find problematic areas. Last, you might consider an exception process for situations in which prohibiting cloud actively increases risk — like, for example, if a product upgrade path requires pushing to the cloud. In that case, you might conclude that the sunsetted legacy version represents a greater risk than a one-off “as a Service” deployment — particularly if there’s no sensitive data involved.