Tuesday, September 15, 2009

Reclaiming your account: Password Reset/Forgot Password

This is probably one of the oldest functionality that is part of any password based system and by now I was hoping that people will have figured out most of the ways of doing it. But while reading answers on stackoverflow on this topic, I was impressed by new ways being developed and implemented by developers in wild. While reading the discussion I felt that there is lack of a structure to look and study this functionality and this post is an attempt to define a structure.
Before I go there, I wanted to capture my understanding of the password reset functionality.
  • Why - Well if we are not noting down all the accounts we have created in life (either electronically or manually), it is possible that we are going to forget passwords for some accounts as we age. Even if you follow some techniques like having standard passwords across all your accounts, due to site limitations, change in word preferences, etc, you may not remember the applicable password for a site and so the lifesaver
  • Why Not create a new account -
    • a lot may be associated with that account in-terms of your reputation, information, etc
    • site limitations of being able to associate a personal identifiers (may be email address or bank account number) with only one account
    • the account id may be generated and can not be changed during your association with the site (SSN, biometric?).
  • What - Password reset/forgot password is a functionality (a bit different from change password - where you remember/know your password) by which user or someone else on behalf of user is able to change the password without presenting their existing password. Again even though the discussion would focus on password, it would probably apply to any shared secret between user and identity provider
  • How - As discussed earlier, the  password reset can be done by user or somebody on their behalf. This process typically involves
    • Verifying the requester's identity
    • Ensuring that requester is authorized to request password reset (incase requester is same as owner of account, this check may be moot)
    • choose a new password (either generated or accepted from requester subject to fulfillment of password policy)
    • provision the password into the authentication system
    • notification that new password can be used, if out of band password change happens (and possible security notification to account owner that password has been changed)
This post explores the first part of the process i.e. verifying requester's identity

Classification Approach

Based on the basics of authentication process, we know that we can verify user based on something they know, have or are. Now in order for the authentication to work we need to ensure same information is available to user and Identity Provider at the time of verification. This implies that prior to verification there has to be an acquisition process which can be classified based on when (at registration, during usage of account or out-of-idp/user account relationship) and from whom (user, Identity/service provider, third-party like credit rating agency, public data) the acquisition has been made.
The verification process itself can be classified based on the type of shared secret/credential along with other criteria like verification channel.

Example


Based on this we can try to classify an approach for user verification which has been done for some of the most commonly used approaches. Please note that this is not an exhaustive list of various approaches in wild and just tries to show how the classification can work for some of the approaches being used in wild

Verification Approach
Acquisition
Verification
When
From Whom
Type
Channel
Registration
Account Usage
Out-of-band
User
Service Provider
Third Party
Know
Have
Are
Single
Multi
What is your pet's name
Y


Y


Y


Y

When was your last withdrawal from account XXX?

Y


Y

Y


Y

Did you live at ZZZ on DD/MM/YYY?


Y


Y
Y


Y

Please provide your date of opening the credit card account


Y

Y

Y


Y

Send a nounce+ to Email Address *
Y


Y



Y

Y

Send a nounce to Cellphone *
Y


Y



Y


Y
One time Password cards for specific duration


Y

Y
Y ^

Y

Y


* The classification may change depending upon the implementation but you get the idea.
^ If IdP is different from Service Provider
+ I do not want to use "temporary password" as it can be confusing

At present not all the permutation/combinations may be utilized but we may find other ways to combine these factors to create new methods. In addition to that, I have a feeling, we would figure out lot more ways of classification of the password reset process.

Why

Even though this was just a thought exercise, I think we may be able to use it to study and compare various verification techniques.  Given that people are already treating some combination of authentication/verification techniques as multi-factor (even though theoretically they may be single factor), it may make sense to develop more detailed classification technique so that we can compare various "multi-factor" techniques and ensure that we are not using pseudo-"multi-factor" techniques. Based on my limited knowledge, I have not run into any such framework but would really appreciate pointer in such direction.

Thoughts?



Saturday, May 10, 2008

Tashan and Data Loss Prevention

I never thought that I would use the two in same blog entry. But I really liked one of subplots of the movie which revolved around usage of social engineering to extract sensitive information about HNI from a Call Center employee for extortion purpose (well a good usecase for DLP). Again given that there are existing products in DLP space to prevent the same from happening over network, would it make sense to add the same to the voice channel too?
The quality of voice recognition (esp for numbers) technology is pretty high. This is pretty evident from the number of deployments in multi-level IVR menus. But , I think, the voice recognition capability of these IVR system is high because it is based on the premise that the user wants its voice to be recognized and false positives for these systems are probably still pretty high.
Incase of DLP, I think, the basic idea is to control accidental release of information and some simple data theft scenario. So, from that perspective adding Voice recognition to DLP makes sense esp for call center deployments.

