“The infosec talent shortage!” “There’s too many roles and not enough candidates!” So many excuses get thrown around about why security teams can’t find talent. Let’s cut to the chase – yes, hiring is hard and there are reports of more jobs than candidates. However, many of the reasons a team can’t find talent is due to the approach used for security hiring. There are actually many tricks and techniques that can help your team-building approach.

Let’s explore 3 changes that can dramatically increase your ability to hire great security folks

#1 Get rid of the security unicorn job description

#2 The fallacy of certifications and degrees

#3 Look internally – growing security members from within your company

#1 Get Rid of the Security Unicorn Job Description

How often do you see a job description like this:  “Junior security analyst needed. Must be expert in red team and forensics. Previous experience leading organizations through ISO27001 certification. Previous coding experience required.”

Wow, let’s unpack that. We just defined a junior level analyst role, tacked on expertise in two different domains (red team and forensics), then asked for experience in a totally different domain, ISO certification experience. And, to top it off, threw in another entire profession at the end – software development. Sure, it’s farcical and exaggerated, but it’s really not that far from the truth of many job postings. This brings us to the first tip for growing your security team – take a hard look at your job descriptions.

A critical activity before attempting to grow your team is to have a clearly defined job description. This sounds like boring HR driven requirements, but it really is crucial for hiring security talent. It’s important to step back and look at the core skill areas and the level of expertise needed in each domain. For example, while at Twitter I lead this exercise when growing our application security team. Here are the core skills we were looking for:

• Application security testing
• Secure code analysis
• Secure software architecture design
• Ability to develop security solutions
• Developer security training

During interviews, we would find candidates great in security testing and code review, but poor in their ability to develop security solutions or vice versa. As we dug in, we realized we were searching for the unicorn. After weighing the different areas we discovered that we actually needed two different roles – an application security consultant to help drive the secure SDLC and review and also and a developer-focused security engineer to build reusable software in the name of security. As we broke this up into two unique roles we also weighted the importance of the different core skills and communicated this to the interviewing team. We don’t need the world’s leading expert in every category. Familiarity in some areas is appropriate, whereas expertise in other areas is a must for the role. The important item was to define these needs, document them, and communicate to the interviewing team. Now, with a clear definition of skills and levels of expertise, we were able to find great candidates for both roles.

#2 The fallacy of certificates and even degrees

A certification is great for learning, but it’s horrible as a screening mechanism for hiring. I get why people hate the job descriptions that ask for X certification. I agree, it’s a bad and lazy approach to hiring. But don’t blame the recruiters, they are taking the lead (or lack thereof) from the security hiring managers.

Instead, hiring managers have to work with the sourcers and recruiters to identify skills, experiences and potential previous roles that indicate a good potential candidate. Talk with you sourcer and describe the role and previous experience that would be relevant. Also talk about other similar roles that aren’t a fit since that will likely come up. I’ve also found it very helpful to take it a step further and craft a few specific screening questions recruiters can ask candidates during their initial call. These can be relatively basic questions, but the important thing is to create buckets of potential answers – ‘great’, ‘good’, ‘not a fit’. This way the recruiter can do an initial screening to see if candidates are a good match to begin the interview process.

Here’s an example:

“Tell me a few considerations for secure password storage within a web application”

• Great answers – they talk about ‘pbkdf2’ or ‘bcrypt’. The candidate possibly mentions that these only protect against offline attacks against the hash so online attacks must be considered via brute force protection. May touch on other related concerns like password reuse attacks.
• Good answers – mentions using a good hashing algorithm and a unique salt
• ‘Not a fit’ – Generically mentions to just “use encryption” or to store it in a database and be sure no one can access it without any other details

As you can see, we’re not going into great depth with a single question. But if you’re hiring for an application security role a reasonable candidate for a non-entry level role should easily respond in a way to be bucketed into good or great – and hence move forward to the hiring manager. Also, just the activity of having a security person explain a security topic to a non-security co-worker is a great test. If that is a difficult experience for the candidate then you may not want them to represent the security team interacting with others in your company.

#3 Growing security members from within your company

Hiring is both a science and an art and while good interviewing may identify talented individuals, there still is the unknown element whether the individual will be successful at the company. However, if you “hire” individuals from within the company you have an incredible advantage, they already have a track record of success (or not, in which case you should tread carefully).

But how do you hire a person that isn’t in the security team into a security role? Don’t think of security as an entire discipline from top to bottom, but rather a specialization on top of an existing base skill. Here are a few security roles and base skills:

• Application security engineer – software developer
• Enterprise/Corporate security engineer – SRE, IT, or DevOps
• Security risk management – compliance, internal audit, risk

Suddenly, you’ll notice you have a large pool of individuals more than qualified in the foundational skills for your role. In addition, they already know the ins-and-outs of how the company and tech stack operate. Plus, since they’ve worked at the company for some amount of time you’ll have real references on their performance. With this foundational knowledge, you have a great indication if this could be a solid employee in the security team. You’ll still have to conduct parts of the interview process, and see if they’re really up for the new style of work, but you’re starting from a great spot!

Security is in high demand but you can build and grow great teams

Hiring great security team members may seem challenging. And rightfully so, because it is. But if you reflect on your hiring process, criteria, and where you’re looking for candidates, you’ll be able to increase your chances of success. But just remember, hiring a great security individual is just the first step – you also have to set them up for success and grow their skills and career. But that’s a topic for another day.

Michael
Want to chat? Find me @_mwc