The BA Fine – How British Airways security flaws let data theft unfold

How will the BA Fine affect IT security? After over a year of delay, the Information Commissioner’s Office (ICO) finally issued their much-anticipated Penalty Notice against British Airways on 16th October 2020.

There have been headlines and debate around the size of the penalty. But the real focus should be on what the Notice tells us about the ICO’s approach to assessing whether an organisation is following the GDPR with regards to information security.

“When organisations take poor decisions around people’s personal data, that can have a real impact on people’s lives. The law now gives us the tools to encourage businesses to make better decisions about data, including investing in up-to-date security.” ICO press release.

We have distilled the 114-page Notice into three insights containing the key lessons to learn:

  1. The data protection landscape is changing – act now 
  2. How British Airways security flaws let data theft unfold
  3. The boardroom’s responsibilities – what are your business risks?

Join our webinar on THU, NOV 12, 2020 10:00 AM – 10:45 AM GMT to find out how the fine will affect IT security.

 

The fine is a significant opportunity to engage with the business afresh

The BA case provides the first detailed view of how the ICO will approach looking at IT security and the GDPR.

At its core, the case highlights that IT departments will likely struggle to demonstrate how they are ensuring the organisation is complying with the GDPR’s security requirements without input from the business and data protection expertise.

This is because the GDPR’s approach to security requires a number of different considerations, only some of which are within the typical IT department’s skill set.

IT should be able to outline:

  • The threats and risks faced by the systems and processes it overseas.
  • The technical options available to mitigate those threats and risks, highlighting whether they are industry standards.
  • The costs of implementing those options.

Yet it is important to recognise that it is for other colleagues in other departments to

  • Assess the value and sensitivity of data and its importance to people if it were mishandled (i.e. to assess the risk to the rights of data subjects).
  • Consider the nature, scope, context and purposes of processing and how this should be reflected in the resources the organisation is willing to commit to this area of risk.
  • Consider the operational, commercial, regulatory and ethical risks the organisation faces when handling data.
  • Consider all these factors, alongside the input from IT, in order to agree what it considers to be the appropriate technical and organisational measures that will deliver an appropriate level of security.

The organisation can then instruct IT to implement these measures. IT is then responsible for deploying the measures and maintaining the operational functionality of systems.

After the BA case, IT can never again be just about IT.

 

 

A strong relationship between IT and Data Protection experts is key

 

The BA case highlights the importance of IT and data protection experts working together in order to ensure their different but related skills and knowledge are aligned for the benefit of the organisation.

Working together can ensure consistent assessments of risk so that the available options, their benefits, costs and risks can be presented to decision-makers and a risk-based decision made.

As well as being important for the selection of appropriate security measures, a strong working relationship is also an important factor in ensuring IT projects do not result in systems that fail to comply.

If Data Protection and IT experts work together from the outset of new projects, adding their expertise alongside input from the business into Data Protection Impact Assessments; consider how the system can be built on the principle of Data Protection by Design and Default, and articulate the impacts (in cost, time, functionality) and benefits of potential solutions, the project can deliver business outcomes and ensure GDPR obligations are met.

 

Systems need to be properly managed and resourced 

 

The BA case highlighted the importance of managing all aspects of your systems and in particular the need to support this with appropriate paperwork that matches reality.

At various points, BA tried to defend its approach to different aspects of information security. It was often unable to provide evidence of its decision-making.

For example, BA tried to say that it was following guidance when not requiring Multi-Factor Authentication (MFA) for certain remote network access. But when pressed for evidence of the decision making behind this approach, the ICO flagged that:

“Given…that no copy [of the risk assessment] can now be located, it is not possible to say that BA took into consideration the risk, the state of the art, the cost, or the available technical measures when deciding what security was appropriate.” (6.26, p34).

Similarly, when the ICO ask why other measures had not been considered or implemented, BA’s arguments failed to convince:

