[smokinn]

I don't plan on applying but I'm curious as to why you would hire a great developer without security experience over someone who knows app security.

Is it because you offer a lot of training or simply because you figure he'll pick up what he needs fairly quickly and eventually surpass the app security expert? Or is there a different reason?

I asked a similar question to Zed Shaw at CUSEC last year. Something along the lines what do you think about Joel Spolsky saying you should only hire the very best. He said he prefers someone who's willing and able to learn because he'll just teach them and they'll become a very valuable person.

[tptacek]

(Speaking of, I think I'm speaking at CUSEC this year, and anyone who's got any advice for me, I would pretty much kill to get it.)

It's simple. The best security researchers are people who have (or at least could) ship software. There is a big swath of high-end work that you simply can't deliver if you can't code. That's where Matasano plays. I suppose you could be a very strong Payment Card Industry certification consultant just by getting very good with WebInspect, but to reverse an embedded kernel, isolate the code that handles a protocol you caught on the wire, and then code a fuzzer for that protocol, you need to be able to read code in a bunch of languages and write code very well in at least one of them.

As a consultancy, there are fringe benefits to our clients from us staffing projects with former devs:

* Devs know how to talk to other devs without sounding like morons or bureaucratic checklist-checkers, and sounding like that is a big problem in my industry. For instance, devs don't tell clients that single-line changes to shipping codebases are "trivial" and should only take minutes to roll out.

* Devs can provide remediation advice that is better than "switch to parameterized prepared statements" or "check input better".

But the reality is, we like working with devs because they are on the whole better at breaking software. They read faster, they don't balk at writing complicated test programs, and they know how pieces fit together --- and those junctions are where software usually fails worst.

[smokinn]

Speaking of, I think I'm speaking at CUSEC this year

I sure hope you're speaking given that they just today announced it on the website http://2010.cusec.net/11-20/thomas-ptacek-security-researche... =)

All the advice I can give you is be honest and be yourself. CUSEC has always been very informal compared to most other conferences, more of a discussion between students and people they respect more than anything else.

John Kopanas, the founder of CUSEC, mentions it every year. He created CUSEC simply because he wanted to talk to and hear from people in the software engineering community that he respected. It's always been that every since.

EDIT: I tried to bet one of my friends that you would have the most technical talk at CUSEC. He wouldn't take the bet. If your talk is anything like this post http://chargen.matasano.com/chargen/2009/7/22/if-youre-typin... though I can't wait to hear it!

[tptacek]

I figured the room might be a bit too generalist to want to hear 40-50 minutes of crypto flaws, and so I was thinking about wrapping the crypto stuff up in a talk that made a technical case in favor of DRM.

If people tell me real-world crypto is going to keep people in their seats, though, I'm totally down for that; it's a much easier talk.

[smokinn]

The room will indeed be quite general. You'll have anything from some (though probably few) 1st year students all the way to some (few again) professionals and masters/phd students. Most will be in between, skewing heavily to last/before last year CS/SOEN majors.

I don't feel very comfortable giving advice about the direction of your talk; I can only speak for myself. If you have questions I highly recommend you ask the director of presentations. That said, personally I think the case in favor of DRM could be quite interesting since I've never heard a technical person argue in that direction. (At least not while doing more than simply assuming the token devil's advocate role.) If you make a good case you'll definitely get lots of questions/objections after!

[rms]

Can we get the two paragraph version of the technical case in favor of DRM now? I'm very curious.

[tptacek]

* That the current state of the industry in crypto development is so weak and poorly understood that many of the statements people make about DRM are rooted not in theory but in observations about incompetant cryptosystems, and that when implemented well, DRM crypto actually has a good track record (cryptocard satellite TV, Blu-Ray). I was hoping to use this thesis as a coat rack for a bunch of practical advice about crypto in general.

* That the security goal of DRM is not about absolute platform integrity, but about meeting the commercial objectives of content providers, and that when you relax constraints from "absolutely protecting media" to "making sure titles are difficult to pirate during their new-release window to maximize profit", you get opportunities for interesting approaches to security, like renewability.

* That taken together, these two ideas suggest that DRM is actually a really interesting CS problem, and --- leaving politics out of it --- even if you believe it's destined to fail, it's worthy of study.

[smokinn]

Also, since Matt Knox will be there, this would fit well in a there's interesting problems even in the "evil" side of programming theme.

[mattknox]

I'd love to hear the tech case in favor of DRM, but then I'd also love to hear 50 mins of crypto flaws. Sounds like it'll be a great talk either way!

[ephermata]

Plus, don't you have a product which may benefit from developers, even if they don't start working on that project?

[tptacek]

We do, and we have a full time dev team on it, but I don't like promising people a product development role when I'm looking for app security people. We're hiring on the product too!

[thaumaturgy]

I've only had to hire two people so far, but based on that limited experience, I'd definitely prefer someone with passion, interest, and willingness to learn, over someone with experience (and without the rest).

For one thing, even though everyone always goes around arguing that there's only one right way to do things, the fact is that any given organization has their own habits and methods and reasons, and very experienced people may be more reluctant to "fit in".

[smokinn]

That problem cuts both ways though.

You have the experienced people who are stubborn and want to do things their way because in their experience that works best but you also have the experienced people who know that the best way to do things is the way that the team is best structured to implement well and maintain efficiently in the future.

The passionate people have the same problem. Passion brings on a strong desire to do things "right" so some will refuse to adapt to the team, their passion dictating what the team should do and others will be more passionate about results rather than methodologies.