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.
- 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
- Ping Identity's Ping Federated
- Symantec's O3
- Symplified's Symplified Suite
- VMWare's Horizon Application Manager