69 lines
2.8 KiB
Markdown
69 lines
2.8 KiB
Markdown
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] |
|