6 ms·

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 beca

by smokinn 17y ago

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.

thaumaturgy 17y ago
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 17y ago
  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.
tptacek 17y ago
(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 17y ago
  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-researcher/ 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-typing-the-letters-a-e-s-into-your-code-youre-doing.html http://chargen.matasano.com/chargen/2009/7/22/if-youre-typin... though I can't wait to hear it!
  - tptacek 17y ago
    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 17y ago
      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!

by smokinn 17y ago

thaumaturgy 17y ago

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 17y ago
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.

tptacek 17y ago

(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 17y ago
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-researcher/ 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-typing-the-letters-a-e-s-into-your-code-youre-doing.html http://chargen.matasano.com/chargen/2009/7/22/if-youre-typin... though I can't wait to hear it!
- tptacek 17y ago
  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 17y ago
    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!