A Tech Talk Tuesday conversation with Aaron Crow, former CTO of Industrial Defender
Some of the best conversations in this space happen when two people who have actually walked plant floors compare notes. This episode of Tech Talk Tuesday was one of those. Dan sat down with Aaron Crow, former CTO of Industrial Defender, and the two of them worked through three things: what industrial cybersecurity actually is, how someone breaks into the field, and what asset owners get wrong when they try to secure these environments.
Below is the discussion in written form for anyone who’d rather read than watch.
Aaron started where most of these conversations should start, which is with the business process instead of the technology.
There are a lot of things in the world that need to run. Power plants. Manufacturing lines. Water and wastewater treatment. And there are a lot of systems that make those things run. In that sense, it isn’t conceptually different from the automation in your house. The difference is consequence. Your smart bulb turning on is not the same as a generating unit staying online or a fill line running to spec.
OT security, then, is about protecting business processes that have been automated. Somewhere along the way, a person stopped walking out to turn a valve by hand, and a controller started doing it instead. That change made the process faster and cheaper, and it also dragged every networking and cyber concern along with it into a world that used to be analog and manual.
As Aaron put it, the question is how you address the cyber issues while still letting the business get the benefit of the automation. Those two goals are not in conflict as often as people assume, but they do require someone in the room who understands both.
Dan made a point here that’s worth sitting with if you’re new to OT.
Look at the history of the programmable logic controller, the Lego brick of the modern factory. Early Modicon PLCs came out of the auto manufacturing industry. Before them, everything was hardwired. Literal wires ran point-to-point between systems so signals could be switched. Then PLCs arrived, and suddenly a computer was making the decision instead of a relay panel.
Those first generations talked over serial. No network stack, no Ethernet driver, no concept of a hostile network. The protocols were designed for a simpler time.
Then, as Aaron described it, a lot of OEMs did the straightforward thing. They kept the same protocol logic, swapped out the medium, and dropped an Ethernet converter in front of it. Same messages from the 1960s and 1970s, now riding IP over CAT5, crossing switches and routers and traveling much longer distances than anyone originally intended. A huge amount of what you’ll find in the field is still serial, 4 to 20 milliamp, hardwired lineage with a newer interface bolted on.
This is why industrial protocols are so much fun to poke at. They were never designed to be poked at.
How Real Is the Threat?
Dan raised the hype question directly. Stuxnet gets invoked constantly, there’s a lot of venture money flowing into the space, and every vendor has a story. So how legitimate is the risk, and where does it concentrate?
Aaron’s answer wasn’t about exotic malware. It was about lifecycle.
IT replaces laptops every couple of years and servers on a three-year cycle. That’s budgeted, expected, routine. OT has always run on 10, 15, and 20 year lifecycles, and the equipment was engineered for exactly that. When a plant was built, the components were specified to live in that plant for two decades. So the gear you find is old because it was designed to be old, and because in an environment where uptime is the whole point, “if it ain’t broke, don’t fix it” is a completely rational operating philosophy.
Aaron was blunt about what that looks like on site. Windows XP. Windows NT. Sun Microsystems boxes. Thirty-year-old technology running critical infrastructure today. If you haven’t seen it, it’s genuinely startling the first time.
Layered on top of that is the IT/OT convergence push, which isn’t a new term but is still an active process. The business wants more data out of its systems, wants to run leaner, wants efficiency. Every one of those enhancements adds complexity, and complexity adds exposure.
And here’s the part worth repeating to anyone who thinks they’ve solved this by unplugging: air gapping removes one attack vector, not all of them. Sneakernet is real. Supply chain risk is real. Aaron described a pattern our team sees constantly, where something breaks, the process has to come back up, and somebody drives to the nearest big box store for a switch or a USB drive. Nobody in that moment is thinking about firmware provenance. They’re thinking about getting the line running.
The staffing asymmetry is the thing that doesn’t get enough airtime.
On the IT side, you have network admins, firewall admins, patch and test teams, threat hunters. Whole functions dedicated to security work. On the OT side, most of the time, you have engineers. Aaron was careful here, and rightly so: it isn’t that those engineers are less capable. It’s that securing the environment is not their job. Their job is making sure the plant runs, and the widget gets made, whether that widget is an electron or a can of Coke.
So this stops being a technology problem pretty quickly. It becomes a question of who you have, where you need them, and what they should actually be doing.
Dan brought up a question a plant manager once asked him after a threat-hunting talk, and it’s a fair one. What’s the cost of just not doing this? Every control you fund is a control you funded instead of something else.
Aaron worked through it with an unregulated manufacturer as the example, since anyone under NERC CIP doesn’t get to ask the question.
A modern manufacturing facility has automation. Rockwell PLCs on an Ethernet network, some switches, a firewall. There’s usually some baseline of something, because the vendor came in, said you need all this stuff, and deployed it. But deployment isn’t capability. Aaron’s analogy: his garage is full of tools, and if nobody knows how to use them and nobody takes them out, they do exactly nothing for him. You can buy the best tools in the world and get zero value from them.
So the risk of doing nothing breaks down into three buckets:
Dan also cleaned up a common misconception here. Colonial Pipeline is cited constantly as an OT attack, and it wasn’t. The billing system got hit. Once they couldn’t bill for product moving down the pipeline, they weren’t going to keep shipping it for free, so everything came down. The business consequence was enormous. The mechanism was not a compromised controller.
Dan asked how you end up as CTO of a vendor in this space.
Aaron’s answer starts in high school with a TRS-80, moves through a small school for electrical engineering, and runs through a stack of part-time technology jobs along the way. Desktop admin first, then networking, then servers, then architecture. One of his early roles was server administration at a power utility in the Amarillo area.
Later he landed at another Texas utility, TXU, where his father had spent nearly a 38-year career. He grew up around power plants and the people who worked in them, which turns out to matter a lot later.
He was hired to do one thing, and then somebody told him the company needed to do more on the OT cyber side beyond NERC CIP compliance, and since he had the network security background, he was it. Nobody called it OT cybersecurity at the time. It was just work that needed doing. Ten years later, he’d built a full OT program, then took that experience to one of the Big Four to do it at scale across many clients, and then to Industrial Defender.
Dan connected this to a pattern he’s seen repeatedly on engagements: the person in charge of cybersecurity at a site turns out to be an electrical engineer who drew the short straw and got told to go do all that cyber stuff. Great people to work with, and often people who need a little more support on the security side than their title suggests.
That’s a real strength of this field, though. You need everybody in the room. An electrical engineer sees the system completely differently than someone who came up through a computer science program or through IT operations, and both views are load-bearing.
For anyone making the transition, Aaron’s advice was refreshingly unglamorous.
When he was staffing his first OT program a decade ago, you could not search LinkedIn for OT cybersecurity experience. The term didn’t exist. So he recruited a close friend who’d spent his entire career in IT, had never set foot in a power plant, and didn’t know what OT stood for. What that friend could do was troubleshoot, and he understood switches, firewalls, and routing.
That works because OT runs on the same technologies IT does. Firewalls, servers, routing, virtualization. The difference is how you use them and how hard you can push them. You still need to patch, but you may not patch on the same schedule, or at all, and you may have to mitigate in a different way instead.
The other half of Aaron’s answer was about trust, and it’s the part people skip.
The reason he’s been effective is that he understands the business process. When he talks to a plant engineer, he can explain the technology and the cyber concepts in a way that doesn’t make that engineer feel stupid, and more importantly, in a way that demonstrates he isn’t going to break anything. The engineer needs to believe that the person recommending a change actually understands the process that change will touch.
One of his mentors told him years ago that all business is the people business. Janitor, CEO, or programmer who never leaves the basement, you still have to work with humans. Relationships and business process understanding are the two things that get you into this field and keep you moving in it.
This one’s harder, and both of them acknowledged it.
Aaron had just read an article about entry-level postings on job boards that list ten-plus years of experience as a requirement. That is not an entry-level position, and pretending otherwise wastes everyone’s time.
His practical advice for someone coming out of school or out of high school:
Dan added a dimension that matters more than people expect. This is still a physical field. Plants are not downtown, and they’re not in the Bay Area. Power plants sit in the middle of nowhere partly because nobody wants one next door. Being open to relocation, especially early in a career, opens doors that stay closed for remote candidates. That might mean a few years somewhere like Beaumont, or rotational shift work in Western Australia, flying out for two or three weeks at a time.
Aaron agreed and extended it internationally. Dubai and the broader UAE are fighting for qualified people. And working for a large consultancy with genuine entry-level roles comes with a heavy travel requirement, but it also exposes you to far more environments than a single local job would.
The hard truth underneath all of this: trust is difficult to build remotely, and in this field trust is the currency.
Here’s where the conversation earned its keep. Aaron, the CTO of a company that sells software in this space, said the biggest mistake is buying a tool before you’ve defined the problem.
His analogy: something’s wrong with your car, you don’t know what it is, so you buy new tires. Maybe you did need tires. Your fuel pump is still going bad.
In OT, it’s worse, because so many sites genuinely do not know what they have. Our team sees this on nearly every assessment. Either there’s no asset inventory, or there’s an inventory scattered across a spreadsheet here, a SharePoint site there, some of it on Bob’s laptop, and the rest of it with Steve. No single authoritative place.
So when Log4j lands, or a vulnerability drops on a specific PLC family, the first question isn’t how do we fix it. The first question is how many do we have, and where are they, and who do I call to find out? That discovery process burns days or weeks before anyone can change a firewall rule, push a patch, or send a tech out to touch a configuration.
Building a security program without that baseline is building a house before you’ve poured the foundation.
Aaron pushed back on the shallow version of inventory, and this is the part most teams underrate.
It’s hard to know what bad looks like if you don’t know what good looks like. And knowing good means more than a hostname, a model number, a firmware version, and Bob as the listed owner. You also need:
Aaron’s suggested method for the connectivity layer is essentially a tabletop. You know what your assets are and where they live. Now walk through how they work together, because in his experience no single person holds all of it. One person knows where everything is. Another understands the business process. A third understands the technology. Sometimes that’s one very valuable individual; usually it’s three.
Then zoom out. If you’re a corporation with 50 sites, or hundreds, or thousands, you need that same conversation at every one of them. The problem scales badly.
Dan made the technical point that ties directly to what our team does every day.
In IT, you can get a lot of value from boundary monitoring. In OT, boundary monitoring alone will lie to you. If you’re trying to capture traffic between an engineering workstation capable of changing a PLC and the PLC itself, and your collection point sits at the environment boundary, you will never see that exchange. Both endpoints are inside.
This is where “we deployed a solution” and “we have visibility” quietly diverge. Teams drop a sensor in at a convenient point, check the box, and then discover the asset inventory is empty, because none of the protocols carrying the asset data they wanted are traversing that link. They were sold the grand vision and didn’t have enough engineering input to identify the point in the architecture where the information actually lives.
Getting collection into the right places, below the boundary and close to the process, is most of the battle. It’s also the reason our assessment work usually starts with architecture and capture point selection rather than with software.
Aaron described the two patterns he sees, and they’re mirror images of each other.
The board or corporate IT leadership buys a tool and pushes it down to the plants. The OT side doesn’t understand it, wasn’t consulted, and doesn’t trust corporate. So they refuse to let it into the areas where it would do the most good. Now the organization is monitoring what it believes is OT, but it’s really just the boundary, and it isn’t seeing much of anything. The process owner’s position is entirely defensible from where he’s sitting: you’re not bringing that into my environment, I haven’t tested it, my vendor doesn’t like it, and I don’t know anything about it.
The site’s controls vendor sells them a suite. It gets installed, it works, and then the vendor leaves. Nobody is left to own it. The asset inventory that tool built is accurate on day one and stale by month three.
Both scenarios end with technology that didn’t solve the problem, and in neither case was the technology incapable of solving it. The failure was that neither side talked to the other. The plant team should have asked IT who’s going to own this after the vendor drives away. IT should have opened with a request to work together so the coverage extends past the boundary into the gray middle where all the interesting traffic lives.
Dan’s addition here is the honest one: if your asset identification maturity is low or nonexistent, the first pass is going to be manual and painful. Accept that up front, because teams that let perfection get in the way of the first step never take it.
Some practical starting points from both of them:
Start with a spreadsheet. Aaron kept coming back to this. An accurate inventory in Excel beats an expensive tool with no owner. You do not need to buy anything to begin.
Go get the drawings, then verify them. Pull the P&IDs and other plant design documentation, then physically walk the plant and confirm. This device is here and actually connected. This switch is here, and I know where those Ethernet runs terminate. The drawings and reality diverge more than anyone would like.
Talk to the engineers and operators. Dan noted that some of the biggest wins on red team engagements have come from asking operators who’ve been on site 15 years how they’d break the process, what happens if this area goes down, and what keeps them up at night. Watch for bias in the answers, but those conversations point you at good starting places you’d never find in a diagram.
Check what you already own. Several OEMs have built genuinely good asset identification into their platforms, and you may already be paying for the license. Aaron pointed to Honeywell’s acquisition in this space as an example, and if you’re running Experion, native asset ID over the proprietary protocols can move your maturity up a level without new spend.
Then find the gaps the OEM tools won’t cover. This is the important caveat. A Honeywell solution covers Honeywell. Emerson covers Emerson. Same for Foxboro, Rockwell, and the rest. The third-party systems sitting outside those ecosystems are the ones nobody accounts for.
Aaron drew the Target comparison here. Target didn’t get breached directly, a subcontractor did. It’s usually the small thing outside the standard that becomes the way in. Same dynamic in OT. Everything is fine, everything’s on the DCS, except that one device over there that nobody seems to know about, and Bob’s on vacation and he’s the only one who understands it. So it gets ignored. And then it turns out to be the back door, connected straight through to the control system and around every firewall and control that was just carefully deployed.
You cannot boil the ocean, and Aaron didn’t pretend otherwise. At a corporate level, the long game is building an actual program: what we intend to do, which asset types, which site types, in what order, and how fast.
The funding piece is where he got specific, and this is the kind of detail that comes from having actually run one of these. Capital is relatively easy to get. The O&M tail is the hard part. That ongoing care and feeding of both the technology and the people is what determines whether your asset management effort still exists in three years or died on the shelf, forcing you to start the whole thing over in five. He sees the restart cycle happen a lot.
Asked where the highest value, lowest hanging fruit sits on the people side, Aaron’s answer was consistent with everything else he’d said. Go talk to the plant engineers and operators. Those are the people who know where the bodies are buried. They know how the process works; they may have helped build it, they walk it every day, they put hands on the equipment, and they know intimately what it looks like when it breaks.
His analogy: you take a Toyota to a Toyota mechanic. Take it to a Chevy shop, and you’ll still get a good mechanic, just one without the specific experience. He’ll figure it out. It won’t be as fast.
So the work is cross-training and conversation. Get your IT and security people out to the sites. Not for a tour. Have them spend a day with an operator, walk the plant, understand how the job actually gets done, and why the things that are easy in IT are difficult here. Once they’ve done that, they design controls and write policies that account for reality, and they stop trying to push IT policy down into an OT space and expecting it to work.
The obligation runs both directions. The OT side can’t hold the position of “I’m disconnecting, you’re not allowed in my world, don’t talk to me.” Both sides have to give up some ground.
Aaron’s framing was a football team. Quarterback, linemen, defense, all different roles, one team, one playbook. If you’re pass blocking and I’m running behind you, we both need to know the play.
Dan added a note on the term itself. He’s never loved “IT/OT convergence,” because the phrasing creates an us versus them dynamic. In a mature program, plant data may well flow up to a centralized SIEM that only the SOC analyst touches, sitting organizationally above the plant. He knows of a company running two incident responders for more than 200 plants. That’s the reality the communication problem sits inside.
Tabletops and Threat Hunts That Are Actually Tailored
Both of them landed on tabletop exercises as the highest value proactive activity, with one strong caveat.
General awareness tabletops have their place. Dan and Aaron ran one together in Austin focused on rail security, and Dan’s run them at DEF CON, and those are good for broad education. But the exercise that changes outcomes is the one built for your specific plant and your specific process.
The scenarios that matter are the 2 a.m. ones. The plant is suddenly down. What are the situations that keep you up at night, and what happens next?
And the value isn’t only technical. Who are you calling at 2 a.m.? Who are you waking up? Dan drew on his time at the Air Force CERT, where there was a defined threshold for when you wake up a three- or four-star general over a security event. You need to know where that line is. If you’re a regulated entity, you need it even more, because missing an incident response or reporting requirement carries fines that can accrue by the day.
Threat hunts serve double duty here. Get your incident responders out doing hunts at the plants so they know what the environment looks like, their boots are dirty, they know the people, and the plant manager trusts them. That trust is what makes or breaks a real response, when stress is high and people are tired and nobody’s slept.
Dan mentioned one engagement he enjoyed: playing in GridEx alongside a retainer customer that had never brought a third party IR firm into an exercise before. They wanted to know what it actually looks like and what their people would do when the scenario hit them. That’s the right instinct.
Asset inventory work has the same secondary benefit. Do it well, and you start seeing your blind spots, your weak points, and exactly where you can and cannot see.
If you’re bored during peacetime, there is plenty more you could be doing.
Aaron closed on this, and it’s the thread running through everything above.
IT and OT use different technology and speak different languages. He drew a comparison to accounts he’s heard of the pre-9/11 intelligence environment, where organizations had information but no mechanism to share it, no way to communicate risk to each other, no way to combine what they knew. Same structural problem, different domain.
Take an IT person to a power plant and he may not understand anything he’s looking at, even after 20 years at that same power company, because he’s been on the IT or business side and has never worn a hard hat and steel toes. It runs the other way too.
The fix is conversation, and specifically the kind where people spend real time in each other’s world. Aaron attributes much of his own success to being able to walk into a plant manager’s office and be understood, not because he’s using the right buzzwords but because he genuinely knows the business process, and then turn around and have the same conversation with a CISO or a CEO in their terms.
Most places he sees still have OT completely islanded from IT, with almost no crosstalk unless it’s a turf fight. And the process friction makes it worse. When something breaks in OT, and the traditional IT procurement path means a fight, a product substitution, and a qualification cycle, the engineer takes the P card to Best Buy and has it fixed by tomorrow. That’s not defiance. That’s someone doing their job under the constraints they’ve been given.
Which brings us to the line that stuck with us most from this episode: you can lock someone down so tightly in the name of security that they can’t do their job. And then they’ll bypass it. Passwords taped to monitors. Doors propped so they don’t lock. If your controls don’t fit the way the business actually works, the business will route around them.
Aaron’s parting note was an open door. OT is an exciting space; it needs more good people, and he’s happy to talk with anyone who has questions about any of this.
That matches what our team runs into constantly. The technical challenges here are interesting, but the field is bottlenecked on people who can hold both halves of the conversation at once.
If you’re working through any of the above, whether that’s building your first real asset inventory, figuring out where your collection points should actually sit, or running a tabletop that’s specific to your plant instead of generic, that’s the kind of work our OT assessment and services team does. Cygnet exists specifically for the sites where you can’t get cloud connectivity or aren’t permitted to, which describes a lot of the environments in this conversation.
Our products are designed to work with
you and keep your network protected.