The Art of the Conference

3 Comments May 31, 2016 Thom Langford

Yes, I know, it has been nearly nine months since I last graced this blog with my presence. What can I say, it has been a busy time… But as they say, if you want me something done, ask a busy person, and eventually they will get around to it. Just ask @hostunknowntv about the podcast I have been preparing for the last eleven months.

One of the reasons I have been busy (apart from the day job that sees me frequently travelling abroad) is that I have been somewhat in demand at conferences and forums. This is a lovely stroke to the ego when asked to keynote somewhere, but also a challenge because I have to come up with a new twist on an existing talk or even a brand new talk. Creating a talk from scratch takes hours and hours, much longer than the 6 CPE hours that (ISC)2 and ISACA allow you to claim. I would estimate anything from 20 to 40 hours for a 25 to 50 minute talk.

I am not complaining mind, the process may be long, but it really helps me form opinions, generate new ideas and even form unique points of view that I can apply to my day job (one of the reasons I always recommend standing up and presenting your ideas to your peers in the industry as a great way to further your own career).

So it frustrates me immensely that after I put this huge amount of effort into producing not a only a presentation, but also a performance for a conference, that the tools I am given to do so are all to often below par. Let me explain;

I like using Apple Keynote; it has a better look and feel to Powerpoint, handles animations better, and allows a finer control of the placement of images and text. I realise this is probably an entirely subjective perspective, but it is one I stand by. I can’t tell you the number of times a conference has insisted that I can’t use my own laptop and have to use PowerPoint. The conversion process not only screws up the formatting, but also the general placement and even the fonts. Those slides I spent hours on look like something from a Dunder Mifflin sales deck.

Secondly, when I can use Keynote or my own laptop, the audio visual teams almost always insist on using VGA;more often than not this messes with the proportions of the main screen, leaving my widescreen presentation stretched into a square shape. Again, I spend hours making sure the images are not distorted, text looks balanced, and then lazy A/V makes my slides look like they are being viewed through a fishbowl. Surely HDMI or even DVI is standard enough now, and the digital signal is far less likely to screw up aspect ratios.

Thirdly, secondary and tertiary screens are important. The normal “comfort” screen in front of the speaker is starting to become more popular, but more often than not it only displays what is being shown behind me, not the secondary presenters view of the current slide, next slide and timer (the latter of which are rarely used by most conferences…). At RSA in San Francisco I was presenting on their Live TV stage, and they had a comfort screen with the presenter view and at the back of the room a screen with my main presentation on as well. Perfect!

Why is this so important?

I personally feel that the quality of presentations at most conferences, InfoSec or otherwise, is very poor. There is plenty of subject matter expertise, but it is delivered in a poor way (see this video for some heinous examples). Conference organisers should be doing everything they can so that a presenter can deliver as effective a presentation as possible, and not worry about their deck being messed around with by either the A/V or a sub optimal “presentation laptop”, or even having to struggle with their delivery. The easier it is in the speaker, the better the presentation and the more effective and impactful an experience it is for the audience.

Should I be able to stand up and talk without my slides, not rely on comfort screens or even know what slide is coming up next? Yes, of course, in an ideal world, but very few people who speak are professional presenters, have demanding day jobs, and often finish their decks days or hours before the day. Conference organisers, please help us produce the very best performances for the benefit of your audience, and get some of these basics sorted out!

And hopefully that bar will raise just a little bit higher and benefit everyone in the industry and community.

“And the winner is… Compliance!”

1 Comment October 26, 2015 Thom Langford

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.

that original quote I Tweeted from the Times dated 25th October 2015

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?

Dido Harding talking to The Times, 24th October 2015

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 R.I.P.

Leave a comment October 6, 2015 Thom Langford

Safe Harbor has officially fallen from grace, here is a link to the actual ruling:

http://datenschutzpolitik.de/dokumente/ecj-c-362-14.pdf

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)

What 80’s pop can teach us about Rocket failure and incident management

Leave a comment August 18, 2015 Thom Langford

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;

“Tell me why? Tell me why? Tell me why? Tell me why….?”

