Earlier this year I had the distinct pleasure of giving a talk entitled: “Anatomy of a Data Breach” at the monthly Cardiff-JS meetup. Rather than write about the content of that talk too much, I’d like to write about my process in preparing for the talk, as well as some of the thoughts and feelings I had along the way.

Look ma'. It's me talking about things!

Early in 2019 I was recommended the Darknet Diaries podcast by a colleague and I immediately began binging the backlog of episodes. Each episode of the podcast, described as being

… about hackers, breaches, shadow government activity, hacktivism, cybercrime, and all the things that dwell on the hidden parts of the network.

is presented like a story, accompanied by interviews with domain experts and people directly involved with the events described in that particular episode.

In November 2019, Episode 52 of the podcast dropped. It talks about the hacking group known as Magecart and how they were able to use digital card skimming to take the card details of hundreds of thousands of people all over the world. In an attack against British Airways the Magecart group were able to take the card details of around 500,000 BA customers, and in a record GDPR ruling the ICO handed British Airways a fine of £183m.

If you haven’t listened to the episode, I highly recommend you start there and come back to this post when you’re all caught up.

I’ve included a link to the talk itself above so I won’t go into too much detail about the events of the attack, instead I’d like to write about my process for preparing for the talk. I know there are many people who have often thought about giving a talk or presentation on a subject but for whatever reason have never quite done so. It is my hope that by discussing my experience I’ll be able to learn something about myself, whilst encouraging others to take that next step and finally give that talk they’ve been planning.

Is there a point to giving this talk?

After I’d listened to that podcast episode, I immediately felt like I had to tell people about it. Here was this nuanced attack that could theoretically impact many of the people that I know. I began talking to my colleagues who were similarly surprised, not just that such an attack existed, but that stopping such an attack seemed fairly straightforward. I felt like the data breach suffered by British Airways offered up a real life lesson in why we should be working hard to secure our web assets.

It felt like presenting this to other people would go a small way towards making the web a safer place for customers.

Why would anyone listen to me?

Talking to a group of strangers is a scary, anxiety inducing experience. Especially when you aren’t a subject matter expert - so why would anyone want to do it?

I was conflicted. On the one hand I felt like this was a story that people needed to hear about - particularly developers who work on web applications where we’re always told that security is everyone’s responsibility (the implication being that, in fact, the developers are responsible and that’s it) - however we’re rarely educated on what we should be securing against, or how to do it. Not only that but whenever a security incident does take place it seems like the only ones who care about it are people already working in the security sector (analysts, blue/red teamers, ops, etc). But at the end of the day, it’s the developers who will be expected to write the patch that fixes whatever caused the security incident in the first place.

On the other hand, security is such an extremely broad and complex subject that when I imagined giving a talk about a data breach I immediately had images of a room full of people tut-tutting at my limited knowledge of the subject.

Because I wasn’t a subject matter expert, I worried that my thoughts weren’t valid

Ignoring this feeling wouldn’t do me any good so I tried to meet it head on resolving to do 4 things:

  1. Research in detail the events surrounding the data breach.
  2. Ensure that the content is factual and entirely backed by credible sources.
  3. Avoid vague generalities. Always try to give exact details (names, dates, figures, etc).
  4. Be upfront about my limited knowledge. Don’t try to be someone you aren’t.

Who is the audience?

You can’t give a talk without an audience and I’d prefer an audience that would not only understand what I was talking about, but would be inspired to continue conversations about security long after the talk was over.

I reached out to a good friend and colleague of mine, Jack, and asked for his advice. As one of the organisers for Cardiff-JS, a monthly meetup in Cardiff that was attended by people representing a broad spectrum of the web development stack, he suggested that I give my talk there in a few months time at their February meetup.

Jack rightly pointed out that simply discussing the events of the data breach as they happened wouldn’t really provide much value to the audience. I agreed and began researching how the developers at British Airways could have defended against this attack - and for me this was really where the value in giving the talk came from. The thinking here was that if I could first set the scene by describing how the attack took place, I could then talk (in very lightweight technical detail) about how the developers could have defended against it, and by doing so could spark the imagination of the audience as they think about their own properties and how they themselves might defend against such an attack.

I went back to Jack with this idea and he was immediately on board. Now I just had to write the thing.

Just tell a story

The best talks I’ve ever attended (certainly the most memorable) are the ones where the presenter tells a story. This is something Nickolas Means does extremely well and if you have the time I’d suggest watching any of his talks here (Fair warning, they’re highly addictive).

Luckily for me the British Airways breach read like a story quite naturally. There were high stakes, theft, intrigue, principle characters and a dramatic ending. All I had to do was put the events together in a semi-coherent way and present them. To do this, I created a basic slide deck with just the headline and a few pictures in place to represent the different parts of the story.

I played around with a few different ways of telling the story, first by simply reciting the events as they happened, starting with how the attackers breached British Airways, then moving on to the discovery and announcement of the attack by British Airways, then the investigation and finally the ruling by the ICO. I toyed with the idea of telling the story backwards, starting with the ICO fine and ending on the initial breach. But in the end the more impactful retelling was the one where I started in the middle at the public disclosure by British Airways. Again, to see how the actual talk ended up I’d encourage you to watch the recording at the top of this post.

