The main interview centers on software security, and is focused on real world scenarios. We avoid "explain this OWASP top 10 blah blah blah" kind of questions. The goal is to see if you can reach the outcomes we expect, regardless of how you may approach them. I don't care if you can explain SQLi to me, you should be able to approach exploiting it on a live system.
We will:
* Give you a sample system and ask you to threat model it. Maybe you will use STRIDE, maybe you wont, but we hope you will find some threats using structured techniques.
* Ask you about secure systems you have designed, why you made the choices you made, and how you would make them differently today. We want to know if you have a methodology, a structured approach, and experience.
* Expose you to vulnerable code implementations, and running systems. We hope you will discover vulnerabilities.
* Show you examples of our systems, and ask you how you would secure them. We want to understand if you can see, and discuss security architecture.
* Role play developer interaction scenarios. Can you handle soft skills?
* Have you done any of this at scale? Do you understand how to make it work for 10, and 1000 developers? Explain your experience, how would you do it differently?
I can go on, but again the emphasis is evaluating whether or not you can do the tasks we need you to do, with a high degree of quality in whichever way works best for you, while also being able to completely ignore your resume if we want.
It is extremely difficult for us to consider hiring junior candidates, and we frequently encounter candidates with no deep experience. While it is unfair to expect candidates to have spent time at home treating this as a passion project, those are the ones im going to hire because they can deliver the outcomes in an interview. To combat the hiring difficulty, we have arrived at this approach which allows us to send candidates through the machinery quickly, with low bias.
Huh interesting. I work in infosec (but not a hiring person). I would normally rank this as an important skill. Not because i actually care about getting an explanation but because half the job is getting non security devs to care about security issues/fix them/not make them in the future. In my experience it is really difficult to do that if you can't explain the vulnerability to them.
api.example.com/;SELECT * FROM customers
See. This is allowing anybody to dump all customers or delete customers (show the next query). Developers understand that this is not an intended feature.However, this is not really what I mean. If you are interviewing for a role in software security, you should be current on the industry and ready to talk sources and research. At a minimum, you should have areas of interest that you are passionate about discussing, even if you are still ignorant about the deep details.
You wont do well if security is something you only do 9-5, but I don't want you working for me after hours.
Indeed there is a major issue with HR focusing too strongly on certificates because they lack the knowledge to evaluate a candidate any other way.
I thought this is exactly what holders of the OSCP certificate has demonstrated during the exam?
See my earlier comment regarding the relative strength of candidates with OSCP.
CEH is box ticking. OSCP is breaking into stuff. That hacking is about "mastery of technology" I don't agree with. The latest major vulnerabilities identified this month were very low hanging fruits, and I bet you there's still way too many unpatched instances of BIG-IP, NetScaler and Windows DNS out there right this moment. ...two of which have available POCs online for any scriptkiddie to get their hands on. If not all three... the researchers who found the Windows DNS vulnerability have agreed to hold their horses for a while, letting admins patch their systems before releasing all details.
Latteral movement in an Active Directory environment is trickier than looking up a version number and trying your luck with a POC, sure, but you give too much credit to hackers, man. :P
Have you been through the course and exam yourself, or are you basing this on something else? If you've been through the experience, which parts of it contribute to you not valuing it?
I'm relating the facts about candidates who applied to my roles with OSCP certifications. I did not hire any of them.
I do not specifically dislike OSCP, its that I do not value any of the certs merely because someone possesses them.
Certs are a marginal signal to me about your potential for discipline, may inform how deep I go on questioning, and thats it. Conversely, certs may lead to bias, particularly for some very lame ones.
I don't think it's very fair to weight letters on a resume so heavily, it's about what you can do in the role I have for you.
Having them is not something that will make a big difference to me.
Im passing on your candidacy when you have the cert, but put me to sleep with the practical application. I'm less interested if you can study, and more interested if you can LEARN.