In 2035, I will be 65. Most likely, unless I was to take up photography or cat breeding, I will most likely still be in this industry doing pretty much what I’m doing today.
I submitted a bunch of “how to fix” talks to OSCON (the unconverted) and Black Hat (the converted). I’ve spoken at both before, and I know I don’t suck too badly at speaking. Knowing that you suck more than other folks is the first step to being a good speaker, and I learnt that many years ago and have been learning ever since. Nowadays, I get good reviews from my customers, got good reviews and write ups for my last talk at OSCON. Black Hat provided me with my feedback which indicate that most of the folks who returned the forms liked what I had to say and how I said it, although there is room for improvement. When I train professionally, I am probably my harshest critic. That said, everyone – including me – can always learn how to present better, and make presentations that don’t suck. But let’s put that aside for a moment, and look at our industry’s premier developer and security conferences.
Why you will not learn solutions at any major event this year
I know this might come across as sour grapes, but seriously, when the biggest “security” conference rejects my talk (which will show how to scale code reviews in large enterprises, a huge problem for the Fortune 500, government and defense types, who just happen to send a bunch of folks to said conferences) in favor of the same theoretical root kit talk as we saw last year and a meta-theoretical anti-root kit talk targeting that specific theoretical root kit talk, they’ve lost the plot. When the largest *developer* conference rejects three of my talk suggestions, two of which are teaching developers how to code more securely (including a advanced level 300 class – I’m sick of teaching “hey, this is htmlentities(). He’s your friend”), they’ve lost the plot, too*.
OSCON’s security track is a paltry seven talks, basically most of one day out of five. And only one, by my friend Chris Shiflett, will teach you how to avoid the most common problems in web apps and another reports on the use of a source scanning tool by the open source community. Each of those talks is less than an hour. The chance you’ll learn something you don’t already know about PHP security is pretty small. At Black Hat, so far, there’s plenty of announced talks, but it will take you until day two before you learn how to do something useful. There are no other how to fix talks at Black Hat. That’s very, very sad.
There are some fine speakers at each event, for sure. But some have been seen before. And before that, too. But when you’ve seen ten theoretical root kit talks, or the fiftieth hundred buffer overflow talk (the same attack since 1988? kill me now), or yet another XSS talk or eight, we get it. Software sucks.
How do we fix it? Show me the money!
Do I want to be fixing SQL injections, buffer overflows or cross-site scripting issues when I’m 65? Hell no. These are solved problems. We know the solution. They MUST be burnt into the APIs so that programmers (no matter what skill) CAN’T do it the wrong way. There are some fine researchers working in the field, and you’re not going to hear them talk about fixes at Black Hat or OSCON. It’s Fear Uncertainty and Doubt. Scare the punters so you’ll buy their products or services. That security sales method is so 1995 when we thought firewalls were kinda neat.
It’s the reason the security industry is little more than snake oil modulo a few gems here and there. Why don’t A/V vendors go white-list? Spend 10 minutes telling your computer about the programs you use and white list the behavior of those probably very common apps? No more virus infections as everything else is untrusted and doesn’t run. That’d kill their
shakedown revenue stream.
To be a smart security vendor today, you provide value to the customer by showing them how to architect a secure solution, how to build secure software (by training their devs – we can’t write all the software), how to test and review software (or indeed provide these services as an external audit function), so they don’t have to worry about spending *more* money on useless controls or worse case, notifying the regulators and their customers that they’ve screwed up and “gee, we’re sorry! we tried our best. Here’s $100 bucks”. Value folks, value. We’re here to provide secure business, not scare money out of folks. Once the horse has bolted, it’s far, far too late. That’s why I think forensics and a lot of compliance is a total WAFTAM. Dead money.
Providing solutions is exactly what we’ve been doing at OWASP. We provide value. Some of the solutions are actually getting towards voting age. We just need to get it out there so you don’t make the same mistakes, time after time. I’ve dedicated the last four – five years to researching, describing and educating how to fix things at OWASP. And yet, we don’t get no love at major conferences. And here’s why – they don’t want to tell you how to fix it. They want headlines in the meeja. The meeja only know about attacks, “hackers”, and people losing money to organized crime gangs, or their daughters to the nasty pedos across state lines. So the conferences provide that. We all lose with this approach. Luckily, with OWASP, we run the conferences, so this year, I will speak, and hopefully it will be useful to those who attend.
But realistically, the folks we want to talk to are at BlackHat and OSCON, not at OWASP (yet). So let’s learn …
How to write a successful talk submission
First off, and foremost, be honest about why you’re going. You’re a conference whore, and so am I. The hallway track is their raison d’etre, and best experienced with booze and lots of it. But how to get there… write a submission!
0. The title must be snappy. “Attacking OMG PONIES!111 2.0” All good talks have 2.0 in them somewhere.
1. Subject matter must ONLY be about attacks, exploits, or bragging. The more esoteric the subject of your attacks, the better. I’m talking to you, side channel attacks.
2. Reading poetry to the attendees is only acceptable if it’s accompanied by images of death and you’re dressed in a funny hat, so try to come up with a reasonable approximation of how much your new tool (P0NIE PWNER) haxxors the badness (OMG PONIES!!111) you claim to attack. You don’t need to provide the tool, just claim it exists. No tool / exploit == no attendance.
3. Don’t include anything – ever – about how to fix the problem. That’d ruin the the “hacker” image of the conference.
So screw them. See you at Black Hat. I’m the one who looks like a trans-gender lady of negotiable affections and I’m lovin’ it.
* OSCON has a talk on PHP security, by Zeev Suraski, one of PHP’s founders. The talk (PHP Security: Fact and Fiction) which sounds pretty defensive. Hopefully, it will say something like “gee, sorry about that!” to all the attendees. I’m very hopeful about the claimed agenda – it talks about what is changing in PHP to fix their previous
stupid insane security decisions and lack of a security architecture. PHP *must* move in that direction, and fessing up to current and past indiscretions is the first of at least 12 steps to resolving the issue. Look at ASP -> ASP.NET. Same thing.
2 thoughts on “Why I will have a job in 2035, or how to write a successful talk submission”
p.s. Here’s the titles in case you’re interested:
* OSCON 1. php++ Safer Architecture Patterns
* OSCON 2. Code reviewing PHP applications
* OSCON 3. 300 level Application Security tutorial
* Black Hat. Code Review 2.0
Notice… these are all brand spanking new talks. I rarely if ever give the same talk more than once. Except for the Ajax talk. That one was given a fair bit due to extensive demand. It’s now officially retired.
You know, the secret to successful speaking is standing in front of a large audience, and pretending they are naked.
One time I got it wrong. I stood up in front of a lecture theatre full of international students, and pretended I was naked. It did not work as well. But you might suggest to your friend Chris that he try the strategy as OSCON as another form of revenge.