0

I am the team lead on the IT Security team where I work. Recently we were interviewing for an security engine role. One of the traditional security / SOC engineer roles in all the places I worked is leading security code scanning and vulnerability remediation.

When I asked candidate what experience they have with static and or dynamic code scanning tools (SAST / DAST), they responded they used tools such as BurpSuite and SonarQube among others but the security code scanning process is more owned by development , not the cybersecurity. These candidates come from well known companies with mature histories so I expected much more more security ownership in the code scanning / vulnerability management process.

As this candidate has significant experience in working with our suite of security tools such as BurpSuite, MetaSpoit etc, I dont want to pass over them simply due to them used to a different process. However, the willingness own the code scanning vulnerability management processes is a critical requirement of the role.

  • Is ownership of secure requirements during development by teams outside of cybersecurity a common occurrence in big, mature companies?

  • How should I evaluate candidates with significant experience in using the technical tools of our team but may not have experience owning processes or are used to working using a significantly different process owned by another team?

  • 5
    Can you not just talk to the candidate that your company's philosophy of who has more of a security ownership is different than what he may be used to, what that entails, and then ask him if that is something he is fine with? I think it would help to avoid a mismatch if you both knew about this ahead of time. – さりげない告白 Aug 11 at 5:06
  • 1
    Companies are all different, the more mature the more different sometimes in security roles. This is because some have built before the existing security measures and standard best practices were even invented. Others may have started with a particular individual doing it his way and evolved from that. Realistically you get someone you think can handle it and re-train them how you want. Same thing with Engineering sometimes. I need to retrain most engineers even with a decades experience. – Kilisi Aug 11 at 6:23
  • 6
    In my opinion he has the better process. If you centralize things like security or quality assurance, everybody else feels less responsible. That doesn't mean you don't need a central team, but the tasks are slightly different. – Chris Aug 11 at 6:48
  • good question! I like that you are challenging your own worldview and asking what the world is like for other people. not enough people do that – Jason FB Aug 15 at 1:58
  • You are doing things this way in your company. His old company did things in a different way. What makes you think that he is not willing to start doing things your way? – gnasher729 Aug 20 at 8:29
9

more owned by development, not the cybersecurity

That's absolutely reasonable. Since development is the department that can actually do something about it, it's pretty pointless to let them run in one direction and later tell them they need to redo their work because automated scanning found a vulnerability. I don't let someone drive straight into the sunset and call them half an hour later like "hey buddy, my navigation device says you would have needed to turn left here". The tool should be used by the people that can change the outcome and it should be used as soon as possible, not after the fact.

It should be normal to have development run those scans while developing and security to run them again (or request the reports) just to make sure development did their jobs or to find vulnerabilities in parts of the system not in the hands of in-house development.

As far as big and mature goes, that's hard to guess. I have seen big, I have seen old, but mature is really something completely disconnected from those two. I think you are way ahead on the maturity curve by just having a cyber security department or team in the first place.

How should I evaluate candidates with significant experience in using the technical tools of our team but may not have experience owning processes or are used to working using a significantly different process owned by another team?

I have the same question with project planning processes. For example Scrum. It's always good to have someone with experience, but in the end, it's not their choice. if their old company did not do it, it's not in their domain to change it.

So what I do is I will evaluate based on what they know about it theoretically and if they are open to doing it. It's not their fault they did not do it before, as long as they are interested and willing. I will draw the line at "never heard before" though. Even if the former company had different guidelines and departmental organization, if someone hasn't heard about the thing, that means they did not properly educate themselves through books or conferences or usergroups or whatever else one can do to keep up to date.

| improve this answer | |
3

I'm failing to see the problem here.

When I asked candidate what experience they have with static and or dynamic code scanning tools (SAST / DAST), they responded they used tools such as BurpSuite and SonarQube among others but the security code scanning process is more owned by development , not the cybersecurity.

... is NOT inconsistent with:

Willingness own the code scanning vulnerability management processes is a critical requirement of the role.

One is simply saying, "I know about this topic, though the emphasis in my past jobs wasn't the same" and not "I refuse to take responsibility for this."

