50
controls/core/data/COR.DAT.001_automated_backup.md
Normal file
50
controls/core/data/COR.DAT.001_automated_backup.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
id: "COR.DAT.001"
|
||||||
|
category: "core/data"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "30m"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC7.5", "CC9.1"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Automated backup
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Automated backups ensure that your data - one of your company’s most important
|
||||||
|
assets - is regularly and securely saved, reducing the risk of data loss. The
|
||||||
|
back-up keep it safe and available, the automated and regular allows for a
|
||||||
|
restoration just before any disruption, minimizing loss.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
### Google Cloud Platform
|
||||||
|
|
||||||
|
- When creating an instance:
|
||||||
|
1. **Google Cloud Console**, go to the **Backups** section.
|
||||||
|
2. Enable **Automated Backups**.
|
||||||
|
3. Set a **Backup Window** to specify when daily backups should occur
|
||||||
|
(especially during off-peak hours).
|
||||||
|
- On existing instance:
|
||||||
|
1. In **Google Cloud Console**, navigate to **SQL** > **Instances**.
|
||||||
|
2. Select your instance and go to **Edit**.
|
||||||
|
3. Scroll down to **Backups** and check the **Automated Backups** box.
|
||||||
|
4. Set a **Backup Window** and **Backup Retention** settings (e.g., how many
|
||||||
|
days’ worth of backups to retain).
|
||||||
|
- Enable Point-in-Time Recovery
|
||||||
|
1. Go to **Cloud SQL** in the **Google Cloud Console** and select the **SQL
|
||||||
|
instance** you want to enable PITR for.
|
||||||
|
2. Click on **Edit** at the top of the instance details page.
|
||||||
|
3. Scroll to the **Backups** section.
|
||||||
|
4. Ensure **Automated Backups** is enabled (PITR depends on automatic backups)
|
||||||
|
and enable **Point-in-Time Recovery.**
|
||||||
|
5. Set a **backup retention period** that suits your needs. PITR allows
|
||||||
|
recovery to any point within this retention period.
|
||||||
|
6. Scroll down and click **Save** to apply your changes.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot of back-up for your database.
|
||||||
36
controls/core/data/COR.DAT.002_data_flow_diagram.md
Normal file
36
controls/core/data/COR.DAT.002_data_flow_diagram.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
id: "COR.DAT.002"
|
||||||
|
category: "core/data"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "30m"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC2.1", "CC2.2"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Help the auditor with a data-flow diagram
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
The auditor doesn’t know your company and your systems. Providing him with a
|
||||||
|
diagram that show all account data accross your systems & networks will enable
|
||||||
|
him/her to understand your challenges faster and also to better evaluate your
|
||||||
|
tradeoffs (when needed). It will also help you be 100% clear on how you process
|
||||||
|
your data, and help with onboarding.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
Create a diagram that captures all systems and networks handling data in your
|
||||||
|
environment.
|
||||||
|
|
||||||
|
On this diagram, map out data flows:
|
||||||
|
|
||||||
|
- entry and exit points
|
||||||
|
- processing steps
|
||||||
|
- storage locations
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Data flow diagram
|
||||||
35
controls/core/data/COR.DAT.003_data_at_rest.md
Normal file
35
controls/core/data/COR.DAT.003_data_at_rest.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
id: "COR.DAT.003"
|
||||||
|
category: "core/data"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "15m"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC6.1", "CC6.6", "CC6.7"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Encrypt your data storage
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
By encrypting data, you ensure that loss or theft of a device won’t result in a
|
||||||
|
data breach. It also protects sensitive information from unauthorized access.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
You need to ensure that all sensitive data stored is encrypted:
|
||||||
|
|
||||||
|
⇒ Cloudflare R2 buckets are encrypted (with AES-256) at rest by default ✅
|
||||||
|
|
||||||
|
⇒ Google Cloud SQL data is encrypted (with AES-256) at rest by default ✅
|
||||||
|
|
||||||
|
⇒ GCP buckets are encrypted (with AES-256) at rest by default ✅
|
||||||
|
|
||||||
|
If you have any other data storage, you need to make sure they are encrypted:
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- All good if your data at rest is only on GCP & Cloudflare, else a screenshot
|
||||||
|
of your encrypted database
|
||||||
56
controls/core/data/COR.DAT.004_tls.md
Normal file
56
controls/core/data/COR.DAT.004_tls.md
Normal file
@@ -0,0 +1,56 @@
|
|||||||
|
---
|
||||||
|
id: "COR.DAT.004"
|
||||||
|
category: "core/data"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "15m"
|
||||||
|
necessity: "optional"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC6.1", "CC6.6", "CC6.7"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Encrypt your data in transit
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Data sent over networks can be intercepted and read - the encryption ensure it
|
||||||
|
won’t be intelligible. It secure it from potential threats.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
If you don’t have your own network or are not using FTP (if you do, ping
|
||||||
|
Antoine), you only need to focus on web traffic.
|
||||||
|
|
||||||
|
It means:
|
||||||
|
|
||||||
|
GCP load balancers have TLS by defaults ✅
|
||||||
|
|
||||||
|
### Configure Cloudflare
|
||||||
|
|
||||||
|
- Activate DNSSEC
|
||||||
|
1. **Log into Cloudflare** and select your domain.
|
||||||
|
2. Go to the **DNS** tab, scroll to **DNSSEC**, and click **Enable DNSSEC**.
|
||||||
|
3. **Copy the DS record** provided by Cloudflare.
|
||||||
|
4. Go to your **domain registrar**, and paste the DS record in the DNSSEC
|
||||||
|
settings.
|
||||||
|
5. **Verify** back in Cloudflare; DNSSEC will show "Active" once propagation
|
||||||
|
is complete.
|
||||||
|
- Ensure you have at least TLS version 1.2 with 1.3 on your zones
|
||||||
|
1. **Log into Cloudflare** and select your domain.
|
||||||
|
2. Go to **SSL/TLS** > **Edge Certificates**.
|
||||||
|
3. Set **Minimum TLS Version** to **1.2**.
|
||||||
|
4. Ensure **TLS 1.3** is enabled.
|
||||||
|
- Require a full or strict encryption
|
||||||
|
1. **Log into Cloudflare** and select your domain.
|
||||||
|
2. Go to **SSL/TLS** in the left-hand menu.
|
||||||
|
3. Under **SSL/TLS Encryption Mode**, select **Full** or **Full (Strict)**.
|
||||||
|
- **Full**: Encrypts end-to-end, but does not validate the origin certificate.
|
||||||
|
- **Full (Strict)**: Encrypts end-to-end and validates the origin certificate.
|
||||||
|
|
||||||
|
Cloudflare ensure HTTPS where possible & R2 bucket data is encrypted in transit.
|
||||||
|
✅
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot of your Cloudflare configuration
|
||||||
42
controls/core/data/COR.DAT.005_data_inventory.md
Normal file
42
controls/core/data/COR.DAT.005_data_inventory.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
id: "COR.DAT.005"
|
||||||
|
category: "core/data"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "15m"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC2.1", "CC6.1", "CC9.2"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Data inventory
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Having an accurate and up-to-date inventory of all your data assets (databases,
|
||||||
|
cloud storage or even file shares) enables you to be exhaustive in how you treat
|
||||||
|
your data safety.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
Complete the following matrix - be sure to have all data assets across your
|
||||||
|
company.
|
||||||
|
|
||||||
|
| **Location** | **Description** | **Owner** | **Sensitivity\*** | **Retention period** | **Backup frequency** |
|
||||||
|
| ------------ | ------------------------ | --------- | ----------------- | -------------------- | -------------------- |
|
||||||
|
| _BigQuery_ | _Access log to prod API_ | _Antoine_ | _confidential_ | _1 year_ | _daily_ |
|
||||||
|
| | | | | | |
|
||||||
|
|
||||||
|
\*Sensitivity:
|
||||||
|
|
||||||
|
- Public: Intended for public dissemination (e.g., pricing information).
|
||||||
|
- Confidential: Sensitive to business operations or personal information (e.g.,
|
||||||
|
customer names).
|
||||||
|
- Secret: Would severely harm the business if breached (e.g., database
|
||||||
|
credentials).
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- If you want to use something else than this template above, just provide the
|
||||||
|
link to the matrix you implemented on your side (or a copy)
|
||||||
Reference in New Issue
Block a user