gearnode
@@ -1,109 +0,0 @@
|
||||
# Toward SOC 2
|
||||
|
||||
## Not everything is mandatory
|
||||
|
||||
You know better than anyone (including the auditor) what is best for your
|
||||
company. You might have good reasons for performing or not a task as every
|
||||
company is unique.
|
||||
|
||||
To help you evaluate the importance of each tasks you will run into, they are
|
||||
labelled with three levels:
|
||||
|
||||
- **Mandatory** – The essential and fundamental elements. If you don’t have
|
||||
those, your auditor or customer will ask questions, you better justify it.
|
||||
- **Optional** – Your auditor or customer might ask questions if any of those
|
||||
elements are necessary to mitigate a risk you have.
|
||||
|
||||
<details>
|
||||
🗣
|
||||
|
||||
A good example is penetration testing.
|
||||
|
||||
- Penetration tests are expensive, but they can be a good investment, especially if you are running into a prospect requiring it
|
||||
- However they probably wont make sense if you are at the MVP stage and you are gonna trash and rebuild your product in a few month
|
||||
</details>
|
||||
|
||||
- **Advanced** – They show a great commitment toward security. Unless it is the
|
||||
only way to mitigate a risk very specific to your company, you won’t be asked
|
||||
about it.
|
||||
|
||||
## What’s next ?
|
||||
|
||||
We have regrouped what you need to do by different thematic in order to setup
|
||||
the proper foundations for your company to get SOC-2:
|
||||
|
||||
<details>
|
||||
|
||||
**Pro tip:** Setup screenshot to clipboard You will have to take quite a lot of
|
||||
screenshot until we automate most of it. We recommend that you setup a
|
||||
screenshot to clipboard so you can just take a screenshot and paste-it saving
|
||||
you ton of time. On mac:
|
||||
|
||||
- Use **CMD + SHIFT + 5** to enter screenshot mode
|
||||
- Click options, to change “save to” to “clipboard”
|
||||
- Now you can use **CMD + SHIFT + 3** to take a screenshot to clipboard
|
||||
- And paste it in the right place with **CMD + V**
|
||||
|
||||
</details>
|
||||
|
||||
### Physical assets
|
||||
|
||||
Protect your physical environment to prevent data leaks or outages from
|
||||
unauthorized access.
|
||||
|
||||
- [Secure your offices and internet access](physical/facilities/README.md)
|
||||
- [Manage your computers](physical/hardware/README.md)
|
||||
|
||||
### Employees
|
||||
|
||||
Your team is your first line of defense—educate, empower, and secure them.
|
||||
|
||||
- [Set up your employees for success](personnel/lifecycle/README.md)
|
||||
- [Secure your emails](personnel/comms/README.md)
|
||||
- [Configure your system access](personnel/access/README.md)
|
||||
|
||||
### Core assets
|
||||
|
||||
These are the heart of your company—prioritize their security.
|
||||
|
||||
- [Secure your codebase](core/src/README.md)
|
||||
- [Secure your infrastructure](core/infra/README.md)
|
||||
- [Protect your network](core/network/README.md)
|
||||
- [Safeguard your data](core/data/README.md)
|
||||
|
||||
### Alert & act
|
||||
|
||||
Be proactive and prepared—track activity and respond quickly to issues.
|
||||
|
||||
- [Log collection and monitoring](operations/monitoring/README.md)
|
||||
- [Prepare for incidents](operations/incidents/README.md)
|
||||
|
||||
### Vendors
|
||||
|
||||
Keep your partnerships secure by managing third-party risks.
|
||||
|
||||
### Transparency
|
||||
|
||||
SOC 2 is about showing how you operate—document and share your processes.
|
||||
|
||||
- [Have a security page](TRA.001_have_a_security_page.md)
|
||||
- [Clearly explain your services](transparency/TRA.002_clearly_explain_your_services.md)
|
||||
- [External support available](TRA.003_external_support_available.md)
|
||||
|
||||
### Review and keep things up to date
|
||||
|
||||
#### Why does it matter?
|
||||
|
||||
Your company changes over time, and so should your security posture.
|
||||
|
||||
#### How can I proceed?
|
||||
|
||||
Some things don’t need review (eg: MFA is enabled), but your infrastructure and
|
||||
your employee are changing.
|
||||
|
||||
⇒ You need to make sure people and digital asset with access are the one working
|
||||
today in/with your company.
|
||||
|
||||
- [Remove unauthorized assets](core/infra/COR.INF.007_asset_decommissioning.md)
|
||||
- [Conduct an access reviews](personnel/access/PER.ACC.006_periodic_access_review.md)
|
||||
- [Test your disaster recovery plan](operations/incidents/OPS.INC.003_drp_testing.md)
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
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)
|
||||
@@ -1,21 +0,0 @@
|
||||
# Safeguard your data
|
||||
|
||||
Your data is one of your company most valuable asset - you must keep it safe
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
It minimizes the risk of unauthorized access, data breaches, and loss. By
|
||||
implementing data security measures, you demonstrates a commitment to protecting
|
||||
client information.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
Implement measures to protect data from unauthorized access and set up processes
|
||||
to regularly secure and monitor its location.
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Automated backup](COR.DAT.001_automated_backup.md)
|
||||
- [Help the auditor with a data-flow diagram](COR.DAT.002_data_flow_diagram.md)
|
||||
- [Encrypt your data storage](COR.DAT.003_data_at_rest.md)
|
||||
- [Encrypt your data in transit](COR.DAT.004_tls.md)
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.001"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.1", "CC4.1"]
|
||||
---
|
||||
|
||||
# List of your Assets
|
||||
|
||||
## Purpose
|
||||
|
||||
The assets that are storing or processing data are potential vulnerabilities
|
||||
that could be exploited. ⇒ You need to know which assets your company has in
|
||||
order to be able to properly manage and secure them.
|
||||
|
||||
## Implementation
|
||||
|
||||
If you don’t have one, create an inventory of all your assets that have the
|
||||
potential to store or process data. This inventory should include:
|
||||
|
||||
- description of the device
|
||||
- location
|
||||
- owner
|
||||
- operating status
|
||||
|
||||
### Google Cloud Platform
|
||||
|
||||
GCP Asset inventory can fulfil this for you if you implement it with systematic
|
||||
tracking and monitoring:
|
||||
|
||||
1. Go to the **GCP console** and enable **Cloud Asset Inventory API**
|
||||
2. Navigate to **API & Services** section, and enable **Cloud Asset API** for
|
||||
the relevant projects
|
||||
3. Identify which assets you want to monitor. You should include (if relevant):
|
||||
1. Compute instances (e.g., VMs)
|
||||
2. Storage (e.g., Cloud Storage Buckets)
|
||||
3. Networking components (e.g., firewalls)
|
||||
4. IAM policies and permissions
|
||||
5. Encryption keys (Cloud KMS)
|
||||
6. Logging (Cloud Audit Logs)
|
||||
4. Set up **automatic collection** of assets using **GCP Cloud Scheduler** or
|
||||
**GCP Cloud Functions** to regularly query and capture inventory snapshots
|
||||
(that way you can maintain a record of changes) OR use glcoud commands/API
|
||||
calls: `gcloud asset search-all-resources --scope=projects/your-project-id`
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your GCP asset inventory list
|
||||
@@ -1,190 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.002"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC4.1", "CC6.8", "CC7.1"]
|
||||
---
|
||||
|
||||
# Scan for security updates
|
||||
|
||||
## Purpose
|
||||
|
||||
An automated security scanning software on your infrastructure components
|
||||
enables you to fix potential vulnerabilities as soon as they are uncovered.
|
||||
|
||||
## Implementation
|
||||
|
||||
### 1/2 - Enable GCP security
|
||||
|
||||
1. Log in to your **Google Cloud Platform** account and navigate to the
|
||||
**Security Command Center**.
|
||||
2. Click **Enable** to activate the Security Command Center for your project or
|
||||
organization.
|
||||
3. If other members of your team need access, go to **IAM & Admin** > **IAM**
|
||||
and assign to them the appropriate roles (**Security Center Admin** or
|
||||
**Viewer**)
|
||||
4. In the **Security Command Center dashboard**, look for **Security sources**
|
||||
and click **Configure** or **Manage Sources**:
|
||||
- **Asset Inventory**: Enables continuous tracking of assets within your GCP
|
||||
project or organization.
|
||||
- **Security Health Analytics**: Automatically scans your resources for
|
||||
common vulnerabilities and misconfigurations.
|
||||
- **Event Threat Detection**: Monitors your logs for suspicious activity and
|
||||
potential threats.
|
||||
- **Web Security Scanner**: Scans your public-facing web applications for
|
||||
known vulnerabilities.
|
||||
5. For each service you want to enable, click on it and follow the prompts to
|
||||
activate it. Configure any necessary settings, such as defining which
|
||||
resources should be scanned or monitored.
|
||||
6. Integrate with other GCP services, such as **Cloud Logging** and **Cloud
|
||||
Monitoring,** to collect detailed logs and metrics.
|
||||
7. Save to update your settings. Verify that each service is active on the
|
||||
Security Sources page.
|
||||
|
||||
### 2/3 - Enable Artifact registry
|
||||
|
||||
<aside>
|
||||
ℹ️
|
||||
|
||||
If you are already using Artifact Registry, make sure **Continuous scanning** is
|
||||
enabled
|
||||
|
||||
</aside>
|
||||
|
||||
1. Log in to your **Google Cloud Platform** account and navigate to **Artifact
|
||||
Registry** under **Storage**.
|
||||
2. Click **Enable API**
|
||||
3. If other team members need access, go to **IAM & Admin** > **IAM** and assign
|
||||
them appropriate roles:
|
||||
- **Artifact Registry Admin**: Full access to manage repositories and
|
||||
artifacts.
|
||||
- **Artifact Registry Writer**: Permission to push artifacts to repositories.
|
||||
- **Artifact Registry Reader**: Read-only access to repositories.
|
||||
4. In **Artifact Registry**, click **Create Repository** and configure the
|
||||
repository:
|
||||
- **Name**: Set a name for your repository.
|
||||
- **Location**: Choose a region or multi-region where the artifacts will be
|
||||
stored.
|
||||
- **Format**: Select the artifact type (e.g., Docker, npm, Maven).
|
||||
- Enable **Continuous Scanning** to automatically scan for known
|
||||
vulnerabilities in container images.
|
||||
5. Click **Create**
|
||||
6. For Docker images, run the following command to configure Docker
|
||||
authentication with `gcloud`: (For other formats like **npm** or **Maven**,
|
||||
follow the instructions in the **Setup instructions** section of your
|
||||
repository).
|
||||
|
||||
```bash
|
||||
gcloud auth configure-docker
|
||||
```
|
||||
|
||||
7. Push artifacts to your repository:
|
||||
- For Docker:
|
||||
```bash
|
||||
docker tag IMAGE_NAME LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME
|
||||
docker push LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME
|
||||
```
|
||||
- For other formats, use the respective package manager (e.g., `npm publish`,
|
||||
`mvn deploy`).
|
||||
8. Verify your repository by navigating to **Artifact Registry > Repositories**,
|
||||
and confirm that the uploaded artifacts appear in the repository.
|
||||
|
||||
### 3/3 - Implement alerts in Slack
|
||||
|
||||
1. Navigate to **Pub/Sub, c**lick **Create Topic**, give it a name (e.g.,
|
||||
`security-artifact-alerts`) and click **Create**
|
||||
2. On the topic you created, click **Create Subscription**, choose a name for
|
||||
the subscription (e.g., `security-artifact-alerts-subscription`), and choose
|
||||
**Pull** as the delivery type..
|
||||
3. Go to the **Security Command Center**, click on **Settings** or
|
||||
**Notifications**, choose **Create Notification**, provide a name for the
|
||||
notification (e.g., `critical-findings-notification`) and select the
|
||||
**resource type** (**Project** or **Organization**) to scope the
|
||||
notification.
|
||||
4. Define conditions for sending notifications, such as:
|
||||
|
||||
- **Severity** (e.g., only send alerts for high or critical severity
|
||||
findings).
|
||||
- **Finding types** (e.g., vulnerability detection, unauthorized access
|
||||
attempts).
|
||||
|
||||
Use filters like:
|
||||
|
||||
```json
|
||||
severity="CRITICAL"
|
||||
```
|
||||
|
||||
5. Choose the **Pub/Sub topic** you created (`security-artifact alerts`) and
|
||||
confirm the connection by allowing **Security Command Center** to publish to
|
||||
this topic.
|
||||
6. Go to **Artifact Registry** > **Repositories** and select a repository.
|
||||
Navigate to **Settings** > **Notifications**.
|
||||
7. Click **Add Notification** and select relevant event types:
|
||||
- **Vulnerability Findings**
|
||||
- **Failed Artifact Uploads**
|
||||
- **Unauthorized Access**
|
||||
8. Link this notification to the same **Pub/Sub topic**
|
||||
(`security-artifact-alerts`).
|
||||
9. Go to Slack API and click **Create New App**. Choose **From scratch**, name
|
||||
the app and select your workspace.
|
||||
10. In the app settings, go to **Incoming Webhooks** and toggle the switch to
|
||||
**Activate Incoming Webhooks**. Click **Add New Webhook to Workspace** and
|
||||
choose the channel where you want to post alerts. Copy the **Webhook URL**
|
||||
provided after adding it - you will use it on GCP.
|
||||
11. Go to **OAuth & Permissions** in the app settings and add the required
|
||||
scope: `chat:write` and `incoming-webhook`
|
||||
12. Send a test message to the channel using the **Webhook URL**:
|
||||
|
||||
```bash
|
||||
curl -X POST -H 'Content-type: application/json' --data '{"text":"Test alert from GCP Security and Artifact"}' YOUR_SLACK_WEBHOOK_URL
|
||||
```
|
||||
|
||||
1. Go to **Cloud Functions** in **Google Cloud Console**, click **Create
|
||||
Function** and provide a name (e.g., `send-alerts-to-slack`), choose
|
||||
**Trigger type** as **Pub/Sub** and select your topic
|
||||
(`security-artifact-alerts`). Set the runtime environment to **Python.**
|
||||
2. Use the following example code to forward alerts to Slack: (replace
|
||||
`YOUR_SLACK_WEBHOOK_URL` with your Slack incoming webhook URL)
|
||||
|
||||
```python
|
||||
import base64
|
||||
import json
|
||||
import requests
|
||||
|
||||
def send_alert_to_slack(event, context):
|
||||
# Decode the Pub/Sub message
|
||||
pubsub_message = base64.b64decode(event['data']).decode('utf-8')
|
||||
alert = json.loads(pubsub_message)
|
||||
|
||||
# Prepare the Slack webhook URL and message format
|
||||
slack_webhook_url = 'YOUR_SLACK_WEBHOOK_URL' # <= To replace
|
||||
message = {
|
||||
'text': f"New Alert: {alert.get('finding', 'No details')} - Severity: {alert.get('severity', 'Unknown')} - Type: {alert.get('eventType', 'Unknown')}"
|
||||
}
|
||||
|
||||
# Send the alert to Slack
|
||||
response = requests.post(slack_webhook_url, json=message)
|
||||
|
||||
if response.status_code != 200:
|
||||
raise ValueError(f"Request to Slack returned an error {response.status_code}, the response is: {response.text}")
|
||||
```
|
||||
|
||||
1. Set the entry point to `send_alert_to_slack` and deploy the function (wait
|
||||
for it to activate).
|
||||
2. Generate a test alert or monitor new alerts in **Security Command Center** to
|
||||
verify that alerts are sent to your Slack channel.
|
||||
- For Security Command Center: Simulate a high-severity finding.
|
||||
- For Artifact Registry: Upload a vulnerable artifact or simulate
|
||||
unauthorized access.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of GCP Security enabled on your project
|
||||
- Screenshot of GCP Security enabled on your registry
|
||||
- Screenshot of Artifact Registry enabled on your registry
|
||||
- Screenshot of an alert received OR of its configuration
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.003"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1"]
|
||||
---
|
||||
|
||||
# IAM for database authentication
|
||||
|
||||
## Purpose
|
||||
|
||||
You want to ensure that only the proper people can access your production
|
||||
database. You also want to avoid the burden of managing another list of users or
|
||||
rotating credentials.
|
||||
|
||||
## Implementation
|
||||
|
||||
### **Set Up Custom IAM Roles for Database Access**
|
||||
|
||||
1. In **Google Cloud Console**, go to **IAM & Admin** > **Roles**.
|
||||
2. Click **Create Role** and define a custom role with only the necessary
|
||||
permissions for your database (for a read-only role:
|
||||
`cloudsql.instances.connect`, `cloudsql.instances.get`)
|
||||
3. Save the role.
|
||||
|
||||
### **Assign Least Privilege Roles to Users or Service Accounts**
|
||||
|
||||
1. Go to **IAM & Admin** > **IAM**
|
||||
2. Click **Add** to assign the custom role to specific users or service accounts
|
||||
that require production database access.
|
||||
3. In the **New principals** field, enter the email of the user or service
|
||||
account.
|
||||
4. Under **Role**, choose the custom role you created.
|
||||
5. **Save**
|
||||
|
||||
### **Enable IAM Database Authentication (Cloud SQL Only)**
|
||||
|
||||
1. Go to **Cloud SQL** > **Instances**
|
||||
2. Select your production database instance.
|
||||
3. Under **Connections**, find the **Database Authentication** section and
|
||||
enable **IAM database authentication** (allows users with the necessary IAM
|
||||
roles to authenticate with their IAM credentials).
|
||||
|
||||
### Test access
|
||||
|
||||
1. In **Cloud Audit Logs** (under **Logging** > **Logs Explorer**), search for
|
||||
`cloudsql.googleapis.com` to view access logs.
|
||||
2. Verify that access is limited to authorized users.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot showing IAM is active on your Cloud SQL
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.004"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.3"]
|
||||
---
|
||||
|
||||
# Plug GCP & Github
|
||||
|
||||
## Purpose
|
||||
|
||||
Having credentials to manage can become a nightmare (especially if you need to
|
||||
change/rotate them often) - it quickly becomes time consuming. It is the same
|
||||
with lifetime tokens - someone leaving and you need to change them.
|
||||
|
||||
## Implementation
|
||||
|
||||
### **1. Create a Workload Identity Pool in GCP**
|
||||
|
||||
1. In **Google Cloud Console**, go to **IAM & Admin** > **Workload Identity
|
||||
Federation**.
|
||||
2. Click **Create Pool**, name it (e.g., `github-pool`), and set a
|
||||
**description**.
|
||||
3. Select **Provider type:** **OIDC** (OpenID Connect).
|
||||
4. Under **Provider details**, enter: **Issuer URL**:
|
||||
`https://token.actions.githubusercontent.com`
|
||||
5. Click **Create** to finish setting up the pool.
|
||||
|
||||
### 2. **Create a Workload Identity Provider in the Pool**
|
||||
|
||||
1. In the pool, go to **Providers** and click **Add Provider**.
|
||||
2. Name the provider (e.g., `github-provider`).
|
||||
3. Set **Issuer URL** to `https://token.actions.githubusercontent.com`.
|
||||
4. **Attribute mapping**: Add a mapping to verify the GitHub repository:
|
||||
1. `google.subject` → `assertion.sub`
|
||||
2. `attribute.repository` → `assertion.repository`
|
||||
3. `attribute.ref` → `assertion.ref`
|
||||
4. `attribute.owner` → `assertion.repository_owner`
|
||||
5. Click **Create** to add the provider.
|
||||
|
||||
### 3. **Grant IAM Permissions on GCP**
|
||||
|
||||
1. Go to **IAM & Admin** > **IAM**.
|
||||
2. Find the GCP service account you want GitHub Actions to use, or create a new
|
||||
one.
|
||||
3. Click **Add Principal** and specify the **Workload Identity Pool** (in the
|
||||
format:
|
||||
`principal://iam.googleapis.com/projects/PROJECT_ID/locations/global/workloadIdentityPools/POOL_ID/attribute.repository/OWNER/REPO`).
|
||||
4. Assign the necessary **roles** (e.g., `Viewer`, `Editor`) to allow access to
|
||||
resources.
|
||||
|
||||
### 4. **Configure GitHub Actions to Use Workload Identity**
|
||||
|
||||
1. In your **GitHub repository**, go to **Settings** > **Secrets and
|
||||
variables** > **Actions**.
|
||||
2. Add a new secret (e.g., `GCP_WORKLOAD_IDENTITY_PROVIDER`) containing the GCP
|
||||
**Workload Identity Provider** details.
|
||||
|
||||
### 5. **Set Up GitHub Actions Workflow**
|
||||
|
||||
- In your **GitHub Actions workflow YAML file** (e.g.,
|
||||
`.github/workflows/deploy.yml`), add steps to authenticate:
|
||||
```yaml
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Configure Google Cloud authentication
|
||||
uses: google-github-actions/auth@v0
|
||||
with:
|
||||
workload_identity_provider:
|
||||
${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }}
|
||||
service_account: YOUR_GCP_SERVICE_ACCOUNT_EMAIL
|
||||
- name: Run GCP commands
|
||||
run: gcloud projects list
|
||||
```
|
||||
|
||||
This setup enables secure, temporary access from **GitHub Actions** to **GCP**
|
||||
resources without needing to store long-term credentials.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your Github actions workflow.
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.005"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.3"]
|
||||
---
|
||||
|
||||
# Manage your service accounts
|
||||
|
||||
## Purpose
|
||||
|
||||
You don’t want to use the “default” service account, it has way too many
|
||||
permissions - it is a super administrator. Even GCP is asking you not to use it,
|
||||
it is only here for legacy reasons. In the same idea, grant your service
|
||||
accounts only what is necessary.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Cloud Platform
|
||||
|
||||
1. Make sure the default service account is not used by any service - if it is
|
||||
the case, create a new service account (with only View and/or Edit
|
||||
permission) and use it.
|
||||
2. Make sure all your service accounts are only Viewer or Editor - you shouldn’t
|
||||
have any admin or owner.
|
||||
3. Delete the default service account if not used anymore
|
||||
|
||||
Note: if you have IaC, it does make sense to have a service account as Admin,
|
||||
but except in this kind of specific case: no admin
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.006"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC5.3", "CC7.1", "CC7.2", "CC8.1"]
|
||||
---
|
||||
|
||||
# Keep an history of all your changes
|
||||
|
||||
## Purpose
|
||||
|
||||
Infrastructure as Code (IaC) makes sure all your infrastructure changes are done
|
||||
in a standardized and repeatable process - the chance of human error is lower.
|
||||
Moreover, IaC enables version control and peer reviews. When growing, you will
|
||||
have to do it - the earlier the better (later, it can become really painful).
|
||||
|
||||
## Implementation
|
||||
|
||||
**Option 1:** If you don’t want an IaC, in the evidence section, provide a
|
||||
screenshot of some log of your infrastructure changes
|
||||
|
||||
**Option 2:** If you already have an IaC, go directly to the evidence section,
|
||||
we only need a screenshot.
|
||||
|
||||
**Option 3:** If you don’t have one, we recommend Terraform - the documentation
|
||||
is available [here](https://developer.hashicorp.com/terraform/tutorials).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot showing some logs
|
||||
- Screenshot of the query you are performing in GCP to see your logs
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: "COR.INF.007"
|
||||
category: "core/infra"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.1", "CC6.8"]
|
||||
---
|
||||
|
||||
# Remove unauthorized assets
|
||||
|
||||
## Purpose
|
||||
|
||||
Outdated/unmonitored/etc.. assets (VMs, Buckets, etc..) pose a significant risk:
|
||||
|
||||
- They can be used for malicious activities
|
||||
- You don’t manage them, they could lack proper security measures.
|
||||
|
||||
## Implementation
|
||||
|
||||
Review the list of authorized asset you created
|
||||
[List of your assets](./COR.INF.001_list_your_assets.md) , identify the ones
|
||||
that should not be there, and select the proper action:
|
||||
|
||||
- Disconnect the asset from your network
|
||||
- Scan for security updates on the asset and ensure proper access control
|
||||
@@ -1,25 +0,0 @@
|
||||
# Secure your infrastructure
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Your infrastructure holds your sensitive data and makes sure your service is
|
||||
available to your customers. Protecting it from unauthorized access or attacks
|
||||
is key to prevent any data leak or service outage.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
To secure your infrastructure, you will need to:
|
||||
|
||||
1. Understand what your are protecting
|
||||
2. Regulate access
|
||||
3. Log changes
|
||||
4. Fix known vulnerabilities
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [List of your assets](COR.INF.001_list_your_assets.md)
|
||||
- [Scan for security updates](COR.INF.002_scan_security_updates.md)
|
||||
- [IAM for database authentication](COR.INF.003_iam_authentication_for_database.md)
|
||||
- [Plug GCP & Github](COR.INF.004_short_live_auth_ci.md)
|
||||
- [Manage your service accounts](COR.INF.005_manage_service_account.md)
|
||||
- [Keep an history of all your changes](COR.INF.006_keep_an_history_of_all_your_changes.md)
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
id: "COR.NET.001"
|
||||
category: "core/network"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-12"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.6", "CC6.7"]
|
||||
---
|
||||
|
||||
# Restrict public access on your infrastructure
|
||||
|
||||
## Purpose
|
||||
|
||||
Public access to your company's infrastructure is a serious security risk. By
|
||||
configuring your cloud provider to restrict public access, you can reduce the
|
||||
risk of unauthorized access to your sensitive data and systems.
|
||||
|
||||
## Implementation
|
||||
|
||||
- Ensure your cloud storage buckets are private (it should be the case by
|
||||
default)
|
||||
1. **Go to the Google Cloud Console,** navigate to **Cloud Storage**.
|
||||
2. In **Permissions**, enable **Uniform Bucket-Level Access** to enforce
|
||||
bucket-level permissions (and not individual object level).
|
||||
3. Remove any **AllUsers** or **allAuthenticatedUsers** roles, as these allow
|
||||
public access.
|
||||
4. Assign only required roles (e.g., `Storage Admin` or
|
||||
`Storage Object Viewer`) to specific users or groups. If you need a bucket
|
||||
to have public access for its purpose (e.g. CDN buckets) :
|
||||
5. Document why this bucket needs to be public in the evidence section
|
||||
6. Disable **Uniform Bucket-Level Access** and proceed at the bucket level.
|
||||
For each:
|
||||
1. Select your bucket
|
||||
2. Under **Bucket Permissions**, remove any **AllUsers** or
|
||||
**allAuthenticatedUsers** roles
|
||||
- Remove the default network The default network in GCP rely on a set of
|
||||
rules/access that can’t be disabled and are “unsafe”. That is why it is better
|
||||
to create your own network.
|
||||
<aside>
|
||||
🚨
|
||||
|
||||
First, replace the default network with a network that allows access only to the services you have enabled.
|
||||
|
||||
</aside>
|
||||
|
||||
1. Once the default network is no longer used, go to [VPC networks](https://console.cloud.google.com/networking/networks/list) on your Google Cloud Console
|
||||
2. Click the network named `default`.
|
||||
3. Click DELETE VPC NETWORK at the top of the page.
|
||||
- Restrict public SSH access If you need to enable access to your system,
|
||||
leverage **Google Cloud Identity-Aware Proxy (IAP)** as a secure alternative
|
||||
to direct SSH. IAP will let you access your VMs via SSH without exposing them
|
||||
publicly, it eliminates the need for public IPS or open SSH ports.
|
||||
1. In **GCP Console**, go to **Identity-Aware Proxy** and enable it for the
|
||||
project.
|
||||
2. Grant the user or group with **IAP-secured Tunnel User** (network access)
|
||||
and **Compute Instance Admin** (SSH permissions) roles.
|
||||
1. It works even for external users as long as they have a google account.
|
||||
To access the VMs, user need to run a command locally via the **gcloud
|
||||
CLI** to tunnel SSH traffic through IAP:
|
||||
```bash
|
||||
gcloud compute ssh <INSTANCE_NAME> --tunnel-through-iap
|
||||
```
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot showing your storage bucket configuration.
|
||||
- Screenshot showing your networks.
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: "COR.NET.002"
|
||||
category: "core/network"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-12"
|
||||
estimate-time: "30m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.6"]
|
||||
---
|
||||
|
||||
# Set-up a WAF
|
||||
|
||||
## Purpose
|
||||
|
||||
A web application protection service acts as a security shield that:
|
||||
|
||||
Filters malicious traffic (SQL injections, XSS attacks) Masks your server's real
|
||||
IP address Blocks DDoS attacks and malicious bots Controls request rates to
|
||||
prevent abuse
|
||||
|
||||
This ensures your applications stay secure and available while legitimate
|
||||
traffic flows normally.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Cloudflare
|
||||
|
||||
1. **Sign up for Cloudflare**: Go to [Cloudflare](https://www.cloudflare.com/)
|
||||
and create an account.
|
||||
2. **Add your domain**: Enter your website’s domain and let Cloudflare scan
|
||||
existing DNS records.
|
||||
3. **Update your DNS**: Change your domain's nameservers to Cloudflare’s
|
||||
nameservers as provided in your Cloudflare dashboard.
|
||||
4. **Configure your security settings**:
|
||||
- **Enable the Web Application Firewall (WAF)**: Set up rules to block
|
||||
threats like SQL injections and XSS attacks.
|
||||
- **Enable DDoS Protection**: Configure DDoS settings to prevent service
|
||||
interruptions.
|
||||
5. **Optional - Set up Access controls**:
|
||||
- Use **IP Access Rules** to allow or block specific IPs.
|
||||
- Configure **Rate Limiting** to prevent excessive requests that could signal
|
||||
attacks.
|
||||
6. **Review and Test**: Ensure that your website operates smoothly, and verify
|
||||
that rules are correctly blocking or allowing traffic.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your WAF configuration.
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
id: "COR.NET.003"
|
||||
category: "core/network"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-12"
|
||||
estimate-time: "30m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC3.2", "CC4.1", "CC8.1"]
|
||||
---
|
||||
|
||||
# Run a penetration test
|
||||
|
||||
## Purpose
|
||||
|
||||
It is a good way to safeguard your company’s data. It is a real-life simulation
|
||||
of attack scenarios on your company: it enables you to identify potential
|
||||
vulnerabilities that can be fixed before being exploited.
|
||||
|
||||
## Implementation
|
||||
|
||||
Schedule a penetration test with a third party.
|
||||
|
||||
## Evidence
|
||||
|
||||
Your penetration test report.
|
||||
@@ -1,23 +0,0 @@
|
||||
# Protect your Network
|
||||
|
||||
Your network connects your devices, servers, and systems.
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Protecting your network is essential for the data and services your company
|
||||
provides. Network security helps ensure that sensitive data is accessible only
|
||||
to authorized users and that systems remain operational and resilient to
|
||||
attacks.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
Strengthening network security in a targeted, efficient way is essential. By
|
||||
restricting access to infrastructure, implementing protective layers like
|
||||
Cloudflare, and conducting regular security assessments, you can effectively
|
||||
safeguard your systems against unauthorized access and potential attacks.
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Restrict public access on your infrastructure](COR.NET.001_restrict_public_access_on_your_infrastructure.md)
|
||||
- [Set-up a WAF](COR.NET.002_web_application_firewall.md)
|
||||
- [Run a penetration test](COR.NET.003_penetration_test.md)
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: "COR.SRC.001"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
||||
---
|
||||
|
||||
# Code Review
|
||||
|
||||
## Purpose
|
||||
|
||||
Requiring pull requests and code reviews ensures higher code quality and
|
||||
security by allowing multiple team members to catch bugs, inefficiencies, and
|
||||
potential vulnerabilities before code is merged. It also promotes collaboration,
|
||||
knowledge sharing, and accountability within the team. This process helps
|
||||
prevent issues in production and maintains adherence to coding standards.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Github
|
||||
|
||||
1. Open your GitHub repository and go to settings.
|
||||
2. In "Branche"s, click "Add Rule".
|
||||
3. Enter the branch name (e.g. "main") in the branch name pattern field.
|
||||
4. Enable: "Require a pull request before merging"
|
||||
5. Click Create or Save to apply the rule
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of branch protection rules configuration
|
||||
- Documentation of PR review process
|
||||
- Sample PR showing enforced requirements
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
id: "COR.SRC.002"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC4.1", "CC8.1"]
|
||||
---
|
||||
|
||||
# Configure Code Scanning
|
||||
|
||||
## Purpose
|
||||
|
||||
It ensures that potential security flaws are detected early. This proactive
|
||||
approach strengthens your security posture and helps maintain high code quality.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Github
|
||||
|
||||
1. Go to the "Security" tab of your repository.
|
||||
2. Click on "Set up code scanning".
|
||||
3. Select "Set up this workflow" under "CodeQL Analysis".
|
||||
4. Review the YAML file and commit it to your repository.
|
||||
|
||||
Code scanning will now run every time code is pushed to the repository, and
|
||||
results will appear in the Security tab.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of code scanning results from Security tab
|
||||
- Sample of resolved security alerts
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: "COR.SRC.003"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC4.1", "CC8.1"]
|
||||
---
|
||||
|
||||
# Configure Dependancy Vulnerability Alerts
|
||||
|
||||
## Purpose
|
||||
|
||||
It ensures your project stays secure and up-to-date without manual tracking of
|
||||
dependencies. It also reduces the risk of using outdated or insecure libraries
|
||||
in your codebase.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Github
|
||||
|
||||
1. Go to your repository on GitHub.
|
||||
2. Click on the "Settings" tab.
|
||||
3. On the left sidebar, click "Security & analysis".
|
||||
4. Under "Dependabot alerts", ensure "Dependency graph" and "Dependabot security
|
||||
updates" are enabled.
|
||||
5. GitHub will now alert you to any vulnerable dependencies and automatically
|
||||
open pull requests to fix them.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of Dependabot configuration screen
|
||||
- Sample of dependency update PRs
|
||||
- Vulnerability alert history
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: "COR.SRC.004"
|
||||
category: "core/src"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC5.2", "CC8.1"]
|
||||
---
|
||||
|
||||
# Document your Development Lifecycle
|
||||
|
||||
## Purpose
|
||||
|
||||
Formalizing a proper development lifecycle helps your engineer in their jobs and
|
||||
helps you to scale your team. It reduces the chances of human error.
|
||||
|
||||
## Implementation
|
||||
|
||||
Write a document with your development lifecycle. It should include: planning,
|
||||
analysis, design, coding, testing, and maintenance. Don’t forget secure coding
|
||||
practices (eg code review) and quality.
|
||||
|
||||
## Evidence
|
||||
|
||||
- System development lifecycle document
|
||||
@@ -1,25 +0,0 @@
|
||||
# Secure your codebase
|
||||
|
||||
Your code is one of your most valuable asset, you want to be sure things are
|
||||
running smoothly and in a predictable way.
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
A proper development lifecycle insure your application is iterated on in a
|
||||
secure and systematic manner. It reduces the chances of error or vulnerabilities
|
||||
and so increase the stability, integrity and security of your software. Also, it
|
||||
helps you scale your engineering team.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
- **Communicate policies:** Publish and update key documents and services.
|
||||
- **Implement structured processes:** Define a development lifecycle for
|
||||
software, adopt Infrastructure-as-Code (IaC), and deploy configuration
|
||||
management systems to maintain consistency and security.
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Code Review](COR.SRC.001.patch_review.md)
|
||||
- [Configure Code Scanning](COR.SRC.002.enable_code_scanning.md)
|
||||
- [Configure Dependancy Vulnerability Alerts](COR.SRC.003.dependancy_vulnerability_alerts.md)
|
||||
- [Document your Development Lifecycle](COR.SRC.004.systems_development_life_cycle.md)
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
id: "OPS.INC.001"
|
||||
category: "operations/incidents"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.2"]
|
||||
---
|
||||
|
||||
# Build an incident response process
|
||||
|
||||
## Purpose
|
||||
|
||||
An incident response plan is crucial for quickly identifying, containing, and
|
||||
resolving incidents, minimizing potential disruptions. It ensures you’re
|
||||
prepared effectively and that you keep your operations running smoothly, even in
|
||||
the face of unexpected threats.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Build an Incident Response Plan and share it with your team.
|
||||
|
||||
Template:
|
||||
|
||||
[Incident response plan](templates/incident_response_plan.md)
|
||||
|
||||
### Create a slack channel
|
||||
|
||||
Create a slack channel to allow your team to raise incident and be kept aware of
|
||||
their resolution
|
||||
|
||||
1. Create a channel (eg `#incident`)
|
||||
2. Pin the **Incident Response Plan** in the channel for quick access.
|
||||
3. Establish guidelines for using the channel, including:
|
||||
1. How to report incidents (e.g., “Post a message with a brief summary and
|
||||
relevant context”).
|
||||
2. Expected response times for acknowledgment and updates.
|
||||
4. Assign roles for incident management, such as:
|
||||
1. **On-duty engineer**: Monitors and triages notifications.
|
||||
2. **Response team**: Engineers responsible for handling and resolving
|
||||
incidents.
|
||||
5. Set up reminders or periodic messages in Slack to encourage proactive
|
||||
monitoring and review of unresolved issues.
|
||||
6. Integrate relevant notifications, if applicable, into the Slack channel for
|
||||
visibility (e.g., system alerts or logs).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Share your incident response plan
|
||||
- screenshot of your #incident slack channel being used (with postmortem
|
||||
visible)
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
id: "OPS.INC.002"
|
||||
category: "operations/incidents"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "6h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.2"]
|
||||
---
|
||||
|
||||
# Disaster Recovery Plan (DRP)
|
||||
|
||||
## Purpose
|
||||
|
||||
Disasters might seem far-fetched, but data loss, service outages, and
|
||||
misconfigurations can happen. Whether it's a simple human error or a regional
|
||||
outage, a DRP helps your team recover fast and maintain customer trust.
|
||||
|
||||
## Implementation
|
||||
|
||||
Here is a basic template, to use as a good starting point:
|
||||
|
||||
[DRP Template](https://www.notion.so/DRP-Template-13e1cc0bd5bc800d9db2f77d3c884521?pvs=21)
|
||||
|
||||
<aside>
|
||||
💡
|
||||
|
||||
If it is easier to manage, you can have several DRP: one for your database, one
|
||||
for your network, one for your infra, etc… that way, when testing, you can test
|
||||
smaller part of it and it adapts better to potential real life events.
|
||||
|
||||
</aside>
|
||||
|
||||
The idea is to be prepared for the unexpected. You don’t need to overthink
|
||||
things, it’s more to know what to do when you will be in the rush of a regional
|
||||
outage. For that, your DRP needs to cover:
|
||||
|
||||
1. **Scope & timings**: clear scope and the expected time to do it
|
||||
2. **Step-by-step:** guide on how to proceed
|
||||
3. **Contacts**: list of internal and external contacts crucial during a
|
||||
disaster.
|
||||
4. **Testing and Review Log**: A record of tests performed to validate the DRP’s
|
||||
effectiveness and any improvements made.
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: "OPS.INC.002"
|
||||
category: "operations/incidents"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-15"
|
||||
estimate-time: "6h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC3.2", "CC5.1", "CC7.5", "CC8.1"]
|
||||
---
|
||||
|
||||
# Test your disaster recovery plan
|
||||
|
||||
## Purpose
|
||||
|
||||
Having a plan with dust on it is useless. The goal of having a Disaster Recovery
|
||||
Plan is to be able to insure business continuity. As things are moving in your
|
||||
company, you need to check whether your DRP is still legit and whether you are
|
||||
able to properly run it.
|
||||
|
||||
## Implementation
|
||||
|
||||
At least once a year, you need to test your DRP and, if possible, improve it.
|
||||
Follow the instructions on yours and log the outcomes. Did it work?
|
||||
|
||||
## Evidence
|
||||
|
||||
- Link to the logs of your last test
|
||||
@@ -1,16 +0,0 @@
|
||||
# Prepare for incidents
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Let’s face it, you won’t be the exception with no incident ever. As it is going
|
||||
to happen to you, it is best to prepare for such event in order to reduce their
|
||||
impacts.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
Create a procedure to restore services and test it
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Build an incident response process](OPS.INC.001_incident_response_process.md)
|
||||
- [Disaster Recovery Plan](OPS.INC.002_drp.md)
|
||||
@@ -1,50 +0,0 @@
|
||||
# DRP Template
|
||||
|
||||
### **Overview and Objectives**
|
||||
|
||||
- **Purpose**: Provide step-by-step instructions to recover **[Critical
|
||||
Services]** in case of a disaster, ensuring minimum downtime and data
|
||||
protection.
|
||||
- **Scope**: This plan applies to **[Specify Services, e.g., Cloud SQL,
|
||||
application servers, etc.]**.
|
||||
- **Objectives**: Restore critical services within **[Define Recovery Time
|
||||
Objective, e.g., 2 hours]**.
|
||||
|
||||
### Instructions
|
||||
|
||||
<aside>
|
||||
⚠️
|
||||
|
||||
- Don’t overthink it.
|
||||
- Unless specifically required by a customer, don’t change your cloud provider
|
||||
for the recovery
|
||||
</aside>
|
||||
|
||||
1. Create a VM
|
||||
2. Run the following commands to log-in and to install the minimum software
|
||||
|
||||
`your commands`
|
||||
|
||||
3. Allow the VM to connect to the Database
|
||||
|
||||
`your commands`
|
||||
|
||||
4. Check the service is running
|
||||
|
||||
### **Troubleshooting**
|
||||
|
||||
> In this section provide everything you think it can help people running the
|
||||
> instruction e.g. “Connection Refused”, “Docker Image does not exist”, etc.
|
||||
|
||||
### **Contact Information**
|
||||
|
||||
| Role | Name | Contact Info | Backup Contact |
|
||||
| ---------------------- | ----------- | ---------------------- | --------------------- |
|
||||
| CTO | [Name] | [Email, Phone] | [Backup Contact] |
|
||||
| Cloud Provider Support | GCP Support | [Support Contact Info] | [Alternative Contact] |
|
||||
|
||||
### **Testing and Review Log**
|
||||
|
||||
| Date | Test Type | Result | Notes/Improvements |
|
||||
| ------------ | ----------------------- | ---------- | ------------------------------------- |
|
||||
| [YYYY-MM-DD] | Backup Restoration Test | Successful | Updated recovery steps for [Service]. |
|
||||
@@ -1,63 +0,0 @@
|
||||
### **1. Triage & validate**
|
||||
|
||||
The on-duty engineer receives the notification, he/she analyze logs, system
|
||||
behaviors, and context related to the indication versus known behaviors.
|
||||
|
||||
He/She needs to determine whether the notification is legit or not:
|
||||
|
||||
1. If it is legit ⇒ it is promoted to an ongoing incident. In the thread, CTO is
|
||||
notified and a message is posted with:
|
||||
|
||||
- A brief summary of the incident
|
||||
- Any immediate risks or concerns
|
||||
- Preliminary findings and scope (if known)
|
||||
- Ping for the relevant engineer (the response team).
|
||||
|
||||
⇒ the response team commences work.
|
||||
|
||||
2. If it is not (ie a false alarm), a message is posted in the thread with the
|
||||
reason for dismissal. The on-duty engineer needs to:
|
||||
- Determine and address the root cause for the false alarm. He/she needs to
|
||||
remediate any system or process issues that led to it.
|
||||
- End the incident response process
|
||||
|
||||
### **2. Handling & Resolution**
|
||||
|
||||
Resolution occurs in 3 steps detailed below. All decisions or actions taken must
|
||||
be documented.
|
||||
|
||||
1. **Contain:**
|
||||
|
||||
If possible, isolate system to prevent the incident from spreading or causing
|
||||
additional damage
|
||||
|
||||
1. **Eradicate:**
|
||||
|
||||
Identify and remove the root cause of the incident - roll back is a strong
|
||||
option.
|
||||
|
||||
1. **Recover:**
|
||||
|
||||
Resume normal business operations by restoring system functionality. Keep strong
|
||||
monitoring to catch any signs of repetition.
|
||||
|
||||
At the end of this process, an update is posted on the thread to keep all team
|
||||
informed. If the complete process takes longer than 30min, a quick update will
|
||||
be given in the thread every 30min so stakeholders are aware of the current
|
||||
state.
|
||||
|
||||
### **3. Postmortem**
|
||||
|
||||
Once the incident is resolved, the on-duty engineer document the findings,
|
||||
decisions and actions taken during the event in a document to which he/she joins
|
||||
recommendations. This document must be shared with stakeholders.
|
||||
|
||||
The postmortem document must answer:
|
||||
|
||||
- What was the incident? What happened?
|
||||
- Which decisions or actions were taken to respond?
|
||||
- What could have prevented it from happening?
|
||||
- What can be improved in terms of security, processes, communication, tools,
|
||||
etc.?
|
||||
|
||||
The CTO must validate and ensure that recommended improvements are implemented.
|
||||
@@ -1,124 +0,0 @@
|
||||
---
|
||||
id: "OPS.MON.001"
|
||||
category: "operations/monitoring"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.1", "CC6.1", "CC6.6", "CC6.8", "CC7.1", "CC7.2", "CC7.3"]
|
||||
---
|
||||
|
||||
# Configure logs and implement real-time monitoring
|
||||
|
||||
## Purpose
|
||||
|
||||
It allows you to detect and respond to potential security incidents or system
|
||||
failures immediately, minimizing downtime and reducing the risk of data
|
||||
breaches. It maintain visibility into system performance and security events.
|
||||
|
||||
## Implementation
|
||||
|
||||
If you are only relying on GCP for everything, you can use the GCP solution:
|
||||
|
||||
- Leverage GCP solution
|
||||
|
||||
1. **Install the Monitoring Agent** on your VMs: SSH into your VM and install
|
||||
the agent.
|
||||
|
||||
```bash
|
||||
curl -sSO https://dl.google.com/cloudagents/add-monitoring-agent-repo.sh
|
||||
sudo bash add-monitoring-agent-repo.sh
|
||||
sudo apt-get update
|
||||
sudo apt-get install stackdriver-agent
|
||||
```
|
||||
|
||||
2. In Google Cloud Console, go to **Monitoring** > **Dashboards** and enable
|
||||
**Google Cloud Operations Suite** (formerly Stackdriver).
|
||||
3. Use **Cloud Monitoring** to set up **dashboards**, track key metrics (CPU,
|
||||
memory, latency), and create **alerting policies** for real-time
|
||||
notifications on critical events.
|
||||
|
||||
Else, we recommend either Grafana or Datadog:
|
||||
|
||||
### Implement Datadog with GCP
|
||||
|
||||
1. Go to the [Datadog website](https://www.datadoghq.com/) and sign up for an
|
||||
account.
|
||||
2. **Install the Datadog Agent** on your GCP VMs:
|
||||
|
||||
- **SSH** into your VM.
|
||||
- Run the installation command for the Datadog agent. For Debian/Ubuntu:
|
||||
|
||||
```bash
|
||||
DD_API_KEY=<YOUR_API_KEY> bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)"
|
||||
```
|
||||
|
||||
⇒ Replace `<YOUR_API_KEY>` with your Datadog API key (found in the Datadog
|
||||
dashboard under **Integrations** > **APIs**).
|
||||
|
||||
3. **Enable Google Cloud Logging**:
|
||||
- In the **Google Cloud Console**, navigate to **Logging** > **Logs Router**.
|
||||
- Click **Create Sink** and name it **Datadog Logs**.
|
||||
- Set **destination** to **Pub/Sub** and create a new Pub/Sub topic (e.g.,
|
||||
`datadog-logs`).
|
||||
4. **Connect Pub/Sub to Datadog**:
|
||||
- In **Datadog**, go to **Integrations** > **Google Cloud**.
|
||||
- Enable the **Pub/Sub** integration and follow the steps to link it to your
|
||||
GCP project.
|
||||
- Create a service account with the appropriate permissions
|
||||
(`pubsub.subscriber`) and add it to the Pub/Sub topic created.
|
||||
5. **Send Logs to Datadog**:
|
||||
- Configure the Pub/Sub topic to export logs from Google Cloud to Datadog.
|
||||
- Ensure logs from GCP services like Compute Engine, Cloud Functions, etc.,
|
||||
are routed to this topic.
|
||||
6. **Monitor Logs in Datadog**:
|
||||
- In Datadog, navigate to **Logs** to see real-time logs from your GCP
|
||||
infrastructure.
|
||||
- Set up **alerts** or **dashboards** for monitoring specific log patterns or
|
||||
critical events.
|
||||
|
||||
### Implement Grafana with GCP
|
||||
|
||||
- **Create a Grafana Cloud Account**: Sign up at
|
||||
[Grafana Cloud](https://grafana.com/).
|
||||
- **Install the Grafana Agent** on GCP VMs:
|
||||
- **SSH** into your VM.
|
||||
- Download and install the Grafana Agent:
|
||||
```bash
|
||||
sudo curl -O -L https://raw.githubusercontent.com/grafana/agent/main/install-agent.sh
|
||||
sudo bash install-agent.sh
|
||||
```
|
||||
- Configure it with your **Grafana Cloud credentials**.
|
||||
- **Enable Google Cloud Logging**:
|
||||
- In **Google Cloud Console**, go to **Logging** > **Logs Router**.
|
||||
- Create a **Sink** and select **Pub/Sub** as the destination.
|
||||
- Set up a **Pub/Sub topic** for Grafana logs.
|
||||
- **Configure Pub/Sub for Grafana**:
|
||||
- In **Grafana Cloud**, set up **Loki** (for log aggregation).
|
||||
- Configure **Pub/Sub** to forward logs to **Loki** by creating a service
|
||||
account with `pubsub.subscriber` permissions.
|
||||
- **Monitor Logs in Grafana**:
|
||||
- Go to **Explore** in Grafana to view and search logs.
|
||||
- Set up **dashboards** or **alerts** for important log data.
|
||||
|
||||
Once the chosen solution is installed, you need to implement your first
|
||||
dashboard (if not already the case). At least, we think you should be able to
|
||||
follow:
|
||||
|
||||
- Availability:
|
||||
- Resource usage (CPU, memory, storage)
|
||||
- System downtime event
|
||||
- Optional:
|
||||
- Uptime
|
||||
- Latency
|
||||
- Access:
|
||||
- Failed log attemps, unauthorized access, MFA usage
|
||||
- Integrity:
|
||||
- Error rate (eg. rate of 500s)
|
||||
- Data loss or corruption (inc. transaction failures)
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of the metrics you are tracking.
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: "OPS.MON.002"
|
||||
category: "operations/monitoring"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC7.3"]
|
||||
---
|
||||
|
||||
# Keep your logs
|
||||
|
||||
## Purpose
|
||||
|
||||
Logs help you to detect and investigate security incidents and troubleshoot
|
||||
operational issues. They provide an audit trail.
|
||||
|
||||
## Implementation
|
||||
|
||||
You should consider a retention period of at least 90 days, and up to 1 year.
|
||||
|
||||
- **If you are using Grafana ⇒ Grafana Loki**: Configure the retention period in
|
||||
`loki-config.yaml`.
|
||||
- **If you rely on GCP**: In **Cloud Logging**, navigate to **Logs Router** and
|
||||
adjust log sink retention settings.
|
||||
|
||||
If you are using Datadog:
|
||||
|
||||
1. Go to **Logs Management**
|
||||
2. Set the retention period (3 to 15 days depending on your plan).
|
||||
3. As you are limited in time, also set up the configuration in GCP.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your configuration in GPC or Grafana
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
id: "OPS.MON.003"
|
||||
category: "operations/monitoring"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.6", "CC6.8", "CC7.1", "CC7.2", "CC7.3"]
|
||||
---
|
||||
|
||||
# Be automatically notified of issues
|
||||
|
||||
## Purpose
|
||||
|
||||
Setting up alerting allows you to respond quickly and minimize downtime or
|
||||
potential data breaches. It ensures that important events, such as unauthorized
|
||||
access or system failures, are addressed promptly.
|
||||
|
||||
## Implementation
|
||||
|
||||
You should implement alerts for critical events (if you have alerts on
|
||||
everything, its not alerting anymore). You should consider:
|
||||
|
||||
- **Resource Utilization**: Monitor high CPU, memory, or disk usage to prevent
|
||||
downtime or system crashes.
|
||||
- **System Downtime**: Set alerts for system unavailability or critical services
|
||||
going offline.
|
||||
- **Network Traffic Anomalies**: Monitor for unusual spikes or patterns in
|
||||
network traffic that could indicate a potential attack.
|
||||
- Optional:
|
||||
- **Unauthorized Access Attempts:** Track and alert on failed logins, unusual
|
||||
login locations, or excessive login attempts.
|
||||
|
||||
To set up an alert:
|
||||
|
||||
### In Cloud Monitoring for GCP:
|
||||
|
||||
1. Navigate to **Monitoring** > **Alerting**.
|
||||
2. Click **Create Policy**.
|
||||
3. Select **Add Condition**, then choose the metric you want to monitor (e.g.,
|
||||
CPU usage).
|
||||
4. Define the alert conditions (e.g., CPU > 80% for 5 minutes).
|
||||
5. Choose how to be notified (email, SMS, **Slack**).
|
||||
6. Name your alert and click **Save** to activate it.
|
||||
|
||||
### In Grafana
|
||||
|
||||
1. Log into your Grafana instance, go to the **Dashboards** section and select
|
||||
the relevant dashboard.
|
||||
2. In the dashboard, add a **panel** that visualizes the metric you want to
|
||||
monitor.
|
||||
3. In the panel settings, go to the **Alert** tab.
|
||||
4. Click **Create Alert** and set conditions (e.g., CPU > 80% for 5 minutes).
|
||||
5. Define the notification channels (e.g., email, Slack) in the **Contact
|
||||
Points** section.
|
||||
6. Save the panel and dashboard. The alert is now active and will notify you
|
||||
when the conditions are met.
|
||||
|
||||
### In Datadog
|
||||
|
||||
1. Go to your Datadog dashboard.
|
||||
2. On the left-hand menu, click on **Monitors** > **New Monitor**.
|
||||
3. Choose the type of monitor (e.g., metric) and select the metric you want to
|
||||
track.
|
||||
4. Define the conditions (e.g., CPU > 80% for 5 minutes).
|
||||
5. Set up notification methods (e.g., email, Slack).
|
||||
6. Name the alert and click **Create Monitor** to activate it.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of alerts received on the slack channel/email created for that OR
|
||||
of the alerts created in your solution
|
||||
@@ -1,20 +0,0 @@
|
||||
# Log collection and monitoring
|
||||
|
||||
Being proactive provides you with more visibility and ensures system
|
||||
reliability.
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Logging and monitoring your infrastructure and network is crucial for
|
||||
identifying and responding to security incidents, system issues or unauthorized
|
||||
access in real-time.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
Log critical event and implement alerts to be notified if everything goes wrong.
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Configure logs and implement real-time monitoring](OPS.MON.001_log_and_implement_real_time_monitoring.md)
|
||||
- [Keep your logs](OPS.MON.002_keep_your_logs.md)
|
||||
- [Be automatically notified of issues](OPS.MON.003_automatically_notified_of_issues.md)
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
id: "PER.ACC.001"
|
||||
category: "personnel/access"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.8"]
|
||||
---
|
||||
|
||||
# Enable 2FA on critical services
|
||||
|
||||
## Purpose
|
||||
|
||||
In order to minimize the threat of someone getting access to something they
|
||||
should not, we follow the **secure principle:** nobody can easily get access to
|
||||
data/systems.
|
||||
|
||||
We need to ensure that if someone has access to your password, they still cannot
|
||||
log into your account. Multi-Factor Authentication (MFA) adds extra layers of
|
||||
security by requiring users to provide additional authentication factors beyond
|
||||
their passwords. The most standard solution is 2FA: your password + something
|
||||
else.
|
||||
|
||||
## Implementation
|
||||
|
||||
Enable 2FA across all your systems. If you don’t want to activate it everywhere,
|
||||
prioritize:
|
||||
|
||||
- System containing sensitive data
|
||||
- System related to your network, infrastructure or production.
|
||||
|
||||
At least, you need it for the following:
|
||||
|
||||
- Cloud provider (GCP, AWS etc.)
|
||||
- Code hosting (Github, Gitlab etc.)
|
||||
- Email/SSO (Google, Microsoft etc.)
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your 2FA settings in Cloud provider.
|
||||
- Screenshot of your 2FA settings in Code hosting.
|
||||
- Screenshot of your 2FA settings in Email/SSO.
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: "PER.ACC.002"
|
||||
category: "personnel/access"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.2", "CC6.3"]
|
||||
---
|
||||
|
||||
# Access Request Process
|
||||
|
||||
## Purpose
|
||||
|
||||
In order to minimize the threat of someone getting access to something they
|
||||
should not, we follow the continuous update principle: making sure the
|
||||
privileges are up to date. We need to setup a proper process to define how we
|
||||
grant and revoke access to different systems.
|
||||
|
||||
## Implementation
|
||||
|
||||
We will formalize your access granting and revocation policy later, for that, we
|
||||
need you to implement the fitting process for you.
|
||||
|
||||
1. Setup an easy process to update the access outside of onboarding and
|
||||
offboarding:
|
||||
1. Define who in your leadership team should be the person granting access.
|
||||
It usually would be someone from HR or IT
|
||||
2. Go to Slack and create an `access-request` channel
|
||||
3. Ensure any access request goes through this slack channel so you can
|
||||
provide screenshots of those requests.
|
||||
|
||||
> Pro tip: Setup an alias to @access-admin that pings the right person in charge
|
||||
> to reduce notification noise
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of the slack channel with some actions on it.
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
id: "PER.ACC.003"
|
||||
category: "personnel/access"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.8"]
|
||||
---
|
||||
|
||||
# Setup a password manager
|
||||
|
||||
## Purpose
|
||||
|
||||
In order to minimize the threat of someone getting access to something they
|
||||
should not, we want to ensure a few things:
|
||||
|
||||
1. The password used in your company are complex enough
|
||||
2. They are stored encrypted
|
||||
3. They are shared safely when needed (not openly, on slack or by text)
|
||||
4. They are not compromised
|
||||
|
||||
The easiest way to implement those is to use a password manager.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Choose your provider
|
||||
|
||||
There are a few options on the market regarding password manager. We will guide
|
||||
you through [1password](https://1password.com/) setup.
|
||||
|
||||
You can also use [Dashlane](https://www.dashlane.com/) or a free open source
|
||||
solution such as https://github.com/passbolt/passbolt_api.
|
||||
|
||||
### Confirm the policy you want
|
||||
|
||||
The main thing you need to decide on is the complexity of password you require.
|
||||
Below, you will find a suggestion of something you can implement in 1password.
|
||||
|
||||
<aside>
|
||||
🔒
|
||||
|
||||
Employees secret must meet the following requirements:
|
||||
|
||||
a. min 12 characters in length b. A mix of uppercase and lowercase characters c.
|
||||
At least one non-alphanumeric character d. At least one number
|
||||
|
||||
</aside>
|
||||
|
||||
> If you change from this suggestion, please edit the suggestion - this rule
|
||||
> will be added to a policy later.
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
id: "PER.ACC.004"
|
||||
category: "personnel/access"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.8", "CC7.2"]
|
||||
---
|
||||
|
||||
# Setup Role Based Access Control (RBAC)
|
||||
|
||||
## Purpose
|
||||
|
||||
In order to minimize the threat of someone getting access to something they
|
||||
should not, we follow the least privilege principle: access is limited to what's
|
||||
necessary for job duties. We need to define which function should have access to
|
||||
which tool in your company to serve as a reference when providing access to
|
||||
people (password manager vaults etc.).
|
||||
|
||||
## Implementation
|
||||
|
||||
Define who should have access to what in a role-based matrix in the template
|
||||
below:
|
||||
|
||||
1. Edit and add columns for the main tool categories you are using
|
||||
2. Edit and add lines for the different functions / teams in your organization
|
||||
3. Edit and add ticks `x` in the right box for access
|
||||
4. In the last line, make sure to fill the right admin team
|
||||
|
||||
| **Role** | **Email** | **Google Workspace** | **Expense Tool** | **CRM** | **App** | **Infrastructure** | **Version Control** | **Build System** | **Vuln Scanner** |
|
||||
| ------------- | --------- | -------------------- | ---------------- | ---------- | ------------ | ------------------ | ------------------- | ---------------- | ---------------- |
|
||||
| **Everyone** | x | x | x | | x | | | | |
|
||||
| **Engineers** | x | x | x | | x | x | x | x | x |
|
||||
| **Sales** | x | x | x | x | x | | | | |
|
||||
| | | | | | | | | | |
|
||||
| **Admin** | HR | HR | Finance | Sales lead | Product lead | Eng lead | Eng lead | Eng lead | Eng lead |
|
||||
|
||||
## Evidence
|
||||
|
||||
- Provide the link to the matrix you implemented on your side
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
id: "PER.ACC.005"
|
||||
category: "personnel/access"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.8", "CC7.2"]
|
||||
---
|
||||
|
||||
# Enforce SSO when possible
|
||||
|
||||
## Purpose
|
||||
|
||||
To minimize the risk of unauthorized access, it's important to centralize and
|
||||
secure authentication across your organization. Single Sign-On (SSO) enhances
|
||||
security by enabling better control over account access, enforcing consistent
|
||||
security policies (e.g., 2FA), and making it easier to revoke access when
|
||||
someone leaves the organization.
|
||||
|
||||
## Implementation
|
||||
|
||||
## Google Workspace
|
||||
|
||||
1. Log in to the [Google Admin Console](https://admin.google.com/) with an admin
|
||||
account.
|
||||
2. Go to **Apps** > **Web and Mobile Apps** > **Add App** > **Add Custom SAML
|
||||
App**.
|
||||
3. Name the app and upload a logo (optional).
|
||||
4. **Generate SSO details**:
|
||||
- Google provides the **SSO URL**, **Entity ID**, and **Certificate** for the
|
||||
app.
|
||||
5. **Configure the Third-Party App**:
|
||||
- In the app’s admin console, input the **SSO URL**, **Entity ID**, and
|
||||
upload the **Certificate**.
|
||||
6. Return to Google Admin Console and configure attribute mapping (e.g., email,
|
||||
first name).
|
||||
7. Test the connection, enable the app, and assign it to users or groups.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of SSO activation for Google Workplace + your cloud provider + code
|
||||
hosting tool
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: "PER.ACC.006"
|
||||
category: "personnel/access"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-14"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC3.3", "CC6.1", "CC6.2", "CC6.3", "CC6.5"]
|
||||
---
|
||||
|
||||
# Conduct an access reviews
|
||||
|
||||
## Purpose
|
||||
|
||||
A formal/explicit process to review employee access on a quarterly/yearly basis
|
||||
is a must have in terms of security hygiene.
|
||||
|
||||
## Implementation
|
||||
|
||||
Every 3 or 6 months, plan an “Access review session” with the relevant people to
|
||||
audit accesses on all systems (that is another good reason to enable SSO). You
|
||||
need to ensure everyone has the proper access for his/her job - an account
|
||||
inactive for the last 90 days can probably be disable. If you proceed to any
|
||||
change, document it in the minutes of the meeting - those minutes will be asked
|
||||
for subsequent SOC 2 audits.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot the recurring meeting invite OR the notes from the previous reviews
|
||||
@@ -1,29 +0,0 @@
|
||||
# Configure your system access
|
||||
|
||||
You can start by making sure you properly manage access to your company system
|
||||
and data.
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Someone having access to something he should not can have serious consequences
|
||||
such as a data leak or a service interruption. It is important to mitigate those
|
||||
risks you have identified previously.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
The main idea is to follow those principles:
|
||||
|
||||
1. **Least privilege:** everyone’s access is limited to what's necessary for job
|
||||
duties
|
||||
2. **Secure:** nobody can easily get access to the your employees
|
||||
passwords/access
|
||||
3. **Continuous update:** making sure the privileges are up to date and you use
|
||||
the latest best practices
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Enable MFA on critical services](PER.ACC.001_mfa_on_critical_services.md)
|
||||
- [Access Request Process](PER.ACC.002_access_request_process.md)
|
||||
- [Setup a password manager](PER.ACC.003_password_manager.md)
|
||||
- [Setup Role Based Access Control](PER.ACC.004_role_based_access_control.md)
|
||||
- [Enforce SSO when possible](PER.ACC.005_enforce_single_sign_on.md)
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
id: "PER.COM.001"
|
||||
category: "personnel/comms"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.8"]
|
||||
---
|
||||
|
||||
# Configure SPF for Email Authentication
|
||||
|
||||
## Purpose
|
||||
|
||||
SPF (Sender Policy Framework) prevents email spoofing by defining which mail
|
||||
servers are authorized to send emails on behalf of your domain. It helps
|
||||
receiving mail servers verify that incoming email from a domain comes from a
|
||||
host authorized by that domain's administrators.
|
||||
|
||||
## Implementation
|
||||
|
||||
1. Identify all legitimate email sources:
|
||||
- Your mail servers
|
||||
- Third-party services (e.g., Google Workspace)
|
||||
- Marketing platforms
|
||||
- Any other authorized email senders
|
||||
2. Create SPF record
|
||||
```
|
||||
v=spf1 include:_spf.google.com ~all
|
||||
```
|
||||
Where:
|
||||
- `v=spf1`: Version of SPF
|
||||
- `include:_spf.google.com`: Include Google's mail servers
|
||||
- `~all`: Soft fail for others (can be changed to -all for hard fail)
|
||||
3. Add record to DNS:
|
||||
- Create TXT record at domain root
|
||||
- Publish SPF record in DNS
|
||||
- Wait for DNS propagation
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of published SPF DNS record
|
||||
- Email header samples showing SPF pass
|
||||
- Documentation of authorized senders
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: "PER.COM.002"
|
||||
category: "personnel/comms"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.8"]
|
||||
---
|
||||
|
||||
# Configure DKIM for Email Authentication
|
||||
|
||||
## Purpose
|
||||
|
||||
DKIM (DomainKeys Identified Mail) helps prevent email spoofing by adding a
|
||||
digital signature to outgoing messages, allowing receiving mail systems to
|
||||
verify that emails genuinely came from your domain and weren't modified in
|
||||
transit.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Workspace
|
||||
|
||||
1. Go to [Google Admin console](admin.google.com).
|
||||
2. Navigate to Apps > Google Workspace > Gmail > Authenticate Email.
|
||||
3. Select your domain and click "Generate new record".
|
||||
4. Copy the DKIM TXT record provided by Google.
|
||||
5. Add this TXT record to your DNS.
|
||||
6. After DNS propagation, return to Admin console and click "Start
|
||||
authentication".
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of published DKIM DNS record
|
||||
- Sample email headers showing DKIM pass
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
id: "PER.COM.003"
|
||||
category: "personnel/comms"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
related:
|
||||
- id: "PER.COM.001"
|
||||
required: true
|
||||
- id: "PER.COM.002"
|
||||
required: true
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.8"]
|
||||
---
|
||||
|
||||
# Configure DMARC for Email Authentication
|
||||
|
||||
## Purpose
|
||||
|
||||
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a
|
||||
policy framework that builds upon SPF and DKIM. It tells receiving servers what
|
||||
to do when emails fail SPF or DKIM checks, and provides reporting on
|
||||
authentication results.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Workspace
|
||||
|
||||
1. Create a Google Group named `dmarc-report@example.com` which is assecible
|
||||
from external users.
|
||||
2. Create DMARC record in monitoring mode:
|
||||
```
|
||||
Record: _dmarc.example.com
|
||||
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
|
||||
```
|
||||
Where:
|
||||
- `v=DMARC1`: Protocol version
|
||||
- `p=none`: Policy for failed checks
|
||||
- `rua=`: Address for aggregate reports
|
||||
3. Check the reports sent to the rua email address to ensure proper
|
||||
authentication of emails.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of DMARC DNS record
|
||||
- Sample aggregate reports
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: "PER.COM.004"
|
||||
category: "personnel/comms"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-07"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.8", "CC7.2"]
|
||||
---
|
||||
|
||||
# Configure Email Security Filters
|
||||
|
||||
## Purpose
|
||||
|
||||
Implement email filtering and warning systems to reduce phishing risks and
|
||||
protect employees from malicious emails. This reduces mental load on employees
|
||||
and decreases company risk exposure through email-based attacks.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Workspace
|
||||
|
||||
1. Access [Google Admin Console](https://admin.google.com).
|
||||
2. Navigate to Settings
|
||||
```
|
||||
Apps → Google Workspace → Gmail
|
||||
```
|
||||
3. Configure "Safety" settings:
|
||||
- Attachments Protection
|
||||
- Scan for anomalous attachment types
|
||||
- Block attachments with scripts
|
||||
- Block encrypted attachments from untrusted senders
|
||||
- Links and External Images:
|
||||
- Enable scanning of linked images
|
||||
- Identify shortened URLs
|
||||
- Display warning prompts for untrusted domains
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of email security settings in Google Admin Console.
|
||||
@@ -1,24 +0,0 @@
|
||||
# Secure your emails
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Do you know what is the most common attack vector among cyber threats?
|
||||
**Emails**
|
||||
|
||||
And by far! It is also where your employees are talking with externals. By
|
||||
configuring a few things in your settings, you are preventing many threats from
|
||||
reaching your employees and you are protecting your data and systems.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
To do so, we divided the work in two steps:
|
||||
|
||||
- You secure the access to your offices.
|
||||
- You secure the internet connexion of remote employees
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Configure SPF for Email Authentication](PER.COM.001.sender_policy_framework.md)
|
||||
- [Configure DKIM for Email Authentication](PER.COM.002.dkim_implementation.md)
|
||||
- [Configure DMARC for Email Authentication](PER.COM.003.domain_based_message_authentication.md)
|
||||
- [Configure Email Security Filters](PER.COM.004.email_filtering_and_warning_system.md)
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.001"
|
||||
category: "personnel/lifecycle"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-10"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC5.3"]
|
||||
---
|
||||
|
||||
# Integrate security checklist in your onboarding process
|
||||
|
||||
## Purpose
|
||||
|
||||
It is the perfect timing to ensure that every employees has:
|
||||
|
||||
- accepted and signed all documents
|
||||
- the access needed to perform his/her tasks
|
||||
- started his/her security training
|
||||
|
||||
## Implementation
|
||||
|
||||
In theory, you already have an onboarding plan for your new employees (if not,
|
||||
[Onboarding for new joiner](templates/onboarding-for-new-joiner.md)) and a to-do
|
||||
for your admin running the onboarding (if not,
|
||||
[Onboarding admin checklist](templates/onboarding-admin-checklist.md)).
|
||||
|
||||
On your employee to-do, be sure to include:
|
||||
|
||||
- Set-up of 2FA
|
||||
- Set-up of password manager
|
||||
- Read & acknowledge all policies (it can be part of the contract)
|
||||
- Complete the security training
|
||||
|
||||
On your admin to-do, be sure to include:
|
||||
|
||||
- contract is signed before granting access
|
||||
- apply “least privilege principle” for access (the matrix you defined)
|
||||
- Force the set-up of 2FA and password manager
|
||||
- Initiate the security training
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshots of a completed onboarding checklists.
|
||||
- Screenshots of a completed admin checklist for new joiner.
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.002"
|
||||
category: "personnel/lifecycle"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-10"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC5.3", "CC6.2", "CC6.5"]
|
||||
---
|
||||
|
||||
# Properly off-board your employees
|
||||
|
||||
## Purpose
|
||||
|
||||
Yes, people will leave your company (either by your decision or theirs). And you
|
||||
want to be prepare! If an early employee leaves and you forgot to change the
|
||||
ownership on his/her document, you might lose the documents.
|
||||
|
||||
Also, you want to be sure people can’t access the company data or systems once
|
||||
they left!
|
||||
|
||||
## Implementation
|
||||
|
||||
1. Integrate the following elements in your offboarding checklist:
|
||||
|
||||
- Return of company assets (laptop etc.)
|
||||
- Transfer ownership of documents
|
||||
- Revoke all access to systems
|
||||
|
||||
(if you don't have an offboarding checklist →
|
||||
[Offboarding admin checklist](templates/offboarding-admin-checklist.md))
|
||||
|
||||
2. Upload a screenshot of your checklist that contains those bullet points below
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of a completed admin checklist for offboarding
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.003"
|
||||
category: "personnel/lifecycle"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-10"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC5.3"]
|
||||
---
|
||||
|
||||
# Know your recruits
|
||||
|
||||
## Purpose
|
||||
|
||||
When recruiting someone, you want to be sure of who you are hiring: by
|
||||
performing reference checks (it can also be background checks), you add an
|
||||
additional layer of certainty on the candidate by looking for potential red
|
||||
flags in the candidate’s past (history of unethical behavior, harassment, fraud,
|
||||
etc..).
|
||||
|
||||
## Implementation
|
||||
|
||||
Recruitment is key, especially early stage, so you are probably already doing it
|
||||
right, it is only about documenting it.
|
||||
|
||||
⇒ Define the recruitment process you follow when bringing on a new member (if
|
||||
you don’t have one formalized, here is a structure:
|
||||
[Recruitment process](templates/recruitment-process.md)).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Reference check template
|
||||
- Completed check records (redacted)
|
||||
- Process documentation
|
||||
- Verification records
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.004"
|
||||
category: "personnel/lifecycle"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.2"]
|
||||
---
|
||||
|
||||
# Implement confidential whistleblower process
|
||||
|
||||
## Purpose
|
||||
|
||||
It encourages and enables employees to raise serious concerns (violations of
|
||||
your code of ethics or law or regulations) in order for them to be addressed and
|
||||
corrected while being protected from any retaliation.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Workspace
|
||||
|
||||
1. Set up an anonymous
|
||||
[Google form](https://html.form.guide/google-forms/make-google-form-survey-anonymous/)
|
||||
|
||||
2. Communicate the link to your employees by explaining how and why they should
|
||||
use it.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of its communication to your employees.
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.005"
|
||||
category: "personnel/lifecycle"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "30m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.3", "CC1.4", "CC1.5", "CC4.2", "CC5.3"]
|
||||
---
|
||||
|
||||
# Run performance reviews
|
||||
|
||||
## Purpose
|
||||
|
||||
Makes sure your team has the skills and focus needed to protect what matters
|
||||
most in your business. They help spot training gaps, reinforce accountability
|
||||
and ensure everyone is aligned with your operational goals - security being one
|
||||
of them. It's all about building a culture that proactively minimizes risks
|
||||
while continuously improving.
|
||||
|
||||
## Implementation
|
||||
|
||||
Create a simple employee
|
||||
[performance evaluation process](templates/performance-review-process.md). It
|
||||
must rely on clear metrics and expectations and must be run at least once a
|
||||
year.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your performance review process.
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.006"
|
||||
category: "personnel/lifecycle"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.2", "CC1.3", "CC1.5", "CC2.2", "CC4.3"]
|
||||
---
|
||||
|
||||
# Specify security responsabilities
|
||||
|
||||
## Purpose
|
||||
|
||||
Having clear ownership improve accountability, it helps employees figure out
|
||||
what is legit and what is not.
|
||||
|
||||
## Implementation
|
||||
|
||||
Here is the kind of document expected - it has to be done for every role with a
|
||||
potential impact on security:
|
||||
|
||||
| Role | Responsibilities |
|
||||
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CTO | • Oversees the overall security architecture and ensures that the technology stack aligns with security best practices<br>• Implements and enforces security policies across all engineering teams<br>• Ensures the security of the company's API by leading security audits, vulnerability assessments, and patch management<br>• Coordinates the implementation of access controls, encryption protocols, and incident response procedures |
|
||||
| Engineers | • Maintain the confidentiality, integrity, and availability of the information systems and processes for which they are responsible in compliance with COMPANY policies on information security and privacy<br>• Responsible for the development and deployment of secure code in accordance with COMPANY standards, policies, and procedures<br>• Leader of the Incident Response team, responsible for incident response, documentation, and lessons learned process<br>• Execution of customer data retention and deletion processes in accordance with company policy and customer requirements |
|
||||
| Head of People | • Ensures that employee onboarding and offboarding processes adhere to security protocols, including access control to company systems<br>• Collaborates with the IT team to manage employee access to sensitive information and ensure role-based access control<br>• Develops and maintains security-related HR policies, such as security awareness training, background checks, and confidentiality agreements |
|
||||
| Office and events manager | • Manages the issuance, tracking, and return of company equipment (laptops, phones) with security policies in place<br>• Manages access for new joiners and leavers for all general software and platforms<br>• Collaborates with CTO to ensure proper deactivation of devices when employees leave or change roles<br>• Tracks and audits equipment inventory to prevent unauthorized access to company systems or data |
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your page where those responsibilities are shared.
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
id: "PER.LIF.007"
|
||||
category: "operations/training"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "30m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC1.4", "CC2.2"]
|
||||
---
|
||||
|
||||
# Train your employees on security
|
||||
|
||||
## Purpose
|
||||
|
||||
Your employees are the main target of cyber threats (especially phishing and
|
||||
social engineering), and education is one of the best way to reduce risk.
|
||||
Awareness of your employees will improve your company security.
|
||||
|
||||
## Implementation
|
||||
|
||||
There are a few options on the market, we will guide you through
|
||||
[Riot](https://tryriot.com/fr/) setup.
|
||||
|
||||
### Riot
|
||||
|
||||
1. **Sign up:** Go to the Riot website ([tryriot.com](https://tryriot.com/)) and
|
||||
either start a free trial or book a demo to get your account set up.
|
||||
|
||||
2. **Install on slack**: If you’re using Slack, you can install Riot directly
|
||||
from the [Slack Marketplace](https://slack.com/apps/A01GSNM2H6V-riot).
|
||||
|
||||
3. **Set up phishing simulations and security training**: After installation,
|
||||
you can begin running phishing simulations to test your team’s readiness
|
||||
against attacks. You can also automate ongoing security training programs
|
||||
that run throughout the year to keep employees aware of best practices.
|
||||
|
||||
4. **Monitor and Track Progress**: Once the setup is complete, you can track
|
||||
your team's engagement and security posture through Riot’s dashboard, which
|
||||
allows you to monitor progress and export compliance reports as needed.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of your program in Riot with completion.
|
||||
@@ -1,27 +0,0 @@
|
||||
# Set up your employees for success
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Without the proper security measures in place, employees can inadvertently
|
||||
expose your company to breaches and vulnerabilities. Providing secure access and
|
||||
clear guidelines on handling sensitive information is crucial to protect your
|
||||
organization from potential threats.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
You will focus on two things:
|
||||
|
||||
- **Processes:** whether it is to recruit, onboard or off-board, things are
|
||||
prepared and you are sure not to forgot anything.
|
||||
- **Enabling**: empower your employees to take the best decision possible to
|
||||
maintain your security posture
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Integrate security checklist in your onboarding process](PER.LIF.001_onboarding.md)
|
||||
- [Properly off-board your employees](PER.LIF.002_offboarding.md)
|
||||
- [Know your recruits](PER.LIF.003_pre-employment-screening-process.md)
|
||||
- [Implement confidential whistleblower process](PER.LIF.004_confidential_whistleblower_process.md)
|
||||
- [Run performance reviews](PER.LIF.005_performance_reviews.md)
|
||||
- [Specify security responsabilities](PER.LIF.006_security_roles_and_responsibilities.md)
|
||||
- [Train your employees on security](PER.LIF.007_security_awareness_training.md)
|
||||
@@ -1,9 +0,0 @@
|
||||
- [ ] 💰 Make sure we closed the contract on Payfit
|
||||
- [ ] 💻 Get back and Reset laptop
|
||||
- [ ] 🔁 Transfert the docs ownership in Google
|
||||
- [ ] 📧 Suppress the Google account
|
||||
- [ ] 🖋 Disconnect manually Notion
|
||||
- [ ] 🛠 Disconnect Slack
|
||||
- [ ] 🔐 Delete from 1 Password (not suspended, billed)
|
||||
- [ ] 🗄 Disconnect manually Github
|
||||
- [ ] 🧐 Double check with the manager for important tool
|
||||
@@ -1,48 +0,0 @@
|
||||
# Onboarding for new joiner
|
||||
|
||||
## 💜 Welcome! We're so glad to have you 😃
|
||||
|
||||
This first week will be about discovery: discovering the team, the way we work,
|
||||
and what we do.
|
||||
|
||||
> 💡Here is a checklist to help you settle down. Feel free to navigate notion &
|
||||
> slack, or to ask questions to anyone. Our role is to make your first days as
|
||||
> easy as possible.
|
||||
|
||||
## 🆕 Setting you up
|
||||
|
||||
- [ ] Log in to your Google Account (you must have received an email) and set up
|
||||
a new password
|
||||
- [ ] Download Google Authenticator app for 2-factor auth
|
||||
- [ ] Set-up the 2-factor auth: it is mandatory
|
||||
- [ ] Log in to 1password
|
||||
- [ ] Log in to Slack with your google account
|
||||
- [ ] Log in to Notion with your google account
|
||||
- [ ] Complete Albert security training on Slack
|
||||
|
||||
## 👷 Your Onboarding Project
|
||||
|
||||
> You’re now ready to present yourself to the team!
|
||||
|
||||
- [ ] Share a few things about you in #all_people in Slack: who are you, where
|
||||
do you come from, what was your journey until now, whatever fun fact you’d
|
||||
like to share with us, … you can draw some inspiration by looking at the
|
||||
previous ones 🙂
|
||||
- [ ] Read our Code of Conduct
|
||||
- [ ] Put a picture of yourself on Slack
|
||||
|
||||
## 👥 Users
|
||||
|
||||
If you want to know more about our users, go check XXXX
|
||||
|
||||
## 🚀 To go further
|
||||
|
||||
**Meet the team 🤝**
|
||||
|
||||
- [ ] Join the #coffee-chats channel for random coffee breaks
|
||||
- [ ] Schedule a chat with every member of your team to get to know them 💜
|
||||
|
||||
**Understand what we do ❓**
|
||||
|
||||
- [ ] Take some time to navigate on our Notion pages 🧭
|
||||
- [ ] Get your access to our product to play with it - follow the guide XXXX
|
||||
@@ -1,52 +0,0 @@
|
||||
### **Objective**:
|
||||
|
||||
Provide clear and constructive feedback, encourage growth and development and
|
||||
align individual goals with company objectives.
|
||||
|
||||
### **Review schedule**
|
||||
|
||||
- **Frequency**: Conduct performance reviews **semi-annually** (every 6 months).
|
||||
- **Duration**: Each review meeting should last between **30 minutes to 1
|
||||
hour**.
|
||||
- **Preparation time**: Allow managers and employees at least **one week** to
|
||||
prepare for the review.
|
||||
|
||||
### **Components**
|
||||
|
||||
- **Self-assessment:** Employees complete a self-assessment form highlighting
|
||||
their achievements, challenges and areas for improvement.
|
||||
- **Manager feedback:** Managers evaluate employee performance based on their
|
||||
responsibilities and taks, their growth, their collaboration and their
|
||||
alignment with the company value.
|
||||
- **Goal setting:** Employees and managers review progress on previously set
|
||||
goals and set 2-3 clear, measurable goals for the next period.
|
||||
|
||||
### **Process**
|
||||
|
||||
1. **Preparation**:
|
||||
|
||||
Distribute a **performance review template** (self-assessment + manager
|
||||
evaluation) one week before the review: employee and manager complete their
|
||||
sections.
|
||||
|
||||
[Performance review template](https://www.notion.so/Performance-review-template-13f1cc0bd5bc801f8b58fbc8679b4b02?pvs=21)
|
||||
|
||||
2. **Review meeting (1o1)**:
|
||||
|
||||
**Start Positive**: Begin with recognition of the employee’s contributions
|
||||
and strengths.
|
||||
|
||||
**Discuss Feedback**: Review the self-assessment and manager’s evaluation -
|
||||
for each, examples of successes or areas for improvement are expected.
|
||||
|
||||
**Collaborative Goal Setting**: Discuss growth opportunities and align new
|
||||
goals. Are training or support needed?
|
||||
|
||||
3. **Commit**:
|
||||
|
||||
Commit on the outcome of the discussion by filling in the Performance Review
|
||||
Template
|
||||
|
||||
### **Documentation**
|
||||
|
||||
Maintain a confidential records of the performance reviews.
|
||||
@@ -1,10 +0,0 @@
|
||||
1. Initial screen (with talent partner) - 30min
|
||||
2. Technical interview (with hiring manager) - 30min/1h
|
||||
3. Home assignment - 3/4h
|
||||
4. Assignment review (with hiring manager and one team member) - 1h
|
||||
5. Check-in call (with talent partner) -15min
|
||||
6. Final interviews: culture fit and deep dive (5 team members and a founder) -
|
||||
2x30min + 1h
|
||||
7. Reference checks - variable, based on position
|
||||
8. Offer call (with talent partner) - 30min
|
||||
9. Hire
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: "PHY.FAC.001"
|
||||
category: "physical/facilities"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "15m"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.4"]
|
||||
---
|
||||
|
||||
# Cloud datacenter physical security
|
||||
|
||||
## Purpose
|
||||
|
||||
You know how critical a data center is. You don’t want unauthorized people to
|
||||
access it.
|
||||
|
||||
## Implementation
|
||||
|
||||
### Google Cloud Platform
|
||||
|
||||
Nothing, it is already done
|
||||
|
||||
> Evidence to provide: https://cloud.google.com/trust-center?hl=en
|
||||
|
||||
## Evidence
|
||||
|
||||
- Security document of your datacenter.
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
id: "PHY.FAC.002"
|
||||
category: "physical/facilities"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.4"]
|
||||
---
|
||||
|
||||
# Implement Physical Access Control
|
||||
|
||||
## Purpose
|
||||
|
||||
Even if you do most of your business online, you still have offices, computers
|
||||
or even printed document: you need to make sure those assets are physically
|
||||
secured (we will focus on the digital access later).
|
||||
|
||||
## Implementation
|
||||
|
||||
If you are working from a co-working space or subleasing offices, you don’t have
|
||||
much do to. Provide a link to their access policy and the dashboard they
|
||||
probably provide to manage the list of authorized personnel.
|
||||
|
||||
If you have your own office space, you need to provide:
|
||||
|
||||
- The security system/measure you implemented (badge, pin, etc…) - select the
|
||||
right element in the evidence section.
|
||||
- The dashboard where you track authorized personnel.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Access policy document from your co-working provider.
|
||||
- Screenshot of the dashboard with a list of authorized personnel.
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: "PHY.FAC.003"
|
||||
category: "physical/facilities"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "15m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.4"]
|
||||
---
|
||||
|
||||
# Implement Visitor Access Policies
|
||||
|
||||
## Purpose
|
||||
|
||||
Even if you do most of your business online, you still have offices, computers
|
||||
or even printed document: you need to make sure those assets are physically
|
||||
secured (we will focus on the digital access later) regarding visitors.
|
||||
|
||||
## Implementation
|
||||
|
||||
Nothing, it is done! The element below will be added to your access policy.
|
||||
|
||||
## Evidence
|
||||
|
||||
Visitors must be accompanied by an employee at all times when they are on
|
||||
premises.
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
id: "PHY.FAC.004"
|
||||
category: "physical/facilities"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-13"
|
||||
estimate-time: "4h"
|
||||
necessity: "optional"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC6.1", "CC6.6", "CC6.7"]
|
||||
---
|
||||
|
||||
# Use VPNs to Secure Access for Remote Devices
|
||||
|
||||
## Purpose
|
||||
|
||||
In short, implementing a VPN will encrypt your data and ensure a safe
|
||||
transmission between your employees devices and your internal network (even when
|
||||
using untrusted networks like a public wifi) ⇒ it offers a layer of security for
|
||||
your data.
|
||||
|
||||
## Implementation
|
||||
|
||||
> If you have doubt whether you should do it or not, ping us on Discord. <br/>
|
||||
> If everything is on Google Suite/Notion/Slack with MFA and you don’t have your
|
||||
> own network => no needed.
|
||||
|
||||
If you think you need one, you should consider deploying one and make it
|
||||
mandatory when working remote => You can follow the
|
||||
[Wireguard installation guide there](https://www.wireguard.com/install/).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Screenshot of VPN settings page (to show active use) or log of VPN connection
|
||||
from employees device.
|
||||
@@ -1,26 +0,0 @@
|
||||
# Secure your offices and internet access
|
||||
|
||||
Start by assessing whether your team works from a physical office or operates
|
||||
remotely, as this will guide your approach to securing the workspace.
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Unauthorized access to your office or network can lead to serious consequences
|
||||
such as data theft, or other serious issues. Protecting both physical and
|
||||
digital environments is essential to mitigate those risks.
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
We break this into two main areas of focus:
|
||||
|
||||
1. **Office Security:** Ensure that the access to your office is secured against
|
||||
unauthorized entry.
|
||||
2. **Internet Security:** Ensure that members of your teams or contractors that
|
||||
work remotely have a secure access to internet.
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Cloud datacenter physical security](PHY.FAC.001_cloud_datacenter_physical_security.md)
|
||||
- [Implement Physical Access Control](PHY.FAC.002_physical_access_control.md)
|
||||
- [Implement Visitor Access Policies](PHY.FAC.003_visitor_access_policy.md)
|
||||
- [Use VPNs to Secure Access for Remote Devices](PHY.FAC.004_virtual_private_network.md)
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
id: "PHY-HW-001"
|
||||
category: "physical/hardware"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.1", "CC6.1", "CC6.6", "CC6.7", "CC6.8", "CC7.1", "CC7.2"]
|
||||
---
|
||||
|
||||
# Configure Anti-malware Protection on Employee Devices
|
||||
|
||||
## Purpose
|
||||
|
||||
Ensure all employee devices have active malware protection to prevent
|
||||
unauthorized and malicious software installation, protecting company data and
|
||||
systems from malware-based threats.
|
||||
|
||||
## Implementation
|
||||
|
||||
### MacOS
|
||||
|
||||
1. Verify Gatekeeper is enabled (default)
|
||||
- System Settings → Privacy & Security
|
||||
- Ensure App Store and identified developers option
|
||||
|
||||
### Windows
|
||||
|
||||
1. Enable Windows Defender
|
||||
- Settings → Update & Security → Windows Security
|
||||
- Real-time protection enabled
|
||||
|
||||
## Evidence
|
||||
|
||||
**Option 1**: MDM solution
|
||||
|
||||
- Screenshot of fleet malware protection status
|
||||
- Configuration compliance reports
|
||||
|
||||
**Option 2**: Manual Documentation
|
||||
|
||||
- Device inventory with protection status
|
||||
- Configuration screenshots
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: "PHY.HW.002"
|
||||
category: "physical/hardware"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.1", "CC6.1", "CC6.6", "CC6.7", "CC6.8", "CC7.1", "CC7.2"]
|
||||
---
|
||||
|
||||
# Configure Automatic Screen Lock on Employee Devices
|
||||
|
||||
## Purpose
|
||||
|
||||
Implement automatic screen lock on all employee devices to prevent unauthorized
|
||||
access when devices are unattended, protecting against physical access to
|
||||
company data and resources.
|
||||
|
||||
## Implementation
|
||||
|
||||
### All Devices
|
||||
|
||||
1. Configure automatic screen lock:
|
||||
- Maximum 5-minute timeout
|
||||
- Require password/biometrics to unlock
|
||||
- Disable bypass options
|
||||
|
||||
### MacOS
|
||||
|
||||
1. Apple menu → System Settings → Lock Screen
|
||||
2. Enable "Require password after screen saver begins"
|
||||
|
||||
### Windows
|
||||
|
||||
1. Settings → Personalization → Lock screen
|
||||
2. Enable "Require sign-in when PC wakes"
|
||||
|
||||
## Evidence
|
||||
|
||||
**Option 1**: MDM Solution
|
||||
|
||||
- Screen lock policy compliance report
|
||||
- Configuration status dashboard
|
||||
|
||||
**Option 2**: Manual Documentation
|
||||
|
||||
- Screenshots of screen lock settings
|
||||
- Device compliance checklist
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
id: "PHY.HW.003"
|
||||
category: "physical/hardware"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-08"
|
||||
estimate-time: "30m"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.1", "CC6.1", "CC6.6", "CC6.7", "CC6.8", "CC7.1", "CC7.2"]
|
||||
---
|
||||
|
||||
# Configure Disk Encryption and Firewall on Employee Devices
|
||||
|
||||
## Purpose
|
||||
|
||||
Ensure all employee devices have disk encryption and firewall protection enabled
|
||||
to secure data at rest and protect network communications from unauthorized
|
||||
access.
|
||||
|
||||
## Implementation
|
||||
|
||||
### MacOS
|
||||
|
||||
1. Enable FileVault
|
||||
- System Settings → Privacy & Security
|
||||
|
||||
### Windows
|
||||
|
||||
1. Enable BitLocker
|
||||
- Control Panel → System and Security
|
||||
|
||||
## Evidence
|
||||
|
||||
**Option 1**: MDM Solution
|
||||
|
||||
- Encryption status report
|
||||
- Device inventory status
|
||||
|
||||
**Option 2**: Manual Documentation
|
||||
|
||||
- Screenshots of encryption status
|
||||
- Device inventory with status
|
||||
@@ -1,25 +0,0 @@
|
||||
# Manage your computers
|
||||
|
||||
## Why does it matter?
|
||||
|
||||
Your company devices have the potential to store or process data ⇒ If someone
|
||||
lose his laptop or it gets compromised, it can expose you to a data leak (and a
|
||||
few other things)
|
||||
|
||||
## How can I proceed?
|
||||
|
||||
You have to make sure that every device is properly set-up. To monitor things,
|
||||
the easiest way is to leverage a Mobile Device Management software (MDM), but if
|
||||
you are early in your development, proper guidelines are enough. On each
|
||||
machine, you need:
|
||||
|
||||
- Screenlock is enabled
|
||||
- Firewall is active
|
||||
- Anti-malware detection is active
|
||||
- Data is encrypted
|
||||
|
||||
## Mitigations
|
||||
|
||||
- [Configure Anti-malware Protection on Employee Devices](PHY.HW.001_endpoint_antimalware.md)
|
||||
- [Configure Automatic Screen Lock on Employee Devices](PHY.HW.002_device_screen_lock.md)
|
||||
- [Configure Disk Encryption and Firewall on Employee Devices](PHY.HW.003_device_encryption.md)
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: "TRA.001"
|
||||
category: "transparency"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-15"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.3"]
|
||||
---
|
||||
|
||||
# Have a security page
|
||||
|
||||
## Purpose
|
||||
|
||||
Having SOC-2 for yourself is useless, you want to leverage it as much as
|
||||
possible.
|
||||
|
||||
## Implementation
|
||||
|
||||
Something simple!
|
||||
|
||||
|
||||
|
||||
People need to know how to contact you if there is an incident or want access to
|
||||
your trust center.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Link to your security page
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: "TRA.002"
|
||||
category: "transparency"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-15"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.3"]
|
||||
---
|
||||
|
||||
# Clearly explain your services
|
||||
|
||||
## Purpose
|
||||
|
||||
Here, we are not enhancing security, we are helping the auditor be more
|
||||
efficient. As part of the audit, he/she will need to understand clear boundaries
|
||||
for the audit, identify the relevant risk and then check how you mitigate them.
|
||||
|
||||
A proper service description is key for your customers, but it also help the
|
||||
auditor understands what your customers are expecting from you.
|
||||
|
||||
## Implementation
|
||||
|
||||
Nothing, everything should already be on your website for customers to see.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Website link
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
id: "TRA.002"
|
||||
category: "transparency"
|
||||
revision-version: 1
|
||||
revision-date: "2024-01-15"
|
||||
estimate-time: "1h"
|
||||
necessity: "mandatory"
|
||||
frameworks:
|
||||
- name: "soc2"
|
||||
sections: ["CC2.3"]
|
||||
---
|
||||
|
||||
# External support available
|
||||
|
||||
## Purpose
|
||||
|
||||
External support is not required for SOC 2, but it enhances transparency by
|
||||
showcasing your security practices, policies, and compliance efforts, building
|
||||
trust with customers and stakeholders. - Ultimately, this is what SOC 2 is
|
||||
about: reassuring your prospect and customer on how you work.
|
||||
|
||||
## Implementation
|
||||
|
||||
Create and maintain a complete list of support resources (eg. user guides,
|
||||
technical documentation) for all your services.
|
||||
|
||||
Ensure easy access to those resources and keep them up to date.
|
||||
|
||||
## Evidence
|
||||
|
||||
- If not publicly available, drop a screenshot from your knowledge base showing
|
||||
everything you cover (especially security)
|
||||
- Link to your public documentation
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 461 KiB |
Reference in New Issue
Block a user