Fortifying OT and ICS Networks: A Practical Security Guide for Indian Manufacturers

• 10 October, 2026
• No Comments

Operational Technology (OT) and Industrial Control Systems (ICS) now sit squarely in the crosshairs of nation-state actors and ransomware groups. For Indian manufacturers, pharmaceutical companies, and critical infrastructure operators, a single compromise in a SCADA controller or PLC can halt production lines, trigger safety incidents, and expose organisations to regulatory liability under CERT-In’s mandatory incident-reporting directive. Yet most enterprise security teams still treat OT networks as an afterthought—segregated by a legacy firewall, visited only when something breaks.

This guide walks Indian enterprise IT and OT security leaders through a structured approach to hardening industrial networks—without disrupting uptime or alienating the engineering teams who run them.

Why OT Security Is Different—and Why That Matters Now

IT security teams operate in an environment designed for patching, rebooting, and rapid change. OT environments are the opposite: availability trumps confidentiality, devices run for 10–20 years without updates, and a five-minute maintenance window requires weeks of planning with plant managers. This fundamental tension creates gaps that attackers exploit relentlessly.

Several trends are accelerating the risk for Indian organisations specifically:

• IT/OT convergence: ERP systems now connect directly to SCADA dashboards for real-time production data. Every integration is a new attack path.
• Remote access sprawl: Post-pandemic VPN tunnels created for OEM vendors and maintenance engineers were never properly decommissioned.
• Legacy PLCs: Many controllers in Indian factories date to the late 1990s and run firmware with no authentication, no encryption, and known public exploits.
• CERT-In pressure: The 6-hour mandatory incident reporting window (April 2022 directive, updated 2024) requires that organisations know they have been breached—something impossible without OT visibility.

Step 1: Map What You Have Before You Protect It

You cannot protect what you cannot see. Yet asset inventory in OT environments is notoriously incomplete. Start here:

1. Passive network discovery: Deploy a passive tap or SPAN port on each OT network segment. Passive monitoring captures traffic without sending any packets onto the network—critical where a ping to the wrong device can cause a controller fault.
2. Protocol-aware parsing: Ensure your monitoring tool speaks Modbus, DNP3, IEC 61850, EtherNet/IP, and Profinet. Generic SNMP-only scanners miss most OT assets.
3. Physical walkthrough: Cross-reference the network discovery output with a physical audit. Undocumented devices—rogue HMIs, shadow IoT gateways, personal laptops plugged into the historian network—appear in every initial assessment.
4. Firmware and model database: For each device discovered, record make, model, firmware version, and network reachability. Compare against ICS-CERT and CERT-In advisories for known vulnerabilities.

Step 2: Segment Ruthlessly

The Purdue Model—Levels 0 through 5—remains the reference architecture for OT network segmentation, but most deployments treat it as aspirational rather than operational. Effective segmentation means:

• Enforcement, not just documentation: A VLAN boundary without a firewall rule enforcing it is security theatre. Each Purdue level transition needs an enforced policy.
• Unidirectional gateways where feasible: For Level 0/1 historian connections, data diodes (hardware-enforced one-way data transfer) eliminate the possibility of lateral movement entirely.
• FortiGate for IT/OT boundary: We deploy FortiGate Next-Generation Firewalls at the Levels 3–4 boundary (manufacturing operations to enterprise IT) with dedicated OT application signatures, anomaly-based policies, and integrated SD-WAN for multi-site manufacturers. OT-specific policies cover Modbus TCP, SCADA protocols, and engineering workstation exceptions—while blocking unexpected lateral paths that generic firewall profiles miss.
• Remote access via ZTNA, not VPN: Replace always-on OEM vendor VPN tunnels with Zero Trust Network Access. ZTNA grants access to a specific asset for a specific session, with full logging—eliminating the lateral movement risk that flat VPN access creates.

Step 3: Monitor Continuously for Anomalous Behaviour

OT networks are highly predictable: a PLC sends the same Modbus read every 500ms, always to the same historian, always with the same payload size. This predictability is your greatest detection advantage. Any deviation—new source IP, new protocol, unusual write command—is immediately suspicious.

