Privilege Management for Healthcare Compliance and Security Teams

0 Flares 0 Flares ×

Enterprises, and small businesses work on trust. Trust between the business and the customer and trust internally inside the organization. In order to reinforce trust and make sure no violations occur, or at least we know when violations occur to take action – it is important for enterprises to manage the privileges that it affords to employees and contractors when handling customer data and business critical systems.

An example of Privilege Management

A typical example of Privilege Account Management (PAM) as noted in the PAM Gartner Quadrant is the following: Employee X of company ABC can access certain reports for consumer data but cannot access other critical reports where customer contact information is stored. This is simple enough and has been used at businesses for many years. Initially using manual processes to lock files and folders in boxes in safe locations, only to be accessed by the right employee to the digital age where employees login to the right portal and get access to the right information. However, things are not as rosy as they sound.

Some nuances that cause hiccups

In the case described above, which could be the use case in nearly any enterprise, there is one omission. Reports often contain multiple pieces of information which are not clearly marked or cannot clearly be separated to control who sees them and does what with the information. Consider the case of pharma companies: Most pharma companies conduct a lot of research for pumping out a new drug in the market. These research reports are stored online in most systems and there is very little to stop an employee from accessing most information about the drug. Why is this so? The reason is that most companies do privilege management at the record or file level and do not have a way to do atomic, granular privilege management. Why is this a problem – this is a problem because employees (say a nurse) can look up the contact information for a patient on the online system when only a doctor should have access to that. The problem is that both these pieces of information are on the same record.

What types of information are in one report

This is a difficult question to answer. If you have ever been to a doctors office you have had to fill out sheets that ask for everything from you allergies, to age, address, lifestyle preferences and much more. Consider this – all this information about you is being stored in a single record or file which an employee can bring up on the screen in one shot. This is the problem – an employee who has access to your medical record has access to everything on the record. Think about this for one second – lets say a nurse needs to follow up with you about an appointment, do you think the nurse needs to know your lifestyle preferences? Maybe not – but the nurse still has access to this information irrespective of whether it is appropriate or not – because of a file or record level access management. Its like saying you have access to a house and now you can do whatever you want in it.

Most reports have billing information, personal information, preferences all bundled up together. There is no easy way for businesses to easily change these pseudo legacy systems to allow for fine grained access control. In time they might even violate HIPAA or other guidelines that are specific to their business vertical. What needs to happen is that even though the data is kept in the same silo under the same report tags there needs to be a way for a business to say Employee X can see section 1 but not section 2.

What is a way to control this

Again – there is no silver bullet but the good news is that for most enterprises employees are using some kind of an online portal to look up information. The data being pumped into the portal may reside on premise or in the cloud. One way to achieve this is to use an approach that implements Access Control Lists (ACLs) in a granular way. This involves writing up a bunch of rules, say in a PHP framework like Zend and then identifying how the data is displayed in the report on a screen and slicing the view with various ACLs. This approach works but there are two downsides: (1) Time – you will need to invest a lot of time in order to build a home grown fine grained privilege management system (2) Scalability – or more correctly, what will you do when the data format changes or someone needs access to Section 2 not just section 1. Rules can’t be statically coded and need to change quickly in order to not frustrate employees waiting for the right level of access.

Another way to do this is by setting up your proxy solution, for http and https traffic. Within your proxy you can perform DOM manipulation directly on the web content being shown to the employee. You can select what to show and what not to show. However there is another issue here – certificate pinning, the growing movement to digitally sign every site, piece of code that does anything important is gaining momentum hence anything that is intercepting traffic will constantly need babysitting to make sure your employees are not seeing browser warnings or errors.

Yet another way to accomplish this is via browser extensions that can help you layer a blanket of ACLs without having to modify the actual application to be ACL aware to the most granular level.

What is the final result

The final result is actually quite interesting to behold. You as the employer can specify exactly what can an employee see, click on, download, fill out on any SaaS app or server that is accessed via a web portal. The facility you have gained is very powerful. Consider the example discussed above where a nurse is looking at an entire report when they should not. You can now specify that when Nurse X looks at the report on your portal only test related information shows up – even though the address information is right there in the report record. You can slice and dice what employees see, fill out almost anything you like to make sure your privacy and compliance constraints are met 100% correctly.

Typical use case

A typical use case for something like this would be where you have a distributed team that is part of the business and needs quick access to information. You can specify what portion of the report is shown to which group of users, like, Nurses can see patient information, but to see contact information they have to use the fingerprint sensor on a phone to request access in real time. You can have automated audit flows implemented where you can track – Did Dr. X look at report Y or not, and did they also look at a specific portion of the report or not. It is up to your imagination what kind of a system you want to build with this flexible envelope of security.

In case you would like to save time and get a pre-built solution, and use it for your organization, please feel free to connect with us at Onion ID.

Would you like to talk about this?

Please feel free to schedule a time to talk using the calendar link here –

(Visited 198 times, 1 visits today)

Share this post

0 Flares Twitter 0 Facebook 0 Google+ 0 Reddit 0 LinkedIn 0 Buffer 0 0 Flares ×