Sunday, February 17, 2008

On a personal note

It has been a while since I last posted on this blog. In the mean while, I have moved back to my home country India and have settled in Pune. Even though I continue to be in the Identity and Access Management domain, my role has changed a bit where I would be focusing on scaling out the IAM practice instead of working with clients on daily basis. At the same time to keep my skills fresh, I will be working on selected projects because there is nothing like talking and working with clients in trenches to be at the cutting edge (already have done one tour of duty and learned a lot about portals in retail banking while working on a authorization policy model for multiple retail banks).
I would be looking forward to continue sharing with you all some of my experiences and thoughts in IAM space on this blog. I will be resurrecting my other blog which will concentrate on my life in India and other issues that I want to talk about.

Friday, November 02, 2007

Cisco Acquires Securent

Why? Many people [Burton group] who [Ian Glazer] are[Jackson Shaw] more[Dave Kearns] qualified[Forrester] than[Ian Yip] me have expressed their opinion on this subject. The main reason for the acquisition proposed -
  1. Cisco has finally seen the light and decided to enter the IAM space - I do not think this makes much sense given that they are not a software stack company, not even a software infrastructure company (like Symantec, Oracle, SAP, etc).
  2. Cisco needed a product to build identity based authorization into network and hence all its products - I think it is a result of reading too much by us entitlement management guys in to it and the way we would like to see the world.
Externalization of Security Reading in to the fact that product has been placed in Collaboration Service Group and created a separate policy group, it looks like Cisco sees the product as a quick way to externalize the policy management from the various collaborative products. Another important aspect of these product (esp SaaS) is that security for these product is managed by End-users. Most of the web based application vendors (who do not sell security products) have been able to successfully externalize the authentication (support for sso, saml) and user repository (LDAP) but do not have a good model to replicate in the authorization space. If the result of this externalization of authorization across multiple application is successful, vendors will have a model to replicate. This will be a very big win for various enterprises that have been trying to drill this into vendor's head ( being one of them). But I think this is a tougher problem to solve than externalization of authentication and user repository (which are mostly one time job). I see the following problems
  1. If externalization is being performed at administration level, then how do you expose widely different access control model (a SaaS site's model would probably be very different from Web Conferencing / IP Phones access model) through same interface without sacrificing usability, flexibility and asking users to learn a new policy language.
  2. If standardization/externalization is being performed at evaluation level, then how do you meet different performance requirements of different access control models through same generic engine. In addition to that keeping different implementations (on different platforms) for same policy evaluation algorithm with various performance tweaks can be tough.
Impressive Team and great execution I am amazed by how everybody has seen it as a complete technology acquisition and has not given enough credit to Cisco for investing into the team (may be they know something that I do not know about how acquisitions work). The complete team starting from Rajiv Gupta to their pre-sales team members have time and again been giving pretty impressive performance during various meetings with their (potential) clients. In addition to that if any body has been tracking securent over past 1.5-2 years, it is amazing how their sales and marketing team (biz dev) have taken a "would-be" space of authorization to a happening space and recreated a whole domain of entitlement management so much so that this year can aptly be said to be year of entitlement management atleast in terms of hype that was generated (I have never seen so many people clamoring to jump on to third-party entitlement bandwagon in financial services). I would really love to see this team take on a bigger challenges like Salesforce :) To me that could be a great reason in itself to buy the company instead of OEMing the product (beside the obvious reason that there is always the issue of OEMing from a small vendor which may be gone or bought by a competitor). What Next? Well looks like Securent is getting ready to be subsumed by Cisco and hopefully, in a year or two, we would have somebody from their team coming to burton group conference (or some other entitlement confrence) to discuss how their attempt to externalize the security from their collaboration software went and we all will have a good use-case to learn from. With the economy in US having a few hiccups and a possibility that SOX (one of the primary driver for various iam initiatives at this point) may be blamed for all economic problems, the info sec across the enterprises may be fighting a tough battle to get their company's entitlements in order (as soon as they get their user directory, authentication, provisioning in order). In addition to that the big vendors are expected to come out with new offerings in this domain which would make survival of new and existing company tougher. So, will we see a new startup in fine grain authorization space? I sincerely hope so and would love to see them grow and find a new niche in this space because as I see it the problems have just become tougher to solve.

Wednesday, September 05, 2007

Roles - What 'bout it?

Disclaimer - I have not worked on role-mining project and so most of the views expressed here are based on very limited understanding, a lot of arm chair thinking and some understanding of access management. I may be slightly biased against the role-management because I seem the end goal as Access Management and not role management and so far I have not had the "aha" moment for Role Management.

