71 lines
2.9 KiB
Markdown
71 lines
2.9 KiB
Markdown
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] |
|