# Security Compliance in GCP (HIPAA + SOC2)

{% hint style="danger" %}
## Still in Draft

This document is not ready for the reader. I probably reference it in another article though and so... here you are!  Read on if you'd like, but it may be best to wait until I complete it.
{% endhint %}

#### Checklist

* Executed a Google Cloud BAA.
* Disabled or otherwise ensured to not use Google Cloud Products that are not explicitly covered by the BAA when working with PHI.
* Using IAM best practices when configuring who has access to the Google Cloud Platform (GCP) projects containing or executing on PHI.
* All customer content is encrypted at rest and in-transit.
* Configured audit log export to Cloud Storage for long term (7 year) archival, as well as to BigQuery for any analytical, monitoring, and/or forensic needs.
* Configured access control for the logs. Regularly review audit logs to ensure security and compliance with requirements.
* All PHI is encrypted using GCP’s Key Management Service with a 90 day key rotation of a symmetric key. This algorithm uses 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata. We do not have access to the key, and in theory, no one at Google or anywhere else has access to it.
* When creating or configuring indexes in Cloud Firestore using PHI, we enforce blind indices using a combined bycrypt + SHA3 hash with a uniquely generated salt per PHI value. The salt is encrypted using the same level of security as our PHI encryption explained above.
* We sanitize all metadata and resource data being captured in our logs.
* We use Identity Platform practices when using Identity Platform for your project, which includes our product’s authentication.
* We never store PHI in build config files, source control files, or other build artifacts.
* We never cache PHI on our services, CDN, on the user’s device or browser’s local storage.
* All product changes that impact PHI are reviewed by our Security Compliance Officer.
* Our staff have routine HIPAA compliance training.
* We perform an internal and/or independent audit of our HIPAA compliance and BAAs annually.&#x20;
* User access to PHI assumes least privilege and requires authentication with automatic log off of session inactivity.
* We self-proclaim compliance with HIPAA and GDPR. You can review our Privacy Policy and Terms of Service for more details.

#### Resources

* [https://www.hipaajournal.com/hipaa-compliance-checklist/](https://www.hipaajournal.com/hipaa-compliance-checklist/)
* [https://www.hipaajournal.com/hipaa-audit-checklist/](https://www.hipaajournal.com/hipaa-audit-checklist/)
* [https://www.hipaaguide.net/hipaa-compliance-guide/](https://www.hipaaguide.net/hipaa-compliance-guide/)
* [https://www.hipaajournal.com/gdpr-requirements-for-us-companies/](https://www.hipaajournal.com/gdpr-requirements-for-us-companies/)
* [https://www.hipaajournal.com/protect-healthcare-data-from-phishing/](https://www.hipaajournal.com/protect-healthcare-data-from-phishing/)
* [https://cloud.google.com/security/compliance/hipaa](https://cloud.google.com/security/compliance/hipaa)
* [https://github.com/GoogleCloudPlatform/solution-acceleration-toolkit](https://github.com/GoogleCloudPlatform/solution-acceleration-toolkit)
* [https://drive.google.com/file/d/1TuK3XJ8nkZhXKVJx3K-TyBeJvvo8Nk3i/view?usp=sharing](https://drive.google.com/file/d/1TuK3XJ8nkZhXKVJx3K-TyBeJvvo8Nk3i/view?usp=sharing)
* [https://www.backhub.co/](https://www.backhub.co/)
* If serverless, then there is no need for Blackduck or other vulnerability scanning services.
* [https://cloud.google.com/filestore/docs/backup-restore](https://cloud.google.com/filestore/docs/backup-restore)
  * [https://cloud.google.com/filestore/docs/scheduling-backups](https://cloud.google.com/filestore/docs/scheduling-backups)
* [https://stackoverflow.com/a/33112378/6090140](https://stackoverflow.com/a/33112378/6090140)
  * [https://cloud.google.com/kms/docs/create-validate-mac-signatures#create\_mac\_signature](https://cloud.google.com/kms/docs/create-validate-mac-signatures#create_mac_signature)
  * Note that the problem with utilizing a MAC is 1) if the secret key ever rotates, the output changes and 2) if the secret key is ever compromised, the MAC is no more secure than a regular hash and a rainbow table can be used and 3) it is generally the case to use one secret key per database, making a compromised key compromised for all data in the database.
  * Lookup Blind Indices for more information.  It's all about what level of comfort you have.  Ask yourself: "If a malicious average user of your platform was insanely smart and dedicated, could they compromise your system?"  "If a malicious admin-level user ..." "If a malicious developer ..." "If a malicious cloud/devops admin ..."&#x20;
