Initial commit

02-standards/secure-configuration-standard.md

@@ -0,0 +1,70 @@
+Title: Secure Configuration Standard
+Document ID: [STD-CONFIG-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Secure Configuration Standard
+
+## Purpose
+
+This standard defines the minimum secure configuration expectations for systems, services, platforms, and supporting technology within the ISMS scope.
+
+## Scope
+
+This standard applies to cloud resources, operating systems, endpoints, containers, Kubernetes components, applications, security tooling, and supporting infrastructure.
+
+## Mandatory Requirements
+
+Systems must be configured according to approved security baselines appropriate to their function, risk, and exposure.
+
+Unnecessary services, ports, protocols, packages, permissions, and features must be disabled or removed where practical.
+
+Default settings that increase security risk must be changed before operational use.
+
+Configuration changes affecting security posture must be controlled through the approved change process.
+
+Configuration standards for production and other high-risk environments must be documented and subject to periodic review.
+
+Security-relevant configuration drift must be detected through review, monitoring, automation, or other suitable means.
+
+Administrative interfaces and management access paths must be restricted and hardened.
+
+Sensitive configuration items, including secrets and key material, must not be embedded in unsecured locations.
+
+## Implementation Guidance
+
+BlackDice should define baseline configurations for common asset classes and align them with cloud-native operating patterns, infrastructure-as-code usage, and automation pipelines.
+
+For distributed or ephemeral workloads, secure configuration should be enforced as early as possible in templates, images, manifests, and deployment workflows rather than relying only on manual review.
+
+Configuration assurance should cover both initial build state and ongoing operational state.
+
+Where legacy constraints or third-party managed services limit baseline application, the residual risk should be understood and addressed through compensating control or exception.
+
+## Roles and Responsibilities
+
+- [Role] must define secure baseline expectations.
+- System and platform owners must implement and maintain approved configurations.
+- Change owners must ensure security-impacting configuration changes are assessed and approved.
+
+## Exceptions
+
+Exceptions to baseline configuration requirements must be documented, risk-assessed, approved, and reviewed.
+
+## Related Documents
+
+- Cloud Security Policy
+- Network and Infrastructure Security Policy
+- Vulnerability and Patch Management Policy
+- Change Management Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |