Security Testing for UAE Aviation & Logistics

In the UAE an airline, airport operator or logistics provider is expected to run independent security testing under the GCAA's cybersecurity regulations, with reference to the ICAO Annex 17 and Doc 8973 guidance, and mapped to the UAE Information Assurance Standards (IAS) where they apply.

GCAA

The General Civil Aviation Authority sets cybersecurity expectations for civil aviation in the UAE, across the systems that keep operations moving and the data that passes through them. We scope the testing to those systems and track the findings to closure, so the engagement produces the scope rationale, the findings, the owners and the retest evidence a regulator reads.

ICAO Annex 17 / Doc 8973

ICAO Annex 17 and the Doc 8973 security manual frame aviation security at an international level, and that includes the cyber dimension. We align the scope with that guidance. We do not claim certification against it, because neither document is a test standard on its own.

UAE IAS

The UAE Information Assurance Standards apply where an operator handles data or runs systems within their remit. We map findings to the relevant controls so an assessor can see which ones the test exercised and what it showed.

A pentest of reservation, passenger service system (PSS) and departure control covers authorisation at the object and function level, the handling of bookings and boarding data, and the limits that stop one agent, channel or partner reaching another party's records. That is where the serious findings sit in this sector.

The most common high-severity finding we report on these platforms is broken object level authorisation: change an identifier in a request and get back a booking, a passenger record or a boarding pass that belongs to someone else. A scanner cannot reason about it, so we test it by hand, per role and per resource.

We scope the booking channels, the PSS and the departure control services separately. A control enforced at the booking front end is not the same as one enforced at the service behind it, and an attacker goes for the service.

Yes. We agree the testing of cargo, freight and partner-facing platforms in writing first, exclude denial-of-service techniques by default, and set the testing window, the excluded techniques and a deconfliction contact in the rules of engagement before any work starts. Nothing arrives as a surprise.

Cargo and freight APIs connect forwarders, handlers and customs brokers, so we test consent and token handling and the boundaries between parties directly, per role and per object, instead of assuming the gateway enforces them.

Where a test case would create a real booking, release a real consignment or move real goods, it runs against a production-equivalent environment instead. If that environment differs materially from production, the report says so, because a test of a different configuration is a test of a different system.

Yes, and conservatively. Airport operational technology, baggage handling and stand or jet-bridge systems are safety-critical, so we test them without denial-of-service and against a production-equivalent environment wherever an action on the live system could affect operations or safety.

We scope the operational technology on its own rather than folding it into the wider network. The systems that control physical movement carry a different risk from an office network, and we test them on different terms.

A named contact on each side handles the case where a tester finds an active compromise rather than a weakness. We settle that path before day one, not during the incident.

An airline or airport should test at least once a year for anything internet-facing, before a significant release reaches production, and after any material change to authentication, authorisation or a passenger, cargo or operational data path. Where a regulator names an interval, treat it as a floor, not the whole schedule.

A new booking channel, a new partner or cargo integration, or a rewritten departure control flow are the changes most likely to introduce the flaws that matter. Each is a reason to test the affected area rather than wait for the annual cycle.

We run the same phases on every engagement, so two reports a year apart are comparable and you can see what changed rather than read two unrelated documents.

Most operators start with a web and API pentest of their booking and reservation channels, add a mobile app pentest for the passenger apps, and run an internal infrastructure pentest across the airport and ground networks. An OT and ICS assessment of baggage and operational systems, and an objective-based Red Team, follow once the basics are in place.

The right mix depends on what you are protecting and what a regulator has asked for. We scope it with you instead of selling a fixed bundle, and we say where something is not worth buying yet.

Yes. Every engagement ends with a report and, where you need one, an attestation that the testing was carried out, what was in scope, and that the findings were retested to closure. Procurement teams and customers usually ask for exactly that.

We write each finding up with a severity and a named owner, and map it to MITRE ATT&CK so a reader can place it against a known technique rather than a label we invented. That is the evidence chain a reviewer follows from scope through to a closed finding.

The retest is priced at scoping, not sold afterwards, so the closure evidence belongs to the same engagement and the attestation can stand on it.