“BA argued that it was untenable to suggest that whitelisting was an alternative in practice…However: (i) there is no evidence that BA considered what alternative measures could be put in place as an alternative to MFA…and (ii) even if BA is correct that this solution would not have proven viable, it does not obviate the need to consider appropriate measures or explain why other appropriate measures were not in place” (6.27b, p35)

You, therefore, need the paperwork as evidence and to support your decision-making, especially if the decision is to accept a degree of risk.

In the BA case, decisions made by IT, whether deliberately or not, accepted a lot of risk on behalf of the business. This was often for the sake of pragmatism.

For example, BA tried to argue that the storage of credentials in plain text within scripts saved time, was standard practice and/or an acceptable way of ‘aiding functionality.’  The ICO notes that:

“If this is why BA stored passwords in this way, that is not an acceptable reason…when considering the minimal time saving it  allows,  the high risk it poses, and the alternative methods…available to BA as an organisation.” (6.74, p49).

Maintaining a risk log can help as it provides a place to document risks, their possible impact, and the solutions available. The decision whether to select a particular solution or accept a degree of risk can be presented to decision-makers, escalated where necessary and kept under review.

The ICO also noted how often BA’s policies and statements did not reflect the reality of what they found happening in practice.

For example, at a policy level BA said Multi-Factor Authentication (MFA) would be used for all remote network access. When challenged to explain why 13 of 243 application were not actually protected by MFA, the ICO concluded that:

“BA has not provided a satisfactory explanation as to why…it was deemed unnecessary for certain applications…to comply with the policy requiring MFA.” (6.21, p32-33).

Paperwork must therefore reflect reality. The GDPR’s accountability principle requires organisations to maintain evidence of their compliance and the effectiveness of their measures. Decisions around IT security should therefore be a reliable, true and honest reflection of your approach, and/or decisions to change, amend or deviate from agreed policies and procedures.

And finally, it is worth noting that the ICO highlighted to BA that:

“None of the…measures [the ICO had highlighted] would have entailed excessive cost or technical barriers. They are all readily available measures available through the Microsoft Operating System used by BA” (6.72, p48)

 

 

Senior management will be more likely to listen

 

For too long, IT Departments have been asked to achieve more with less; issues have been seen as something solely for “IT to sort.” And the business has left many decisions about risk and what is appropriate to IT when, as outlined above, they should not have been.

And for too long, IT Departments have often struggled to bridge the gap between heavy, technical detail and explaining why it needs resource to support the business in achieving its objectives. They have struggled to find language that the business, particularly senior decision-makers, can understand, recognise, and act upon by providing sufficient resource or accepting risks on behalf of the business.

The BA case demonstrates the importance of finding a way to translate the IT threats and risks an organisation faces into the practical, possible impacts that they will have on the people whose personal data is being processed. This should in turn enable the business to understand the risks alongside the costs of different technical measures available to them and place these against the other risks it faces.

The ICO noted that BA:

“has indicated that expenditure on IT security will not be reduced as a result of the impact of Covid-19.” (7.46, p73)

It is important to recognise that BA is now, after the event and with the ICO watching, are having to use unplanned time and resource to address security issues as well as make a public commitment to future spend in this area.

Organisations should not get into this position. The ICO is frequently at pains to highlight that the law requires appropriate measures to be in place depending on the circumstances of each organisation.

“The Commissioner does not find that simply because an attack took place BA was in breach of its obligations under the GDPR. Instead, the Attack which did occur exposed the fact that BA had failed to secure its systems in an appropriate manner.” (6.111, p59)

The ICO is interested in “whether a particular data controller has taken appropriate steps by reference to the data it is processing.” (6.106, p58)

 

 

Learn from what happened and recognise the areas that relate to your current approach to security

 

Context

The ICO’s report lists considerable failings on BA’s part. The timeline below represents a portion of the high-level events and things to learn.

 

Timeline

22/6/18

An attacker obtained five sets of credentials to the company Citrix portal. The supplier, Swissport, operated at an airport in Trinidad and Tobago. No mention was made about how the credentials were obtained, although four methods are possible (1) Purchasing them (2) A camera recording logins (3) Social Engineering (4) Use of a keylogger.

