Insurance companies handle sensitive data for a large set of clients. They operate in a highly regulated industry and need to comply with both external and internal compliance frameworks such as PRIIPs, GDPR, MLD4, IFRS4, IDD, HLA, ISO27001, NIST etc.
Insurance companies must know exactly who has what access, but the reality is that this is a major gap in most insurance company’s security architectures.
Permissions and authorizations are often managed in siloed IT platforms and applications that might provision and even enforce access control. The siloed nature makes this approach cumbersome, error prone and inefficient. In order for a Claims Manager to know that a Claims Agent has the correct access to a Customer Portal that manages claims and contracts, for example, they likely need to ask the IT department, who would need to research the specific request. Many companies attempt to subvert the inefficiency by simply granting broad brush strokes of access to employees, which creates unprecedented security risk. Errors that stem from manual provisioning only add to this risk and create inefficiencies for the business. One of the biggest concerns is the time and money being spent by IT to administer these siloed platforms.
PBAC offers a centralized approach to streamline secure business processes and to simplify back-office and IT permission management processes. This approach ensures that the right users have access to the right data at the right time without the hold up of slow, sometimes even manual, internal processes.
At insurance companies there are a multitude of business rules that could govern how client data can and should be accessed. These can relate to basic client profile data such as home address, type of relationship with the insurance company and active client contracts.
The client’s information such as customer profile information, personal records and insurance claims typically have specific rules for access. This type of data is what we can consider basic insurance data that a 3rd Party Agent or Claims Agent might need to access in their daily business activities. There is also other data that needs even more restrictions such as a Client Risk Score or Claim Investigations where the insurance company has more detailed access rules.
A policy example in natural language:
Note that there are no references to specific agents in the policy. Neither are there any references to specific Insurance Client Profiles, Insurance Policies or Claims. The PlainID visual representation of the policy allows for a simplified and understandable view of who can access which data, down to the fine-grained layer. It also shows under which circumstances and what reasons the users are able to access the data. You can also see that one policy can govern the access control through multiple applications. On the right side of the UI, you can see two different applications, the Agent Insurance Portal and the Call Center Application, and both use the same policy ensuring the same user experience across multiple applications.
This example policy demonstrates the efficiencies and flexible access control that PBAC offers over a traditional Role Based Access Control (RBAC) model. Implementing an RBAC structure to support the policy requirements above would be nearly impossible or at least force the Insurance Company to implement hundreds or even thousands of Roles causing a massive administrative burden.
Even though the basic policy above is very effective in segregating access to an Insurance Company’s Client’s data and thereby supporting basic privacy requirements aligning with the “need-to-know” principle, there are far more sophisticated privacy rules that must be incorporated. Below we have outlined some of these rules for our use case.
At run-time when the 3rd Party Agent tries to access a Client Profile through an Insurance Application, the application sends a simple request to the PlainID authorization rule engine.
In order for the rule engine to be able to provide an “informed decision” the authorization service needs to access the underlying Insurance data. This includes the identity data and the asset data, but also the referential data, meaning the relationships between relatives, black listed agents and VIPs/PEPs. This data could be retrieved from a variety of systems including SQL, LDAP, SCIM, REST API’s etc.
The rule engine evaluates the current user’s (in this use case, the 3rd Party Agent) role and 3rd party company to compare this data with the current Client Profile data to be able to reach an access decision for the basic policy.
In addition, the rule engine also evaluates the restrictive rules that are part of the advanced restricted policies e.g. the 3rd Party Agent’s colleagues, relatives’ potential blockings.
Of course, we can also use the policy decision to enable appropriate access. This approach can support access based on a “white list” or, for example, if the Insurance Agent is assigned as a “Personal Agent” to a client or a set of clients.
After evaluating all the granting access policies and the restrictive policies, the rule engine can provide an authorization decision and/or the information that Insurance Application needs to enforce the correct access for the 3rd Party Agent/Manager.
The application may use this information in-application for many purposes. Maybe it is used to provide a decision if the user needs to have access to a functional tab in the application (coarse-grained resource) or maybe the access should provide more fine-grained access due to a specific Client Claim Investigation.
By unifying and externalizing the authorization logic from the Insurance Application, we can now start maintaining the life-cycle of the policies in a separate process from maintaining the application logic.
The benefit of having two processes is that they now can change independently from each other. This is often very important for insurance companies that struggle with supporting the ever-changing compliance frameworks, both internal and external.
The visibility offered through the PlainID solution ensures that no one is able to access beyond what they should, and that the business knows at all times who has access to what.
The financial benefits of PBAC include a cost reduction in application development and application maintenance efforts but also in the user management processes where PBAC provides efficiency and clarity to the business. In the longer term, significant financial and strategic benefits relate to the efforts of being able to stay compliant with regulations over time, and to be able to continuously onboard new technologies in a secure and efficient fashion.
Furthermore, the compliance control gains can decrease data breaches as well as the number of records affected by each breach. The accounting of access decisions and their enforcement is complex and voluminous. Adoption of PBAC forces an organisation to standardize the dimensions of the authorization landscape to identify and define users, roles and resources (data, applications, other). With standardized taxonomies on which to pivot access control policies the accrued benefits include not only simplification, but greater transparency around who is accessing what, when, how and why. This makes control attestation for effectiveness a much easier process in order to self-assure compliance and audit teams that information control compliance requirements are being met.
