On July 10, 2023, attorneys filed suit against Johns Hopkins University and its health system alleging that the renowned hospital and medical school had failed to properly secure IT systems, resulting in a massive theft of sensitive patient data. In particular, the lawsuit cites the MOVEit file transfer system that Hopkins used internally and ran on a hosted system. Attackers identified a Zero-Day flaw in MOVEit’s code and began exploiting it well before vulnerability warning came out, according to news reports. Since those initial vulnerability alerts, researchers have identified a number of other potential security flaws in the widely-used MOVEit system.
Hopkins is not the only healthcare provider hit by the MOVEit flaw. Harris Health, a major hospital system in Texas, was also compromised. As more and more hospitals and healthcare providers come under attack, many are moving quickly to adopt SaaS applications to reduce the burden on their IT teams. Ultimately, they hope this will also reduce their risk and attack surface.
The criminals are, not surprisingly, a step ahead of them and are already creating TTPs for ransomware and other attacks against SaaS tooling. An example of this is the recent attack against Jumpcloud, a SaaS provider of SSO and directory services which was forced to hard reset all customer API keys due to a security incident. SSO and directory services provide the keys to the SaaS kingdom and are a rich target for attackers seeking to access not only email and files but also SaaS applications. The new focus on attacking SaaS is forcing many providers of SaaS products for healthcare organizations to up their security game and to reevaluate how to design better security into both the infrastructure and user levels of their apps.
From our experience providing identity management services to healthcare SaaS companies, here are five rules for building more secure SaaS applications. These rules are broadly applicable but in some cases take into account the specifics of the healthcare vertical. The list can serve as a guide either for healthcare organizations looking to move key operations to SaaS or to makers of SaaS applications for healthcare customers.
Rule 1: Zero trust for any critical data
To start with, implement a Zero Trust model. It basically means build to assume breaches. Under ZT, you must verify each request for access to critical systems as though it originates from an open network or from adversaries. This seems like obvious advice. But implementing ZT in healthcare applications can be tricky. For example, it may not make sense to force authentication constantly for non-critical systems and cause friction in user workflows. And for some types of access, a single authentication per session might be sufficient while for sessions interacting with PII, time-based session re-authorization should be the norm. Ideally, ZT should be relatively painless for end users and newer technologies like passkeys make this possible. In addition, ZT should move away from more hackable authentication mechanisms like SMS or even email (attackers are now targeting SSO providers as a way to get access to email).
Rule 2: Create intuitive, excellent security UX
Traditionally, the security UX of a SaaS application has been a second-class citizen. This is somewhat understandable because users generally spend little time managing their security. Unfortunately , the rise of ransomware means every user must be more fluent in security topics. Creating a UX that makes it easy for users to understand and manage their security settings becomes essential. This includes clear explanations of what each setting does and the implications of turning it on or off. The sniff test? Non-technical users must be able to easily manage and modify their security settings, at the account level, and do so without requiring any IT assistance.
Rule 3: Empower users to control their own security policies
Related to the above, it is critical to allow users or their direct IT staff to customize security settings to fit their unique needs and risk tolerance. This could include options for two-factor authentication, session timeout rules, password complexity, and more. Security policies that are too onerous can annoy users and sap productivity. Security policies that are too broad can make it impossible to secure SaaS effectively. For example, a major authentication provider offers so-called “risk-based” MFA step-up settings that does not allow users to configure the parameters behind the risk. By only including the most basic risk measures — impossible travel, IP address, domain — this risk-based system is quite easy to circumvent. The upshot? Empowering users does not mean only two options (on or off); it means giving them rich controls.
Rule 4: Segmentation and multi-tenancy are key
The segregation of SaaS customers and their data to prevent or limit damage from a breach is mandatory. This can best be achieved through multi-tenancy, where each customer’s data is isolated in a separate ‘tenant’ environment. Multi-tenancy might be at the namespace level, at the Container level, or even at the virtual machine level but it should create a strong sandbox per customer. For even greater levels of security, you might want to seek solutions that can allow organizations to further segregate information within their tenancy level, offering different levels of protections for different types of data. Increasingly, too, geographical segmentation becomes key. Florida, for example, just passed a law mandating that all medical records of Florida residents be physically stored on systems in the Continental U.S. or Canada. Different states are passing different cybersecurity laws, creating a patchwork of risks that will be best addressed through geographical control possible only through granular segmentation and multi-tenancy.
Rule 5: If your customers are institutions, make it wasy for them to analyze their own security events
In healthcare, real-time access to user logs is essential to identifying and firewalling any attacks. SaaS providers for healthcare should design their systems to enable customers to download, on demand, any logs they need. SaaS providers should never charge customers for log access. While this may seem like a nice way to make money, it can delay response times. This is simply not acceptable when the users are doctors and others who might rely on your SaaS to provide lifesaving services.
Conclusion: Higher standards and less room for error in healthcare SaaS
The healthcare sector is the most mission critical of all of our businesses. When technology fails, critical care may be interrupted and patients can die. SaaS for healthcare must design to higher tolerances and for greater security and reliability. This goes beyond the usual expectations of SOC-2, HIPAA, and high-level uptime SLAs. It requires designing SaaS apps under a different set of rules that offers multi-tenancy and segmentation, elevates user experience, and, ultimately, reduces the chances of attacks succeeding and interrupting the important activities of our doctors and hospitals.
Photo: Traitov, Getty Images
