SaaS Risks in Healthcare: Anatomy of a Data Exposure at the HSE

By Aaron Costello, Principal SaaS Security Engineer @ AppOmni

In December 2021, I discovered a misconfiguration in the Health Service Executive’s (HSE) COVID Vaccination Portal. The HSE provides public health and social care services to everyone living in Ireland. The vaccination portal, developed by the HSE with Salesforce Health Cloud, granted registered users excessive permissions. This oversight allowed individuals to access sensitive Personal Identifiable Information (PII) and Protected Health Information (PHI) of other registrants, as well as internal Health Service Executive (HSE) documents. Since all vaccinations occurring in Ireland go through the HSE, it is estimated that the private information of over a million Irish citizens was inadvertently made publicly accessible.

Once reported to the HSE, I assisted them with resolving the issue over the course of several weeks until the misconfiguration was fixed. After investigation by the HSE, they fortunately did not find any evidence that any information was accessed by unauthorized individuals with malicious intent.

My goal in writing about this issue is to provide a public service to organizations that handle sensitive data in SaaS applications. I have attempted to coordinate disclosure of the issue over the last two years with HSE, but to my knowledge, it has not been publicly disclosed or acknowledged by the HSE (see section below on Disclosure Timeline). This article is the first to publicly acknowledge the misconfiguration in the HSE portal. It seeks to discuss the misconfiguration(s) that occurred, a timeline of events, and provides security posture recommendations for organizations that use the Salesforce platform to store and process sensitive information.

SaaS Risks in Healthcare: Anatomy of a Data Exposure at the HSE | AppOmni

MEDIA COVERAGE

How It Happened

The Root Cause

The vaccination portal, built on top of Salesforce, allowed any individual to sign up to the portal through a self-registration form. In Salesforce nomenclature, this particular type of portal is known as a Lightning Community or Digital Community. These communities are configured to grant all registered users a specific Profile. Through the permissions granted by the profile, users can then perform actions using the vaccination portal’s user interface, such as register for a vaccination or view their own personal vaccination appointment details. All of this information was being stored in various tables of data (referred to as objects) within the Salesforce Health Cloud application.

Unfortunately, the individuals who had configured the profile’s permissions had accidentally granted the profile an unprecedented level of access to the Health Cloud object that is responsible for storing information specifically about vaccination administration. In the Health Cloud application, this object is referred to as ‘EhrImmunization__c’ and is used to store both PII and PHI. Thankfully, the ability to see everyone’s vaccination administration details was not immediately obvious to regular users who were using the portal as intended.

Furthermore, the same profile had accidentally been granted read access to a folder containing internal HSE documents. Because of that, sensitive information could have been downloaded and distributed by anyone who had registered to the portal.

How It Could Have Been Accessed

In the previous section, I alluded to the fact that normal users would not have realized they had this level of access. This is because when information is being displayed after logging in to the portal, it is designed specifically to show only your own data.

However, several years ago I published an independent blog post which was the first of its kind to outline how individuals could retrieve data through the out-of-the-box Salesforce API known as the Aura API. When information is accessed through the methods outlined in that blog or similar alternative methods, users can see not only their own information but also any other information they have been granted permission to access.

By following that methodology, a malicious user could have performed the following steps:

  1. Registered to the Vaccination Portal in order to be automatically assigned the over-privileged Salesforce profile.
  2. Through the API, view all objects that existed within the Salesforce platform including those belonging to the Health Cloud application.
  3. Iterate over the list of available objects and attempt to access the data within them.
  4. For any successful attempts, proceed to access and download thousands of rows of data at a time.

Using those four simple steps, this would have allowed the malicious individual to access both internal HSE documentation, and all vaccine administration records for over a million individuals.

Preventative Measures

In this example, the HSE had poor permission management practices which resulted in registered members of the portal having the ability to view data far outside the scope of what was intended. This is a common problem among organizations using Salesforce, as managing object and field access alongside sharing rules can be challenging and cumbersome. For organizations that have publicly facing content on the Salesforce platform, this is the number one cause of data exposure.

Typically, I recommend that organizations follow several steps in order to accomplish a strong initial security baseline for Salesforce. These include:

  • Principle of Least Privilege: Ensure that both internal and external users have the minimum required permissions to fulfill their needs.
  • Routine Permission Model Reviews: Regularly review import access-granting elements within Salesforce, such as profiles, permission sets, and sharing rules.
  • Classify Sensitive Data: Review the data being stored on-platform, categorize it, and implement classifications based on its sensitivity level. This allows organizations to easily target data of utmost sensitivity and employ stricter access controls.
  • Monitor Salesforce Logs: Salesforce provides multiple types of readily available logs that can be ingested into an external SIEM tool and analyzed. Of most interest with respect to this particular issue is the relatively new ‘Aura Request’ event which captures the use of Aura Controllers in the logs. This makes it especially useful for detecting data exfiltration attempts.
  • Audit the Platform’s Configuration: Settings within Salesforce have the ability to influence the security of your organization in nearly any capacity, including access control. These settings should be seen as the first line of defense and configured to be in line with internal security policy or adhere to a globally accepted security framework, such as NIST. This must be done on a continuous basis as the configuration will change very frequently in most organizations.

Conclusion

We can recognize that this vaccination portal was deployed during a particularly chaotic period in which many governments across the world were scrambling to provide a single streamlined vaccination management solution for its citizens. Under these conditions, it would have been exceptionally difficult for the HSE to manually implement the preventive strategies I had outlined in a manner that is both quick and effective.

This makes it a perfect use-case for AppOmni’s SaaS security solution for Salesforce. AppOmni provides immediate value for organizations by not only providing a holistic, current, and continuous view of their platform’s security, but also assisting them in preventing these kinds of data exposures long before they can happen.

Disclosure Timeline

16 Dec 2021

  • Engaged with HSE twitter to ascertain best point-of-contact for reporting the issue
  • HSE twitter provided point of contact
  • Context of vulnerability sent to HSE
  • HSE DDPO requested technical details of the vulnerability
  • Vulnerability details sent to HSE DDPO

20 Dec 2021

  • HSE provided confirmation of issue and that they are working on resolution

04 Jan 2022

I asked for an update on the status of resolution

17 Jan 2022

HSE confirms that they resolved the issue

04 Feb 2022

I requested public disclosure of the issue, in a coordinated manner.

18 Feb 2022

HSE states they have forwarded the details of the issue to NCSC.

10 Mar 2022

HSE states that the NCSC would like me to contact them directly with details of the issue.

28 Jul 2022

  • I provided context of the vulnerability to the NCSC CSIRT
  • NCSC stated that this type of vulnerability is not within their scope

10 Aug 2022

I contacted HSE and informed them of NCSC’s response.

17 Aug 2022

HSE states that the NCSC has requested me to work with a specific NCSC individual regarding disclosure request.

19 Sep 2022

I contacted this individual at the NCSC regarding the vulnerability.

21 Jun 2023

I contacted the HSE informing them that I did not receive a response from the NCSC.

27 Jun 2023

I re-initiated contact with the individual at the NCSC. Individual stated they have moved to the DECC and that my email slipped through the cracks and to forward the details to the NCSC.

30 Jun 2023

NCSC sent details about the vulnerability

03 Jul 2023

  • I inform the DECC of NCSC’s response. 
  • DECC asked for information relating to my email to NCSC and would push it internally.
  • After discussion surrounding the original report, DECC stated that they would not usually disclose an issue that has already been rectified in the past.
  • I stated that it’s better late than never to disclose the issue. No response received since.

Related Content