Hiring for application security positions is often seen as almost impossible. With many claims of talent shortages and so many open positions, finding the right candidate can be a daunting task. Here are 5 common mistakes to avoid and how to get past them.
Not understanding your current needs
If you are thinking about bringing on an additional resource focused on application security, you must understand what the duties will be. Unfortunately, due to the constant pressure to be secure, many companies focus on having the resources and then trying to determine what they will be expected to do. While this may be the case for the initial hire of a brand new application security program, it shouldn’t be the norm.
Understanding your needs requires work. It requires understanding what your immediate priorities are vs. the long term goals. While both of these may play into the candidates skill sets, focusing on the immediate may result in a quicker hire. There are many different tasks that an application security professional may perform. For example, working with static or dynamic analysis tools, or helping with threat modeling. They may also be creating automation around identifying security issues within the organization’s environment. You have to ask yourself, which of these are the current priority. Your organization may implement static analysis this year, but have dynamic analysis scheduled out a year. Maybe manual testing (red teaming) is a nice to have, but you know you won’t have time to build up that program for a few months.
Ignoring existing resources
Once you have a good understanding of what your needs are, it is time to look at existing resources. The common mistake is to just look at the security team. Instead, look at the application teams as well. What type of resources and skill sets exist within the organization. Business analysts are great at digging into understanding problems and gathering requirements. Developers know development and are typically great problem solvers. QA testers know how to test applications. Project managers know how to efficiently schedule tasks to get the project to its expected milestones.
All of theses resources, none of which are dedicated to security, provide a wealth of experience that can be applied to security. Let’s be honest, application security should be a part of each of these roles if we expect it to be successful.
Not sharing the workload
Just because it says application security doesn’t mean everything has to be handled or executed by the application security team. Many of the application security programs can be spread across multiple teams. For example, dynamic analysis could be integrated into the QA team’s responsibilities. The team already performs testing against the application, it makes sense to put dynamic testing within this context. Shifting the ownership to the correct location adds many benefits. First, it allows the application security team to focus on more specialized tasks. If using on-premise static analysis, this may include writing custom rulesets vs. just executing the tool and reformatting the results. It also helps embed security into the SDLC. The verification phase will now not only test for the common bugs, but also for the security bugs. In addition, the bugs will all be tracked using the same process, requiring less implementation effort.
There are many application security tasks that can be integrated into the existing SDLC processes. This will typically require engagement from the application security team to help guide the creation of these processes. That may be, however, what defines the role you are trying to fill.
Not defining the role
Once you have a good understanding of your needs and what still falls within the application security team’s responsibility, you can start to define the role you see. This process still relies heavily on understanding your needs, filtering out what is covered by current resources. Depending on the size of your organization and your application security team, the role may be very broad or very specific. It is this definition, however, that will drive the job requirements that get shared to human resources.
Overly broad job requirements
Getting candidates interested in the open position is critical to getting their attention. Being specific about what you are really looking for helps reduce noise and attract more relevant candidates. Often times job requirements are very broad and cover every possible task that may be performed. How often do those tasks actually get performed once someone is brought in? Some of them may never get executed.
Having too broad of requirements may cause great people to pass on by, thinking they don’t have all the skill sets needed. On the other hand, people may apply because they have one of those skill sets and it never gets used once they are hired.
Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.
James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at firstname.lastname@example.org or @jardinesoftware on twitter.