Securing OT and ICS Networks: A Practical Guide for Indian Manufacturers

  • Home
  • Securing OT and ICS Networks: A Practical Guide for Indian Manufacturers
Securing OT and ICS Networks: A Practical Guide for Indian Manufacturers

India’s manufacturing sector is undergoing rapid digital transformation. Smart factories, Industry 4.0 automation, and connected assembly lines are driving efficiency gains that would have seemed impossible a decade ago. But this convergence of Operational Technology (OT) and Information Technology (IT) has introduced a threat surface that most enterprise security teams are not yet equipped to defend.

Attacks on OT and Industrial Control Systems (ICS) are no longer the exclusive domain of nation-state actors. Ransomware groups now specifically target production environments — not to steal data, but to halt output and extract maximum leverage. When a production line stops, every hour of downtime translates into crores of rupees in lost revenue, contractual penalties, and reputational damage with OEMs and export customers.

This guide is written for IT and OT leaders in Indian manufacturing, automotive, pharmaceuticals, and critical infrastructure — sectors that are both exposed and underserved by conventional IT-centric security frameworks.

Why OT Security Is Different

Most enterprise security tools are designed for the IT world: Windows endpoints, cloud workloads, SaaS applications. OT environments are fundamentally different in ways that matter deeply for security:

  • Legacy systems with long lifecycles: A PLC or SCADA workstation may run Windows XP or Windows 7 — patching is either impossible or requires a shutdown window that doesn’t happen until the annual maintenance cycle.
  • Availability over confidentiality: In IT security, the CIA triad is balanced. In OT, Availability is supreme. A security control that causes even brief downtime may be unacceptable.
  • Proprietary protocols: Modbus, DNP3, PROFINET, EtherNet/IP — these are not HTTP or TLS. Most firewalls, IDS sensors, and SIEMs have no native understanding of these protocols.
  • Flat network topologies: Historically, OT networks were air-gapped. As they connect to enterprise IT and the internet, they often inherit flat Layer 2 designs with no segmentation — a single compromised HMI can reach every PLC on the floor.
  • No endpoint agents: You cannot install an EDR agent on a Siemens S7 controller. Passive monitoring and network-based detection are the only realistic options.

The Expanding Threat Landscape

The global threat landscape for OT has shifted dramatically. Security researchers and incident responders have documented a significant rise in ransomware families that include dedicated OT kill modules — designed to stop industrial processes before encrypting files, maximising the operator’s pain and the attacker’s leverage.

Beyond ransomware, Indian manufacturers face threats from:

  • Espionage actors targeting pharmaceutical formulations, semiconductor IP, and defence supply chains — sectors where India has seen explosive FDI growth.
  • Supply chain compromise via OEM remote access channels — the same VPN tunnel a German engineering firm uses to perform remote diagnostics can become an attacker’s entry point if credentials are weak or MFA is absent.
  • Insider threats and contractor access — contract engineers frequently have broad, persistent access to OT networks that is never revoked after project completion.
  • IT/OT pivot attacks — attackers compromise an IT workstation first (often via phishing), then move laterally into the OT network through poorly segmented boundaries.

The Purdue Model and Why It Still Matters

The ISA/IEC 62443 standard and the Purdue Reference Architecture define a layered model for OT network segmentation: from the enterprise network (Level 4) down through plant operations (Level 3), supervisory control (Level 2), basic control (Level 1), to the field devices themselves (Level 0). A Demilitarised Zone (DMZ) between Levels 3 and 4 is the critical control point.

In practice, most Indian manufacturing sites we engage with have at least partially collapsed this model. Common findings include:

  • SCADA servers directly reachable from the corporate LAN
  • Engineering workstations with internet access and no application whitelisting
  • Remote access (RDP, VNC, TeamViewer) open directly to OT assets with shared, non-rotated credentials
  • No logging or monitoring on OT network switches

Rebuilding Purdue-compliant segmentation does not require ripping out and replacing existing infrastructure. A phased approach — starting with visibility, then segmentation, then active monitoring — is both practical and cost-effective.

