Talk Talk Hacked

[directhex]

https://paul.reviews/value-security-avoid-talktalk/

I'd hope heads would have rolled last time, but I doubt it.

Drupal and PHP simply shouldn't be used when anything needs any kind of security, the practices both the language and platform encourage are incongruent to a safe secure software development lifecycle.

"We don't support HTTPS under any circumstances" is a pretty core issue, and unrelated to choice of dev framework

[peterb]

I wonder how many fraudulent claims for compensation will be made?

[Dave_07]

TT have posted an update:

https://help2.talktalk.co.uk/oct22incident

[Saracen]

I agree, and I don't either BUT .... what reassurance do we have that other companies are any better? Or for that matter, haven't previously been hit and lost customer data, but managed to keep it quiet?

I've been accused of tin-hatism over my attitude to privacy in the past, because my attitude is that I guard ALL aspects of my privacy jealously, UNLESS there's a convincing reason why it's in MY interests to release it. In part, my reasoning is that I don't want any company, any at all, no exceptions, building a profile on me for marketing purposes, but another aspect is that I have no way to know how carefully they protect, or don't protect, that data.

So, who here knows what data their ISP or mobile provider gathers? What happens to historic geo-location data, call or text metadata, and so on, to the nth degree? When you use a store card, who knows what transaction data they keep, what profiling data may have been mined, what data sources it's been cross-referenced with, and for that matter, what country it's stored in, and with what procedures and/or software security measures, are in place? What data is encrypted? Which servers are hardened, and if they are, does the person hardening them know what they're doing. And are those protections regularly updated, by someone competent, or did the data owner call in some consultants five years ago, and assume that once hardened, job done? If so, they're idiots.

The real message in this is not that TalkTalk are incompetent idiots, though that's looking likely too, but that :-

- ANY data you provide ANYBODY is at risk, because you don't KNOW how well it's protected, and

- the ONLY way to minimise your risk is for YOU to take all reasonable steps to minimise exposure.

Short of living a hermit-like life, without modern telecom's (or at least any registered to you), never buying online, paying cash for everything and not having bank accounts, it's impossible to avoid virtually all risk. Using just about any modern device, and most obviously smartphones, opens up the very real prospect that ANY data gathered vua them WILL, sooner or later, be compromised. Same applies to giving websites data, ordering online, card and or contactless payment systems, and so on.

I get that most, or nearly all, people seem to regard smartphones as mandatory these days, and so many people seem to just trust that their data is guarded assiduously. Newsflash - it isn't. Or at the very least, you have zero grounds to believe it is, and plenty of incidents suggestjng it isn't, and that's just the ones large enough to have gone public.

So here's the thing. By all means indulge in all these modern telecom's devices and practices. Just don't be surprised, let alone shocked, when this sort of thing blows up and your data is lost. It WILL happen, and signs are, increasingly frequently, and about the ONLY thing that will protect you is when public anger makes the business risk of not devoting adequate money and resources to customer data security so serious that boards give it the funding it deserves.

For that reason, I hope this cripples TalkTalk or puts them out of business entirely. Just maybe, a really serious backlash woukd motivate others. It looks like good times comming for security consultancies. Maybe I ought to start one, called Paranoia Ltd.

But right now, them taking our security seriously is simply another unwelcome, and avoidable, overhead.

I mean, even after a couple of days investigating, TalkTalk's MD doesn't even seem to know what was and wasn't encrypted? Their IT guys/gals ought to be able to have told her that in 5 minutes. The fact that they couldn't, and that the MD clearly hadn't taken this seriously despite two previous incidents (this year, IIRC) screams of negligence, and/or gross incompetence, to me.

So TalkTalk got burned, along with 4m customers. But what grounds are there for believing any other large company, never mind small ones without the same resources, are any better?

Nobody should be complacent about this.

[MrNeil]

http://www.bbc.co.uk/news/uk-34627541

