BT

A Pragmatic Approach to Scaling Security in the Cloud

Posted by Mark Nunnikhoven on Jun 06, 2014 |

Cloud computing is more than just fast self-service of virtual infrastructure. Developers and admins are looking for ways to provision and manage at scale. This InfoQ article is part of a series focused on automation tools and ideas for maintaining dynamic pools of compute resources. You can subscribe to notifications about new articles in the series here.

 

Security. Cloud. Two words that are almost always together but rarely happily.

For years, vendors and consultants rooted in traditional, data center centric world views hollered from the rooftops that the public cloud was a security disaster in the making. Hyperbole reigned supreme and any dramatic turn of phrase that had vague roots in fear, uncertainty, or doubt was touted as the reason you shouldn't be moving to the public cloud.

It's not surprising really. Traditional approaches to information security don't work well in the cloud.

The only way to stem the inevitable migration to the cloud was to ensure that it became canon that the public cloud was insecure. Fortunately, the business drivers for migration are just too strong.

The key to a successful migration is to understand the model behind cloud security and to adopt a cultural willingness to a new way of doing things.

With the high levels of scrutiny that IT organizations are under these days, that can be a tall order. Each high profile breach brings renewed attention. Information security is quickly becoming a regular topic at the board level.

The pressure is on and no one wants to screw up.

The good news is that if you and your security team take the time to understand the model for security in the cloud and then put the right tools, processes, & people in place you can be more secure in the cloud than in your current environment.

Let's take a deeper look at the keys to successful security in the cloud…

Sharing The Responsibility

It all starts with two words, "shared responsibility".

This is the model for security that all cloud1 service2 providers3 operate under. The good news is that it's ridiculously simple to understand.

The challenge with the model is that it will have significant impact on the way your security has to approach their roles. The traditional view of being a gatekeeper or even being in complete control has to go. Toss it out the window.

A modern security practice has to be flexible and understand it's role within the shared responsibility model. With a solid understand of the model and the partnership it implies, you can start to build a dynamic, successful practice.

Notes

  1. Microsoft Azure Trust Center
  2. AWS Security Center
  3. Google's Approach To IT Security

The Model

The model itself is simple. Your cloud provider is responsible for the security of the following areas:

  • facilities
  • physical infrastructure
  • network infrastructure
  • virtualization layer

You are responsible for the security of:

  • the operating system
  • any applications
  • your data

That's it. That's all. A nice, clear division of labour.

This clear line is what makes it possible to increase your security by moving to the public cloud. I've referred to this possibility a few times. The reason it's possible to increase your security posture is because this model immediately removes the half of your security workload.

Think about that for a minute. Your limited resources now only have to cover half of the areas they previous had to cover. With the shared responsibility model you can focus on fewer areas which means you can focus more resources on those tasks. That's a huge win.

Big1 name2 organizations3 have realized this and are now moving sensitive workloads into the cloud. There's no reason that you shouldn't be planning to do the same. Sharing the workload lets you deliver high quality security with the same set of resources you have now.

Don't worry, I won't tell you boss. You can still ask for more budget to cover the migration. But just think of what you could accomplish with that increase now that you only have to focus on half of the work.

Notes

  1. Customer Success. Powered by the AWS Cloud
  2. Companies Using Google Cloud
  3. Customer and Partner Success Stories for Microsoft Azure

Trust But Verify

Of course it's not all unicorns and rainbows. From a security perspective, you can't just assume that everything will work out on the cloud providers side of the model. A little paranoia can be a very healthy thing.

You need to verify that your provider is holding up their end of the deal and providing the security that you expect and rely on.

The good news is that you're not the only client of the provider in this situation and the providers are waking up to this fact. The information your need to verify and validate the provider's claims on security is not something that you–as their client–should have to work to track down. This is why the leaders in the field are adopting a near transparent information sharing policy.

Leading providers have published landing pages or information centers where all of their security and compliance information is posted1. Typically anything you need above and beyond this published information is only a support call away.

