Initial commit
This commit is contained in:
68
02-standards/logging-and-alerting-standard.md
Normal file
68
02-standards/logging-and-alerting-standard.md
Normal file
@@ -0,0 +1,68 @@
|
||||
Title: Logging and Alerting Standard
|
||||
Document ID: [STD-LOG-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]
|
||||
|
||||
# Logging and Alerting Standard
|
||||
|
||||
## Purpose
|
||||
|
||||
This standard defines the minimum requirements for log generation, log protection, alerting, and review of security-relevant events.
|
||||
|
||||
## Scope
|
||||
|
||||
This standard applies to applications, infrastructure, identity systems, cloud services, Kubernetes environments, CI/CD platforms, and security monitoring workflows within the ISMS scope.
|
||||
|
||||
## Mandatory Requirements
|
||||
|
||||
Systems must generate logs sufficient to support operational oversight, incident investigation, and audit where proportionate to risk.
|
||||
|
||||
Security-relevant events should be logged, including authentication activity, privileged actions, security control changes, and material failures or suspicious events where feasible.
|
||||
|
||||
Logs must be protected against unauthorised access, tampering, and inappropriate deletion.
|
||||
|
||||
Time settings for systems generating logs should be controlled so that event sequencing and investigation remain reliable.
|
||||
|
||||
Alerting rules or equivalent review mechanisms must exist for material security events and high-risk operational issues.
|
||||
|
||||
Logging and alerting coverage must reflect the distributed and ephemeral nature of cloud-native and containerised services.
|
||||
|
||||
Retention of logs and monitoring records must align with approved retention requirements and business need.
|
||||
|
||||
## Implementation Guidance
|
||||
|
||||
BlackDice should define logging expectations by asset class so that services with greater exposure or criticality receive stronger coverage.
|
||||
|
||||
Centralised or consolidated collection should be used where practical to improve correlation, searchability, and access control.
|
||||
|
||||
Alerting should be tuned to balance timely escalation with manageable operational noise.
|
||||
|
||||
Where logs may contain personal data, credentials, or other sensitive information, collection and retention should be minimised to what is necessary and handled appropriately.
|
||||
|
||||
## Roles and Responsibilities
|
||||
|
||||
- [Role] must define logging and alerting control expectations.
|
||||
- System owners must ensure relevant logging exists for their systems and services.
|
||||
- Operational teams must review alerts and take action according to defined processes.
|
||||
|
||||
## Exceptions
|
||||
|
||||
Exceptions to logging or alerting requirements must be documented, risk-assessed, approved, and reviewed.
|
||||
|
||||
## Related Documents
|
||||
|
||||
- Logging and Monitoring Policy
|
||||
- Incident Response Policy
|
||||
- Data Classification and Handling Policy
|
||||
- Records Retention and Disposal Policy
|
||||
|
||||
## Version Control
|
||||
|
||||
| Version | Date | Description of Change | Author |
|
||||
| --- | --- | --- | --- |
|
||||
| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
|
||||
Reference in New Issue
Block a user