This morning’s dialog on Twitter from @wmremes and @singe reminded me of something that’s been bouncing around in my head for some time.
Wim blogged about a tweet Jeff Moss made regarding Black Hat DC in which he suggested CFP submissions should focus on offense (versus defense.)
Black Hat (and Defcon) have long focused on presentations which highlight novel emerging attacks. There are generally not a lot of high-profile “defensive” presentations/talks because for the most part, they’re just not sexy, generally they involve hard work/cultural realignment and the reality that as hard as we try, attackers will always out-innovate and out-pace defenders.
More realistically, offense is sexy and offense sells — and it often sells defense. That’s why vendors sponsor those shows in the first place.
Along these lines, one will notice that within our industry, the defining criterion for the attack versus defend talks and those that give them, is one’s ability to write code and produce tools that demonstrate the vulnerability via exploit. Conceptual vulnerabilities paired with non-existent exploits are generally thought of as fodder for academia. Only when a tool that weaponizes an attack shows up do people pay attention.
Zero days rule by definition. There’s no analog on the defensive side unless you buy into marketing like “…ahead of the threat.” *cough* Defense for offense that doesn’t exist generally doesn’t get the majority of the funding
So it’s no wonder that security “rockstars” in our industry are generally those who produce attack/offensive code which illustrate how a vector can be exploited. It’s tangible. It’s demonstrable. It’s sexy.
On the other hand, most defenders are reconciled to using tools that others wrote — or become specialists in the integration of them — in order to parlay some advantage over the ever-increasing wares of the former.
Think of those folks who represent the security industry in terms of mindshare and get the most amount of press. Overwhelmingly it’s those “hax0rs” who write cool tools — tools that are more offensive in nature, even if they produce results oriented toward allowing practitioners to defend better (or at least that’s how they’re sold.) That said, there are also some folks who *do* code and *do* create things that are defensive in nature.
I believe the answer lies in balance; we need flashy exploits (no matter how impractical/irrelevant they may be to a large amount of the population) to drive awareness. We also need more practitioner/governance talks to give people platforms upon which they can start to architect solutions. We need more defenders to be able to write code.
Perhaps that’s what Richard Bejtlich meant when he tweeted: “Real security is built, not bought.” That’s an interesting statement on lots of fronts. I’m selfishly taking Richard’s statement out of context to support my point, so hopefully he’ll forgive me.
That said, I don’t write code. More specifically, I don’t write code well. I have hundreds of ideas of things I’d like to do but can’t bridge the gap between ideation and proof-of-concept because I can’t write code.
This is why I often “invent” scenarios I find plausible, talk about them, and then get people thinking about how we would defend against them — usually in the vacuum of either offensive or defensive tools being available, or at least realized.
Sometimes there aren’t good answers.
I hope we focus on this balance more at shows like Black Hat — I’m lucky enough to get to present my “research” there despite it being defensive in nature but we need more defensive tools and talks to make this a reality.