Gunnar Peterson on Understanding Cloud Security Standards, part 3

Moving applications to the Cloud puts many enterprises in an accustomed position, the technology and processes that their business depends on aren’t under their sole control, but rather a mix of responsibilities. The move to the Cloud is not a simple “forklift” migration where bits are copied to a Cloud Provider, instead the architecture and assumptions must be reviewed and refreshed to meet the needs and constraints of Cloud systems.

Implementing authorization services with standards like XACML empowers the security architect to enforce policy via a Gateway and answer the authorization queries from the source with the freshest and most specific data. Often the information needed to resolve authorization requests is stored beyond the directory and only available in a database or other repository.

The Cloud presents real integration challenges to the enterprise, what Gartner calls Cloudstreams and Cloud Service Brokerages focus on “integration, governance, and security impact points.”

In Part 1, we examined four Anti-Patterns that enterprises should avoid as they move the Cloud. These four Anti-Patterns are at the heart of dealing with the “Complexity Kills” problem that Gartner’s research shows as a recurring theme in Cloud migrations.

Anti-Pattern	Description	Mitigations
Low/No Access Control	“we’ll see if it works and then turn on security later”	Strong access control protocols for authentication and authorization
Replicating User Accounts	copying in full or an extract your Enterprise directory to the Cloud Provider	Retain enterprise provisioning on Cloud Consumer side
Copying Credentials	Copying Enterprise Access Credentials to Cloud based services	Implement Federated Identity
“Trusted” Proxy	Gateway lacks support security services and standards	Implement improved access control, audit logging and monitoring on the Gateway

In Part 2, we looked at how open standards like SAML, Oauth, and OpenID can be used to mitigate the Anti-Patterns, when it comes to fine grained authorization and Attribute based Access Control that many Cloud applications require, standards like these are necessary but not sufficient for the overall identity architecture.

The old enterprise perimeter was based on network firewalls, but today applications are integrated, distributed via Cloud and consumed via Mobile apps. The network firewall is severely limited in this context. Fine grained authorization and Attribute Based Access Control help close out the gaps in Cloud Security by providing a Dynamic Perimeter that manages access control across these contexts.

Today’s reality is that users, systems and data are distributed. The genie is not going to be put back in the box, but access control policy enforcement can and should be centralized.

Centralizing access control policy enforcement is essential for:

• For Security architects to understand the boundaries in the system,
• For developers to know what and where to code for authorization operations
• For auditors to be able to review
• For testers to be able to identify vulnerabilities

Gateways are ideal for providing the Policy Enforcement Point function, to intercept requests before they reach the resource and ensure the request is authorized.

The trend line  in access control points to more fine grained access control and to have authorization decisions be policy based (rather than hard coded).

 

 

The four Anti-Patterns that we discussed show why trends continue in the direction of increased granularity and policy based access control.

Low/no access control – “we’ll see if it works and then turn on security later”

Access control is too important to be left up to developer discretion. Authorization and access control should be configured in policy, not hard coded. Externalizing the application’s authorization gives the enterprise several important advantages, including flexibility to route authorization requests to the system that has the most specific and freshest information.

Replicating user accounts – copying in full or an extract your Enterprise directory to the Cloud provider

XACML separates the Policy Enforcement Point (PEP: which protects the app) from the Policy Decision Point (PDP: which has the information to grant or deny the authorization request). This logical separation enables the enterprise to deploy its PEP on the Cloud Provider side to implement authorization enforcement while routing requests to PDP’s with the freshest and most specific attributes to answer the authorization request.

Separating the PEP and PDP means that the Gateway can intercept the request to the resource, route the request to the system with the freshest and most specific information, and enforce the policy. This pattern allows for a flexible, best of breed authorization architecture with the PEP and PDP tuned to control the authorization workflow. The PEP is responsible to enforce the chain of responsibilities in authorization and the PDP carries out the responsibility via querying data sources to grant or deny access.  Note, the information needed to make the grant or deny access may cross from Cloud Provider to enterprise Cloud.

