Configuration and hardening: who owns it on each service model
The settings a service runs with and the baseline they are held to. Misconfiguration of a service you administer is yours on every model.
The split by service model
| Service model | Owner | Why, and the clause |
|---|---|---|
| Infrastructure as a service | yours | The image, the services enabled and every setting from the guest up are yours to harden and hold to a baseline. ISO/IEC 27017 CLD.9.5.2 |
| Platform as a service | shared | The provider hardens the platform it runs; every setting you choose in your tenancy, and a public or open default you leave on, is yours. ISO/IEC 27017 CLD.12.1.5 |
| Software as a service | shared | The provider hardens the platform it runs; every setting you choose in your tenancy, and a public or open default you leave on, is yours. ISO/IEC 27017 CLD.12.1.5 |
| Serverless functions and event services | shared | The provider hardens the platform it runs; every setting you choose in your tenancy, and a public or open default you leave on, is yours. ISO/IEC 27017 CLD.12.1.5 |
| Hosted AI models and AI platforms | shared | The provider hardens the platform it runs; every setting you choose in your tenancy, and a public or open default you leave on, is yours. ISO/IEC 27017 CLD.12.1.5 |
The clauses each framework attaches
6 quoted| Framework | Clause |
|---|---|
| Cloud Controls Matrix v4.0.1 | CCM-IVS-04 OS Hardening and Base Controls |
| ISO/IEC 27017:2015 | ISO/IEC 27017 CLD.9.5.2 Virtual machine hardening ยท ISO/IEC 27017 CLD.12.1.5 Administrator's operational security |
| SOC 2 Trust Services Criteria | SOC 2 CC8.1 Change management processes are in place |
| CMMC 2.0 | CMMC CM.L2-3.4.2 Security Configuration Enforcement |
| C5 cloud criteria catalogue | C5-PSS-11 Images for Virtual Machines and Containers |
CCM-IVS-04 OS Hardening and Base ControlsHarden host and guest operating systems, hypervisors and the infrastructure control plane to a documented security baseline enforced by technical controls.
- The hardening baselines per platform and the standard they derive from
- Compliance scan results against the baselines
- Technical enforcement such as configuration management or policy as code
- Exception records for deviations
- Baselines documented but compliance never measured
- Control plane excluded, with only guest operating systems hardened
- Deviations found repeatedly and never remediated or accepted
ISO/IEC 27017 CLD.9.5.2 Virtual machine hardeningVirtual machines in a cloud computing environment are to be hardened to meet business needs. Whichever party configures a virtual machine should apply hardening: only needed ports, protocols and services enabled, unnecessary components removed, and technical controls such as anti-malware and logging appropriate to the workload; the customer hardens the machines it controls and the provider those it operates, including the images it offers to customers.
- Hardening standard for cloud virtual machines
- Configuration evidence or scan results for a sample of machines
- Provider statement on hardening of provided images
- Provider default images deployed unchanged with all services enabled
- Customer hardening standard written for physical servers and never applied to cloud images
ISO/IEC 27017 CLD.12.1.5 Administrator's operational securityProcedures for administrative operations of a cloud computing environment are to be defined, documented and monitored. The provider should document how its administrators operate the service and monitor their activity; the customer should document the administrative procedures for its own use of the service, covering critical operations such as configuration changes, backup and restore, and access management, and should monitor that they are followed, because a mistaken administrative action in a cloud console can affect the whole tenancy.
- Documented administrative procedures for the cloud environment on each side
- Monitoring records of administrative activity
- Provider description of its administrative practice
- Cloud console administration done ad hoc with no procedure for high-impact actions
- Administrative activity logged but never monitored
SOC 2 CC8.1 Change management processes are in placeAuthorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives
- The change management process covering infrastructure, data, software and procedures, including the emergency change route
- Change records for the period showing design, development or acquisition, configuration, documentation, testing, approval and implementation
- Evidence of segregation between those who develop, approve and implement changes
- Testing evidence per change proportionate to its risk, including security testing where relevant
- Evidence of rollback capability and of post implementation verification
- Emergency changes used routinely, with retrospective approval that is never withheld
- Approval and implementation performed by the same person, so the approval is not independent
- Automated deployment pipelines outside the documented process, so most changes are untested against it
- Infrastructure and configuration change treated as out of scope because the process was written for application code
CMMC CM.L2-3.4.2 Security Configuration Enforcement Level 2Define security configuration settings for the IT products used in the system and enforce those settings in operation.
- Documented security configuration settings or hardening standards
- Evidence of enforcement, for example policy objects or configuration management tooling
- Compliance scan results against the defined settings
- Standards documented but drift never measured
- Settings applied at build with no ongoing enforcement
- Products in use with no defined hardening standard
C5-PSS-11 Images for Virtual Machines and ContainersWhere customers run virtual machines or containers, let the customer restrict which images its users may launch, inform the customer of what changed between versions of any images the provider supplies, and harden those provider supplied images to generally accepted industry standards.
- Customer facing setting restricting which images users are permitted to launch
- Release notes describing what changed between successive provider supplied images
- Hardening baseline and build evidence for one provider supplied image
- Catalogue showing the approved image set made available to a tenant
- Image restriction applies in the console while other launch paths ignore it
- New image versions published with no statement of what changed
- Provider images shipped with default accounts and unnecessary services enabled
- Hardening applied at first build and not maintained across later rebuilds