Sunday, November 27, 2011

Governing Identity Management

Traditionally, each software application is developed to maintain and manage the identity and the related permission information within it. As more and more such applications gets deployed, user provisioning and managing access control could soon be a nightmare. A well managed Identity Management function within an enterprise can alleviate the hassles around this and will also enable the enterprise to better govern the identity and resource provisioning activities.

Identity Management solution as such comprises of the following key functions in addition to being technically capable of exposing necessary automation APIs:

Account Provisioning

This is a core function within Identity Management and this is where an identity gets created.  The following are the typical activities that need to be performed under this function.
  • Adding an Identity - includes receiving a request with required data, performing necessary verification and obtaining approval from appropriate authority.
  • Modifying an Identity - involves change of certain attributes of an identity.
  • Deleting an Identity - when an identity no is no longer associated with the organization, deletion may be required. Deletion may not mean actual deletion and instead may mean de-activation.
  • Suspending / Resuming an Identity - usually when employees go on long vacation, it would be appropriate to suspend the identity and resume again when the employee comes on board.

Resource Provisioning

An Identity once created need to be provisioned to access one or more services, which could be out of a computing resource or a non computing service. For instance, computing resources could mean access to payroll application and similarly a non computing resource could mean physical access to the Data Center.


De-provisioning is an equally important function which, if not done on a timely manner could put the organization into a big risk. For instance, if an employee who has been granted access to critical systems, is not de-provisioned when he leaves the organization, he could cause potential loss to the company.

Managing Permissions and Authorization

Provisioning a resource would only mean that the resource has a need to use the target resource, but it has to be further managed by defining specific privileges like, Read, Write, Delete. Similarly, the identity may have to be granted different permissions for different sub functions that the resource may expose. While a standards based IAM solution would be extensible, the consuming application may require changes to interact with the IAM solution and make use of the authorization information that is exposed.


With a central identity management solution, it is important that the related functions are better managed, monitored and audited. This requires defining, implementing and monitoring controls around people, process and tools & technology.
  • People – The person performing the one or more of the above functions should be highly trust worthy and appropriate separation of duties and responsibilities should be put in place. For instance, the person approving the identity creation should not be the same person who creates it. The identity performing these functions should be at appropriate level which ensures accountability. 
  • Process – Policies and processes need to be defined for each of the above functions. For instance, Identity creation shall specify the source of data, the required attributes for which data need to be captured, a process or methodology to have the identity information verified and on top an approval process. It is typical that the approving authority may be different for different resource, which has to be unambiguously defined. There should also be a process specifying the monitoring and audit requirements for the above functions.
  • Tools  & Technology – Carrying out the above functions will certainly need an appropriate tool and related technology. A comprehensive enterprise tool may facilitate carrying out all the required functions in addition to offering necessary APIs for the resources that consumes the authentication services. It is important to specify how access to these tools and related infrastructure is protected and governed.

The following are the key control objectives that need to be defined with respect to each activity performed under Identity Management:

  • Identification – the security control process that creates an entity and verifies the credentials of the individual, which together form a unique identity for authentication and authorization purposes
  • Authentication – a security control process that verifies credentials to support an interaction, transaction, message, or transmission
  • Authorization – a security control process that grants permissions by verifying the authenticity of an individual’s identity and permissions to access specific categories of information or functions exposed by a resource.
  • Accountability – a security control process that records the linkage between an action and the identity of the individual or role who has invoked the action, thus providing an evidence trail for audit or non-repudiation purposes
  • Audit – a security control process that examines data records, actions taken, changes made, and identities/roles invoking actions which together provide a reconstruction of events for evidence purposes