Key monitoring principles for OT:

• Baseline normal traffic per device pair and protocol, then alert on deviations.
• Watch for engineering commands (Modbus Function Code 5/6 writes, PLC program downloads) outside change-window hours.
• Alert on new assets appearing on the network—an attacker’s reconnaissance phase often involves scanning with a laptop connected to an accessible switch port.
• Correlate OT anomalies with IT alerts. A credential compromise in the IT domain followed by RDP to a historian server is a well-documented OT intrusion pattern.

PrahiX Ora: Unified SecOps Across IT and OT

One of the most persistent problems in OT security is the gap between IT security operations (SIEM/SOC) and OT monitoring tools. Engineers use OT-specific platforms; security teams use enterprise SIEM. The result: the correlation that would catch an IT-to-OT lateral movement stays hidden because no single team sees both sides.

PrahiX Ora is a unified SecOps platform built by PrahiX Tech Pvt Ltd. PJ Networks is its primary field deployment and operations partner—we deploy and operate the platform for clients across manufacturing, healthcare, and multi-site retail estates in India.

Ora addresses the IT/OT visibility problem through four integrated pillars:

SIEM with MITRE ATT&CK Mapping: Ora ingests logs from OT historians, IT firewalls, endpoint agents, and cloud services into a single correlation engine. Rules are mapped to the MITRE ATT&CK for ICS framework—so an alert isn’t just “anomaly detected” but “Stage: Lateral Movement / Technique: Default Credentials.” Graph-based attack storyline reconstruction stitches individual events into a narrative, dramatically reducing analyst fatigue. Tiered retention (hot/cold/archive) supports CERT-In’s 180-day in-country log retention direction without blowing the storage budget on expensive hot storage for all logs.

Network Management System (NMS): Unified observability across FortiGate firewalls, managed switches, wireless APs, WAN links, and SD-WAN overlays—all in one view. LLDP/CDP topology discovery automatically builds a live network map; when a device drops or a link degrades, the NOC sees it in context, not as an isolated alert. ML-based anomaly detection flags baseline deviations and, for pre-authorised scenarios, auto-healing policies can push a configuration remediation automatically. For Indian manufacturers running multi-vendor estates where NOC visibility is fragmented across five different vendor portals, this single-pane-of-glass approach cuts mean-time-to-diagnose significantly.

Video Surveillance (VMS): Ora’s video surveillance (VMS) module integrates ONVIF-compliant cameras alongside Hikvision and Dahua deployments—common in Indian manufacturing and retail—and adds video analytics (motion zones, loitering detection, perimeter breach). The key differentiator for security operations is convergence: a physical perimeter breach alert and the network anomaly detected on the same subnet at the same time are correlated in the same platform. For multi-site manufacturing or retail estates, operating physical security and network security from one operations view reduces the coordination overhead between security guards, facility managers, and the SOC.

SOAR and Playbook Automation: CERT-In’s 6-hour incident reporting window is not achievable through manual processes when an incident strikes at 2 AM. Ora’s SOAR module provides pre-built playbooks with connectors to FortiGate (automatic blocklist push), endpoint agents, and ticketing systems. When the SIEM fires a confirmed ransomware lateral movement alert, the playbook can isolate the affected segment, push updated blocklists to FortiGate, open a ticket, and draft the CERT-In notification—all within minutes, not hours. Automation is what makes the 6-hour window realistic.

If your organisation is evaluating unified SecOps or struggling with IT/OT correlation visibility, we’re happy to walk you through how we deploy Ora for clients similar to yours. Speak to a PJ Networks specialist.

Step 4: Patch What You Can—Compensate for What You Can’t

Patch management in OT is not like IT patch management. You cannot push a firmware update to a running PLC without a maintenance window, vendor validation, and often a full regression test of the control logic. Accept this constraint and build a compensating-controls strategy:

