OT & ICS Security in India — Segmentation, Asset Discovery, IEC 62443

OT security protects the systems that run physical processes — controllers, SCADA, HMIs, sensors and actuators — as distinct from the IT systems that run the business. The difference is not merely technical. Because these systems move physical things, safety and availability outrank confidentiality, equipment stays in service for decades, and many of the routine practices of IT security are either unavailable or actively dangerous.

The priorities invert. IT security usually leads with confidentiality; OT leads with safety, then availability. Patching in IT is monthly and automated; in OT it may require vendor certification and a plant shutdown. Vulnerability scanning in IT is routine; in OT active scanning can fault a controller and stop production. Equipment lifecycles are three to five years against fifteen to thirty. The comparison table above sets these out row by row — the summary is that practice transfers badly and principle transfers well.

A reference architecture dividing an industrial environment into levels, from Level 0 — the sensors and actuators touching the physical process — up through basic control, supervisory systems and site operations, to the enterprise network at Level 5. Between them sits Level 3.5, the industrial DMZ. It is not a rule about how networks must be built; it is a shared vocabulary for reasoning about where a system sits and what should be allowed to talk to it, and that shared vocabulary is most of its value.

It is the buffer between the enterprise network and the control environment, and the only place traffic should cross between them. Done properly, no session originates on one side and terminates on the other — data is brokered, historians replicate into it, remote access terminates in it. It matters because it converts an unbounded question, “what can reach the plant?”, into a bounded and reviewable one: “what crosses the DMZ, and why?”

Not actively, not by default, and not without a change approval and a window. Discovery is passive: we observe traffic from a span or tap and build an asset inventory from what the devices already say. Active techniques have caused outages on legacy controllers, and a provider who treats active scanning of a control network as routine has not worked on a running plant.

Building an inventory by listening rather than probing. Industrial protocols are chatty and largely unencrypted, so a sensor watching a mirrored port can identify devices, firmware versions, communication relationships and often the process logic itself — without sending a single packet to a controller. It is slower to reach completeness than active scanning and it is the only responsible default in OT.

Almost certainly not, and it is worth checking rather than assuming. In practice there is nearly always a path: a vendor support connection, an engineering laptop that moves between networks, USB media carrying recipes or updates, a historian replicating to the corporate side, or a cellular modem fitted during a project and never removed. The belief in the air gap is more dangerous than any single connection, because it is the reason nobody looks.

Sometimes, slowly, and on someone else’s schedule. Many vendors certify patches long after release, and applying an uncertified patch can void support for an entire line. The practical answer is a documented position for each system: patch where certified and a window exists, and where it does not, apply compensating controls — isolate it, restrict what may reach it, monitor it closely — and record the acceptance.

A family of standards for industrial automation and control system security, addressing different audiences — asset owners, system integrators and product suppliers — across defined security levels. It is useful as a structure for organising a programme and as a certification target, and those are very different pieces of work with very different costs. A claim of “62443 compliance” means little without stating which part, whose role and which security level.

Incrementally, and starting with visibility. Establish what actually communicates today — which is invariably more than the documentation says — then enforce in stages: monitor first, then alert on violations, then block, beginning with the flows nobody can justify. Designing a segmentation policy from a network diagram rather than from observed traffic is the reliable way to break something during cutover.

It is usually the most important finding of the first assessment and almost never in the asset register. The target design is a single brokered path through the DMZ, authenticated, time-bounded, recorded and approved per session, replacing whatever mixture of persistent VPNs and cellular modems accumulated over the years. Vendors accept this readily; it is usually internal scheduling that makes it difficult.

Yes, passively, feeding the same 24×7 operations centre that watches the rest of your estate — see managed SOC services. What differs in OT is the response: containment that stops a line is a production decision, so the escalation path runs to operations rather than to an analyst with an isolate button. That path is agreed before go-live, not during an incident.

Yes, and the constraints that come with it shape everything above: passive by default, changes scheduled with operations, nothing installed on equipment whose vendor has not approved it, and no assumption that a maintenance window is available for the asking.

By the number of sites, the rough count of controllers and supervisory systems, which vendors and protocols are in use, whether there is any existing segmentation, and how remote vendor access works today. A first assessment usually pays for itself in the asset inventory alone, because it is rarely the inventory anyone expected.