Share a cyber observation with a route to correct it
Shared cyber observations can speed up local investigations. Preserve their evidence and revision state, and give the receiving organisation its own decision about any response.
Keep sources linked to the record used for review. The diagram does not represent automatic approval.
An automated defence service can make another organisation’s observation useful within minutes. The receiving team still needs to know what the observation supports. A match may justify opening an investigation or collecting more local evidence. Authority to isolate a device depends on a different decision, made against the receiving organisation’s systems and playbooks.
The National Cyber Security Centre (NCSC) describes Cyber Shield in its annual review published on 3 November. The programme aims to use national intelligence to inform defensive agents in organisations and to combine signals from those agents into wider insights. The review describes shared infrastructure and work on protocols and data models as parts of the programme. It presents a direction for collaboration rather than a deployed interface specification. (NCSC Annual Review, Cyber Shield)
Share an observation with enough context to check it
Consider a hypothetical group of engineering companies sharing threat observations. One company detects an outbound connection to infrastructure associated with suspicious activity. Another has seen the same destination during a legitimate test. A shared message that contains only the destination and a severity label leaves the second company unable to distinguish those cases.
A proposed signal should identify what was observed, where in the technical path it was observed and when. Separate the observation from an assessment about why it happened. Include whether the observation came from an endpoint, a network monitor or a derived correlation. Give it a stable identifier so later information can correct or withdraw it. Where it is possible to share the supporting evidence, give the receiving investigator a way to inspect it.
Apply sharing rules to evidence as well as conclusions. A network event may contain internal names or identifiers the sender does not need to disclose. The Forum of Incident Response and Security Teams’ Traffic Light Protocol is one existing way to label how recipients may redistribute information. That label addresses onward sharing. Use separate fields for evidential strength, the time for which the assessment remains relevant and the local action it may warrant. (FIRST Traffic Light Protocol)
Choose the receiving response
Swipe or scroll for the full diagram →
What does this signal support on the receiving network?
Owner: Security operations owner. Threshold: Local corroboration and the authority required by the playbook.
- Expand
- Take the locally permitted response when its conditions are met.
- Retain narrower scope
- Keep the case open for investigation without taking a disruptive action.
- Gather more evidence
- Request evidence or record a correction when the signal cannot support action.
Hypothetical handling of a shared observation. Each receiving organisation sets its own playbook and authority.
Use a credible observation to gather evidence. A locally approved action needs the required corroboration and authority. A withdrawn or insufficient signal needs an explicit record.
Let the receiving system decide what happens
The receiving organisation can correlate the signal with its own records, route it to an analyst or take an action allowed by a local rule. Decide which of those routes is available for each signal class. A high-confidence external observation may be highly relevant while still saying little about a particular internal device.
For the engineering group, a match could open a case and gather recent connection history. Isolation might require evidence of suspicious activity from the affected device and approval from the response owner, depending on the service and playbook. The message format should make it possible to retain the signal while declining its suggested action. The local record should identify the evidence and authority used.
The NCSC’s companion chapter on operational cyber defence describes agents helping investigate and correlate activity and, in some circumstances, taking reversible action. It puts that work alongside playbooks, reliable telemetry and clear authority. A receiving organisation can prepare these prerequisites while shared protocols develop. (The changing nature of operational cyber defence)
Exercise a correction after the alert has spread
A second exercise starts with an observation that is later withdrawn. Replay its receipt, correlation and withdrawal in a test environment. Confirm that case records reflect the change and that new automated responses stop using the withdrawn signal. If an action already took place, examine the reversal route and the decision owner. Reversing a block and restoring a service are operational events that need their own confirmation.
Include a delayed message, a duplicate and a genuine observation that is irrelevant to the receiving network. These cases help distinguish a format that can transport intelligence from a service that can use it responsibly. Measure time to useful triage and count unnecessary actions. The exercise cannot establish the performance of a national programme or how often the same conditions occur across organisations.
The archive’s effect boundary article concerns refusal when an agent has no authorised route to change an external system. The design here begins earlier, when an observation crosses an organisational boundary and becomes input to another investigation. The security operations owner should first agree what can be exchanged and how recipients can correct it. Expand the receiving service from evidence collection towards response only after it can show which local checks and authority govern each proposed action.