When IT gets breached, data leaks and money moves. When OT gets breached, turbines spin down, a furnace overheats, a pipeline valve opens, or a city loses power. Operational technology — the SCADA systems, PLCs, RTUs and safety controllers that run physical processes — is now squarely in the crosshairs of nation-state and criminal actors, and India's critical infrastructure is on the target list. Yet most OT environments are still secured the way IT was in 2005: a flat network, default credentials, no monitoring, and an air-gap that quietly stopped existing the day someone added a remote-access laptop. This is the playbook we use to fix that — written for the plant manager, OT/control-systems engineer and CISO who jointly own the problem.
The hard part of OT security is not the technology — it is that the priorities invert. An IT security team can patch on Tuesday, reboot a server, and quarantine a host. An OT team cannot take a running process offline to patch it, cannot reboot a controller mid-batch, and cannot quarantine the PLC that is keeping a boiler from overpressurising. Safety and availability come first; confidentiality comes last. Any control you propose that ignores that ordering will be — correctly — rejected by the people who run the plant. The playbook below is built around that reality.
Why OT security is not IT security with different acronyms
The single biggest cause of failed OT programmes is an IT team applying IT playbooks to an environment that breaks every one of their assumptions. Active vulnerability scanning that knocks a fragile PLC offline. A patch cycle that the vendor will not warranty. An EDR agent on a Windows XP HMI the OEM forbids you to touch. Multi-factor auth on a control console an operator must reach in two seconds during an emergency. The constraints are real and they are non-negotiable — so the methodology has to change.
| Dimension | IT | OT / ICS |
|---|---|---|
| Top priority | Confidentiality of data | Safety + availability of the process |
| Asset lifespan | 3–5 years | 15–30 years (PLCs, RTUs, drives) |
| Patching | Routine, frequent | Rare — vendor-gated, change-window only |
| Downtime tolerance | Maintenance windows | Near-zero; an unplanned trip costs lakhs/hour |
| Scanning | Active scans are normal | Active scans can crash legacy devices |
| Protocols | TCP/IP, HTTPS, well-authenticated | Modbus, DNP3, OPC, PROFINET — often no auth/encryption |
| Endpoint security | EDR everywhere | Often unsupported by the OEM; passive monitoring instead |
Where OT breaks IT security assumptions
The threat landscape is no longer theoretical
OT attacks moved from research curiosity to operational reality over the last decade, and India is not a bystander. Stuxnet (2010) proved a worm could physically destroy centrifuges. Industroyer/CrashOverride blacked out part of Kyiv in 2016. TRITON/TRISIS (2017) went a step further and targeted the Triconex safety instrumented system of a petrochemical plant — malware aimed squarely at the last line of defence between a process upset and a catastrophe. Closer to home, security researchers have reported intrusion campaigns against India's power-grid infrastructure, and the October 2020 Mumbai grid disruption put OT cyber-risk on the front page even where attribution stayed contested.
- Stuxnet (2010) — first malware to cause physical damage, targeting Siemens S7 PLCs and VFDs at a uranium-enrichment facility.
- Industroyer / CrashOverride (2016) — purpose-built grid malware speaking IEC 60870-5-101/104, IEC 61850 and OPC; caused a Kyiv power outage.
- TRITON / TRISIS (2017) — targeted Schneider Triconex safety instrumented systems, the controls designed to prevent loss of life.
- Ransomware spillover — Colonial Pipeline (2021) shut OT operations as a precaution after IT ransomware, showing IT/OT blast radius even without OT-specific malware.
- Reported grid-targeting against India — open-source threat-intel reporting on intrusion sets focused on Indian power utilities and load-despatch centres.
The Purdue model and why segmentation is the whole game
The Purdue Enterprise Reference Architecture is the lingua franca of OT security. It organises an industrial environment into levels — from the physical process at the bottom to enterprise IT at the top — and the entire defensive strategy flows from controlling what is allowed to cross between them. If an attacker who phishes an employee in the corporate network (Level 4/5) can reach a PLC (Level 1) in a handful of hops, you do not have a segmentation problem, you have no segmentation. The Level 3.5 DMZ between operations and enterprise is where most of the real work lives.
- Level 0 — the physical process: sensors and actuators (valves, motors, drives) that touch the real world.
- Level 1 — basic control: PLCs, RTUs and IEDs executing the control logic.
- Level 2 — supervisory control: HMIs, SCADA servers and engineering workstations.
- Level 3 — operations management: historians, MES, batch and production systems.
- Level 3.5 — the industrial DMZ: the brokered boundary where historians, jump hosts, patch and AV servers live so that nothing in OT talks directly to enterprise IT.
- Level 4/5 — enterprise: ERP, business systems and the corporate network/internet.
IEC 62443 — the standard that organises the work
IEC 62443 (formerly ISA-99) is the international standard for security of Industrial Automation and Control Systems, and it is the framework we anchor OT programmes to because it is built for OT realities rather than retrofitted from IT. Its central design idea is zones and conduits: you group assets with shared security requirements into zones, define the conduits (the only permitted communication paths) between them, and assign each zone a target Security Level (SL 1–4) based on the sophistication of attacker it must withstand. SL 1 stops casual or accidental violation; SL 4 is designed to resist a nation-state with extended resources and ICS-specific skills.
- 62443-2-1 — establishing an IACS security programme for the asset owner (governance, risk, policy).
- 62443-2-4 — security requirements for service providers and integrators working in your environment.
- 62443-3-2 — risk assessment and the design of zones and conduits for a system under consideration.
- 62443-3-3 — system security requirements mapped to Security Levels SL 1–4.
- 62443-4-1 / 4-2 — secure-by-design product development and technical requirements for the components themselves.
The India regulatory stack for OT
OT operators in India increasingly answer to named regulators, and 'we run a plant, not a data centre' is no longer a defence. The framing below applies to most critical-sector operators; verify the specific obligations and timelines against the current official texts, which are periodically updated.
| Regime | Issuer / basis | Who it reaches | What it expects |
|---|---|---|---|
| NCIIPC guidelines | NCIIPC, under IT Act §70A | Designated Critical Information Infrastructure (power, banking, telecom, transport, strategic) | Protection of CII, designation handling, threat reporting and baseline controls |
| Cyber Security in Power Sector Guidelines 2021 | Central Electricity Authority (CEA) | Power generation, transmission, distribution, load-despatch | A mandatory cyber-security framework for the power sector, incl. ISMS, audits and a CISO |
| CERT-In Directions 2022 | CERT-In (MeitY) | Broadly all entities, incl. OT operators | Incident reporting within 6 hours, 180-day log retention, clock sync |
| Sector regulators | PNGRB, sector ministries | Oil & gas, ports, metro/rail, water | Sector-specific cyber expectations layered on the above |
The India regulatory layers that reach into OT
A practical OT security readiness path — 30 / 60 / 90 days
- Build a passive asset inventory: you cannot protect what you cannot see, and you cannot actively scan OT safely. Use passive network monitoring and configuration review to enumerate every PLC, RTU, HMI, drive and engineering station, with firmware versions and communication paths — this single artefact underpins everything else.
- Find and map every IT/OT path: trace each conduit between enterprise and OT — vendor VPNs, jump hosts, historians, USB workflows, IIoT gateways and cellular links. This is where the air-gap myth dies and the segmentation backlog is born.
- Design zones and conduits (IEC 62443-3-2): group assets into zones, set a target Security Level per zone from a risk assessment, and define the only permitted conduits. Enforce the enterprise↔OT boundary with a hardened Level 3.5 DMZ (and data diodes for one-way historian flows where warranted).
- Lock down remote and removable access: broker all vendor and engineering access through a monitored jump host with MFA at the boundary (never on the control console an operator needs in seconds), kill always-on vendor VPNs, and put a controlled process around USB media.
- Stand up OT-aware monitoring and IR: deploy passive ICS detection that understands Modbus/DNP3/OPC/PROFINET, feed it into a SOC with OT context, and write an incident-response plan whose first move is protecting the process and people, with named OT and safety-engineer escalation.
- Test the way OT can tolerate: run OT-aware assessments — passive analysis, config and architecture review, and active testing only on lab/twin or during agreed shutdowns — never an off-the-shelf IT pentest pointed at a live plant. Then map the findings to NCIIPC / CEA so the same evidence base serves the regulator.
Five mistakes that get OT programmes stuck
- Pointing an IT pentest at a live plant: an active scan or exploit against a fragile legacy controller can trip the process. OT testing is passive-first and active-only on a twin or during a maintenance window.
- Buying tools before designing segmentation: an OT-monitoring product on a flat network produces alerts no one can action. Zones and conduits first, tooling second.
- Trusting the air-gap: assuming isolation you have never proven. Find every path before you certify anything.
- Forcing IT controls onto OT: EDR the OEM forbids, MFA on emergency consoles, a patch cadence the vendor will not warranty. Adapt the control to safety and availability or it gets bypassed.
- Leaving OT out of IR: an incident plan that assumes you can isolate and reboot. In OT the first question is whether the process and the people are safe — design the runbook around that.
How Macksofy helps
Macksofy runs OT/ICS security as a safety-first programme, not an IT audit pointed at a plant. We start with passive asset discovery and an IT/OT path map, design zones and conduits to IEC 62443, and deliver OT-aware IoT/OT security testing that uses passive analysis and twin/shutdown-window testing rather than live active scanning. We map the result to the India regulatory stack — NCIIPC CII and the NIST CSF for the management framework — stand up OT-context monitoring through a managed SOC, and keep an OT-aware DFIR retainer ready for when minutes matter. It is the security practice behind our manufacturing & OT industry work, delivered on the ground from our Mumbai and Pune base across India's industrial corridors.