CIS Controls Cloud Companion Guide (v8.1)

Control 4 covers secure configuration of enterprise assets and software. In cloud environments, most configuration is set through consoles, APIs and templates rather than on hardware you own, so the configuration record is often the cloud account itself. Safeguard 4.6 asks that enterprise assets and software be managed securely, and the CIS examples point to keeping configuration in version-controlled infrastructure as code and reaching administrative interfaces over secure protocols such as SSH and HTTPS.

• Version-controlled templates: Keep cloud resource definitions in a repository so changes have an author, a review and a history.
• Secure administrative access: Confirm that management interfaces use SSH or HTTPS and that Telnet and HTTP are disabled unless a documented operational need exists.
• Drift detection: Compare deployed resources against the templates so that console changes do not silently replace approved settings.
• Hardened baselines: Map the account and workload settings to the relevant CIS Benchmarks for your cloud provider.
• Exceptions: Record every insecure protocol that remains and the reason it is needed.

Before an assessment, ask the platform team to show a repository commit that changed a production network setting and the review that approved it.

Control 15 covers service provider management. A cloud platform, managed database, SaaS tool or support partner that holds your data or runs part of your IT operations is a service provider under this Control, even when you never sign a traditional contract with it. Safeguard 15.1 asks for an inventory that lists all known service providers, their classification or classifications, and a designated enterprise contact for each.

• Complete inventory: Include cloud accounts, managed services, SaaS applications and subprocessors that touch sensitive data.
• Classification: Record which providers hold sensitive data or run critical processes, since that drives how much assessment each one receives.
• Named contacts: Assign an internal owner for every provider so that questions about security, incidents and renewals have a destination.
• Shared responsibility: Document which controls the provider operates and which controls your team still owns in each service model.
• Review trigger: Update the inventory when a new cloud service is adopted, not only at annual review.

Ask the team to show the inventory filtered by data sensitivity and confirm that each entry has a named owner.

Control 16 covers application software security across the software life cycle, including software developed in-house, hosted or acquired. Cloud delivery speeds releases through automated pipelines, so security checks have to run inside those pipelines rather than in a separate review at the end. The Cloud Companion Guide links agile, cloud-based development to Control 16, which makes the pipeline a place where evidence is produced.

• Environment separation: Show that development, test and production environments are separated, with distinct accounts or projects where practical.
• Automated code checks: Run static analysis and dependency checks on every merge and record the results.
• Third-party components: Track libraries and container images, and document how vulnerable components are handled.
• Threat modeling: Attach threat models to significant design changes, including new cloud services.
• Pipeline access: Restrict who can change build and deployment definitions, and log those changes.

Ask for a sample of recent pipeline runs that show a failed security check and the fix that followed.

Control 8 covers audit log management. In cloud environments, much of the activity that matters happens inside the provider's control plane, such as account changes, identity events and API calls. Control 8 includes service provider logs, which means you need to collect the logs your cloud provider and other service providers make available to you, not only logs from workloads you operate directly.

• Control plane logs: Enable account-level activity logging and send it to a location your team controls.
• Identity and access events: Capture sign-ins, role changes and permission updates from the cloud identity service.
• Time synchronization: Confirm that logs from cloud and on-premises sources use a consistent time source so events can be correlated.
• Retention: Define how long each log source is kept and who can access it, and test retrieval.
• Provider log review: Name who reviews provider logs and how often, and record the findings.

Before an assessment, check that a sample administrative action in the cloud console appears in your central log store within the period your process states.

CIS publishes Benchmarks for cloud platforms that translate Control 4 into specific settings. For Amazon Web Services, CIS lists current Benchmarks for AWS Foundations, Compute Services, Database Services, End User Compute Services and Storage Services. These Benchmarks give a concrete check for the configuration and identity settings that the cloud Companion Guide asks you to manage. Because Benchmarks change with provider releases, the version you test against matters.

• Foundations first: Start with the AWS Foundations Benchmark for account-level settings, then add service-specific Benchmarks for the services you use.
• Version tracking: Record the Benchmark version used for each scan so results can be compared over time.
• Scanning: Run automated checks against accounts on a schedule and retain the output.
• Remediation ownership: Assign each failed check to a team and track it to closure.
• Scope statement: Document which accounts and services are in scope and which are excluded, with reasons.

Confirm with your platform team which Benchmark versions the scanning tool supports before relying on a score.