Episode 50 — OT, Air-Gapped Networks, Microservices, and Segmentation
In this episode, we look at several architecture ideas that all connect to isolation and control: Operational Technology (O T), air-gapped networks, microservices, and segmentation. These topics may sound separate at first, but they all deal with the same security question. How do you design an environment so that one problem does not spread everywhere? O T environments may control physical processes, such as factory equipment, energy systems, water treatment, transportation, medical equipment, or building systems. Air-gapped networks try to create strong separation by keeping systems disconnected from other networks. Microservices break large applications into smaller services that communicate with each other. Segmentation divides networks, systems, or applications into zones with controlled paths between them. You are learning how architecture can reduce damage, support monitoring, and make updates safer, while also recognizing that isolation has limits and must be designed realistically.
Before we continue, a quick note. This audio course is part of our companion study series. The first book is a detailed study guide that explains the exam and helps you prepare for it with confidence. The second is a Kindle-only eBook with one thousand flashcards you can use on your mobile device or Kindle for quick review. You can find both at Cyber Author dot me in the Bare Metal Study Guides series.
O T is different from ordinary business technology because it often interacts with the physical world. Information Technology (I T) systems usually focus on data, applications, communication, and business processes. O T systems may open valves, move robotic arms, regulate pressure, control temperature, manage pumps, operate production lines, monitor sensors, or keep safety systems running. That physical connection changes the security mindset. A failed email server may cause disruption and frustration, but a failed control system may stop production, damage equipment, affect safety, or interrupt essential services. O T systems may also have long lifespans. A device in a plant or utility environment may remain in place for many years because replacing it is expensive, risky, or operationally difficult. Security design has to respect that reality. You cannot always treat O T like a normal office network where systems can be patched, rebooted, or replaced whenever convenient.
In O T environments, availability and safety often receive more attention than speed of change. That does not mean confidentiality and integrity do not matter. They do matter, especially when designs, recipes, control settings, or operational data are sensitive. Still, many O T environments are built around the need to keep the physical process stable. A patch that causes a brief outage in a business application may be inconvenient. A patch that causes a production line, hospital system, or electrical control process to behave unpredictably can be much more serious. This is why updates in O T often require testing, maintenance windows, vendor coordination, and careful rollback planning. Security teams must work with engineers, operators, safety personnel, and vendors. The goal is not to avoid updates forever. The goal is to update in a way that reduces risk without creating a new danger through rushed or poorly tested change.
O T systems are often associated with Industrial Control Systems (I C S) and Supervisory Control and Data Acquisition (S C A D A) systems. These terms describe environments that monitor and control industrial or physical processes. You do not need to know every engineering detail for Security Plus, but you should recognize that these systems may include sensors, controllers, human operator screens, engineering workstations, historians, and communication links between equipment. Many of these components were designed for reliability before cybersecurity became a major concern. Some may use older protocols, older operating systems, or vendor-specific tools. Some may not support modern endpoint protection or frequent updates. This creates a security challenge. The environment still needs protection, but the protection must fit the system. A control that works well on a business laptop might cause problems on a sensitive control device. Architecture has to account for those limits.
Air-gapped networks are designed to be physically or logically separated from other networks, especially from the internet or ordinary corporate systems. The idea is simple: if a sensitive network has no direct connection to less trusted networks, attackers have fewer paths into it. Air gaps are often discussed in military, industrial, research, backup, and highly sensitive environments. They can reduce exposure, but they are not magic. People still move data. Vendors still perform maintenance. Software still needs updates. Reports may need to be exported. Removable media, laptops, temporary connections, mobile devices, and human procedures can all become bridges across the gap. A true air gap is difficult to maintain over time because organizations often need some controlled way to move information in or out. The security lesson is that disconnection helps, but only if the supporting processes are also disciplined.
The main misunderstanding about air-gapped networks is the belief that disconnected means unreachable. Attackers may not be able to scan the network from the internet, but they may still reach it indirectly. A compromised laptop used for maintenance could carry malware into the environment. A Universal Serial Bus (U S B) drive could transfer infected files. A vendor support process could introduce risk. A person could copy data from a connected system to an isolated system without enough checking. Even printed information, phone calls, and screenshots can move sensitive data across boundaries. That does not mean air gaps are useless. They can be very valuable for reducing routine exposure. The point is that an air gap must be supported by policies, physical controls, media handling rules, monitoring, and training. You protect the boundary because the boundary is where the risk concentrates.
Microservices take a different kind of architectural approach. Instead of building one large application where many functions are tightly combined, a microservices architecture breaks the application into smaller services. One service might handle user profiles, another might handle payments, another might handle notifications, and another might handle reporting. Each service can be developed, deployed, scaled, and updated more independently than a large monolithic application. That can help teams move faster and reduce the impact of some changes. It can also create more communication paths. Services need to talk to each other through Application Programming Interfaces (A P I), messages, queues, or events. Every one of those connections needs security attention. A large application may have fewer internal boundaries, while microservices create many smaller boundaries. That can be good for resilience, but only when identity, authorization, monitoring, and network rules are handled carefully.
Microservices can improve security when each service has a narrow purpose and limited access. A payment service should not automatically have access to every user document. A notification service should not have broad administrative rights. A reporting service should not be able to change production records unless that is truly part of its role. This is the principle of least privilege applied inside an application architecture. If one service is compromised, the attacker should not automatically gain access to everything else. The challenge is that microservices can become complex quickly. There may be many services, many identities, many certificates, many secrets, and many routes between components. Monitoring also becomes more difficult because one user action may pass through several services before it is complete. Good design helps you trace requests, control service-to-service access, rotate secrets, and understand which services depend on each other.
Segmentation is the practice of dividing an environment into smaller parts and controlling how those parts communicate. Network segmentation may separate user workstations, servers, guest wireless access, payment systems, development environments, cloud workloads, and O T networks. Application segmentation may separate services, functions, or data flows. Identity segmentation may limit which accounts can reach which resources. The purpose is to reduce unnecessary access and slow an attacker who gains a foothold. Without segmentation, one compromised device may be able to reach too many other systems. With segmentation, the attacker must cross controlled boundaries, and those crossing attempts may be blocked, logged, or investigated. Segmentation is not only about putting up walls. It is about placing doors where doors are needed, locking them appropriately, and watching how they are used. A good segment has a purpose, an owner, and clear rules for communication.
Logical segmentation uses configuration and technology to separate systems that may still share physical infrastructure. Examples include Virtual Local Area Networks (V L A Ns), firewall rules, access control lists, software-defined networking, cloud security groups, identity-based access policies, and application-level controls. The systems may run in the same data center, on the same switching fabric, or in the same cloud provider, but logical rules determine what can communicate. Logical segmentation is flexible because you can often change it without moving cables or rebuilding the physical environment. That flexibility is useful, but it also means mistakes can happen quickly. A rule that is too broad may open access across zones. A forgotten exception may remain after a project ends. A cloud security group may allow traffic from anywhere when it should only allow traffic from a trusted service. Logical segmentation needs review, documentation, and monitoring.
Physical segmentation uses separate physical infrastructure or physical separation to reduce connectivity between environments. This might include separate cabling, switches, rooms, racks, facilities, management consoles, or dedicated hardware for sensitive systems. Physical segmentation can provide strong assurance because the separation is not only a rule in software. It can be helpful for O T, high-security networks, backups, classified environments, or systems with strict compliance requirements. The tradeoff is cost and flexibility. Physical separation may require more equipment, more space, more maintenance, and more planning. It may also make operations harder if people need to manage multiple isolated environments. Physical segmentation can still fail if someone creates an unauthorized connection, plugs in a bridge device, uses shared credentials, or moves data carelessly between segments. Strong physical design must be matched with strong operational discipline.
Different environments require different monitoring strategies. An ordinary office network may support endpoint agents, frequent vulnerability scans, and rapid configuration updates. An O T network may require more careful passive monitoring because aggressive scanning could affect fragile devices or create operational concerns. An air-gapped environment may have fewer network paths, so monitoring may focus on physical access, removable media, administrative activity, and controlled transfer points. A microservices environment may need detailed logs that trace a request across several services. A segmented network may need visibility at the boundaries between zones, because boundary traffic shows whether the design is working. Monitoring should match the architecture. If the environment is isolated but nobody watches the transfer process, a major risk may go unseen. If the environment is highly distributed but logs are not connected, an attack may look like unrelated fragments.
Update strategies also differ across these architectures. In business I T, updates may be frequent and automated for many systems. In O T, updates may require vendor approval, lab testing, safety review, and scheduled downtime. In air-gapped networks, updates may need to be transferred through controlled media or a trusted update process. In microservices, individual services may be updated independently, but the team must ensure that changes do not break communication with other services. In segmented environments, updates may need to pass through controlled management paths that do not weaken isolation. The security goal is to reduce known vulnerabilities, but the operational goal is to avoid breaking essential services. A mature architecture balances both. It keeps systems current where possible, tests carefully where needed, and uses compensating controls when immediate patching is too risky.
Isolation also affects incident response. If a regular workstation is compromised, segmentation can help prevent the attacker from reaching servers, administrative systems, or O T networks. If a microservice is compromised, narrow permissions can prevent it from reading unrelated databases or calling powerful internal services. If an O T environment shows suspicious activity, responders may need to coordinate with operations before isolating devices or changing settings, because careless action could affect safety or production. If an air-gapped network is involved, responders may examine the controlled transfer points, removable media records, maintenance laptops, and physical access logs. Architecture shapes the response options. A flat network gives an attacker more room and gives defenders fewer clean containment points. A well-segmented environment gives defenders places to stop movement, collect evidence, and protect the most critical systems.
O T, air-gapped networks, microservices, and segmentation all show how security architecture must fit the environment it protects. O T requires special care because cyber events can affect physical processes, safety, and availability. Air gaps reduce exposure, but they depend on strict control of the people, media, and processes that cross the boundary. Microservices can make applications more flexible and resilient, but they create many service-to-service paths that need identity, authorization, and monitoring. Logical segmentation uses rules and configuration to create separation, while physical segmentation uses separate infrastructure or physical boundaries. Each approach can reduce risk, but none works well by name alone. You have to ask what is being isolated, why it is being isolated, how updates will happen, how monitoring will work, and what defenders can do when something goes wrong. Good architecture does not assume failure will never happen. It limits how far failure can spread.
