On Security Conference Themes: Offense *Versus* Defense – Or, Can You Code?
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.
/Hoff
Hi.
I think there is a simple (hidden) reason that skews the offense/defense ratio at conferences, and don't see this changing for a while. Lots of people assume its skewed because offense makes headlines, but the hidden reason is that defense makes money!
What i mean here is simple:
If i find a new way to attack X, i have no way to easily monetize it as a good guy. (Instead i trade it at a conference for marketing. This is also why most offense talks are given by people selling services.)
Most people who find new ways to defend X, _do_ have a way to monetize, and will try to build a product or offering around it (if it is indeed new enough or good enough).
Now if i do build it as a solution, then talking about it too early bleeds my trade secret or becomes a product push which will be frowned upon.
So.. its not that conference organizers are just peddling innovative offense for headlines, its also that innovative defense has an alternative route to market..
@haroonmeer
@haroon
Pretty much what I meant when I said (above):
"More realistically, offense is sexy and offense sells — and it often sells defense. That’s why vendors sponsor those shows in the first place."
…but you voiced it (as you always do, damnit!) so much better than I.
Good to hear from you, man.
There may be a sort of cannibalizing effect in our industry as well. An attacker creating a new exploit/attack gets press (and some haters who dislike full disclosure). A defender creating a new defense gets people poking holes in it and basically being antagonistic. If someone came up with a new IDS with a new approach, the first reaction is probably not positive (already done that, this isn't new, it's not perfect, you don't have a POC, etc). That or, as you and haroon have said, it'll be perceived as a product push.
We're a finnicky bunch, us security geeks. And I think you're right, coding prowess helps, as many non-coders can get a quick elitist cold shoulder.
In the end, it's still about *doing* something, that gets attention. I think offense is probably easier to actually demonstrate the doing, than defense usually is. Likewise, defense is often an answer to offensive innovation…which might suggest defense takes more knowledge? (You have to not only come up with the ideas offensive people will come up with, but stop them a priori?)
So, to that end, how does one make defense sexy? And to the matter, innovative, defense that isn't just about patching, firewall denies, and log-reading? Creative coding of snort rules for brand new things? Do armed forces CTF events do it, or academic red-vs-blue team events with students as the blue teams?
I agree that offense sells defense and that offense is, for all intents, sexier. Think about a cool attack, I figure out how it works, get it to the point where it is stable, can run it in front of people, and pow a moment of self awareness dawns on the audience (sometimes). It can have so much inherent imperfection, the attack code doesn't even have to be well written, it only needs to find one hole in one version of whatever with enough unallocated memory to jam shell code into, and if that platform combination is prevalent thousands, millions of machines can be owned. It can take one of the many tried and true attack methods (fuzzing, parameter tampering, etc.) and show how the latest platform (mobile, wireless, etc.) didn't account for it in their product hardware or software implementations.
Then there are tools that take those known attacks, combine them with a way to take control of a machine in a stable way, and second pow, we realize that all of the knowledge required to pull off an attack times hundreds of possible attacks is packaged in a neat interface anyone can use, increasing both the possible prevalence of certain attacks on known exploits as well as the population of people that can pull the attack off.
These tend to be the three formats of talks on the offensive side (new attack, attack on new platform, simplifying groups of attacks for a single offensive). About the only way security people can participate in this, the fun side, (without breaking the law) is presenting the work as research or tools for the "defensive" community, with at least a stated goal of offering better defense or at least better situational awareness to other security professionals.
Defense is icky, especially the way we have to do it. It is the equivalent of fixed fortifications, things in the words of General Patton, attackers go around. It is showing better ways to read logs…stare at configuration, patch things. And to be good at it you have to block thousands of possible scenarios, listen to people complain about your blocking, and implement solutions that might not be foolproof, but at least must be fool usable. For the engineering mind, these are troubling ambiguities with no sight of the desired near perfection reached, the satisfied relief one feels when code executes successfully.
If you are a coder, it is the equivalent of looking at version control, process engineering, naming standards, project management documentation: the crap you need to do but wasn't the reason you started coding in the first place.
—-
One thought I have though, is that there are a bunch of conferences whose presenters don't drop code, don't talk about offense in any meaningful way, and every presentation is on some management type initiative or "state of the industry". I would put NY Forensics, SC Mag, and a host of others in that category. I don't personally find them as exciting (they lack the "event" feel that the conferences you mention have), but many security professionals working in corporate America feel (I think correctly so) that they must expose themselves to both sides of the equation in order to be effective.
So if RSA, Blackhat, and a host of smaller shows are about offense, there are a number of conferences about management and tools (which might as well be defense I guess).
You don't write code?
There's hope for me yet. (I write crappy Powershell nowadays, but that's about it. I was never any good at it)
Great post. I need to write my own to explain that Tweet. Coding can be part of the answer, no doubt. I've found my team writing our own tools because we can't buy what we need. Building is also about creating the team, the processes, the operations — none of which can be bought. Thanks for the mention Hoff!
There is definitely room for more work on active mitigations for attacks. Things that take advantage of flaws in attack tool protocol implementations or coding come to mind. Many people in defensive roles don't have the requisite background in either programming or network protocol design to match the work done by committed designers of offensive tools. Of course many attackers don't either.
Making an effort to actually understand what happens in a network protocol stack all the way down to the PHY would be time well spent for all manner of security professionals, whether they care to write code or not. The embarrassment of riches (as it were) of buffer overflows in everything and non type-safe languages has encouraged laziness.