Cloud 101CircleEventsBlog
Register for CSA’s free Virtual Cloud Trust Summit to tackle enterprise challenges in cloud assurance.

Deprovisioning in the Cloud

Deprovisioning in the Cloud

Blog Article Published: 02/23/2012

Let's be honest: how many of you have tried logging in to one of your former employer’s accounts? Maybe you had a CRM solution and you wanted to get the name of that guy who suggested he had the next hot idea. You didn't set your out-of-office message with your new/personal contact information in the hosted email service. The travel site for the previous company was just plain better than anything else you can access. As security professionals, we know the risks: the lag time for deprovisioning varies, but best practices suggest when an employee walks out the door, all of his administrative access shuts down as it closes. That has been harder to do in the cloud. Even with SAML tokens and a smathering of open standards for authentication, inconsistent support by SaaS providers and spotty enterprise directory integration leave opportunities for exploitation that simply don't exist in the on-premise IT world.

The open identity standards were supposed to fix this, but even after six+ years, they haven't been adopted across the industry. Federated Identity Management, OAuth, SAML (Security Assessment Markup Language), OpenID and large initiatives to implement them, such as those by Google and Facebook, are beginning to pop up on various sites. A Fortune 500 company easily uses over 100 cloud services, ranging from expense reporting with Concur to American Express' GetThere Travel to SalesForce's Customer Relationship Management software. All 100 don't support a new authentication standard and those that do don't all support the same one.

Why is this important, you might ask? Quite simply, until you have a single place to pull the plug or an extraordinarily mature configuration management / process control structure embedded into the corporation, you cannot fully disconnect an ex-employee from the company. Most companies will immediately remove access to obvious things like Active Directory/LDAP and VPN credentials. They may synch other passwords through automated processes and close down internal access to SAP or Oracle. The remaining stragglers may seem innocuous, but there was some function that was important enough to enroll the employee in the first place. Think back to the multitude of cloud services you use day to day for your job; many of them still rely on good old usernames and passwords.

Password policy controls

If you're stuck with passwords, there is always the possibility of a password intermediary, a system you log into that stores all of your credentials in a hash format you can't read or, better still, access. There are plenty of programs that run locally on your machine, password vaults of sorts like KeePass, Password Vault, etc., where the user enters a master password (that may be looped into a directory structure of some sort) and receives back a set of service IDs. Click on the service you want and a password is automatically copied to the clipboard. Of course, there is a bit of customization necessary to make the commercial and open source projects into something single purposed where, if an administrator removes your rights to that program, all other access simply goes away.

But what happens when a power user, or better still a corporate executive, says they want to venture away from the corporate standard (be it Wintel or Apple or even Linux) and use something different. Customizing software's expensive; customizing and supporting multiple platforms becomes exponentially so. Someone else may already have done the legwork - at least one vendor looks to have taken this approach towards handling customization. Between the major PC OS release schedules and versions, and the constantly (and quickly) evolving mobile platforms, can anyone really afford to wait for locally developed software?

There are a plethora of “as a Service”s - Software as a Service, Platform as a Service, and recently venturing cloud folks began pitching Identity as a Service. Certificate Authority (CA) vendors like Entrust, GeoTrust and Verisign might argue that's what public certificates were all about, but let's table that discussion for later. Instead of Identity as a Service, which is trademarked by Fischer International Identity, let's use Gartner's “Identity and Access Management as a Service” (IAMaaS) as defined in their 2011 Magic Quadrant for User Administration and Provisioning. So, how can IAMaaS help?

Let's let the cloud fix the cloud problem

Since the cloud got us in to this mess, can it be the solution as well? What happens if we move the password vault to the cloud? The idea for most IAMaaS providers centers around an information store that synchronizes internally, federates when it can, uses two-factor when it's important and stores passwords when all else fails.

  • Internal Synchronization – this is one of the stickier prospects to the deal. The directory service that a corporation uses (LDAP, AD, etc.) has to be accessible to the IAMaaS. Not directly accessible that you're handing over the password tables, but lookups and validations do need to occur. In many cases, this is an on-premise device for network security reasons and so that the data remain fresh; real-time integration beats anything with latency. Plus, when we keep the systems internally synchronized, we're not amplifying the deprovisioning problem by introducing an across the board delay.
  • Multi-platform support - the cloud is always (usually) on and all of the authentication happens across http. This makes the services cross platform (provided they have a TCP connected device and browser).
  • No expensive programming – most of the vendors write connectors for the various websites they support out-of-the-box. This abstracts away the complications of Facebook changing their login processes or Google changing their APIs. The number of connectors included out of the box may be indicative of the breadth of support by that vendor, or poor design/programming choices in creating the backend software.
  • Standards support – in the Fortune 500 company example, I can use the out-of-the-box connectors side by side with a federated OpenID, SAML or even a future standard. And I expect that two-factor authentication will still work when it needs to.
  • Ease of adding new sites, services and apps – In addition to the out of box connectors and standards, several of the products include do-it-yourself, wizard options that work in most cases. When that doesn't work, some vendors find the development of new connectors so trivial they offer a fixed-priced development.

The benefits of IAMaaS are numerous and include deprovisioning. An administrator maintains access to the keys to the kingdom without having the responsibility of legible text files or tons of endpoints to support. Users don't worry about complexity requirements, password rotation, multiple login credentials, federation, or any of the other headaches associated with good password policies. When an employee leaves, the administrator uses the well-implemented processes already in place to eliminate internal access; the external sites simply fall off as user's rights.

The same techniques are applicable to a wide range of sectors, and could even be useful in the Public Sector. The US military stood up their DEERS/RAPIDS CA around the mid 90's. Several of the agencies and military services utilize this CA through a smart chip embedded card called the Common Access Card (CAC) for Identification and authentication. With this card, users can log in to their systems, access secured web sites using client side certificates, and send signed or encrypted emails – internally, they define secure. But even the government uses publicly available websites (you thought Linkedin and Facebook are only mined by corporate recruiters?) as well as “external” inter-departmental and inter-agency sites, where these same deprovisioning problems are even more imparative. Automating the processes might help the Government more than we'll ever know.

The crop of identity providers clambering to ride the cloud and become the next default solution include players in Gartner's MQ that already embraced the cloud, but also non-represented companies conceived there:

  • CA Technologies' Role and Compliance Manager
  • Citrix OpenCloud Access
  • Courion's Access Assurance
  • Fischer International Identity's Identity as a Service (yes, the trademarked one)
  • Forge Rock
  • Intel's Cloud Access 360
  • Iron Stratus
  • McAfee’s Cloud Identity Manager
  • Okta's Application Network
  • OneLogin
  • Ping Identity's Ping Federated
  • Symantec's O3
  • Symplified's Symplified Suite
  • VMWare's Horizon Application Manager

This is far from an exhaustive list, and each solution has their benefits and detractors. If I left you out, please expand the article by way of comments.

Jon-Michael C. Brook is a Sr. Principal Security Architect with Symantec's Public Sector Organization. He holds a BS-CEN from the University of Florida and an MBA from the University of South Florida. He obtained a number of industry certifications, including the CISSP and CCSK, holds patents & trade secrets in intrusion detection, enterprise network controls, cross domain security and semantic data redaction, and has a special interest in privacy. More information may be found on his LinkedIn profile.

Share this content on your favorite social network today!