Lacking 2 cyber controls lead TalkTalk to lose 150k customers in just 3 months

talktalk-logo-608x342On 21 October 2015 TalkTalk, a major UK telecommunications provider with over 4 million customers, suffered what it called a “significant and sustained cyber attack”. Ultimately this attack lead to over 150,000 TalkTalk customers to leave its service in just 3 months and lose a reported £45m. But here’s the thing; this attack and the subsequent losses were completely avoidable.

We are very sorry to tell you that yesterday a criminal investigation was launched by the Metropolitan Police Cyber Crime Unit following a significant and sustained cyber attack on our website on Wednesday 21st October.

-Trista Harrison, Managing Director (Consumer) of TalkTalk

This story has been well covered in the media and tech journals. But how did this happen? How can your company avoid the same fate as TalkTalk?

Now that the fog of war has lifted from this event, let’s take a look at two critical failures that not only enabled this attack to happen but allowed it to cause such devastating reputational and financial damage to the telecom giant.

1. Secure Coding

This all started when a 15-year-old teen in Northern Ireland discovered an error in TalkTalks customer website that allowed for SQL Injection (SQLi). “Through SQL injection an attacker can request arbitrary data from the database behind the application. It would be prudent to assume that all data kept within the database is now compromised”, explains Wim Remes, manager EMEA strategic services at Rapid7.

Remes continues, “This is an attack vector that has been known for more than a decade and it is still found in web applications around the globe. While it is possible for the error that enables such an attack to slip through a well-established application security program, they are fairly easy to prevent with the proper safeguards in place”

This entire situation could have been avoided if 3 simple secure coding principals had been followed:

  1. Educate your developers on secure coding best practices;
  2. Test all code using an application such as Metasploit PRIOR to it reaching your production environment;
  3. Test your code AGAIN (preferably using a different tool that the one used for initial testing) after it is pushed to production.

One can maybe excuse a non-sophisticated network falling prey to an SQLi however, TalkTalk is a telecom giant. This attack could, and should, have been prevented through well-established code and release management best practices.

2. Incident Response

“Luck is what happens when preparation meets opportunity.”

– Seneca

If luck is what happens when preparation meets opportunity, in the world of cyber, incident response is that preparation. Incident response is the plan of action that an organization has in place that clearly prescribes the criteria to escalate and declare a common security event into a full blown incident.

An incident response plan should cover how an incident will be handled, as well as how an incident will be communicated to internally up the chain of command, to the authorities, the press, and the public. Sounds simple enough, right? No. Incident response planning is complex and detailed work. It must be tested, table-topped, and rehearsed until everyone knows exactly what their individual role is and what they will do, how they will act, and what they will say. Think of it like this: having an inadequate incident response plan would be akin to going to the SuperBowl without a playbook and saying ‘we are professionals, we have played a thousand games, we know what to do.’

To be fair, TalkTalk did have an incident response plan. Within hours of the breach, they had taken down the affected website (a common practice) and had enlisted BEA Systems to perform root-cause analysis. From all appearances their technical response plan was effective.

Reputational harm, however, will often cause more damage to your company than the actual attack. We already know that this attack could have easily been avoided by employing secure coding best practices. However, the true damage of this attack was in the companies crisis communications post-incident.

On October 21, after several customers reported that their broadband was slowing, TalkTalk released their first public statement “We have taken down talktalk.co.uk temporarily, and normal service will be resumed as soon as possible. Our taking down of the website is not related to a broadband outage.” Just two days later TalkTalk was announcing a “significant and sustained cyber attack” which, quite understandably, raised considerable concerns with its 4 million+ customers.

For an amazing blow-by-blow, I recommend this article by TripWire.com.

After alerting customers that TalkTalk had undergone a ‘significant’ breach they further raised the alarm by communicating that the attackers had accessed the following customer information:

  • Names
  • Addresses
  • Dates of birth
  • Email addresses
  • Telephone numbers
  • TalkTalk account information
  • Credit card details and/or bank details

At this point, if I were one of TalkTalks 4 million+ customers I would be seriously concerned! However, TalkTalk tried to console its customers by making it clear that this data was accessed through its website and not it’s ‘internal core systems’. Look, if you tell customers that their personal, account, and credit card information has potentially been stolen, the very last thing they care about is if it came from TalkTalks customer website or their internal ‘core’ systems. Adding to the dismay, TalkTalk was not immediately able to confirm that the credit card information on the website was properly encrypted according to PCI-DSS requirements.

Nettitude principal security consultant Chris Oakley commented: “The PCI-DSS standard – which regulates the way companies store credit card details – includes some very specific requirements that are designed to ensure that this card data is always properly secured; it is unclear what the TalkTalk PCI compliance status is at the time of this week’s breach. Fundamentally, in order to be compliant, the TalkTalk cardholder data environment should be appropriately minimized and isolated from the rest of their network. The data within should be appropriately secured; cardholder data must be encrypted using strong cryptography.

Let’s fast forward to the end, shall we? On Monday 26 October, TalkTalk CEO, Dido Harding released a video

The number of customers affected and the amount of data potentially stolen is smaller than originally feared.

We don’t store unencrypted data on our site, any credit card info which may have been stolen has the six middle digits blanked out and can’t be used for financial transactions.

No My Account passwords have been stolen.

No banking details have been taken that you wouldn’t already be sharing when you write a cheque or give to someone so they can pay money into your account.”

Remember those earlier statements about the data being taken from the website rather than their ‘core systems’? Turns out that that was a rather important detail. The UK press had a  field day with TalkTalk absolutely lambasting the company for its lack of security around customer information. However, because the information was taken from the website (and not directly from their internal networks) the exposure was dramatically lower that originally stated in their initial public responses. While customers personal information was taken (potentially exposing them to identity theft), their credit card information was not revealed. This also significantly reduced the number of total affected customers to 154,000, with 15,000 of those having their banking information exposed. That’s no small amount, totaling 4% of their customers, but indeed a far cry from a complete breach of 4million as initially suspected.

It was evident from the start that TalkTalk had no clear crisis communications plan. The information that was communicated to the public only served to cause further confusion and sow anger and doubt among its customers.

The Fallout

“Nuclear weapons and TV have simply intensified the consequences of our tendencies.”
― David Foster Wallace

A crisis is the result of a cascade of failure. In the months preceding the attack, TalkTalk CEO, Dido Harding, has appeared on countless new programs, hundreds of news articles and blog posts have been written, arrests have been made, and with the company still reeling from its November, 2014 breech, customers are left feeling angry, confused, and wanting answers.

talktalk-stock-hack
Source: Businessinsider

The UK data protection regulator Information Commissioner’s Office (ICO) fined the mobile operator a record £400,000 for the incident. However, The full financial impact was far greater. TalkTalk lost over 112,000 customers and paid over  £43million in dealing with the attack. TalkTalks stock price also took an absolute beating plummeting to a 5-year low.

 

Ultimately, Five people were arrested and charged in connection with the breach:

  • A 15-year-old boy from County Antrim, Northern Ireland.
  • A 16-year-old boy from West London.
  • A 20-year-old man in Staffordshire.
  • A 16-year-0ld boy in Norwich
  • 18-year-old boy in Llanelli, Wales.

It is easy to blame these kids for causing such havoc but I think ICO Information Commissioner Elizabeth Denham said sums it up best: “TalkTalk’s failure to implement the most basic cyber security measures allowed hackers to penetrate TalkTalk’s systems with ease.

“Yes hacking is wrong, but that is not an excuse for companies to abdicate their security obligations. TalkTalk should and could have done more to safeguard its customer information. It did not and we have taken action.”

 

Well said.