Detection Gaps at a Payments Processor

Logging (8.15)

• Coverage is incomplete: 3 of 14 network devices. The firewall is the single most valuable source for detecting command-and-control and exfiltration, and it was switched off rather than tuned.
• Event selection was never risk-based. Privileged group changes - the highest-signal event in most intrusions - are not logged as an alertable event at all.
• Retention of 14 days of raw logs is almost certainly below the legal and contractual expectations applicable to a payments processor, and it guarantees that any incident discovered late is unreconstructable.

Monitoring (8.16)

• There is no defined monitoring use-case set, no alerting, and no tuning process. Dashboards reviewed by two analysts during office hours are not monitoring; they are periodic inspection.
• The March response to collector saturation was to remove a source. That is a capacity and design failure being managed as an operational inconvenience.

Clock synchronisation (8.17)

• Servers use public NTP pools with no authentication, and two domain controllers are 47 minutes out. Cross-source correlation is impossible when timestamps disagree, and evidence gathered for disciplinary or legal purposes is weakened.

Incident management (5.24-5.26)

• Detection depended on chance; there is no out-of-hours path and no tested escalation, which is why 11 days elapsed.

Evidence (5.28)

The reconstruction failed for a predictable reason: the data no longer existed. That is a design defect, not bad luck.

Evaluation

More storage addresses retention only. It does not address any of the three reasons the June intrusion went undetected for 11 days: missing sources, absent detection logic, and no out-of-hours review. Nor does it fix the time drift that makes stored logs uncorrelatable. Buying storage first is spending on the symptom, and it will produce a larger archive of evidence that still cannot answer the question.

What to fund, in order

1. Re-enable firewall logging, but with filtering and aggregation at source - flow records, deny/allow summarisation, selected syslog facilities. This restores the single most important evidence source at a fraction of the volume that saturated the collector, and it costs mostly configuration effort.
2. Fix time. Two internal NTP servers syncing to authenticated external sources, a domain hierarchy beneath them, and an alert on drift beyond a few seconds. Without this, every other investment is undermined.
3. Build a prioritised alert catalogue: privileged group and role changes, new service creation, disabling of security tooling, mass file access, endpoint detections, anomalous outbound volume. Start with ten rules that map to real attack paths rather than a thousand that nobody reads.
4. Cover the monitoring hours. Either a follow-the-sun arrangement, an MSSP for out-of-hours triage with clear escalation into the internal team, or automation for first-line triage. Record the residual risk if the organisation chooses business hours only.
5. Then storage, if the agreed retention policy requires it.

Measure

Report mean time to detect and mean time to acknowledge, not ingestion rate. Ingestion volume measures how much data you bought, not how much you see.

The constraints

• Logs contain personal data: usernames, IP addresses, workstation identifiers and sometimes file names or message content. Collecting them is processing and needs a stated, legitimate purpose.
• Purpose limitation is the crux. Logs collected for security monitoring must not be quietly repurposed for performance management, attendance tracking or general employee surveillance. That repurposing is a common and expensive mistake.
• Minimisation: do not collect what you will never review. Expanding collection 'in case' is the opposite of a risk-based decision.
• Transparency: employees must be told what is monitored, why, how long it is kept and who can see it. In many European jurisdictions, works councils or unions must be consulted before monitoring is introduced or widened.
• Retention: each log type needs a defined retention period justified by investigation and legal needs, not simply 'keep everything forever'.

How to satisfy them

• Write the purpose into the monitoring procedure so that scope creep requires a change, not an improvisation.
• Restrict access: role-based access to the SIEM, a named monitoring team, and logged access to log data itself.
• Prohibit content inspection of communications except in a specifically authorised investigation, with evidence handling and chain of custody documented.
• Define retention per source and automate deletion.
• Record the assessment, the notice given and the consultation outcome before the expanded collection starts.

Judgement

The same technical control can be lawful or not depending on notice, scope and use. Widening collection without those elements converts a security improvement into a compliance exposure.