Coming from fine-grained access management background, I have always considered roles as a means to achieve the end goal of access management. Roles to me are an abstraction that we use to separate the policy modeling phase (roles being used to design policy model) and policy management phase (by managing user to role assignment).
But a lot of people do see the roles themselves as something important that need to be "mined" out of privileges. This could be, to some extent, a result of role-centric security model  pushed by J2EE specification in past (and now through SCA Policy Framework) and the developers being comfortable with such models which tried to build a simple security model built around the idea of Is User In Role. Even though this works for most of the simplistic use-cases, some of the security model are more complex and that may warrants the need for XACML profile for J2EE to express the security policy to be enforced. 

But there is another dimension to this whole discussion. There is a neat idea of  Business Role and IT Role (equivalent to Basic Roles in NIST RBAC?) that seems to be gaining ground. The business roles are typically something that are defined by the Business/Organization (like Vice President, Teller, Trader, Foreman, etc) and IT Roles are defined by the application (like admin, user, auditor, etc). Most of the time it is expected that mapping the business roles to IT Roles would simplify the policy modeling and management. This could be a good justification for finding business roles (probably using top-down approach) and "mining" IT Roles (probably using bottom-up approach), if not already present, and mapping the two. So the problem of managing all the user-role relationships can be reduced to controlling user assignment to Business Roles which is something that is already in place in form of HR systems in many enterprise (Again it is probably already showing why I should not talk about things I do not have experience with and so feel free to correct my understanding)
Even though this approach looks great on paper, I am not sure how effective it is. In the few domains that I have worked, most of the business roles are contextual (for example - trader on a desk, teller at a bank branch). I have always thought that some of domains like manufacturing and retailing were closer to a standard role based entitlement model because of very well defined processes and role. But thinking more about it, even those may have nuances like supervisor of a specific shop. Similarly most of the IT roles are also context based. For example an admin role in a account management application would probably be given on specific accounts.
At the same time there are definitely applications ( for example any vice president can approve expense report ; show the admin menu only to an administrator) that can be fulfilled by generic roles.
Ultimately the use of NIST RBAC in an application boils down to how complex the role context is within the domain. In case the context is simple enough, it can addressed by building it in to roles so that you may have na_sales_mgr, emea_sales_mgr and so on. But most of us already know that such hacks, if not controlled, can become a recipe for role explosion and would ensure that you need a role management product.
The complexity of the context itself can make the role almost a secondary concept. For example let's take a case of a consulting firm working on large project. Such a project may have separate teams of developers, architects, infra guys spread over multiple geographical locations. Now such a scenario may be uncommon in IT consulting but I think some thing similar would be case in a auditing or investment banking where some of the multi-national M&A deals and company auditing take place. In the example earlier let's say the employee John Doe is assigned role DBA for the developer teams in New york and Seattle for the project Big Bang and Backup DBA for the architect teams in Europe (located in London and Paris) for the project Solve World Hunger. In this example the role itself is such a tiny part of the possible complex context structure (Location hierarchy, teams, etc). Now there may not be that many examples out there with such complexity at the context but at the same time such examples help keeping things in perspective.

To summarize I think we need to be clear about what is the problem we are trying to solve before starting on the role management path. If the end goal is access management then NIST RBAC should be looked at just one of the ways of policy modeling. But if the goal is to get the organizational hierarchy in control, then using a role mining tool to get some roles that are meaningless to business may not be right way to proceed and instead appropriate process must be defined and implemented for organizational hierarchy leaving the IT Roles out of scope.

Wednesday, August 29, 2007

Preferences and Entitlements

So far I have thought about the Preferences and Entitlements as two separate notions that are not connected to each other. But today while thinking about a few things from work and some blog posts, I realized that there is more to the it than that meets the eye.
Before we go any further let's summarize the definition of terms for the purpose of this discussion

Preference is information that user makes available to resource / application to allow the resource /application to present information in a "user-friendly" manner. (I understand that this is very limited version of preference and there might be other better terms like Persona to describe the same concepts).

Entitlement Model (including model and data) is information that resource / application owner makes available to resource / application so that it can present information that user has access to.

