SIAS-CLD-01 Secure configuration baselines and drift detection
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes (servers, containers, cloud services, network devices and SaaS admin settings)
- SecurityInspect Verified profiles
- VP-CLD
Control objective
Every in-scope platform is built to a documented hardened configuration, and departures from it are found automatically and corrected or consciously accepted.
Testable requirement
- (a)The applicant shall maintain a documented baseline configuration for each in-scope platform type (operating systems, database engines, container hosts and images, cloud service configurations, network devices and the administrative settings of in-scope SaaS tenants). Each baseline shall be derived from a recognized public hardening benchmark or the vendor's published security guidance, name its source and version, and record each deviation with its reason.
- (b)The applicant shall apply baselines at build or provisioning time (for example through hardened images, templates or policy-as-code), not only after deployment.
- (c)The applicant shall change default credentials and disable unnecessary services, ports, accounts and features before a system enters production.
- (d)The applicant shall detect drift from the baseline automatically at least every 7 days.
- (e)The applicant shall correct drift, or record an approved deviation, within 30 days for settings the baseline marks as high impact and within 90 days for other settings.
- (f)The applicant shall review each baseline at least every 12 months and after its source publishes a major revision.
Applicability and scope
All scopes (servers, containers, cloud services, network devices and SaaS admin settings). It cannot be marked not applicable. SecurityInspect Verified profiles: VP-CLD, where it covers the platforms inside the named cloud tenants or accounts.
Pass criteria
- 1.A baseline exists for every in-scope platform type, names its source and version, and justifies each deviation (M1).
- 2.The sampled checks find no failing high-impact setting without an approved deviation, and at least 95% of all checked settings pass (A1, M2).
- 3.No in-scope system accepts a vendor default credential (A2).
- 4.No sampled host runs a listening service that the baseline does not allow, unless an approved deviation covers it (A3).
- 5.Drift detection ran at least every 7 days throughout the look-back (A4).
- 6.No drift item is past its deadline without an approved deviation (A5, M3).
- 7.Each baseline was reviewed in the last 12 months, and the inspected new build met the baseline (M4).
Severity
High. Standard escalation triggers apply. A default credential that works on an internet-facing management interface is an authentication bypass and is recorded as a Critical finding.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 2.2
- Trust Services Criteria
- CC7.1
- ISO/IEC 27001:2022
- A.8.9
- Theme (SecurityInspect wording)
- hardened baselines with automated drift checks
SIAS-CLD-02 Cloud account and tenant governance
- Mandatory
- Yes
- Severity
- High
- Applies
- Conditional — IaaS, PaaS or SaaS administrative tenants or accounts are in scope
- SecurityInspect Verified profiles
- VP-CLD
Control objective
Every cloud account and SaaS administrative tenant in scope is known, centrally governed and protected by guardrails, and the most powerful identities in each tenant are tightly held.
Testable requirement
- (a)The applicant shall maintain an inventory of every cloud account, subscription, project and SaaS administrative tenant in scope, showing the owner, purpose, environment (production or non-production) and the organization or billing structure it belongs to. No account outside the inventory shall hold in-scope data.
- (b)Where the provider supports it, the applicant shall manage accounts under a central organization structure with preventive guardrails that at least: stop control-plane logging from being disabled; restrict resources to approved regions; and block public access to resources by default (see SIAS-CLD-03).
- (c)The applicant shall separate production from non-production at the account, subscription or project level.
- (d)The applicant shall protect each root, owner or tenant-wide administrator identity: multi-factor authentication enabled, no long-lived access keys, no routine use, credentials held in a vault or under dual control, and an alert on every use.
- (e)No more than four named individuals shall hold the highest tenant-wide administrative role in any tenant, unless the applicant documents why more are needed. No shared or unnamed account shall hold that role.
- (f)The applicant shall enable control-plane activity logging in every account and in every region with activity. Protection of those logs is assessed under SIAS-LOG-02.
- (g)The applicant shall follow a documented procedure for opening and closing accounts, including removal of resources and data at closure.
Applicability and scope
Conditional — IaaS, PaaS or SaaS administrative tenants or accounts are in scope. Marking it not applicable needs a written rationale approved by the quality reviewer. SecurityInspect Verified profiles: VP-CLD, where it covers the named tenants or accounts and the organization structure above them.
Pass criteria
- 1.The inventory matches the organization enumeration and the billing records, and no unlisted account holds in-scope data at decision (A1, A6, M2).
- 2.Every in-scope account is under the management structure with the required guardrails active, or a documented provider limitation applies, and the guardrail test was blocked (A2, M3).
- 3.Production and non-production are separated at the account, subscription or project level (M5).
- 4.Every root, owner and tenant-wide administrator identity has multi-factor authentication, no long-lived access keys, no routine use and a working use alert (A3, M4).
- 5.No tenant has more than four holders of the highest administrative role without a documented reason, and none is a shared or unnamed account (A4).
- 6.Control-plane logging is enabled in every account and every region with activity (A5).
- 7.Every account closed in the look-back followed the closure procedure (M5).
Severity
High. Standard escalation triggers apply. Missing multi-factor authentication on a tenant-wide administrator identity also fails SIAS-IAM-02 (Critical severity), where it is scored.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 2.2, 7.2
- Trust Services Criteria
- CC6.1
- ISO/IEC 27001:2022
- A.5.23
- Theme (SecurityInspect wording)
- governed cloud tenants with enforced guardrails
SIAS-CLD-03 Prevention of unintended public exposure of cloud resources
- Mandatory
- Yes
- Severity
- Critical
- Applies
- Conditional — cloud storage, databases, snapshots, functions or management endpoints are in scope
- SecurityInspect Verified profiles
- VP-EXT, VP-CLD
Control objective
No cloud resource in scope can be read or reached from the internet by an unauthenticated party unless it was deliberately made public and holds only public data, and any new exposure is found and handled quickly.
Testable requirement
- (a)No in-scope storage container, database, cache, search cluster, snapshot, backup, machine image, message queue, function URL, container registry or management endpoint shall be accessible to unauthenticated or anonymous parties from the internet, unless it is recorded in a public-resource register with its owner, its purpose and confirmation that it holds only Public-classified data.
- (b)The applicant shall enable provider-level controls that block public access by default at account or organization level wherever the provider offers them. Per-resource exceptions shall be made only for resources in the public-resource register.
- (c)The applicant shall restrict database ports and management endpoints (for example SSH, RDP, orchestration APIs and administrative panels) to private networks, brokered administrative access or allow-listed source addresses. No rule shall allow those ports from any internet source.
- (d)The applicant shall detect new public exposure automatically at least daily, alert a monitored queue, and triage each alert for a resource not in the register within 24 hours.
- (e)Snapshots, machine images and backups shall be shared only with named accounts, never publicly.
Applicability and scope
Conditional — cloud storage, databases, snapshots, functions or management endpoints are in scope. Marking it not applicable needs a written rationale approved by the quality reviewer. SecurityInspect Verified profiles: VP-EXT and VP-CLD. In VP-EXT, criteria 1 and 3 are tested externally against the declared internet-facing assets, and the applicant grants read-only access to the cloud accounts that host those assets so that criteria 2, 4 and 5 can also be tested.
Pass criteria
- 1.No resource of a type listed in requirement (a) is readable or reachable by unauthenticated parties, except registered resources holding only Public data (A1, A2, A5, M1, M2).
- 2.Account-level or organization-level public-access blocking is enabled wherever the provider supports it, and per-resource exceptions exist only for registered resources (A3).
- 3.No network rule allows database or management ports from any internet source (A4).
- 4.Exposure detection ran at least daily, the canary test was blocked or was alerted and triaged within 24 hours, and every look-back alert was triaged within 24 hours (A6, M3, M4).
- 5.Snapshots, images and backups are shared only with named accounts (M5).
Severity
Critical. A confirmed exposure of sensitive data or credentials to unauthenticated parties is Critical and cannot be lowered. A finding may be lowered one level only when no in-scope resource is actually exposed (for example an account-level block is missing but nothing is public), with written rationale, quality-reviewer concurrence and second independent reviewer concurrence.
Informative framework mappings
- HIPAA Security Rule
- §164.312(a)(1)
- PCI DSS v4.0.1
- 1.3, 1.4
- Trust Services Criteria
- CC6.6
- ISO/IEC 27001:2022
- A.5.23, A.8.3
- Theme (SecurityInspect wording)
- no unintended internet exposure of cloud resources
SIAS-CLD-04 Infrastructure-as-code and configuration change control
- Mandatory
- No
- Severity
- Medium
- Applies
- Conditional — infrastructure-as-code or configuration-management tooling manages in-scope resources
- SecurityInspect Verified profiles
- VP-CLD
Control objective
Changes to infrastructure defined as code are reviewed by a second person, checked automatically for security problems and applied through a controlled pipeline, and changes made outside that path are found and brought back under control.
Testable requirement
- (a)The applicant shall store infrastructure-as-code and configuration-management definitions for in-scope resources in version control. The production branch shall be protected: direct pushes blocked, and each change approved by at least one person other than its author.
- (b)The applicant shall apply changes to production through an automated pipeline using a dedicated deployment identity with only the permissions it needs, and shall log each pipeline run.
- (c)The applicant shall run automated security checks on each proposed change and block merges that introduce issues the applicant rates high impact (at least public exposure, disabled encryption and disabled logging).
- (d)The applicant shall reconcile deployed state against the definitions at least every 7 days. Each change made outside the pipeline shall be recorded with a justification and brought back into the definitions within 30 days.
- (e)Emergency changes that bypass review shall be reviewed after the event within 5 business days.
- (f)Definitions and state files shall contain no secrets in clear text, and state files shall be stored encrypted with access limited to the pipeline and named administrators.
Applicability and scope
Conditional — infrastructure-as-code or configuration-management tooling manages in-scope resources. Marking it not applicable needs a written rationale approved by the quality reviewer. SecurityInspect Verified profiles: VP-CLD.
Pass criteria
- 1.Every in-scope repository's production branch blocks direct pushes and requires approval from someone other than the author (A1).
- 2.Every sampled production change in the look-back was approved by someone other than its author and passed its required checks, or is a documented emergency change reviewed within 5 business days (A2, M2, M3).
- 3.Automated security checks run on every change and block the high-impact issue types in requirement (c) (A3, E7).
- 4.Drift was reconciled at least every 7 days, and every change outside the pipeline was justified and returned to the definitions within 30 days (A6, M3).
- 5.No unrotated secret exists in the definitions or their look-back history, and state files are encrypted with restricted access (A4, A5, M4).
- 6.The deployment identity has no permissions beyond those its pipeline needs (M5).
Severity
Medium. Standard escalation triggers apply. A secret in a repository that unauthenticated parties can read is credential exposure and is recorded as a Critical finding.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 2.2, 6.5
- Trust Services Criteria
- CC8.1
- ISO/IEC 27001:2022
- A.8.9, A.8.32
- Theme (SecurityInspect wording)
- reviewed, pipeline-applied infrastructure changes
SIAS-CLD-05 Container, orchestration and serverless workload security
- Mandatory
- No
- Severity
- High
- Applies
- Conditional — containers, orchestration platforms or serverless functions are in scope
- SecurityInspect Verified profiles
- VP-CLD
Control objective
Container and serverless workloads run from trusted images with least privilege, their control planes are not open to the internet, and their secrets and network paths are controlled.
Testable requirement
- (a)The applicant shall build container images from approved, maintained base images and deploy only from approved registries, enforced at deployment time.
- (b)The applicant shall scan images for known vulnerabilities and embedded secrets in the build pipeline and continuously in the registry. Remediation timelines for the vulnerabilities found are set and scored under SIAS-VPM-02.
- (c)Workloads shall not run in privileged mode, share host namespaces, mount sensitive host paths or run as the root user unless an approved, documented exception covers them. The applicant shall enforce this with admission control or another policy mechanism that blocks non-conforming workloads.
- (d)Orchestration control-plane APIs shall be reachable only from private networks or allow-listed sources, shall require authentication, and shall have anonymous access disabled.
- (e)Workload secrets shall be held in a secrets manager or an encrypted orchestration secret store, never baked into images or kept in plain text in repository-stored workload definitions.
- (f)Namespaces or services that process Restricted data shall have network policies that deny traffic by default and allow only the flows they need.
- (g)Serverless functions and workload identities shall have only the permissions they need. Wildcard administrative permissions require an approved exception.
- (h)Orchestration platform versions and function runtimes shall be within vendor support.
Applicability and scope
Conditional — containers, orchestration platforms or serverless functions are in scope. Marking it not applicable needs a written rationale approved by the quality reviewer. SecurityInspect Verified profiles: VP-CLD.
Pass criteria
- 1.Every running image comes from an approved registry, and scanning runs in the pipeline and in the registry (A1, A2, E6).
- 2.No privileged, root, host-namespace or sensitive-host-mount workload runs without an approved exception, and the admission test was rejected (A3, M2, M3).
- 3.Orchestration control-plane APIs are not reachable from the internet except from allow-listed sources, and anonymous access is disabled (A4, A5).
- 4.No secret is present in an image or in a repository-stored workload definition (A2, M4).
- 5.No workload identity or function holds wildcard administrative permissions without an approved exception (A4, M2).
- 6.Orchestration versions and function runtimes are within vendor support (A6).
- 7.Every namespace or service that processes Restricted data has a default-deny network policy (A7).
Severity
High. Standard escalation triggers apply. Anonymous access to an orchestration API from the internet is an authentication bypass, and a Known Exploited Vulnerability on an internet-facing workload is escalated; both are recorded as Critical findings. A condition such as an unsupported runtime is recorded once, against the most specific control.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 2.2, 6.3
- Trust Services Criteria
- CC6.8, CC7.1
- ISO/IEC 27001:2022
- A.8.9, A.8.19
- Theme (SecurityInspect wording)
- hardened, least-privilege container and function workloads
