Access Governance in the Cloud Age (Part 2 of 3)
Part 1 of this 3-part article set the stage by defining access governance in general, and with a focus on cloud applications. In this second part, we look at the scope of access governance and some of the unique challenges that cloud applications rise.
Incidentally, I just came back from the Gartner IAM Summit in San Diego last week, and among the many good sessions that went on, I found Gregg Kreizman’s Managing Identity in the Cloud particularly interesting and relevant to the theme of this article.
The Scope of Access Governance in the Enterprise
For the most part, all organizations today must have an access governance solution in place, particularly if they are subjected to regulatory compliance (i.e. SOX, NERC CIP, etc.), regardless of whether it is done manually or automated.
Viewed from this standpoint, cloud applications that need to be under governance should be treated no differently than those applications and systems deployed internally. However, given access governance solutions have evolved with the assumption that systems and applications were internally deployed, some challenges arise today in the ability of existing solutions to cover cloud applications.
Unique Challenges Raised by Cloud Applications
These challenges are not just technical, but also pose a challenge from a procedural and policy point of view, and while they vary from application to application, here are some of the most common ones we have seen:
Ironically one of the virtues of the cloud paradigm – they are accessible from anywhere, is also one of the toughest challenges to bringing them under governance. There is no intranet or extranet anymore, it is all the same. Moreover, the advent of mobile devices and smart phones as enterprise computing platforms pushes ubiquity even further. Users have a multitude of access paths to cloud applications, and in some cases, these paths provide inconsistent security levels. For instance, a provider typically allows the option for an organization to federate authentication into its cloud application, in which case, the organization provides authentication into the application and can enforce password policies or increase authentication strength by adopting multi-factor authentication; yet if a user relies on an iPhone client application to access the cloud application, chances are the user utilizes a separate set of credentials to log in, which are not managed by the organization. This is an inconsistency, and the authentication strength that can be attributed to the application is the weakest one being used. Now, if the application is categorized as “non-sensitive or low risk” this is maybe fine. But in cases such as Google Docs, the sensitivity of the information may be high; therefore, organizations should give this the appropriate attention.
The appeal of cloud applications often dazzles business stakeholders to the point their desire to adopt the application often circumvents the normal application deployment lifecycle and security assessment a typical, internally deployed application would follow. In many cases, the IT organization is blindsided by the existence and usage of the application, and often finds out only after an auditor highlights it, or worse yet, after something has already gone wrong. These circumstances make it really difficult for the organization to proactively assess and manage these types of risk, and change their posture from proactive to reactive. IT security is then engaged to “bless” the application, and pressured to minimize friction in the adoption of the application as a “governed” system, to avoid disruption to the business. This further contributes to the stigma that IT security is a roadblock in the organization’s ability to conduct business, rather than an enabler. This is a very common predicament we see IT organizations facing more and more frequently.
Proprietary and Deficient Security
For many cloud applications, security is often an afterthought with convenience and usability take precedence over security. This is why most SaaS vendors support only user name and password as the authentication method, by default do not enforce password policies (syntax and expiration), have limited session risk management options (other than session timeouts), and implement weak password recovery mechanisms.
From an authorization perspective, the access control model for each application is very proprietary; some rely on a few roles to manage access while others provide finer granularity. Many cloud applications allow users to specify access control rules to documents and data they make available within the application, making it hard to really prevent any inadvertent access authorization. And this is just the perimeter of the application. For cloud applications deemed sensitive, organizations should also be concerned with knowing how the information is protected within the application, its back ends, when the data is at rest, and when is backed up, and how it is segmented from other organizations’ data [due to multi-tenancy of the application]. The challenge here is SaaS vendors do not disclose all of this information voluntarily, and at best, will share an IT security assessment report on their security mechanisms and practices, rather than allow the organization much access to its secret sauce.
Lack of Visibility
While all cloud applications provide some sort of audit capability that allows the organization to list out which users have access to the application, the driver for this kind of visibility is most often the need to manage license costs – given that most cloud applications are licensed on a per-user basis, rather than the need to reconcile and audit who has access to what. Using the example of Google Docs again, an administrator could query for a list of its Google Apps users, but may not be able to inventory which Google documents or folders a given user has access to.
Limited IAM Integration Options
The cloud space is an evolving area altogether even more so from an IAM perspective. While some mature standards exist (i.e. SAML, SPML, WS-Federation) to allow organizations to integrate their IAM infrastructure with cloud applications, these are inconsistently adopted by most SaaS vendors, if at all, turning the integration landscape into a collection of one-offs. Many cloud vendors claim to support identity federation standards, but they either support it for limited use cases (mainly authentication) or the breath of the integration is limited compared to what they offer when using their proprietary APIs. , In many cases, organizations have no choice but to implement custom integration solutions to integrate Cloud applications with their IAM infrastructure. I speculate that in many cases, the cloud vendor is not motivated to adopt a standard, since doing so would minimize switching costs for their customers, and lose leverage with the customer – a higher integration cost may lock in an existing customer (yes, I said it, I know this is harsh). Today, there is a plethora of emerging solutions that claim to facilitate and automate IAM integration with the cloud, but for the most part they tend to focus only on authentication, and struggle to address provisioning, terminations, role changes and reconciliation. Having said that, I must also state these options tend to be better than building your own integration, but require organizations spend some time understanding the integration and ongoing support available in these offerings. Remember, cloud applications evolve and cloud vendors can change their integration options at any point. In the long term, a centralized, common-platform approach to integrating all cloud applications will prove the best option. Nishant Kaushik has written a few articles on this topic that describe a strategic IAM architecture for both cloud and internally hosted applications very well.
One important observation to point out when considering the cost benefits of cloud applications versus traditional alternatives, is while the subscription-based pricing and the OpEx rather than CapEx model makes a very compelling business case for adopting cloud applications, the tail end of integration cost and recurring support costs to bring the application under governance is not to be underestimated. Clearly, for low risk applications, where the need for access governance is not as stringent, the business cases are closer to what is advertised.
Let’s say your organization uses a business critical cloud application (i.e. ERP, HR, CRM, etc.), and for whatever reason it goes down; what happens? Who do you call? How do you manage this situation? Can you call the help desk? Can you page the IT data center staff to look into the problem? This is now funneled to the cloud vendor. Part of your assessment process should be to gauge and mitigate operational risks, and the best you get are SLAs and possibly penalties (or insurance) that you can draw from to repair the damages. You need to figure out what makes sense in terms of coverage for an outage, what if your sales ordering system goes down during business hours? How much is that worth? Have you consulted with the line of business to ensure you know what constitutes appropriate coverage? Remember, SLAs, particularly those that have penalties tied to them, cannot be decided and negotiated by IT only, the business needs to weigh in on what coverage and recourse is appropriate.
In part 3 we will make some recommendations on how to bring cloud applications under governance. Until then, I would like to wish you all (particularly in the US) a great Thanksgiving holiday.