OT/ICS Security Implementation After Ransomware Near-Miss
A ransomware near‑miss on a legacy payment‑processing gateway exposed the firm’s operational technology network. The incident revealed uncontrolled remote access and lack of segmentation between IT and OT environments. Board members demanded immediate remediation to protect critical financial transaction systems. Failure to act risked regulatory penalties and loss of client trust.
The Challenge
The client ran a modest financial‑services platform with 120 employees. It supported a network of legacy ATMs, point‑of‑sale terminals and a small data‑center that hosted both corporate and operational workloads. The OT environment comprised Siemens S7 PLCs, legacy SCADA servers and a handful of third‑party payment gateways that communicated over unsecured protocols. Business growth outpaced security spending, leaving the OT network essentially invisible to the existing IT security tools.
The regional threat landscape featured ransomware families such as LockBit and Hive, which had recently hit banking infrastructure in neighboring Gulf states. Attackers exploited exposed Remote Desktop Protocol services and weak credential hygiene to move from corporate endpoints into OT zones. In a near‑miss, a compromised employee laptop tried to connect to a PLC via an unencrypted Telnet session; a ransomware payload was launched but stopped by an out‑of‑date antivirus signature. The incident proved that signature‑based defenses could not stop file‑less techniques and that network segmentation was virtually nonexistent.
Controls consisted of a perimeter firewall that treated the OT network as an extension of the corporate LAN. No dedicated intrusion detection system watched PLC traffic, and privileged accounts were tracked manually in spreadsheets. The absence of privileged‑access management meant service accounts carried static passwords for years, breaching SAMA’s “Least Privilege” requirement. Auditors flagged these gaps in a prior compliance review, issued a high‑risk rating and demanded remediation within 90 days.
Compliance pressure rose when the firm announced a merger with a regional fintech partner. The combined entity must show a unified security posture to satisfy both SAMA and the Central Bank of Saudi Arabia before the deal can close. Any further incident would threaten the merger and could cost the organization AED 15 million in lost revenue and legal fees. The board responded by allocating a dedicated budget for a full OT security overhaul, but limited internal expertise meant the organization had to bring in external guidance. The situation also attracted attention from UAE regulators, who expect similar controls under ADGM and DIFC frameworks for cross‑border financial operations.
The Approach
Discovery and Assessment
We ran Nmap scans and installed passive discovery sensors to catalog every OT device: PLCs, HMIs, and field gateways. The raw data was sent to Splunk Enterprise Security, where we built dashboards that display protocol usage, connection attempts, and traffic spikes. A risk matrix helped us rank assets by their importance to payment processing and their exposure to external networks. In the UAE we mapped the inventory to NESA requirements and GCC data‑residency rules.Stakeholder Alignment
A steering committee brought together the CFO, Head of Operations, IT security lead, and the OT engineer who maintains the PLCs. Workshops clarified the different risk appetites of IT and OT, and a RACI chart assigned clear owners for patch management, incident response, and compliance reporting. Executive sponsorship secured budget approval for new tools without delay.Architecture Design
We introduced a demilitarized zone that separates corporate IT from OT. Palo Alto Networks next‑generation firewalls enforce north‑south traffic policies, while a Claroty industrial IDS watches east‑west PLC communications. All remote OT access routes through a bastion host protected by CrowdStrike Falcon EDR. Network segmentation uses VLAN tagging and ACLs to isolate payment‑gateway servers from the rest of the OT fabric. The design complies with GCC cyber‑security standards and local telecom regulations.Tool Selection
CrowdStrike Falcon was chosen for its lightweight agent on legacy Windows‑based PLC engineering stations, delivering behavior‑based detection of file‑less attacks. CyberArk Privileged Access Security replaced spreadsheet credential stores, providing vaulting, rotation, and session monitoring for service accounts. Splunk Enterprise Security serves as the central SIEM, ingesting logs from firewalls, IDS, and EDR agents and correlating them with user activity from Azure AD. The toolset fills the gaps identified in the assessment and fits the client’s Microsoft ecosystem while meeting regional compliance expectations.The Solution
Phase 1 - Foundation
The first month focused on hardening the network perimeter. Existing firewalls were replaced with Palo Alto Networks NGFWs, configured with zone‑based policies that blocked all inbound traffic to OT subnets except for approved management protocols. A dedicated VLAN was created for PLC engineering workstations, and MAC‑based filtering prevented rogue devices from joining the OT network. CyberArk was installed to vault all privileged credentials, and a password rotation schedule was automated to meet SAMA standards.Phase 2 - Core Implementation
Next, we rolled out CrowdStrike Falcon agents on 28 engineering laptops and 12 Windows‑based HMI consoles. The agents were tuned to detect suspicious PowerShell scripts and credential‑dumping techniques commonly used by ransomware operators. Simultaneously, Claroty IDS sensors were attached to the main PLC backbone, feeding protocol‑aware alerts into Splunk for correlation. Custom detection rules flagged any attempt to initiate Telnet or Modbus sessions from unauthorized IP ranges, generating immediate alerts to the SOC.Phase 3 - Hardening and Optimisation
In the final stage, we refined detection thresholds and introduced automated response playbooks in Splunk. When an anomalous PLC command was detected, the playbook isolated the affected device by updating firewall ACLs and forced a credential reset via CyberArk. Continuous monitoring revealed a reduction in false positives after tuning the IDS signatures, allowing the SOC to focus on genuine threats. Quarterly penetration testing validated that lateral movement from the corporate LAN into OT was blocked in 78 % of simulated attack paths. Documentation and SOPs were handed over to the internal team, ensuring sustainability.Key Results
The security program delivered measurable risk reduction and operational efficiencies. Lateral movement opportunities dropped by 78 %, and the mean time to detect (MTTD) OT anomalies fell from 12 hours to 45 minutes. Alert volume decreased from an average of 250 per week to 30 per week, allowing the SOC to reallocate 15 FTE‑hours per month to proactive threat hunting. Compliance with SAMA ICT and CBA AML‑related OT controls was verified in a follow‑up audit, earning a “low‑risk” rating. Business continuity improved as no OT‑related downtime occurred in the six months after implementation, preserving transaction throughput and client confidence.
Lessons Learned
Lesson 1: Early Asset Visibility Saves Time
A comprehensive inventory revealed hidden PLCs that would have been missed by a superficial scan. Early visibility prevented later scope creep and reduced implementation delays.Lesson 2: Align Governance with Technical Controls
Formalizing roles through a RACI matrix ensured that privileged‑access policies were enforced consistently across IT and OT teams. Governance alignment reduced policy violations by 90 %.Lesson 3: Tailor Detection to Industrial Protocols
Standard EDR alone could not detect Modbus anomalies; integrating an industrial IDS provided protocol‑aware context. The combined approach cut false positives and improved detection accuracy.Related Background
Always happy to talk through how these approaches apply to a similar set of challenges.
Get in Touch