What to do following the British Airways Breach
If you’ve been paying any attention at all to the news in the last couple of weeks, you’ll be aware that British Airways had a significant and embarrassing problem with their website. You can read about it here, with quotes from me! I, and most other commentators, were fairly certain that this the stolen credit card data of 380,000 BA customers was stolen in real time, as they were making bookings, and indeed this turned out to be the case. The RiskIQ analysis shows exactly what happened (though doesn’t identify exactly how the hackers got access to make the necessary changes) and links the breach to other similar activity, including the breach at Ticketmaster.
The cyber criminals compromise websites that process credit card payments in this way because, if they are successful, it gives them all the data they need to conduct fraud. Any other protections – the use of SSL (the little padlock at the top of your browser), securely storing of customer details, are rendered useless. The goal for these gangs is to compromise websites of companies that have a lot of customers, and hence a lot of credit card transactions. The actual value of each transaction does not matter to the cyber criminals, they just want the details of as many customers and their credit cards as possible.
So what can you do? Firstly, review which third party scripts you have active on payment pages, and remove any that aren’t necessary (as the initial compromise can be at the third party – it doesn’t need to be your website that is breached).
You should also read this post by Scott Helme – if you are processing payments, setting up CSP is a good way to block one avenue of attack by ensuring content can only be loaded from approved domains. SRI may be harder to implement, but certainly discuss it with your web team.
You can also monitor your website infrastructure directly – if you host it yourself there are open source tools (such as ossec) you can use that will alert you to any changes of files you identify as critical. Whatever approach you choose some kind of security monitoring of your website is a good idea, and remember there is no point deploying the monitoring tools if you don’t have anyone monitoring their output.
I wrote about security monitoring recently, and the requirements for GDPR compliance.
In short if you are processing credit card transactions through your website, right now you should;
- Check your website for vulnerabilities, yourself or using a security supplier (if you are moderately technical then have a look at something like this from Tenable)
- Review the third party components of your website, especially on the payment pages. Do you load any content from other domains at the point of payment? Are they all essential?
- Read Scott’s blog above, and at least implement CSP
- Implement security monitoring, so you can be alerted to unauthorised changes on your website.
As usual, if you have questions or want help, please get in touch.
Thanks for reading
Rob