Session
Engineering Out the Adversary: Applying Consequence-Driven Cyber-Informed Engineering (CCE)
Industrial control system security teams talk in CVEs, APTs, and threat models. Mechanical and electrical engineers talk in FMEA, margins, and safety factors. Value engineers track line items and budgets. Risk owners demand defensible compliance records. Each discipline does the right work in its own language, and the consequences that matter most sit at the blind handoffs between them.
Consequence-driven Cyber-informed Engineering (CCE) is Idaho National Laboratory's methodology for working backwards from the worst-case engineered consequence. It asks a singular question: can an adversary trigger that specific consequence through cyber means? CCE assumes breach by design. It prioritizes engineered and procedural protections that take the consequence out of cyber reach. Once those protections are in place, they hold whether the trigger is an adversary, an operator, a software bug, or an AI agent acting outside its envelope.
To demonstrate this, the session runs an accelerated CCE tabletop on a representative ICS system selected by the room from a curated list. The audience works through Phase 1 consequence prioritization and Phase 2 system-of-systems analysis, as we map the process from both sides of the aisle. We take the physical failure modes engineers care about and connect them to the attack paths security uses to reach them. By the end of the exercise, we produce what every CCE engagement yields: a functional block diagram highlighting choke points and engineered protection candidates.
The resulting diagram gives every discipline the same reference to work from. Each team sees functional blocks, trust boundaries, and attack paths without needing to be an expert in everything. The same artifact carries into traditional IT penetration testing, design review, and cost decisions, because it ties the argument to consequence rather than tool findings alone. The analysis handles the parts of OT where ownership and visibility break down, including the closed-source vendor devices the architect can only engineer around. The steps don't change. What changes the outcome is running them early enough to influence design, with the right people in the room.
Tyler Berube
Senior OT Platform and Security Engineer, Microsoft
Seattle, Washington, United States
Links
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top