Let’s explore the Principle of Least Privilege. What is it? What happens when it’s violated? And, we’ll map out 5 actions you can take to protect your company.
You may need to pick up some new vocabulary.
Because it will help you have intelligent conversations with your clients and get better results for your company.
My sad story…
Once upon a time, I was a new statistician in industry assigned to general tox studies. As I reviewed the study data, I saw “tarry stools.”
I read “tarry” as in “to delay” or “to be late.”
What the heck? Late rat stools? How would anyone know? My colleagues professed not to know. So I called the Study Director for clarification. Color me red. I’m pretty sure they’re all telling that story over a beer to this day. (On the other hand, maybe they’ve completely forgotten, and I’ve now shared my ignorance with all of you!)
Nobody likes to look ignorant. Let’s learn the lingo so you won’t be that guy when it comes to computer systems
What is the Principle of Least Privilege?
The Principle of Least Privilege means providing users the minimum access they need to do their work for the minimum time required.
(I’m not a fan of acronyms, but you might see Principle of Least Privilege abbreviated PoLP. Just not in my blog posts.)
The Principle of Least Privilege also applies to computer programs and processes. In this blog post, we’ll address only human users.
Violations, Consequences and Corrective Actions
Violations of the Principle of Least Privilege can result in
- Loss of data integrity
- Loss of data
- Data leakage (you still have the data, but so does your competitor!)
Any of these consequences may qualify as a security incident in your organization – be familiar with your policies and procedures so you can involve the right people at the right time. Corrective actions should include determining how long the violation has been going on and what the impact has been on the data.
In both case studies below, users have “elevated permissions.” In other words, they have permissions to do or see more than they ought to.
2 Case Studies
Case Study 1: User Gets Too Much Access
You’re a clinical auditor who has suddenly realized you have investigator access to all sites in the EDC system. You don’t think you’ve created, modified, or deleted any records.
- Log off (don’t expose yourself to any more risk!).
- Report the situation to your management.
- Determine if the problem meets your company’s definition of a security incident and, if it does, follow that procedure.
- Someone should
- Establish how long you had elevated access.
- Change your access to the appropriate level.
- Review the audit trail for the period in question to determine if you created, modified, or deleted any records.
- Notify investigators if you changed, modified, or deleted any records, and have them make corrections. (Remember the predicate rule: eCRFs are the investigators’ responsibility!)
- Figure out how you were assigned the wrong access level.
Case Study 2: User Changes Jobs and Retains Access
This is a variation of Violation 1 and demonstrates why the Principle of Least Privilege has a time element attached.
You’re a clinical auditor auditing one of your company’s providers: a clinical lab. The lab hosts an in-house developed web-based application allowing clinical project teams at your company to view all the data for their assigned studies and download it into Excel. Once a user has access to the system, they can access it from anywhere – their personal smart phone, their home computer, their work laptop, etc. As you review the user list, you notice the name of someone you know well. Unfortunately, they left your company months ago to work for a direct competitor. Whoops!
- Determine if the problem meets your company’s, or the lab’s, definition of a security incident and, if it does, follow that procedure.
- Someone should
- Record the fact the problem occurred, including the date the user left your company.
- Revoke their access.
- Review the system log and audit trails to determine if and how the user accessed data after they left your company. (This goes for all studies to which they had access.) Special note: If the lab cannot provide you this information, the system has a serious design flaw. Your management should consider ceasing its use until it is fixed.)
- If the user did download data after leaving your company (and this is where it gets ugly), the lawyers will step in to help.
5 Real Life Examples
Here are 4 examples from FDA Warning Letters.
- Study coordinator used the subjects’ login IDs to complete the subjects’ e-diaries instead of the subjects.
- “All employees had administrator privileges and shared one user name, so actions could not be attributed or traced to specific individuals. This exposed your electronic data to manipulation and/or deletion without traceability.”
- Lab workers shared login IDs for high performance liquid chromatograph units, the X-Ray Diffraction unit, and the Windows operating system on the gas chromatography standalone workstations.
- Lab failed “to use separate passwords for each analyst’s access to the laboratory systems.”
And in Europe, in the GMP environment: Lab analysts “routinely use the PC administrator privileges to set the controlling time and date setting back to over-write previously collected failing and/or undesirable sample results.” (See Italian Medicines Agency report on Sri Krishna Pharmaceuticals on 4 Dec 2014.)
I’m sure your VP of Quality or Executive Director of Development Quality Assurance doesn’t want to have to go to Executive Management or the Board of Director’s Audit Committee to explain
- All the subject-recorded data at your highest enrolling site had to be excluded from analysis because the subjects didn’t record their data – the study nurse did.
- The biomarker data generated at a contract lab to drive a new indication can’t be relied on because no one knows who created, modified, or deleted data.
- Your competition has all the lab data for your oncology program because a clinical team never notified the lab that an employee left your company for the competition.
5 Actions to Protect Your Company
Here are 5 actions your company should be taking (and requiring your service providers to take) to protect itself from violations of the Principle of Least Privilege
- Have a policy in place requiring use of the Principle of Least Privilege.
- Have procedures in place to investigate and correct violations of the Principle of Least Privilege.
- Grant access based on user roles and what they need to be able to do in the system, and only when properly authorized by management.
- Review access periodically to ensure assigned roles are still appropriate.
- Revoke access as soon as reasonably possible when users no longer need access.
In the GMP environment, regulators worldwide are taking a firm stand on violations of least privilege when they can be demonstrated to impact data integrity. At the very least, they require “a retrospective review” of data (see Finding 1). They may require hiring a data integrity consultant (see the end of this Warning Letter) to get to the root of the problem at your entire company. And in the most extreme case, when combined with other quality problems, product may be blocked from a country or an entire region. FDA’s recently released draft “Guidance for Industry: Data Integrity and Compliance with CGMP” devotes 2 of the 18 FAQs to access to computer systems.