27 Sep, 2017

I presented my first talk at an InfoSec conference and lived to tell the tale

by Ryan Reid

In this post, I’ll discuss my recent adventure regarding my first InfoSec con presentation. Hopefully, you’ll find the tips littered throughout this blog helpful as you prepare to present for your first time.

This past weekend, I gave my first InfoSec con presentation. Boom! All of my life goals accomplished. Well, not quite, but it was super cool and fulfilling. Right before I left the conference, another attendee asked me for tips as they prepare to give their first presentation. To be honest, it caught me a bit off guard. I thought, “Who am I to give advice? I’ve only done this one time.” But as I traveled back home, I realized that perspective might have merit. Many of my colleagues have spoken at a plethora of conferences. They frequently provide excellent feedback, advice, and encouragement (including recommending that I write this blog. So, if you don’t like it, blame this guy), but only through their experienced eyes. That is, it’s become second nature for them.

First, TL;DR:

  1. Submit to Call for Papers (CFPs), even if you don’t think you’ll make the cut.
    • Have someone else review your response before you submit it.
  2. Try not to get discouraged by rejection; think of it as an opportunity to improve.
    • If rejected: ask the review folks, “What could I have done better?”
  3. Don’t procrastinate.
    • Work steadily on the presentation.
    • Be ready before the conference.
  4. If giving a demonstration, consider having videos of you performing the demo.
    • These are great to fall back on if something goes wrong while on stage. (You can thank me later)
  5. Realize things are going to go wrong. But you’re on stage and ready to handle it.
  6. Have fun and laugh at yourself. You’ve already done a great job.
    • Even with the little mistakes during the presentation, you got up in front of people and shared something great.

So, here’s my long-form tale:

Having an idea

About a year ago, I started working on a BurpSuite extension, SpyDir. As I shared it with friends and coworkers, I got feedback on how to make it better. However, as the days rolled by, the frequency of feedback slowed. I knew it could be better and simply needed a wider audience. I wrote a blog post about it and decided to submit to a CFP.

Submitting to the CFP

I chose to submit to a conference I had attended in the past. It was somewhat local to me, and I had the comfort of knowing a good group of people who go every year. The chances of my fears, presenting to an empty room, becoming reality was acceptably low. I looked for examples of others’ submissions. I looked to see what was accepted and what wasn’t. This conference provided a template of sorts to minimize some of the potential differences regarding submissions. I filled out their form and prepared to submit.

IMPORTANT: Don’t be your own reviewer. I had three people review my CFP submission before I submitted it. All three of them had different and valuable comments. If possible, don’t just rely on technical people with knowledge of your field. If you can, reach out to someone who is ignorant of what you do. I had the benefit of a non-technical, English-proficient person offer to review my work. They ensured that I used appropriate grammar, spelling, and, aside from the jargon, made some semblance of sense. If you’re interested, here’s my submission.

So, I had something to talk about, and I had a response to the CFP. I submitted and held my breath.

Waiting to hear back

I waited and waited. It was at least an eternity…

Just checked… it was less than a month. But it felt way longer. It was like interviewing for a job and waiting to hear back. I tried not to dwell on it though. Once I hit submit, I knew it was out of my hands. I could no longer attempt to control the thoughts or feelings of the reviewers; my letters of persuasion, bits on their machine. I could only wait. So, that’s what I did. While I waited, I continued to work on my project as if I were going to present on it. Finally, I got an email from the conference; their decision had been made.

Rejection

Yep. Rejected. First response to a CFP falls flat. Time to crawl into a hole and give up, right? Nooooope. I was bummed about the rejection, but, and this is super important, I needed to know why the presentation was rejected. Luckily, the conference offered to provide feedback to anyone who asked. This was huge for me. In hindsight, to be able to reach out to the organizers and ask, “What can I do better?” is one of the best benefits you can get from submitting to a CFP. We are all here to learn, right? So, I asked. And then, because the organizers were understandably busy preparing and administering the conference, I waited some more. After the conference was but a memory, one of the organizers responded to me. I’ll include it here:

