From a 30,000-foot-view perspective, the idea of Risk being a driver and a business proposition for the implementation of Identity and Access Management is perhaps one of the strongest for garnering Executive-level support and budget consideration. Over the last couple of years we have also seen similar trends in the real or perceived status of economic conditions. Certainly, the convergence of regulatory compliance concerns and risk in particular is key to developing a business case for IAM per our post last week.
From a more granular perspective, the need for recertification of access for users on a periodic basis (specifically so that you don’t run into segregation of duty concerns) is critical for both audit purposes and internal business stakeholders. Establishing some kind of role construct for users internally so that access can be managed by a non-security user population is also an excellent goal that helps generate a compelling business case. It allows end users and departments to more reasonably recertify employee access to certain areas based on their functional job requirements. This also allows supervisors and managers to avoid delving way down in the proverbial weeds at a very technical level to determine whether someone should have access to a particular asset or data. While this is not a new revelation, it continues to be a very strong goal for IAM that can be easily inserted translated into a business case. This is particularly true when recognized through an event – namely a failed audit or compliance penalty.
This convergence around governance risk and compliance with these and similar identity and access concerns has elevated the profile of identity and access management within many organizations. As a result, more and more projects are being driven at the infrastructure level, and because of the exposure of the risk through effective business cases we are seeing much more involvement from the CFO and CIO offices in elevating these projects into annual budget consideration.
Another key area to factor in IAM business case development are operational efficiency goals, particularly in light of strains on budget and resources due to the recent econominc downaturn as alluded to earlier. In addition, some of the need is driven by the expanded access needs for internal and external user populations. But, with that becomes operational overhead. While this is one of the driving forces in the growth and popularity of cloud services, that’s another subject for another day with its own unique challenges and benefits. As it relates to this subject, the desire to mitigate risk from these external populations while reducing the operational overhead for providing this level of access is definitely a key component of the business case for IAM.
The idea of making data and employee collaboration more available to the business, while improving the end user experience and security posture, is a particularly strong driver on the operational efficiency side. We still see the need for password and group management within the classic network world, but for remote group password management in support of operational efficiencies is one area where organizations must have a more definitive ROI. This is a catalyst and an effective kick start for an IAM initiative internally, as IAM can provide a strong correlation between the business goals and a classic ROI or risk/cost avoidance. For example:
• Web portal registration and access control allows for remote workers, contractors and satellite office to access centralized data and application infrastructure.
• The growth of unified messaging concepts will bring convergence around email, voicemail and IT services.
• Identity and access management has also begun to have an overlap with information rights management and data leakage prevention, particularly for remote desktops and privileged users.
At the end of the day, it can be very difficult for the IT organization to take on the role of “selling” to the organization, but hopefully some of these considerations provide a solid starting point for developing a compelling and effective business case. Of course, partnering with strategic consulting and integration partners (such as Logic Trends) can provide a significant leg up in not only achieving business objectives and supporting business goals. They also have the experience, and data, to help ensure that the message resonates and the funding can be justified.
Friday, July 29, 2011
Friday, July 22, 2011
How to Introduce Risk Management into an IAM Business Case
This is something we’ve seen a number of clients struggle with over the years. There really is a strong need to include risk management as one component of the overall business case preparation. So many IT-focused business cases tend to concentrate on a project that is critical operation infrastructure, like email or networking. Or, they look to focus on a project where it is easy to demonstrate a positive ROI to get approval, like a password reset solution that diminishes the need for calls to the help desk.
Demonstrating hard-dollar ROI is very challenging for IAM projects and has been for years, but the fundamental challenge is that identity and access management costs are spread out across multiple departments in organizations and aren’t tracked sufficiently to accurately determine current spend. The access request process is a great example of this. A user’s manager might request access via a portal, the help desk might process the request, and an IT administrator might fulfill the request, but there is no clear tracking of what actually costs for the entire request process from a resource perspective. Without a current cost to compare the outcome against, it is virtually impossible to come up with a realistic ROI number. For these reasons we think it is very important to focus on risk management concerns when making a business case for identity and access management.
What kinds of risks can you focus on? One example is operational risk. This could be a user that has inappropriate access and could fraudulently steal money or product. Or, could an employee cause a breach of contract scenario, such as not meeting an SLA? Could they destroy critical data? Real world examples of these are really hard to come by because so few organizations that have experienced such issues want to talk about them.
To cite a few examples that we do know of:
• A large utility had a terminated worker who maintained their physical badge access and they returned to a substation where they flipped the vital system switch causing an outage.
• In the communications sector a terminated worker retaliated by taking down servers that supported millions of high speed internet customers, resulting in a multi-million dollar refund.
• At a services company, an employee thought she was going to be fired and in retribution deleted all of her employer’s files (including all of the backup files) from years of operation.
These are examples of operational risks that need to be considered, because having access to these types of systems creates risk instead of reducing it. You can also look at it in terms of IT risk primarily related to inappropriate access. However, most folks who are approving business cases are not overly concerned with IT risks, so you have to keep it in their language so you can move on from operational risk to financial risk. You’ve certainly got the aforementioned fraud issue, and there are literally dozens if not hundreds more cases of users perpetrating fraud nearly crippled those organizations.
What about some things that are near and dear to the IT department’s heart? License Management? Well, if you are properly revoking users who are terminated or separated from the organization, you could be saving licensing expense associated with paying on a per-user basis. Those types of things are typically not included in an IAM business case, but they should be.
Another risk that you should include in your business case are compliance risks. You’re subject to fines, penalties and so forth if you are not in compliance to various regulations. The significance on this can be influenced by the industry and geographic region that you are operating in but we are seeing cases where some fines go from a slap on the wrist to multimillion dollar events and this is significant enough to get to get some buy in from the executive management.
One final intangible that can also be included are reputational risks. Brand awareness, especially for consumer-focused businesses is critical to their ability to operate. You have a major breach, outage, or other type of incident that really erodes the confidence like the recent Sony Playstation 3 Network hacking, and those incidents can literally drive your customers to competitors. These are the types of messages, included in a business case that can help you get the support you need to move forward with your identity and access management case.
Demonstrating hard-dollar ROI is very challenging for IAM projects and has been for years, but the fundamental challenge is that identity and access management costs are spread out across multiple departments in organizations and aren’t tracked sufficiently to accurately determine current spend. The access request process is a great example of this. A user’s manager might request access via a portal, the help desk might process the request, and an IT administrator might fulfill the request, but there is no clear tracking of what actually costs for the entire request process from a resource perspective. Without a current cost to compare the outcome against, it is virtually impossible to come up with a realistic ROI number. For these reasons we think it is very important to focus on risk management concerns when making a business case for identity and access management.
What kinds of risks can you focus on? One example is operational risk. This could be a user that has inappropriate access and could fraudulently steal money or product. Or, could an employee cause a breach of contract scenario, such as not meeting an SLA? Could they destroy critical data? Real world examples of these are really hard to come by because so few organizations that have experienced such issues want to talk about them.
To cite a few examples that we do know of:
• A large utility had a terminated worker who maintained their physical badge access and they returned to a substation where they flipped the vital system switch causing an outage.
• In the communications sector a terminated worker retaliated by taking down servers that supported millions of high speed internet customers, resulting in a multi-million dollar refund.
• At a services company, an employee thought she was going to be fired and in retribution deleted all of her employer’s files (including all of the backup files) from years of operation.
These are examples of operational risks that need to be considered, because having access to these types of systems creates risk instead of reducing it. You can also look at it in terms of IT risk primarily related to inappropriate access. However, most folks who are approving business cases are not overly concerned with IT risks, so you have to keep it in their language so you can move on from operational risk to financial risk. You’ve certainly got the aforementioned fraud issue, and there are literally dozens if not hundreds more cases of users perpetrating fraud nearly crippled those organizations.
What about some things that are near and dear to the IT department’s heart? License Management? Well, if you are properly revoking users who are terminated or separated from the organization, you could be saving licensing expense associated with paying on a per-user basis. Those types of things are typically not included in an IAM business case, but they should be.
Another risk that you should include in your business case are compliance risks. You’re subject to fines, penalties and so forth if you are not in compliance to various regulations. The significance on this can be influenced by the industry and geographic region that you are operating in but we are seeing cases where some fines go from a slap on the wrist to multimillion dollar events and this is significant enough to get to get some buy in from the executive management.
One final intangible that can also be included are reputational risks. Brand awareness, especially for consumer-focused businesses is critical to their ability to operate. You have a major breach, outage, or other type of incident that really erodes the confidence like the recent Sony Playstation 3 Network hacking, and those incidents can literally drive your customers to competitors. These are the types of messages, included in a business case that can help you get the support you need to move forward with your identity and access management case.
Friday, June 3, 2011
ISAG Part 2: Access Governance 101
Over the next few weeks we will be posting excerpts from select Logic Trends' Identity Strategy and Advisory Group (ISAG) briefings. Part 2 below is transcribed from a recent briefing that takes place via conference call, which is why it takes a conversational tone. Email us at sales@logictrends.com to find out how you can sign-up to be apart of future briefings.
Robert Block, Vice President of Strategy & Services
Question: Based on your experience, what are the highest value/ lowest risk cases that should be tactful as early quick wins as regards to access governance?
Response: I would say initially the most obvious use case where most everyone wants to start is manager or user recertification done by a direct reporting manager. So, let’s say I have some regulatory compliance that says I need a new periodic recertification of access and we are going to have our direct reporting manager take care of that. That was often the first place we started.
However, I think what we are finding now is that there are probably a number of preliminary use cases that should be done in advance of that to gain a more affective “win” once manager recertification is being done, or even earlier “wins” prior to the managers who might not be used to certifying access to date. Some of those are starting with the use cases around user review, so I didn’t really call that recertification because I wouldn’t ask the user to certify what they have. But, having the user see what they have through an automated message allows you to get through some initial data clean up.
Another use case could be starting with more security-intelligent folks if the managers aren’t used to accesses (meaning security coordinators); information security folks having them go through a level of access governance prior to integration with the business.
The next phase of use cases that are useful in quick “wins” is done through the role management use case. This not only involves the business from a role management perspective when interviewing and showing them potential role models and getting them to accept it. It also involves creating a use case around the governance of the role model so that the business is involved in the continual management of the role model going forward.
Finally, the manager re-certification use case is key, because that’s probably the largest one across the organization. Insuring that there is an automated way to govern user access at the direct-report level is often important from a regulatory compliance perspective. The use case is typically required to fulfill a specific business requirement.
Brent Starnes, Regional Director - South/Central
Question: Can a simulated provisioning approach accelerate the role out of an access governance solution?
Response: The biggest thing about differentiating simulated from automated provisioning is that with automated you typically have an adaptor or connector that is directly connected into target systems. Therefore, the identity product can use anything that is done through that connector for auditing purposes. With simulated, the workflow send the request to the user but we aren’t actually pushing the permission through that instance. Instead, we are relying on the administrator for that system to create the provisions and the access that was requested.
To the question of how to simulate the provisioning that accelerates the role out of access governance, in the normal first or second phase rollout you are probably only going to connect your high-value systems like active directory. But, you still want to know what access users have to other end users to target systems. For instance, you might have financial or HR systems. So, instead of taking the time to set up that connector to get the audit information into your identity system, you stand up the simulated provisioning. This allows you to go ahead and do all the work flows and get the auditing information so when you go in to do an access recertification, you can look at the user and say, “Ok. They have these AD groups, so let’s simulate it now,” and that will show up in the report as well. With that approach you have another view that shows all the permissions and the simulated sources, as well as at the directory or the connected systems.
Stoddard Manikin, CISM, CISSP, Regional Director - Southeast
Question: Can Segregation of Duty (SOD) policies be used to clean up excessive permissions first, I.E. detective, paving the way for subsequent role out of access governance workflow?
Response: Essentially, segregation of duties is a security principle that’s primarily objectified to prevent fraud or mistakes. What happens is that some set of tasks or access rights are separated out so that one user cannot have so many privileges, such that they could perpetrate fraud or make a critical mistake to the organizations. In the real world, examples of this would include requiring two separate signatures on a paper check before that check can be issued or cashed. So, in the world of access governance, the idea is to manage a user’s access based on a segregation of duties, rules or policies. In terms of if you can use SOD to clean up the access? Yes - you can.
Typically what we recommend is that on initial clean-up of an entitlement, it really needs to be done with more of a traditional approach like a manager review. A manager review of a user entitlements will simply look at, “Does this user really require the access that they have, are they still in the same roll or job title that we granted them?” What we see usually is that an organization will clean up anywhere from 20-40% of their entitlements on that initial clean up. The reason we recommend that you do that first is because it is incredibly time consuming to identify SOD rules and policies and then apply those to your existing user access rights.
What we suggest is that you clean it up first, do those initial entitlements scrub, and then to use SOD more as a preventive control going forward rather than that detective type of review. By that, I mean putting policies in place that say when a user requests a particular entitlement or access that it is checked by an SOD matrix or list of rules and policies, so that the access is not granted at all if it would violate an SOD rule. What we recommend is using SOD polices to avoid assigning inappropriate access and then you can use it deductively later, but it is much harder to do and much more complex.
Robert Block, Vice President of Strategy & Services
Question: Based on your experience, please explain lessons learned in best practices for role out of access review/ recertification process.
Response: I think we have found that one of the strongest lessons learned was to break out the recertification process itself into phases. This should be done prior to inundating an inexperienced business with the process of access-based recertification to some extent by self-reviews, information security or administrative reviews… and ultimately the manager’s reviews. There are another set of lessons learned that are very infrastructural and aren’t necessarily tied to a set of discrete use cases in that data readiness. There needs to be some upfront attention paid to proper data analysis from IT systems perspective and a HR systems perspective. I don’t just mean modeling roles, even if you are going to do an access recertification review from an entitlement prospective and we aren’t going to do roles in the first place.
A critical lesson is the importance of have an understanding of, “What elements are unique and which data elements we are going to certify again? How we are going to certify? What attributes are we going to use?”
Understanding the readiness of that data to support the recertification process up front prohibits everyone having to operate in crisis mode. Ultimately from an access review and recertification process, if it’s going to be roles-based from a lessons-learned prospective, it’s over communication to the business having to certify that the role means something to the business world. Tying that back to the HR prospective, understanding the job title and job functions, we are seeing most often is that HR departments have started to go to generic terms to make the job title easier for us to manage in HR not understanding that there is an impact to that from the IT prospective. In the last few months we are seeing HR are more willing to expand the amount of job titles they have, understanding that there are real ties and implications into the IT world from a compliance and automation prospective.
Steve Szewczyk, Director of PMO
Question: What data elements from the HR system must be assessed and remediated prior to the launch of an access governance solution?
Response: From our experience, there are numerous attributes that are available in HR or identity and access governance. You’ve got to go ahead and identify an individual user identity. And what we find out is there are attributes such as last name, first name, date of birth, date of hire, employee ID, Global ID and email address. These can be used to identify a unique user. In addition you need to define access requirements and we found out that using location, division, apartment, job type and job title are successful to go ahead and identify access requirements. Lastly, for approval, we are looking for the existence for some type of organizational priority and manager ID. These will enable you to have an effective identity and access management strategy and solution.
Robert Block, Vice President of Strategy & Services
Question: Based on your experience, what are the highest value/ lowest risk cases that should be tactful as early quick wins as regards to access governance?
Response: I would say initially the most obvious use case where most everyone wants to start is manager or user recertification done by a direct reporting manager. So, let’s say I have some regulatory compliance that says I need a new periodic recertification of access and we are going to have our direct reporting manager take care of that. That was often the first place we started.
However, I think what we are finding now is that there are probably a number of preliminary use cases that should be done in advance of that to gain a more affective “win” once manager recertification is being done, or even earlier “wins” prior to the managers who might not be used to certifying access to date. Some of those are starting with the use cases around user review, so I didn’t really call that recertification because I wouldn’t ask the user to certify what they have. But, having the user see what they have through an automated message allows you to get through some initial data clean up.
Another use case could be starting with more security-intelligent folks if the managers aren’t used to accesses (meaning security coordinators); information security folks having them go through a level of access governance prior to integration with the business.
The next phase of use cases that are useful in quick “wins” is done through the role management use case. This not only involves the business from a role management perspective when interviewing and showing them potential role models and getting them to accept it. It also involves creating a use case around the governance of the role model so that the business is involved in the continual management of the role model going forward.
Finally, the manager re-certification use case is key, because that’s probably the largest one across the organization. Insuring that there is an automated way to govern user access at the direct-report level is often important from a regulatory compliance perspective. The use case is typically required to fulfill a specific business requirement.
Brent Starnes, Regional Director - South/Central
Question: Can a simulated provisioning approach accelerate the role out of an access governance solution?
Response: The biggest thing about differentiating simulated from automated provisioning is that with automated you typically have an adaptor or connector that is directly connected into target systems. Therefore, the identity product can use anything that is done through that connector for auditing purposes. With simulated, the workflow send the request to the user but we aren’t actually pushing the permission through that instance. Instead, we are relying on the administrator for that system to create the provisions and the access that was requested.
To the question of how to simulate the provisioning that accelerates the role out of access governance, in the normal first or second phase rollout you are probably only going to connect your high-value systems like active directory. But, you still want to know what access users have to other end users to target systems. For instance, you might have financial or HR systems. So, instead of taking the time to set up that connector to get the audit information into your identity system, you stand up the simulated provisioning. This allows you to go ahead and do all the work flows and get the auditing information so when you go in to do an access recertification, you can look at the user and say, “Ok. They have these AD groups, so let’s simulate it now,” and that will show up in the report as well. With that approach you have another view that shows all the permissions and the simulated sources, as well as at the directory or the connected systems.
Stoddard Manikin, CISM, CISSP, Regional Director - Southeast
Question: Can Segregation of Duty (SOD) policies be used to clean up excessive permissions first, I.E. detective, paving the way for subsequent role out of access governance workflow?
Response: Essentially, segregation of duties is a security principle that’s primarily objectified to prevent fraud or mistakes. What happens is that some set of tasks or access rights are separated out so that one user cannot have so many privileges, such that they could perpetrate fraud or make a critical mistake to the organizations. In the real world, examples of this would include requiring two separate signatures on a paper check before that check can be issued or cashed. So, in the world of access governance, the idea is to manage a user’s access based on a segregation of duties, rules or policies. In terms of if you can use SOD to clean up the access? Yes - you can.
Typically what we recommend is that on initial clean-up of an entitlement, it really needs to be done with more of a traditional approach like a manager review. A manager review of a user entitlements will simply look at, “Does this user really require the access that they have, are they still in the same roll or job title that we granted them?” What we see usually is that an organization will clean up anywhere from 20-40% of their entitlements on that initial clean up. The reason we recommend that you do that first is because it is incredibly time consuming to identify SOD rules and policies and then apply those to your existing user access rights.
What we suggest is that you clean it up first, do those initial entitlements scrub, and then to use SOD more as a preventive control going forward rather than that detective type of review. By that, I mean putting policies in place that say when a user requests a particular entitlement or access that it is checked by an SOD matrix or list of rules and policies, so that the access is not granted at all if it would violate an SOD rule. What we recommend is using SOD polices to avoid assigning inappropriate access and then you can use it deductively later, but it is much harder to do and much more complex.
Robert Block, Vice President of Strategy & Services
Question: Based on your experience, please explain lessons learned in best practices for role out of access review/ recertification process.
Response: I think we have found that one of the strongest lessons learned was to break out the recertification process itself into phases. This should be done prior to inundating an inexperienced business with the process of access-based recertification to some extent by self-reviews, information security or administrative reviews… and ultimately the manager’s reviews. There are another set of lessons learned that are very infrastructural and aren’t necessarily tied to a set of discrete use cases in that data readiness. There needs to be some upfront attention paid to proper data analysis from IT systems perspective and a HR systems perspective. I don’t just mean modeling roles, even if you are going to do an access recertification review from an entitlement prospective and we aren’t going to do roles in the first place.
A critical lesson is the importance of have an understanding of, “What elements are unique and which data elements we are going to certify again? How we are going to certify? What attributes are we going to use?”
Understanding the readiness of that data to support the recertification process up front prohibits everyone having to operate in crisis mode. Ultimately from an access review and recertification process, if it’s going to be roles-based from a lessons-learned prospective, it’s over communication to the business having to certify that the role means something to the business world. Tying that back to the HR prospective, understanding the job title and job functions, we are seeing most often is that HR departments have started to go to generic terms to make the job title easier for us to manage in HR not understanding that there is an impact to that from the IT prospective. In the last few months we are seeing HR are more willing to expand the amount of job titles they have, understanding that there are real ties and implications into the IT world from a compliance and automation prospective.
Steve Szewczyk, Director of PMO
Question: What data elements from the HR system must be assessed and remediated prior to the launch of an access governance solution?
Response: From our experience, there are numerous attributes that are available in HR or identity and access governance. You’ve got to go ahead and identify an individual user identity. And what we find out is there are attributes such as last name, first name, date of birth, date of hire, employee ID, Global ID and email address. These can be used to identify a unique user. In addition you need to define access requirements and we found out that using location, division, apartment, job type and job title are successful to go ahead and identify access requirements. Lastly, for approval, we are looking for the existence for some type of organizational priority and manager ID. These will enable you to have an effective identity and access management strategy and solution.
Wednesday, May 18, 2011
ISAG PART 1: Can’t find an Identity and Access Management Cookbook? Check out this Recipe!
Over the next few weeks we will be posting excerpts from select Logic Trends' Identity Strategy and Advisory Group (ISAG) briefings. Part 1 below is transcribed from a recent briefing that takes place via conference call, which is why it takes a conversational tone. Email us at sales@logictrends.com to find out how you can sign-up to be apart of future briefings.
Readiness
Attestation
Protection
Integration
Do it again
Andrew Ames, Vice President, Sales & Marketing
Question: What does readiness of identity data, strategy and organization mean to an overall RAPID value approach?
Response: Though we look at this from a readiness prospective, it’s really part of three different categories. It is a very relevant topic around data which is the ability to not just focus on technology, but readiness within the organization from a data standpoint. We’ve talked on seminars about how it really is an assessment of the data. No project is going to be successful without that recipe of the cookbook. All the projects that were discussed took that path.
Number two from the readiness prospective is setting the strategy, and this came from a pharmaceutical company that has multiple initiatives. So the ability to set a strategy to enable the organization across the different business units is imperative. Establishing a strategy with the organization that is modular in approach is imperative as well. We need to set with the business the step by step prospective so that everybody is on the same page.
The third bucket that I would talk to you about from the readiness prospective is really around the organization. So we’ve talked about people processing data and the initial point, the last point is that there is really change in the organization. The ability for the organization to understand what they are doing. Certainly steering committees are talked about or governance committees to make sure there is oversight in this. The business stake holders need to understand why we are doing this, is it efficiency, regulatory compliance, in user satisfaction or cost avoidance?
So from an organizational change management, the buy in as well as the ongoing communication is key. So those three buckets are key.
Stoddard Manikin, CISM, CISSP, Regional Director - Southeast
Question: How do you build on what Andrew has accomplished in step 1’s Readiness activity taking it to the next level during step 2’s Attestation activity?
Response: Access attestation can also be referred to as periodic access reviews or recertifications, which are typically driven by compliance requirements aside from generally good security policy. Essentially you can leverage the data that was reviewed that was a part of the ready process that Andrew discussed.
Look through your data and you will have output from that assessment that tells you what accounts are actually attributed to individual users, where you have accounts that are orphaned or shared, and which accounts don’t have managers or supervisors to support them. What this does is allows you to do a cleanup of access. Doing a cleanup of existing access will take care of all of the various entitlements that have been accumulated over the lifetime of the employee and the relationship with the organization. This is really essential before you move on to the next stage because you want to have data that is as clean as possible.
You can also capture the account’s entitlements from your target application based on the information during the ready step where you analyze an application list. You can take that and go out and connect to those applications or gather extracts from those applications, pull those account’s entitlements into a central entitlements repository, and then execute your recertification campaign with managers and supervisors using a tool or using the old email and spread sheet method.
The managers and supervisors will have to know how to do the recertification, but really this shouldn’t take more than a few weeks. This allows you to get back which access is appropriate, and which access needs to be cleaned up, which is generally called remediation. You really want to remediate the results within the target application so you’ll be set up for the next step - Protection.
Buck Bell, Vice President, Identity Management Practice
Question: Now that Attestation is complete, what are you doing with the Protection of assets?
Response: One of the interesting of the protect assets stage of the rapid process is that this is an opportunity where they can begin introducing some formal concept of roles into the organization where there might not have been before. It’s a fair question to say, "If I’m going to vet entitlements that users own, against what standard am I going to vet them?"
You can approach that on an atomic level where you evaluate users on a one-by-one basis, but as you begin the cleanup process you have an opportunity to introduce the business roles context. Initially, that may be very high level to the employee contractor type of stuff, but you may begin to drill down to departmental type of level as well. This ends up being an enabler to the protect assets phase in the sense that now you are beginning to enable more than just the manager community to be a part of the work flow processes associated with access request. In this phase, you are really looking to extend the audit benefits that you set in the prior phase.
So you are allowing some users in the community to use the identity management tools themselves to make requests for access to certain assets. During this phase you are pushing it out a little more and making it more business friendly. And again, one way to do that is through a role context. You may allow more people to make more atomic requests for specific applications or assets. This does begin to empower more of the nontechnical user community to be able to use the systems that are in place.
Now typically in this phase you are introducing some of the identity management software components. And, as a consequence of that, you are going to begin reaching out a touching some of the systems internally. But, what we have found in these phases is you are well-served to really take advantage of what ends up being called a simulated or a manual provisioning approach for many systems. You may have core systems like an active directory that are well understand, and you may want to do some electronic integration at that point, but that's the best way to get the greatest value out of the work you have done.
In many cases you are more interested in having more consistent work flow processes than you are trying to work through the nuts and bolts of electronic integration for each of these applications. So again, you’ll insert a larger number of users in the process and allow them to make requests for access to resource and assets. Those will go through work flow approval process and at the end of the work flow process you’ll see that application custodians are still manually adding the accounts and then going back and attesting that they have done so to close the audit loop. Again, this is a way of getting a higher number of applications into the context of the identity system to realize quick value of the solution in a shorter amount of time.
Another aspect of this is, this may be a time to begin to introduce and authoritative linkage between a force like an HR system and the newly formed global identity that you’ve created for a user. So in order to do this, you have to set up the identity system and start pulling data in from the prior step to create a clean view of that user from the get-go so that you are not just replicating the orphan status that you’ve seen from the past. This protect-assets phase is really the one that begins to have a lot greater of visibility in the organization.
Brent Starnes, Regional Director - South/Central
Question: How do you extend what Buck accomplished during the Protect phase to provide deeper electronic empowerment and lower administrative effort?
Response: So you’ve been working on this for a few months and have a pretty good idea what your data looks like. If you have this job code, you know you should have these different access roles in our target system. So at this point we need to go ahead and set up electronic provisioning connectors into some limited systems so you can start creating and managing accounts in the system.
We are focusing on electronic provisioning, so what we want to do is keep this limited to small chunks and phases in 3 months or less. In order to keep this limited to 3 months, you have to decide which 3 applications are the priority. To do this, you do applications that are common... that everyone has done. We will also - depending on the business - do a point of sale system, or maybe an employee portal or something that is straight forward and still has high impact to the business. This will be something that administrators dedicate a lot of time creating or maintaining accounts so it has high value, but nothing that has a real complex back end where we have to write a custom connector. Occasionally we’ll see folks use Rack up into phase one but that’s fairly rare because rack up is a little bit complicated.
The last thing I want to talk about are the use cases. When you talk about provisioning there are about 21 different use cases that you can use, so you want to limit the use cases that you tackle in the first phase or you are never going to get it done in the 3 months. Typically the use cases that you 'll want to do are to manage the creation of employee accounts and the directory in the two other applications. We will usually not just create the account; there is work flow involved where you send notification to managers. You will also want to create some basic birthright roles maybe based on job code.
Determination is more important than that. Contractor management is normally done in this phase as well. Some companies will have contractor management system in place which will be one of the 3 apps that we tie into, but those who don’t will typically use the identity management system as the authoritative source for contractors. This involves standing up forms within the idea system that can be used to create contractors and terminate contractors extend their access and things of that nature.
We usually do some service account management in this first phase as well. It’s important that you differentiate your actual user objects from service accounts. Sometimes in the first phase we will also do automatic updates of user information. Simple things like attributes, phone numbers and addresses will go ahead and automatically push those through the end system. Things like last name changes you want to avoid pushing through the end phases because things are a little bit more complex. Department transfers are things you want to avoid in this first phase as well because it can be pretty complicated. Usually when someone transfers departments they need to keep access to what they already have for 30 days, and need to have access to additional things for 30 days, so defining all that and managing all that is a bit trickier and we typically push the use case off to another phase.
Employee to contractor conversions and rehires are along the same lines, and are very difficult to recode and maintain. And, any kind of advanced birthright provisioning, such as really detailed groups or entitlements of applications, usually takes a little more detail and time to define all the access that everyone needs we usually do that in later phases.
Phillip Lentz, Chief Technology Officer
Question: What does D stand for in R.A.P.I.D.?
Response: D stands for "DO IT AGAIN." "Do it again" means you have seen how to do the major use cases that makeup the identity management program in the previous four steps. So now you have more knowledge to do this. Our goal here is to empower you to "DO IT AGAIN." Repeat step A, the attestation where now you might bring additional compliance related application in to the "A" step of RAPID, and then you - the customer - takes more ownership of the protectingtion, step 3, and then integrations of more connectors, step 4.
So, do it again... reset... and go back to step 2, the attestation. You now have more ownership. We then become more of a source for guidance, assistance and issue management for you. It’s more cost effective for you to hire full time resources that we can teach, train and empower. Now we are simply assisting and you are leading, whereas in the first integration we were leading with your assistance. So DO IT AGAIN is key, and it lowers your costs.
The goal here in the DO IT AGAIN step is to determine your deliverables. Number one, it’s time to have incremental releases that are scheduled throughout the year, it’s as though you are a product development shop. Identity management needs to be treated that way. What this means is that in the "D" (Do it again) step, you need to schedule releases where you might have 2.1, 2.2, 2.3 and 2.4 each year where you have perhaps 4 minor releases and 1 major release.
Tis approach is key to keep things going. You have the knowledge. The user communities have been maturing. They understand how the product works; they have been trained through communication plans. You can add more functionality. They will demand more functionality. The more they see, the more they will want. They will like what you have done and they will ask why you haven’t done more. The reason why you haven’t done more is simply because if you did too much, your project would’ve more than likely failed. So with thatbeing said, do it again, start it over and continue to have four releases throughout the year.
If you are familiar to the Agile Approach to software development, you would see there are correlations to that. It’s all about low-risk, incremental successes building upon the momentum that was establish from the infrastructure, and maturity that was established as a relation to performance. Really, the change of the organization maturity that was established was due to slowly allowing the end user community to digest more and more usability and the user inter-phase type.
Readiness
Attestation
Protection
Integration
Do it again
Andrew Ames, Vice President, Sales & Marketing
Question: What does readiness of identity data, strategy and organization mean to an overall RAPID value approach?
Response: Though we look at this from a readiness prospective, it’s really part of three different categories. It is a very relevant topic around data which is the ability to not just focus on technology, but readiness within the organization from a data standpoint. We’ve talked on seminars about how it really is an assessment of the data. No project is going to be successful without that recipe of the cookbook. All the projects that were discussed took that path.
Number two from the readiness prospective is setting the strategy, and this came from a pharmaceutical company that has multiple initiatives. So the ability to set a strategy to enable the organization across the different business units is imperative. Establishing a strategy with the organization that is modular in approach is imperative as well. We need to set with the business the step by step prospective so that everybody is on the same page.
The third bucket that I would talk to you about from the readiness prospective is really around the organization. So we’ve talked about people processing data and the initial point, the last point is that there is really change in the organization. The ability for the organization to understand what they are doing. Certainly steering committees are talked about or governance committees to make sure there is oversight in this. The business stake holders need to understand why we are doing this, is it efficiency, regulatory compliance, in user satisfaction or cost avoidance?
So from an organizational change management, the buy in as well as the ongoing communication is key. So those three buckets are key.
Stoddard Manikin, CISM, CISSP, Regional Director - Southeast
Question: How do you build on what Andrew has accomplished in step 1’s Readiness activity taking it to the next level during step 2’s Attestation activity?
Response: Access attestation can also be referred to as periodic access reviews or recertifications, which are typically driven by compliance requirements aside from generally good security policy. Essentially you can leverage the data that was reviewed that was a part of the ready process that Andrew discussed.
Look through your data and you will have output from that assessment that tells you what accounts are actually attributed to individual users, where you have accounts that are orphaned or shared, and which accounts don’t have managers or supervisors to support them. What this does is allows you to do a cleanup of access. Doing a cleanup of existing access will take care of all of the various entitlements that have been accumulated over the lifetime of the employee and the relationship with the organization. This is really essential before you move on to the next stage because you want to have data that is as clean as possible.
You can also capture the account’s entitlements from your target application based on the information during the ready step where you analyze an application list. You can take that and go out and connect to those applications or gather extracts from those applications, pull those account’s entitlements into a central entitlements repository, and then execute your recertification campaign with managers and supervisors using a tool or using the old email and spread sheet method.
The managers and supervisors will have to know how to do the recertification, but really this shouldn’t take more than a few weeks. This allows you to get back which access is appropriate, and which access needs to be cleaned up, which is generally called remediation. You really want to remediate the results within the target application so you’ll be set up for the next step - Protection.
Buck Bell, Vice President, Identity Management Practice
Question: Now that Attestation is complete, what are you doing with the Protection of assets?
Response: One of the interesting of the protect assets stage of the rapid process is that this is an opportunity where they can begin introducing some formal concept of roles into the organization where there might not have been before. It’s a fair question to say, "If I’m going to vet entitlements that users own, against what standard am I going to vet them?"
You can approach that on an atomic level where you evaluate users on a one-by-one basis, but as you begin the cleanup process you have an opportunity to introduce the business roles context. Initially, that may be very high level to the employee contractor type of stuff, but you may begin to drill down to departmental type of level as well. This ends up being an enabler to the protect assets phase in the sense that now you are beginning to enable more than just the manager community to be a part of the work flow processes associated with access request. In this phase, you are really looking to extend the audit benefits that you set in the prior phase.
So you are allowing some users in the community to use the identity management tools themselves to make requests for access to certain assets. During this phase you are pushing it out a little more and making it more business friendly. And again, one way to do that is through a role context. You may allow more people to make more atomic requests for specific applications or assets. This does begin to empower more of the nontechnical user community to be able to use the systems that are in place.
Now typically in this phase you are introducing some of the identity management software components. And, as a consequence of that, you are going to begin reaching out a touching some of the systems internally. But, what we have found in these phases is you are well-served to really take advantage of what ends up being called a simulated or a manual provisioning approach for many systems. You may have core systems like an active directory that are well understand, and you may want to do some electronic integration at that point, but that's the best way to get the greatest value out of the work you have done.
In many cases you are more interested in having more consistent work flow processes than you are trying to work through the nuts and bolts of electronic integration for each of these applications. So again, you’ll insert a larger number of users in the process and allow them to make requests for access to resource and assets. Those will go through work flow approval process and at the end of the work flow process you’ll see that application custodians are still manually adding the accounts and then going back and attesting that they have done so to close the audit loop. Again, this is a way of getting a higher number of applications into the context of the identity system to realize quick value of the solution in a shorter amount of time.
Another aspect of this is, this may be a time to begin to introduce and authoritative linkage between a force like an HR system and the newly formed global identity that you’ve created for a user. So in order to do this, you have to set up the identity system and start pulling data in from the prior step to create a clean view of that user from the get-go so that you are not just replicating the orphan status that you’ve seen from the past. This protect-assets phase is really the one that begins to have a lot greater of visibility in the organization.
Brent Starnes, Regional Director - South/Central
Question: How do you extend what Buck accomplished during the Protect phase to provide deeper electronic empowerment and lower administrative effort?
Response: So you’ve been working on this for a few months and have a pretty good idea what your data looks like. If you have this job code, you know you should have these different access roles in our target system. So at this point we need to go ahead and set up electronic provisioning connectors into some limited systems so you can start creating and managing accounts in the system.
We are focusing on electronic provisioning, so what we want to do is keep this limited to small chunks and phases in 3 months or less. In order to keep this limited to 3 months, you have to decide which 3 applications are the priority. To do this, you do applications that are common... that everyone has done. We will also - depending on the business - do a point of sale system, or maybe an employee portal or something that is straight forward and still has high impact to the business. This will be something that administrators dedicate a lot of time creating or maintaining accounts so it has high value, but nothing that has a real complex back end where we have to write a custom connector. Occasionally we’ll see folks use Rack up into phase one but that’s fairly rare because rack up is a little bit complicated.
The last thing I want to talk about are the use cases. When you talk about provisioning there are about 21 different use cases that you can use, so you want to limit the use cases that you tackle in the first phase or you are never going to get it done in the 3 months. Typically the use cases that you 'll want to do are to manage the creation of employee accounts and the directory in the two other applications. We will usually not just create the account; there is work flow involved where you send notification to managers. You will also want to create some basic birthright roles maybe based on job code.
Determination is more important than that. Contractor management is normally done in this phase as well. Some companies will have contractor management system in place which will be one of the 3 apps that we tie into, but those who don’t will typically use the identity management system as the authoritative source for contractors. This involves standing up forms within the idea system that can be used to create contractors and terminate contractors extend their access and things of that nature.
We usually do some service account management in this first phase as well. It’s important that you differentiate your actual user objects from service accounts. Sometimes in the first phase we will also do automatic updates of user information. Simple things like attributes, phone numbers and addresses will go ahead and automatically push those through the end system. Things like last name changes you want to avoid pushing through the end phases because things are a little bit more complex. Department transfers are things you want to avoid in this first phase as well because it can be pretty complicated. Usually when someone transfers departments they need to keep access to what they already have for 30 days, and need to have access to additional things for 30 days, so defining all that and managing all that is a bit trickier and we typically push the use case off to another phase.
Employee to contractor conversions and rehires are along the same lines, and are very difficult to recode and maintain. And, any kind of advanced birthright provisioning, such as really detailed groups or entitlements of applications, usually takes a little more detail and time to define all the access that everyone needs we usually do that in later phases.
Phillip Lentz, Chief Technology Officer
Question: What does D stand for in R.A.P.I.D.?
Response: D stands for "DO IT AGAIN." "Do it again" means you have seen how to do the major use cases that makeup the identity management program in the previous four steps. So now you have more knowledge to do this. Our goal here is to empower you to "DO IT AGAIN." Repeat step A, the attestation where now you might bring additional compliance related application in to the "A" step of RAPID, and then you - the customer - takes more ownership of the protectingtion, step 3, and then integrations of more connectors, step 4.
So, do it again... reset... and go back to step 2, the attestation. You now have more ownership. We then become more of a source for guidance, assistance and issue management for you. It’s more cost effective for you to hire full time resources that we can teach, train and empower. Now we are simply assisting and you are leading, whereas in the first integration we were leading with your assistance. So DO IT AGAIN is key, and it lowers your costs.
The goal here in the DO IT AGAIN step is to determine your deliverables. Number one, it’s time to have incremental releases that are scheduled throughout the year, it’s as though you are a product development shop. Identity management needs to be treated that way. What this means is that in the "D" (Do it again) step, you need to schedule releases where you might have 2.1, 2.2, 2.3 and 2.4 each year where you have perhaps 4 minor releases and 1 major release.
Tis approach is key to keep things going. You have the knowledge. The user communities have been maturing. They understand how the product works; they have been trained through communication plans. You can add more functionality. They will demand more functionality. The more they see, the more they will want. They will like what you have done and they will ask why you haven’t done more. The reason why you haven’t done more is simply because if you did too much, your project would’ve more than likely failed. So with thatbeing said, do it again, start it over and continue to have four releases throughout the year.
If you are familiar to the Agile Approach to software development, you would see there are correlations to that. It’s all about low-risk, incremental successes building upon the momentum that was establish from the infrastructure, and maturity that was established as a relation to performance. Really, the change of the organization maturity that was established was due to slowly allowing the end user community to digest more and more usability and the user inter-phase type.
Monday, May 9, 2011
Webinar: Identity Management - Front and Center for Healthcare Providers
Webinar Details:
• Tuesday, May 24th
• 12:00 pm to 1:00 pm EST (9:00 am to 10:00 am PST)
• Complimentary
• Register
Who Should Attend:
• CIO, CMIO
• Information Security, CISO, Risk Officers
• HIPAA, Compliance Officers, IT Audit
• IT Architects
• IT Infrastructure
• Clinical Applications Staff
ARRA, the American Recovery and Reinvestment Act of 2009, provides a framework to incent healthcare providers and physicians to use health information technology in a meaningful way. In order for healthcare providers to meet the requisite criteria and enhance their ability to address strengthened HIPAA requirements, they must take a long-term view that is consistent with their strategic IT objectives, associating proven Identity and Access Management controls.
Join us for this one-hour live webinar in which healthcare and technology experts present a case study and a recommended plan of action that will help you to:
• Define and institute an Identity and Access Management program that is best aligned with the HIPAA requirements associated with Meaningful Use;
• Streamline the transition to digitized healthcare records;
• Enhance the security posture to best enable protection of private patient health data;
• Increase incentive eligibility by demonstrating meaningful use of EHR systems;
• Effectively manage appropriate levels of access and streamline the access certification process across clinical, business and financial applications;
• Provide a centralized access request system that efficiently delivers access and ensures appropriate controls are put in place to meet compliance and audit requirements for the long term;
• Enable migration from legacy directory infrastructures that inhibit enterprise IAM adoption.
Hosts:
Jackie Gilbert, Vice President, Marketing & Founder – SailPoint
Andrew Ames, Vice President, Marketing – Logic Trends
Larry Wolf, Regional Sales Director – Logic Trends
• Tuesday, May 24th
• 12:00 pm to 1:00 pm EST (9:00 am to 10:00 am PST)
• Complimentary
• Register
Who Should Attend:
• CIO, CMIO
• Information Security, CISO, Risk Officers
• HIPAA, Compliance Officers, IT Audit
• IT Architects
• IT Infrastructure
• Clinical Applications Staff
ARRA, the American Recovery and Reinvestment Act of 2009, provides a framework to incent healthcare providers and physicians to use health information technology in a meaningful way. In order for healthcare providers to meet the requisite criteria and enhance their ability to address strengthened HIPAA requirements, they must take a long-term view that is consistent with their strategic IT objectives, associating proven Identity and Access Management controls.
Join us for this one-hour live webinar in which healthcare and technology experts present a case study and a recommended plan of action that will help you to:
• Define and institute an Identity and Access Management program that is best aligned with the HIPAA requirements associated with Meaningful Use;
• Streamline the transition to digitized healthcare records;
• Enhance the security posture to best enable protection of private patient health data;
• Increase incentive eligibility by demonstrating meaningful use of EHR systems;
• Effectively manage appropriate levels of access and streamline the access certification process across clinical, business and financial applications;
• Provide a centralized access request system that efficiently delivers access and ensures appropriate controls are put in place to meet compliance and audit requirements for the long term;
• Enable migration from legacy directory infrastructures that inhibit enterprise IAM adoption.
Hosts:
Jackie Gilbert, Vice President, Marketing & Founder – SailPoint
Andrew Ames, Vice President, Marketing – Logic Trends
Larry Wolf, Regional Sales Director – Logic Trends
Thursday, May 5, 2011
An Effective Approach to Meeting Today’s Healthcare Security & Privacy Requirements with Identity Governance
The following is an Executive Summary from the new solution brief by Logic Trends and SailPoint. Please email us at sales@logictrends.com to request your digital copy of the complete whitepaper.
Healthcare providers are confronting the reality that regulatory compliance is now a factor of everyday business life. The HITECH Act of 2009 brought significant new business and technology challenges that providers must grapple with, starting now. And, in 2011, healthcare providers have the opportunity to demonstrate progress in their HIPAA compliance efforts. For compliant organizations there are significant financial incentives, but if organizations fail to comply, there are increased risks and penalties.
As the healthcare industry moves more and more toward electronic and personal healthcare records, protecting privacy and security becomes even more important. In addition to compliance pressures, there are significant risks of data breaches and theft of identity data.
SailPoint and Logic Trends are partnering to help providers adopt a risk-based approach to meeting HIPAA security and privacy requirements and to safely move toward adopting the meaningful use of electronic health records (EHR). The partnership is based on strategic consulting and best practices as outlined by the proven IAM5™ Process from Logic Trends and SailPoint IdentityIQ™, a next-generation identity management solution built from the ground up to help healthcare providers automate and streamline their user management processes, thereby enabling stronger HIPAA controls.
This paper profiles the regulatory and EHR challenges facing healthcare providers, focusing on the key role played by identity governance in addressing those challenges. It reviews guidelines for meeting the HIPAA privacy law’s requirements for administrative, physical, and technical safeguards and offers recommendations for how providers can build a sustainable approach to HIPAA compliance and an integrated set of controls across all identity and access management processes.
Healthcare providers are confronting the reality that regulatory compliance is now a factor of everyday business life. The HITECH Act of 2009 brought significant new business and technology challenges that providers must grapple with, starting now. And, in 2011, healthcare providers have the opportunity to demonstrate progress in their HIPAA compliance efforts. For compliant organizations there are significant financial incentives, but if organizations fail to comply, there are increased risks and penalties.
As the healthcare industry moves more and more toward electronic and personal healthcare records, protecting privacy and security becomes even more important. In addition to compliance pressures, there are significant risks of data breaches and theft of identity data.
SailPoint and Logic Trends are partnering to help providers adopt a risk-based approach to meeting HIPAA security and privacy requirements and to safely move toward adopting the meaningful use of electronic health records (EHR). The partnership is based on strategic consulting and best practices as outlined by the proven IAM5™ Process from Logic Trends and SailPoint IdentityIQ™, a next-generation identity management solution built from the ground up to help healthcare providers automate and streamline their user management processes, thereby enabling stronger HIPAA controls.
This paper profiles the regulatory and EHR challenges facing healthcare providers, focusing on the key role played by identity governance in addressing those challenges. It reviews guidelines for meeting the HIPAA privacy law’s requirements for administrative, physical, and technical safeguards and offers recommendations for how providers can build a sustainable approach to HIPAA compliance and an integrated set of controls across all identity and access management processes.
Thursday, July 23, 2009
IAM and SaaS/Cloud Computing
As we hit the mid-point of 2009, Corporate America has not yet rebounded from the recent tough economical environment. Shrinking budgets, tightened spending, resource cuts - Logic Trends has witnessed these same spending trends regardless of the type of industry. We believe these trends will likely continue into 2010. Therefore, creativity and flexibility are cornerstones of IT spending for the foreseeable future.
Interestingly enough, the requirements, however, have not changed. Organizations must increase security, increase regulatory compliance, and optimize IT workloads – All with less or a more multipurpose IT staff. It is also important to understand that these challenges / requirements are common regardless of the size of the organization. In reality, it is even more important today to truly understand who has access to what and how to manage and report on that access effectively, but with increased fiscal constraints.
Let’s face it – deploying an IAM system, as it exists today, is costly and time consuming. Organizations need to invest in analysis and requirements-related work, vendor evaluations, proof of concepts, hardware and software spend, prototyping, development and integration services, internal resource training, and enterprise communications and marketing costs. Given the amount of required investment, IAM deployments rarely show high Return on Investment (ROI) until a number of years after the initial deployment. Logic Trends has developed its IAM5 Methodology for the purpose of being able to somewhat forecast and lessen the costs and risks associated with these deployments, but not even a mature methodology will offer enough immediate return for some organizations (especially the small to medium-sized business).
This is where Software as a Service (SaaS) or Cloud Computing comes into play. These concepts haven’t become a reality in the IAM space specifically yet, but as the major IAM vendors look for new ways to grow business and offer IAM solutions to increasingly diverse clients, these concepts will become much more important. If you are not familiar with Cloud Computing or SaaS please view the following for more information:
http://csrc.nist.gov/groups/SNS/cloud-computing/
or
http://en.wikipedia.org/wiki/Cloud_computing
Where does IAM fit into the Cloud?
Simply put, IAM concepts fit very nicely into the cloud. Think about the basic components of any IAM deployment – first, you have the business processes that any technology-based solution must support, and second you have an application server, a web server, a database, and a user repository. In addition, there could be provisioning connectors, additional databases/data stores, multiple directory domains, target systems, and other third-party tools.
Now think about the basic components that could make up a “cloud”:
Storage networks
Servers
Zones/partitions
Load balancers
Network components
Technology Stack
The intriguing bullet on that list is the “Technology Stack”. The Technology Stack includes application servers, web servers, caches, databases, etc; all the components necessary to deploy an IAM system internally today. One of the main benefits of deploying an application in that stack is that once the IAM software and necessary development/configurations/customizations (including connectors) has taken place, the risks associated with availability, scalability, and maintenance are absorbed by the vendor managing the cloud. For organizations already on tight budgets, this could provide reductions in costs associated with storage, daily maintenance, and training administrators, and end users.
Additionally, there is potential in separating the various modules that make up an IAM solution into individual SaaS solutions. One of the most commonly discussed modules is authentication. Authentication, especially web or enterprise SSO, remains one of the hardest IAM functionalities to deploy and manage properly. How would organizations respond if they could simply point toward the cloud, have users enter their credentials via whatever authentication service, have the secure token services layer handle any authentication conversion, and the user is granted access to whatever applications are managed in the cloud? Couple that with a federation model and the possibilities could be endless.
Finally, showing the cloud’s true potential and versatility, Joe McKendrick of ZDNet recently wrote an article about the cloud’s flexibility and introduced an interesting idea from George Ravich, Chief Marketing Officer of Fundtech – Services, in general, could be offered like songs on iTunes. We can take it one step farther with IAM. Although there would most likely be legal hurdles to overcome, a publically available, iTunes-like program would allow various IAM vendors to offer IAM applications/modules for organizations to download, IAM workflows/frameworks/connectors for purchase and modification, third-party integration firms and developers could offer their services and expertise, and a community could be established for organizations to discuss product improvements and challenges.
Deploying an IAM solution in the cloud conceptually makes sense from both a technical and business perspective. Its benefits are many, the technology already exists for other industries, and in the current economic climate the demand is present. However, we are still some time away from rapid adaptation. There are still some risks that need to be overcome by both the consumer organization and the service providers – how to overcome the issue of data localization, how to restructure licenses, how to design their own architecture to be flexible enough, how to provide privacy, governance, and assurance in the cloud and the legalities and how-to’s related to managing third party tools…all of which are rather large hurdles.
Despite the challenges, IAM as a SaaS/cloud offering is definitely on the horizon as we’re already seeing glimpses of progress. Hitachi ID Systems recently launched an outsourced IdM Administrator service offering for its password management product (Password Manager), Sun and Oracle are authoring white papers involving cloud computing/SaaS and its possibilities, and with the focus Microsoft has been putting on its cloud computing offering called Azure Services Platform (allows an organization’s applications to be hosted and new applications to be built in various languages), the future for IAM will soon be the present.
Come back for the next blog where we will dive into the technical side of common use cases that could be supported by IAM in the cloud.
Interestingly enough, the requirements, however, have not changed. Organizations must increase security, increase regulatory compliance, and optimize IT workloads – All with less or a more multipurpose IT staff. It is also important to understand that these challenges / requirements are common regardless of the size of the organization. In reality, it is even more important today to truly understand who has access to what and how to manage and report on that access effectively, but with increased fiscal constraints.
Let’s face it – deploying an IAM system, as it exists today, is costly and time consuming. Organizations need to invest in analysis and requirements-related work, vendor evaluations, proof of concepts, hardware and software spend, prototyping, development and integration services, internal resource training, and enterprise communications and marketing costs. Given the amount of required investment, IAM deployments rarely show high Return on Investment (ROI) until a number of years after the initial deployment. Logic Trends has developed its IAM5 Methodology for the purpose of being able to somewhat forecast and lessen the costs and risks associated with these deployments, but not even a mature methodology will offer enough immediate return for some organizations (especially the small to medium-sized business).
This is where Software as a Service (SaaS) or Cloud Computing comes into play. These concepts haven’t become a reality in the IAM space specifically yet, but as the major IAM vendors look for new ways to grow business and offer IAM solutions to increasingly diverse clients, these concepts will become much more important. If you are not familiar with Cloud Computing or SaaS please view the following for more information:
http://csrc.nist.gov/groups/SNS/cloud-computing/
or
http://en.wikipedia.org/wiki/Cloud_computing
Where does IAM fit into the Cloud?
Simply put, IAM concepts fit very nicely into the cloud. Think about the basic components of any IAM deployment – first, you have the business processes that any technology-based solution must support, and second you have an application server, a web server, a database, and a user repository. In addition, there could be provisioning connectors, additional databases/data stores, multiple directory domains, target systems, and other third-party tools.
Now think about the basic components that could make up a “cloud”:
Storage networks
Servers
Zones/partitions
Load balancers
Network components
Technology Stack
The intriguing bullet on that list is the “Technology Stack”. The Technology Stack includes application servers, web servers, caches, databases, etc; all the components necessary to deploy an IAM system internally today. One of the main benefits of deploying an application in that stack is that once the IAM software and necessary development/configurations/customizations (including connectors) has taken place, the risks associated with availability, scalability, and maintenance are absorbed by the vendor managing the cloud. For organizations already on tight budgets, this could provide reductions in costs associated with storage, daily maintenance, and training administrators, and end users.
Additionally, there is potential in separating the various modules that make up an IAM solution into individual SaaS solutions. One of the most commonly discussed modules is authentication. Authentication, especially web or enterprise SSO, remains one of the hardest IAM functionalities to deploy and manage properly. How would organizations respond if they could simply point toward the cloud, have users enter their credentials via whatever authentication service, have the secure token services layer handle any authentication conversion, and the user is granted access to whatever applications are managed in the cloud? Couple that with a federation model and the possibilities could be endless.
Finally, showing the cloud’s true potential and versatility, Joe McKendrick of ZDNet recently wrote an article about the cloud’s flexibility and introduced an interesting idea from George Ravich, Chief Marketing Officer of Fundtech – Services, in general, could be offered like songs on iTunes. We can take it one step farther with IAM. Although there would most likely be legal hurdles to overcome, a publically available, iTunes-like program would allow various IAM vendors to offer IAM applications/modules for organizations to download, IAM workflows/frameworks/connectors for purchase and modification, third-party integration firms and developers could offer their services and expertise, and a community could be established for organizations to discuss product improvements and challenges.
Deploying an IAM solution in the cloud conceptually makes sense from both a technical and business perspective. Its benefits are many, the technology already exists for other industries, and in the current economic climate the demand is present. However, we are still some time away from rapid adaptation. There are still some risks that need to be overcome by both the consumer organization and the service providers – how to overcome the issue of data localization, how to restructure licenses, how to design their own architecture to be flexible enough, how to provide privacy, governance, and assurance in the cloud and the legalities and how-to’s related to managing third party tools…all of which are rather large hurdles.
Despite the challenges, IAM as a SaaS/cloud offering is definitely on the horizon as we’re already seeing glimpses of progress. Hitachi ID Systems recently launched an outsourced IdM Administrator service offering for its password management product (Password Manager), Sun and Oracle are authoring white papers involving cloud computing/SaaS and its possibilities, and with the focus Microsoft has been putting on its cloud computing offering called Azure Services Platform (allows an organization’s applications to be hosted and new applications to be built in various languages), the future for IAM will soon be the present.
Come back for the next blog where we will dive into the technical side of common use cases that could be supported by IAM in the cloud.
Subscribe to:
Posts (Atom)