Getting Your Proposal Accepted
The call for papers for RSA Conference 2019 is open, it closes on August 1st.
A friend asked me for some tips on getting a proposal accepted, and as speaking at an event like RSAC is great for self-development, and a brilliant opportunity to give back to the community, I thought I’d share my advice.
I follow a really simple rule which is to start from the basis that any presentation I give at RSAC is essentially is my way of paying back to the wider information security community. While I was starting out, I learned so much from good speakers at conferences, especially RSA Europe (when such a thing existed).
I generally have three approaches to a conference presentation:
- What have I learned through experience which would be useful for someone else to know?
- What have I done in my role that worked really well (or badly) and other people could try this (or learn what not to try!)?
- Have I researched anything in depth that I can explain in a simple way in 45 minutes to save someone else a week of research?
And of course sometimes it is a combination of these.
They key thing is to start from the position that you’re there to educate and to provide something that the attendees can use when they leave. So I start by writing down what will be on the last slide of the presentation - RSAC calls this the “take away” slide. It answers the question “as a result of sitting here for 50 minutes, what will people be able to do that they couldn’t before”. This should then lead to your title - because the title should tell the potential attendees what they will gain by coming to your session - which you now know because you’ve written it down.
The title needs to communicate this, in simple language. Don’t try to be too clever or cryptic because in the conference program/app people probably give the title just a few seconds and then, if the title captures them, they will read the very short description. I will often write 10 titles before I get just the right one, and the same for the short description -- your first attempt won’t be the best. Remember you’re writing these so people will decide to come to your session, but a good title and short description focussed on attendee outcomes will also grab the attention of the program committee.
Now comes the hard part -- the detailed session description that is only read by the programme committee. Again my best advice is to spend a decent amount of time on it and don't just put down a stream of consciousness. I have no evidence for this but I bet the program committee, either consciously or unconsciously, make the assumption that if you put forward a hastily written sloppy proposal, your actual session will be hastily written and sloppy.
You’re writing for a bunch or super-bright people who have good information security knowledge and skills. They have seen innumerable proposals, assessed oodles of presentations and sat through countless sessions. They may not be an expert in the area you want to talk about, but they will be expert enough in the general domain.
The first thing to make sure is that you are not selling anything. And if your take away is really for attendees to checkout your shiny new thing, you’re probably not going to succeed. The program committee can spot this a mile away and you won’t be accepted. It is fine however to talk about the technology that underlies a product -- especially if it is novel.
The session detail is what gets your session selected, so spend as much time on it as you can. You want to show two things:
- A flow through the presentation that emphasises what attendees will learn.
- Clear demonstration of your expertise and authority.
As an example, at the end of this post is the session detail for my 2016 session - you can see a webinar reprise of it here.
RSAC encourages new presenters, it's not the same folk every year so if you've a good story to tell, and can communicate this to the programme committee, I look forward to grabbing a coffee with you in the speakers' lounge next year. If you're a new speaker and would like some assistance with your proposal or your presentation then contact me @withoutfire and I'll be glad to help.
How to Explain Cybersecurity to the Board Using a Simple Metaphor: FIRE
Cyber security professionals are often criticised for their communication skills, especially when it comes to communicating with the C-suite and the board. One reason is that when we explain the core issues around cyber security, we start to use technical terminology that is not accessible to senior management, so they’re faced with two problems – working out what we’re saying and working out what they need to do.
The aim of this session is to pass on proven simple metaphors that can be successfully used by attendees to explain cyber security concepts to senior executives.
The way that fire is managed forms part of common societal knowledge. Once past school, people know the roles that smoke detectors (detect) and fire engines (respond) fulfil. This common knowledge can be harnessed to explain the holistic cyber security requirements of prevention, detection, response and recovery.
Everyone understands that the sooner a fire is detected, the less damage that occurs – the same is true of our networked systems. All buildings have clear ways to report a fire incident and regularly tested response plans. Many commercial building have fire detection in place (cf IDS) that’s also tested and linked to a response plan. Depending on the risk, some have automatic response systems such as sprinklers and automatic suppressant release (cf IPS).
A fire management system that just had prevention and some detection would not be fit for purpose (although some organisations sill build their security this way). Buildings have fire extinguishers and hoses, staff are trained and depending on the severity of a fire, external help is on standby to be summoned quickly. In the event of the loss of a building, BCP plans are activated and claims made against insurers.
Finally a brief examination of the great fires of Chicago and London gives three discussion points with cyber security parallels.
Attribution: was the Chicago fire started by a cow, did London’s start in a bakery or was it a deliberate act by foreign state actors (a Frenchman was hanged for starting the fire)?
Architecture: sometimes the architecture (wooden sidewalks, tar roofs) just needs to change no matter what else is done.
Economics: Will insurance be the driver of cyber security innovation?
The key take-way from this session is to provide the attendees with easy to access fire-metaphors to use when they’re talking about the core cyber concepts of prevention, detection, response, recovery, attribution and co-operation.