Discipline #1: Rules Before Tools - by Jason Rivera

SubscribeSign in

Touchstone<br>Discipline #1: Rules Before Tools<br>"If you can't describe what you are doing as a process, you don't know what you're doing."

Jason Rivera<br>Jun 09, 2026

Share

“Rules before tools.” Cabreza<br>W. Edwards Deming was the “father of the quality movement” who revolutionized modern business. With “If you can’t describe what you are doing as a process, you don’t know what you’re doing.” he promulgated thought and understanding of what you’re doing and why you’re doing it before you do it.<br>Consider the popularity of threat Defense within OT Security and the tool-first trend it has enabled.<br>To a point, the more threats and risks that owners and operators can see and block, the better protected they are. But threats, risks and Defense are not the arbiters of protection.<br>It’s an intentional trend which inevitably consumes the attention span of critical infrastructure asset owners and operators. This is what governance, culture, and operational discipline, not only to enable tooling but also a complete protection strategy, have to compete with.<br>Controlled Tool Defense

OT Security’s “Defense” ecosystem has become exceptional for the top tier and increasingly unachievable to everyone else. The K-shaped industry offering tool-secured programs or compromise has fueled a dogma culture:<br>Who are we using to secure us?

How secure are we?

How quickly do we detect bad guys?

How many assets do we see?

How many threats are we piping in to track?

Which gobbitygoop smacklepop bad guy is threatening me today?

According to Evgeny Morozov, “solutionism“ reframes complex social, political, and organizational problems as technical problems with clean technological fixes.<br>The fixes often ignore structural, political, and human dimensions and eliminate the highly valuable friction (ambivalence, opacity, deliberation) that come with them.<br>So rather than treat an improperly maintained network lacking change management rigor, invest in a network detection solution that will show you all the holes. Solutionism treats inefficiency, opacity, ambiguity, and friction as defects to be engineered away.<br>Charles Perrow claimed that in systems with interactive complexity and tight coupling, the conventional engineering response of adding more warnings and safeguards increases complexity and can actually create new categories of accidents (citing Chernobyl, where testing a new safety system helped produce the meltdown).<br>From a different angle entirely, research by Brynjolfsson, Hitt, and Yang (2002) found that financial markets valued each dollar of a firm’s computer capital as though it were accompanied by roughly nine dollars of complementary intangible assets, the organizational changes, process redesign, and skills that surround the technology.<br>The technology was the smaller share of what created value; the practice built around it was the larger.

Tangible to intangible capital value<br>Fragment in Depth

In broader cybersecurity terms, Defense means facing an adversary and holding the line. Defense, however, isn’t perfection - and never has been.<br>Today, Defense mostly operates as Defense in Depth, even in ICS/OT cybersecurity. Defense in depth is a cybersecurity and physical security strategy that uses multiple, overlapping layers of independent safeguards.

Image Source: Cloudmask<br>Defense in Depth also admits that no single defensive layer can defend on its own. And while any one layer may prove larger in defensive contributions than another, especially within a sector by sector and domain by domain (IT/OT/Cloud/etc.) construct, there’s a point within the depth where their defensive strength begins to fragment.<br>If you have no Defense at all, putting something in place may confer hefty benefits. If you’re layer upon layer of Defense, every tool begins to yield diminishing returns.<br>Defense in Depth should be approached through controls, so that if one layer fails, another catches the attack - and the structural pillars from which individual controls should be developed from are:<br>Administrative

Technical

Physical

Experience Over Expertise

I once deployed an OT detection platform to >20 manufacturing sites for a client who almost immediately disabled all alerting right after we finished.<br>The platform was fine and doing exactly what it was supposed to do. The organization wasn’t ready for any of what it was telling them.<br>The alerting policies were off-the-shelf, they had no classification of OT assets, process for asset to site attribution or even validation of the vendor’s alert, risk or vulnerability severities against their own.<br>Even if they had happened to sort all of that out, there were no escalation paths, change management queues or relationships in place to build any of it. So we turned it all off.<br>I tell that story because it explains why no critical infrastructure organization of any size should ever buy a tool first.<br>The thing about turning the lights...