Making the world angrier, one process at a time

Leave a comment August 3, 2015 Thom Langford

I have recently set up Family Sharing on my iOS devices, so that I can monitor and control what apps go on my kids devices without having to be in the room with them. Previously they would ask for an app, and I would type in my AppleID password and that was that. Unfortunately with my new role I am travelling so much now that the thought of waiting a week before they can get an apps was causing apoplectic grief with my kids. Family Sharing was the solution, and when I had finally worked it out, we were goood to go and it works well. I can now authorise a purchase from anywhere in the world. I get woken up at 3am with a request for a BFF makeover or car crash game (one girl, one boy) but my kids are happy.

One problem however was that for some reason my daughters date of birth was incorrect, therefore indicating that she was an adult, and thereby breaking the whole “app approval” process. Straightforward to fix? Not at all.

I won’t bore you with the details, but it was the most frustrating process I have encountered in a long time. I admit, I misinterpreted the instructions along the way (they were a bit asinine in my defence), but it came down to the fact that I had to have a credit card as my default payment method for my family account, not a debit card, simply to authorise the change of status of my daughter from an adult to a child. In other words, I had to jump through hoops to restrict her account rather than give it more privilege. Not only that, but from an account that already had the privileges in the first place. There didn’t seem to be any element of trust along the way.

I am sure there is a good, formal response from Apple along the lines of “take your security seriously”, “strong financial controls” etc, but as an experience for me it sucked, and if I could have worked around it I would have. Thankfully not all of Apple’s ecosystem works like this!

This is a problem for many information security organisations when they introduce procedures to support organisational change or request mechanisms. For instance, how many times have you seen a change request process require CISO, CIO and potentially even higher approvals for even simple changes? Often this is due to a lack of enablement in the organisation, the ability to trust people at all levels, and often it is a simple lack of accountability. It seems we regularly don’t trust either our own business folks as well as our own employees to make the right decisions.

Procedures like this fail in a number of places:

They place huge pressure on executives to approve requests they have little context on, and little time to review.
The operational people in the process gain no experience in investigting and approving as they simply escalate upwards.
The original requestors are frustrated by slow progress and no updates as the requests are stuck in senior management and above queues.
The requestors often work aroun d the procedure, avoid it, or simply do the opposite of what finally comes out of the request as work pressures dictate a quicker response.
The owners of the procedure respond with even tighter regulations and processes in order to reduce the ability nof the nrequestor to wotk around them.

And so the cycle continues.

The approach I have regularly used in situations like this comprises of two tenets:

Consider the experience of the user first, then the desirable outcomes of the process second.
Whatever process you then come up with, simplify it further. And at least once more.

Why should you consider the expoerience of the user first? Who is the process for the benfit of, you as in formation secuity, or them as the end user? If you answered the former, then go to the back of the class. We are not doing security for our benefit, it is not security for the sake of security, it is to allow the user, our customers, to do more. If we make their experience bad as they do their best to make more money, sell more beer, do more whatever, security becomes an irellevance at best and a barrier to successful business at worst.

Making the requstors exoerience as painless and as straightforward as possible (perhaps eeven throw in a bit of education in there?) they are encouraged to not only see the long term benefits of using the procedure as we defined, but also become fanatical advocates of it.

Secondly, why should we keep it simple? Well not only to support the above points, but also because guess who is going to have to support the process when it is running? Of course, you and your team. If the process itself is bulky and unmanageable then more time will be spent running the process than doing the work that the process needs to support. If that amount of time becomes too onerous over time, then the process itself breaks down, the reporting on the process becomes outdated, and ultimately the process itself becomes irrelevant and considered a waste of time by those it affects.

Putting your requestors at the centre of your simplified process universe will always make that process more robust, more understood, more beneficial and of course more relevant to the business, and who can argue with that?

InfoSecurity Europe

I spoke at this years InfoSecurity Europe in London a few months back on articulating risk to senior management. Peter Wood, the moderator, did an excellent job as moderator of the panel, and even revitalised my faith in them after too many very poor experiences earlier this year.