The MITRE ATT&CK for ICS matrix names adversary behaviors across initial access, discovery, lateral movement, process control and impact. It is a vocabulary for planning and comparing a threat-informed exercise, not a report card by itself. A proposal that lists many technique IDs without a permitted test mode, observable event or decision criterion leaves the buyer unable to tell what was actually assessed.
Quick answer. Buy ATT&CK for ICS red-team coverage as a set of evidence-backed scenarios. For each selected technique, require a plant-relevant objective, written-authorized test mode, expected telemetry, analyst or operator decision, pass/fail rule and retest record. Keep active work at approved enterprise, identity, perimeter and DMZ boundaries; use a representative lab or tabletop for disruptive ICS behavior under NIST SP 800-82 Rev. 3. Stingrai can cover the human-led IT and boundary portion with the client's defenders, while OT specialists own controller-level scenarios.
This article is for critical infrastructure security leaders, plant operators and procurement teams deciding whether a proposed red or purple team engagement is useful and safe. It covers the exercise design and evidence. It does not claim that every ATT&CK technique should be attempted in production. The published Stingrai guide on grading MITRE ATT&CK coverage in a red-team proposal discusses the broader proposal problem; this guide applies the question to the separate ICS matrix and the operational boundary.
Why a coverage list can mislead a buyer
ATT&CK maps behaviors seen in the threat landscape. A technique may apply to several assets, routes and tactics. The appearance of an ID in a proposal does not tell you whether the provider will generate a benign event, inspect a configuration, run a lab exercise, or merely discuss a hypothetical consequence. Nor does a green detection claim prove that the right person saw the signal and made a useful decision.
The ICS matrix includes techniques for initial access and movement as well as behaviors that could inhibit a response or impair a process. Those latter categories have a different safety profile. A live test of a corporate VPN and DMZ jump host can be scoped and stopped using ordinary engagement controls. Suppressing a plant alarm or restarting a device is a different operational decision. NIST SP 800-82 Rev. 3 says penetration testing on OT networks should be used with care, points to replicated, virtualized or simulated environments, and warns that tests on non-OT networks must not propagate into OT.
That guidance makes the mode part of coverage. A report should not put "tested" beside an impact technique if the team only held a tabletop. A tabletop may be the right exercise and can still expose a real decision gap, such as an unclear plant shutdown authority or an alert escalation that ends at the IT help desk. State the mode honestly and evaluate the evidence that mode can provide.
MITRE updated several ICS technique pages on 13 October 2026, shortly before this article's research cutoff. The IDs below were checked against the live pages on 15 October 2026. That matters because techniques, descriptions and detection guidance change. Keep the link and date with the exercise plan rather than copy a static matrix into a contract and never revisit it.
Define coverage as an objective, not a count
A useful objective is framed in terms of a decision the owner needs to make. "Can the SOC identify an unexpected vendor login to the DMZ broker and notify the plant contact before approving support?" is assessable. "Cover T0822" is not. The former specifies the route, the observer and the decision; the latter names a technique but says nothing about how it will be evaluated.
The buyer should choose a small set of scenarios grounded in actual architecture and credible paths. A water utility with cellular-connected remote stations may care about exposure inventory. A manufacturer with many integrators may care about identity and vendor remote services. A site with shared operations workstations may care about whether remote service activity is attributable. Selection is a risk and operations decision. ATT&CK should organize the scope after the path is known.
Each selected scenario needs an authorized surface and a protected asset boundary. The external gateway, identity platform, enterprise workstation and DMZ broker may be live test surfaces when named in the rules of engagement. A controller, HMI, safety controller, industrial protocol and operational process remain outside active scope here. An owner-placed canary at the boundary can prove denial or alerting without traffic to a live control device. A lab can show how a representative alert behaves. A tabletop can test who acts on that alert and whether the process owner would permit a shutdown or isolation decision.
Figure 1: Original exercise-mode map for authorized live boundary tests, representative labs and tabletop decisions. Source for the production safety boundary: NIST SP 800-82 Rev. 3, CA-8.
ATT&CK for ICS red-team coverage and evidence matrix
This is an original buyer matrix. The MITRE links identify the behavior; the safe mode, acceptance criterion and evidence request are proposed by the author. They must be tailored to the owner's plant, documented architecture and signed rules of engagement. A "pass" means the agreed control outcome was demonstrated for the chosen scenario and mode, not that the site is immune to that technique.
Verified ICS technique and buyer objective | Authorized safe mode | Telemetry or record to request | Pass/fail proof | Retest evidence |
|---|---|---|---|---|
T0883, Internet Accessible Device: Are exposed remote assets known and owned? | Compare public inventory with approved asset register; bounded external validation for named addresses only. Do not query production controllers. | Asset register, gateway inventory, external exposure observation, change ticket. | Pass when the observed route is approved and owned; fail for an unexplained public path. | Updated register and repeat narrow exposure check with the same asset scope. |
T0822, External Remote Services: Does an outside vendor reach only the intended entry point? | Prearranged positive and negative cases at an authorized gateway using supplied test identities. | Sign-in, MFA, gateway, source and time logs; any locally required gateway alert. | Pass when approved access works, unapproved access is denied and a pre-agreed local signal reaches an analyst; fail on an unintended route or a missing signal required by the buyer-defined rule. | Same source and test account, new policy version, gateway decision and analyst disposition. |
T0859, Valid Accounts: Are identity rights and reuse contained? | Review role mapping; bounded test with dedicated low-privilege identities against IT or DMZ canaries. | Identity roles, token or session record, denial log, account owner. | Pass when a supplier identity cannot inherit a broader role or move to a canary; fail when rights exceed the approved job. | Revised entitlement and repeat allowed and denied cases. |
T0840, Network Connection Enumeration: Can defenders recognize unapproved host-level discovery? | Use a representative Windows or Linux lab host, or review existing endpoint telemetry. No live OT enumeration. | Endpoint event, account role, asset baseline, analyst note. | Pass when the event is correctly distinguished from approved engineering or inventory work; fail when role context is missing. | Replayed lab event and analyst decision with an updated detection rule. |
T0846, Remote System Discovery: Is unexpected discovery at the boundary noticed? | Lab simulation or an owner-controlled IT-side canary under explicit rate and destination limits; no plant subnet sweep. | Boundary sensor, source and destination list, approved inventory, analyst triage. | Pass when unauthorized discovery scope is identified and triaged; fail when it is invisible or treated as ordinary maintenance without evidence. | Repeat canary or lab case with the same source role and detection window. |
T0886, Remote Services: Are remote hops between approved segments controlled? | Benign authorized session to a DMZ jump host and an IT-side canary; stop before live OT. | Broker session, authentication chain, firewall flow, analyst correlation. | Pass when the hop is attributable and an unapproved destination is blocked; fail when the path or identity is lost. | Corrected broker rule and same allowed and denied path traces. |
T0866, Exploitation of Remote Services: Would a remote-service weakness permit an unintended path? | Configuration and vulnerability review of approved IT/DMZ services; representative lab validation only. No production OT exploit attempt. | Version and exposure inventory, patch or mitigation record, boundary alert. | Pass when the route is controlled and risk is remediated or explicitly accepted; fail for a vulnerable exposed path without containment. | New version or rule record and repeated safe reachability or lab validation. |
T0878, Alarm Suppression: Would loss of a protection alarm be recognized and escalated? | Lab-generated synthetic alarm state plus tabletop with operators. No production alarm manipulation. | Lab event, alarm historian sample, operator decision record, escalation timeline. | Pass when the simulated discrepancy is noticed and the plant escalation path is followed; fail when no one owns the decision. | Repeated lab signal and documented operator response after procedure changes. |
T0881, Service Stop: Could service loss be distinguished from planned work? | Isolated lab service event and tabletop of operational response. No production service stop. | Lab service alert, maintenance schedule, SOC ticket, plant notification. | Pass when the team identifies the unexpected event and checks operational context; fail when it is ignored or misclassified. | Repeated lab event plus revised triage and plant contact record. |
T0816, Device Restart/Shutdown: Is the response authority clear for an unexpected device state? | Tabletop or isolated representative lab only. No live device restart. | Simulated device state, runbook, operator decision log, recovery plan. | Pass when responsible operators and decision thresholds are clear; fail when the exercise stalls on ownership or unsafe assumptions. | Second tabletop with the corrected runbook and named decision owner. |
The first rows exercise access and detection at a path the buyer can authorize. The middle rows examine movement and discovery where a representative lab or IT-side canary can carry the signal. The final rows address operational effect through evidence of preparedness and operator decisions. They should not be collapsed into one coverage score. A lab finding about an alarm workflow is a different kind of assurance from a production gateway denial. Both may be useful when labeled.
Distinguish ATT&CK behavior from the test action
For T0883, MITRE describes access through an internet-exposed device rather than a managed external remote service. The buyer's action can be an inventory comparison and narrow exposure validation. There is no need to authenticate to or probe a live controller to learn that an asset is unexpectedly reachable. Preserve the address ownership and approved communications profile so an intentional remote operations route is not marked as a finding solely because it is public.
For T0822, MITRE describes external remote services used for initial access, including vendor and internal engineering routes. The useful live test is whether the named route enforces identity, MFA, source policy and approval, and whether a prearranged unusual case is visible under a buyer-defined gateway rule. That entry-only rule is not MITRE DET0803: the current T0822 analytic requires a policy violation plus protected-asset access or another security-relevant follow-on event and suppresses approved support windows. This article does not send test traffic to protected OT assets. The related OT vendor remote access matrix gives a detailed buyer acceptance packet for this particular path. Here it is one part of a broader ATT&CK-informed exercise.
For T0859, a valid account can look normal to a perimeter device. The buyer needs role and entitlement context. A clean sign-in may still be wrong if the vendor account can reach another site's jump environment. Use dedicated test identities and canaries, and let the owner define which permissions are appropriate. An analyst should be able to explain the account's contract owner and expected support window, not just confirm that the password was correct.
For T0840 and T0846, MITRE's current detection guidance asks defenders to distinguish unauthorized discovery from normal SCADA, HMI, historian, inventory and engineering behavior. A lab host or a controlled IT-side canary is a good way to test the analytic and analyst without sweeping a plant subnet. The exercise should record the source role, target scope and expected baseline. An alert triggered by any unusual command or volume without operational context may create noise rather than coverage.
For T0886, an authorized remote service can become an unintended bridge if access controls are broad. The live portion can be a bounded session through a DMZ broker to an owner-controlled listener. A second, unapproved destination should be denied. The report should show both decisions, their logs and the identity chain. A route diagram without observed policy decisions is a design assertion, not validated control.
For T0866, the technique refers to exploitation of a remote service. A production ICS exploit is outside this guide's safe mode. A configuration and vulnerability review on authorized IT and DMZ infrastructure can identify an exposed path, while a lab can validate the representative behavior where needed. The result should say which boundary was reviewed and whether the plant's actual service is covered by the same version and rule set. Do not convert a lab finding into a claim about a production controller.
For T0878, T0881 and T0816, the safety mode is decisive. Alarm suppression, service stop and device restart can affect operational response and availability. A synthetic lab state can test a detector; a tabletop can test whether operators and security staff recognize the consequence and make a safe decision. The output is an evidence-backed process finding, not a claim that the live plant withstood a disruptive attack. The owner should decide whether any deeper OT assessment is needed under separate specialist control.
Collect telemetry that answers a decision
A raw log bundle is rarely enough. For each scenario, ask the provider to state the expected chain: the entry point or host event, the sensor or policy that should register it, the queue or screen an analyst watches, the context needed to distinguish maintenance from suspicion, and the action the analyst or operator should take. Timestamp and scenario ID tie these records together. A screenshot of an alert without the preceding event and analyst disposition does not establish that the defender process worked.
For access scenarios, preserve identity, MFA, gateway, broker and firewall records. For endpoint discovery scenarios, preserve host role and the approved maintenance baseline alongside the event. For a lab alarm scenario, keep the synthetic event and operator interpretation separate from any production historian data. For a tabletop, retain the inject, participants' decisions, escalation timing and any unresolved authority question. These are different evidence classes; label them accordingly.
MITRE's T0822 page couples a remote-access policy violation with protected-asset access or another security-relevant follow-on event before its operational-fidelity gate calls for an alert. Its T0886 page maps remote-service movement. The proposed live gateway case is a narrower buyer-defined rule: check whether the owner has source and timing data and whether analysts can use it, without claiming MITRE DET0803 coverage. An ATT&CK detection section is a hypothesis for local design, not proof from an entry event alone.
The test team and defenders may run a purple team exercise together or a red team scenario with limited notice. The buyer should agree which one applies. A purple exercise can spend more time tuning a rule and repeating the same benign signal. A red exercise can reveal whether the process works without coaching. Both need the same final evidence: what was observed, what decision was made, what changed and what happened on retest. Stingrai's purple teaming service aligns with that joint defender work.
Figure 2: Original evidence chain from a selected ICS technique to objective, observation, decision and retest. Sources for technique mapping and test planning: MITRE ATT&CK for ICS and NIST SP 800-115.
A proposal rubric that resists inflated coverage
A buyer can evaluate each proposed scenario across five fields: relevance, safe mode, observable signal, defender decision and retest plan. The scenario should remain out of scope until all five are filled. That rule avoids a technique count that rewards labels instead of outcomes. The exact pass threshold belongs in the contract, since one site may accept a tabletop for a high-impact behavior while another has a dedicated test rig and wants lab evidence.
Relevance asks why the technique matters to this architecture. The provider should identify a real trust boundary, role or operational process. A generic entry in the ICS matrix is insufficient. Safe mode identifies which action is live, reviewed, lab-only or tabletop and who can stop it. Observable signal lists the sensor and event expected, including whether the data is available to the SOC. Defender decision names who must triage, escalate or authorize a response. Retest plan states how the same scenario will be repeated after a fix.
Ask the provider to label the outcome as demonstrated, partially demonstrated, reviewed, simulated, not observed, or not tested, then attach the evidence. These labels are an editorial proposal, not MITRE scoring categories. "Not observed" needs investigation: the test event might have failed to generate, a sensor might be blind, or the analyst might not have seen it. Do not convert it automatically into a detection failure without checking the test conditions.
A scope can be valuable even if it contains fewer techniques. A short scenario chain that starts at a supplier gateway, confirms least privilege at the DMZ, and ends with an analyst calling the plant contact can show how several controls work together. A longer list of disconnected technique IDs may leave those handoffs untested. The red team rules of engagement buyer checklist explains the authorization and stop conditions a buyer should require before the exercise starts.
Example: a synthetic water-site scenario
Consider a fictional regional water operator that uses a managed remote access gateway for equipment support. The OT team approves one supplier role to reach one diagnostic host during a maintenance window. The security team wants to know whether an unexpected supplier sign-in is denied, whether the broker records an approved session, and whether the SOC contacts operations when a session arrives outside the expected window. No client system or observed outcome is represented here.
The authorized live phase uses a dedicated test identity and a named gateway. A positive case confirms the approved route. A negative case with a separate unapproved role should be denied before the diagnostic host. A benign unusual-time event is coordinated in advance with the operator and monitoring team as a buyer-defined gateway monitoring check, not a validation of MITRE DET0803. The evidence includes the approval ticket, identity and MFA decisions, gateway and broker events, and analyst disposition. The route stops at an IT or DMZ asset; no controller receives test traffic.
A lab phase represents a lost protection alarm, using a synthetic event rather than a production alarm change. The SOC and plant contact describe how they would validate the condition and protect the process. The tabletop then presents a simulated loss of a service and asks who has authority to isolate remote access and who tells the shift operator. A useful report keeps the live gateway control outcome separate from the lab detection observation and tabletop decision record.
Suppose the unapproved role is denied but the analyst cannot link the buyer-defined gateway alert to the support contract owner. That is a partial result, not a blanket failure of the gateway. The remediation may be a supplier-to-identity mapping and an updated triage field. A retest repeats the benign unusual-time case and asks the analyst to identify the owner and contact path using the revised record. The scenario stays synthetic here; the acceptance criteria illustrate how a buyer can demand precise evidence.
Safety and authorization belong in the contract
NIST SP 800-82 Rev. 3 remains the final publication at this research cutoff; a Rev. 4 initial public draft was open for comment. The final guide's CA-8 OT discussion says a replicated, virtualized or simulated system may be used for penetration testing, production OT may need to be offline for testing, and non-OT tests need extra care to avoid propagation. This article adopts the conservative boundary of live activity on the IT and perimeter side unless a separate OT specialist plan is approved.
The rules of engagement should name every live IP range, tenant, test identity, gateway, broker, canary and monitoring contact. They should list industrial assets and protocols excluded from active work, the maintenance and stop windows, the operational authority and the communication plan. The test team should be able to explain how it will recognize an unexpected plant route and cease activity. A broad authorization to test "the network" is not specific enough for a converged IT/OT environment.
NIST SP 800-115's technical testing guide emphasizes planning, performing tests, analyzing findings and developing mitigation strategies. In an OT-adjacent exercise, that sequence should include the plant owner from the beginning and preserve the mode of each observation through remediation. A lab result may justify a production policy review without authorizing a production exploit.
A supplier contract should also say who owns the evidence, how sensitive system details are redacted, when a confirmed finding is reported, and who can approve a retest. A provider that offers a dramatic scenario but cannot describe the evidence and stop conditions has not made the proposal reviewable.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing services company founded in Toronto. Its human-led red teaming, purple teaming, internal and external network testing, and Active Directory testing can assess authorized enterprise, identity and IT/OT boundary paths with the client's SOC. The human-led engagement uses two named penetration testers, reports confirmed findings in the PTaaS portal as they are found, and includes retesting. One-time annual engagements and continuous programs are available according to the buyer's scope.
For an ATT&CK for ICS brief, Stingrai's role is the human, network and detection chain leading to the plant boundary. A qualified OT specialist and the plant operator should design and own controller, HMI, safety-system and industrial-protocol lab work. The proposal should identify those roles explicitly, so the buyer knows what each team will demonstrate and where the evidence comes from. Stingrai's testing can support a compliance program and produce evidence for an audit, but the acceptance criterion remains the buyer's own operating policy.
FAQ
How should a buyer evaluate MITRE ATT&CK for ICS red-team coverage?
Evaluate each selected technique against a plant-relevant objective, authorized safe mode, expected telemetry, defender or operator decision, pass/fail rule and retest evidence. An ID in a proposal is a reference to behavior, not proof that the behavior was safely tested or detected.
Is a high count of ATT&CK for ICS technique IDs a good red-team score?
No. A count can hide shallow coverage, mismatched techniques and unsafe test assumptions. A smaller set of relevant scenarios with observable decisions and repeatable evidence is more useful for procurement than a long unqualified list.
Can an ICS red team run live alarm suppression or device shutdown tests?
Those behaviors can affect operations and require a separate OT-led decision. In this matrix, alarm suppression, service stop and device restart are evaluated through a representative lab or tabletop only. Live work remains on written-authorized enterprise and boundary surfaces.
What is the difference between T0822 and T0883?
T0822 covers external remote services such as managed gateway routes used for initial access. T0883 covers internet-accessible devices exposed directly rather than through those managed services. The buyer should test the approved gateway route and separately compare public exposures with the asset inventory.
What evidence should a purple team return for an ICS technique?
It should return the approved scenario, the generated or reviewed event, the relevant sensor and policy records, the analyst or operator decision, the finding with its scope limit, and a repeat of the same case after remediation. It should identify whether the observation was live, lab, review or tabletop.
What part of an ICS exercise can Stingrai perform?
Stingrai can run human-led red, purple, network and identity scenarios on authorized enterprise and IT/OT boundary systems, with the client's defenders and retesting. Controller, HMI, safety-system and industrial-protocol work should be designed and owned by the plant OT team or an OT specialist.
Related reading
Primary sources and method
The technique names and IDs come from the live MITRE ATT&CK for ICS matrix and the linked MITRE technique pages, read on 15 October 2026. The safety boundary follows NIST SP 800-82 Rev. 3; the planning and evidence cycle follows NIST SP 800-115. The matrix, proposed outcome labels and synthetic scenario are editorial tools for buyers. They are not MITRE coverage scores or claims about a client environment.
Talk to Stingrai
Stingrai can help scope a human-led, threat-informed exercise at the enterprise and IT/OT boundary, including detection collaboration and retest evidence. Get a Quote or book a free discovery call.
