In this segment, the speaker emphasizes that the primary concern when merging IT security into OT environments is managing risk. He outlines three fundamental questions about data flow—whether the connection is bidirectional, inbound‑only, or outbound‑only—and stresses that clarifying these flows is a massive but essential undertaking. He advocates for a programmatic approach to identify, register, and architect solutions around these risks, aligning them with organizational requirements. The speaker argues that cybersecurity decisions should be driven by business prerogatives rather than endless technical debates, urging stakeholders to reach business‑level agreements on what risks are acceptable. He cautions against over‑reliance on extensive external specifications, suggesting they be used for information only, while the core risk‑mitigation strategy should be defined within the organization’s business unit.
Chapters
What I focus on is the risk. So from a security side, bringing IT security risk into OT is where I like to strike the best balance because obviously that's what I do. But you find that there's relatable terms or relatable issues in that convergence. So if you're introducing an IT system into an OT environment and let's say, you know, foundationally you don't have a good construct for how the data is gonna flow from that IT system to your OT systems? Is it gonna be bidirectional data? Is it just reaching in and grabbing data and pulling out? Is it going the other way where it's outbound only? I just touched on 3 small principles, but that in itself is a massive undertaking to flesh out in a way that you— and to do so in a way that's programmatic and that you're outlining that risk and understanding that risk. and registering that risk, or that you're architecting the solutions to meet the organizational requirements that you have. So you'll find, hopefully, Aaron, a lot of my— a lot of what I do and how I try to proceed, you know, points on cybersecurity is back to organizational because we can argue technical definitions until we're both asleep or something else, right? It's a business prerogative to bring IT into the OT world, and it should be a business-level agreement between stakeholders as to how to architect and introduce these things in a way that keeps the risk level low. And I think that's one of the prevailing factors that I like to make sure I have conversationally or assert into folks who are working on IT/OT convergence is that, you know, You need to just have the right stakeholders together, right? And playing off the business requirements and saying, as a business, we can agree to this, but we can't agree to this. That is a fair statement, and you should say that. You should make that decision point be the one that you lean on versus looking outside or external to a bunch of specifications and requirements and 800, 900-page documents to tell you what to do. Those are informative, right? But in order to keep that risk low, you should flesh that out organizationally as a business unit.
