Posted by Jim McDonald on Mon, Apr 30, 2012
In our Kickstart advisory engagements, we normally recommend that our clients deploy an Access Recertification process. Even when access provisioning has been automated, access recertification should be used to certify not only that users still “work here” but also that their access is appropriate. This is particularly valuable in cases in which the user population being recertified is not managed by an authoritative system, such as an HR system. For example, contractors are rarely managed within a corporate HR system. Usually, their roles and privileges are managed within the IAM system directly.
So What is Access Recertification?
Access recertification is known by different names in different organizations. You may know it as an attestation campaign, access certification, entitlements review, access governance, or even access audits. Whatever it is called, it equates to doing the same thing: a periodic, conscious review by a designated reviewer (a person), of what access users have to a given system. It is a detective control.
Ideally an access review consists of a list of users (for example in an ERP application) and their role in that system. This list will be distributed to managers or ‘sponsors’ (the people who are responsible for users). Managers review the list and flag any inappropriate access, or, simply sign-off that all users on the list have appropriate access. It helps to provide collateral such as a glossary of entitlements, system roles and what they give a user access to.
It can also be argued that recertification campaigns done without a tool are less accurate. One advantage of recertification tools is that they leverage a provisioning eco-system and enact the changes in real-time on the source systems.
Process
Any recertification process needs to be well communicated and well orchestrated. Whether your organization agrees to a quarterly or semi-annual cycle, it is key that there is a business owner with management clout to stress its importance to the rest of the organization. Typically, this should fall in the lap of the Compliance Officer, CISO or CSO.
Other keys to making the process successful are:
- Performing regular training events for those managers who perform certifications. Webinars are a great way to accomplish this.
- Making sure recertification campaigns time-bound. This entails setting deadlines that are realistic, yet aggressive, which will ensure that the process completes within a desirable time frame. The idea is to minimize any risk, for example, quickly eliminating unauthorized access, and by doing so, minimizing risks.
- Developing metrics and a dashboard to track the completeness of each campaign. This will be key in enforcing the need to comply with the recertification campaign. (Show the results to senior management)
Technology
The role of technology in performing access recertifications is to make them more accurate and efficient. I know of an organization that performs an effective access recertification process with spreadsheets, email, and Sharepoint. This solution may not be scalable but it still helps mitigate risk.
Often packaged with role engineering functionality, and in some cases bundled with provisioning products, recertification tools can greatly improve the efficiency and accuracy of a recertification campaign. Here’s a typical process, which is both efficient and accurate:
- Data from source systems is fed to the recertification tool’s database automatically via an ETL tool (extract, transform and load). This process can be batched and scheduled, essentially eliminating the human factor.
- Conduct access reviews via a web-based interface (goodbye spreadsheets). Access is reviewed and a button is clicked to approve or reject. All of these events are logged for later audits.
- Finally, when access changes are required (for example, complete termination of access) then a provisioning system can be leveraged to automate changes, and handle any exceptions.
People (don’t forget the people)
The owner of the Access Recertification process will be key to its success. The person needs to bring passion to the position. They will be called upon to answer questions from managers who are confused by the process, and may even question why it needs to be done. This owner must be a people-person but at the same time they need to care deeply about the integrity of the process.
One of the biggest flaws with recertification processes (with or without tools) is that those who are certifying the access don’t take the job seriously. Many are just “checking the box” or “rubber stamping”. The approach I favor to combat this is part carrot and part stick. The carrot would be to appeal to the approving manager’s sense of duty – to mitigate the risk of the organization. The stick can best be wielded with the implied risk that they could lose their job if they are negligent in their responsibility. How you communicate the stick is up to you – it needs to fit your organization’s culture. The owner will need to have standing with the senior management of the organization. Ideally the owner would be the CISO or CSO.
Posted by Jim McDonald on Mon, Apr 23, 2012
Privacy is a hot topic in all industries. In higher education it is mandated by two regulations FERPA in the US and FIPPA in Canada.
Both regulations give students the right to have their identity omitted from public directories and more. This presents a special challenge for the IAM practitioner who must provision data to applications.
FERPA
FERPA is the Family Educational Rights and Privacy Act of 1974. The best source of information on this legislation, not surprisingly, can be found on the US Government’s website. When it comes to IAM, the most relevant passage is the following:
“Schools may disclose, without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance. However, schools must tell parents and eligible students about directory information and allow parents and eligible students a reasonable amount of time to request that the school not disclose directory information about them.”
Universities in the U.S. are allowed to publish elements of a student record that are not considered an invasion of privacy. However, there must be a process to make the student aware of her rights under FERPA, and provide the option to opt-out. According to the U.S. Education Department’s “FERPA for Students” website, Universities need to notify individuals of their rights and can use various methods including the student newspaper. The student must also be informed of their right to restrict the publishing of their “directory” information and the time period in which they must opt-out.
Most universities err on the side of caution and use multiple channels to communicate a student’s rights under FERPA. The University of Texas at Arlington’s FERPA website gives clear guidance on its intent to publish student “directory” information and has a link where registered students can request their information be restricted.
FIPPA
FIPPA is the Freedom of Information and Protection of Privacy Act. Many provinces have additional privacy legislation that can increase FIPPA’s bite in regards to privacy regulations. I’ve heard anecdotally that British Columbia has the tightest restrictions on publicizing student data. British Columbia’s FIPPA “Resource for Public Bodies” contains deep information on FIPPA’s applicability in BC. Most provinces have a similar guideline published on their websites.
As with FERPA in the U.S., FIPPA covers personal information for anyone including members of the public, students and employees. The U.S.’s FERPA is solely focused on student privacy. FIPPA does have some exceptions for employees when it comes to work-related information (work-related information would not include information like home address for example). Exceptions like this do not exist for students – for them, even their name is considered private information. The term “data banks” is used similarly to FERPA’s “directory” information. Note that there is separate Canadian legislation covering personal health information (PHIPA – the Personal Health Information Protection Act) and private sector employees (PIPEDA – the Personal Information Protection and Electronic Documents Act).
The biggest difference between FERPA and FIPPA is that FIPPA can be an “opt-in” model. So by default, student information in a data bank, cannot be made public without a student’s consent. One key to the administration of FIPPA is that the student who chooses to exercise her privacy rights under FIPPA cannot be penalized or have her academic progress affected by her decision.
The impact of FERPA and FIPPA on IAM
Privacy adds another level of complexity to the management of identity information. Data is frequently moved from the IAM system to destination applications through provisioning tools. Data is also made public through web interfaces, such as searches within the identity management system. Since some students opt-out (expressly or by default) of having their information visible, the IAM system must have a way to hide or obfuscate their data.
One way I’ve seen universities handle this issue is through a FERPA or FIPPA flag. This flag by itself can only store information – yes/no – public/private – or a date when the student “opted-out”. However, context must be included in the provisioning logic or in the application.
To hone in on the complexity this can create for IAM architects, look no further than email systems. A student clearly needs an email account in order to conduct their academic pursuits. However, if they were to appear in the address book, their FIPPA rights could be violated. The IAM and Email teams must collaborate on how provide a student email while protecting their privacy under FIPPA. The likely scenario is to set a provisioning rule to exclude students who do not consent to being displayed publically.
To formalize the process of governing provisioned data, I’ve seen “data sharing agreements” used to set the ground rules. It is an important step to “memorialize” an agreement that may need to exist beyond the tenure of the managers who agreed (for example) that fullname cannot be shown in anywhere in the application UI.
Finally I wanted to mention the complexity created by the fact that students can also be university employees. As employees, they do not have the same rights under these regulations. This brings up the person vs. persona debate – ergo, should student-employees have separate IDs for each role? Assuming one ID per person, systems need to become context-aware to handle the student persona differently than the staff persona.
Summary
At first glance it might not make sense why someone would be so concerned about having their name listed in a directory. “Big deal… someone can see who goes to school here, right?” But in reality, there are people who are being stalked and victims of domestic violence, celebrities and their relatives and people who just want to remain anonymous. While IAM systems can be designed to provide that privacy, proper IAM Governance is essential to ensuring that private data in IAM systems can be appropriately shared with other IT systems without violating the privacy rights of protected individuals.
Posted by Jim McDonald on Tue, Apr 17, 2012
One of the hardest cases to make for any CTO or CIO is that reducing helpdesk calls or saving users 45 seconds per login is a true cost save. Typically referred to as “soft savings” they are considered inferior to “hard savings”. Hard savings are judged by the qualifier “how many people can I fire? … give me names.” It is now more important than ever for organizations to drive efficiency to remain competitive.
A methodology common in manufacturing and other industries is Lean Six Sigma. This methodology focuses on wringing out waste from the mundane workplace activities (processes, tasks). An example that comes to mind is a shop floor where factory workers make several trips per day to get a commonly used part. The lean six sigma solution would be to move the part closer or at least shorten the path to retrieve the part. Lean is not limited to manufacturing – Denver Healthcare used it to turn around its operations and profitability.
Kaizen events are workshops that focus on a single business process, usually using re-enactments or white-boards. The goal is to identify unnecessary steps or steps that can be made more efficient. This can be applied to almost any industry or any business process.
The shop floor example identified a process optimization that might only save 20 seconds per round trip. However, multiplied over several times per day, many days per year, performed by many different people and perhaps applied to many different processes – the time-savings can be substantial.
The question becomes – how can this be quantified. When faced with the question of “who can I fire?” you need to be able to say “nobody, but…” and follow it with a meaningful metric related to machines per year, patient satisfaction, or dollars per hour wasted.
What spurred me to pen this article was a study performed internally by Mahaska Health Partnership. The study applied Lean Principles to Identity Management and coined the phrase “authentication waste.”
They started by process-mapping their authentication flow. By eliminating waste from the authentication process for registered nurses, it was able to “give back” 45 minutes per day to nurses. More important than reducing costs by “firing someone” they were able to redirect their focus from the computer to the patient.
Identropy has mused on this topic in past blogs – check out “Death by Clicking”. The focus was on single sign-on in a clinical healthcare setting and how long it takes to open a patient record. 15 seconds seems to be the acceptable threshold. Getting down to 5 seconds is the nirvana. But…can this be achieved without using shared anonymous accounts?
We work with a lot of healthcare organizations and the problem is universal. Every second counts which is why technology that allows for badge access and biometrics for authentication are really taking hold. These technologies do a good job of guaranteeing security while minimizing the total time spent in authentication.
The business proposition is clear for healthcare. Roaming nurses and physicians need fast access to systems that can be accessed on stationary desktops, kiosks, or mobile devices. The applications (mostly client-server) each require authentication, but doctors and nurses can’t be expected to keep track of dozens of passwords.
Single sign-on applications (used in conjunction with virtual desktop) pay for themselves through improved clinician productivity and patient satisfaction. Through Lean Six Sigma, the wasted seconds can be quantified and the business case can be made.
Posted by Frank Villavicencio on Thu, Apr 05, 2012
A few months ago, I wrote a few blogs about trends in Healthcare and why these were making Identity a top of mind issue in the Healthcare sector.
As we continue to work with clients in Healthcare, we are seeing that many of the trends we had identified are at play before our eyes, and from this experience, we see patterns that may very well apply to other industry verticals outside of Healthcare, and as you would suspect, we are myopically focused on what these means to identity.
The main trend in healthcare that we see is Consolidation. It is happening at all levels. Healthcare organizations are growing through M&A - and the intensity of activity seems to be increasing in 2012. This triggers the consolidation of different medical offices, hospitals and long-term care centers into a larger healthcare system. And with this comes the need to consolidate clinical, financial and ancillary systems to achieve consistency and economies of scale.
In turn, this trend has translated into intense M&A activity in the Healthcare IT space – examples such as the acquisitions done by AllScripts, Siemens Healthcare, GE Healthcare Systems in recent years. In a way, these acquisitions are forcing consolidation and standardization across EMR, EHR, PACS, Pharmacy and other systems. Healthcare CIOs are really busy working with their Clinical Informatics team, and their vendors to figure out which systems they should standardize on (regardless of whether or not the Healthcare organization is embarking on M&A activity itself).
What does this mean to IAM then?
As I once explained in a prior blog, IAM is relatively new as a discipline, managed as a program in healthcare. For many organizations, Chief Information Security Officers are in their first or second year at the job, since it was just created. And as such, many organizations are struggling with how to scale their IAM platforms (in the event they even had one) to keep up with the consolidation and growth that the organization is likely experiencing.
IAM budgets in Healthcare are very tight, which makes keeping up with these trends particularly challenging and exciting at the same time.
So what is an identerati to do?
- If your organization is embarking on an M&A and business application consolidation strategy, you should view IAM as an enabler, rather than a barrier for the organization to execute this strategy. IAM will be front and center of the action. Therefore, you should have a defined IAM program with a governance model in place
You need to have a practical data or application classification methodology which can help you figure out which system or application needs to be integrated with IAM first and to what degree (i.e. automated vs. manual provisioning, local or externalized authentication, local or externalized authorization). We recommend that you define an “application grid” in which you map risk levels to a set of IAM integration requirements that the application will need to satisfy. This will help you devise a scalable and repeatable way to bring applications under governance. I recommend to customers that they define a risk/assurance level approach to classifying and tackling applications. This way it is easier to manage the IAM-fication of applications at a program level.- When it comes to managing access, truly consider roles-based model. Managing at a granular level may not be practical, and is certainly not scalable. Often, organizations think that they are not ready to adopt roles management when in fact they need them badly. I discussed this topic in a past blog. But if you need to integrate new medical staff offices and hospital into the consolidated EMR or EHR system, your IAM program will be better served by mapping the new organizations to existing roles that are defined and likely integrated with the IAM access request, approval and provisioning system. To make decisions as to how the mapping should be done or whether new templates or roles are needed, involve the business stakeholders! Avoid, at all costs, having IT make decisions about who should have what access in the application, let alone approve such access. IT is a facilitator not an owner. There are some corollaries to this point that are worth discussing:
- If you end up being too granular, you won’t scale – it will be hard for end users to manage access for their users (i.e. managers will get confused), and it will be really hard for the IAM program to scale and not lose momentum.
Are you really that unique? For many organizations, defaulting to a myriad of access permutations is typically given as justification since "the organization is that unique". In my experience working with hundreds of organizations, I have found quite the opposite: most organizations, particularly in similar industry verticals have a lot in common, and rather than managing access by exception, would be much better off managing by roles.- If you are really that unique, do you need to be? Having to accommodate so many access permutations to systems may be indicative of bigger business issues which will likely result in increased complexity, which will be contrary to the desired state of an M&A growth strategy. To be agile in integrating and consolidating, you will need to divide and conquer, and that means you have to define common business processes that can be manageable and that can scale. IAM is no exception. So feel free to challenge the business when you see complexity getting out of hand.
- The more permutations you need to manage the more fun your auditors will have when assessing the effectiveness of your access controls, particularly for highly visible, highly sensitive systems.
In summary, a risk/assurance application categorization model along with a pragmatic roles-based access control model for managing user access to applications are the key elements in helping your IAM program achieve scalability, and this is not exclusive to an industry vertical.
Posted by Mike Trachta on Fri, Mar 02, 2012
Today I want to talk about a very simple idea:
A successful implementation begins and ends with a successful partnership.
This may sound obvious, but you'd be surprised how many people don't understand this concept. I've seen customers who are more concerned about extracting everything they possibly can from a vendor that they lose sight of their goal. They point to the vendor any time a deadline is missed or a mistake is made.
I've also seen software vendors and integrators who seem to care more about landing a deal and maximizing revenue that they fail to serve their customers in the best way possible. They look for excuses when things go awry, and resort to making up answers to issues. This does not build trust with a customer.
I recently completed a project with a healthcare organization that understood this very well. The project wasn't the biggest technical challenge, but it was going to noticeably affect everyone in their organization, most notably their help desk who was going to have to handle calls for the new system. However, we didn't see the same resistance we see when implementing visible change at other organizations. We were even able to get buy-in from the doctors, which is often a challenge in itself in healthcare.
The customer sponsor, the implementation team, the help desk and Identropy had all formed mutual trust with one another. Because of this, we were able to effectively communicate the benefits of the project and work together towards a successful implementation. One member of the customer's implementation team even told me they liked Identropy from the start because we were willing to say "I'm not sure about that, let me get back to you" to questions before even landing the deal.
We ended up going live with barely a blip on the radar. There were a few things that had to be tweaked after feedback from end users, but nothing major.
And one other thing, the project was also completed WAY under budget. Part of it was due to changes in the initial scope. Most of it was due to two things:
-
We rarely had the communication issues that can arise from looking out for #1, and
-
With guidance, the customer was willing to take on some of the work even though they weren't formally trained on the product.
Rather than focusing on CYA and individual interests, we focused on the project. I attribute this to the fact that the customer saw the value of our partnership, and viewed myself and Identropy as "Trusted Advisors" rather than just another vendor. On the flip side Identropy understood the value of the project, and rather than just billing just because we had the hours, we truly worked in the customer's best interests.
After wrapping up that project I joined an ongoing implementation with a large telecom. Its an aggressive project. Within the next 24 months we are to design, build, test, and implement a best of breed collection of logical access controls, physical access controls, privileged access management, as well as automated and request-based provisioning for an organization that cannot tolerate any real measurable downtime. Oh, and the customer is new to pretty much all of these concepts and products and is relying heavily on Identropy's expertise.
In most situations I would call this a daunting task. In this instance I not only think its doable, but I have every confidence we will exceed expectations and deliver on-time. How can I be so confident? This customer recognizes the value of partnership. They value a work-life balance, even for their vendors. As a services vendor, I must say this is refreshing.
I just returned from my first on-site visit. The purpose of the visit was to get to know the team and build rapport. Of course I had deliverables to work on, but they could have just as easily been completed at the home office. The better we know and understand one another, the better we will communicate and work together.
Don't get me wrong, this customer can't afford to simply waste dollars just to have their vendors visit the office. Nor do they think they need to watch over us. They have assured us that they fully trust our abilities to work off-site without watchful eyes. They just understand the value of getting to know one another.
It seems like all too often we focus on short term goals rather than building lasting relationships. It's good to work with customers (and for a company) that understands the value of these relationships not only for the team members, but for the organizations themselves.
[Cross posted from mike.trachta.org]
Posted by Frank Villavicencio on Mon, Feb 27, 2012
We recently did a live webcast with Sally Hudson (Research Director, Cloud Identity at IDC) and Nishant Kaushik (Chief Architect at Identropy), where we explored how organizations can leverage the cloud to increase the ongoing value of their Identity Management (IDM) infrastructure while reducing its operating cost. The webcast featured presentations from both speakers and a demo of our SCUID Operations offering.
If you joined us for the webcast, thanks so much for participating and for all your input and questions. You can now play the recording of the webcast, and the results of the poll we conducted and a transcript of the Q&A are below.
Poll
During the webcast, we asked the audience what they considered to be the most difficult part of running an identity and access management infrastructure. The results are as follows.
Not surprisingly, the main issues are programmatic as opposed to technical - the lack of good business processes and clean data.
Questions and Answers
Q: What IAM products does SCUID Operations currently support?
A: As of today our focus has been the most difficult to manage platforms which are typically the provisioning systems. We presently support NetIQ (Novell) Identity Manager, Oracle Identity Manager, Quest ONE Identity Manager and Courion’s Products (AccountCourier and PasswordCourier). In the future we will be adding support for additional products including access management systems.
Q: Can we share some real life examples of global and large organizations that have embraced a cloud-based model for identity management?
A: A few organizations have spoken publicly in venues like the Cloud Identity Summit. Examples include Fidelity, Cigna, Bechtel. Several other organizations, which cannot be named publicly, are pursuing Cloud identity initiatives. Among them, we have seen many who already have a good handle on how to manage identities internally (within their environments), but are looking at ways in which they can manage their users’ identities when accessing cloud or SaaS applications, given that these kinds of applications are becoming an increasingly large part of their application ecosystems. These organizations, rather than extend their on-premise IDM, are looking to supplement it with cloud-based IDM solutions – sort of having a split or hybrid model. Some other enterprises, albeit not as common, have decided to move all of their IDM to the Cloud to align with their organization’s mandate to leverage the Cloud for the majority of their applications and IT infrastructure. These organizations are leading the way in Cloud identity adoption.
Q: Where is the [SCUID Operations] software being installed - in all Domain Controllers?
A: No. It does not really go with Domain Controllers, because we are not managing Active Directory directly. What we are doing is deploying it with IDM systems (i.e. Oracle Identity Manager, Novell Identity Manager, and so on). So [SCUID Operations] is connected to them, but in those cases where it needs to monitor a database or a directory, it does so via remote calls (i.e. ADSI or LDAP calls). We are not doing any deep level or intrusive installations, because we have not had a need to do so. Remote calls have been sufficient for us to be able to monitor and detect the health of the system. Therefore, we have no need to deploy software on the Domain Controllers
Q: How do I, as consultant, hand-over details of IAM customizations done for the client to Identropy so that your Ops team can takeover and provide the necessary support?
A: This comes up during our setup process. The setup process for SCUID Operations tends to be a 4 to 8 weeks engagement where the goal is not only to get the Collector deployed and baselined, but also to understand the customizations that have been done and how they impact the data that need to be gathered. In general, this will require us to gain access to any documentation about those customizations, but we also interact, conduct interviews and work with customer staff that can provide us this information. As is typical in many IDM implementations, documentation tends to be scares and spotty, this is why we have developed an interview and data gathering process. So if you were onsite working on behalf of the customer, you would likely be part of the interview process that we would go through, and we would leverage any documentation that can be provided.
Q: How long does it take to setup a customer, and how is the monthly cost calculated – is it fixed or is there a usage component?
A: The usage metric is based on complexity, which is derived from the number of workflows, number of targets, number and extend of customizations, in some cases it may even depend on the number of users or roles being managed. It varies from environment to environment, as well as the type of IDM product being used. The complexity level is assessed early on through a process that we follow, and then we use it to compute the monthly fee.
The setup fee is a bit more straightforward, typically 4 to 8 weeks, and it is typically just a multiple of the monthly fee, as it is also correlated to the environment’s complexity.
The actual deployment of the Collector and baseline configuration of the system does not usually take too much time, and what it does is “train” the system to understand the specific configuration (i.e. drivers, logs, workflows, etc.) that applies to the customer’s environment, since there is no such thing as a vanilla environment. So, the bulk of the setup time is a training period for the system.
Q: How do you demonstrate ROI? And given that the environment is so different from customer to customer, how do you ensure that the metrics that we gather?
A: The reality is that no two customers are the same in terms of their configuration and their flavors of technology. During the setup process for SCUID Operations, we train the system to gather those elements of data that are relevant to that specific customer. For instance for some customers, we focus on provisioning but not re-certifications, some customers care more about terminations than other processes, and these are the ones that we will train the system to focus on and be more sensitive in monitoring issues about. We have developed SCUID Operations to be smart enough to understand various flavors of IDM technology (i.e. Oracle, Courion, Quest) and to be able to “translate” different metrics coming from each flavor, and adjust based on the rules and sensitivity associated to this data. The UI will only show specific data that is relevant for the customer’s environment and not display those elements that are not being gathered or are not configured to be monitored. This is a result of combining the training done during the setup process with our own technology to allow SCUID Operations to effectively monitor a customer’s IDM environment.
Q: What are the culture challenges that you have encountered with the incumbent and your add-on solution? Can you discuss some of your challenges and success stories?
A: Over the last couple of years that SCUID Operations has been in production, we have learned quite a bit about the cultural elements associated with running Identity and Access Management programs, such as:
- The initial perception by customers that SCUID Operations was a way to reduce their headcount in running their IDM infrastructure. This is in fact the case, but over time, our customers have come to realize that what this truly means in practice is that their administrator’s bandwidth is alleviated. As many of them typically perform 3 jobs at the same time, SCUID Operations allows them to free more cycles so they can focus on more strategic aspects of their IDM program, rather than having to manage the IDM system. And at the same time, the subject matter expertise that we provide through our service enhances their value and their ability to improve the overall reach of their program. Culturally, this has been a change of posture from a pure headcount reduction to the realization that with SCUID Operations there is greater value above and beyond the headcount cost savings.
- We are looking at a shift with SCUID Operations where our clients first see value in just managing the day-to-day operations, but over time start to see greater value to aid their business stakeholders. For example retail customers look at SCUID Operations data to see trends and patterns about their staff: during or before the holiday season they see spikes in provisioning and password reset activity, which is later compensated after the holiday season with a spike in termination activity. These trends and patterns help customers with planning and resource allocations, and can indicate possible issues in business processes if there are discrepancies in the patterns.
Posted by Nishant Kaushik on Fri, Feb 24, 2012
If you're planning to be at the RSA Conference next week, then we'd love for you to come by Jillians (at the Metreon) on Tuesday evening. Quest and Identropy will be hosting a mixer where you'll get a chance to unwind, network with your peers over food and drinks, and chat with us about all things identity management. Hey, if you're nice, I might even pull out my iPad and show you SCUID Operations.
When: Tuesday, February 28 from 6:30 - 9:00 p.m.
Where: Jillians at the Metreon
101 4th Street
San Francisco, CA 94103
Register Today
Posted by Nishant Kaushik on Tue, Feb 21, 2012
Anyone following me on Twitter is well aware of my stance on AddressBookGate. While the tech world's initial outrage was being directed at Path, I felt that a more balanced conversation would also lay some culpability at the feet of Apple and other API platforms that were exposing data to applications like Path without any controls in the first place.
Some great investigative work has revealed just how widespread the practice (problem) is. And while everyone has promptly responded to the firestorm by announcing a myriad of fixes, patches and CYA statements, it still feels very reactive. Sure, we're taking care of location and address book data, but is there a MessageGate, PhotosGate and PlaylistGate on the horizon? Surely we need to look at this holistically, which led me to ask:
Does #AddressBookGate move the onus for ensuring responsible and ethical use of APIs from consumers to providers? /cc @defrag
Ian Glazer's inital reaction led to a more elaborate response in the form of a blog post titled "Free-ranged Ethically Treating APIs". 
His conclusion is that the need for services to innovate and the desire for platforms to become ubiquitious simply cannot be balanced with the need for usability and privacy controls for users. There is too much of a conflict at the intersection of these concerns. That may well be true, but I refuse to believe that as I don't think we've actually tried to address this particular problem. Yes, users can only get so many warnings and alerts from the applications/OS before it becomes meaningless and they start accepting them blindly. But that model originates from the same old construct of thinking about privacy in terms of opt-in and opt-out controls.
Surely some time devoted to creating a usability model for privacy policy enforcement can yield some smarter controls. Is anyone really going to install the Foursquare app without giving access to Location Services? And why would the Pandora app ever need access to the same? The app review process (ostensibly done to ensure security, among other things) should be able to catch this and enforce more than just a ToS or Developer Guidelines. Similarly, allowing users to create Privacy Profiles, much like the Sound Profiles (Silent, Meeting, etc) in the platform could open up some creative ways to address this.
Maybe it is a dream. I acknowledge the distinct possibility that ideas like these have been considered and discarded for good reasons. But one thing is clear - addressing this is going to require work and co-operation on each side of the equation, something that I believe can happen. It's a copycat industry (as AddressBookGate has amply illustrated), and if a workable solution emerges that gets acclaim, others will be quick to adopt it.
Maybe what we really need to do is add the treatment of user data and APIs to the manifesto for the first ethical iPhone. A topic for Glue Conference, maybe?
[Cross posted from Talking Identity]
Posted by Nishant Kaushik on Wed, Feb 15, 2012
RWW Enterprise just covered the latest update of PingFederate in an article titled It's PingFederate 6.6 Versus "Identity as a Service". I couldn't pass up the opportunity to comment on some details that made me cringe, so naturally this blog post was born. Please note that this is not about PingFederate in specific, a product I have no in-depth knowledge of. It's about identity concepts and architecture.
To set the table, we need to make sure we understand adaptive authentication. The concept of being adaptive is at the heart of risk-based security models, which try to align the security protocols and mechanisms being enforced on the user and the organization with the risk inherent in the activity taking place. You can check out a talk I gave last year that expands on this a great deal.
Adaptive authentication relies on being able to measure certain details about the context (is the user inside the firewall or outside, the nature of the device being used, the kind of authentication already done and, obviously, the risk inherent in the transaction) to create a risk score that then determines whether the authentication level (and thereby the level of assurance) of the user needs to be adjusted. Products like Oracle Adaptive Access Manager and (presumably) PingFederate do this by providing ways in which applications can tap into them during transactional flows (in the simplest form, during login).
The title of the article seems to pit this security model against the concept of Identity as a Service (though nowhere in the article itself does this come up). But this is by definition IDaaS, because the application is externalizing the security controls it needs to a service provided by a 3rd party provider. When done the right way, the application doesn't specify whether it needs the user to authenticate using hardware token based OTP, PhoneFactor or any other model. It simply specifies the risk factors in the transaction and lets the external service use configured policies to determine what is entailed. That way, a change in corporate security policy that switches from one authentication factor to another doesn't impact the application. On top of that, PingFederate seems to be catering to security models that rely on social (federated) login, which is obviously an IDaaS model.
And even if you presume that Scott meant it as Identity Management as a Service, or more descriptively Identity Management Software as a Service, it still doesn't hold because given the right integration points, the model shouldn't impose any restrictions on where the service is run/hosted.
The article also seems to conflate (or confuse) authentication chaining with authentication against multiple identity stores. Authentication Chaining is a way to string together multiple, distinct authentication events (often in sequence) to create a stronger level of assurance about the identity. E.g. this user authenticated correctly using their username-password AND with a One-Time-Password sent via text message to their mobile number of record. Authentication against Multiple Identity Stores is about authenticating the user only once, but by checking it against different identity stores because you're not sure which one the user is in.
AuthN Chaining vs Split over Distributed Stores (Grossly Simplified for Clarity)
The latter use case is where Virtual Directories are incredibly useful, because they can present a single, unified view to any consuming application, including an authentication application (like an SSO product). Virtual directories are also good at creating a single view of an identity whose attributes are split across multiple repositories (combining LDAP attributes with HR attributes, for instance). But this single view serves many different purposes in the IDaaS realm, especially for consuming applications and services that need that data at different points in time. It isn't simply about creating a single token during authentication that combines these attributes. That's why I don't like the assertion (quoted in the article) that PingFederate's attribute aggregation feature "makes virtual directory products unnecessary...". There are many use cases where applications that have externalized identity need access to unified identity data outside of the context of an authentication event. Unless PingFederate actually includes a virtual directory service (which would make the above statement circular), I don't see how they solve that particular IDaaS architectural need. And if you have multiple identity stores, you are going to have to address that need at some point.
So you see, in the end it is all about Identity as a Service.
[With that, I retreat into my bomb shelter to prepare for the onslaught from Paul, Pam, Patrick and Brian (who really should consider adding a silent P to the front of his name. Just for consistency)]
[Cross posted from Talking Identity]
Posted by Nishant Kaushik on Fri, Feb 10, 2012
Time and time again, we hear from organizations that are struggling with the task of managing their IAM deployments. Budget overruns and unexpected expenses, the difficulty of finding and retaining IAM specialists, the inability of an overtaxed IT department to keep up with the constant adjustments and demands on the program - these are just some of the issues that keep program managers and CIOs up at night. Organizations have come to the realization that Identity and Access Management is a program, not a project, and that the successful deployment of an Identity Management infrastructure is only the first step of a (long and) continuous journey.
Join us for a live webcast with IDC on Tuesday, February 14, 2012 at 2:00 pm EST to detail how Identity Management-as-a-Service can help overcome the challenges of successfully and cost-effectively running an IAM program. During this webinar, guest speaker Sally Hudson, Research Director within IDC's Security Products and Services group, will discuss why many of these projects fail and what operational areas need to be accounted for to help bridge the divide between project-go-live and long-term success. I will talk about and show our SCUID Operations offering that has helped many customers address their operational concerns and yield long-term and increasing value from their IDM investment. And we'll take questions too, just not about coach's decisions in a certain recent football game.
So ask yourself this:
- Would you like to reduce your IDM Operations costs by 50%, while still proving that the IDM program is meeting its goal?
- Is your IT team overburdened with IDM operational support in response to a constant stream of patches and updates that were never budgeted for?
- Do they lack the bandwidth to get to strategic new tasks in an ever-evolving, increasingly important IDM program?
- Do they lack the time or subject matter expertise to enhance your IDM solution in response to changing organizational needs and business objectives?
If so, this webcast is for you. Register now and learn how IDaaS and SCUID Operations can help you take back control of your IAM program.