Security Standards – Why they are so Critical for the Cloud Arrow to Content

May 13, 2011 | 1 Comment

By Matthew Gardiner

Everyone loves standards, right?  When is the last time you heard a vendor proudly say that their product or service was closed and proprietary?  However, it also seems that every time a new IT architecture sweeps through the market, this time one based on cloud models, the lessons of the critical value of standards needs to be relearned.  While it is easy to poke fun at standards by saying such things as “I love standards because there are so many from which to choose,” it is also easy to see the incredible value that they can unlock. Look at the Internet itself as an example.  It is hard to imagine the cloud reaching its potential without it using a set of widely adopted standards – security and otherwise.

In the context of this blog when I refer to security standards, I am talking about security interface standards (basically cloud security APIs) that enable security systems in one domain, whether in a cloud service or in an on-premise enterprise system, to communicate and interoperate programmatically with security systems in other domains.  The absence of such standards drives the use of customized integrations which have been the bane of IT agility since the beginning of modern computing.

Why is it that everyone loves standards in concept, including those for security, but often standards definition and deployment is less than speedy?  Why doesn’t everyone involved just pull together and solve this obvious problem now, instead of waiting until we are all suffering from lack of standards?  While this is a general issue with standards, let’s look at this issue through the lens of the emerging public cloud-based services (public IaaS, PaaS, & SaaS).  There are both rational and less rational reasons why standards are developed and used at a rate slower than they should be for maximum benefit.

While not the only factor to consider, the reality is that standards must be considered as an element of the overall vendor competitive struggle, where differentiation is key.  There are logical economic reasons why market dominant vendors — in this case dominant cloud service providers — tend to be wary of using publicly available interface standards for their services.  For one it makes their differentiation that much harder and it lowers the cost of switching to competitive services.  Thus interface standards can serve as a competitive threat.

While no vendor will come out explicitly against standards (remember that everybody loves them), when pressed on the issue, they will come back with answers such as, “existing standards are too immature” or the “market is moving too fast to standardize yet” to explain why they are not moving more quickly to standardize their interfaces.  Of course they might be partially right, but these are not objections which generally hold up under explicit and consistent customer demand for standardization.  See the broad adoption of SAML by cloud providers as an example of what this pressure can accomplish.

This leads me to one of the less rational reasons why standards are not used as readily as they could be:  Lack of customer vision! Without a clear long-term vision of the future and how cloud services will be engaged to support the business, customer’s of today’s cloud service providers basically stumble into using the available proprietary interfaces and thus are enabling the current providers to largely get away with not providing standards based interfaces.  IT departments are doing what they need to get the job done, which optimizes the short-term results, but unfortunately it’s at the expense of the longer-term.

What does the future of the cloud look like over the next three to five years?  In my view organizations of all sizes will be deep in the middle of a dynamic and hybrid mix of public cloud services, private cloud services, and traditional on-premise IT systems.  The mix will vary by organization. We could see 20 percent public cloud services and 80 percent on-premise and private cloud services at some organizations and a 50/50 split or some other mix at other organizations.  Even within the public cloud category there will be a tremendous variety of usage at most organizations, not only with the types of cloud services used (Infrastructure-as-a-Service, Platform-as-a-Service, Software-as-a-service) but also with the variety of service providers from which they receive them.  If you agree with this view of the future, then you should understand the need to use security interface standards to enable effective security management across them.

If supporting dynamic and hybrid IT requires organizations to continually build-up and tear down proprietary security integrations that bridge their on-premise and cloud worlds, then they will either be spending an inordinate amount of time and money creating these integrations, or worse will be living in the middle of a hodge-podge of security silos, which are neither secure nor convenient for the users.

For the cloud to reach its potential as the next transformative IT architecture akin to the Internet itself, it is critical that it operate similar to Legos which can be assembled and re-assembled quickly and securely as required.  Furthermore, it is imperative that automated controls, both preventive and detective, can be configured to flow back-and-forth between and among all components of the organization’s mix of public and on-premise IT systems.  This prospective future is not as far off as if it might seem.  There are many security interface standards already in existence (XACML, WS-Security, CloudAudit) and some are already relatively widely deployed, such as SAML, that were built to enable the hybrid cloud and on-premise application world.  The primary issue now is the adoption of these standards.

While I recognize that collective action on the use of security standards such as these is not easy, I believe it is imperative that customers start envisioning and working towards this future now – and pushing their cloud service providers to get onboard with it too.

 

Matthew Gardiner is a Director working in the Security business unit at CA Technologies. He is a recognized industry leader in the security and Identity & Access Management (IAM) markets worldwide. He writes and is interviewed regularly in leading industry media on a wide range of IAM, cloud security, and other security-related topics. He is a member of the Kantara Initiative Board of Trustees. Matthew has a BSEE from the University of Pennsylvania and an SM in Management from MIT’s Sloan School of Management.  He blogs regularly at: http://community.ca.com/members/Matthew-Gardiner.aspx and also tweets @jmatthewg1234.  More information about CA Technologies can be found at www.ca.com.

 

