Expressway on YouTubeWe’re happy to announce general availability of Intel Expressway Cloud Access 360 (ECA 360) 2.0 release. This new release adds a range of exciting new features designed to simplify and improve our customers ability to manage user’s access to popular cloud applications. Key new features and benefits include:
To learn more about the new and improved ECA 360 v2, please visit our web site at www.intel.com/go/identity.
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:
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.
There has been some recent chatter about the lack of strong, proven standards for API authentication when using the REST paradigm. Recent discussions seem to suggest that 2-Legged OAuth2 is the de-facto champion for securing so called lightweight web services based on the REST paradigm.
The trouble is, for all it’s hype, Enterprises looking to secure critical parts of their B2B communication and supply chain tend to view OAuth2 similar to an excited, overanxious know-it-all teenager, one that you just don’t trust quite yet.
In fact, in talking with some of our potential customers the chief complaint is that OAuth2 doesn’t have the same trusted track record as other established standards, most notably SAML. The problem is, SAML has no official binding for REST based API communication and it is often accused of being too heavyweight due to the XML and XML security processing it imposes on applications. What if there was a way to solve both of these problems for the Enterprise?
At Intel, we’ve long believed that XML is the way to go and the use of an XML Gateway decouples the expensive security, parsing, and transformation features from the developer, making things like SAML processing a snap.
About the second problem. We’ve thought about it and came up with a new feature in the latest version of Expressway Service Gateway that solves the binding problem using a simple approach. Rather than start a new OASIS group or other heavyweight process, we’re suggesting that SAML assertions, either holder-of-key or bearer, be encoded using standard base64 encoding into the HTTP Authorization header. Further, in order to provide an adequate security model, SSL is a must as the assertion itself (while it may be signed) will not be cryptographically bound into the header.
The approach is extremely lightweight and will allow any Expressway customer to protect REST APIs using SAML as the required token mechanism. On the client side, the developer still needs to generate an assertion on their own (or use a gateway product like Expressway), but if they are already using SAML as a token for SOAP messages or other purposes, the assertion is likely already available.
Let’s see how it works in the product. There are two sides to this interaction, the client and then the service. On the client side Expressway can act as a client gateway and attach a SAML assertion to a REST call. To do this, We’ve added a new REST security action to the palette.
In the previous picture, we have a new action that will do the work of creating a new SAML assertion and attaching it into the header. The next question is, how do we control the options? For this, the action is connected to a REST security policy. Here, we are specifying that the output is the HTTP Authorization header and choosing SAML holder-of-key. Remember, for the scheme to be secure, the API call must be done over SSL.
The previous two screen shots suggest a way to generate the assertion and attach it to an outbound call. What about processing it on the service side? For this, we’ve rolled the SAML for REST processing into the existing AAA action.
As you can see in the previous screen shot, all that is needed is a AAA step. The mechanics are pretty simple and extra options are available from the AAA policy – shown in the following screen shot.
In the previous screen shot, you can choose how you want to obtain the assertion. For instance, if you are grabbing the SAML assertion from a standard place (such as SOAP header), a workflow variable, or the two SAML for REST options from the HTTP Authorization header.
We’d really like your feedback and comments on this approach. We’ve already heard the requirement from a few large Enterprise customers – please let us know what you think! -Blake
Many pundits say that you must pick a Cloud Provider and trust them. I beg to differ. First off why should we trust the Cloud Provider? A Cloud Consumer wants to leverage the Cloud Provider’s capabilities for functionality and scale where it makes but why should this equate to blind naïve trust? And anyway, what specifically is the Cloud Consumer trusting the Cloud Provider? As the old country music song says, “In God, we trust, all others pay cash.”
Instead of blindly trusting the Cloud provider to do the right thing (and a glance at any recent news will show how hard this is in practice) it makes more sense for the Cloud Consumer, e.g. you, to limit how much control you choose to pass to the Cloud Provider. One technique for accomplishing this is to retain control of User Account Management at the Cloud Consumer site.
When the Cloud Consumer retains the responsibility for User Account Management, the security architecture gains in several ways:
To realize these benefits the Cloud Consumer company must ensure that their local user account information and sessions can be integrated with the Cloud Provider. A starting point for most of these efforts relies on using SAML as a strong, standard based method to integrating Cloud Consumers with Cloud Providers. The Cloud Consumer plays the role of the SAML Identity Provider and the Cloud Provider plays the roles of the SAML Relying Party. This style enables the Cloud Consumer to retain control of the User Accounts and issue standards-based assertions for the Cloud Provider to make run time decisions based on authentication, authorization and attribute sharing scenarios.
Enterprises have demonstrated the desire to explore a wide variety of authentication techniques, driven in some cases by authentication strength and other times by constraints. Below is a list of authentication methods supported in the SAML standard:
First off, holy protocol soup, Batman! What this clearly shows is that authentication remains a moving target. Recent troubles at RSA (http://online.wsj.com/article/SB10001424052702304906004576369990616694366.html) show there is not an end in sight to this trend. Authentication is clearly something that enterprises will continue to iterate on and attempt to improve upon.
As security architects, we should expect authentication technologies to continue to evolve and support a wide variety of techniques. The architecture should insulate the consuming applications like Cloud Providers from this change, and the standard SAML tokens and protocols give us a way to do this.
The enterprise user’s credential, whether 2 Factor, Password, PKI or one of the myriad of other choices is insulated from the integration between the Cloud Consumer and Service provider. This separation of concerns means that changes in authentication technology or in Cloud application should not ripple through the architecture. The separation of authentication concerns from the Cloud creates a pragmatic way to address the enterprise authentication and credential choice locally at the Cloud Consumer.
To enable this separation, the security architect should work on design patterns along the following integration points:
The role of the SAML provider providing access in this case play a dual role crossing the chasm from byzantine enterprise authentication to more open Cloud Providers while not losing the fidelity of the original session.
For further research on how this may apply to your planned Cloud application scenarios, the Dynamic Perimeter site shows a number of real world Use cases and integration examples
http://www.dynamicperimeter.com/products/cloudaccess360
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.
Cloud computing has become an integral part of all IT decision making today across industries and geographies. This market is growing at a rapid pace. By 2014, IDC expects public cloud spending to rise to $29.5 billion growing at 21.6 percent per year. At the same time, Forrester predicts the cloud security market to grow to $1.5 billion by 2015. This is good news, yet there are many CIOs sitting on the fence and not jumping on the opportunity cloud computing presents as they worry about security of data and applications. The figure below lists survey results from top CIOs when asked about their top of mind concern for using cloud services by TechTarget.
Loss of control, Compliance implications, and Confidentiality and auditing topped the results. Under these 3 themes, the issues they listed are:
• They find it hard to trust cloud providers security model
• Manage proliferation of user accounts across cloud application providers
• Extended enterprise boundary complicates compliance
• Shared infrastructure, if the cloud gets hacked so do you
• Audit log silos on proprietary cloud platforms
This blog post lists a potential solution to address these issues and more.
Security Layers
First, lets look at the various layers that are required to secure cloud applications and data.
You need to protect applications and data for assurance and compliance, access control, and defend against malicious attacks at the perimeter. Yet, the weakest link remains the client as malware and phishing attacks can send requests as if it were coming from a human user. To achieve end-to-end security, you need to look holistically at how to provide “trusted client to cloud access”. You can watch a webinar on this topic I recently did with security expert Gunnar Peterson.
Solution
One solution to this problem is to have a trusted broker that provides the glue between client security and cloud security. It should be able to determine if cloud applications are being accessed from trusted and attested client devices or not, and block access from all non-trusted clients. One way to get client attestation is through Intel® Identity Protection Technology (IPT) which embeds 2nd factor authentication in the processor itself.
While a trusted broker enforces above check it should also be able to provide supplemental security on top of what cloud applications provide by offering:
Such a “Trusted Broker” software can insure that Enterprises adopt cloud applications providing tools to achieve “Control, Visibility, and Compliance” when accessing cloud applications. View more on Intel’s solutions in this space.
Industry initiatives
Cloud Security Alliance (CSA) is working feverishly to provide awareness and guidance with reference implementations to address some of the security concerns listed earlier in this blog post. At the CSA summit 2011 held at RSA conference 2011, I presented a roadmap for Trusted Cloud Initiative (TCI) which is one of the sub groups of CSA. In it’s reference architecture, TCI lists the following use cases for trusted access to the cloud.
TCI also published a whitepaper covering identity and access control for cloud applications.
Summary
While cloud application providers continue to enhance their security posture, it’s in the best interest of enterprises to supplement it with additional security controls using technologies such as “Trusted Broker” that enable end-to-end secure client to cloud access and provide 360 degree visibility and compliance into how various cloud applications are being accessed by enterprise users. One such implementation of a “Trusted Broker” is provided by Intel Expressway Cloud Access 360 product. Visit http://www.dynamicperimeter.com to learn more.
 |
Vikas Jain, Director of Product Management for Application Security and Identity Products with Intel Corporation has over 16 years experience in the software and services market, with particular expertise in cloud security, identity and access management, and application architecture. Prior to joining Intel, Vikas has held leadership roles in product management and software development at a wide-range of technology companies including Oracle, Oblix, Wipro and Infosys. You can follow him on twitter @ VikasJainTweet
|
The Intel Cloud Builder program has launched a forum and discussion board today. I am not sure if you have seen it yet, but there is a great paper that outlines a number of cloud security use cases built around Intel(R) SOA Expressway. Grab the paper entitled “Intel® Cloud Builders Guide: Cloud Design and Deployment on Intel® Platforms.”
The paper shows how Expressway can be used as a control point for some interesting use use cases: (i) As a secure proxy for auditable virtual machine controls, (ii) single sign-on using an on-premise STS to map internal credentials to SAML assertions for a payroll application and (iii) secure credential federation for a hybrid cloud environment in a cloudburst scenario. The paper has a lot of detailed information on what some of these applications might actually look like once deployed on Expressway. You can request an evaluation copy of Intel(R) SOA Expressway at the dynamic perimeter microsite, located here.