A Practical OT Security Roadmap

Phase 1: Visibility (Weeks 1–4)

You cannot protect what you cannot see. The first step is passive asset discovery — deploying a network TAP or SPAN port on OT network switches and running a passive protocol-aware discovery tool that identifies every device, its firmware version, the protocols it speaks, and its communication patterns. No active scanning; the goal is a zero-impact inventory.

Phase 2: Segmentation (Months 2–4)

Deploy a next-generation firewall (PJ Networks standardises on FortiGate) as the IT/OT boundary enforcement point. Configure zone-based policies that explicitly permit only the minimum required communication flows — e.g., the SCADA historian pushing data to the enterprise data warehouse — and deny everything else by default. Where legacy systems cannot tolerate inline inspection, use passive IDS on SPAN ports.

Phase 3: Monitoring and Response (Ongoing)

OT-aware SIEM integration is essential. Log sources must include OT switches, the FortiGate boundary firewall, engineering workstations, and — where possible — historian and SCADA application logs. Correlation rules should look for OT-specific attack patterns: unexpected Modbus function codes, new devices appearing on the OT segment, off-hours remote access sessions, and lateral movement from IT to OT subnets.

Phase 4: Access Governance

All remote access to OT should be brokered through a Zero Trust Network Access (ZTNA) gateway with MFA enforced. Contractor and OEM access should be time-limited, session-recorded, and automatically revoked on expiry. Shared accounts on OT assets should be eliminated in favour of individual credentials tied to a directory service — even if that directory service is OT-specific.

Regulatory Context: CERT-In and DPDP

Indian manufacturers operating in sectors classified as critical information infrastructure (CII) — which includes power, chemicals, defence production, and certain segments of pharma — are subject to CERT-In’s 2022 directions. These require incident reporting within six hours of detection and mandate log retention that supports forensic investigation.

The Digital Personal Data Protection (DPDP) Act 2023 adds another layer for manufacturers who process personal data — employee records, customer data in ERP systems, biometric data on plant floors. A breach that originates in OT and pivots to IT can trigger DPDP obligations even if the initial target was purely operational.

Organisations that have not yet mapped their OT environment to these obligations are carrying both operational and regulatory risk simultaneously. CERT-In’s requirement that incidents be reported within six hours creates a particularly hard constraint in OT environments, where the cause-and-effect chain can span both production-floor systems and enterprise IT infrastructure.

Common Mistakes to Avoid

  • Treating OT security as an IT project: OT teams must be involved from day one. Security controls that impact availability will be bypassed or disabled by operations staff if they are not co-designed with them.
  • Starting with policy instead of visibility: You need an accurate asset inventory before you can write meaningful firewall rules. Skip the inventory phase and your policies will have gaps from day one.
  • Assuming air-gapping is sufficient: True air-gaps are rare in modern manufacturing. USB drives, maintenance laptops, and OEM remote access channels are all vectors that bypass the assumption of isolation.
  • Ignoring supply chain risk: OT equipment often ships with default credentials and may have remote access software pre-installed by the OEM. Inventory, harden, and monitor before connecting to your network.
  • No OT-specific incident response plan: A generic IT IR playbook is insufficient. OT incidents require coordination with plant managers, safety officers, and potentially regulators. Tabletop exercises specific to OT scenarios — production halt, HMI compromise, historian breach — are essential.

How PrahiX Ora Supports OT and IT SecOps

A persistent challenge in OT security is that most SIEMs and SOAR platforms were built for IT environments — they have limited understanding of OT asset types and protocols. The result is that security teams end up with fragmented visibility: IT events in one console, OT alerts (if captured at all) in another, with no correlation between them. Analysts spend time manually connecting dots that an integrated platform would connect automatically.

The platform we deploy and operate for clients — PrahiX Ora, built by PrahiX Tech Pvt Ltd — is designed to close this gap across four integrated capability pillars:

