Skip to main content

IT-OT Boundary Failures in Kalimantan's Energy Sector

Field notes from assessing operational technology environments across mining and power generation sites, and the four boundary weaknesses we find repeatedly.

Aditya Pratama Wibowo 10 min read

Operational technology environments in Indonesian mining and power generation were not designed with adversarial network access in mind. Most were built for availability and safety, then connected to corporate IT for reporting and remote maintenance. That connection is where nearly every serious finding originates.

Weakness one: flat historian access

The process historian is usually the first system to be exposed to the corporate network, because business analysts need production data. In practice, the historian frequently sits in the OT VLAN with no intermediate broker, and it authenticates with a shared service account whose credentials appear in a scheduled task on a corporate file server.

The remediation is not complicated: replicate historian data outward to a DMZ instance rather than allowing inbound corporate queries into the control network.

Weakness two: vendor remote access

Remote maintenance channels for turbine, conveyor, and SCADA vendors are typically always-on VPN tunnels with static credentials and no session recording. A single compromised vendor laptop becomes a direct path into the control environment.

Move vendor access to a jump host that requires client-side approval per session, records the session, and expires credentials automatically.

Weakness three: engineering workstations on the corporate domain

Engineering workstations that hold PLC project files are frequently joined to the corporate Active Directory domain for patch and antivirus management. This means any domain-wide credential compromise reaches the systems that can reprogram physical processes.

If domain join is operationally necessary, place these hosts in a separate forest with a one-way trust and no shared administrative accounts.

Weakness four: no baseline of normal

The most consistent gap is not a control, it is visibility. Very few sites have a documented inventory of which controllers exist, what firmware they run, and which hosts legitimately communicate with them. Without that baseline, detecting anomalous instructions is impossible.

Passive network monitoring on an OT tap answers this question within weeks and rarely requires any change to the process network itself.

Sequencing the work

For sites starting from a low baseline, we advise this order: build the asset inventory, deploy passive monitoring, fix vendor remote access, then segment the historian and engineering workstations. Attempting segmentation before you have visibility almost always causes an operational incident, which then stalls the entire programme.