TalkTalk announced on Thursday afternoon that it had been the target of "a significant and sustained cyberattack" against its website (talktalk.co.uk press statement) and that customer information including names, addresses, dates of birth, telephone numbers, email addresses, account information, and "potentially" credit and debit card information may have been accessed. The CEO, Dido Harding, has been on the BBC and on Sky News repeatedly since Thursday evening with statements that have, even by the unkind standards of incident-response media performance, generated a great deal of comment.
Several arrests have been made in the past forty-eight hours by the Metropolitan Police: a fifteen-year-old in Northern Ireland on Monday, a sixteen-year-old in Feltham yesterday, and a twenty-year-old in Staffordshire this morning (Metropolitan Police statements). The age of the alleged perpetrators has become its own news story, but the operational interest is in what the technique appears to have been. The reporting and the early forensic indicators converge on SQL injection against a customer-facing webpage, which produces database access from which the customer data was retrieved.
If the SQL injection account holds — and the early evidence is consistent with it — the technical posture is the part of the story that needs more attention than the perpetrators' ages. SQL injection in 2015, against a substantial customer-facing service of a major telecommunications provider, is an embarrassing finding. The defensive techniques have been well-understood for fifteen years; parameterised queries are a near-universal default in mature web frameworks; the Open Web Application Security Project's Top Ten (owasp.org/Top10) has had injection at or near the top since 2003. That a service of TalkTalk's scale was reachable by SQL injection in 2015 indicates, at a minimum, that the application security programme had material gaps; pen testing on the customer-facing surface was either not happening, was happening at insufficient depth, or was not feeding remediation back into the code.
The communications side is the more publicly visible problem. Harding's statements — that the attack was "significant and sustained", that the company "cannot guarantee" the safety of customer data, and that "no business is impregnable" — are the kind of phrasing that combines honesty with a managerial frame that does not address what customers actually want to know. The customer-impact picture has, over the four days since disclosure, evolved several times: the credit-card data is partially affected; only some customers are affected; the data may have been encrypted, then was not encrypted, then was unclear. The information vacuum has been filled with second-hand reporting, ransom-demand stories from people claiming to be the perpetrators, and a great deal of speculation. The customer trust dimension of this incident is, if anything, more damaging than the technical compromise itself.
For the SOC and engagement work, there is a near-term industry effect. Customers in our portfolio — particularly those running comparable customer-facing webapps with database backends — are this morning on the phone asking whether their applications would have caught what TalkTalk's apparently did not. The conversation is straightforward when the customer has a current pen test report on file and the SQL injection class of issues is closed; less straightforward when the last pen test was eighteen months ago and the surface has changed since. We are running supplementary scans through the weekend on customer estates where the customer wants the assurance now rather than at the next scheduled engagement.
The wider question is how this lands with the regulatory and disclosure environment in the UK. The Information Commissioner's Office is involved and has confirmed an investigation (ico.org.uk statement). The UK telecoms sector operates under the Communications Act 2003 and PECR (the Privacy and Electronic Communications Regulations), and the breach-notification obligations under PECR are tighter than for non-telecoms data controllers — twenty-four hours for personal-data breaches. Whether TalkTalk met that standard is going to be one of the points the ICO assesses. The likely fine will set a UK precedent; the maximum under PECR is currently £500,000 (the GDPR-derived higher fines are still ahead of us). Whatever the outcome, this incident is going to feature in next year's vCISO board briefings as the reference UK case.
The bit I keep coming back to, perhaps unfairly, is that this is the third TalkTalk breach in twelve months. The earlier incidents — a customer-data exposure in February and a separate scam-call exposure in August — should have been catalysing events for the application-security programme. Whether they were is a question that the post-incident review will need to address. The pattern of repeated incidents at the same organisation often points at organisational rather than technical causes; the technical fixes get applied, but the underlying programme weakness — staffing, prioritisation, board engagement, vendor management — does not. The ICO's findings will, I expect, be on those structural questions as much as on any specific technical control failure.