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