OT cybersecurity at fuel terminals: real risks and first steps under IEC 62443

OT cybersecurity at a fuel terminal starts with four steps: know every asset and its connections, separate the control network from the office network, control remote access, and confirm that backups can be restored.

OT (operational technology) is the equipment and software that runs the physical terminal: PLCs, SCADA, the terminal automation system, gauges, meters and the networks between them. The ISA/IEC 62443 series is the common reference for securing it, and NIST SP 800-82 Rev. 3 gives practical guidance. This guide turns both into first steps a terminal can take without stopping operations, and points to the Indonesian rules for vital information infrastructure.

Office IT protects information. A terminal's OT protects a physical process that handles flammable product.

NIST SP 800-82 Rev. 3 frames the task as securing OT while respecting its unique performance, reliability and safety requirements. In practice that changes the rules. A server in an office can be restarted tonight to apply a patch. A loading bay controller cannot be restarted while trucks are loading, and a patch for it may need vendor testing first. Equipment lives for many years, and some of it cannot run current software.

Good OT security therefore uses compensating controls: separation, strict access, monitoring and backups that do not depend on touching the running system.

Most incidents in control systems start with ordinary weaknesses, not exotic attacks.

The table lists the weaknesses that appear again and again in terminal networks, with the first fix for each. None needs a large budget. All of them need someone to own the task and to check it later.

You cannot protect a device you do not know is there.

Start with a list: every PLC, server, HMI, switch, gateway, serial converter and remote link, with its model, version, location and owner. Then draw how they connect. The Citia article on PLC/SCADA assessment describes the same baseline: an asset register, the real topology and the backups, with uncertainty recorded as a finding when documents are incomplete.

Small habits help. At LPG Panjang, labelling the wiring in the server rack in stages made cable paths easier to identify later, as the LTSA project record notes. The same labelling makes an unexpected cable easy to spot.

Walk the site as well as reading the drawings. An undocumented second network card, a forgotten modem or a wireless access point added for convenience is exactly the connection an attacker finds first.

Give the list an owner. OT security often falls between the IT team, who do not know the plant, and the operations team, who do not manage networks. A named person with authority over both, even part-time, keeps the inventory current and decides who may connect what.

Separation means a problem in one part of the network cannot freely spread to another.

The IEC 62443 series describes this with zones and conduits. A zone groups assets that need the same level of protection. A conduit is a controlled communication path between zones, with a firewall or a similar control on it. At a terminal the natural zones are the field and control equipment, the TAS and SCADA servers, an interface zone for data going to the business systems, and the office network.

The data link to SAP described in integrating TAS and TMS with SAP should pass through the interface zone, and the layers are explained in TAS architecture. Remote vendors enter through that same zone and never reach a PLC directly.

Not every zone needs the same protection, and the standards give a way to decide.

IEC 62443-3-3 describes security levels. A system has a capability level, which is what its design can withstand, and each zone gets a target level chosen from risk. The zone that runs loading control and pump interlocks deserves a higher target than the guest network in the visitor room, and the difference should show in the firewall rules, the account rules and the monitoring.

The exercise also protects the budget. Raising every zone to the highest level is expensive and rarely needed, while leaving the control zone at the level of the office is how incidents start.

Remote access is useful and dangerous in equal measure, so it needs rules.

Vendors need to reach the system for support, and a night-time fault is a poor moment to argue about how. Decide in advance. Citia's technical bulletin on secure system integration describes a layered model with encryption, multi-factor authentication and a firewall, and the same layers apply to support sessions.

After each session, close the temporary account, read the session record and file it with the fault report. A vendor who knows the record will be read is a more careful vendor.

The contract side matters too. The LTSA guide lists the remote access, credential and incident terms to ask a service provider for.

A backup is useful only if it survives the incident and can be restored by someone who is tired and in a hurry.

Keep at least one copy offline or on a separate system that ransomware on the control network cannot reach. Restore it on a spare machine at least once and write down what happened. The Citia reliability material makes the same point: a backup file alone does not establish recoverability, so record its version, date, source, target equipment and any licence or configuration dependencies.

Citia's Condition Monitoring and Maintenance service includes backup and restore tests and network and gateway checks.

Different layers need different backups: PLC programs, gateway configurations, databases, SCADA projects and engineering documents. The guide on PLC and SCADA backup and restore covers how to organise them.

A short checklist is better than a long policy that nobody starts.

Work through these in order. The first four cost almost nothing and remove the largest risks. The rest build on them. Record the date and the owner of each step, because the record is what turns a good intention into a programme.

Prevention fails sometimes, so a terminal also needs to notice and to act.

The Padalarang TAS support shows the habit: routine database backups and records of maintenance activity and configuration changes are kept as an audit trail.

Keep logs from the firewall between the zones, from the servers and from the remote access point, and give someone the task of reading them on a schedule. Unusual hours, new devices on the control network and repeated failed logins are the first signs worth a call.

Write a one-page response plan before it is needed: who is called, what is isolated first, how operations continue manually and what evidence is kept. Practise it once with operators, in the same spirit as testing a manual fallback for any other system.