Even though these definitions are not the standard, they are used here to drive the point of view that I am trying to explain. At some level we can view these two things as being about the same thing i.e. annotation of the user-resource mapping / relationship. There are a few implications that I could think of

  • Entitlement Modeling as preference source and vise versa - One of the various source for the user preferences that an application can have is Entitlement Model. For example [James McGovern - Relationships and Authorization] - In case the Insurance application has  modeled user's preferences (including relationships and their access levels /roles) in to its entitlement model, his preferences should be taken into account while determining the access for the user's son.
  • One way relationship (do we have a word for these things) - If we treat the relationships as preference (i.e. I prefer to call John Doe my friend even though he may prefer to consider me to be an acquaintance) and have a standard way to integrate preferences into entitlement model, relationships can be just another preference that is supported by the entitlement model. Please note that incase preferences are modeled as attributes, downgrading relationships to attributes is something that can come back to bite when there are specific requirements wrt relationships.
  • Provisioning - As discussed as part of entitlement and provisioning integration topic earlier, user's attributes for a given application can be based on the entitlement model the application enforces. Now one of the aspect of this is that some of the attributes /relationships being exported by entitlement model to provisioning model can be part of the self-service workflow to be managed as user preference.
  • Extending Social Graphs - The relationships and attributes that form part of the identity provider trove, can be further enriched by providing additional preferences or refine the scope of relationships based on resources. For example I can be friend of a person in the context of specific resource (say flickr) but an acquaintance in the context of other resource.
Thoughts?

Saturday, July 14, 2007

Integration of Authorization/Entitlement Management products with Provisioning Products

As part of the various discussions that I keep having in the fine-grained authorization domain (or is it entitlement management now?), this is one of the topics that we visit. The above requirement stems from the fact that Provisioning Products were never built to support the entitlement/authorization concepts and authorization policy lifecycle management.

So, the entitlement management products' management interface (for policy lifecycle management) can not be replaced by provisioning product. In light of this realization, the next step is to find the best way to bring together the two technologies. There are various ways in which the two products can be integrated and some of the approaches are discussed below. Please note that this list is in no way complete and would look forward to your comments on other possible approach in this area.

  • User Provisioning - The entitlement management product itself may be seen as another repository of user data that must be updated OR the product may be seen as something that must be updated as part of user provisioning for a specific application (which is protected by entitlement management product). This idea is valid only if the entitlement management product can not integrate with standard identity repositories OR due to implementation requirements which forces the product to store the user information instead of pulling it at management and runtime from external repositories.
    Incase the product is being treated as another repository of user identity, the User Identity with its standard attributes and roles may be provisioned to the product as part of standard user setup or when the user is assigned an application that depends on the entitlement management product for entitlement management. If the setting up of user information in entitlement product is being treated as one of the steps of application provisioning, then an application specific profile (with application specific identity, attributes and roles) can be provisioned to the entitlement product as part of application provisioning process. This profile would need to be generated manually based on application policy model (see fine-grained authorization provisioning below).
  • Resource Provisioning - The concept of resource in most of the user provisioning system is limited to the idea of application, i.e. these product do not understand that the application itself consists of additional resources like accounts, documents, trades to which the entitlement provisioning need to happen. Due to this deficiency the user provisioning products are not great for managing and provisioning resources (which most people still think is in the domain of application unless there is a drive to start building a standardized resource lifecycle management infrastructure which may makes some sense for some type of data like Personal Identifiable Information, Intellectual property, etc). But some product may provide the capability to provision the application to the entitlement management product when the application is created in the provisioning product.
  • Fine grained Authorization Provisioning - The provisioning systems so far have supported the idea of provisioning of user data (id, roles/groups, attributes) into the application repository. People have extended this idea and implemented ad-hoc models of provisioning entitlements into their applications by mapping the user specific entitlement data to standard concepts like application specific attributes (some of the products do not support the concept of role/group as a separate concept). But such an approach means that the model hard coded into provisioning products is completely dissociated from model embedded into the application or the entitlement management product.

    As far as I can see, there is no standard way to communicate this information to the provisioning product at runtime. What we need is a way to ask the entitlement management product, what is the model that it wants to expose to the requestor and what is the information corresponding to the model that should be provided to requestor so that they can choose the entilement that needs to be provisioned for OR this information can be communicated to the provisioning system by the entitlement management system as and when the policy model is updated. For example if the authorization model implemented for application X is User based ACL, then the provisioning system would need to display to the requestor the resources (provided by application or entitlement management product) that provisioned user may be granted access to OR incase the authorization model is a role based access control model, the requestor would be provided with a list of application specific roles (provided by entitlement management product) that user can be provisioned for OR if the entitlement model is attribute and role based, the application specific  attribute and role list can be provided to the requestor to allow them to define the user's entitlement for the application.
    The approach described above is more of a thought and I do not have answers for all the question this may raise. But from lifecycle perspective, unless there is a change in the authorization model for the application(i.e. from User ACL to RBAC), only the attributes and roles (or resource values incase of User based ACL) would change for an application over time and that can be addressed by adding validation and associated remediation to the provisioning system's identity data synchronization/auditing process for the application.  

Thoughts?