3. Security Impact
Security events break customer trust in us; being good at information security is about preserving customer trust. Many events have a customer or security impact, and this process makes a point of treating them equally.
Security events are a special class of event, in that they may have downstream, unknown or unintended consequences that weren't clear at the original time of the event, or the time when the post-mortem analysis is completed. They may have their own process and team involved in the incident separately. CoE helps that work.
Confidentiality, Integrity and Availability are three separate questions, and each of them is answered with evidence rather than with a view.
Could anybody have read something they should not have? What data, whose, and how many of them?
Could anything have been written, altered or deleted that should not have been? If we believe not, what did we look at that tells us so?
Was the system available to the people entitled to use it? If the answer to this one is no, it is usually the failure itself and belongs in Customer Impact as well.
These are far easier to answer when somebody has already asked them of the system before it failed. That is what a threat model is: what the system holds, who would want it, how it could be reached, and what we decided to do about each of those. During an incident it turns what could have been read? from a research task into a lookup, and the difference is measured in hours at the point where the clock is already running. It is why inventory, bill of materials, threat model is on the list of habits in what good looks like.
There was no security impact. The failure was confined to the rendering of a page that carries no customer data. We reviewed the access logs for the two hours around the incident and found no requests to any authenticated route from the affected instances.
Confidentiality was breached. Integrity and availability were not. 41 customers had their name, postal address and account balance shown to 214 other customers. No credential, full account number or date of birth was disclosed. We notified the Information Commissioner within 72 hours and wrote to all 255 customers involved.
There was no confidentiality or availability impact. We cannot yet say whether there was an integrity impact. The job wrote to the ledger table for 19 minutes while holding a stale view of the account, and reconciliation against the payment provider is not complete. This section will be reissued.
The third is the most useful of the three, and the hardest to write.
If there was no impact, then "There was no security impact." is sufficient; but care should be taken, especially with internet or customer facing systems. The sentence has to survive being asked how we know.
If we define Security as Confidentiality, Integrity and Availability, was there definitely still no impact?
Every security event is also evidence about the threat model, and this section should say which kind of evidence it is.
The threat was modelled and the control did not hold. We understood the risk, chose a mitigation, and it failed, or was never implemented, or was implemented somewhere other than where it was needed. Reference the threat by its identifier and say which of those it was.
The threat was not in the model. This is the more serious of the two findings and the more common. It means the incident is not really the failure — the incident is that we were working from a picture of the system that did not include this, and everything else we concluded from that picture is now worth reading again.
Updating the model is a Next Action like any other, with a person against it and a date. A CoE that closes with neither the model nor the controls changed has quietly decided the event was bad luck.
Cause of Error is not a substitute for an Information Security Incident Response plan. CoE may be part of one. Where a separate security incident is running, this section is where the two meet, and it should say who owns that work and where it is recorded rather than repeating it here.
The clock runs from when we became aware, not from when we understood. Where a personal data breach is notifiable — under UK GDPR that is 72 hours to the Information Commissioner — the notification and the CoE run alongside each other, and the CoE must never be the reason a notification is late. A first issue that says we are still counting is expected. A late notification is not.
A security impact and a personal data breach are not the same thing, and neither one contains the other. An outage that destroyed a backup is a breach of the availability of personal data with no attacker anywhere near it, and a credential left in a public repository is a security impact with, on a good day, no personal data involved at all. Ask both questions.
Where a control saved us that we did not know we had, this section is where to say so. It is tempting to write it up as though we had planned it, and that turns the one piece of genuine luck in the document into an assurance somebody will later rely on. A control we did not know we had is not a control.