Aviation Cyber Incidents and Their Lessons

Eight incidents, eight documents

Each row below is one incident a reader can open. The figure in the row is a figure in that document. Nothing in the table is a guess at a fine, a headcount, or a volume of data.

Two worth a closer look

LOT, 21 June 2015 — the ground system

The BBC report is about computers that issue flight plans at Warsaw Okecie, not about an aircraft in flight. More than 1,400 passengers were affected. Ten flights were cancelled and twelve were delayed. LOT told the BBC the attack did not affect aeroplanes already in the air.

Asco, June 2019 — the factory

CERT-EU’s memo of 17 June 2019 records a ransomware attack on Asco Industries, an aerostructures supplier. About 1,000 people were sent home on unpaid leave. The memo, relying on public media, says production was shut down. It does not say for how long, and it does not say what recovery cost.

Could this be you? Three Monday-morning scenarios

Run these against your own organisation. All three are fictional — the organisations do not exist, and any resemblance to a real one is coincidental. They borrow the shapes in the documents above: a ground system that stops a departure, ransomware on a maintenance network, a credential used from outside the organisation. They are not retellings of those incidents.

ExampleMRO — a Part-145 workshop

• Monday. A technician receives an email, apparently from a component OEM, with an "urgent revised inspection procedure" attachment. It is a fake — the attachment installs malware on an office laptop.
• Tuesday. The malware spreads to the PCs driving the bench test equipment, because office and workshop share one network. It quietly uploads the stored test records and credentials.
• Friday night. Ransomware detonates. Test records, calibration data and the work-order system are encrypted. The backup drive — permanently connected — is encrypted too.
• Monday. No test records means no evidence behind recent releases. Whether that is an information-security incident or vulnerability with a significant risk to aviation safety is a judgement for the organisation. If it is, the clocks are the ones in IS.I.OR.230, quoted below.

ExampleCAMO — a continuing-airworthiness organisation

• Monday. A continuing-airworthiness engineer enters credentials on a convincing fake login page for the records portal. Nothing visible happens; the working day continues normally.
• The following weeks. The attacker logs in with the phished credentials and exfiltrates quietly — fleet records, AD-compliance status, review working files — while watching how the organisation works.
• One night. Having taken what there is to take, the attacker encrypts the AD-compliance records and the airworthiness-review files.
• The next morning. Fleet records are unavailable. The same question as in the workshop applies: if the condition in IS.I.OR.230 is met, the notification and the report in the quote are the ones that apply.

ExampleAir — an operations department

• Weeks earlier. A dispatcher installs a cracked tool on a personal laptop at home. The infostealer bundled with it harvests every saved password in the browser — including the work ones.
• Monday. Those credentials are sold and used: flight-planning and crew-records access is compromised. There is no alarm, because the logins look legitimate.
• Tuesday. The intrusion is discovered. The integrity of the weight-and-balance and fuel figures produced since the compromise can no longer be assumed.
• The rest of the week. Operations stop until the systems are verified. If the condition in the quote is met, the report does not wait for the clean-up to finish.

The 72 hours are in point (c)(2). They run from the time the condition has been known, for an incident or vulnerability which may represent a significant risk to aviation safety, and exceptional circumstances are the stated exception. The quote does not start a clock for every outage.

What the pattern teaches

The eight documents are not one attack. LOT is a ground planning system. British Airways is a change to the website that copied payment-card data. Cathay Pacific’s report records Group One activity from 15 October 2014 and detection of suspicious activity on 13 March 2018. Asco, VT San Antonio Aerospace and Swissport are ransomware reports, and none of those three states a volume of stolen data. SITA’s statement is about passenger data on a supplier’s servers. Boeing’s statement, as Reuters printed it, is that a criminal ransomware actor released information it alleged to have taken from the parts and distribution business.

Two rule points sit next to that list. The point titled information security incidents — detection, response and recovery is IS.I.OR.220. Interfaces are IS.I.OR.205(b):

SITA’s statement is the illustration: passenger data processed for airlines was stored on the supplier’s servers. The quote requires the organisation to identify that kind of interface. It does not, by itself, say the interface is an unacceptable risk.

The next guide in this series turns to shop-floor, office and contract habits. It is not a claim that any of the eight documents priced the recovery.