What does it say about cloud security issues when Zappos—owned by leading cloud provider Amazon—still doesn't place...
critical data in the EC2 environment? According to Saffet Ozdemir, Zappos chief security officer, it doesn't say much about the cloud itself, but rather how unprepared security professionals are to create a cloud security strategy that works for an increasingly complex cloud environment. After all, a cloud security strategy must include new kinds of firewalls that don't introduce latency, and software that provides in-depth monitoring and logging for compliance even in an environment where server instances are constantly shifting.
For Zappos, the solution to the cloud security management challenge has been to very slowly move into a virtual private cloud, using it first for development and backup before moving critical data onto virtual servers. Along the way, Zappos is using host-based distributed firewall management and exposure management tools from CloudPassage—going with what is essentially cloud security as a cloud service. Ozdemir sat down with SearchNetworking.com to discuss the Zappos cloud security strategy.
Can you start by explaining the makeup of the Zappos cloud?
Saffet Ozdemir: We've leveraged virtual private clouds in the EC2 environment. The Zappos usage of the cloud is still in its earlier stages. We're using it more for creative development and also considering it for disaster recovery purposes. We have a number of private clouds for different projects. The creative development and innovative development side of things will have its own virtual cloud, and disaster recovery will have its own.
For all you're doing in the cloud, what did you see as the largest security concern?
Ozdemir: The largest security concern for us was just as mental as it was about actually securing systems. But also, having as much segregation as possible in the cloud environment was critical to us, which is why we went with EC2.
But at least for now, anything that is deemed highly critical or highly confidential, we've decided not to move over. We are looking at having the cloud manage 90% of our business processes and then 10% would be critical data, which we would have in a different environment that we could control.
What's missing in terms of security to trust moving critical data and applications to the cloud?
Ozdemir: It's very new. When there's a new technology or new solution, you see operational teams or development teams very excited and eager to use the new technology, and you will see security teams be frightened. It's a sad state of affairs, but that seems to be a common theme.
The gist of it is that we are trying to reduce risk as much as possible, so whether it's the cloud or different instances in our network, we try to limit what we do with highly sensitive data. A company should not have instances of credit card data or social security numbers in 10 or 15 different instances. It should all be centralized.
More on cloud security strategy approaches
Virtual network security: A vendor comparison
Top 5 cloud security tips of 2011
Top five virtualization problems: Building a private cloud
For me the virtual private cloud is just another instance on our network, but for the same reason I wouldn't want to put my customer's credit card information in multiple data centers that we manage and own; I wouldn't want to necessarily put them on the cloud in multiple instances either.
What are the key elements of securing the cloud?
Ozdemir: I don't conduct cloud security management much differently than I would in an internal network security. We look at four or five fundamental aspects of information security. We focus on network segregation or network control as much as possible. We focus on access control. We ensure compliance and vulnerability management. We verify that the logging and monitoring are in place as well.
Do you have to go with a new kind of firewall strategy?
Ozdemir: The different firewall strategy is that we can't just put in three or four appliances in the cloud. We use local firewalls on the actual server instance. When you create a server in the cloud you are creating one instance. This instance will have a number of applications, tools, software packages and configuration requirements. One of these tools or packages would be CloudPassage, and it would be able to configure and monitor the local firewall on that instance. It actually becomes the HCL local system.
We haven't gotten to the point where we are elaborate or complex in our cloud infrastructure, but think of it in a regular network infrastructure: You have multiple layers. For any application you will have the Web layer, the application services layer and then the database layer, and those are traditionally segregated from a network standpoint.
When we have a VPC (virtual private cloud) with multiple layers, that’s when the firewall aspect will become critical for us. We will be able make each server have particular firewall rules applied. [The challenge] is not so much the ability to create these firewall rules, it's the management of these rules that become more and more critical without the luxury of having an appliance like a Check Point or a Cisco firewall. CloudPassage centrally manages these firewalls [and their separate rules].
What else can you use the CloudPassage's client for?
Ozdemir: It's a centralized solution to address access control and network control, logging and monitoring and auditability and compliance issues. It allows you to centrally manage multiple types of controls and it also provides reporting. Each agent lives on its own server instance in the virtual private cloud, and the management of these agents are provided as a SaaS service managed by CloudPassage.
It can perform our validation of compliance with standards, so we type in a number of security standards into our CloudPassage console and the agent checks the server to see if it's complying with all the standards we set forth.
How does CloudPassage's user management side work?
Ozdemir: It's basic access control. Rivka has group level access to this server and Saffet has secondary level access, and those access types are defined and associated with a particular user.
What's next in terms of using CloudPassage and your cloud security strategy?
Ozdemir: The challenge for CloudPassage and for us is once we've implemented the fundamentals of security, then comes the complexity and the nuances and risks based on business decisions. How do we move forward with that? That's going to be the main area of focus for CloudPassage and everyone else in the next couple of years.
The next step will be to address denial of service in the cloud or IPS or data loss prevention. Are we going to have systems that monitor data leakage? We have these additional things that we care about in a regular network that we'll have to care about in a year or two on the cloud as well.
How is IPS in the cloud different than on a regular network?
Ozdemir: It's not so different. If the CloudPassage agent can monitor incoming traffic, which it has to do for the firewall, at that point it's just a matter of inspecting that traffic with signatures to determine if any of the requests or incoming traffic is malicious. You could also incorporate a third-party solution or consider IPS as a service for the cloud.
I wonder why you would choose to go with cloud security as a service, when you already have some questions about the cloud. Wouldn't it have been more sound to go with a self-managed tool?
Ozdemir: I don't have problems with the cloud; I have problems with our newness to securing instances in the cloud. As far as saying, 'Isn't it kind of weird to have a service on the cloud for the cloud?' I've been asked that question before, and it's not something that we believe is any higher risk issue.