◄Previous: 3.3 Who were the attackers?

# 3.4 What lessons can be learnt?

The attack originated from a group of teenagers showing off their hacking skills and having a laugh, but the consequences of the attack to TalkTalk and its customers were huge. TalkTalk not only suffered a big financial loss but also damaged its brand, and left its customers facing the possibility of identity theft crimes and scams for years to come.

Based on an analysis carried out by Colin Tankard, managing director of a data security company, here is a summary of what went wrong and how the attack could have been prevented (Tankard, 2015):

- The three web pages that were vulnerable to SQLi were inherited from Tiscali when TalkTalk took over its UK business in 2009 (ICO, 2016). According to the ICO’s investigation, TalkTalk did not undertake proper security testing or secure the problem web pages before allowing them to access their databases. This obviously was a big mistake.
- According to the ICO’s investigation, there was a security bug in the database management software in use at that time which allowed attackers to bypass access restrictions. The patch for that bug had been available for over three and a half years before the attack. However, TalkTalk did not apply the patch in time. Tankard (2015) believes that this indicates poor patch management practice. Systems must be kept up to date with security patches in a timely manner. Outdated systems that cannot be patched should be isolated from the main network.
- According to Tankard (2015), TalkTalk may not have proactively monitored network activities, such as server logs, to detect unusual behaviour at the time of the attack. According to the report from Channel 4 News (White, 2015), the attack happened continuously for days before TalkTalk discovered it. The ICO also reported two previous SQLi attacks in the same year. This should have given TalkTalk enough warning to undertake proper proactive action. Tankard (2015) believes it is possible that TalkTalk’s technical team were aware of the alerts but chose to ignore them. Therefore, management should have had a mechanism to receive these alerts as well.
- Given that TalkTalk had suffered two previous attacks within a year, they still did not appear to have a good strategy to manage such an event and their response to the attack was slow (Tankard, 2015). They didn’t report the incident to the ICO until a full day after they discovered the attack. They also failed to inform their customers straight away so that their customers could be more vigilant to scams. During the first press interview, TalkTalk’s CEO, Dido Harding, did not know whether the data was encrypted and was unable to give any details of the attack. This made customers frustrated. According to Tankard (2015), TalkTalk should have prepared a robust disaster recovery plan. They also had not significantly strengthened their defences after the previous attacks, which was another big mistake.
- Although investment in a proactive threat detection system is costly, the damage of a breach can be much more expensive. It is better to prevent an attack from happening than to have to deal with the consequences of it.
- Finally, the TalkTalk attack demonstrates how vulnerable business networks can be. Businesses must start to check their networks and isolate any parts not strictly necessary for providing services to their customers. In case one area is compromised, the isolated parts are still protected. They should also incorporate in their network some 'honeypots', which are fake servers that lure attackers to them in order to monitor and analyse their activities. This would allow the businesses to determine a strategy to stop the attack and to report the suspicious activities to the police.

◄Contents►Next: 4 Case study 3: the Mirai botnet

OpenLearn - Learning from major cyber security incidents
Except for third party materials and otherwise, this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence, full copyright detail can be found in the acknowledgements section. Please see full copyright statement for details.