
British Airways faces record £183M fine for data breach - adzicg
https://www.bbc.com/news/business-48905907
======
K0nserv
> At the time, BA said hackers had carried out a "sophisticated, malicious
> criminal attack" on its website.

Compromising a single JS resource that was being carelessly loaded on a
payment page doesn’t qualify as sophisticated in my mind. It might not be
uncommon in the industry, but tools like SRI and CSP stop these attacks dead
in their tracks.

I believe we are about one huge attack[0] of this kind away from realising how
dire the situation truly is.

As a victim of the earlier Ticketmaster attack I’m curious as to if the ICO is
investigating that too.

0: [https://hugotunius.se/2018/11/29/how-to-hack-half-the-
web.ht...](https://hugotunius.se/2018/11/29/how-to-hack-half-the-web.html)

~~~
zemnmez
> but tools like SRI and CSP stop these attacks dead in their tracks.

this isn't... usually true. in the case of this attack, the Javascript was
appended directly to a 'known good' library resource[1]. Typically CSP
whitelists based on origin, which would make CSP ineffectual in this case.
Also, websites like BA have advertising, and it's nearly impossible to run CSP
with ads unless you use the `strict-dynamic` directive, which whitelists any
javascript loaded by your javascript recursively... including this
javascript[2].

There are other, more uncommon modes for CSP which you might be referring to:

1\. Nonce, which provides protection by ensuring each script has a server-
calculated one-time-use token. This would not have any effect, as the script
is part of one naturally loaded by the server.

2\. Hash[2], which provides protection by checking the script's content
against a predetermined hash. This _possibly_ could be effective, but in
practice rarely is. If the attackers could edit this script, there's
absolutely no reason to believe either (1) this just updates the generated
hash or (2) the attackers cant just update the hash. (this is essentially the
same as SRI). Hash is potentially effective where taking advantage of a third-
party CDN with known content that should not change, but by the look of the
url:
[http://www.britishairways.com/cms/global/scripts/lib/moderni...](http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js)
the resource was not on a CDN.

[1]: [https://medium.com/asecuritysite-when-bob-met-alice/the-
brit...](https://medium.com/asecuritysite-when-bob-met-alice/the-british-
airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50)
[2]: [https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Co...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src)

~~~
K0nserv
From the reporting I've read, primarily by RiskIQ, in both the Ticketmaster
and BA case it was not the origin servers that were compromised in which case
SRI would have been effective in so far that it would have required the
attackers to compromise the origin servers too at which point it's all game
over anyway.

So I would assert that SRI would have stopped both these attacks.

~~~
zemnmez
i cant find any hits for "origin" or "CDN" on the original RiskIQ article:
[https://www.riskiq.com/blog/labs/magecart-british-airways-
br...](https://www.riskiq.com/blog/labs/magecart-british-airways-breach/)

the RiskIQ article identifies the location of the script as "the main website"

additionally, I'm not sure how this would solve the problem. If BA went to all
the effort of putting their frontend assets on a CDN, why wouldn't their HTML,
with the hashes also be on the CDN? and if the hashes are not generated by the
CDN, how does the server generate the hashes without being affected by changes
on the CDN? regardless of outcome, if the process is automated, does a human
being need to read a diff every time any file on any CDN changes? Can't an
attacker then just wait until the hashes are automatically updated?

~~~
K0nserv
Sorry I should have been clearer here. RiskIQ doesn't distinguish between the
CDN and origin in their write up. That's an assumption on my part, I believe
it be the case that the CMS that serves the JS file is different from the
origin server that would be serving the checkout pages and other parts of the
BA website. From a quick Google it looks like the CMS path on BA is just a
file storage server of some kind.

Most likely the origin server had a hardcoded reference to the CMS
path([https://www.britishairways.com/cms/global/scripts/lib/modern...](https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js))
and if that had been done as

    
    
        <script type="text/javascript" src="https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js" integrity="sha384-5XrDTQbmmgpJKmfKW8outDDdYpRCnIf+nxX2nVR10NyWby6pPcujAELgWVmCu2P/"></script>
    
    

I speculate the attack would not have been successful. For an extremely static
resource like this it wouldn't have been complex to adopt SRI.

------
EnderMB
I'm glad to see a solid fine given for a data breach.

I've worked on projects in this sector before, and it's a common story to
others - client cuts cost as much as possible, until the risk of an inferior
product has grown too high to handle. It's a race to the bottom, and security
rarely comes into consideration outside of a basic pen test being mentioned
(if it happens).

Still, I'm quite annoyed at the lack of follow-up against what is blatant
bullshit from BA. When your business is so heavily reliant on taking payments
online, their security procedures should be airtight. I can understand that
it's quite a clever hack, but it's security 101 to know what third-party code
is doing on your server.

The fine is good, but it would be nice to enforce rules where a company caught
in a data breach has to accept liability and not contest the severity.

~~~
koheripbal
This amount represents more than their profits for roughly two years. It isn't
realistic and is likely a number released to make headlines.

The point of regulation is to change corporate behavior, not drive them out of
business.

The stock market does not seem to think the fine will ultimately be anywhere
near that high, with a drop in stock price of only 1.5%.

As always, beware of headlines.

~~~
EnderMB
I'm not too bothered by the number, but am worried that a company will be able
to talk their way out of punishment through misinformation.

You only need to look at the latest Zoom vulnerability, and the Panera Bread
data leak to see how companies will happily tell its users that everything is
fine, while doing absolutely nothing to publicly resolve the issues being
raised. To make things worse, a lot of people will blindly believe this, or
take their side to be contrarian.

As you've rightly said, regulation needs to change corporate behaviour, and
while a hefty fine will do that, it's also a minor risk to a firms ongoing
reputation. It's a cost that can be offset elsewhere - more than likely onto
the customer. I would rather the fine be halved or even quartered, if it meant
that BA had to publicly accept full responsibility, and to push for
independent auditing of all of their software.

------
jrpt
For those who are wondering what happened, British Airway’s website had
malicious JavaScript included in some files they were using. Compromised third
party libraries (in this case, the Modernizr library) was the attack vector.
The malware would take sensitive data off the webpage and send it back to the
hackers surreptitiously.

Most sites still would have no idea if this were to happen to them today.

That’s why I’ve developed Enchanted Security
([https://enchantedsecurity.com/](https://enchantedsecurity.com/)) - a virtual
content security policy that tracks the network requests and even blocks
malicious ones. It’s like a firewall but running on your users’ browsers. This
would’ve prevented what happened to British Airways. Get in touch if you’re
interested in learning more.

~~~
donaltroddyn
Interesting approach, but doesn't using your product add another attack
vector? Surely Enchanted's CDN will be a rich target for attackers.

Full disclosure: I'm in private beta with a product that periodically loads
production sites and compares all executed JS to the last-known-good profile
(usually from CI prior to deployment), and raises warnings if anything
changes. We don't run in actual users' browsers, so we won't see malicious
code as early as Enchanted, but you don't have to trust us.

~~~
jrpt
For your first question, there's an optional hash you can add that locks the
code to its known hash. Also, you can self-host everything if you like.

The type of product it sounds like you're running is a scanner and scanners
have a couple problems. First, there's cloaking: if the malware can detect
that it's a scanner (usually pretty easily) then the malware doesn't activate.
Second, the malware comes from trusted code that you already think is trusted,
and that's a problem if you overlook something because it's trusted. By
contrast, Enchanted Security would see it since it runs on every users'
browser all the time.

~~~
donaltroddyn
To be honest, if you can get clients to reliably use SRI, that's probably
better protection than either of our products.

Yeah, our product could be classed a scanner, but there's no (little) risk of
cloaking, as the network request or JS loaded to work out whether we're a real
user is enough by itself to raise the alarm. To pull it off, the attacker
would have to compromise the host of a trusted resource, determine that we
were a scanner from our network request alone, and serve to us the original
resource. There's a few ways to help ensure that our network requests aren't
easily recognised, which is part of our "secret sauce".

Our approach does protect against the case where an attacker gets access to
the client company's server and makes changes to the resources served, which
can allow them to work around / selectively serve embedded snippets.

The second problem you mention isn't an issue, as we don't trust hosts, only
the hash of resources (the same idea as SRI).

~~~
jrpt
Depending on how the code is being served, cloaking is a big problem for
scanners... if you think it's no risk you're probably overlooking the risk.
Google put out a report on it and there's lots of papers on it and related
topics like VM detection in browsers.

You can use SRI for something like a specific version of jQuery, but not for
most of the products people are relying on that have more dynamic
functionality.

SRI isn't practical for third party resources that are expected to change over
time, which is actually a lot of third party resources. For example, a chat
script like Intercom will change when someone from marketing makes a change
that affects its frontend settings. This may be changing some text or
coloring. So you can't pin it with SRI.

In your case, if your product tells you that some marketing script you're
using changed hashes, how would you know whether that was a valid change or
whether an attacker introduced malware?

~~~
donaltroddyn
> Depending on how the code is being served, cloaking is a big problem for
> scanners... if you think it's no risk you're probably overlooking the risk.
> Google put out a report on it and there's lots of papers on it and related
> topics like VM detection in browsers.

Almost all bot/automated test/scanner detection relies on JS in the browser,
which is too late to avoid triggering an alert with our approach. The attacker
would have to identify us from our network request to load the compromised
resource alone, for which we have (so far) effective mitigations.

> In your case, if your product tells you that some marketing script you're
> using changed hashes, how would you know whether that was a valid change or
> whether an attacker introduced malware?

We'll alert the client company for any resource that's changed - you can't
trust that any third party resource change is okay, especially if the
reputational and legal cost of a breach can exceed 10's or 100's of millions.

Most third party code from reputable companies, including tracking tagging,
doesn't change that often, and client security/ops teams tend to be horrified
by the ones that do. Each time some third party silently replaces code that
they're serving, it introduces new opportunities for bugs, breakages, and
attacks.

I really disagree with you about SRI. SRI isn't sufficient to prevent all
client-side attacks, but it is very effective, and when enterprise customers
demand it, third-party services almost always find a way to support it.

------
planetjones
Seems very just. BA clearly had no controls to understand the code running in
production was the code they had deployed. I hope this serves as a wake up
call to other companies who have a blatant negligence for infosec.

~~~
buro9
> clearly had no controls to understand the code running in production

This applies to everyone who has advertising or third party anything on their
page, no?

~~~
isostatic
If they choose to import some code from elsewhere sure. They could run their
own advert by hosting "advert.jpg" on their server and wrapping it in an
anchor tag.

BA however are a company selling their own product, no need for them to have
adverts. If they want to dilute their product with adverts then they take the
risk of fines (as well as losing custom)

~~~
ginko
Why does an airline even need to show advertising on their page in the first
place. You'd think they would be most concerned about selling their own
product.

~~~
donaltroddyn
Many of them show ads for partners to generate ancillary revenue, which is a
large source of profits for airlines.

In addition, if they themselves _advertise_, they'll need to add tags to track
attribution, conversions, etc.

~~~
isostatic
Funny how people advertised for decades on tv, in newspapers, and with
leaflets through the door, without invasive tracking

~~~
donaltroddyn
Fair enough, but if you're advertising online with any of the major companies
today, there's no way to do so effectively without instrumenting at least your
landing pages and conversion pages with advertising tagging.

------
topogios
"The information included names, email addresses, credit card information such
as credit card numbers, expiration dates and the three-digit CVV code found on
the back of credit cards, although BA has said it did not store CVV numbers."

Is it standard for airlines to handle storing payment card details themselves
and hence having to be PCI certified instead of delegating to a PSP?

~~~
robjan
Someone injected Javascript into their pages which collected this information.
But, yes, it's standard practise for airlines to store card information
(excluding the 3/4 digit code) in the customers' PNR (Passenger Name Record)
in the airline's GDS (Global Distribution System). The details are on this
page: [https://servicehub.amadeus.com/c/portal/view-
solution/965353...](https://servicehub.amadeus.com/c/portal/view-
solution/965353/en_US/ticketing-and-fare-elements-form-of-payment-fp-)

~~~
namdnay
Just a quick clarification, in the case of an airline website, the PNR will
not be created through the GDS (too expensive), it will be created directly in
the PSS (usually managed by the same company)

~~~
robjan
Think it depends on the airline and whether they allow agent bookings. Last I
knew, BA.com created them on 1A but that may have changed with NDC.

~~~
namdnay
For web they create them on 1A, but directly in 1A PSS, not going through 1A
GDS (and therefore not paying the GDS fee, just a PSS fee). This is the case
for all direct channels (websites or airline call centers) of all airlines

------
jajag
Statement on the Information Commissioner's website:
[https://ico.org.uk/about-the-ico/news-and-events/news-and-
bl...](https://ico.org.uk/about-the-ico/news-and-events/news-and-
blogs/2019/07/ico-announces-intention-to-fine-british-airways/)

~~~
Anthony-G
The statement shows that the ICO investigated this data breach on behalf of
other data protection regulators of other EU states. As an Irish citizen, I
wish our Data Protection Commission was as serious about protecting the
personal data of EU citizens.

------
OliverJones
UK's ICO and other data security enforcers are acting. That's good. They're
changing companies' calculus about putting resources into infosec. That's even
better.

The public and press perceive that "justice is served," so we're tempted to
think the problem is solved. I don't think that's helpful. These fines don't
address root causes of the problem. They don't make our systems more
resilient.

They're drawing a significant amount of money from the system and transferring
it to their governments' general accounts. Is that the best use of that money?
Should some of that money be used to help address infosec problems? To fund
training for citizens, legislators, and governments? To step up law
enforcement efforts against cybercreeps? To publicly fund independent security
researchers (white-hat hackers) to help detect this stuff and nip it in the
bud? To help subsidize the significant expense of comprehensive infosec audits
for municipal governments, ngos, and small firms?

Here in USA, the National Security Agency has, by hoarding zero-day exploits
and inadequately protecting them, done major infosec damage to civil
institutions worldwide (UK's NHS, the Baltimore city government, you name it).
I suspect similar things have happened in other governments. To what extent is
it their responsibility to help clean up the mess? Can other governments use
their resources to backfill where the US government can't or won't act?

Do governments now join identity thieves as enemies of people doing infosec?
That cannot be good. We have to get this right and we can't do it if we're
fighting each other rather than the criminals causing the trouble.

~~~
M2Ys4U
>They're drawing a significant amount of money from the system and
transferring it to their governments' general accounts. Is that the best use
of that money? Should some of that money be used to help address infosec
problems?

Well the point of these fines is to say to organisations "put your money into
infosec, or when you have a breach it'll probably be your fault and we'll take
that money as a punishment".

>Should some of that money be used to help address infosec problems? To fund
training for citizens, legislators, and governments? To step up law
enforcement efforts against cybercreeps? To publicly fund independent security
researchers (white-hat hackers) to help detect this stuff and nip it in the
bud? To help subsidize the significant expense of comprehensive infosec audits
for municipal governments, ngos, and small firms?

The NCSC[0], GCHQ's defensive side, publishes advice for the public,
companies, charities, schools, government departments etc.

[0] [https://www.ncsc.gov.uk/](https://www.ncsc.gov.uk/)

------
jfk13
Just FTR, note that BA might appeal against this, so it may be subject to
revision before it's all over...

“BA has 28 days to appeal. Willie Walsh, chief executive of IAG, said British
Airways would be making representations to the ICO. "We intend to take all
appropriate steps to defend the airline's position vigorously, including
making any necessary appeals," he said.”

------
xhgdvjky
This may be the beginning of the end of hiring front end devs in house.
Suddenly they are a serious liability... much nicer if you can pass on the
fine to a third party!

~~~
barking
I'd say it's likely to be a game changer when it comes to skimping on IT in
general, whether in-house or outsourced. It's good news.

------
olliej
So this is ~$366 per person whose data was compromised. That seems fairly
cheap all things considered.

It's a far sight better than the "credit protection" they normally provide
(from our point of view, rather than the people who are used to not having any
penalties for abusing their customers). Remembering of course that the typical
cost to companies making when they settle with "credit protection" is much
lower than the already low $30 individuals would have to pay.

I'm also tired of newspapers parroting press releases that say things like
"sophisticated, malicious criminal attack". Just like a few years ago every
publicly exposed+default password service was compromised by "Nation state
attackers", and before then "Advanced Persistent Threats". If you make a claim
like this, you should be required to provide the full details of the attack:

\- what level of employee account was compromised, and if none was needed, why
not? Otherwise, did the targeted employee need the level of access that the
attackers used? If not, why did they have it? Simply being a C-level executive
does not imply requiring access.

\- Did it make use of any software exploits? If it did, were those exploits
fixed in the release versions? If those exploits were fix in released
software, why was that out of date software being used?

\- Is your company using established best practices: 2FA for all accounts, TLS
for all networking, service isolation.

\- Did the compromise come about due to loading content from a third party? If
so, how was that code authenticated (multiple browsers support SRI)? Was that
code used to support the site functionality, or was it for tracking or
advertising?

This seems like a perfectly reasonable bare minimum if you want to support a
claim that the compromise was unavoidable.

------
biddlesby
Do the regulators take into account whether the firm is actually at fault?

Without considering what happened in this specific scenario, surely there are
cases where companies take the utmost care, follow standard security
principles and still get hacked; or the issue was not with the company
operating the website but rather with, say, a hardware manufacturer?

~~~
dalbasal
They do in some form. Largely though, "regulator" action tends to be outcome
based. Relying on "standards" can be difficult. In some caes, standards exist
and ignoring them can point to negligence. Conversely though, standards don't
exist for a lot of things and when they do, they're not a full solution. IE,
it's possible to follow "standard security practices," while still being
insecure. If regulators make that a "get-out"... you may as well just have
legislation instead of a regulator.

In recent times, regulators and legislators don't understand the problems
(maybe no one does) sufficiently to be specific with rules. They demand
general things, outcomes (you will not lose data) and general operating
principles (you will secure your users' data , have good policies, and enforce
them).

Both data protection (eg gdpr) and anti money laundering rules are examples of
recent areas that work this way. If a bank's customer has been depositing
stolen money, financing terrorism or something... the bank is at risk. Their
policies will be examined and circumstances do get taken into account, but the
"standards" they're judged against aren't absolute and standards compliance
doesn't totally protect them. OTOH, if they don't adhere to their own policies
or the policies are bad... it is enough to get them in trouble.

Lawyers, btw, hate this emerging system.

In short, modern "regulator enforcement" is a lot less legible & "letter of
the law" oriented than legal environments that we are going used to.

~~~
M2Ys4U
This is far from being a new development in Europe. Regulators have never been
a strict rule interpretor

------
alkonaut
Excellent. Now I wish they pick another big corporation (just pick one) and
hand them a similar fine for using a standard GDPR opt-in-by-default popup.

They need to make it clear through _action_ , not just vague wording, that
having a default of allowing all tracking is not ok.

Pop ups should say “hi and welcome to site X. Click the yelliow button to
enter with tracking/personalization and the blue button to enter without”.

~~~
Jnr
The company I work for explains it to our customers that we can't enable any
tracking cookies, analytics, external chat scripts and other external scripts
unless visitor opts in. I explain that it is against the law and they back
down.

Sadly not many people in the industry realize it and they keep doing whatever
they were doing for years.

------
kkm
Websites need to really up their game, specially given the amount of third-
parties they are using.

I've tried highlighting similar issues in the past, where even if there is no
active breach, but they are leaking sensitive data to multiple third-parties
when it's not needed in the first place.

[https://dev.to/konarkmodi/watching-them-watching-us-how-
webs...](https://dev.to/konarkmodi/watching-them-watching-us-how-websites-are-
leaking-sensitive-data-to-third-parties-1nn3)

[https://news.ycombinator.com/item?id=16516687](https://news.ycombinator.com/item?id=16516687)

------
rlpb
Original source: [https://ico.org.uk/about-the-ico/news-and-events/news-and-
bl...](https://ico.org.uk/about-the-ico/news-and-events/news-and-
blogs/2019/07/ico-announces-intention-to-fine-british-airways/)

------
TomAnthony
Is there a good reason for them not to launch a bug bounty program?

The cost of doing so would be significantly cheaper than any future fines, and
would reduce the chances of future breaches.

------
jeffail
"amounts to 1.5% of its worldwide turnover in 2017"

I imagine that's a significant sum but I'm struggling to get my head around
it. If so then good for the ICO I suppose. I remember reading endless comments
a few years back speculating GDPR would never have any bite.

~~~
dtf
The maximum fine of 4% of parent company IAG's turnover would have been almost
€1bn.

------
simion314
Is good that we see on the font page of HN more GDPR fines for non US
companies because I seen a lot of US users accusing that only US companies are
targeted(there are other non US examples but those did not appeared or stayed
on the first page here on HN ).

~~~
pjc50
Yes, there was always that weird nationalist claim that GDPR was just a
protectionist measure rather than a sincere attempt to achieve its stated
aims.

------
sbhn
So who gets the money? The people who had there data stolen?

Who gets the money are the people who create laws. The more crimes commited,
the safer there jobs are. The people who had there data stolen, are now on a
register sold to the insurance industry, and the insurance industry decides
they are a greater risk to insure, so the costs to the consumer go up. Strange
how crime really drives the economy.

~~~
dtf
The Treasury. Fines are sent to the Consolidated Fund (the government's
general account at the Bank of England).

~~~
graphene
From the article:

    
    
        Where does the money go?
    
        The penalty is divided up between the other European
        data authorities, while the money that comes to the
        ICO goes directly to the Treasury.
    

So it seems most of it will go to other European data authorities.

~~~
dtf
Ah thanks, I missed that. It usually all goes to HM Treasury but this is a
joint operation between multiple EU supervisory authorities.

"ICO has been investigating this case as lead supervisory authority on behalf
of other EU Member State data protection authorities. It has also liaised with
other regulators. Under the GDPR ‘one stop shop’ provisions the data
protection authorities in the EU whose residents have been affected will also
have the chance to comment on the ICO’s findings."

[https://ico.org.uk/about-the-ico/news-and-events/news-and-
bl...](https://ico.org.uk/about-the-ico/news-and-events/news-and-
blogs/2019/07/ico-announces-intention-to-fine-british-airways/)

------
dijit
This is a death knell for BA, my friends father is a high level manager and if
he’s to be believed they are running on major thin margins.

Mostly due to compensating employees fairly in the 90’s-early-2000’s. Now
they’re desperately trying to remove those compensation packages.

Although it could just be cost aversion masquerading as a hard requirement.

~~~
isostatic
BA has becoming a low cost carrier over the last 10-15 years and make a large
profit from it. They're trading on their past glories and failing to innovate.

Last time I traveled BA in first it was shocking, rude crew, dirty seats.
FinnAir in Business on the other had is a joy to behold.

I used to hit 2500 tier points a year on BA metal, I barely make 300 now, just
occasional short flights in europe, but they've doubled-down on the 737 max,
so I guess that will end soon too.

~~~
magduf
>Last time I traveled BA in first it was shocking, rude crew, dirty seats.
FinnAir in Business on the other had is a joy to behold.

It seems like the American and European airlines are all going down the tubes,
unless you shell out for business class on certain ones. The Asian airlines
are the best ones these days; you don't have to pay extra for a first-class or
business-class ticket to get superb service and cleanliness there.

------
sneak
Too bad this will all go to the state and not to any of the people who were
actually damaged in the breach. :/

~~~
aw3c2
The state is made up by the people it represents so by this, society benefits
as whole.

~~~
sneak
Not only is this false in the national sense, as the machinery and personnel
of the state are not coterminous with those they rule over, but it is also
false in this specific sense, as many of the people who were harmed by this
breach (such as myself) were not involved or are not permitted to be involved
with the regulatory body that is assessing this fine.

Many people who are not British subjects are customers of BA.

The ICO does not represent me, yet somehow they are getting paid for the
misuse of my data.

It’s nice work if you can get it.

~~~
ddalex
The fine is not there to repair the damage made to individual customers. The
fine is there to punish the Corp for its bad practices, and to scare other
Corps into having good data protection practices. It's a punishment and a
deterrent.

If you want personal compensation, free to sue BA.

~~~
amelius
From the article:

> Where does the money go?

> The penalty is divided up between the other European data authorities, while
> the money that comes to the ICO goes directly to the Treasury.

> It is up to individuals to claim money from BA, which provided no
> information on whether any compensation had been paid.

So you are right.

It would be nice if a portion of the money goes back to ICO, so they can grow
and have a chance to focus on smaller fish as well.

