As more organizations leverage the cloud for critical business applications, they are discovering one of the greatest challenges is combining existing internal controls with cloud protection efforts. Highly regulated business and government organizations in particular must maintain comprehensive security and compliance postures across these hybrid systems. Network World explores the issue in-depth with:
- Shawn Kingsberry, CIO of the Recovery Accountability and Transparency Board
- Craig Sutherland, principle architect and engineer, lead associate, Booz Allen Hamilton
- Mike Rothman, president, Securosis
- Ken Ammon, chief strategy officer, Xceedium
Credit: Stephen Sauer
NW: Let's start with a basic question. When companies are building hybrid clouds, who is responsible for what when it comes to security? What are the pain points as companies strive to address this?
AMMON: I think what you end up with is a shared-security model. The cloud service providers are offering many security capabilities that don't cost anything, that come with the service, and it's in your best interest to take advantage of those capabilities. But you define your compliance requirements and if you can't get the necessary coverage you add your own overlay security architecture.
[ OUTLOOK: Cloud security to be most disruptive technology of 2013
ANALYSIS: Growing confidence in cloud security ]
The challenge, of course, is you have to figure out how to instrument that capability and how to manage it. And of course it makes sense to do this on an enterprisewide basis, so that means developing an architecture that will span X + N cloud providers that will meet your policy and incident response requirements, give you access to the audit data you need, and simplify your implementation of policy across what may be an embedded security service within the cloud providers themselves.
ROTHMAN: A lot of folks think having stuff in the cloud is the same as having it on-premises except you don't see the data center. They think, "I've got remote data centers and that's fine. I'm able to manage my stuff and get the data I need." But at some point these folks are in for a rude awakening in terms of what the true impact of not having control over layer four and down is going to mean in terms of lack of visibility.
So I think people just figure -- "Hey, it's cheaper, but it's more of the same." And they don't take the steps to build a program office and really work through the little details of jurisdiction and incident response and the compliance impact, of not having control over what could be pretty sensitive and critical data.
SUTHERLAND: When deciding who is responsible for controls, the decisions need to take into account the service delivery and deployment model. The Cloud Security Alliance provides some great guidance in this area, and the NIST cloud computing security working group is expanding on these models. Ultimately these responsibilities need to be contractually assigned during the procurement process, and service level agreements alone are not enough if the cloud provider is left with the option of modifying the agreements without warning, as happens on occasion.
But getting back to the original question about the security pain points in the hybrid cloud, I'd add that sometimes when you're looking at new reference architectures and developing a new model for the cloud, some enterprise teams may default to imposing legacy solutions onto a cloud environment, whether its hybrid or just purely public.
And while everyone wants to use solutions they're familiar with, sometimes these controls do not scale for the cloud. In addition, you need to think about the controls at the appropriate level of abstraction and consider and frame it in the context of the risk that the control is really addressing or mitigating. So this means understanding what is new and different in the cloud, and implementing a control that is appropriate for the cloud and allows the benefits of the cloud to be fully realized.
NW: So my first desire is to extend all my legacy controls to this new environment, but, by the sounds of it, I'll always have to bolster these controls for the cloud.
SUTHERLAND: In this cost-sensitive environment you need to start with re-using existing infrastructure, and there's plenty that may be re-used. The point is, just be aware of the nuances and limitations of certain tools.
AMMON: Let's ignore the security controls utilized by the cloud provider below the visibility of the customer, i.e., from the hypervisor to the concrete slab. You are left with three categories of security tools: 1) Tools provided within the cloud such as firewall and VPN; 2) Existing enterprise security tools which operate no different within a cloud environment; and 3) Additional security tools necessary to manage the unique environment presented by the cloud. Here are two examples of new requirements for cloud security tools: First, due to the nature of cloud elasticity, these tools must accommodate an auto-scaling architecture and be able to automatically discover new systems and apply policies. And second is the challenge presented by the advent of the all-powerful cloud API layer. Within the API layer users are implementing the practice of auto configuration ... basically machines building machines. That requires a new security paradigm to manage the unique challenge to auditing and controlling automated machine-to-machine privileged access. This will certainly require new cloud-specific security technology.
NW: Is it different when you're talking about SaaS in particular? Do you just have to take what they give you?
ROTHMAN: Where we've seen a lot of SaaS players open things up a bit is in the area of identity. So instead of having to manage all of these different authoritative sources and user lists, you can get around it through the magic of federation (some suppliers support standards like SAML to provide specific assertions and integration) so you don't have to use the SaaS players' identity model.
But when you start thinking about specific controls and managing access, most of that stuff happens within the auspices of the SaaS provider. So there isn't a lot of flexibility. Salesforce is one company that allows customers to use adjunct technology to encrypt some of the data you store in their environment down at the field level. They acquired a company called Navajo maybe two or three years ago to provide that capability.
But in terms of the continuum of who's responsible for what, when it comes to infrastructure as a service and even platform as a service, the customer is really responsible for pretty much everything that happens on the security side, whereas with SaaS the service provider or the cloud provider actually assumes all responsibility for control sets and auditing and all of those things.
SUTHERLAND: Even in the case of infrastructure providers, the cloud supplier's controls provide the base for any compliance solution, and the shared responsibility model involves selecting appropriate controls above the cloud service or management layer to combine with appropriate user-level controls, whether it's privileged identity management or just host-based and endpoint controls. So this can involve integrating vendor components to address any of your compliance objectives from security or privacy or operational risk, regulatory and legal requirements.
NW: Does the cloud service provider, whether it's SaaS or and IaaS supplier or whatever, want the buyer to assume as much control of the security environment as possible?
SUTHERLAND: It's ultimately the consumer's responsibility. But if you step down from SaaS to platform to infrastructure as a service, the consumer is assigned more of the responsibility. With additional flexibility, you also take on more responsibility for the security controls that are implemented. However, to develop a fully compliant or low-risk solution, you need to implement the user-entity controls, as some cloud providers refer to them, in addition to your own controls above the service layer.
KINGSBERRY: We recently interviewed roughly 30 leaders across industry and the federal government about cloud computing security and built our cloud hub addressing every one of the security issues. We migrated our mail and collaboration into Microsoft 365 as their first GovCloud customer, and in parallel migrated other key infrastructure components over to Amazon. All NetFlow flows through our Recovery Accountability and Transparency Board (RATB) Cloud Hub on-premises, even Microsoft 365 Web mail, meaning if you use Microsoft 365 to send an email it comes back through our cloud hub stack from a compliance perspective. And we have capabilities within our stack like Xceedium that help us manage access control between Microsoft 365 and Amazon.
So, in essence, we have the same level of visibility between software as a service and infrastructure as a service. It's a shared responsibility, but I have auditing and compliance. No Social Security numbers, for example, are going to leave our organization because it gets stopped by Proofpoint. And everything goes through our NetWitness infrastructure and our McAfee Data Loss Prevention. We have categorized the RATB Cloud Hub into six critical services: 1) Governance 2) Protection 3) Access Control 4) Monitoring 5) System Management 6) Failover. Each category has components that play key roles into the delivery of the RATB Cloud Service. Proofpoint, RSA NetWitness, and McAfee Data Loss Prevention Managers are only a few of the components making up our Cloud Hub stack. Now we can put workloads anywhere and it doesn't matter.
NW: Are your federal customers generally asking you to shoulder more responsibility?
KINGSBERRY: If you look at the Federal Data Center Consolidation Initiative, roughly 70% of all federal data centers are already outsourced. So federal CIOs are already having data centers delivered as a service. From a federal standpoint, it's all about the data. The classification of the data is what defines the level of security controls required (e.g., FISMA Low, Moderate and High). I think the federal government is past the point of asking the question, "Can I get the same level of information assurance leveraging cloud services"? Federal understands you can. Securing federal data is a shared responsibility between the federal agency and the provider. Roles and responsibilities will differ between agencies as FISMA is managing risk and each agency's view of risk is different.
NW: As Sutherland mentioned earlier, a lot of this has to be baked into the contract terms. Are there best practices that addresses how?
ROTHMAN: A lot has to do with how much leverage you have with the provider. With the top two or three public cloud providers, there's not going to be a lot of negotiation. Unless you have a whole mess of agencies coming along with you, as in [Kingsberry's] case, you're just a number to these guys. When you deal with smaller, more hungry cloud providers, and this applies to SaaS as well, then you'll have the ability to negotiate some of these contract variables.
So it's a matter of understanding what the agreements specify, understanding who's going to be responsible for what. But I haven't seen a lot of folks be overly successful getting better terms or negotiating special deals or doing any of that kind of stuff because, remember, the cloud and being a cloud provider is all about leverage. So if you've got a different deal for every one of your customers there's no way to really leverage that.
So it's a matter of understanding what you can do, what they're going to do, and looking at it from a threat-modeling standpoint -- we know we're not going to be able to amend the contract to any great deal, so where are our exposures, and what do we have to do to address or mitigate those exposures when making that decision?
KINGSBERRY: When we went to Amazon we were in negotiations for months. We literally had our general counsel talk directly to Amazon and they had to modify their terms or we were not going to migrate. Microsoft as well. We literally restructured the whole agreement. And right when we were at the place of agreeing to all the changes made, Microsoft GovCloud was released. They learned from us what the federal government needed, and then the terms and conditions were rolled into the GovCloud we know today. The government was not going to come in if they didn't remove language about the possibility of our data ending up in third-world countries.
NW: So there is still a lot of learning going on and people on both sides have to be adaptable.
ROTHMAN: It's really early days when you think about the fact that we haven't been through a cycle of litigation and precedent, and that could take years. Until that happens, all this stuff is reasonably academic.
NW: How about the maturity of the cloud security tools themselves? Are they where they need to be?