Making technical sense of the TalkTalk story
Does TalkTalk deserve to be pilloried for this latest data breach?
It seems clear from the last 24 hours or so that the TalKTalk data breach is more worthy of the term "hack" than is usually the case with mass-market data theft incidents. This is not one of those times were a departing employee walked out with the information: it's a genuine bedroom-inhabitant intruder, a scenario much beloved of the few Hollywood attempts to portray the lifestyles of the Dark Web's operators.
Of course, we don't have a clear view of the actual events that led up to the breach, and there's an ongoing arrest and potential trial to look forward to -- but whoever did the deed, they used tools which are freely findable on the web, to probe and then exploit the small part of the TalkTalk website which is made out of an insecure software platform. The basic truth about the Dark Web these days is that the users of those tools, the guys who think of themselves as hackers just because they can pay in Bitcoin for something with a funky, subcultural name and completely opaque internal workings or provenance, are just as much victims, as the corporates they target. It's a mug's game, basically: the "sharp end" user of the tool is the source of money for the developers of the tool, and they can walk away with those bitcoins free and clear, without having to participate in any foolish mouse-clicks that lead the mug in question to that loud banging on the door at 5am, the handcuffs, and all the PCs in the house being carted off for forensic examination.
Notice that I said the tools to do this type of attack are "opaque". By that I mean that the mug who buys and runs it has no easy way of telling what's going on inside the cool tool he thinks he's mastered. Even if the police have the right guy this time, and he claims he did nothing himself, it makes next to no difference, because no purchaser of these types of hacker tool is in a position to be quite sure what that code is up to on their machine.
You can see this kind of problem for yourself, by looking at your firewall logs (and I mean network firewall, not PC personal firewall) for a day or a week. Most firewalls will emit a syslog format account of the traffic that passes through them, and there are many tools that will let you twist and turn that log to show up handy basic reports, like "most accessed site" and "top ten newest sites by IP address, for this week" and so forth. Can you account for all of the ones you see? No? Got any that turn out not to be "sites" but rather, consumer connections within a large ISP? Then you may well have a lurking Trojan infection. Or they could.
Data Analytics is a hot topic in late 2015, but while people mostly think about it as a tool for probing your customer data for trends, it's equally useful as a way of probing your IT data for trends of a much nastier kind. Thinking through the way the economics of the Dark Web produces an apparently-endless queue of mugs waiting to both be fleeced, and then take the rap, my conclusion is that there is no lower bound to the size of network that should be thinking about watching their own traffic. It's quite difficult to encourage would-be criminals to think about Best Practice Analysis, but if ever there was a field with lessons to teach everyone else, it's them.
Looked at from TalkTalk's side of the equation, I can see an endless bumpy, rutted, twisting road of hard-learned lesson. Much of the current criticism (ours included) has been focussing on their user data and how that can be secured as an exercise in custom software coding. Snippets of Java are floating around, and conversations about HTTPS and similar. It's actually not about this, really. First of all, let me summarise a lot of that code-cleanup territory by saying: this is all about inverted commas. I can remember having to tangle with them when I was a developer, and that was in COBOL and BASIC and Pascal on a VAX-11/780, and it appears that their status within computing as a tongue-twister for the brain and fingers is no less in 2015 than it was back in 1987. Fail to strip the end-quotes out of anything that comes in from your web pages, say hello to their attacks succeeding.
But that still isn't where I am going with this, technically. SQL injections can be warded off by many different techniques, ranging from ever-smarter firewalls through standard downloadable patches for the OS components, right up to analysers that go looking through source code for insecure habits on the part of the coders - but I am very much afraid that none of these would have helped TalkTalk one tiny bit. The breach was in their finance systems, and finance IT - even in a company whose business is technology - is a very different and peculiar place to the more regular type. It would be a gargantuan task to self-code your own personal accounting system, for example, and once you had it ready, it would be nigh-on impossible to hire any staff prepared to take responsibility for working on it. This means that finance products are often bought in locked-down packages, or in some cases even locked-down collections of hardware, software and even services. Exposing these to a web-page entry form which may be the subject of injection based attacks has been the downfall of far too many businesses.
Get the ITPro. daily newsletter
Receive our latest news, industry updates, featured resources and more. Sign up today to receive our FREE report on AI cyber crime & security - newly updated for 2024.
TalkTalk's great shame, then, is one that isn't that uncommon at all - but it's not where most of the commentaries are aiming. It is likely to be an incompletely tested subsystem, possibly maintained solely by a contractual promise from an outside specialist - and a specialist in accounting software, not web security. Many people will say that there's no excuse for taking contractual promises at face value, and that automated penetration tools for black hats are easily and more honestly matched by automatic vulnerability-testing tools for white hats: but all of these are meant to be issues for backwater, overtaxed, understaffed non-technical business. Not for a frontline ISP prominent in the public arena and linked to the Prime Minister in an advisory capacity on the nature of "Digital Britain". That's why this incident takes them from policy pillar to laughing stock.