Disclaimer: My comments below are based upon quotes from both Twitter and The Times of London on the UK’s TalkTalk breach; as a result the subsequent investigation and analysis may find that some of the assertions are in fact incorrect. I will post clarifying statements should this happen to be the case.
I am not normally one to pick over the bones of company A or company B’s breach as there are many people more morbid and qualified than me to do so, and I also hate the feeling of tempting fate. All over the world i would guarantee there are CISOs breathing a sigh of relief and muttering to themselves/psychoanalyst/spouses “thank god it wasn’t us”. Bad things happen to good people, and an industry like ours that tends to measure success on the absence of bad things happening is not a great place to be when those bad things appear to happen far more frequently than ever before.
So it took me a while to decide if I should write up my feelings on TalkTalk’s breach, although I had Tweeted a few comments which were followed up on.
Initially I was shocked that people are still using the same password across so many crucial accounts. After a ten minute rant in the car about it with my wife, she calmly (one of the many reasons I married her) explained that not everyone thinks like me as a security professional, and that I should remember my own quote of “convenience eats security for breakfast”. Having calmed down a little, I was then shocked by something else. That something else was when the TalkTalk CEO, Dido Harding was on national television looking clearly exhausted (I can only imagine how much sleep she had been getting the last few days) giving out unequivocally bad advice such as “check the from address on your emails, if it has our address it is from us”. Graham Cluley’s short analysis was spot on here:
As if TalkTalk’s customers hadn’t gone through enough, they are then being given shoddy advice from someone in a supposed position of trust that is going to put them at even more risk. The scammers and phishers must have been rubbing their hands with invisible soap and glee as they prepared their emails and phone calls.
Now, the attack it seems did not disclose as much information as was first though, which is good news. So credit card numbers were tokenised and therefore unusable, so no direct fraud could be carried out there (again dependent upon the form of that tokenisation which I am sure there will be more details on in the coming months). Bank details were however disclosed, but again, there is a limited amount of damage that can be done there (there is some I acknowledge, but it takes time and is more noticeable… another time for that discussion). Here is the Problem Number One though; with Harding’s poor advice, many people subsequently (and allegedly) fell for phishing attacks through either phone calls or emails, and lost hundreds of thousands of pounds. TalkTalk’s response? Credit monitoring.
And then we move to Problem Number Two; Why weren’t the bank details stored safely? Why were they not encrypted? Armed with the knowledge of customers bank account details scammers can make a much more convincing case that they are actually from TalkTalk, especially if other account information was also lost (time will tell). TalkTalk’s response?
So TalkTalk was technically compliant? Shouldn’t this kind of thinking be consigned to the same mouldering scrapheap where “we’ve always done it this way” and “we’re here to secure the business, not help it” lay? I sincerely hope that this episode will at the very least highlight that “compliance” and “security” are two very different things and that the former most certainly doesn’t automatically result in the latter. What has transpired is the perfect storm of a breach, unforgivably poor advice, and complacency based upon compliance and resulted in the pain of a lot of people involving large amounts of money.
If an example like this does not spur you into doing more as regards your own security awareness activities, then please go back to the beginning and start again. Why? I have been accused of “victim blaming” somewhat (see the above Tweets), but if individuals had an ounce of sense or training they wouldn’t have fallen for the subsequent scams and been more careful when responding to email supposedly from TalkTalk. I will leave the last word to Quentin Taylor, and as you carry on with your internet residencies, don’t forget you need to wear protective clothing at all times.
Safe Harbor has officially fallen from grace, here is a link to the actual ruling:
What this actually means is still not fully clear, but what is clear is that it affects thousands of companies who now find themselves without the added “protection” of its (self certified) legal framework. Thousands of contracts will be invalidated and thousands of companies will be deemed to not have met minimum standards of protection of EU data in the USA.
There is one thing for certain though; with the speed required to address this, there will be one group of people set to profit from this to get the next best thing into place as quickly as possible…
Picture credit – Quentyn Taylor (@quentynblog)
Most accidents originate in actions committed by reasonable, rational individuals who were acting to achieve an assigned task in what they perceived to be a responsible and professional manner.
(Peter Harle, Director of Accident Prevention,Transportation Safety Board of Canada and former RCAF pilot, ‘Investigation of human factors: The link to accident prevention.’ In Johnston, N., McDonald, N., & Fuller, R. (Eds.), Aviation Psychology in Practice, 1994)
I don’t just read infosec blogs or cartoons that vaguely related to infosec, I also read other blogs from “normal” people. One such blog is from a chap called Wayne Hale who was a Fligh Director (amongst other things) at NASA until fairly recently. As a career NASA’ite he saw NASA from it’s glory days through the doldrums and back to the force it is today. There are a number of reasons I like his blog, but mostly I have loved the idea of space since I was a little kid – I still remember the first space shuttle touching down, watching it on telly, and whooping with joy much to my mother’s consternation and chagrin. The whole space race has captured my imaginaion, as a small child and an overweight adult. I encourage anyone to head to his blog for not only fascinating insider stories of NASA, but also of the engineering behind space flight.
What Wayne’s blog frequently shows is one thing; space is hard. It is an unforgiving environment that will take advantage of every weakness, known and unknown, to take advantage and destroy you. Even just getting into space is hard. Here is Wayne describing a particular incident the Russians had;
The Russians had a spectacular failure of a Proton rocket a while back – check out the video on YouTube of a huge rocket lifting off and immediately flipping upside down to rush straight into the ground. The ‘root cause’ was announced that some poor technician had installed the guidance gyro upside down. Reportedly the tech was fired. I wonder if they still send people to the gulag over things like that.
This seems like such a stupid mistake to make, and one that is easy to diagnose; the gyro was in stalled upside down by an idiot engineer. Fire the engineer, problem solved. But this barely touches the surface of root cuse analysis. Wayne coniTunes;
better ask why did the tech install the gyro upside down? Were the blueprints wrong? Did the gyro box come from the manufacturer with the ‘this side up’ decal in the wrong spot? Then ask – why were the prints wrong, or why was the decal in the wrong place. If you want to fix the problem you have to dig deeper. And a real root cause is always a human, procedural, cultural, issue. Never ever hardware.
What is really spooky here is that the latter part of the above quote could so easily apply to our industry, especially the last sentence – it’s never the hardware.
A security breach could be traced back to piece of poor coding in an application;
1. The developer coded it incorrectly. Fire the developer? or…
2. Ascertain that the Developer had never had secure coding training. and…
3. The project was delivered on tight timelines and with no margins, and…
4. As a result the developers were working 80-100 hrs a week for three months, which…
5. Resulted in errors being introduced into the code, and…
6. The errors were not found because timelines dictated no vulnerabiliy assessments were carried out, but…
7. A cursory port scan of the appliction by unqualified staff didn’t highlight any issues.
It’s a clumsy exampe I know, but there are clearly a number of points (funnily enough, seven) throughout the liufecycle of the environment that would have highlighted the possibility for vulnerabilities, all of which should have been acknowledged as risks, assessed and decisions made accordingly. Some of these may fall out of the direct bailiwick of the information security group, for instance working hours, but the impact is clearl felt with a security breach.
A true root cause analysis should always go beyond just the first response of “what happened”? If in doubt, just recall the eponymous words of Bronski Beat;
My annual home insurance quote came through this morning, with the usual 10-20% uplift that I know I can remove again through simply phoning the provider and threatening to leave. It is a pretty standard technique in the industry that has been going on for years, and that preys upon the lazy people in the world who can’t be bothered to look for a better deal.
Rewind a few months when I spoke with a very senior executive who admitted that he saw information security as a form of insurance.
“I don’t want to have to pay for it, but I do because I know that when I need it you guys come and fix the problems we are in”
This is a somewhat common and fair attitude to information security given our background as an industry and how we often interact with the business (a particularly large topic that this entire blog is really about). yet what was so interesting was his follow on comment:
“the things is, I am sure there is so much more information security can do for us, I just don’t know what it is”
When I first took out home insurance, I was most concerned about getting the cheapest quote. I was young, free and almost single, but all of the extras that the larger insurance companies were offering (and charging for) did not concern me. If my house burnt down I would find somewhere else to live while the insurance company sorted everything out, what do I need a hotel for? Lost my house keys? I will change the crappy lock on the front door myself when I get round to it, I don’t need a locksmith from the insurance company to do it for me.
Fast forward to today, and I live a far more complex busy life, cash rich (relatively speaking), time poor, with responsibilities to my children and wife, and a lifetime of memories in my house that are virtually irreplaceable. if things go wrong, I need it fixed quickly and easily and with the minimum of impact to me and my family. I even have proactive services, such as boiler cover and servicing to reduce the likelihood of things going wrong in the first place. Therefore I am leveraging every aspect of what the insurance company can give me even before something goes wrong, and the peace of mind that I get knowing they are looking out for me even prior to disaster striking is worth (almost!) every penny.
An information security programme must be able to sell every aspect of its services to the business, and not just be seen as a reactionary force. if it does that, every time something goes wrong, both the financial and emotional premiums of paying for your services will increase time over time until the point the programme is seen as imply an overhead like paying the rent and keeping the plant watered, i.e. when the time comes, costs to be reduced.
Look at how you provide service before the fact; risk assessments, security testing, awareness and education can all be seen as services that prevent and/or add value to the business. What about the day to day? Consultancy to the business to do things securely without them even thinking about it; it doesn’t have to have “security” written on it to be a win for you and the business. And of course don’t forget after the event; incident management, business continuity, or even helping in the quality acceptance environments after something has been developed.
The key is to be involved in the full lifecycle of your business, whatever they are. They will be different from business to business and industry to industry, so it may not always be easy to identify, but it is extremely valuable.
And the prices we quote every year? Unlike insurance premiums, we are worth every penny.
Note: I don’t actually like the analogy of infosec and insurance, but it is one I regularly hear, so I decided to try and embrace it in this blog. I still don’t like it, but I can see how it could be useful for a simple elevator pitch or short conversation. There are plenty of analogies out there, and the best place for them in my humble opinion is at The Analogies Project. Check them out, and use them wherever possible. Even better, think about becoming a contributor.