Back Activities

Managing observability

This activity must be performed during the following phases:

Alpha Private beta

Observability refers to the ability to capture the current state of your digital project or service through logging, monitoring, and alerting.

This is crucial for identifying and responding to potential attacks.

Strong observability also allows teams to:

  • check the effectiveness of security controls
  • identify areas of improvement on an ongoing basis
  • enhance the resilience of digital projects and services while they are operational
  • support ongoing security assurance activities

Who is involved in this?

Your approach to security logging should be:

  • designed by technical security architects and systems engineers. For example, DevOps who have detailed technical knowledge of your infrastructure to configure logging, storage, analysis and alerts
  • monitored on a daily basis by a Security Operations Centre (SOC) or equivalent monitoring body
  • supported and reviewed by security professionals to ensure accurate data capture and analysis

This is a shared responsibility across the Cyber and Information Security Division (CISD) and project teams for responding to security incidents.

It is important that security logs and events can be shared with the Security Incident Management (SIM) team in the event of critical and major incidents (P1 and P2) or when self-reporting security incidents.

When should I think about observability?

You must consider your approach to logging and monitoring during the projects build phases. It should be no later than private beta stage of delivery.

Thinking about this during system design allows you to:

  • build and integrate the appropriate capability into your system
  • identify opportunities to work alongside the CISD Security Operations Centre (SOC) in the future

You should regularly review your approach to security logging:

  • when major system changes are planned or implemented
  • when threats to your digital project or service change

Where required, you should update your approach to ensure any risks remain within your risk appetite.

Determining logging, monitoring, and alerting requirements

Delivery teams must follow the Logging and Monitoring Policy (DfE intranet) when performing this activity. Key considerations for project teams include:

  • ensuring required logs are captured as per section 5.1 of the policy
  • monitoring and auditing security logs as per section 5.2
  • adequately protecting security logs as per section 5.4
  • retention of security logs for at least 3 months, as per section 5.5

We recommend expressing your security monitoring needs as a series of requirements. This allows them to be easily tracked and support project planning across other SbD activities.

When doing this, project teams should:

  • consider the security capabilities of the technologies you are using, and whether you may need to use more capabilities
  • ensure enough security data is collected to counter known threats. For example, as determined by your business impact assessment, threat assessment, threat modelling, and associated risk treatments
  • check security data on a regular ongoing basis, to identify potential security issues and attacks
  • integrate security data to continuously verify and improve control effectiveness
  • document the approach to ensure consistency and alignment across key stakeholders. This should include how data is analysed and when alerts are triggered in response to suspected security incidents.

Further reading