Halden Utilities: an 11-day exposure, a seven-day log retention and a notification clock nobody owns
On 3 March a security researcher emails Halden Utilities that a storage bucket behind its customer portal is publicly readable. The bucket holds 180,000 meter-service records: names, addresses and partial bank details for 4,100 customers. Engineers confirm the exposure on 5 March and close it the same day; the bucket had been public for 11 days. Cloud audit logs exist but the provider retains them for seven days and releases them only through a support ticket taking up to five working days. Halden's SIEM never ingested them. The provider contract requires notification within 72 hours of confirmed unauthorised access. Halden's incident procedure is a one-page document written for on-premises servers, names no provider contact, and has no escalation path to the data protection officer, although 900 affected records belong to EU residents and 179,100 to a non-EU market.
1. Walk through detection to notification: who notifies whom, on what clock, and where the procedure fails.
Read the worked answer
The clock starts on awareness, not confirmation. Where GDPR applies, the controller's 72-hour window runs from when it becomes aware of a personal data breach. A specific, credible report from a researcher naming the bucket and its contents is normally awareness; waiting for engineers to reproduce it on 5 March does not restart the clock. The correct position is to treat 3 March as the awareness date, open the incident then, and let the DPO decide notification on the evidence available.
Who notifies whom
- Halden, as controller, notifies the supervisory authority for the 900 EU records and, because names, addresses and partial bank details create a real fraud and phishing risk, the affected individuals without undue delay. It notifies its own customers/regulator as the non-EU market requires.
- The provider notifies Halden of any breach it detects, under the 72-hour-after-confirmation clause. Here the provider detected nothing, so that clause does not help; it is a safety net, not the primary control.
- Halden cannot outsource its notification duty to the provider.
Where the procedure fails. No cloud provider contact or escalation route; no definition of awareness; no DPO escalation; no decision log; no template; no cross-border assessment step; and a one-page on-premises document that assumes physical servers and internal forensics.
2. What can and cannot be reconstructed about the 11-day exposure, and what must change in logging and evidence handling?
Read the worked answer
What can be reconstructed. Portal and application access logs held by Halden; the provider's control-plane audit logs, if requested in time; any bucket-level access logs, if the bucket was configured to emit them; and configuration history if the account uses a managed configuration recorder. What cannot be reliably reconstructed is a definitive list of who read the objects during the whole period, because the provider's seven-day retention has already expired for most of the window and the release path takes five working days - longer than the retention itself.
Changes
- Deliver cloud audit logs to a destination Halden owns: a log sink into a separate, restricted account or bucket with immutability and a retention period set by incident and legal needs, not by the provider's default.
- Ingest them into the SIEM and prove it works - a log source that exists but is never parsed is the same as no log source. Test with a synthetic exposure.
- Contract for a forensic support path: named contacts, an evidence-handling statement, a response time inside the notification window, and a legal-request route.
- Pre-authorise the collection of volatile evidence in the procedure, and record chain of custody from first contact.
An incident review that only fixes the bucket misses the point: the bucket was the trigger, the evidence gap is the systemic failure.
3. Classify the incident and decide what the first 24 hours after the 3 March email should look like.
Read the worked answer
Classification. A confidentiality breach of personal data, high severity: 180,000 records, a live identifier set, and financial fragments that make targeted phishing credible. It is also an availability and integrity question until the object store is examined - check for modification or deletion, not just read access. Severity should drive the escalation tier, not the reverse.
First 24 hours
- Acknowledge the researcher, ask for the URL and timestamps, and log the contact.
- Open a formal incident with a single commander, and notify the DPO and legal immediately - not after confirmation.
- Contain without destroying evidence: change the bucket policy, but capture the configuration, IAM policies and any available logs first. Snapshot before you clean.
- Ask the provider for audit logs the same day, referencing the contractual timeframes and escalating through the account team because the ticket queue will not meet the clock.
- Decide and record whether the awareness threshold is met for notification purposes, with reasons, and diarise a reassessment within 24 hours.
- Start the affected-population analysis so individuals can be told specifically what leaked.
The failure mode to avoid is a tidy, sequential investigation that consumes the statutory window before the DPO is in the room.