User training would have prevented social engineering and endpoint protection (although this was unlikely to be an appropriate solution in this case given that it was third party hardware) could have been configured in such a way as to prevent keyloggers. None of the four methods would have been successful if multifactor authentication had been in place.

On gaining access to the portal, the attacker discovered that it had not been hardened as per Citrix’s own published standards. The attacker was, therefore, able to breakout by running a program that was either not intended for users or was uploaded. The details of this are not published, however, it is implied that this program was possibly IT admin related. It is also implied that the users had more access than they required.

On breaking out of the portal, a plain text file was found on the network containing system admin passwords. There is a suggestion that this was a code for applications.

  • Use of application blocklists and allow lists would have been appropriate in Citrix. Alerting should have been configured to report attempted access to unauthorised applications.
  • A process for system implementation and risk assessment should have been in place to ensure all systems were configured to agreed standards.
  • Additionally, the least privilege principle should have been used on the Microsoft user accounts.
  • Penetration testing should have been undertaken.
  • A password management or Privilege Access Management (PAM) tool should have been in place.

 

23/6/18

The System admin credentials from the plain text file were used. They were out-dated and were unsuccessful.

A system monitoring alert could have been set up regarding the failure of SA logons. It is implied that a suitable system was in place, however it was not configured appropriately. The attack could have been stopped here.

 

25/6/18

The attacker successfully logged into 3 servers using local accounts. No details on how are published thereby implying a security exploit and possible patch management issue. By adding the guest account to the local administrator group they were able to use that to gain local admin capability.

Patch management and system monitoring for Event 4732 (inclusion of an account into the local admin group) would have interrupted this attack vector.

 

26/6/18

The attacker located DBA credentials.

 

26/6/18

The attacker located log files containing payment card details in plain text. BA stated that this was in there for testing purposes but was not removed when promoted to live. This led to a breach of 108,000 records.

Intelligent network security applications or hardware would have blocked and identified the movement of these records.

The attacker was able to scan BA’s system thoroughly without alerting any monitors and alter some JavaScript code in the Modernizr application which was last updated by BA in 2012, to redirect payment card details to a server controlled by the attacker. It is implied the code was changed in a Development environment and the attackers waited for it to be promoted to Live as part of the normal release cycle.

Manual reviews of such high-volume transaction codes should have been undertaken. There was no alert to report on code changes.

 

14/8/18 – 5/9/18

The above actions led to all payments (including card and CVV data) on BA’s website being copied and redirected to ‘BAways.com’, a domain controlled by the attacker.

 

5/9/18

A 3rd party identified payment data being copied to an external domain and notified BA.

 

Conclusion

The security of the infrastructure was either not considered or thought of as a sufficient threat to address even though it suggests third parties had BA domain accounts. There may be several reasons for this. Certainly, this suggests a lack of knowledge of staff in terms of security configuration of Citrix. It also implies that IT management did not make that a priority of the admin staff. It further strongly implies that Senior Management was carrying risks that they were unaware of or disinterested in.

As BA had the resources to address these issues, the fundamental failure here was likely to be one of communication. No IT team would intentionally introduce the security issues mentioned above. Senior Management should have provided appropriate resources and guidance as well as insisted on appropriate risk management reporting.

 

 

Where Protecture can help

Protecture does not view Data Protection (DP), Information Security (IS), IT and Leadership-led risk management as being separate entities. It is not possible for each of those individual specialities to be successfully implemented without the other three. We understand the overlap, that each need to communicate and each speak different languages. We can help you break down internal barriers, unlock budget by highlighting the risks and implement the solutions you require.

Whilst our individual services focus on IS, DP, IT and Risk, they all delivered by people that understand the interaction of them. Through partnerships with best in class manufacturers, software creators and specialists, we are able to address all of the issues listed above in a way that suits your business requirements.

We can help you Manage Data Fearlessly.

Join our webinar on THU, NOV 12, 2020 10:00 AM – 10:45 AM GMT to find out how the fine will affect IT security.