Not as bad they say !!
My opinion is that TT did all the right actions and think the media made things spin a bit like they always do .

If there is a problem behind the door then keep it locked until the problem is sorted . They done that !!


this my opinion !

[peterb]

While no-one should be complacent, it is worth remembering that every time you write a cheque, you are disclosing your bank account name, number and sort code. However the authentication mechanism is your signature and the possession of those details does not enable remote access to the funds in your account.

A credit card number on its own is of limited use. For Card holder present transaction, you need either a pin or a signature, and a signature based transaction will require authorisation, which may not be granted, depending on circumstances. Credit card issuers have fairly sophisticated mechanisms for detection fraudulent activity. For Cardholder Not Present (CNP) transactions the authentication method is the CVC number, often augmented by the Visa or MasterCard verification system. There is a caveat in that it assumes the retailer is PCI (Payment Card Industry) security compliment which does not permit recording of CVC numbers.

To re-emphasise, that is not a cause for complacency, but just to add a little perspective to it.

I said in an earlier post that I wondered how many fraudulent claims for compensation would be entered on the back of this - a comment prompted by a news item where someone claimed to have had their bank account emptied as a result of this latest leak - reported with glee by the media, without apparently looking into the precise circumstances.

[Dave_07]

Whilst TT did some things I defiantly do not agree with during this scenario. I'd have to say on the whole, I personally believe they handled things overall with a degree of moral honesty that - to be honest - I have not seen many other companies engage in to a similar extent. That said I defiantly think they got lucky with how much info was eventually deemed to have been accessed. I just really hope they take this whole thing as a huge wake up call and become much more aggressive in their security practices.

[Saracen]

Whilst TT did some things I defiantly do not agree with during this scenario. I'd have to say on the whole, I personally believe they handled things overall with a degree of moral honesty that - to be honest - I have not seen many other companies engage in to a similar extent. That said I defiantly think they got lucky with how much info was eventually deemed to have been accessed. I just really hope they take this whole thing as a huge wake up call and become much more aggressive in their security practices.

Is it moral honesty, or pragmatic PR?

Any decent PR person will tell you that it's far better to be ahead of press reports than playing catch-up, looking like every admission has to be dragged out of you. It's also better to initially saying "potentially really bad" then being able to follow up with "not as bad as we thought", than to underplay it, then have to keep coming back with another bit of bad news. This is for two reasons: the former looks more honest; expectations management means that painting it bad scares people, then they're relieved when it turns out not so bad.

Also, I'm cynical when initially it's "potentially all customers". That "potentially" leaves wriggle room. Now, we're getting a very vague "not as bad". So, instead of 4m people, is it 100k? Or a 'mere' 1m? Or 2m?

If they said 1m and it turned out to be 2m, it's a PR nightmare. If they said 4m, and it turns out to be even 3.9m, it's "not as bad".

Maybe they're acting on a moral basis, but I think it's more likely they got good PR advice. After all, if they were that moral, they'd have made sure after the first two breaches this year that their procedures, systems and defences were state of the art.

So I'm more cynical. I think they just knew this was really, REALLY bad from a PR perspective, and did the best damage limitation they could. That, they've certainly done well.

[abaxas]

The media will look for new prey. People will forget about it. Life moves one.

To paraphrase the above :-

You are a total mong is you actually think any data (computer or paper based) is secure. Some may be more secure than others, but the reality is that if people want it, they can always get it.

[MrNeil]

Always be the same !

Damned if you don't and damned if you do ! They are not going to win either way so you'll never will know the true extent of it all !!

Im still happy with them , I got the email and was given all the ongoing updates keeping me informed !

[The Hand]

With regards to corporate PR, one of the wonderful ways a certain mobile/telecoms company used to disguise the number of customers affected by a certain issue, was to describe millions of customers as "many hundreds of thousands"... misleading but not necessarily inaccurate..

[abaxas]

Ask yourself the question... would you prefer to know or not?

If you prefer to know, then you get this fiasco.

