Introduction

The Job Nobody Applied For

You didn't get into automation to become a cybersecurity professional. You got into it because you're good at making industrial systems run reliably — the PLC logic, the HMI screens, the historian that keeps 10 years of process data, the network that ties it all together. You know your environment. You know what normal looks like and what it doesn't. And then, at some point, someone asked you to also be responsible for securing it. Maybe a regulator requested a cybersecurity assessment. Maybe IT sent a vulnerability report that named your SCADA system. Maybe there was an incident somewhere in the news that made your manager nervous. However it happened, you found yourself in conversations about attack surfaces, network segmentation, and authentication controls — and the systems you know better than anyone suddenly looked different. Not because they changed, but because you were now looking at them from a perspective you hadn't been trained for. That gap between operational knowledge and security knowledge is exactly what this book is designed to close. Not by turning you into a penetration tester or an enterprise IT security analyst, but by giving you a working understanding of how industrial systems get attacked, how the IEC 62443 framework helps structure a defense, and how to make decisions and have conversations about risk in a way that holds up under scrutiny.

The Same Problem From a Different Direction

There's a second version of this problem that starts from the opposite end. You're an IT security professional — comfortable with Active Directory, firewalls, endpoint detection, patch management, and vulnerability scanning. Your organization acquires a manufacturing facility, or your CISO decides that OT security now falls under your team's scope. You walk into the control room expecting something in the same category as a data center. Instead you find PLCs from vendors you've never heard of running protocols that don't appear in any of your tool's support matrices. The engineering workstation runs an operating system version that your organization would never allow on a corporate laptop — but nobody can patch it because the control system vendor won't certify the update without a validation process that takes months. The historian is sitting on the flat network with no segmentation because "that's how it was installed in 2009 and we can't touch it." None of your standard tools apply. None of your standard assumptions hold. The calculus of safety versus security is completely different here, because a misconfigured firewall rule in an OT environment doesn't just slow productivity — it can stop a physical process with real consequences. This book works from both directions. It builds the technical vocabulary and mental models that let OT professionals see their systems through a security lens, and gives IT professionals the context they need to apply their security skills without breaking the operational environment they're trying to protect.

What This Book Covers and What It Doesn't

This is a fundamentals book. It covers the terrain you need to understand before any specialist work begins: what industrial control systems are and how they're built, how they differ from IT environments in ways that matter for security, what kinds of adversaries target them and why, and how the IEC 62443 standard gives practitioners a structured way to assess risk and build defenses. By the end, you should be able to identify the security risks in your own ICS environment, participate credibly in a risk assessment, understand the zone-and-conduit model that underpins IEC 62443, and explain OT security concepts clearly to IT teams, auditors, and management. What this book doesn't cover: it's not an enterprise IT security primer, so if you need to learn firewalls or Active Directory from scratch, you'll want to supplement with dedicated resources. It's not an advanced ICS penetration testing guide — that's a specialized discipline that builds on everything here. And it's not a vendor-specific implementation manual. The concepts are drawn from the IEC 62443 framework and applied in a way that's relevant across sectors and system types, from water and wastewater to oil and gas, power generation, manufacturing, and building automation.

A Book in Two Parts

The book is structured around a deliberate sequence. The first three chapters build the ICS foundation: what an industrial control system actually is, how the major components — PLCs, HMIs, SCADA systems, DCS platforms, RTUs, and historians — work together to run a physical process, and how industrial networks connect them using protocols and architectures that have their own logic and constraints. If you come from an OT background, these chapters will sharpen vocabulary you already have in practice. If you come from IT, they're essential — skip them and the security chapters won't make sense in the way they need to. Starting with Chapter 4, the book shifts into cybersecurity. The threat landscape specific to ICS environments. The IEC 62443 zone-and-conduit model for network segmentation. The security program elements that a mature OT security posture requires. How to build visibility into a network you can't instrument the same way you would an IT environment. OT-specific network security devices and architectures. Remote access design in a world where vendors need connectivity but that connectivity creates risk. ICS protocols and what makes them difficult to secure. Risk assessment methodology as IEC 62443 defines it. And finally, how to manage the security risks introduced by third parties — vendors, contractors, and integrators who have access to your systems. Each chapter assumes you've read the ones before it. Concepts introduced early are referenced later but not re-explained. That's intentional — it's how a practitioner reads, and it's how the material is designed to build.

How to Use This Book

Read it in order the first time. The sequence is not arbitrary: each chapter hands something off to the next, and the security chapters in Part 2 frequently refer back to the foundation laid in Part 1. After that first read, the book works well as a reference. The chapter on zones and conduits is something you'll want to return to when you're working through a real zone design. The risk assessment chapter is worth rereading before you walk into an IEC 62443-style assessment. The chapter on ICS protocols is a useful reference any time you're trying to understand what a network monitoring tool is telling you about traffic you haven't seen before. If you're an OT professional who already knows the equipment cold, Part 1 will move quickly for you — use it to sharpen the formal vocabulary and note any terms that appear later in the security chapters. If you're an IT professional, slow down in Part 1 and pay particular attention to how ICS availability requirements change the constraints. The decisions that look wrong from an IT security perspective almost always have an operational reason behind them — Part 1 is where you build the understanding to see it.

What's Next

Chapter 1 starts where everything else has to start: a clear answer to the question "what is an industrial control system?" It's a question that sounds simple but has a precise answer that shapes everything else in the book. Once you understand what makes an ICS distinct from a general-purpose computing environment — the physical process it controls, the real-time constraints it operates under, the safety priorities that sit above everything else — the security decisions that follow start to make a different kind of sense.

Reflect

• What pulled you toward this book — a specific incident, a new responsibility, a conversation that exposed a knowledge gap? What did that moment reveal about what you need to know?
• When you think about the control systems in your environment right now, which systems or connections make you most uncomfortable from a security perspective — and what is it about them specifically that concerns you?
• If your organization faced a cybersecurity incident affecting the ICS tomorrow, what would you know how to do, and what would you have to figure out on the fly?
• Where does the boundary between IT responsibility and OT responsibility sit in your organization — and is that boundary clear enough to defend in an audit?