Submitting To A Cfp

I recently posted a twitter thread with some advice for submitting to CFPs and writing abstracts. I’m FINALLY containing it in a blog post with a few corrections, updates, and additions

The original tweet:

Some examples of talks I’d attend:

  1. So you’ve been in the industry for a year (or more)? You’ve learned a lot. Share with others the resources you found helpful, the mistakes you made, and what you wish you knew a year ago. Many BSides have first time attendees and people looking to get into the field.
  2. Saw a presentation of new research that blew your mind? Reproduce the work and share your successes and stumbling blocks. Experts may show off cool new stuff, but your experience is more relevant to most attendees.
  3. Fascinated by a specifc topic you’ve seen lots of different work on? Take all the prior art and summarize it for someone who doesn’t know about it. Part history, part techical, part future trends.
  4. Got a new idea, trick, hack, attack, technique, solution, etc you came up with? Explain it. You don’t need a CVE or 0day or 12 step process, but if you’re doing something new that works for you, tell people!
  5. Have a track record of coming up with cool new ideas? Share your approach, methodology, thought process, or where those ideas come from.

Presenting is absolutely not the only way, but is a great way of exercising and developing the skill of communicating technical information. Get practice presenting to be prepared for that big hack you figure out some day. Rockstars hacking the planet live onstage get lots of attention, but it’s all the other types of presentations that actually convey information that can be directly applicable and most useful to attendees.

Some points to keep in mind about CFP submission:

  1. Put way more time/effort into your submission than you expect the reviewers to spend reviewing it. Respect each other’s time.
  2. Target your submission to the right venue and it’s audience. Some talks are appropriate for your local BSides. Some for Black Hat. Some for DEFCON. Very few are suitable to all three.
  3. If you’re sharing something new, make sure it’s clear in your submission. If you’re building on prior art, say so along with what makes your work different.
  4. If you have a specific target audience, say so. This could boost or lower your chance of acceptance, but either way results in a better fit for the event.
  5. Get help proofreading your submission from a variety of skill levels (including non-technical). They can let you know when you’ve got implicit assumptions, ambiguities, or just typos.
  6. If you don’t get accepted, don’t blame the reviewers or complain, take advantage of the opportunity. Ask for feedback if available. Learn what to do differently next time.
  7. Reviewers need to pick talks attendees will appreciate. If you can’t make a clear point in 200 words, they’re worried about what 50 minutes would end up like.

Writing a good abstract:

The abstract tells reviewers why they should accept your talk because it tells attendees why they should attend it. An attendee-focused talk is the best kind, so an attendee-focused abstract is the way to go.

Think back to 5-paragraph expository essays you probably had to write in school - all the same guidelines apply (including knowing when to break the guidelines).

Here’s one method I use to formulate abstracts that has worked well for me:

  • Sentence 1: Broad statement everyone can understand that sets the scope of the topic to be presented. Say something people will relate to and understand. Don’t deter anyone yet.
  • Sentence 2: Narrow statement that presents a specific flaw/problem/misconception I hope to clarify. This is where you can challenge an assumption or tell people why they might be missing something.
  • Sentence 3-5: walkthrough of the presentation. 3: background info. 4: list key points or examples I’ll bring up 5: explain the result/demo/conclusion i hope to hit home with
  • Sentence 6: Broad statement telling what I hope they take away and how to use it. Sometimes I specifically say who should attend here, because this is where I tell them why they should attend.

After all that - did your submission get declined? Checkout part 2: Congrats, you’re rejected!

Did your submission get accepted? more coming soon…


Joe FitzPatrick

Written by

Joe (@securelyfitz) is an Instructor and Researcher at SecuringHardware.com. Joe has spent over a decade working on low-level silicon debug, security validation, and penetration testing of CPUS, SOCs, and microcontroller. He has spent the past 5 years developing and leading hardware security-related training, instructing hundreds of security researchers, pen-testers, hardware validators worldwide. When not teaching classes on applied physical attacks, Joe is busy developing new course content or working on contributions to the NSA Playset and other misdirected hardware projects, which he regularly presents at all sorts of fun conferences.

Updated