(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.
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!
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.
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!
* 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.
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!
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.