Port Infrastructure VAPT: Critical System Testing

Why Port VAPT Is Its Own Discipline

Port infrastructure VAPT brings together disciplines usually scoped as separate engagements: enterprise IT penetration testing, OT and ICS testing, web and API testing of the terminal operating system, wireless testing of yard and gate networks, and supply-chain assessment of the many vendors who reach into terminal systems. Treating them as a single coherent engagement is what produces a report that a port authority, an ISPS officer and the terminal IT team can all act on.

The defining feature is the IT/OT boundary. The terminal operating system (TOS) is an IT application. Quay cranes, yard cranes, straddle carriers and reach stackers run PLC-based control with vendor remote diagnostics. The integrations between TOS and equipment, plus shared use of vendor remote access and operator workstations with visibility into both, create a single security domain even when the organisation chart pretends IT and OT are separate. Port VAPT has to test that domain as it actually exists, not as the network drawing claims.

The other defining feature is consequence. A compromise at a port is not an abstract data-loss event. A TOS outage stops crane moves, queues trucks for kilometres, delays vessels and cascades into customs and supply-chain disruption within hours. Recent international incidents, terminal operators hit by ransomware causing multi-day closures, show that cyber events at ports translate to physical and economic consequences fast. The testing has to reflect that resilience, not just confidentiality, is the operating requirement.

Scope Definition: Six Environments, Three Depths

Scoping is the most important hour of the engagement. Terminal operators typically arrive with 'test everything' or 'test the TOS', neither of which is precise enough. The engagement letter must enumerate each environment and the test depth permitted in each. Our standard template covers six environments at three depths: passive observation, active non-disruptive, and active intrusive.

• Terminal operating system (TOS): web and thick-client application, database, role-based access, integration boundaries. Standard pentest depth
• Crane and equipment control: STS and yard crane PLCs, telematics, vendor remote diagnostic paths. Constrained OT, passive plus non-disruptive only
• Gate systems: RFID and proximity access, OCR, weighbridge integration, gate-operator workflow. Standard pentest with replay and cloning tests
• Port community system and customs integration: multi-tenant APIs, EDI channels, external partner access. Standard API pentest depth
• Terminal IT: corporate workstations, servers, Active Directory, planned maintenance, document management. Standard enterprise pentest depth
• Wireless and vendor surface: yard and gate Wi-Fi, vendor remote access, jump hosts. Standard wireless and external pentest depth

Terminal Operating System Testing

The TOS is the centre of gravity, so it gets the deepest application testing. Common platforms are web-based or thick-client applications backed by enterprise databases and integrated with the gate, crane, port community system and customs channels through a mix of EDI standards and vendor-proprietary APIs. We test them with standard OWASP web and API methodology plus maritime-specific role and tenancy tests.

The testing covers authentication and session management, role-based access enforcement across operator, supervisor, gate clerk and customer-portal roles, and broken object-level authorisation (BOLA) across terminal or tenant boundaries where one shipping line might query another line's cargo. We examine the integration boundaries closely, because the TOS-to-PCS and TOS-to-customs links often carry weaker authentication than the front-end login.

Recurring TOS findings include default or shared vendor support credentials retained on production, missing role enforcement that lets an operator perform supervisor actions, BOLA across tenant IDs in multi-tenant deployments, weak segregation between the TOS database and peripheral integration databases, and a backlog of unpatched CVEs in the application server stack underneath the TOS. Each is straightforward to remediate once surfaced, but they have to be surfaced first.

Crane and Equipment PLC Testing, Safely

Crane and equipment control is where port VAPT diverges most sharply from enterprise testing. Quay cranes, yard cranes, straddle carriers and reach stackers increasingly run networked PLC control with vendor remote diagnostic access and telemetry to the TOS. A compromise of crane control has direct safety consequences, load swing, collision with a stack, a dropped container, and operational consequences, a forced stop of all moves on the affected berth.

Because of that, OT testing is constrained. We do not fuzz an active control loop or send unexpected commands to a PLC handling a live load. The methodology is passive observation first: capture on the OT network through a SPAN port or managed switch, enumerate devices and protocols, map every cross-zone path and every vendor remote session. Active testing is limited to non-disruptive checks, performed during planned downtime where possible, on configuration, authentication, default credentials and the conduits between the OT zone and the rest of the terminal.

The vendor remote diagnostic path receives particular attention. It is often a persistent inbound route into the most safety-critical equipment in the terminal, and it is frequently unmonitored. We test whether it is gated through a controlled jump host with session recording, whether the credentials are shared or unique, and whether the conduit is restricted to the equipment it should reach or opens onto the wider OT zone.

Gate Systems and Port Community System

Gate systems control truck and rail access and combine RFID or proximity identification, optical character recognition for plates and container numbers, weighbridge integration and gate-operator workflow. They are a recurring weak point. RFID tags frequently use cleartext UIDs that can be cloned with a low-cost reader, allowing one truck to impersonate another. Replay attacks on the gate workflow can authorise entry without a valid permit. Gate-operator terminals often share accounts with weak logging that defeats after-the-fact attribution.

We test gate systems for tag cloning resistance, replay resistance, the coupling between gate authorisation and the cargo manifest check, and gate-operator workstation hardening. Where the RFID is cleartext, the remediation is a phased migration to authenticated tag formats with diversified keys, alongside operator account hardening and integration of gate events into the monitoring layer.

The port community system (PCS) is the integration backbone, exposing APIs to many external parties, carriers, freight forwarders, customs brokers, of varying cyber maturity. We test it as a multi-tenant API-driven application: authentication and authorisation review, BOLA testing across organisation boundaries, API key rotation and audit, and the trust assumptions between the PCS and the customs declaration channel. BOLA across organisations is the finding that recurs most, because a single broken authorisation check can expose one company's cargo data to another.

Reporting for Authority, ISPS, Class and Insurer

A port VAPT report must serve several audiences in one document. The port authority wants assurance on critical infrastructure resilience. The ISPS officer wants the cyber dimension folded into the port facility security plan. The terminal IT and OT teams want technical detail with remediation steps. Any classification society or insurer reviewing the port wants a risk posture statement.

Our reports map each finding against IEC 62443 zones and conduits for the OT components, ISO/IEC 27001:2022 Annex A controls for the IT components, and the OWASP Top 10 for web and API surfaces. CVSS v3.1 with environmental modifiers gives the base risk number, and a port-specific severity overlay, Safety-Impacting, Operations-Impacting or IT-Only, sits alongside it so a crane engineer and a CISO read the same report with the same urgency.

The remediation roadmap is prioritised by risk and sequenced into immediate, 90-day and 180-day work, because a port cannot stop operating to fix everything at once. The first 90 days typically deliver disproportionate risk reduction: vendor remote-access consolidation onto a monitored jump host, basic monitoring coverage of the IT/OT boundary, default-credential rotation across the TOS and equipment, and RFID hardening on the highest-traffic gates. Free re-test within 90 days is standard.