Configuration Management Policy¶
Introduction¶
Soon runs its service entirely in the cloud (AWS eu-west-1, plus SaaS tools such as GitHub, Netlify, Stripe, Intercom, Sentry and PostHog) and issues laptops to a fully remote team. These components — cloud infrastructure, SaaS services and end-user devices — are all potentially vulnerable to attack. In order to lessen the risk of these components becoming compromised, it is important that we identify the most appropriate ways of configuring them and then ensure that these methods are used consistently.
This policy describes the main principles on which such standard configurations must be based and sets out the rules for their use.
This control applies to all systems, people and processes that constitute the organization's information systems, including employees, suppliers and other third parties who have access to Soon's systems.
The following policies and procedures are relevant to this document:
- Device Management Policy
- Cloud & Infrastructure Security Policy
- Cloud Services Policy
- Secure Development Policy
Configuration management policy¶
New components that make up Soon's software, services and networks must have their required security settings defined and correctly configured prior to their implementation within our environment.
Configurations of existing components must be reviewed periodically to ensure they meet the requirements of this policy.
Such components will include, but are not limited to:
- Endpoint devices, primarily company laptops
- Cloud infrastructure in AWS (eu-west-1), such as compute, networking, storage and databases
- SaaS services used to build and run the product (e.g. GitHub, Netlify, Stripe, Intercom, Sentry, PostHog)
Where possible, standard templates will be used to document the required configuration of components. These templates will be subject to change and version control.
The configurations defined will take appropriate account of available sources of information about securing the relevant components, such as vendor templates, guidance from cyber security authorities and best practice organizations, system hardening guides (e.g. CIS benchmarks, AWS Well- Architected security guidance) and our own information security policies.
Details of configuration standards will be protected as sensitive information which would be of use to an attacker.
Configuration standards must be reviewed on a regular basis and kept up to date with changes in the components themselves (such as new software versions) and the threats and vulnerabilities they face.
The correct configuration of components will be monitored and instances where existing settings deviate from the established standard will be investigated and, if necessary, corrected.
Where feasible, automated methods such as Infrastructure as Code (IaC) will be used to create components with the correct configuration, and changes will go through version control and peer review in GitHub. TODO(owner): confirm which IaC tooling is in use for AWS (e.g. Terraform, CloudFormation, CDK) and how much of the infrastructure it covers. Automated audit tools (e.g. AWS Config) may also be used to check configurations regularly and report on and correct those found to be noncompliant. TODO(owner): confirm whether AWS Config or a similar drift-detection tool is enabled.
Change log¶
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | 2023-12-11 | First draft document | |
| 0.2 | 2026-07-18 | Andrea Cardinali | Cleaned up and made Soon-specific (ISMS overhaul) |