For any technology, it’s important to understand what problems it’s meant to address. In the last post we looked at Cloud Security Anti-Patterns. An Anti-Pattern represents an ineffective or counterproductive practice. In moving to the Cloud several Anti-Patterns have emerged that enterprises should be on the look out for and Identity architecture goals to address these issues for Cloud applications. Enterprises moving to the Cloud should identify if they have Anti-Patterns summarized in the following table and seek to mitigate:
Enterprises moving to the Cloud must avoid the Cloud Security Anti-Patterns. Luckily there are a set of open standards to use in this endeavor. Unfortunately, for enterprises there are many standards to choose from and it can be difficult at first to decipher what standards are addressing which problem set.
SAML, OAUTH, OpenId, and XACML are widely regarded by Cloud Security Alliance, Cloud providers, and the tech community as a whole as key building blocks to the Cloud. In each case, these standards have a unique value proposition towards addressing the Cloud Security Anti-Patterns.
Low/no access control – “we’ll see if it works and then turn on security later” This mindset is not limited to Cloud applications, its been around since the dawn of IT, but its at the root of many of thorniest issues in security. When security is not factored into the design at the beginning stages its very, very complicated to add it in later.
Home builders will often run wires and pipes inside walls of the homes they are building, leaving stubs where sinks, appliances and electric outlets can be added later. After all, who wants to rip up their walls just to add a new electric outlet?
Enterprises moving to the Cloud must look for strong access control protocols that enable:
- Tamper proof credentials
- Encrypting sensitive data
- Secure attribute exchange
- End to end authentication
Cloud security standards like SAML, OAUTH, OpenId, and XACML enable enterprises to move their applications and data to the Cloud while still implementing an access control regime that meets policy goals around enterprise control as described above.
Like deciding where the sinks should go while building out your houses’ foundation – with all the choices in identity standard, it can be difficult to know which one enterprises should implement. What’s important is to choose a Identity standards for you applications that are designed for newer Cloud applications because low and now access control leaves too many holes.
Replicating user accounts – copying in full or an extract your Enterprise directory to the Cloud provider. There are several security and compliance nightmares at work here. The Enterprise directory’s purpose in life is for the Enterprise to manage its user accounts, provision, deprovision, and assign group and role membership so that the business runs efficiently. Adding points of administration is a proven way to make this process less efficient and more error prone.
Of course, the problem with Replicating user accounts to the Cloud is immediately clear for most security architects, but the solutions can seem more elusive. The solution in this case requires that the Enterprise Directory stays under Enterprise control and management while still allowing for fine grained access control decisions on the Cloud Provider side. The challenge then is to facilitate the movement of identity information from the Enterprise-controlled User directory and give the Cloud provider applications the attributes they need to make authorization decisions. Oh, and your users would probably like Single Sign On (SSO) as well.
This is where standards like SAML provide a lot of value. Enterprises using SAML designate their Enterprise Directory as the Identity provider and the Cloud Service Provider consumes identity information as needed from the enterprise directory. The key distinction here is that the Cloud provider doesn’t manage the identity information. SAML profiles provide the standard protocols that enable applications to provide Single Sign On user experience and securely exchange attributes. This means the Cloud provider can make access control decisions based on identity information in the Enterprise directory without owning the management (and risk) of that directory.
Copying credentials – sometimes Enterprise copy credentials to Cloud based services; and thereby create a new pool of identity risk to manage. Related to the previous Replicating User Account Anti-Pattern, sometimes Enterprises will seek a temporary work around for Cloud Applications by copying credentials like system accounts and passwords that enable a magical, back door access to certain apps or data. Like all magic, its fun for a kids’ party trick, but not for running a business on.
Enterprises using Cloud application should focus on getting the benefits of the Cloud – scale, distribution, cost savings – but not confuse those benefits with a system that should be trusted with enterprise secrets. Credentials should remain under direct enterprise governance. Copying credentials like passwords to the Cloud Provider simply introduces too much risk where the credentials can be used to effect changes to enterprise accounts and systems.
As with the Replicating User Accounts Anti-Patterns, Enterprises should seek to enforce a separation with Identity Management (owned on the Enterprise side) versus Identity Consumption (owned on the Cloud Provider side) through standards like SAML, OpenID and oauth.
“Trusted” proxy – where trust is in name only As we discussed in Part 1, the first step to dealing with Cloud Security Anti-Patterns is deploying a Policy Enforcement Point to give the Information Security team a place to implement controls that avoid the Anti-Patterns and enable more robust security architecture. There is not a magic “pizza box” that you can simply route your Cloud traffic through to get the kind of security Cloud applications need.
The Proxy or Gateway that you select for mediating the communications to your Cloud provider(s) should be selected based on its support for identity and access standards, monitoring visibility, and ease of integration. The Cloud Security Alliance (https://cloudsecurityalliance.org/) guidelines provide a robust starting point for planning for these capabilities; these should be factored in from the very first Cloud deployment for your enterprise.
Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and federal/Gov systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at http://1raindrop.typepad.com.