It's the exact same thing as McDonalds interviewing someone for a drivethru worker that said, "Yeah, I'm comfortable taking the orders as well as manning the window. Though where I worked last, they were handled by two different people."

You're not going to say, "Dude, that applicant refused to work drivethru!" Because it's not true - they're simply saying the last place they worked had a different process, not that they're refusing to do something!

Same thing with your applicant. Did they actually say, "I refuse to handle code scanning!" Because, otherwise, you're making a mountain out of a (nonexistent) molehill.

| improve this answer | |
2

Yes, ownership of tasks such as vulnerability scanning and vulnerability remediation is increasingly owned outside of a centralized security org in many organizations.

This is almost universally recognized as a benefit - the centralized security team model has been failing for 30 years to product secure systems and applications. Therefore “shifting left” these functions into the teams that actually create the software and have the ability to actually fix vulnerabilities is an accelerator to actually achieving the goals of security.

Here you have a opportunity by hiring new blood to actually learn newer, more effective approaches from the industry. There’s still a role for dedicated cybersecurity professionals in this new way of working (which is why you are talking to a bunch of people with those skills, that just aren’t obsessed with old command and control style organization). You could use these newer-skilled folks as you pivot your focus to education, empowerment, and centralized reporting instead of insisting on “owning” everything. Because when you say “owning” you don’t really mean it - security groups still own the approach even if performing these tasks is decentralized into the teams (that is the process the organization uses in this case) - you mean micromanaging it. I’d strongly encourage looking into the DevSecOps track at RSA or other similar venues to learn about newer approaches (maybe like hiring someone that knows them, even).

As for “how to interview someone who’s used a different approach” - well, interview them on their skills, and also talk with them about your approach. I’ll be honest, it’ll probably cause a number of them to discontinue pursuing the job. I had a similar discussion with a tech department at a large home improvement retailer about leading a Web application performance team - I had done this previously by empowering development teams with tools and techniques and leading the setting of department-wide goals. I had a conversation with some upper managers about how “no we expect YOU and your team to own it and do it, not that hippie stuff”, and I decided not to pursue the opportunity because they were basically artificially constraining how successful it could ever be, and life in tech is too short for that noise.

| improve this answer | |
1

How should I evaluate candidates with significant experience in using the technical tools of our team but may not have experience owning processes or are used to working using a significantly different process owned by another team?

Evaluate them based on their skills, experience, and merits... not by the processes their current/former employer used or is using. You're bringing them into your company and your processes.

| improve this answer | |
0

For me personally, as a Ruby on Rails developer, I generally think of "cybersecurity" as what is traditionally referred to as perimeter security and network security, or in a cloud context could be thought of as cluster security or cloud security.

Being an application developer, I tend to agree with your candidate that in the app dev realm, it is the app developers who are responsible for write our own secure code. I tend think it is best for the developer to write their own secure code, and best for the application. When it is "someone else's job" to make my app secure, I'm bound to pay less attention to it.

it seems to me that this answer is perfectly valid from an application developer, but perhaps you want a security specialist, like perimeter and network security. Hence, the linguistic distinction.

| improve this answer | |
-1

Here's an option that is frown upon by some, and accepted by others: Send them a take home exercise. Provide a temporary license for the tools, describe a workflow, along with code to review and tasks to do.

The great candidates will pick up the flow you want and leverage their knowledge of the tool. The bad ones will submit the bare minimum or just give up.

Depending on your company culture and legality of it, you may elect to pay the candidates a token amount, say 4h or 8h pay. Still cheap compared to your interviewers' time or a plane ticket to the in-person interview.

But it's much more work to setup and maintain. YMMV.

PS : A docker image, all setup with the tools and task is easy to install and will tell you the difference between those who can figure stuff out and those who can't.

| improve this answer | |
  • Dear downvoter: are you downvoting because you disagree with the practice or because there's something that could be improved in the answer ? – Jeffrey Aug 12 at 21:51
  • You are measuring how the candidate works in a startup phase. That person is supposed to be there for two years at least (my rule of thumb), so you want someone who is efficient from month 3 on; efficiency on day one is totally irrelevant. – gnasher729 Aug 20 at 8:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .