Paranoid Penguin - DEFCON: One Penguin's Annual Odyssey
Maybe because DEFCON invites such high expectations, a few things bothered me. Some are peculiar to DEFCON; others probably are characteristic of hacker culture as a whole. Either way, these observations are offered in a wholly constructive spirit. Nothing worthwhile is worth being complacent about.
The thing that bothered me most consistently about DEFCON this year was the behavior and attitude of many (emphatically not all) of the “red shirt goons”. In case you're unfamiliar with them, all members of DEFCON's volunteer staff are called goons, whether they're serving as actual physical-security goons like the red shirts, manning the information desk or running the massive DEFCON LAN infrastructure. All goons have T-shirts proclaiming their DEFCON goon status, but only the physical security crew's shirts are red.
I'm privileged to call many of these goons friends. In fact, it was the “original goon”, Conal Garrity, who first urged me to give DEFCON a try many years ago. I've seen my goon friends work incredibly long hours with little sleep, irregular meals and little else in the way of extrinsic rewards for their efforts. They're an amazing group of people.
So maybe I was disproportionately bothered by seeing a small number of the red shirts being disrespectful to the point of being counterproductive, in their efforts to manage the large crowds that attended DEFCON 17. At various times I saw some of these guys yelling at attendees, calling them names, insulting their intelligence and making vague threats (though their preferred punishment seemed to be “more yelling”).
One prominent goon even interrupted a presentation I was enjoying to harangue the crowd because there had been an incident concerning one person trying to bungee jump off the hotel's roof and another involving someone with a concealed handgun on the casino floor. The only problem was I'm pretty sure none of the hundreds of people who had up until this point been respectfully listening to Sam Bowne's talk had even heard of these incidents, let alone contributed to them in any way. I understand the goon was frustrated and stressed, but he took it out on the wrong people.
The crowds I saw at DEFCON this year were certainly large, but not unruly nor even particularly uncooperative. Certain goon antics seemed disproportionate. When I described some of them to a nonhacker friend later, his reaction was “sounds like Barney Fife syndrome”. I had to reluctantly agree that yes, it did seem as though authority had gotten to some of these guys' heads just a tiny bit.
Another thing that occasionally struck me was the paradox of DEFCON elitism. On the one hand, in many ways DEFCON represents one of the most inclusive, accepting and open atmospheres I experience in any context. Everybody is welcome: hackers, cops, feds, nerds, script kiddies, lawyers, teachers, students, reporters—even vendors. Boundaries of race, nationality, socioeconomics, creed or sartorial style generally do not apply at DEFCON.
And yet, there's definitely an in-crowd. DEFCON parties abound, which are, as with parties the world over, frequently about who is not invited as much as who is. This shows up in all sorts of contexts, including the speaking schedule itself, but it's subtle, and over the years I've had trouble putting my finger on the real shape, extent and nature of DEFCON elitism. To talk of elitism at such an essentially inclusive event as DEFCON really is a bit of a paradox.
Obviously nepotism figures into practically any human endeavor, so maybe it's no big mystery. But I've observed that many if not most of those who seem to be in the DEFCON in-crowd are more oriented toward attacking things than defending them. I suppose this isn't very surprising, given the way DEFCON markets itself—one of the official DEFCON T-shirts this year featured the slogan “hack everything!”
Why wouldn't a hacker conference concern itself primarily with new attack techniques? After all, as I've just described, much of the content that made the biggest impression on me this year involved attacks. Exposure to new attacks and vulnerabilities provides valuable insights to those of us who defend networks and systems for a living.
So, I don't mean to suggest DEFCON should set some sort of quota on attack-oriented material. However, I do think it's a shame that there's less of a focus on defense at DEFCON nowadays than there used to be. For example, both times I presented at DEFCON (in 2002 and 2003), my talk was included in the “Defense” track—a track that was phased out years ago. Maybe it's time to bring it back. Maybe more people need to submit DEFCON proposals involving compelling, cutting-edge defensive techniques.
And maybe, if we hackers want the world to give us more credit for the constructive things we do, and if we want people ever to accept the broader definition of hacker as creative problem solver, we need to do a little more to avoid giving the impression that we're almost exclusively creative problem makers.
So perhaps I'm less worried about nepotism per se—which in one form or another is inevitable in anything that relies so heavily on volunteers—than I am about its particular effects and ramifications. DEFCON simply needs more defense-oriented people it its in crowd. And I'm prepared to serve in that capacity myself, even if that means having to present at DEFCON year after year in multiple tracks, schmooze at all hours with prominent feds and attractive celebrity lawyers and accept one free beer after another at crowded, hot parties. You know where to find me, guys!
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- Web & UI Developer (JavaScript & j Query)
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




3 hours 4 min ago
8 hours 50 min ago
9 hours 7 min ago
11 hours 44 sec ago
12 hours 54 min ago
19 hours 48 min ago
20 hours 4 min ago
21 hours 55 min ago
1 day 3 hours ago
1 day 8 hours ago