How to evaluate, choose and work securely with cloud service providers
A comprehensive collection of articles, videos and more, hand-picked by our editors
Failure to police, or even determine, security lifecycle management practices is a common mistake in cloud provider...
selection, according to John Overbaugh, managing director of security servicesat Caliber Security Partners. Any evaluation should clearly determine a cloud provider's primary and secondary security control and lifecycle management responsibilities.
During Overbaugh's two-decade software security career, he has helped businesses do security assessments of almost 200 cloud providers in software as a service (SaaS), infrastructure as a service, and other Web and cloud service environments. Along the way, he has created a security control matrix for evaluating cloud risks, which he describes in this interview.
Do you see businesses over-estimating the extent of security services cloud providers' offer?
John Overbaugh: One of the big mistakes that companies make when they consider a move to the cloud is this common assumption: 'I'm giving up all control of security.'
Some think, 'I can't handle that.' For them, that's the end of the conversation, and cloud is out of the question.
Other businesses are very eager to take advantage of cloud providing security; [they're] just thinking about how giving up security responsibilities will reduce costs and increase flexibility. Therefore, they're just not very discerning about cloud risks and don't take the time to evaluate the security areas that the provider doesn't cover.
What should businesses evaluating cloud adoption find out about cloud providers' control processes and responsibilities?
Overbaugh: In moving to cloud computing, businesses must determine who has administrative access to each portion of a cloud environment. To do this, I recommend creating a control matrix for evaluating who's going to be able to implement the security control on a given layer. Using an administrative control matrix is the first step that the security team can take to understand where the security controls are going to be in place and what questions are appropriate to ask the cloud provider. The goal is to always be able to determine who has access to your business' cloud site infrastructures and services. Essentially, the matrix is four questions:
- Who administers the infrastructure? That's the logic that ties up to the hypervisor layer, so it's what determines how [random access memory] is distributed, how disc resources might be distributed amongst virtual machines and so forth.
- Who administers the system? This question considers administrative responsibilities for the operating systems on which these platforms are running.
- Who administers the data? Controlling administrative access to data is a critical security factor.
- Who administers the software that's running on these systems? This isn't easy to map out, because most companies run several applications on the cloud.
What secondary security controls should cloud providers use to back up primary security controls?
I've found that many companies take the Easter egg approach to security.
John Overbaugh, Caliber Security Partners
Overbaugh: The concept behind secondary control is that strong security is executed in layers. In my many security evaluations, I've found that many companies take the Easter egg approach to security. There's a firm chocolate outer shell, but once you break through the shell, the inside is a soft, sweet, gooey mass. In other words, there's only that primary shell layer and no real security internally, at the network level. That's insufficient in today's world.
Ask questions about secondary controls that back up primary controls to make sure they've implemented the security in layers. Most monitoring functions are, in general, secondary controls to check that primary controls are in place and functioning well and [to] sound alerts to spur action if the outer shell is breached.
What is an example of a secondary control for cloud security?
Overbaugh: An easy example is the layer of control that follows antivirus measures, and that's change control. Antivirus systems attempt to prevent unauthorized change on a server in a data center. Let's say the antivirus system fails to catch an attack, and a virus or some unauthorized software is loaded and performs a configuration change on the machine. Your change control system, as a backup to antivirus, should be watching and should detect that change and act quickly to stop it. Without change control, the hacker could make an unauthorized change that could provide access to data, interrupt communications and so forth.
So, the change control system is the secondary control system that kind of sits on top of everything and monitors as changes occur.
What are some cloud application lifecycle security risks that can be overlooked in cloud settings?
Overbaugh: Unfortunately, not a lot of customers stop and take the time to ask that question. In a SaaS environment, in particular, application lifecycle management [ALM] is very important. Even though the layers of security control are automated, continual monitoring is needed to make sure access is given only to those whom access has been granted.
There are plenty of ways a cloud customer's data could be compromised if a SaaS provider doesn't have good lifecycle management. The provider could release an application that is full of security vulnerabilities or fail to discover and nullify new threats. A business' security team must ask about ALM controls before choosing a SaaS provider. Will there be ongoing monitoring of the behavior of the application itself and its state? How are upgrades and changes made secure?
Asking these questions allows us to really understand how cloud computing security is implemented to protect cloud applications from a global perspective.
Feedback: Which security gaps and shortcomings have you or your organization uncovered during cloud provider evaluations? Reply to firstname.lastname@example.org. The first U.S. responder gets a $10 Starbucks card.