Under the shared responsibility model (and good ol' common sense) it's up to you to read through this information and to understand exactly what your provider is doing to security the facilities, physical infrastructure, network infrastructure, and the virtualization layer.

Also key is to understand what tools–if any–that the provider has created to help you secure your areas of responsibility. Have they provides a robust identity and access control framework? Firewall controls for your virtual machines? You need to understand what these features are capable of and how to deploy them properly.

Notes

  1. Leading providers information sharing around security: AWS, Microsoft, and Google

In Practice

Now that you understand the model in theory, you're probably wondering what it looks like in practice. Let's take the example of facing a PCI (payment card industry) audit.

Audit's are about as much fun as they sound but they do an excellent job of highlighting how the shared responsibility model works in practice. If you don't have to be PCI compliant, don't worry. Just substitute your favorite compliance framework and the example still holds.

The PCI framework touches nearly every area of information processing. From the facilities where the data is stored to how information is discarded during processing, compliance requires security controls (process or tools) in all areas of the shared responsibility model.

But as we know, we don't control the security in the facilities, physical infrastructure, network infrastructure, or the virtualization layer. So how do you successfully respond to an audit?

Well an audit response is a shared activity that you lead.

You need your cloud providers help to respond to the audit. You will need validation that their controls are in place and working in order to be successful.

Now you're not the only client of theirs in this situation so it's not surprising that most cloud providers already have 3rd party audit evidence available for their clients to assist in audit response.

Simply open a support request and ask for the appropriate documentation.

Now you can provide that to your auditor and it should satisfy compliance for the areas of provider responsibility. Now you can focus your audit response on the security you've applied to the operating system, applications, and your data.

The audit documentation from your cloud provider is the verification of their side of the model. Add the documentation of the controls you've implemented for the operating system, your applications, how you handle your data, and the processes that you use to manage the whole deployment and you've got your audit response.

That's the shared responsibility model in action and it highlights how migrating to the cloud can simplify compliance.

Shifting Controls

Understanding the overall model is a great first step but it also raises questions along the lines of:

  • "What about my intrusion prevention system?"
  • "How do I monitor my network?"
  • "Can my provider deploy my gateway controls for me?"

When confronted with a new challenge, our instinctive response is to try and map our existing experiences to the new challenge. In this case, trying to figure out how to deploy the same set of security controls in the same manner is a recipe for disaster.

Our previous model of a strong boundary no longer holds water in the cloud.

The Wall

A traditional data center typically has "big iron" controls deployed at each of the interconnects. Anywhere the data center connects to another environment, security is used to create a choke point. At each choke point traffic is analyzed, verified, and either permitted to proceed or dropped. We commonly refer to this design as the "zones" approach and it's worked well for years.

In effect, this creates a strong wall around your data center much like a medieval castle.

Unfortunately when viewed in the context of a cloud deployment, medieval is an accurate description.

Using this approach is the cloud is a recipe for failure. You'll quickly hit performance bottlenecks and be strained to maintain a high level of security in a very dynamic environment.

The irony of the public cloud is that while compute and storage resources are available in abundance, bandwidth is typically scarce. All of the traditional methods of deploying these controls are bandwidth intensive.

Successful security in the cloud moves these same controls to the virtual machine. We move from single, large security controls that protect the entire data centre to controls deployed directly on the virtual machine and responsible for only that virtual machine. This allow the use of much smaller rule sets since the control now has the context in which it's running.

Think of it this way: the traditional method is to have the city guard check everyone at the gate. The guard has to know the business of everyone in the city and then validate whether or not the folks at the gate have a valid reason for being there. By moving that check to the door of the business someone is visiting, it makes it a lot easier for the guard at the door to do more in-depth checks. The guard at the door only has to keep track of the one business, not the entire city.

Moving controls to the virtual machine allows great context which means we can deploy richer policies to each of these controls. That's important in a dynamic environment where changes happen minute-to-minute instead of week-to-week.

Keeping Tabs

To stretch the metaphor a bit, you're probably wondering how the captain of the guard keeps track of which guards are stationed at each business and how well each of them are doing. That's a valid question and one we need to address in order to be successful.

As we migrate to the cloud, we've shifted from a small number of deployed controls (only at the interconnects) to hundreds, thousands, or tends of thousands of controls. This generates two main challenges: deployment, and management.

Deployment

Even in a traditional data center deployment was a challenge. Nobody really enjoys racking a set of boxes that weigh 15–40 Kgs. In the cloud that physical challenge goes away but how can you rapidly deploy a thousand or more applications?

The good news is that this isn't a security problem. This is a general operations problem.

The better news is that your organization has probably already solved the issue. It might be with a solid strategy for "gold" images of virtual machines or on-demand orchestration via tools like Chef or Puppet. One way or another, you need to method of simplifying application deployment in the cloud.

Don't re-invent the wheel. Leverage the existing solution in your organization and use it to deploy the security controls to your virtual machines. This way you only have to prioritize the deployment (security should be the first thing applied to a new machine) instead of creating a new distribution challenge.

Management

That leaves the challenge of managing all of these controls now that they've been deployed. Regardless of security technology, vendor, etc. you absolutely have to have a method of managing these controls from a central location.

Operationally it's not feasible to expect a small team (or even a large one) to manage thousands of controls. Especially when the major of them will be doing the exact same thing. Your security team should be able to view the security of one web server in the same manner as they can view the security of one hundred web servers.

Centralized, automated management is the only logical method of addressing this challenge. That's another shift in the way we think about security controls.

Stronger, Faster

If you understand the shared responsibility model for security in the public cloud, you will be successful and at the very least maintain your current levels of security.

But if you take the time to truly understand not only the model but also the nature of cloud deployments you can easily strengthen your security posture. More importantly you can strengthen your security posture without spending more time or budget.

Computer systems are good at repetitive tasks. Take advantage of this by automating the deployment and management of your security controls. This will let your security team focus on doing in-depth analysis and adding value to your organization.

Imagine if you team was viewed as the key piece that enabled your organization to move to the cloud and modernize it's IT infrastructure. The team that allowed the organization to simplify IT service delivery and really raise the bar on what can be done with modern technology.

Wouldn't that be a nice position to be in?

About the Author

Mark Nunnikhoven, Vice President, Cloud & Emerging Technologies at Trend Micro focuses on helping organizations as they move from the data centre to hybrid environments to working fully in the cloud. Bringing over 15 years of practical experience to the table, he is regularly sought after to speak on cloud computing, usable security systems, and modernizing security practices. He can be reached online and @marknca.

 

Cloud computing is more than just fast self-service of virtual infrastructure. Developers and admins are looking for ways to provision and manage at scale. This InfoQ article is part of a series focused on automation tools and ideas for maintaining dynamic pools of compute resources. You can subscribe to notifications about new articles in the series here.

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

There is a few more issues to address by Lars Nielsen

Hi Mark,

I understand where you are coming from and what you would like to achieve. However, a few practical problems I cannot find a solution for in your article:
- There is no such thing as shared responsibility. A legal entity still owns the task of ensuring legal and regulative compliance. We (at least in Europe) cannot just state Amazon or Microsoft's business model depends on them being secure, so we should trust them
- "Does Microsoft allow customers to audit Azure operations or its data centers? No." - major issue for compliance audits. Trust in a NSA/Snowden/OpenSSL/Truecrypt/American companies regardless of location must comply with handover requests from American authorities world, is not really an option. We need new audit standards if this should be ignored.
- Many types of data are not allowed to be distributed to other countries, e.g., any form of data that can be used to figure out whom/what should be considered as targets during a war. It is not a major problem for US companies as most major cloud providers are located in US, but for european companies it is. Interesting enough, most cloud security articles ignore this fact.

There is of course solutions for anything, but as of now we still have to learn how to love the bomb.

Re: There is a few more issues to address by Mark Nunnikhoven

Lars,

It's definitely more complex then this but the point of this essay was to address the principles that will lead to success in the cloud.

To your specific points:

- there is absolutely such a thing as shared responsibility. Your point of a legal entity still owning legal & regulative compliance is 100% valid BUT it's not the entirety of the argument. It's much more nuanced then that. The basic concept holds true when it comes to designing your approach to security for the cloud

- Microsoft or AWS or other cloud providers might not let _you_ audit their services but they do let reputable international auditors perform the work. They then share those results with customers on request. The alternative you allude to would mean that these services could host a steady parade of auditors, that's not realistic

- geolocation of data is a nightmare to sort out. I don't think anyone's solved this yet. You have the whole transit vs storage, level of awareness, etc. Lot's to shake out here

I like the points you raised and they are valid and relevant. However you can't take an all or nothing view. If you do, you'll never move things forward.

Re: There is a few more issues to address by Lars Nielsen

I agree with cloud is not a white or black question, I just think we need to take the discussion to the next level. For all matters we can not easily change the laws or regulatory standards that are relevant to cloud computing, but we can develop awareness of issues, standard methods and patterns for dealing with issues with trust boundaries. Basically we have to embrace the fact that the enemy have full access to all infrastructure and software that is part of our trust boundary, except for what is located inside our own datacenter. Patterns include segmenting your application software and making sure any sensitive data sent to the cloud is encrypted or cannot be related to any person and such. If we can architect our systems and infrastructure in such a way, then we can allow our self to use the audit reports from Microsoft/Amazon/... that they paid them self for[1].

[1] I will ignore the risk of the auditing company turning the blind eye to issues that might jeopardize a major client buying the services from them again, as it is a general risk for all auditing companies.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT