Part of the FAIR Analysis: Factor Analysis of Information Risk. Start there for the wide view, then come back here for the close-up.
Industrial engineering improves cybersecurity resilience by handing security teams a toolkit that plants have trusted for decades: failure mode analysis, reliability math, statistical process control and engineered redundancy. Each tool turns a vague worry into a number you can rank, track and put in front of a budget committee. Each one also carries a quiet assumption that failures happen by chance. Attackers do not happen by chance. The whole trick is keeping the tool and patching the assumption.
Availability = MTBF ÷ (MTBF + MTTR)
Mean time between failures on top, total cycle time underneath. Security work can push MTBF up (fewer incidents) or MTTR down (faster recovery). Recovery is usually the cheaper lever, and it is the one attackers cannot vote on.
| Industrial engineering tool | What it measures on the plant floor | The FAIR factor it feeds | The patch for an adversary |
|---|---|---|---|
| FMEA | Severity, occurrence and detection of each failure mode | Loss Magnitude (severity), Vulnerability (detection) | Rank by severity first; an attacker picks the occurrence |
| Reliability math (MTBF, MTTR) | How often a line stops and how long it stays down | Loss Event Frequency, Productivity and Response loss | Test recovery against a deliberate, repeated outage, not a single random one |
| Statistical process control | Whether variation comes from chance or an assignable cause | Vulnerability, via detection speed | Watch for drift and patterns, not only points outside the limits |
| Redundancy and backup | Spare capacity when a component fails | Loss Magnitude, via Replacement and Productivity | Make the spare different and separately protected, or it fails with the primary |
Why Plant Tools Need an Adversary Patch
NIST says it plainly in its guide to cyber-resilient systems: "There is no reason in resilience engineering to attempt to 'mislead' a hurricane." Safety and reliability disciplines were built against weather, wear and human slips. None of those read your maintenance schedule. An attacker does, then shows up the week the spare pump is out for service.
That same guide (NIST SP 800-160 Volume 2 Revision 1) frames cyber resiliency as four goals: anticipate, withstand, recover and adapt. Industrial engineering already owns the middle two. The upgrade is teaching them to expect a thinking opponent.
FMEA: Rank by Consequence, Not Odds
A classic Failure Mode and Effects Analysis scores every failure mode on severity, occurrence and detection, usually 1 to 10 each, and multiplies them into a Risk Priority Number between 1 and 1,000. The automotive world codified the modern version in the AIAG & VDA FMEA Handbook, which walks teams through a seven-step process.
The occurrence score is where a cyber FMEA goes sideways. A bearing fails at a rate you can look up. A remote access account gets abused at whatever rate an adversary finds worthwhile, and a low occurrence score is exactly the kind of quiet corner they like. So keep the worksheet, but sort by severity before you ever multiply. A failure mode that could stop the line or hurt someone stays on the top of the list even if nobody has seen it happen yet.
| FMEA column | Random failure reading | Cyber reading |
|---|---|---|
| Severity | Consequence if the part fails | Consequence if the function is deliberately misused |
| Occurrence | Historical failure rate | Attacker interest times exposure; treat as unknown for high-severity modes |
| Detection | Chance the fault is caught before it escapes | Chance your monitoring catches someone actively hiding |
MTTR Is a Loss Magnitude Lever
Reliability engineers obsess over mean time to repair because downtime is money leaving at a steady drip. FAIR counts that drip under two of its six forms of loss: Productivity (you cannot ship) and Response (you are paying people to fix it). Shrinking MTTR cuts both, and it works no matter who caused the outage.
Here is how the arithmetic plays out on an illustrative plant. The numbers are made up to show the mechanics, not pulled from a survey.
| Illustrative scenario | Outages per year | MTTR | Downtime hours | Productivity loss at $5,000 an hour |
|---|---|---|---|---|
| Restore from untested backups | 2 | 72 hours | 144 | $720,000 |
| Rehearsed recovery runbook | 2 | 24 hours | 48 | $240,000 |
Same attackers, same frequency, two thirds less loss. That is the pitch that gets a recovery drill funded, and it drops straight into a risk versus cost budget.
Control Charts and the Attacker Who Stays Inside the Limits
Statistical process control draws a center line and two control limits around a process. The NIST/SEMATECH e-Handbook explains that with 0.001 probability limits, a point lands above the upper limit by chance only one time in a thousand, so a point outside the lines is a strong hint of an assignable cause.
Pointed at security telemetry (failed logins, outbound traffic, PLC write commands), control charts are a lovely early warning for noisy problems. A careful intruder is not noisy. They keep their activity inside the limits on purpose. The fix comes straight from the quality textbook: watch for runs, trends and slow drift, and chart the things an attacker has to change to reach their goal, such as configuration writes and new accounts, rather than only volume.
Redundancy Is Not Resilience Until It Is Diverse
Engineers add a spare so one failure does not stop the line. NIST warns that backup, surplus capacity and replication "are not sufficient to protect against the APT." An attacker may target the backup servers themselves, and a remote backup built on the same architecture as the primary can fall to the same malware.
The plant-floor instinct still wins with one change: make the spare different. Separate credentials, a different platform or an offline copy means an intruder has to beat two unlike defenses instead of one defense twice. NIST makes the same point about integrity checks: a cyclic redundancy check catches accidental corruption, but only a cryptographically signed hash holds up against someone who can recalculate the checksum.
Cyber-Informed Engineering: Design the Consequence Out
"We need to ensure that cybersecurity is synonymous with reliability and safety in standards development working groups and in the hallways of engineering colleges..."
Puesh Kumar Director, Office of Cybersecurity, Energy Security, and Emergency Response, U.S. Department of Energy, in the National Cyber-Informed Engineering Strategy (June 2022)
Cyber-Informed Engineering is where industrial engineering and security stop being roommates and get married. The Department of Energy strategy opens with Consequence-Focused Design: find the functions where cyber manipulation could cause unacceptable consequences and engineer them out, often with physical or process controls that no amount of malware can argue with. Its Planned resilience with no assumed security principle is the adversary patch in one line: expect any digital component to be compromised at some point, and plan to keep running.
The Twelve CIE Principles, Plant Edition
| Principle | Group | What it asks an engineer to do |
|---|---|---|
| Consequence-Focused Design | Design and operational | Protect the functions whose misuse would be unacceptable first |
| Engineered controls | Design and operational | Use engineering and process changes early, reducing bolt-on IT controls |
| Secure information architecture | Design and operational | Make data flow only in the directions you intend |
| Design simplification | Design and operational | Remove high-consequence, low-value complexity and latent features |
| Resilient layered defenses | Design and operational | Assume compromise; add diversity, redundancy and predictable degradation |
| Active defense | Design and operational | Detect intruders and isolate them without stopping critical operations |
| Interdependency evaluation | Organizational | Bring safety, quality and maintenance into the misuse analysis |
| Digital asset awareness | Organizational | Keep a complete inventory of hardware, firmware and software |
| Cyber-secure supply chain controls | Organizational | Write security requirements into procurement and contracts |
| Planned resilience with no assumed security | Organizational | Plan for operation during and after an attack that degrades digital controls |
| Engineering information control | Organizational | Protect drawings, specs and configurations that would help an attacker |
| Cybersecurity culture | Organizational | Use cross-functional teams and continuous training |
Plugging the Numbers Into FAIR
FAIR prices risk as Loss Event Frequency times Loss Magnitude. Industrial engineering fills in both halves with data your operations team already collects, which is the rare security project that starts with a spreadsheet already half done.
Where Plant Data Lands in a FAIR Scenario
| Plant data you already have | FAIR input | Adversary adjustment |
|---|---|---|
| Downtime logs and MTTR by line | Productivity loss, Response loss | Add the time to confirm the attacker is gone before restart |
| Hourly contribution margin | Productivity loss per hour | Include the cost of running in a degraded manual mode |
| Spare parts and rebuild quotes | Replacement loss | Price the case where the spare is compromised too |
| FMEA severity scores | Loss Magnitude ranking of scenarios | Keep high-severity modes even with no incident history |
| Control chart alarm history | Vulnerability, through detection capability | Discount detection for low-and-slow activity |
| Customer penalty clauses | Fines and Judgments | Assume a deliberate outage lands at the worst time of quarter |
Frequently Asked Questions
- How does industrial engineering improve cybersecurity resilience?
- It brings structured tools (FMEA, reliability metrics like MTTR, statistical process control and engineered redundancy) that turn cyber risk into ranked, measurable numbers, then lets teams improve recovery speed and design out high-consequence failures.
- Can FMEA be used for cybersecurity risk assessment?
- Yes, with one change: an attacker chooses when to strike, so occurrence scores are unreliable for high-severity failure modes. Rank by severity first and treat occurrence as unknown when the consequence is serious.
- Is MTTR a security metric or an operations metric?
- Both. Every hour of recovery counts toward FAIR's Productivity and Response losses, so cutting MTTR lowers annualized loss whether the outage came from a worn bearing or ransomware.
- What is Cyber-Informed Engineering?
- A Department of Energy strategy for building cybersecurity into engineered systems from the earliest design phases, organized around twelve principles led by Consequence-Focused Design.
Industrial engineering will not stop anyone from trying. What it does is make a successful attack smaller, shorter and cheaper, and it gives you numbers to prove it. Plug those numbers into a FAIR analysis, and see how the attacks already hitting plants play out in our look at ransomware on the shop floor. If you want someone to run the recovery drill with you, our cybersecurity team would enjoy the stopwatch.
About Industrial Engineering in Cybersecurity
- NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems
- U.S. Department of Energy, National Cyber-Informed Engineering Strategy
- NIST/SEMATECH e-Handbook of Statistical Methods, What Are Control Charts?
- AIAG & VDA FMEA Handbook
- FAIR Institute, What Is FAIR?
NIST publishes the systems security engineering series, the Department of Energy's CESER office leads Cyber-Informed Engineering, and the FAIR Institute maintains the FAIR risk model.
Sources: NIST SP 800-160 Vol. 2 Rev. 1, DOE National Cyber-Informed Engineering Strategy (June 2022), NIST/SEMATECH e-Handbook, Section 6.3.1, AIAG & VDA FMEA Handbook, FAIR Institute, What Is FAIR?
