AppSec Qualifications

At Jemurai, we often find ourselves in situations where a company wants to build their own application security program but doesn’t really know how.  That’s a common and very understandable problem given the trends in the industry (increasing focus on app security) and the inherent complexity of doing application security well.  We take great pride teaching and coaching organizations such as these to build successful programs.  Inevitably there comes a point where they want to hire someone to “run AppSec.”  Often, we’ll be asked for feedback on resumes or about candidates.  This happens often enough that I wanted to take a minute and write down some of the things we’ve learned and how we approach situations such as these.

Our Point of View

We fundamentally believe that to succeed with application security, a team needs to have development & SDLC expertise, excellent communication skills and security knowledge.  Tools are a part of the package, but only a part we use to help save time so we can focus on the hard problems as a team of people.  The number of times we have seen “last mile” problems, where issues are known but can’t be fixed for organizational reasons is too many to dismiss.  Emphasize relationships, communication and the human element of making security fixes happen and the tools part will come along easily.  Starting with expert developers that can win the respect of the technical team while engaging in a non-invasive way is our goal.

Internal

Usually, one of the first questions I’ll ask in this situation is if there is anyone internal that would be a good fit.  Most medium to large development groups have a few developers that are proven but might be looking for their next thing.  Giving them a way to pivot into application security can be a great way to leverage their organizational knowledge, domain expertise and familiarity in the current process.  If they’ve been building things, they almost certainly understand the SDLC and main programming languages in use.  If they understand the domain, they can communicate with developers and business stakeholders.  Provided that they have the disposition to work with a variety of teams and communicate constructively, this is the kind of person that we can coach into being a core contributor for an AppSec team.

Gotchas

Not surprisingly, we have also made mistakes and seen things go sour while building a program.  The following are some things to watch out for:

• If we build around someone that is not experienced enough, developers will run circles around them.  This could be technical or process (eg. JIRA) knowledge.
• If we don’t emphasize both written and verbal communication, we may end up with a technically qualified candidate that can’t effectively build a program.
• Empathy is foundational to organizational change.  Weaving security into a development process can’t be done without meeting developers part way.

Questions

In order to assess candidates, we pulled together some interesting questions that reflect our point of view more concretely.  Of course it is imperfect, but we’re sharing it here because we think it is interesting.

Internal question:  Do we want the person to be able to get their hands dirty?  Our answer would generally be “yes”.

General questions:

• Any mention of OWASP?  SANS?
• Any experience with AppSec Tools?
  • Pick your names of popular tools in the industry.  As we said, tools are secondary but a lack of them can reflect
• Any mention of programming languages on their resume?
• Any product development experience?  Does it sound like they grew out of that?
• Does the candidate have recent experience working with developers?  Do they seem to enjoy that?
• Does the candidate know about any security standards?  ISOISO (International Organization for Standardization) is an independent, non-governmental international organization that develops and publishes standards for various industries and sectors, including cybersecurity., NISTNIST stands for the National Institute of Standards and Technology, which is a US government agency responsible for developing and publishing standards and guidelines related to information security and cybersecurity., Top 10, ASVS.
• SDLC Experience?
  • Agile / Scrum / JIRA?
  • Where can security fit into an SDLC?
    • Looking for an answer that suggests familiarity with SDLC and emphasizes aspects OTHER than at the end during waterfall testing.
• Can the candidate write code?
  • What is their language of choice?
  • IDE?
  • What have they built?
  • Any open source contributions?
• How would they do code review?
  • Looking for some strategy for digesting code and following logical paths, eg. data flow, authorization, input validation, etc.
  • What would they do with a finding?  How have they interacted with other teams in the past around issues?
    • Looking for a discussion/relationship based approach – not a cold handoff via a spreadsheet or tool.
• Can the candidate talk about architecture?
  • Is any of their experience relevant to web development?
  • Does the candidate know about CI/CD?  Cloud?  Mobile?