• Prioritise by exploitability and exposure: A critical vulnerability on an HMI with internet-facing RDP is far more urgent than a critical CVE on a PLC with no network access. Use a risk-ranked patch backlog.
• Virtual patching via IPS: FortiGate IPS with OT/SCADA signatures can block known exploit traffic targeting unpatched controllers—buying time until the maintenance window arrives.
• Compensating controls for legacy devices: For devices that will never be patched (end-of-life PLCs), isolate them behind a dedicated micro-segment with a deny-all-except whitelist policy. Log every access attempt.
• Vendor coordination: Establish a process with OEM vendors for firmware advisory tracking. Many Indian manufacturers have no formal process for receiving or acting on ICS-CERT advisories from their automation vendors.

Step 5: Incident Response Planning for OT

OT incident response is meaningfully different from IT IR. Isolating a compromised IT server takes seconds; isolating a compromised PLC segment may require stopping a production line and notifying safety engineers before any action is taken.

Build an OT IR playbook that explicitly addresses:

• Decision authority: Who is authorised to isolate an OT segment? The CISO alone cannot make that call—plant operations management must be part of the response chain.
• Safe states: For each critical process, document the safe state the plant should enter during an incident. Isolating a network segment while a process is mid-cycle can cause physical damage or safety incidents.
• CERT-In notification: Under the 2022/2024 directive, a ransomware compromise affecting OT systems is a mandatory reportable incident within 6 hours. The notification must include nature, scope, and initial mitigations taken. Have a template ready.
• Forensic preservation: OT systems often lack persistent logging. Configure historian systems and HMI workstations for forensic-grade event logging in advance—you cannot go back and collect evidence that was never recorded.

CERT-In Compliance Checklist for OT Environments

The following actions help evidence compliance with CERT-In’s directions for organisations operating critical information infrastructure:

• ✅ Maintain system logs for a minimum of 180 days on servers and network devices, stored in India.
• ✅ Enable NTP synchronisation to a Government of India NTP server (or approved alternative) to ensure log timestamps are consistent for forensic analysis.
• ✅ Implement and test a documented incident response plan covering OT/ICS environments.
• ✅ Report incidents to CERT-In within 6 hours of detection; maintain a communication chain that reaches CERT-In contacts 24/7.
• ✅ Conduct vulnerability assessments on internet-exposed and IT/OT boundary systems at minimum annually; document findings and remediation timelines.
• ✅ Maintain an asset register that includes OT devices; update it at each change window.

It is important to note that no single product or platform makes an organisation “CERT-In compliant.” Compliance requires documented processes, trained staff, and evidenced controls—technology supports that evidence but does not substitute for it.

Where to Start: A 90-Day OT Security Roadmap

Days 1–30 (Visibility): Deploy passive network taps and a protocol-aware discovery tool on your highest-risk OT segments. Complete a physical asset walkthrough. Establish the asset inventory baseline.

Days 31–60 (Segmentation and Remote Access): Audit all remote access paths into the OT network; decommission unused VPN accounts. Deploy or harden the IT/OT boundary firewall policy. Implement ZTNA for OEM vendor access.

Days 61–90 (Detection and Response): Deploy continuous monitoring on OT segments. Integrate OT alerts into the SOC workflow. Run a tabletop exercise against an IT-to-OT lateral movement scenario. Validate the CERT-In 6-hour reporting chain end-to-end.

How PJ Networks Supports OT Security

PJ Networks provides managed security services to Indian enterprises across manufacturing, pharmaceuticals, BFSI, and critical infrastructure. Our OT security practice combines FortiGate NGFW deployment at IT/OT boundaries, ZTNA implementation for vendor remote access, and 24/7 NOC/SOC monitoring with OT-aware detection rules.

For organisations that need unified visibility across IT, OT, and physical security, we deploy and operate the PrahiX Ora platform, providing a single operational view from the SIEM through to FortiGate response automation.

If your organisation is beginning an OT security programme, or has an existing programme that needs a maturity assessment, contact PJ Networks for a structured evaluation of your current posture and a prioritised remediation roadmap.