6:00 PM -- I’ve thought long and hard about what it takes to interview IT talent. Having worked in lots of different high-tech organizations, I’ve found there are a lot more people out there who should never touch a computer than there are people who are qualified. That’s doubly true when it comes to security and maybe even double again when it comes to Web application security.
If you are tasked with hiring this sort of talent, you've probably run into many of the same problems I have. Here are a few interview questions for potential candidates that have worked for me. I hope they prove as useful to you.
- When did you start in the Web application security world?
- How do you dump HTTP headers and how do you modify them?
- What sorts of things in HTTP might tell you something about the person connecting to a Web server?
- What sorts of user logging do you have on your Website?
- Have you ever been hacked? If so, tell me what happened. If not, tell me about the closest call you’ve had.
- Bonus question: What’s the single most destructive command you can type?
If they say they started in 1970, you can be pretty sure that they don’t know what Web application security is. The modern day Website as we know it -- with CGI -- didn't catch on until the early '90s. Anything before that is a lie or a misunderstanding of the technology. I didn’t start my Web application security career until 1995, which is about as early as you can possibly have started it in this field.
There’s a range of answers for the first part of the question. The candidate could cite some sort of proxy, TCPDump, Telnet, Netcat, or a whole range of other things. The key: Their answer should indicate that they’ve actually done this at some point.
The second part of the question is less broad, but could still include proxies, Telnet, Netcat or a range of other solutions. You want to be sure that they’ve actually seen a HTTP header and modified it often enough to explain how to do it. If they haven’t done this, they aren’t experts. Not by a long shot.
Although this is a very similar question to the one above, it’s important to know there are lots of HTTP headers out there that might be useful for forensics. X-Forwarded-For might tell you what the real origin IP address is. IP can be translated to a service provider, and can be associated with a geographic location. Language sets can tell you about their preferred language. There are other esoteric answers as well, but the key is to get the candidate to show how much, if any, experience they have had.
This is a good question because there are two tricks to it. Lots of people will respond by citing Google Analytics, or if they work for a big company, an application like Omniture. But anything that uses a tracking pixel is bad from a security perspective, because robots don’t render content, and therefore won’t show up in those sorts of logs.
The right answer should prove that the candidate has been looking at application logs and Web server logs. Bonus points for custom logging! But the most important thing about this question is that you need to know that the candidate knows how to run a Web server. If they don’t, there is almost no chance that they are qualified to run your company’s Web server security.
I have mixed feelings about this question, because if the candidate has been hacked, that’s a little scary. But if they haven't, then they probably haven’t encountered a worthy adversary or haven’t had a target worth hacking into. The key here is to get them talking about the hairiest thing they’ve had to deal with in their career, and how they dealt with it. Make sure they react the way you’d want them to react in a time of crisis.
This is the hardest and most telling question you can ask. Lots of people can describe something bad that might be done to a computer system, but amazingly few people can tell you the exact command to do that task. If they don’t understand your operating systems well enough to tell you which command not to type, I doubt they have spent enough time in the business to be considered a qualified professional.
Remember, this is a fun question. You might get some funny or interesting answers that involve building worms that spawn onto other platforms, so feel free to play with the candidate and get them to elaborate as much as they are willing and able to. The key is to get a feel for their abilities. If they don’t know how to do it, that’s not the most destructive command they can type, is it? Granted, some candidates are good at Web research and could find a destructive command to type -- but this a test of their current skill, as they sit there in your office.
Make sure the candidate has some database experience, or proxy experience, if you rely heavily on those elements for your application. Culture fit is important, too, so get them to meet your team. Have your team ask at least one argumentative question designed to illicit a reaction from the candidate. You’ll be much happier having not hired the Grinch, trust me.
In a future blog, I’ll talk about how to find, recruit, and retain good talent. In the meantime, here's a hint: In the Web application security space, money talks.
– RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F*the.net. Special to Dark Reading