[vc_row][vc_column][vc_column_text]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 Security

 

So, 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:

 [/vc_column_text][vc_row_inner css=”.vc_custom_1567699867980{background-color: #f4f4f4 !important;}”][vc_column_inner width=”1/2″][vc_column_text]#1 Boundary Defense[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]#2 Continuous Vulnerability Assessment and Remediation[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner css=”.vc_custom_1567699887326{background-color: #f4f4f4 !important;}”][vc_column_inner width=”1/2″][vc_column_text]#3 Controlled Access Based on the Need to Know[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]#4 Controlled Use of Administrative Privileges[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner css=”.vc_custom_1567699887326{background-color: #f4f4f4 !important;}”][vc_column_inner width=”1/2″][vc_column_text]#5 Data Protection[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]#6 Email and Web Browser Protections[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner css=”.vc_custom_1567699887326{background-color: #f4f4f4 !important;}”][vc_column_inner width=”1/2″][vc_column_text]#7 Inventory of Authorized and Unauthorized Devices and Software[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]#8 Maintenance, Monitoring, and Analysis of Audit Logs[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner css=”.vc_custom_1567699887326{background-color: #f4f4f4 !important;}”][vc_column_inner width=”1/2″][vc_column_text]#9 Secure Configuration for Network Devices, such as Firewalls, Routers and Switches[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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)

[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner width=”1/2″][vc_column_text]#10 Secure Configurations for Hardware and Software[/vc_column_text][/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]

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

[/vc_column_text][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]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:

[/vc_column_text][/vc_column][/vc_row]

Share This Article
Share on facebook
Share on linkedin
Share on twitter
Share on email
THE SERVERLESS
SMARTS PODCAST
THE SERVERLESS
SMARTS PODCAST

Join industry experts as they discuss all things serverless including industry news and best practice tips.

podcast_image