The key takeaway here is that I didn’t care too much about the content of the slides, but rather I focussed on how to tell the story. After all, as egotistic as it may sound, people weren’t going to attend the talk to look at my slide deck - they wanted to listen to what I had to say.

2 weeks to go

At this point, I had nailed down the first part of my talk - the actual retelling of the data breach. Next I wanted to focus on the real value of the talk - how we as developers can protect our property from similar attacks. At this point, I knew very little about things like Content Security Policies, STS headers, XSS and data-injection attacks. I wanted to know more about them and knowing that I had to discuss them in a talk in a few days time rather forced my hand.

The deadline gave me the push I needed to actually do my research.

I spent a great deal of time spinning up dummy websites using Netlify and Mozilla Observatory to test security headers so that I could confidently talk about them on the night. As a precautionary measure I spent time practicing the talk without any slides at all (I’ve seen this happen to speakers at conferences and the idea of having to give the talk with no slides was honestly nightmare inducing).

At this point in time, I really felt like I’d done all the homework I needed to do to give this talk.

Jack casually mentioned to me that they had to move to a bigger venue because the attendee list was bigger than they were initially expecting.

I had mixed emotions about this.

The day before

I was excited! The talk felt pretty tight. I’d practiced it through a few times to ensure I could meet the timings, hit the right marks and (crucially) say the right words in the right order. Now I just wanted to do it. The attendee list had grown even more as some colleagues of mine were travelling down from HQ to visit and I couldn’t wait for them to see it.

On the day

Oh God, why the hell am I doing this? Why are people coming to listen to what I have to say? Some of them have paid real life actual money to be here. In the grand scheme of things I know absolutely nothing about this stuff and people are going to find out.

The talk is in the evening and I spend the day doing very little work and occasionally going to the bathroom to have mild panic attacks.

I don’t look at my slides until a few hours before the talk is scheduled to start. I find a small side room where I can calm myself and go through the talk one last time and make peace with the fact that whatever happens I’m going to have to stand in front of a room full of people and talk at them.

About an hour before kick off, I have a 15-20 minute period where I get extremely excited again. I can’t wait to tell everyone what I have to say.

Then, another brief panic attack before I’m being introduced and people start politely clapping as I take the stand.

We’re on.

Deep breath, brief pause, let’s go.

The aftermath

Everyone was extremely kind and full of praise and after the talk there was beer and pizza and I could hear snippets of conversation from around the room as people discuss whether the ICO fined British Airways enough, whether they themselves had systems that could be susceptible to a similar attack, and asking more technically nuanced questions about defending against this kind of threat. It was exactly the kind of response I was hoping for. People were talking about it.

In the months that followed I’d get the occasional DM or text from someone asking about security headers, or whether a certain site could be trusted. For me, this was the most rewarding thing. All I wanted from this exercise was for people to have these questions in the back of their mind; for developers to have that quiet nagging voice asking, “Is this secure enough?”.

Closer to home I’ve noticed that within my own team we now talk quite regularly about the security of new features for our applications. We take the time to understand the impact of things like security headers and application security has become a first class citizen in our sprint planning meetings.


This has been a very rambly post, but I’ve personally enjoyed the exercise of writing down my thoughts on how I approached this talk. In my day-to-day life I often find the best opportunities for learning are when we stand back and reflect on what we’ve done so far. In my work life this happens at the end of each sprint in the sprint retrospective, and in my personal life it happens when I take the time to sit and really think about things, like I did for this post.

This certainly won’t be for everyone, but that’s okay. It’s been good for me to write things down and I’m sure I’ll revisit this the next time I have to give a talk so I can remind myself that it’s okay to feel like you haven’t prepared enough, or that people will dismiss you - because those are things you can control.

I hope that if you’ve taken the time to read through this stream of consciousness you will have recognised some similarities with feelings you’ve had before. Perhaps those feelings of anxiety may have prevented you from telling your story. If so, I hope that seeing those same feelings in someone else, and being able to see the end product will encourage you to say what you have to say to whoever needs to hear it.

Thank you

I wanted to finish off with some gratitude.

A massive thank you to Cardiff-JS. If the community hadn’t allowed me an evening of their time I’d probably still be waiting to give this talk.

A huge thank you to Jack for being a good friend and providing honest feedback and guidance. You’re a legend and a vastly superior snooker player to me.

To the Darknet Diaries podcast that introduced me to this whole thing to begin with. I’m still an avid listener and would encourage anyone to give them a listen.

To Tom and Emily who shot the talk on the night. You folks are pros and anyone would be lucky to work with you.

And finally to everyone who attended on the night. If you didn’t, I’d have been talking to an empty room and that would have been weird. Thanks for all your questions and feedback, and I look forward to seeing more of you when lockdown is over and we can go to the pubs again.