Thanks for your submission, Introducing SpyDir – a BurpSuite Extension. Thanks too for your patience in waiting for our reply.

The Program Committee (PC) was impressed with your knowledge of web application testing and the automation you’ve implemented. However the PC had two areas of concern regarding your talk:

Limited audience - [The conference’s] audience is relatively diverse. The PC was concerned that the topic of automating activities in Burp might be too niche to be of broad appeal to our audience.

The “so what” - The PC struggled a bit with your core problem statement. You effectively communicated the work you have done, but didn’t really communicate what problem you were solving. Some members on the PC aren’t web app assessment experts so without a crisp description of what you’re solving, they struggled to understand the impact of your tool.

Those are the reasons the PC decided to pass on including your talk in this year’s conference. It should be noted, however, that your submission was well structured and generally well received. You were very close to making the cut.

Okay, so that isn’t the most heart-crushing rejection I can imagine. The person who responded did an excellent job of providing both positive and negative feedback. I had actionable items; I needed to work on stating the impact of my solution. I re-worked my submission material and tried again. Did some more waiting too.

Acceptance

Oh!em!gee! Pure bliss! I got accepted. DerbyCon 2017: Here I come! But wait… there’s still a ton of work to do.

Preparing

We, nVisium, do internal Lunch and Learn presentations on a semi-weekly basis. These presentations have two huge benefits.

  1. They assist in our individual ability to speak publicly in the comfort of a friendly environment.
  2. They provide an opportunity for us to share the cool things we’ve been working on. They are super informal presentations, sometimes even improvised. Personally, I had already written a bunch of stuff in Comic Sans for previous Lunch and Learns, but quickly realized it was outdated. And, of course, I had started to work on presentation material for the previous conference, but… it was also outdated. Eh, no problem, the conference is months away.

Lesson: Comic Sans is an awesome font. Oh, and, of course, leverage the resources around you. Remember to re-use what you already have; don’t do more work than you need to.

Uhhh…

Two weeks until DerbyCon

Freaking out - a wild deadline appears

Whoa, where’d all my time go? I mean, yeah, sure, I had a lot going on at work and in my personal life, but what happened to months away? I have two weeks to get all of this together. Luckily, I had already finished writing the tool I was going to present on. I just needed to write the slides and think of a few jokes, right?

Learn from my mistake: Don’t procrastinate. Even if it doesn’t feel like you are. Working steadily will remove a ton of stress in the end.

Test 1-2-3-4

Have you ever seen someone’s live demo fail? Ever had it happen to you? I have. After the first time it happens, you’ll feel foolish and vow to be more diligent. One option is to record your demo and play the video during your presentation. This is a good option! Otherwise, you need to test, test again, and then test a bunch more to make sure everything will go according to plan. For my DerbyCon presentation, I went the test route. I thought, “I developed the tool, right? I should know it inside and out. If it doesn’t work for me in a live demo, it won’t work for people using it in their daily work.”

Lesson: Determine which route you’re going and become perfectly comfortable with it. Also, back-up videos, even if you don’t end up needing them, is a great idea.

At the Con

Oops, I broke something

So, I tested, and I found bugs. I found bugs… two days before the presentation. Remember when I only had to write the slides and think of a joke or two? Ahhh, those were the days. The Friday before the presentation, I stayed up until 3:00AM crushing bugs (or so I thought). After I wrote up my fixes and started testing again, I found I had broken everything.

Learn from my mistake: If you’re tired, STOP CODING. You’re probably too tired to make progress, and you might even be hurting your project. I passed out and slept for 4 hours.

Sleep is important

When I woke up, I immediately realized my mistakes from the wee hours of the night. I mean it. I woke up at 7:15AM and had my project working again at 7:20AM.

Fix things

Now, with a working project and slides starting to come together, I felt like I was in a much better place. I’ve always written things somewhat subconsciously, so when I sat down to write up the slides, they came out mostly in a fluid stream.

