The importance of scoped access in the customer identity access management market space
30 March, 2016
category: Digital ID
By Marla Hay, director of product management, Janrain
It’s only the third month of 2016, and according to the Identity Theft Resource Center (ITRC), there have already been 139 reported data breaches, resulting in almost 4.3 million exposed user records. For all businesses where internal data was exposed, this can mean compliance breaches and employee identity fraud can result. For businesses where customer data was exposed, this can additionally result in broken customer trust, loss of existing or new business or lawsuits which can result in hefty fines. Ideally, all data breaches would be prevented. However, this is not always the reality. In this article, we discuss how scoped access can help mitigate the damage.
For context, the user record count includes any incident in which the individual name plus a critical identifier like a Social Security number, driver’s license number, medical record or financial record (credit/debit cards included) is exposed, but it doesn’t include records which expose usernames, emails and passwords without involving sensitive personal identifying information — this would drive the total record number even higher (ITRC lists these breach incidents but without the total number of records exposed). While some of this information was exposed by hackers accessing databases or physical theft of unencrypted data or devices, others were exposed through subcontractors or employee error, specifically involving phishing attacks or allowing their access information to fall into the wrong hands.
The more people who need or use data, the more exposure to the possibility for unintentional data leaks. Scoped access helps by ensuring that only the minimum level of data is available to each individual.
The Identity Theft Resource Center report lists a number of examples, including a phishing attack on a hospital resulted in four staff email accounts being compromised. Such email accounts could be used to reset passwords in related systems to access protected data. In another case, a company was the victim of an email spoofing attack, in which the employee provided information to whom they believed to be the CEO, when in fact, it was a malicious third party. At a large data storage company, an employee was tricked into providing Social Security numbers and other personal data through a phishing attack as well.
These types of breaches are damaging when they occur with partner or employee data, but they can be devastating when they occur with customer data. In 2013, Target’s data breach of 40 million credit and debit card numbers, plus 70 million customer records (including addresses and phone numbers), resulted in a fine of $252 million. For a company like Target, this isn’t a crippling sum, but the financial penalty could be a major burden for a smaller organization. And even if financial information isn’t exposed, the customer relationship will be damaged when customers no longer trust the organization to be a good steward of their data.
So – how does scoped access help? The more people who need or use data, the more exposure to the possibility for unintentional data leaks. Scoped access helps by ensuring that only the minimum level of data is available to each individual.
Support, marketing, technical and administrative employees in an organization access customer data for different reasons. As a support person, an employee may need to access customer login information to assist a user who is trying to log in, or provide information to them about their account data. To this end, the support person should be able to see the information they need to to support the customer. The support person should not however, have access to the password information for the user, but instead is able to trigger a password reset flow that requires the user to validate their identity. This approach protects the support person from the phishing techniques discussed above, where data was provided to a malicious party masquerading as someone entitled to the data. For all other data, it’s always preferable for the support person to facilitate the user’s ability to self-authenticate and manage data, rather than providing direct access to the data itself.
In another example, a technical employee may need access to end user data in order to validate implementations or to confirm that products are functioning as expected. The technical employee may need access to an administrative level of data, in order to program the interfaces that move user data from place to place. In as many cases as possible, the technical employee should use test or dummy data to do all development and testing of any implementation or integration. Once the testing is complete and the system is turned on, any authorization granted should be abstracted out to a key and secret or administrative user if possible and stored in a secure vault which is accessed in a programmatically secure way. Those technical users with access to such privileged data should be minimized in an organization with strict rules in place about how and when that information can be shared.
The idea of scoped access isn’t new, but the stakes and roles change when the data introduced is customer rather than internally focused.
Quite the opposite of the technical employee, a marketer may need the user data in order to guide decisions on where to invest advertising and develop programs on how to improve customer relationships or market to groups similar to their current user base. In this case, individual user information should be limited or avoided if possible. Instead, users should be segmented and analyzed statistically to provide marketing with the aggregate view of the users that they need to generate value out of the user data.
Scoped access is already a tenant of good access management practices for an internally focused IT organization. Information Technology Infrastructure Library (ITIL) emphasizes access management as part of the Service Operations portion of the framework, highlighting the need for information security management that enables the organization to “..manage the confidentiality, availability and integrity of the organisation’s data and intellectual property,” as highlighted in the Universities and Colleges Information Systems Association’s (USICA) ITIL guide. Scoped access is part of the process that allows an organization to maintain the confidentiality of its information by ensuring employees have the right level of access to do their jobs, but not more. When used in conjunction with audit logs and the ability to easily grant and revoke access, scoped access is a critical part of a comprehensive access management strategy, so much so that it’s often a required part of security and control certifications. The idea of scoped access isn’t new, but the stakes and roles change when the data introduced is customer rather than internally focused.
As discussed in the earlier description of the roles of users who access customer data, there is a wider range of employees who may need access to customer vs. internal data. A marketing organization needs to understand the customer base to improve targeting and relationship building efforts, technical teams need to develop integrations and tools that utilize customer data, and support staff needs to assist customers with their accounts. An organization won’t just need to limit access to the data, but will need to limit access to specific types of data as well. This makes the ability to create a custom access level a critical feature need in the Customer Identity Access Management (CIAM) space.
There are a few ways in which scoped access can be accomplished in a Customer Identity Access Management. The most flexible is to allow the ability to generate scoped API access to the customer data. This means generating an API client with read and/or write access to specific fields. Generating this level of access allows an organization to build user interfaces on top of the data that can grant access at a fine level of granularity. It can be used to create a GUI that allows different support personnel to have exactly the right access based on their seniority or area of expertise. It also allows an organization to build scripts and integrations that are permitted to see exactly the data they are allowed to consume. This is especially helpful when integrating with third party tools that don’t require Personally Identifiable Information (PII), such as business intelligence, segmenting, or data science tools. It means there is far less risk in adding these types of integrations to your platform – because there’s no risk of customer data exposure due to security lapses caused by the third party.
Another mechanism for scoping access is through interfaces that only allow specific data to be shown. Customer Identity Access Management tools that have interfaces built for a particular function can supercede the need for specialized APIs by providing the graphical user interface that an employee needs to get exactly the data they need, and none of the data they don’t. Customer resource management tools are built for exactly this type of work, allowing employees to access customer records at precisely the right level. Likewise, business intelligence tools can work similarly, allows employees who are entitled to see aggregated data see only that information, while allowing employees with more privileged access the ability to see the records behind the aggregate as well.
There is a wide variety of ways and means of establishing scoped access for customer specific data. The mechanism isn’t important, as long as an organization thinks through all of the customer data they hold and establish who, how, and when that data can be accessed by all of the roles within the company.
About the author:
Marla Hay is a director of product management with over ten years experience in developing and managing web software. Marla started life as a software developer and quickly grew a passion for reducing friction in user experiences, which led her towards the direction of product management. In previous positions, she has managed development and lifecycle of customer support platforms and enterprise monitoring services. In her current role at Janrain , she manages a portfolio of products contribute to expanding the user identity market space. Marla has a Bachelors of Science in Computer Science from Cornell University and a Masters of Science in Computer Science from Johns Hopkins University.
