Thoughts from the Interview Room

I had an interesting comment from James in an earlier post about penetration testing teams. There were a lot of questions in there so I thought I’d write a response as a new post. We’re still hiring by the way, so if you’re looking to join a fledgling security consultancy on the sharp edge of the ‘verse, you could do worse than get in touch (yes I know that it’s the blog for snakeoillabs page but it’ll get to me).

I also know a few friends who have been tarting up their CVs – we’re in that period between bonuses being slashed and InfoSec, which usually precedes a large number of job moves for many so it’s the right time of year to start thinking about changing your employer.

Here’s what James had to say on the subject:

Assuming your’ve finished hiring – what questions did you ask your interviewee’s? Did you get them to demo anything? It’s intresting to hear from an HR side of things – whats your take the techie tester and the ‘technical sales’ kind of pen tester? Often it’s good to have a non uber geek on your customers site to act as a contact while doing external audits – what sort of ratio does you company have of these?

It’s an intesting industry with some very different extremes isn’t it.

What questions did you ask your interviewee’s?
This is an interesting one. I’ve been interviewing people for security-consultancy related positions for years now, and the questions have definately changed over time. A good technical interviewer will recognise that the person on the receiving end is probably more nervous than they ever would be in the course of normal employment. This presents the interviewer with two options – 1) Put the candidate at ease. 2) Turn up the heat. You’d be surprised how many people seem to opt for number 2, even sub-consciously.

I tend to ask a mix of technical and non-technical questions. What I try to do at the interview stage is establish the boundaries of knowledge and the degree of bullshit involved in the conversation. Quite often people will embelish details of what they’ve done in an interview situation but the smart people only do so slightly and only in areas that the interviewer appears weaker than the candidate in, so the first thing I do is find out what they really know. Here’s an example:

Me: Tell me about some of the things you’ve been doing when you’re not being billed out.
Candidate: I’ve been writing a port scanner because nmap’s really slow. It’s not always accurate either, especially with UDP. I thought I’d write it in assembly because it’s faster.

This is the worst kind of response and it doesn’t wash with me. First of all, yes nmap can be slow but by doing some work beforehand with hping or scapy you can get enough information to optimise nmap if it’s that big an issue. Secondly, the point about Nmap being inaccurate with UDP results is valid, but applies to generic UDP scanning techniques in general so he’s either really really smart (possible) or really really stupid, or just trying to really really impress. The final statement adds weight to the argument that what’s coming out is probably BS, as limitations in port scanning tend to be network-related. For all I know I could actually be speaking to the next Fyodor or the author of Unicorn. So I follow it up with another question.

Me: What makes your scanner faster and more accurate than nmap?

The candidate will either dig themselves deeper into a hole or will surprise me with some deep-founded insight that I’ll find really impressive. The candidate will never say “Actually it’s only faster at the moment because it doesn’t compensate for network latency, and it does send protocol-specific datagrams but there aren’t many supported ones yet as I haven’t had the time to get it working properly, but it spots DNS.”

Once we’ve established knowledge boundaries, what I’m looking for is whether or not the candidate is a heavy bullshitter. Bullshitters are the consulting equivalent of Albatrosses, and need to be shot out of the sky before they can land on the bow and offend clients. As a wise man once said:

You may not know shit from shinola, but as long as you’re not afraid to tell me that and you’re willing to take a taste test to find out then I’m happy. If you’re polishing your shoes and it’s just getting dirtier, don’t try and convince me you’re going to be the worlds best shoe shine boy if I take you on.

Other bullshit catching questions I often ask include (although I’ll use different ones in your interview):

• How does UDP fragment IP? (It doesn’t, IP is lower down the stack and fragments UDP, not the other way round)
• Name all 7 TCP flags. (There are 9: SYN, ACK, PSH, RST, URG, FIN, ECE, CWR and NS – thanks Dave!)
• Alice wants to send an encrypted message to Bob. She sends Bob an encrypted email, along with her private key but Bob can’t decrypt the email. Why? (Alice should’ve sent her public key, not her private one!)
• Is ICMP a TCP or UDP-based protocol? (Neither)
• I’ve found a buffer overflow in the TCP/IP stack of an Operating System. Would the return address sit at the top or bottom of the IP stack? (This question mixes two different meanings of the word stack to create something completely nonsensical. Only fools (and yes, I mean plural) would attempt to answer this)
• My web application uses SSL Certificates to identify users via their browsers from across the Internet. The accreditor wants me to use a less secure form with a username and password. Which is more secure and why? ( A slightly subjective one in that some would recommend a username and password, and smarter people would go for both. In this case the certificate identifies a certificate holder or browser, but not necessarily an individual user, especially if the user’s computer is shared.)

If all that seems horrible, then I’m sorry but it is. If I had a penny for every firewall administrator who thought he could jump across to the role of a senior consultant and lead on application tests because of a Checkpoint seminar on deep packet inspection then I’d be at least 27 pence richer. Of course, if you tell me that you don’t know, don’t know but would find out (better), or that you think that the questions are unfair (true, but doesn’t change the fact that I asked) then you won’t see the rest of them. If you find yourself coming up with increasingly elaborate ficticious answers, then ask yourself how long you think you’ll be in the job if you have to make all this stuff up to get through the interview.

Once that’s out of the way it’s all smooth sailing from there. It all boils down to several things:

• Do you know enough about the job to do what I need you to do?
• Can you do it without being wet-nursed?
• Can I leave you in a room with a client on your own, walk out, come back in five minutes later and know you haven’t started barking, arguing or masturbating in front of them
• Do you fit in with the team?
• Are you likely to bring any money in?

Get 3 right and you have a job. Get 4 right and you’ll have a job for life if you want it. Get 5 right, and you’re one of those expensive rare breeds that are often spoken about but never seen. In my view the most important things are a lack of wet-nursing (as it’s one thing to reduce your own profitability, but reducing that of others in a consulting environment is very bad for your career aspirations) and an ability to fit in with the team. After that, bringing money in is the key nice to have, closely followed by (but not entirely matched) by field ability. Please be aware of the fact that I’m using security testing as a general example here because of the previous post. This applies just as much to a support engineer or receptionist as a hardcore exploit coding bluetooth sniper rifle toting ubergeek.

We’re aiming for 20% hardcore techie, 40% midrange and 30% ’sales aware’ techs. The remaining 30% are likely to be Juniors, which leads me to an interesting point. Most consultancies rarely make vast sums of money from experienced hires. The greatest amount of money made comes from the juniors that are put on the job. We tend not to put juniors on client-facing jobs, which is why I live in a two bedroom end terrace and not a mansion. Our clients on the other hand love us for it as they know they’ll get the resources to do the job well, rather than the resources necessary to get the job billed. Still want a job with me? Get in touch through the link above.

If anyone’s interested, I’ll post some of the answers I’ve heard to the questions above. What kind of interview experiences have you had, on either side of the fence?