SIEM with MITRE ATT&CK-mapped correlation: PrahiX Ora ingests logs and events from diverse sources — FortiGate boundary firewalls, OT switches, SCADA historians, engineering workstations, cloud workloads, and identity systems — into a unified correlation engine. Detection rules map to both MITRE ATT&CK for Enterprise and MITRE ATT&CK for ICS, enabling the SOC to identify OT-specific attack patterns such as exploitation of remote services and manipulation of control alongside conventional IT-side threats. Graph-based attack storyline reconstruction lets analysts trace how an IT-side phishing event connects to downstream OT reconnaissance — in a single timeline rather than two separate tools. Tiered log retention (hot/cold/archive) directly supports CERT-In’s direction on 180-day in-country log retention, a requirement that is particularly relevant for manufacturers classified as CII.

NMS for unified OT/IT observability: In multi-vendor OT estates — where Siemens PLCs, Rockwell HMIs, Schneider RTUs, and a mix of managed and unmanaged network switches coexist — NOC visibility is typically fragmented across multiple vendor-specific consoles. PrahiX Ora’s NMS pillar brings unified observability across firewalls, switches, access points, and WAN/SD-WAN links through LLDP/CDP topology discovery and network path tracing. ML-based anomaly detection can flag when a previously quiet PLC begins generating unusual traffic volumes — a potential indicator of scanning or data staging — with auto-healing policies that can isolate the affected segment pending SOC review.

Video surveillance (VMS) for physical-digital convergence: Manufacturing sites, multi-site retail estates, and logistics hubs increasingly need to correlate physical events with network events. PrahiX Ora’s video surveillance (VMS) pillar manages ONVIF, Hikvision, and Dahua cameras with video analytics capabilities, bringing physical and network security under one unified operations view. For a plant floor, this means a network anomaly alert can be immediately cross-referenced with camera footage from the relevant production zone without context-switching between disparate systems — a meaningful improvement in both response speed and situational awareness.

SOAR for the CERT-In 6-hour reporting window: Meeting CERT-In’s six-hour incident reporting requirement is extremely difficult to achieve manually in environments that span both OT and IT. PrahiX Ora’s SOAR pillar provides playbook automation with pre-built connectors, including automated response actions such as pushing blocklists to FortiGate firewalls and triggering network isolation of compromised segments. Automation is what makes the six-hour timeline realistic — incident workflows that require manual coordination across IT, OT, and management layers cannot consistently meet that window without it.

If your organisation is currently managing OT and IT security operations from separate, unconnected tools, that is a structural gap worth addressing before an attacker exploits it. We would welcome a conversation about what an integrated OT/IT SOC looks like in practice for your environment. Reach out to the PJ Networks team at pjnetworks.com/contact.

Building OT Security for the Long Term

India’s manufacturing ambitions — Make in India, PLI schemes, semiconductor and electronics manufacturing investment — are creating exactly the kind of high-value OT environments that sophisticated threat actors target. The organisations that will navigate this period successfully are not necessarily those with the largest IT security budgets, but those that build OT visibility, segmentation, and monitoring now — before an incident forces the conversation.

OT security is not a one-time project. It is an ongoing programme that must evolve alongside changes to the production environment, new equipment introductions, changes to OEM access arrangements, and shifts in the threat landscape. Organisations that treat it as a box to check will find themselves back at the beginning after the first significant change.

PJ Networks works with Indian manufacturers to design and operate OT security programmes that are realistic for constrained patching windows, legacy-heavy environments, and the availability-first culture of plant operations. Our 24/7 NOC and SOC teams bring experience with FortiGate-based OT segmentation, ZTNA-based remote access for OEM and contractor channels, and OT-aware monitoring via the PrahiX Ora platform.

If you would like a no-obligation assessment of your current OT security posture — covering asset inventory, IT/OT boundary analysis, and alignment with CERT-In and DPDP obligations — contact the PJ Networks team at pjnetworks.com.

Leave a Reply

Your email address will not be published. Required fields are marked *