OAuth – authentication & authorization for mobile applications Arrow to Content

May 6, 2011 | Leave a Comment

By Paul Madsen

paul-7.jpg

Federation is a model of identity management that distributes the various individual components of an identity operation amongst different actors. The presumption being that the jobs can be distributed according to which actors are best suited or positioned to take them on. For instance, when an enterprise employee accesses services at a SaaS provider, Single sign-on (SSO) has the employee’s authentication performed by their company, but the subsequent authorization decision made by the SaaS provider.

Federation’s primary underlying mechanisms are ‘security tokens.’ It is by the creation, delivery, and interpretation of security tokens between the actors involved in a transaction that each is given the necessary information to perform their function. Security tokens serve to insulate each actor from the specific IT & security infrastructure of their partners, customers, and others by standardizing how identity information can be shared across company and policy boundaries. Returning to the enterprise employ SSO example, after authenticating the employee, the enterprise creates a security token attesting to that fact, as well as additional attributes that might determine what actions she can perform at a particular SaaS provider (e.g. she is in Engineering not Sales) and then delivers the security token to the SaaS provider. The SaaS provider, rather than directly authenticating the employee through some stored password, instead relies on the authentication performed by the enterprise, and acts accordingly.

SSO simplifies life for the employee because she need not manage a password for each SaaS application her job demands. Furthermore, SSO provides security benefits for the employer, such as being able to easily & quickly terminate access to all those applications should the employee leave the company. SSO arguably offers even greater value when the service being accessed is a mobile web application (i.e. delivered through the browser on an employee’s mobile phone). Data entry remains challenging on mobile devices, even more so when corporate password policy requires entering a mix of case and characters. If an employee is tempted to create (or reuse) an easy password at her desktop, then she will be doubly so on a phone.

The federation standards for browser-based SSO to web applications are well-established (if perhaps a bit duplicative) on the consumer web with OpenID being the preferred choice. In the enterprise and cloud world, the Security Assertion Markup Language (SAML) is the default with WS-Federation an option in Microsoft environments. SSO for mobile web applications works the same as for desktop browsers. The protocol messages and security tokens are delivered through the browser between the actors. The only potential difference is that the HTML served up may be optimized for the smaller screen and/or processing capabilities of the phone.

The popularity of the iPhone AppStore and Android Market in the consumer world highlights an increasingly important alternative to browser-based applications, Native applications have the user download and install the application to her device; the application then interacts with servers to retrieve the data rather than rely on the browser. Both native and web applications have their pros and cons. A seeming trend towards the native model may well be reversed as HTML5 makes possible richer user experiences and device integration for web applications.

The native applications on the phone push and pull data from the server typically through REST APIs. The IdM challenge for native applications is how the native application can authenticate to these APIs so that the API can make an appropriate access control decision. Security tokens provide a solution, offering similar advantages as they do for web applications. Critically though, the federation protocols relevant for web applications (i.e. SAML, OpenID, WS-Federation) are generally not optimized for the requirements, challenges, and opportunities presented by native applications.

OAuth 2.0 is a federation protocol, currently nearing finalization as an IETF standard, that can be optimized for just such native applications. OAuth emerged from the Consumer Web (an archetypical use case that of one web site being able to post to a user’s Twitter stream) but has evolved to meet enterprise and cloud requirements. For mobile native applications, OAuth defines 1) how a native application can obtain a security token from an ‘authorization server’ and 2) how to include that security token on its calls to the relevant REST APIs. Importantly, OAuth supports the concept of the user being able to control the issuance of security tokens to native applications and so indirectly control the authorizations the native applications have for accessing personal data behind APIs. Before OAuth, the default authentication model for native applications was the so-called ‘password anti-pattern’ in which the native application would ask the user to provide her password for the site hosting the APIs the native application wanted to call. Teaching users to share their passwords with arbitrary (and potentially untrustworthy) applications is less than ideal. OAuth mitigates the practice by having the native application authenticate to the API with a security token and not the password itself.

By abstracting away the particulars of each of their security infrastructures from multiple participants, and obviating the need for placing passwords ‘on the wire’ federation (and the more fundamental security token model) offers many benefits for both web (browser-based) and native (installed) mobile applications. Ultimately, an authentication and authorization framework for mobile applications should address the needs of both application models through support for the relevant federation protocols like SAML and OAuth.

About Paul Madsen

Paul Madsen is a Senior Technical Architect within the Office of the CTO at Ping Identity. He has served in various design, chairing, editing, and education roles for a number of federation standards, including OASIS Security Assertion Markup Language (SAML), OASIS Service Provisioning Markup Language (SPML), and Liberty Identity Web Services Framework (ID-WSF). He participates in a number of the Kantara Initiative’s activities, as well as various other cloud identity initiatives. He holds an M.Sc. in Applied Mathematics and a Ph.D. in Theoretical Physics from Carleton University and the University of Western Ontario respectively.

Who Moved My Cloud Arrow to Content

May 4, 2011 | Leave a Comment

