How To Handle HIPAA Compliance with Serverless Security

It is back to school time, which means if you are a parent with younger children, it is time to fill out countless forms and medical records. I have three children and each one requires about 6 different forms. This process used to take me hours and all I was left with was a sore neck, cramped hand, and an empty glass of wine (or two). Fortunately, the school this year decided to move everything over to a new, pre-populated, SaaS application. It was convenient, fast, and easy to use. It saved me time, but then got me thinking…here I am sharing my children’s medical information and history, how secure is this application’s back-end? Followed by, I sure hope the SaaS provider is hosting this all on a serverless platform to save some money!

HIPAA Compliance with Serverless SecuritySo, how do medical forms for school purposes fall in the scope of HIPAA (i.e. Health Information Portability Accountability Act), unfortunately, the answer is, they don’t. In most cases, the school is not a covered entity under HIPAA since they are only storing the healthcare records for educational purposes. This means that they do not have to, under law comply, with the privacy and security requirements within HIPAA, they do however have to comply with FERPA (i.e. Family Educational Privacy Act) which has broader and less prescriptive security guidelines. If you need some “light reading,” I highly recommend you check out the following guidance report, but if you don’t have time, here is the Cliff Notes version: 

When a school provides health care to students in the normal course of business, such as through its health clinic, it is also a “health care provider” as defined by HIPAA. If a school also conducts any covered transactions electronically in connection with that health care, it is then a covered entity under HIPAA. As a covered entity, the school must comply with the HIPAA Administrative Simplification Rules for Transactions and Code Sets and Identifiers with respect to its transactions. However, many schools, even those that are HIPAA covered entities, are not required to comply with the HIPAA Privacy Rule because the only health records maintained by the school are “education records” or “treatment records” of eligible students under FERPA, both of which are excluded from coverage under the HIPAA Privacy Rule. 

Okay, so how does this tie back to HIPAA compliance with serverless security?  While all of the recorded information that was supplied by my children’s pediatrician and dentist is covered and protected under HIPAA, and I did grant them permission to share it, once transmitted to the children’s school via the SaaS application, that could or could not be hosted on serverless, the HIPAA protection is now gone and we enter the world of FERPA. While we do not want to place unnecessary burdens on an already heavily regulated and resource-constrained system, there are some wonderful guidelines and best practices under the HIPAA Privacy Rule that are good guidelines to follow for providers handling medical information but are not technically covered entities. 

As Saas providers are migrating their applications to serverless, understanding these compliance rules, restrictions, and policies, and how they apply to serverless applications on AWS Lambda, Google Cloud, Microsoft Azure, etc can help better protect everyone (patients, providers, educators)–ensuring they not only have HIPAA compliant applications but greater protection and efficiency. In fact, at Protego Labs, we are working with many clients across both healthcare and education who are applying the principals outlined in HIPAA, and other regulations, to establish security best practices for their serverless deployments.

HIPAA Compliance with Serverless Architectures

So what does serverless security for healthcare and other related industries entail? Highlighting some of these best practices below is an outline of how common security controls apply to ensure HIPAA compliance with serverless architecture:


Boundary Defense

The solution should use behavioral micro-segmentation around all workloads, and automatically restrict all inbound and outbound network traffic, allowing only traffic which is necessary based on deep code-flow analysis. Custom policies to functions to prevent access to the Internet from workloads that contain sensitive data are also critical. Multi-factor authentication is an additional security barrier that is important.

FERPA: Network mapping; Provide a layered defense; Authentication; Access control; Automated vulnerability scanning

Continuous Vulnerability Assessment and Remediation

The solution should detect vulnerabilities in 3rd-party components using data from several sources including the NVD, and provide detailed risk information including scoring.

HIPAA: 164.310(b) – 164.310(c)

FERPA: Automated vulnerability scanning

Controlled Access Based on the Need to Know

The solution should apply auto-segmentation to workloads to prevent outbound traffic where it is not explicitly necessary. The ability to create custom policies to functions to prevent access from workloads that contain sensitive/protected data is critical. All compute and non-API resources are in private IP ranges automatically, and public buckets are detected.

HIPAA: 164.308(a)(1); 164.308(a)(4); 164.312(a)(1); 164.312(c)(1); 164.312(d); 164.312(e)(1)

FERPA: Access control; Authentication

Controlled Use of Administrative Privileges

The solution should detect vulnerabilities in 3rd-party components using data from several sources including the NVD, and provide detailed risk information including scoring.

HIPAA: 164.310(b) – 164.310(c)

FERPA: Access control; Authentication

Data Protection

The solution should have the ability to automatically encrypt all data stored within workload runtimes, including data stored in /tmp in a Lambda Function, with short-lived strong cryptographic keys.

HIPAA: 164.308(a)(4); 164.310(d)(1); 164.312(a)(1); 164.312(e)(1)

FERPA: Provide a layered defense; Automated vulnerability scanning

Email and Web Browser Protections

The solutions should enforce the least privilege on each workload, and continually scans the cloud account to determine if any of the deployed serverless resources are unused and recommends removing all unused services and resources.

HIPAA: 164.310(b) – 164.310(c)

FERPA: Secure configurations; Shut down unnecessary services

Inventory of Authorized and Unauthorized Devices and Software

The solution should automatically and accurately profiles function and application behavior to detect anomalies, and block unauthorized access. It should also provide an inventory of all application system components and provides a report on the compliance status of each resource.

HIPAA: 164.308(a)(4); 164.310(d)(1); 164.312(a)(1); 164.312(e)(1)

FERPA: Automated vulnerability scanning

Maintenance, Monitoring, and Analysis of Audit Logs

The solution should provide a full audit trail for all user actions within the system including any changes to defense policies and rules and exceptions.

HIPAA: 164.308(a)(1); 164.308(a)(5)

FERPA: Automated vulnerability scanning

Secure Configuration for Network Devices, such as Firewalls, Routers and Switches

The solution provides a topological view of the serverless application, indicating which resources are connected to external networks and resources. Behavioral micro-segmentation around all workloads including but not limited to workloads that are connected to the internet, internal VPCs, and DMZs is also a critical element.

FERPA: Firewalls and Intrusion Detection/Prevention Systems (IDPS)

Secure Configurations for Hardware and Software

Serverless applications are designed with a single primary function per serverless workload. The solution should enforce least privilege on each workload, and continually scans the cloud account to determine if any of the deployed serverless. An enhanced solution will also determine automatically if any of the deployed serverless resources are unused and recommends removing all unused services and resources, as well as to detect and prevent misconfigured IAM Roles, Triggers, and Unauthenticated API Gateways, as well as public buckets.

HIPAA: 164.310(b) – 164.310(c)

FERPA: Access control; Secure configurations; Automated vulnerability scanning; Shut down unnecessary services

These are just a few guidelines our clients follow to ensure their serverless deployments meet HIPAA compliance as well as other industry requirements. It all stems from taking the right schooling of security learnings and using that foundation to apply it to serverless.

HIPAA Compliance in AWS Resources

For additional reference materials on HIPAA compliance in AWS please refer to these resources:

The post How To Handle HIPAA Compliance with Serverless Security appeared first on Protego.

*** This is a Security Bloggers Network syndicated blog from Blog – Protego authored by Trisha Paine. Read the original post at: