Skip to the lesson

Module 4 · Lesson 7 of 8 · 3 min

Choosing and Using the Framework Lens

0:00 / 5:48

Frameworks earn their keep when they turn a sprawl of devices and worries into a structured, comparable picture. For a facility that spans IT and OT, three complementary bodies of work do most of the useful work, and the skill is knowing what each is for.

The first is the family of adversary-behavior knowledge bases, most prominently the ATT&CK matrices. There is one for enterprise systems and a distinct one for industrial control systems. Each catalogs the tactics an adversary pursues — initial access, persistence, discovery, lateral movement, and, in the industrial matrix, control-system-specific goals like impairing process control and inhibiting the safety functions that would trip equipment to a safe state — and the concrete techniques under each. The value for a converged facility is precise: the enterprise matrix describes the front half of the campaign and the industrial matrix describes the back half, and laying them side by side gives you a single narrative of adversary behavior that crosses the IT-to-OT seam. When your IT team and your controls team both describe threats in this shared vocabulary, they can finally compare notes about one campaign rather than two disconnected worries.

The second is the risk-management and cybersecurity framework tradition, exemplified by the widely used cybersecurity framework that organizes a program around a handful of core functions — identify, protect, detect, respond, and recover, with governance threaded through. Its contribution is not a device list but a management scaffold. It forces the questions that infrastructure programs skip: Have we identified every asset and every connection, including the plant? Are our protections matched to the risk? Can we detect a quiet intruder? Do we have a response plan that includes operational technology and not just the IT help desk? Can we recover the plant, not just the servers? Used honestly, it exposes the gaps between the two halves of the building.

The third is the standards tradition built specifically for industrial automation and control systems, most notably the international series developed for that purpose. Where the cybersecurity framework is general, this body is OT-native. It codifies concepts this course has used throughout: dividing the plant into zones and defining the conduits that connect them, assigning each zone a target security level according to the threat it must withstand, and holding both asset owners and equipment vendors to defined requirements. Its most durable idea is defense in depth expressed as zones and conduits — decide what must be separated, define the controlled pathways between, and secure those pathways deliberately rather than hoping a single perimeter holds.

The mistake to avoid is treating any of these as a checklist to be completed and filed. A framework consumed as compliance produces a binder and a false sense of safety. A framework used as a lens produces a map. The difference is whether you turn the framework's categories back onto your own specific facility: your actual controllers, your actual IT-to-OT links, your actual vendor paths, rendered into the framework's structure so that exposure becomes visible and comparable.

The practical method is to combine the three. Use the standards tradition to define the zones and conduits — to decide how the plant should be partitioned and how each partition should be defended. Use the cybersecurity framework's functions to run the program around those zones — to make sure you are identifying, protecting, detecting, responding, and recovering across both IT and OT rather than only the former. And use the adversary matrices to red-team the result — to walk an attacker through your zones and conduits, tactic by tactic, and find the techniques you have not covered. Standards define the structure, the framework runs the program, the matrices test it against a thinking opponent.

One caution in the Mach register: frameworks are coordinate systems, not armor. They tell you where things are and give you a shared language to describe them; they do not themselves stop an intruder. Their power is that they let a divided organization see one surface. That shared sight is the precondition for everything in the final lesson, where the separate maps collapse into a single graph and prioritization becomes a matter of geometry rather than guesswork.