If someone tried a Triton style attack on your safety system, would you notice? This checklist tests that with twelve questions about network paths, engineering workstations, firmware and response. It draws on MITRE's description of the malware and on standards such as ISA/IEC 62443, and it assumes no blame for any past victim.
What does the malware tell us to check?
MITRE describes Triton as a framework built to interact with Triconex safety controllers over the TriStation protocol on UDP port 1502. It discovers controllers by broadcast, reads operating mode and key state, exploits a firmware flaw for privilege escalation, disables a firmware consistency check after injecting a payload, and changes controller tasking so the payload runs every cycle.
Each behavior suggests a question. The list below follows them.
The twelve questions
Network
- Can any host outside a short list reach your safety controllers over their programming protocol?
- Do you capture and alert on that protocol, so an unfamiliar source stands out?
- Is broadcast discovery traffic on the safety network normal or rare? Do you know the baseline?
- Is the safety network separated from the process control network, with a controlled path between them?
Workstations and access
- How many engineering workstations can program the safety system? Who can log in to them?
- How does a vendor or contractor reach these workstations, and is each session approved and recorded?
- Is a workstation that talks to controllers also used for email or web browsing?
Firmware and programs
- Do you have a current list of controller models and firmware versions?
- Who watches vendor and CISA advisories for those models, and how fast do they act?
- Do you hold known good copies of the controller programs and compare them to what runs?
Response
- If a safety controller trips for no clear reason, is there a rule to investigate it as a possible cyber event before restarting?
- Does your incident plan cover bringing the process to a safe state without relying on the safety system?
How do you score it?
For each question, mark one of three answers: yes with evidence, yes without evidence, no. Treat "yes without evidence" as a no until someone shows a log, a diagram or a setting. A good result is not a perfect score. It is a short list with owners and dates.
NIST SP 800-82 Revision 3 covers OT threats, vulnerabilities and countermeasures, and ISA/IEC 62443 splits responsibilities among asset owners, suppliers, integrators and service providers. Use them to frame who owns each fix. Your controller vendor's advisories should settle product specific steps.
Where do software supply chain controls fit?
Firmware and engineering software are part of your supply chain. Ask suppliers for component lists, a patch process and signed updates. Store that information with the asset record, so an advisory can be matched to an installed version in minutes.
What to do
- Run the twelve questions with one OT engineer and one network engineer.
- Mark each answer with evidence or without.
- Fix network isolation and workstation access first.
- Build the firmware inventory and attach advisory feeds.
- Take a baseline of safety network traffic and set alerts.
- Store known good program copies offline.
- Add the unexplained trip rule to your incident plan and rehearse it.
Quick check
Does this checklist replace vendor guidance?
No. Product specific hardening and patch steps come from the controller vendor and from official advisories.
Why test for protocol traffic?
MITRE describes the framework communicating through TriStation, so unexpected use of that protocol is a useful signal.
Sources
- MITRE ATT&CK: Triton, S1009
- NIST SP 800-82 Rev. 3, Guide to OT Security
- ISA/IEC 62443 series overview
Last reviewed: 18 October 2026.