Test more

What about the presentation? I wrote mine in Markdown using Marp, but decided to present using Reveal.JS. I chose to use Reveal.JS because it allowed me to embed notes within the slides. I wanted to have the ability to have my thoughts in front of me during the presentation. Next, I had a to make sure my environment was ready to present. Within my presentation in Marp, I included a :heart: in one of the slides. Marp rendered a heart emoji, Reveal didn’t. Also, I noticed that Marp didn’t enforce the same slide size limits as Reveal. On slides that contained both text and an image, the image almost always fell off the slide in Reveal.

Lesson: Make sure your presentation is presentable. Modify as necessary.

Practice

The slides are done, project is bug-free (obviously), time to practice. I ran through my presentation, from start to finish, about eight times before I presented. With each iteration, I found something I could make better. I would often stop mid-presentation, make my adjustments, and restart on the improved slide. As I practiced, I took notes, with pen and paper, regarding the flow of information during my demonstrations. Doing this helped make sure I would intuitively repeat the delicate dance steps on stage.

Lesson: Run through the presentation one more time. You can never be too comfortable with the content.

Breathe

It’s the night before the presentation. I decided to take a break and enjoy working on the CTF with a co-worker and some new friends. I elected not to drink all the booze and got to bed early. I wanted to feel good before my presentation.

Lesson: This one is more personal, but I think getting a good night’s sleep and avoiding intoxicants is a good way to establish a foundation under you.

The final countdown

I accepted that I had no more time for changes, this was the final copy. Depending on your level of comfort with the material, and comfort doing some on-the-spot improvisation, you might decide to make your final copy earlier.

Time for the final practice run. I ran through my talk one more time. I stood in my hotel room and presented to the couch as if it were a live audience. I’m no Bill O’Reilly, I need practice. After that final run-through, I packed up and headed to the Stable Talks room.

Lesson: Unless you’re A) Bill O’Reilly or B) prepared to do it live, practice-practice-practice.

Present - no plan survives first contact with the enemy

I had the benefit of being in the 10:00AM (hangover) slot. That’s right, the hangover slot was a huge benefit. I had the privilege to arrive early, set up, and make sure things would work as expected. I arrived about 30 minutes early, met the wonderful AV team that would help with my presentation, and started to set up. When I entered the room, I said, “This is my first presentation at a conference.” The gentleman at the AV station smiled and said, “You’re going to do great.”

Lesson: Arrive early if you can. And remember, the AV people are awesome. They want you to succeed.

Panic - wait, no, it’s not so bad

I connected my laptop and found I hadn’t guessed the right resolution when I made up my slides. Yet again, I found my images had been pushed off the slides by the real estate-greedy text. Well… I didn’t think I had time to make major changes to the slides, and I knew the material well enough. Just a few minutes before I was to speak in front of real people, I was deleting text from my slides to make sure the images were on screen. Oh, remember those embedded notes I wanted? Well, it was about this time, I realized seamlessly presenting would require mirrored displays. Bye-bye presenter view.

Lesson: Don’t panic. Things are going to go wrong.

Remember: you’ve got this.

Frank-the-Tank-debate.gif

Wh-what happened? I blacked out for a few moments there. Oh, the presentation is over. Cool. Did it go well?

Lesson: Don’t be hyper critical of yourself as you exit stage-left. Maybe things could have gone better. But they certainly could have gone worse. You’re here, breathing, and, believe it or not, ready for your next challenge.

Laugh

I think the most important lesson I’ve learned in my life is: Be able to laugh at yourself. I’ve since watched the video of the presentation. And for the most part, I’m super happy it… There was one part though…

What happens when you delete content too quickly

One of my co-workers took that. After the presentation they asked, “Did you do that on purpose?” Cringe. I suppose I did that onced.

Lesson: Have awesome co-workers. Try to surround yourself with people with enough faith in you and your humor to think you would intentionally misspell words in your first big presentation.