If you prefer not to know, you simply have no idea.

* option 2 happens to you more than you think.

[MrNeil]

http://www.bbc.co.uk/news/business-34631555

Happening again but with Barclays ??

[Saracen]

Ask yourself the question... would you prefer to know or not?

If you prefer to know, then you get this fiasco.

If you prefer not to know, you simply have no idea.

* option 2 happens to you more than you think.

I go with option 3 - assume that any available data is, at a minimum, at risk so minimise what data is available. They can't lose what they don't have.

For instance, buy computer bits at one place, and the relevant data can only be lost if that place is hit. Buy it from 10 places, and you lose it if any of the 10 are hit. Buy from a local supplier, pay in cash, and they don't have any personal data to lose.

Yes, you might pay a bit more, but that's the price. It's a choice of whether it's worth it.

It's impossible to eliminate all risk, but we can reduce our exposure profile .... if we care enough to bother. I do.

Oh, and Peter, it's not just about card payments or accessing bank accounts. Indeed, it's not primarily about that, IMHO, because while it'll cause hassle, you would normally be reimbursed. More malicious is that increased levels of data increases ID theft risks, and that is far more pernicious. We also don't know what happens to data once compromised, but presumably, it's sold on, multiple times. We don't know to whom, and for what. We also don't know what level of combining goes on with data from other sources. But if some corporates combine data from multiple sources, it's probably unreasonable to assume serious criminal enterprises don't. So, a bit of data here, combined with a unique identifier (like NI number) or a series of data items providing a unique combination (like name, address, DOB, etc) can be combined with data purchased from previous (or future) hacks, maybe of a price comparison site you've used or, heaven help us, a credit check agency, and pretty soon you have a comprehensive picture for ID thieves to use.

The onus is then put on us to be proactive to monitor things, as evidenced by TalkTalk offering 12 months free credit check service, and never mind that the lost data is out there permanently, never mind just 12 months.

Our lives increasingly rely on digital data, and hence increadingly are at risk from attacks like this.

Too many people hand over too much information without querying why they're being asked for it. I recently had a call from my utility company and despite them calling me, they wanted me to provide a series of bits of data like DOB, mother's maiden name, etc, for 'security checks'. Well, they're beggar-all use for security if you give them out all over tge place, companies stick it in their database and then get hacked. Next time a fraudster's asked for 'security data', they'll know ours.

The ID check model needs seriously improving. Those particular items of data are already compromised beyond any serious credibility, yet as that call demonstrated, they're still used.

[big_hairy_rob]

I would be surprised if this did not cost them significantly, however as the majority of their customers have picked them based on price, then I fail to see how these people would care either way.

My perspective is that this has happened three time, or at least that's the number of times that it has been detected AND reported. I can't help but question how many other times incidents could have happened and just why the company has not taken adequate action to prevent it happening again. Certainly it appears that the hackers hold the skills to break their fixes (if any have been carried out), so they need to tackle this problem a different way, or have game changing sanctions imposed.

I would be interested to know whether they had employed a penetration/security test after their previous incursions?

[TheAnimus]

"We don't support HTTPS under any circumstances" is a pretty core issue, and unrelated to choice of dev framework

They did use SSL, just not everywhere, and their implementation was bad.

I would say that framework choice has a part to play in this, some frameworks 'dev mode' can not be used in a production environment easily, things like denying a request that isn't from the same machine as the default config. Then requiring SSL for login say, but also you can have your framework/hosting environment defaults secure too, most people, myself included don't know which SSL modes are 'safe' to use, so we just use the default or what some reputable source says is best practice. Why would a framework say enable TLS_RSA_EXPORT_WITH_DES40_CBA_SHA by default? It's apparently week. For example MS disable SSLv3 and below by default, yet some SSL hosts do not.

People often say that languages and frameworks shouldn't have the blame because the users are using them badly. It's true in a way, a bad developer will always manage to do things badly, but the language can make it harder than doing things the better way.