Suppose you’re throwing a party at your office (to celebrate your success with deploying cloud security at your organization). Word has gotten out… a bit more than you expected. Too many people are coming, and many of them aren't even employees or clients. Things could easily get out of hand. But you can’t cancel the party, or it will look like your company is having trouble. You start thinking about, well… security.
Unpredictability makes security harder
You just can’t know for sure what will happen. You think about hiring someone to help you. What kind of guardian do you need? Someone intimidating? Good at combat? Maybe just someone with a nose for finding troublemakers?
I’m reminded of Roadhouse, the 80s B-movie classic starring Patrick Swayze as Dalton, a midwestern bar bouncer, who is also some kind of Zen master. As he’s explaining to his underlings how to behave, he says:
“I want you to be nice. Until I tell you it’s time not to be nice.”
One of his minions asks: “How are we supposed to know when that is?”
In a moment of sublime understatement, Dalton responds: “I’ll tell you.”
From that moment on, the audience waits for Dalton to give the signal to stop being nice.
Check out the white paper: Cloud security architecture - from process to deployment
Smart cloud security means constant re-evaluation
Many heroes are tough, but what makes Dalton special is his restraint, his sense of timing and proportion. Knowing that he has this, business owners trust him to protect their assets.
Dalton was a great bouncer, but he missed his calling. He should have been a cloud computing security expert. That’s because he understood that smart security is a process involving constant re-evaluation.
Components of dynamic cloud security
Consider the components of dynamic tavern (and cloud) security:
- Risk insight: Decide what’s at stake, and how far you’re willing to go to protect it.
- Build and deploy: Stock up on padlocks, crowbars, and headlight shields.
- Operate and control: Watch the dance floor. Chat with the customers. Will this be a quiet night, or not?
- Predict and learn: Find out the name of the dodgy guy who just walked in. But don’t let it distract you from the argument over by the pool table.
- Comply: Enforce the rules. (In cloud computing, we say “comply” rather than “enforce” because the rules are enforced automatically.)
- Trust: Using your allies, tools, and abilities, embark on a constant process of situational assessment, risk evaluation, and tactical reconfiguration.
Multi-tenancy in cloud computing
Back to the party analogy. But this time, it’s an office building party. Your company shares a cafeteria, conference rooms, and bathrooms with a bunch of other tenants. Some of your neighbors are business partners. Others are competitors. But there is no doubt about it: the party is better with your neighbors involved. They share the burden of space, provisions, electricity, climate control, even security.
In cloud computing (and in office buildings), sharing space in ways that are beneficial but not always comfortable is called multi-tenancy. Now, whose responsibility is it to make sure no one gets hurt at this party, and that nothing gets damaged? Partly the various tenants (cloud consumers), partly the landlord (cloud service provider), partly the contractor (infrastructure service provider). And part of the responsibility will also fall on the actual partygoer (end user). The formal agreement that distributes this responsibility is the SLA (service level agreement), and the amount of fun (and safety) that is guaranteed to be had is the QoS (Quality of Service).
Keeping order with SLAs
Back when I was at a startup, we used to say that a client appreciation party wasn’t successful unless building security stopped by to see if everything was all right. In other words, we wanted an indicator that we were getting so much value out of the space for which we were paying, that the managers of the space had to check in to be sure we weren't getting too much use out of it. In cloud computing, this is like a tenant (cloud consumer) who attempts to use more than his maximum allocated bandwidth, or storage space, or processing time. But if the SLA is properly written and executed, that’s just not possible. (Imagine a client advisory board (CAB) awards ceremony in which the maximum decibel level of the microphone is magically prevented from exceeding a certain threshold.)
On the other hand, what if everyone else who works in the building has left for the day? Or what if they're all at the party? Or, in cloud terms, what if only one tenant in a multi-tenant environment is asking for a set of shared resources? Then they should get them (as long as it falls within the SLA).
Scaling security in the cloud
So what happens to security in this situation? It scales up with the party. It has to. For example: The party is only moderately crowded, but suddenly, at 2am, 500 more people show up. Did they come to congratulate you on the launch of your great new product, and they just couldn't get away earlier? Or is something sinister afoot? In computing, this is like trying to tell the difference between a sudden spike in your web traffic, and a distributed denial of service attack (DDoS).
All of this is to say that security in the cloud is dynamic. The mechanisms that enforce the SLA react to the context of a specific situation. But the humans who make decisions about security policy -- whether to use a private, public, or hybrid cloud; where to find the balance between provider security controls and tenant security controls, and how the security operations center (SOC) will orchestrate various other security functions and policies -- make use of a set of dynamic paradigms for flexible security decision-making that together can be called the trust engine.