Several years ago, as Sarbanes-Oxley (SOX) and other mandates started to challenge IT managers, it became obvious that the current approach for managing users was ineffective. Security controls were often weak, security processes were inefficient and decentralised, and worst of all, critical financial and banking applications and information were not adequately protected from improper access.
Enter identity and access management (IAM). IAM became a hot topic for financial institutions because of the significant benefits that it promised – improved security, increased efficiencies and reduced costs, simplified compliance, and enablement of new business opportunities. That’s a marketer’s dream of a ‘value prop’, and with that list of benefits, IAM should have sold itself. And, in some respects, it has. Virtually all of the largest financial and banking institutions have deployed some form of an IAM solution over the past few years, and the benefits have been significant.
Before we look at where IAM is going, let’s agree on what it is. The definition of IAM is definitely in the eye of the beholder. However, comprehensive IAM would include the following components:
- Identity and role management – centralise the control of user information and accounts, and associate access rights based on user roles.
- Provisioning – automate the creation and deletion (de-provisioning) of user accounts and entitlements.
- Web access management – centralise policy enforcement for access to critical applications, including single sign-on.
- Privileged user management – control actions by privileged users (administrators) to prevent improper activity.
- Data loss prevention – enforce policies on what users can do with the data that they access.
- User activity and compliance reporting – automate the collection, analysis and reporting of all user activity.
- User directories – some mechanism to store information about each user and their attributes, roles, etc.
Other components, such as strong authentication solutions, etc, are often included in IAM, but the components above are the core of a good IAM strategy. Figure 1 highlights the key components of an IAM platform.
IAM systems have succeeded, for the most part, because they focused on two critical areas for financial firms: protecting confidential corporate and customer information, and simplifying compliance. Let’s look at a typical use case to see how these systems might be used. A large banking institution would centralise the management of all user accounts and identities across all of their thousands of employees. This would eliminate (or at least reduce) the multiple identities that each user often had spread across many IT systems. They would deploy a provisioning system that would automate the process of creating accounts and access rights for each new employee. They would also create a hierarchy of user roles within the organisation, and assign access rights based on the job requirements of each role. They would then create central policies for which systems, applications and information each employee could access.
So, for example, a credit manager might be granted access to a particular credit evaluation application, but not to any other strategic application that the institution might use. This manager might only be allowed access from their work computer and during normal work hours. If it was smart, the firm would adopt some form of data loss prevention, so that it could try to prevent a rogue (or even thoughtless) employee from transferring sensitive financial information outside the organisation. And, finally, it might deploy some sort of system log management solution that would help automate the collection and analysis of system log files.
What’s Next for IAM?
These systems have worked well, in part because they focused on what these institutions care most about – controlling user identities and access to financial information. But here’s the rub. These financial institutions allow access to confidential information for certain employees – for authorised use. In the case above, the credit manager probably has access to a customer’s complete financial information (account numbers, social security number (SSN), etc) because this information is needed in the credit analysis process. But traditional IAM systems stop at the point of access – that is, once they determine if you can access a given resource, their job is done.
If, for example, the employee wants to access the customer banking records for a valid purpose, the IAM system will only grant that access if the employee is authorised to access that information. But how do you know what that employee does with the data once they get it? Do they copy it to a thumb drive to take home with them? Do they email it to one of their friends? What about those plans for a new bank marketing campaign, or the new pricing for the new banking services that you are getting ready to roll out? How do you know that a rogue employee isn’t sending that info to one of your competitors?
These examples illustrate and are driving the next likely evolution for IAM technologies. Analysts are starting to call this phase ‘content-aware IAM’ because it reflects the fact that decisions about policy enforcement within the IAM system will be made not only based on who the user is and what their access rights are, but by the actual content of the data. For the first time, the content of the data will impact not only policy enforcement, but also potentially the user’s roles and entitlements. This is an exciting evolution of IAM technologies because it has the potential to significantly expand the breadth of capability, as well as the benefits, of an IAM platform.
Let’s look at quick scenario to see the power of this approach. Let’s say that George is in the finance group at 2Big2Fail Inc, a large multinational banking firm. As such, he has access to the Finance Sharepoint site where they store confidential financial information. He is authorised to see certain financial information (e.g. inter-bank transactions) but not other types (e.g. corporate revenue numbers). One day, he attempts to open a spreadsheet he finds on the Sharepoint site. Before granting the access, the IAM system analyses the file’s contents (in addition, of course, to his access rights) and determines that this is ‘sensitive financial data’.
George is not authorised to see this type of financial information, so the access attempt is denied. Later, George opens a spreadsheet that he is authorised to use. But for whatever nefarious reasons, he attempts to copy this info to a thumb drive to take home with him. The IAM system intercepts the attempted transfer, determines that this is sensitive information that should not be transmitted externally, and denies the attempt. It also enters this into the security log for later analysis.
Undaunted, George attempts to email the spreadsheet to his Gmail account. The IAM system again denies the attempt because the content is sensitive and this operation violates information use policies. But this time, it not only enters it into the security log, it sends an email alarm to the IT compliance manager for immediate action, and dynamically alters George’s entitlements so that he can no longer access any confidential financial information. The result is not only that this rogue employee is prevented from violating information use policy, but his attempt causes his entitlements to change dynamically based on the content of the data and his attempted actions. In effect, the entire IAM system ‘learns’ that George is attempting to violate use policy and modifies its responses accordingly.
Content-aware IAM has the potential to be an important evolution of traditional IAM technology, because it adds an entirely new attribute – the content of the data – to the overall IAM approach. Financial institutions have serious challenges both in the areas of information security and regulatory compliance. This approach has the potential to significantly improve information security enforcement, as well as make compliance audits somewhat less painful.
How treasury stands to benefit from blockchain: Ripple’s goal to revolutionise cross-border transactions
Imagine a world where cross-border transactions can occur in real-time, at a few cents per transaction, to and from any bank, in any ... read more
Europe’s opening banking regulation is finally here. After months of preparation across the continent, the Revised Payment Services Directive comes into effect on January 13.
The revised Payment Services Directive regulation, regarded as one of the most disruptive in Europe’s financial services sector, will begin to make an impact on January 13, 2018.
The cost of compliance efforts for banks has increased exponentially in recent years. This is especially true for those banks that are active in the global trade finance domain, where the overwhelming expectation is for compliance requirements to become even more complex, strict and challenging over time.