by Allen Allison, Chief Security Officer at NaviSite (www.navisite.com)

Managed cloud services are quickly being adopted by large enterprises. Organizations are increasingly embracing cloud technologies for core services like financial systems, IT infrastructure, online merchant sites, and messaging solutions. This adoption rate is creating an ever-increasing role for audit and compliance in the cloud.

Before cloud computing gave IT environments elasticity, flexibility, and transportability, it was relatively simple to provide the regulatory compliance. Prior to the cloud, an organization was able to isolate all of the devices, operating systems, and applications on which sensitive or regulated data could reside, and the auditors had an easy task of auditing the security controls and verifying policies, procedures and processes for isolated environments. However, as the industry began to adopt more flexible solutions such as cloud, it became more difficult to contain environments for auditors to provide the same review without requiring a significantly higher level of work. While a managed cloud services company may deploy like policies and security solutions for cloud computing as would be in a traditional IT environment, proof of those same controls grows more difficult to demonstrate to the satisfaction of the auditors.

For example, if an organization had a virtualized environment that had well-defined boundaries or security zones, and even during a failover or disaster recovery all events, logs, and incidents were easily tracked and verified, it took little effort for an auditor to review and provide the assurance of compliance for the environment.

Cloud changes this game a bit, with its ability to move environments dynamically, without human intervention. This move could be within a single data center, but is often from data center to data center, from coast to coast, or even from continent to continent. This flexibility, while often necessary to support business needs, introduces a level of complexity that many auditors have had difficulty with. When the auditor can’t pin down the environment, how can she or he assess its compliance?

But there are a number of cloud providers who have been working to overcome these challenges in conjunction with their auditors. For example, SAS70 (soon to be SSAE16) has been especially difficult for auditors to assess in cloud environments. Depending on the controls, SAS70 will likely have the requirement of aggregating the review of physical access to the facility, at-console access to systems, and logical access to the environment. To add to the complexity, there may be differing controls for the application that provides the user interface from the application being presented to the end users. Furthermore, the controls in place may incorporate role-based access controls with built-in work flow for provisioning and approvals. This has provided for a very complicated system of buttons and levers to assess. However, by providing a common platform for the audit trails and logs, managed cloud providers are simplifying the work for the assessor and allowing for the aggregation and correlation of those events into a simplified platform.

In addition to the aggregation of these access events, following are additional controls that cloud service providers are incorporating in order to provide the common manageability of and the ability to audit a cloud platform:

Security Event Correlation – By incorporating industry leading Security Incident and Event Management (SIEM) solutions, more cloud providers are able to aggregate the logs from multiple platforms, multiple customer-specific and customer-shared devices, and multiple data centers into a centralized security management solution that can provide an easy to review aggregation point of all related security events.

Centralized Authentication – Providing a single authority for authentication and authorization, while centralizing all accounting, is a significant step to providing the proof of access and attempted access to an auditor. This authentication, authorization, and accounting (AAA) is a critical aspect of audit and verification of access to key systems housing data or intellectual property.

Data Replication – A growing requirement for organizations moving to cloud is the seamless failover and recovery of applications in the event of an outage. While we have always enjoyed highly available, fault-tolerant systems, the gating factor has always been the integrity and currency of the backend data. In order to provide the assurance that the data in all systems, and all data centers is consistent, data replication solutions are often deployed to guarantee the low Recovery Point Objective (RPO) often required in a Disaster Recovery solution. These may require high bandwidth, low latency backend solutions to deliver the infrastructure to support such replication, and most globally diverse managed cloud service providers deliver these networks across their infrastructure.

Common Monitoring and Management Solutions – A single pane of glass is often required to provide a unified look of the entire infrastructure. This will provide an auditor the ability to verify the provider is delivering the level of service guaranteed by the solution. Auditors often look for event handling and common management across all systems. By automating the deployment of such monitoring solutions, and relying on a common platform for the management (including patch management, software revision control, and system lockdown procedures) a level of assurance can be provided to the auditor that all systems are uniform and follow the controls of the monitoring and management criteria.

As the adoption of cloud accelerates, there will be added requirements for auditors to understand these ever-changing, elastic environments, and to be able to provide the same compliance and accreditation that they have historically provided for more static, pre-defined solutions in the past. These requirements are increasing at a significant pace, and the industry relies heavily on managed cloud service providers to guide the auditors through these more difficult assessments.

Allen Allison, Chief Security Officer at NaviSite (www.navisite.com)

During his 20+ year career in the information security industry, Allen Allison has served in management and technical roles, including the development of NaviSite’s industry-leading cloud computing platform; chief engineer and developer for a market-leading managed security operations center; and lead auditor and assessor for information security programs in the healthcare, government, e-commerce, and financial industries. With experience in the fields of systems programming; network infrastructure design and deployment; and information security, Allison has earned the highest industry certifications, including CCIE, CCSP, CISSP, MCSE, CCSE, and INFOSEC Professional. A graduate of the University of California, Irvine, Allison has lectured at colleges and universities on the subject of information security and regulatory compliance.

Page Dividing Line