Monday, 26 October 2015

Walking The TalkTalk

We don't really know that much about the TalkTalk hack, despite lots of speculation and frequent (though often misleading) media utterances by the CEO, Dido Harding. A distributed denial of service (DDoS) attack has been cited, along with a failure to encrypt sensitive data, both in transit and storage, plus a SQL (pronounced "sequel") injection attack that would allow a hacker to rummage around a database by manipulating Website URLs. But this in itself tells us little, and some of the issues may be red herrings. Together with the company's inability to get its story straight, this suggests chaos round the back, and that is likely to be down to the organisation and culture of the business rather than specific failings in its IT. 
The initial response to the news of the breach went big on cyber-terrorism, possibly as a result of SPECTRE being in the air, but I doubt this was a highly-professional job. Incompetent businesses tend to get hacked by incompetent hackers: like attracts like. Hazel Blears' idiotic claim that cybercrime was "probably the biggest threat to our economy" rather makes the point. One blatantly self-interested claim was that hackers may "case the joint" using a a DDoS attack: "More frequently, theft of personal data comes on the heels of a DDoS attack, as this activity can be used to map or profile a network's existing security defences, pinpointing holes in security or vulnerabilities to capitalise on".
This is dubious, to say the least. A DDoS attack cannot bring a SQL injection vulnerability to light because by definition it prevents the Web server responding (it's a blockade). The idea of a "distraction" only makes sense if hackers were able to bypass the Web servers (which were gummed up) and attack a database server that was not isolated by a firewall (i.e. logging into the database server directly). This is a possibility, but if the hackers already knew of this vulnerability then they wouldn't need a distraction. It would be like having a spare key to a house and arranging for a game of knocky-nine-doors before attempting entry.
The headline vulnerability (i.e. the one the ordinary punter might understand) was in plain sight, namely the lack of any SSL encryption for IDs and passwords submitted via the Web (you can tell this from URLs that start http instead of https - modern browsers automatically highlight the latter). Though this appears to have been addressed a year ago, the investigation at the time by Paul Moore, an independent security expert, revealed not only TalkTalk's casual and dismissive attitude to security but, inter alia, that their website was running on Apache 2.2.22, suggesting that their Web server had not been updated since 2012.
It is pure speculation on my part, but this could mean that their front-end is built on LAMP, a common suite of technologies used to power transactional websites: Linux, Apache, MySQL and PHP. As the middleware (PHP, which handles the to-and-fro with the user, and MySQL, which stores the data) is less likely to have been updated than the operating system (Linux) and Web server (Apache), the vulnerability that led to the data theft could relate to software that is much older than 2012. This could be the case even with other middleware, such as ASP and IIS. This is an issue both because patching/updating will fix vulnerabilities as they come to light, and because the required periodic integration testing gives you an opportunity to uncover weaknesses.
I'd hazard a guess that there hasn't been a root-and-branch review of the front-end since 2010, when TalkTalk was spun off from Carphone Warehouse and floated, following its purchase of Tiscali in 2009. The absence of SSL and the choice of LAMP suggests that, like many B2C companies, Talk Talk are suffering from the legacy of the early 00s when front-end development was often outsourced to web design agencies that lacked proper IT knowledge about data and security (particularly the need to encrypt sensitive data stored in the database, which is trivial to do if you plan it from the off). Many will have used opensource freeware like LAMP to keep costs down, and not bothered to update thereafter.
Another organisational dimension to consider is that TalkTalk has grown as a business through 6 acquisitions over the last decade: Tele2, One.Tel, AOL's UK business, Tiscali, Virgin Media's ADSL business and most recently Tesco/Blinkbox. As anyone who has experienced this will know, it can take a couple of years to fully work through all system integration issues for a single merger, and that assumes you have full boardroom backing for the necessary expenditure and procedural reorganisation. TalkTalk bear all the hallmarks of a business struggling to absorb change and manage the growth in customer numbers. That they also consider themselves "an asset-light business" does not inspire confidence.
One of the most obvious signs of this is a tendency to cling to legacy systems – i.e. hard-pressed staff focus on gaps that need to be plugged and shore up what already works. Combine this with a front-end that may have been bought as a "black box", and limited software infratructure upgrades, and you have an obvious risk. Another sign that this was a disaster waiting to happen would be disaffection among senior IT staff. There are grounds to believe that this was the case at TalkTalk. Their last annual report (June 2015) suggests that they have recognised some of the issues and are taking steps to rectify them, but the hopeful talk of an "IT change agenda" in 2016 (i.e. not yet) and the outsourcing of security to BAE Systems (when data security should be a core competence, even a USP) doesn't suggest a board that really gets it.
As a company, TalkTalk has a track-record of being cavalier about customer service and security, while being overly intrusive in terms of commercial surveillance (see Phorm) and government initiatives around parental controls. In other words, this is a business driven by stock market priorities (i.e. acquisitions as a way of securing growth in market-share), opportunistic about customer exploitation, with a political CEO (she is a Tory peer and longstanding chum of Cameron's), and a disdain for technology. The revelation that Dido Harding thinks the data-theft was due to a "sequential injection" puts her in the same category of idiocy as Hazel Blears. The root cause of the problem is to be found in the boardroom, not the IT department.

[Update 31-Oct: As suspected, the hackers look to have been unsophisticated script-kiddies, not the criminal masterminds of PR lore. It is also looking increasingly clear that the board of TalkTalk were negligent in their approach. They didn't prioritise data security, presumably because they neither understood it nor valued it. There are grounds to suspect that they have avoided investment in their IT infrastructure to meet stock market expectations in respect of short-term profitability.]

No comments:

Post a comment