How would you feel if just about anybody could browse through your medical records if they felt like it? The chances are you’d be pretty upset. It wasn’t quite as this bad in Centro Hospitalar Barreiro Montijo, a hospital in Portugal, but it was close. Portugal’s supervisory authority, Comissão Nacional de Protecção de Dados, determined that the hospital violated three GDPR regulations. Let’s dissect the case based on what the hospital was actually found guilty of. You can find the original article here.
...and access for all
“…a violation of Article 5(1)(c), a minimization principle, by allowing indiscriminate access to an excessive number of users, and a violation of Article 83(5)(a) a violation of the processing basic principles.”
GDPR doesn’t only cover proper measures against cyber attacks. It also mandates that access to sensitive data is regulated and restricted within an organization. Indiscriminate access in this context means that there were no proper control mechanisms over who had access to what type of information.
The principle of least privilege
An example of such negligence is when someone with a highly privileged account shares their access credentials with others who should not have the same level of access. Another alternative is that the most powerful access available is granted to almost everyone by default, which in practice completely ignores the sound practice of segregation of duties. It is also possible that the accessible information was not properly categorized and isolated based on the level of confidentiality.
"Nine technical employees enjoyed the level of access reserved for the medical group, which resulted in the indiscriminate possibility of such employees consulting the clinical processes of all hospital users."
Unfortunately, this is not the first time we’ve seen something like this. We’ve come across with cases where technical personnel have had permanent access to highly confidential information, such as stock exchange release drafts, credit card details or access from a non-production to production environment in DevOps. It is understandable that all systems require technical maintenance, emergency support or regular upgrades. But these are all special cases that should be handled accordingly: privileged access should be available for only as long as it takes to get the job done and it should be restricted so that confidential information is not available to technical people unless absolutely necessary. This is the very idea of least privileged access.
We should all play the right role
“There was no document containing the correspondence between the functional competences of the users and the profiles for access to the information (including to clinical information)…There was also no document defining the rules for creating users of the hospital's information system.”
Having access roles and policies defined on paper is the minimum you should expect from any organization. Personnel then need to be trained and made aware of the company's security policies and processes. The next step is to make sure no one is able to access sensitive information by accident. There are also ways to enforce access policies so that privileged users simply have no choice but to comply with the company security policy. This is one of the areas we specialize in at SSH.COM. We have also developed software that automates a lot of privileged access governance and adheres to the principles of role-based access control (RBAC).
“Existence of access credentials which allowed any doctor, regardless of his/her specialty, to access at any time the data of the clients of a hospital. This was considered as violating the principle of "need to know" and the principle of "minimization of data."
And this is what not implementing proper access roles or valid privilege elevation mechanism looks like in real life. This is no longer just about about certain people having permanent unrestricted access, it’s about giving the most powerful "root" access credentials to too many people.
Doctor or hacker?
“There were 985 users associated with the profile "doctor," but in the official hospital human resources charts there are only 296 doctors in that hospital.”
So once again, you have employees who have no legitimate reason to access highly sensitive medical data doing so. But there’s another and perhaps more sinister angle to the story. This is actually somewhat similar to what many hackers prefer to do: once they get inside a system, they often look for credentials that allow them to pose as a legitimate user and then move laterally inside the system until they find an opening for something valuable.
Therefore, this type of “put your hands in the air and grant access like you just don’t care” mentality is not only in direct violation of multiple regulations, but it also increases the risk of hackers getting their hands on something truly valuable. The more unmanaged and untracked power user access accounts you have, the more likely their serious misuse becomes outside - as well as inside - your organization.
Bad offboarding can lead to outsider access
“Maintenance of useless profiles for doctors who no longer provide services to the hospital… There were only 18 user accounts that were inactive and the last one was deactivated in November 2016.”
This is clearly a problem with offboarding. People no longer work for the hospital but their access isn’t revoked. And this means that the risk has truly moved from inside the organization to the outside world. How do you know that these credentials are not still being used by ex-employees who no longer are associated with the hospital? What’s worse, how do you really know who is actually using the credentials? Highly privileged access is encrypted to protect the traffic from the prying eyes. But this also means that if a connection is established to steal data, it’s invisible to your existing security systems.
Imagine a connection that's invisible and/or considered legitimate by your security software because it was established using valid credentials. Again, this type of access is a goldmine for hackers, since they don't even have to breach the security perimeter. They can simply assume an identity that your system considers legitimate and extract sensitive information undetected without leaving a trail! You can read more about some of the verified cases here.
So why did this happen?
The principles of proper access governance are actually not that difficult. All privileged sessions, such as those conducted by systems and applications administrators, 3rd parties and subcontractors, should always be monitored, logged and reviewed. They should leave a complete audit trail that adheres to the defined security policies and procedures. Privileged access management (PAM) solutions are typically used to handle these types of scenarios. But even with PAM, some of the problems persist. Below you can find some of the reasons we have come across:
-
Insider risk is not seen as a top priority. There’s a perception that the only real threat and risk comes from the outside.
-
Thinking Identity & Access Management (IAM) solutions cover privileged users. In some organizations it not clear what the different layers of access are, how they should be handled or if there are dedicated tools to handle privileged access.
-
Many Privileged Access Management (PAM) solutions are hard to implement and difficult to use. Setting up a traditional PAM solution might take years and keeping them up-to-date can be difficult.
-
PAM is relatively easy to bypass by system administrators who know what they are doing. You work faster if you bypass PAM. It is sometimes as simple as that. This is also one of the reasons system admin level access is shared.
-
Wilful negligence. This might be a bit shocking to hear but as was demonstrated by this case, those who should’ve known better chose to ignore compliance, as indicated by the quote below:
“The defendant acted in a free and voluntary way and consciously knowing that its acts are prohibited by law.”
Keep your organization's privileged access compliant
We are happy to lend you our expertise in privileged access management and encrypted traffic monitoring. We’ve offered services and software solutions in this field for 25 years and are the primary experts in Secure Shell, the protocol invented by our founder that is used in every organization to transfer and secure confidential information.
Get in touch to discuss how you can stay GDPR compliant in these turbulent times. In the meantime, read about why GDPR is really awesome...
Regards,
Kaisa
kaisa.olkkonen (a) ssh.com