Copying credentials – sometimes Enterprise copy credentials to Cloud based services; and thereby create a new pool of identity risk to manage.

Separating the PEP and PDP eliminates the need to hard code individual credentials to resolve access control challenges. This is because the PEP queries the PDP on behalf of the user to verify user’s attributes against the authorization target including the Resource and Action requested.

“Trusted” proxy – where trust is in name only

Trust, but verify means auditability. When authorization logic is strewn across millions of lines of code, auditing is impossible. Auditable systems must have authorization rules and logic that are clear and straightforward to review. Pulling key authorization policies out of the code and into XACML policies allows the Auditor to assess the target and ensure it meets the system owners’ goals.

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.

What the Analysts are Saying…

Read what the analysts are saying about Intel & McAfee’s cloud access broker strategy.

Here’s a “birds-eye-view” on our new Analyst Consensus page

-Jeff

Government Solutions Resource Center

If you haven’t already seen it, Intel^® Application Security & Identity Products has released a new Government Solutions Resource Center  that is a must-see. Whether you are looking for information on Identity Credential Access Management, High Assurance, Cross Domain Information Sharing, NIEM, NSTIC or other info about other current Government concerns, I highly recommend you check out this resourceful center. Among other things, it has webinars featuring distinguished NIST leaders, pertinent information on a whole range of relevant topics, and introduces how Intel & McAfee are addressing some of the current IT challenges in the Government.

 

 

Federal CIO VanRoekel details his ‘first’ priorities

With nearly three months on the job, federal chief information officer Steven VanRoekel is revisiting some long-standing technology priorities.

VanRoekel gave his first major policy speech recently, since taking over for Vivek Kundra in August, signaling how he plans to move the administration’s IT reform ball forward.

In this Federalnewsradio.com post, read about how:

• OMB will promote “Share first” policy –The Office of Management and Budget will begin promoting a “share first” policy. VanRoekel said the idea is to have agencies look to others when buying technology or upgrading systems before going off on their own.
• “I envision a set of principles like XML First, Web Services First, Virtualize First and other firsts that will inform how we develop our Government’s systems.”
• “All of these elements are really grounded in the foundation that is cybersecurity.”

 

 

 

Toward these goals, you can deploy Intel Expressway Service Gateway, a purpose-built cross domain service gateway that enables secure collaboration amongst agencies.

You can address perimeter defense with wire speed XML threat protection, complex security policy enforcement and ready multi-factor integration to identity infrastructure.

And you get the Intel advantage since Intel Expressway Service Gateway has been engineered to take advantage of Intel hardware optimizations to deliver best in class performance and hardened, high-assurance security.

Please reach out to us at  intelsoainfo@intel.com or call 978-948-2585 if you need assistance.

Webinar: Federal Cloud Security Initiatives Explained – Choosing the Right Standards and Technologies

Join us on 10/6  at 2pm Eastern Time for an exciting and informative webinar:

Federal Cloud Security Initiatives Explained – Choosing the Right Standards and Technologies

Mapping the alphabet soup of federal cloud security initiatives is a daunting task. Tim Grance from NIST and federal security expert Gunnar Peterson join forces to decompose the funded programs and standards initiatives to recommend an adoption path for cloud security. Tim begins with a grounding in NIST’s baseline cloud security architectures/guidelines. Gunnar follows with insight into how these practices have been incorporated into programs such as NSTIC, FedRamp, FICAM, Cyberscope, and DOD-PKI.  This will be followed with additional guidance on some of Intel’s solutions from Intel Application Security & Identity Products Chief Architect, Andy Thurai. A group discussion will comment on the adoption timelines, real world use cases, and applicable COTs commercial technologies. Attendees of this webinar will receive a copy of Gunnar Peterson’s Federal Cloud Security white-paper. Sponsored by Intel & McAfee.

Register here:

http://washingtontechnology.com/webcasts/2011/10/intel-mcafee-cloud-security-100611.aspx?tc=page0

 

OAuth2 for the Enterprise? Not so fast… Exploring SAML for REST with Expressway Service Gateway

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