Given the CfP for Black Hat US in Vegas ends in a few days – and as apparently some people have already started to think about their TR18 submissions – I’ll quickly provide some loose recommendations on how to write a submission here. There’s quite some reasonable advice out there already (the BH CfP site lists this and this which you should both read as well) but some of you might find it useful to get (yet) another perspective.
I feel somewhat qualified to write this as I’m a member of the BH review board (on a temporary basis & for specific tracks only) for the second consecutive time and I’ve been part of the PC/review team of Troopers since the beginning. I’ve hence developed a certain routine of looking at submissions (and I assume other reviewers have done the same, which might be important for the message for this post). Also I’ve been an accepted speaker at Black Hat myself (six times between 2006 and 2014, at both US and EU events).
Disclaimer: everything you find in the following describes my own personal point of view of looking at submissions; certainly other reviewers have different criteria and different ways of evaluation. Be further aware that this does not describe any official Black Hat statement or position on reviewing (to the best of my knowledge such a thing does not exist. it wouldn’t be a good idea either as usually [review approach] diversity is a good factor in the process).
It’s a Kind of Speed Date
At first you may keep in mind: the reviewer is a human person. While the reviewer reads your submission there’s a kind of relationship between her and you. The time span of this relationship is limited so you must be able to catch (and keep) her attention. This directly brings me to one of the most important points: don’t waste the reviewer’s time and concentration. Keep your stuff clear & concise which in turn usually means: keep it short!
In addition keep in mind that the reviewer might might be a bit stressed or might just have a bad day, and her technical knowledge is limited to certain domains only – at least all these apply to myself – which further emphasizes the importance of giving the reviewer the impression you’re really serious about your stuff and your submission.
Title
It’s a common approach to have a two-part title, with the first part being some wordplay and the second part/subtitle displaying the technical subject. Usually this is a good approach (not least because it serves both types of audiences, see below) and the two successful samples referenced here both use this approach in a nice way. However be warned that “All Your $FOO Are Belong to Us” or “$BAR Considered Harmful” have already been used extensively in the past…
Also just going with “(Attacking|Breaking|Compromising) $TECHNOLOGY” can work well, but you may choose your words wisely. Going with a “Breaking $XY” title and then the abstract reveals you found a way to DoS sth, can be convincing, or not (depending on $TECH).
Choice of Tracks
While this might seem an easy one you should carefully think about it, for the simple reason that this somewhat determines the reviewers looking at your submission (at least the “temporary” reviewers like myself only rate submissions from specific domains/tracks and I strongly assume that the full members of the review board also mostly look at submissions from their respective fields). I once observed a (from my point of view) technically very sound submission fail badly in the process as the guys had chosen the wrong track and one of the first reviewers (being from another field) slightly misunderstood what the thing was about, and subsequently gave it bad review along the lines of “nothing new here”. Many reviewers read the comments of other reviewers (I myself usually don’t and when I do only after I’ve provided my own feedback) so this observably influenced successive reviews. Taking further into account that at some point metrics, scoring and the mathematical instrument of calculation of an average might come into play, one bad review might have severe impact on your chances.
The Abstract
This is a tricky one, namely because there’s different dimensions here:
- in the course of the submission process the abstract is the main vehicle to convey why your research & results are relevant, so the addressee is the reviewer.
- later on the abstract will be published on the web site to attract the conference participants to come attend your talk. This is a different target audience (than the reviewers) though.
Personally I like to see/understand the research approach and methodology here and usually this applies to the audience, too. There’s the old saying of “you don’t give a talk for the other speakers present at the event, but for the audience interested in learning something”. So from my perspective the abstract does not have to contain mentions of those 0-days you found but sth along the lines of “we will lay out our research approach and its pitfalls & challenges, plus how we managed to overcome those” commonly has my sympathy. I’m aware that other reviewers see this a bit differently though.
I’ve noted that in the BH submission form there’s a 300 word limit now which surely is a good idea. Still you can put a lot of not-too-helpful pieces into 300 words… and being German I’m familiar with succumbing to the temptation of coming up with complex grammatical constructions just to be able to put even more content into one single sentence. Just don’t do it ;-). Let me state this again: you should trust the reviewer to be able to recognize your skills and knowledge by reading just a short text.
In general I’m a fan a submissions with a simple three-fold structure like
- short intro or overview of technology covered.
- research venues / coverage of attack paths.
- results, conclusions, tool release etc.
For example this abstract from Troopers17 was a good one (except the listing of the CVEs which could have been replaced by just “several CVEs”).
This one from BH US 2016 is another example of a short, clear & well-structured submission.
Presentation Outline
This is your chance to show you’ve clearly thought through your message and how to convey the relevant points to the audience. Still, did I mention already that brevity helps? When putting too much stuff here there’s a clear risk the reviewer gets the idea that you try to convince her by sheer quantity instead of quality which evidently bears the risk of getting bored. I’d be very careful here. When looking at the samples of accepted submissions found here I really like the presentation outline of the first one but honestly the outline of the second is a tad too long for my taste (and I wouldn’t expect sources/references in there either).
Overall this part presumably is as important as the abstract is.
Message for Review Board Only
Remember what I stated above the relationship between the submitter and the reviewer? Imagine you have a speed date and the other person ends with a “thank you for spending some minutes with me” instead of “I’m a cool person, there you have it”…
Draw your conclusions. Also this is a good opportunity to make clear what has changed in the interim (if you’ve given the talk before) and even to sneak in additional info (not to be found in the abstract) like “after that talk in 2016 the vendor contacted us and we had a good exchange with them. We jointly discussed mitigation strategies but after that we put further research effort into it and identified new venues of circumvention. these will be laid out in our BH 2017 talk”.
At the end let me state this: rest assured, we as reviewers sincerely honor the effort put into proper research, and a good submission is a pleasure to read.
I wish everybody good luck!
Have a great weekend,
Enno
PS: if you’ve made it this far you’ve probably realized that I wrote much of this with the simple goal of making my own (reviewer) life easier 😉