On Thu, Apr 15, 2004 at 09:08:47AM -0300, Mads Rasmussen wrote: > > In their book, "writing secure code, 2nd ed", Michael Howard & David > LeBlanc talks about an exercise when interviewing new people. > The purpose is not to test the persons security skills but to ascertain > how the person thinks about security issues. > > They give an example: >
[deleted] > > Do anyone use similar skills to interview new staff? I've been using a similar question for the last 5 or 6 years. I treat it as two parts-- a general security design part where the candidate tells me about the threats to the system, and a specific design part where they tell me specifically how they'd solve it (alice sends bob xyz encrypted in algorithm pdq, etc). > I find this idea > really nice. You force the person to think as a hacker in order to > answer the questions, will his/hers answers satisfy your expectations? I'm not asking them to think like a hacker, I'm asking them to think like the designer of a secure system that uses cryptography. The good thing about my question is that there is more than one reasonable solution. The different solutions have their advantages and disadvantages, so I can get candidates to talk about that too. > Another interesting idea would be to draw up some code on a white board > and ask the candidate to identify the buffer overflow. _that's_ asking them to think like a hacker. Also very useful of course. Eric
