Cloud Security Takes More Than Superficial Teamwork

Teamwork is important. We all know this to be the case whenever we do anything in a group involving other people. But arbitrary — even directionless — teamwork doesn’t make success by itself, no matter what the motivational poster might tell you. There are different kinds of teamwork.

Consider, for example, the difference between a three-legged race and a relay race. In both cases, teamwork defines success — victory or defeat is directly decided by how well the individuals can work together cooperatively. But there’s a crucial difference between the dynamics of the teamwork involved in those two cases: While a three-legged race limits the team as a whole to the performance of the weakest team member, the relay race combines strengths of each team member cumulatively. In other words, tie an Olympic sprinter to a couch potato and you get a slow-running team (no matter how many gold medals the sprinter has won in the past). Take that same team and make it a relay? Well, you might still be competitive (depending on who the competition is).

In the first case, the weakness of the slower runner limits them both; in the second case, the strength of the faster runner makes up for the slower one.

Which Kind of Cooperation Do You Need?

There’s a lesson here for those of us working to secure cloud-based services. In a cloud model, there’s no question that security tasks need to be performed cooperatively. Because a cloud service can span multiple environments, different sets of personnel — in most cloud models, at multiple companies — need to jointly operate controls and coordinate efforts.

Take, for example, trying to trace a given security event to its source over multiple systems. You might need application logs from a SaaS provider, OS logs from an IaaS provider, and logs from internal systems the client organization maintains. Joint effort — teamwork — is required to do this without stepping on each other’s toes.

But as in the racing examples, different types of cooperation apply in the cloud world too. Models that just “glue” existing security measures (processes and controls) together are like the three-legged race. The weakest set of process or control measures, be they on the vendor or the customer side of the equation, can limit the security of the overall system. Unfortunately, this is where most cloud arrangements tend to start, and it undermines one of the key promises of the cloud: Namely, that leveraging economies of scale benefits everyone over the long term.

So how can deliver on that promise? How can we move to the different model that leverages both vendor and customer strengths rather than locking them both into inheriting the weaker paradigm? To start with, it requires embracing some new (and potentially scary) ways of thinking about security — ways that might run contrary to how we’ve approached security in the past.

Principle 1: Delegate

When it comes to securing a cloud environment, organizations can find themselves in a scary place. On the one hand, they retain liability for breaches, hacks, etc. Who takes the public image “hit” of showing up in the papers if something gets hacked? The customer does. So an organization moving to the cloud rightly needs to consider where that liability lies and protect themselves accordingly. But at the same time that they retain liability, they also need to be able to delegate responsibility in order to ensure security controls operate effectively.

Why is delegation important? Because the vendor is the party best equipped to be the “eyes and ears” when it comes to control implementation. This is because they are closest to the asset, and also because they can potentially have economies of scale. In other words, not only are they likely to be the first to know about anomalous conditions that impact an asset (such as malware, DDoS, and other attacks), but also that they can (and should) maintain specialized niche personnel who are in a position to respond to those situations. The vendor will, quite likely, be your “first responder” — so assigning them room to operate (within, of course, structured and defined boundaries) can have a real payoff.

Principle 2: Data Sharing

Also, in order for control operation to be effective, organizations need to make sure that the vendor has sufficient information about the environment to keep data safeguarded and to plan accordingly. The vendor should be maintaining expertise in cloud-specific security architecture considerations and also should best understand the nuances of their own environment. So they need to understand role, sensitivity, and criticality of the systems they’re maintaining.

But it’s the customer organization and not the vendor’s that has the institutional knowledge required to do this — where security controls are, mitigating controls put in place based where there are areas of risk exist, compensating controls, data sensitivity and regulatory context. But data-sharing — particularly sharing the intimate details of this type of security-sensitive data — does not come naturally to many security organizations. Let’s face it: A philosophy of openness isn’t something usually a part of the established security traditional wisdom.

To the contrary, many organizations espouse the belief that specific details of security controls, as well as areas of operational risk, should be kept out of public view to avoid an attacker from capitalizing on that information. But in a cloud relationship, it de facto limits the ability of both parties to operate a maximum potential.

It may not be the most comfortable thing for security organizations to accept, but working most effectively with a cloud provider requires a level of trust over and above what that organization has with other third parties. Understandably, this level of trust isn’t easy to come by — and quite frankly, not every vendor warrants it.

Trust’n’Verify

So successful strategies in the cloud will both trust and verify. To verify that delegated security responsibilities are being performed appropriately, document who is responsible for what and establish a feedback loop to make sure those responsibilities are being taken seriously. It is important here to make sure there is no ambiguity with respect to responsibility. If there is an application issue, can your vendor deploy a patch? Should they? You need to decide this ahead of time and give your vendor a framework within which to work.

You also need some way to measure activity so that you can have confidence that appropriate action is being taken. Is your vendor responsible for patching? Establish a process to check for missing patches on those assets to make sure the job is getting done according to expectations. Let your vendor do what they are (supposed to be) good at, but keep an ear to the ground to make sure they’re not dropping the ball. If your vendor is worthy of your trust, measuring their performance can open up the true value of cloud by moving to a mutual-trust level of operations; if your vendor is unworthy, at least you’ll know it so you can start looking out for someone else who is.