Identity Access Management, or IAM, is, in a nutshell, a system used to ensure that the right individuals have access to the right resources at the right times and for the right reasons. In a modern large organization the relationships between the individuals and the resources can be very complex. What complicates the situation even further is the need to ensure the access is done for the right reasons. Organizations impose a host of rules on who can and cannot access applications and the underlying data, since permission to run applications are normally associated with data access, and the data can be proprietary, PII, and otherwise not open for public consumption. Identity management solutions apply these rules to determine the level of access for every user and every resource. One of the most significant concerns is Segregation of Duty (SoD) requirement. SoD policies are put in place to significantly reduce the risk of illegal, unethical or otherwise damaging activities. SoD rules is a big part of compliance, such as SOX compliance or 21 CFR Part 11 compliance. Failure to follow proper procedures can result in non-compliance, data leaks, and data breaches.
Traditionally, identity and access management has been implemented by building a custom solution based on a relational database. Relational databases are not flexible enough to deal with the highly dynamic nature of data in the IAM systems. Relational databases are not good at representing relationships, either. The main reason is because in order to represent the relationships multiple tables have to be joined, a process that becomes prohibitively slow for IAM data of large organizations.
Graph databases, as all NoSQL database, have no predefined data schema. This flexibility of the data model makes adding, modifying or deleting roles, profiles, and access rights a transparent task that doesn’t disrupt the normal operations of the organization. It also eliminates the redundancy of storing the same data in multiple records. The multiple joins that have to be executed in a SQL database to combine multiple dimension tables are effectively executed when the graph is created. This feature is unique for graph databases and sets them apart from other NoSQL, and SQL, databases; it allows graph databases to deal with complex relationships in a transparent and expedient fashion.
One of our major customers was faced with the increasing complexity of their entitlement provisioning and de-provisioning system and wanted to get a handle on it. Their first goal was the ability to 'predict' the impact on the risk profile of the organization by a change to any aspect of the entitlements before making the change. With the existing entitlement system, which is based on a relational database, this task would have been prohibitively slow to implement and to run.
Another goal was to expedite the process of explanation to the business users what changes to the entitlements cause spikes in risk metrics. Again, with the existing system using a relational database such a task usually turned out to be a several day project for an investigation team.Our customer was in search of a better solution. They reached out to us with the hope that we can do something, and they were not disappointed in the end.
Entitlement provisioning process goes through a labyrinth of enterprise roles, application profiles and roles, entitlements to connect end users with the applications and data they need to access as part of their work activities. This is where graph databases really shine. They are designed to capture the complexity of relationships, to follow the 'trail' from the users to the applications and data in a very transparent fashion.
We piloted a graph database solution for their entitlement system to achieve their goals. We were able to reduce the development time for the database queries from weeks to days, and reduce the query execution times from hours to seconds. We were also able to provide a way to explain the spikes in risk metrics without doing any extra work as an additional benefit. Probably one of the most rewarding moments during our engagement was when the manager and the team members of the customer shared with us that they found it more natural to think about their entitlement data applying the graph database concepts of nodes and relationships.
Now, they have a more ambitious goal of performing a proactive analysis: instead of simply responding to changes, they want to be able to discover actions that will help theme lower the risk posture. We have reasons to believe that the graph database approach will be able to help them achieve this goal, as well.
Authored by: David Makovoz, TCS Cyber Security