All the control objectives above serve the requirement to provide an auditable chain of evidence.
Identity management control processes should have an input, one or more control activities, an output, feedback, management monitoring, and an overall audit appraisal activity to ensure that they are fit-for-purpose. The starting point is an individual who is enrolled into an organization and subsequently acts in a function or role in the organization. The individual may be an employee, partner, or contractor, or third party. The output is the appropriate degree of policy enforcement and individual accountability for the business activity. Within the controls, the threats and vulnerabilities constituting the business risk must be addressed and assessed. These include business, legal, and technical aspects.

Like with any systems, the following are the key non-functional requirements an Identity Management infrastructure should aim to offer.
  • Being more responsive and secure
  • Interoperability with a multitude of systems requiring identity information.
  • Support for multiple authentication mechanisms, like two factor, bio-metric, etc.
  • Interfaces and APIs for automation which could result in reduction in operational costs.

A governance framework would not be complete if it does not define the measurements that indicate the efficiency and effectiveness. The following are some of the metrics that could be considered:
  • Password Reset volume – A well managed Identity Management System is expected to considerably reduce the help desk calls on forgotten passwords. As such a measure of this activity could be a key metric to establish that there is a considerable saving in such help desk activities.
  • Number of distinct credentials per user – With Single Sign On implemented, there should be only one distinct credential per user.
  • Average time taken for each of the identity management functions could be another useful metric to establish that the investment is worth.


More related reading:

Sunday, November 20, 2011

SaaS Maturity Level

Cloud is catching up amongst enterprises. Amidst the security and the other concerns that are still to be addressed, CIOs are seeing a clear benefit in shifting towards the Cloud offerings. That means, there is an increasing number of enterprises seriously engaging cloud based applications. This necessitates the need for a model to measure or assess a SaaS application. Like we have Capability Maturity Model to assess a software development shop to be at a particular level, we need a maturity model to assess the SaaS application.

Microsoft way back in 2006 suggested a 4 level maturity model using Scalability, Multi-Tenancy and Configuration to define various stages. While Level 1 is meant to define an ad-hoc hosted application which lacks all the three basic fundamental characteristics and at Level 4 a SaaS application is expected to meet all these three basic characteristics. This model has its own deficiencies as it does not consider few other important characteristics of a SaaS application, like for instance managing the releases, data isolation, etc.

Forrester has come up with the six level definition of SaaS Maturity. Let us examine each of these levels as below:

Level 0: Just Outsourcing, not SaaS. This is a typical scenario where a service provider operates a software installation for a large customer and cannot leverage this setup for another customer. This is just outsourcing and not SaaS.

Level 1: Manual ASP (Application Service Provider). In this case, the service provider has established unique skill in operating similar service to multiple customers, but each client has a dedicated instance and each instance is manually customized by the service provider to the needs of the customer.

Level 2: Industrial ASP, still not SaaS. The Application Service Provider uses techniques to package and deploy the application with different configurations for different customers. In this case, still the customer does not have the ability to customize their instance of the application.

Level 3: Single-app SaaS. This is when the provider is able to offer application  as service to multiple customers out of single packaged application. This is the initial level of SaaS, wherein the application demonstrates some of the basic characteristics of Software as a Service.  At this level, the provider deploys the packaged application on a scalable infrastructure, and shares the single instance to multiple customers with customization limited to configurations.

Level 4: Business Domain SaaS. At this level, the provider offers a well defined business application and also a host of packaged application modules or third party packages, with which the customer has the ability to extend the business logic of the application.

Level 5: Dynamic Business Apps as a Service. This level is a visionary target where in the provider offers a comprehensive application and integration platform on demand. With this ability, the provider can compose tenant specific and even user specific business applications or services.

SEI has in line with the popular CMMI for development, presented CMMI for services packing in some of the service specific process areas in addition to typical development related practice areas. This however is used to assess an organization offering services as against assessing a SaaS product.

As of now, none of the models are popular amongst the major SaaS vendors, may be because of not enough competition on the SaaS space. Once major players compete on SaaS space, then customers for sure will find a way to assess the service maturity and that could be the way forward.

Please throw in your comments.