Full Report
New proposal appears for better incident evaluation and reporting – without the inflation. In following the various ICS cyber incidents since 2010 I often asked myself: how significant is this incident for the sector of critical infrastructure in which it occurred? Was it an incident due to some unintentional accident, operator error, equipment fault or […]
Analysis Summary
# Best Practices: ICS/OT Incident Evaluation and Reporting
## Overview
These practices address the critical need for accurate, technical, and objective evaluation of Operational Technology (OT) and Industrial Control System (ICS) security incidents. They aim to move beyond "media-driven" reporting (which is often inflated or inaccurate) toward a standardized framework for measuring actual physical and operational impact.
## Key Recommendations
### Immediate Actions
1. **Activate Triage Protocol:** Within the first 12 hours of an incident, focus on process stability rather than public reporting. Ensure engineers and operators are the primary sources of internal truth.
2. **Establish Fact-Checking Channels:** Prioritize internal engineering data over initial "fog of war" reports. Avoid making public statements about "cyber attacks" until malicious intent is confirmed via logs.
3. **Engage Subject Matter Experts (SMEs):** Immediately involve those closest to the industrial process (operators and control systems engineers) to differentiate between equipment failure and malicious manipulation.
### Short-term Improvements (1-3 months)
1. **Implement an OT Incident Impact Score:** Adopt a standardized scoring system (like the proposed OT Incident Impact Score) to categorize events by their actual effect on the physical process rather than just network penetration.
2. **Establish External Forensic Partnerships:** Contract third-party ICS forensic specialists who can be deployed when local teams suspect malicious intent but lack specialized tools for deep-packet inspection or PLC memory analysis.
3. **Draft Communication Governance:** Create a policy that mandates technical validation from the Engineering/OT department before the C-Suite or PR department releases incident status updates.
### Long-term Strategy (3+ months)
1. **Institutionalize Post-Incident Reporting:** Commit to publishing or reviewing "Official Reports" 30–60 days after an event. These should include the "Who, What, Where, How, and Why" to contribute to the global community's knowledge base.
2. **Cross-Sector Knowledge Sharing:** Participate in information-sharing platforms (like CERTs or ISACs) to determine if an incident is a "one-off" or part of a wider trend in the critical infrastructure sector.
3. **Standardize Forensic Readiness:** Integrate ICS-specific forensic logging (e.g., changes to Safety Instrumented Systems) into standard operating procedures to reduce the "time to discovery."
## Implementation Guidance
### For Small Organizations
- **Resource Limitation Management:** Rely on established public resources like CERT Polska or NERC briefings to learn from the mistakes of larger entities.
- **Initial Focus:** Focus on distinguishing "unintentional accidents" from "malicious intent" early to avoid unnecessary panic.
### For Medium Organizations
- **Departmental Synergy:** Bridge the gap between the IT Security team and the Engineering team. Ensure the Engineering team has a seat at the table during incident response meetings.
- **Drill Planning:** Conduct tabletop exercises that simulate the "media bubble" to practice staying grounded in technical facts under pressure.
### For Large Enterprises
- **Governance:** Implement rigorous reporting standards that align with international frameworks like ISA/IEC 62443.
- **Leadership Role:** Lead the adoption of the OT Incident Impact Score to set an industry benchmark, reducing the likelihood of unnecessary government hearings due to misinformation.
## Configuration Examples
*While this specific article focuses on reporting philosophy, it refers to the following technical indicators for configuration:*
- **Safety Instrumented Systems (SIS) Monitoring:** Configure alerts for any unauthorized changes to SIS logic (Ref: Triton/Trisis incident).
- **Network Traffic Analysis (NTA):** Deploy sensors specifically tuned for industrial protocols (Modbus, DNP3, etc.) to capture the "how" of an intrusion.
- **Log Retention:** Ensure logs for industrial controllers are retained for at least 6 months to support long-tail forensic investigations.
## Compliance Alignment
- **ISA/IEC 62443:** Particularly Workgroup 16 (Incident Management).
- **NIST SP 800-61:** (Computer Security Incident Handling Guide).
- **NIST SP 800-82:** (Guide to Industrial Control Systems Security).
- **NERC CIP:** (Critical Infrastructure Protection standards for the energy sector).
## Common Pitfalls to Avoid
- **"The Media Bubble":** Allowing PR departments or uninformed journalists to dictate the narrative before technical forensics are complete.
- **Underestimating Discovery Time:** Expecting full clarity within 12 hours; history (e.g., Saudi Aramco/Triton) shows it can take months to confirm malicious intent in OT environments.
- **Blaming the Operator:** Characterizing hard-working engineers as the "cause" of poor reporting; the fault usually lies with disconnected C-Suite/PR communication protocols.
- **The "Fog of War":** Acting on initial, unconfirmed reports (e.g., the San Bruno explosion being initially reported as a plane crash).
## Resources
- **OT Incident Impact Score Initiative:** [Proposed framework for objective scoring]
- **CERT Polska Incident Reports:** [hXXps://cert[.]pl/en/posts/2026/01/incident-report-energy-sector-2025/]
- **Dragos Intelligence Reports:** [hXXps://www[.]dragos[.]com/blog/poland-power-grid-attack-electrum-targets-distributed-energy-2025]
- **ISA 99 (IEC 62443):** [Industrial Automation and Control System Security Standards]