Hiring #

Hire for Curiosity #

Expand your candidate list from experienced researchers to experienced engineers that have strong curiosity. Software engineers often have a background that the most experienced researchers do not; how are applications deployed at scale and how systems communicate.

These engineers know that critical credentials are stored in terraform state files and nuances, like instances in your private subnet may be able to communicate externally with a c2 over IPv6 without a NAT gateway. Exposing software engineers to experienced researchers enables team discoveries that have wider coverage of allure and day in the life practicality. Joining forces is the way.

Hire for Locale #

Some threats are obvious, blatant, and in those instances we can classify and move on. But you cannot apply a blanket of cultural norms to a customer base that crosses cultural boundaries. Data collection and monetization practices vary across cultural demarcation points. Your best bet at understanding these impacts and backgrounds is to hire from the locale. Specifically, if you are a US company analyzing applications or threat actors from LATAM and Asia, you need to have researchers from that region. Colloquialisms and slang simply do not translate via automated tools. Further, what is considered acceptable for data collection and monetization can vary wildly by region. It is imperative to understand the intent and the outcome before you classify. Otherwise, you risk false positives in your Serviceable Obtainable Market(SOM).

Outputs #

Researchers need and deserve a technical outlet. This can be positively influenced with

• public facing technical blog
• internal technical blog
• regular internal documentation on threat actors and malware

Product, research leads, and product marketing(PMM) can create a pipeline of technical and product relevant posts based on your internal documentation. Credit your researchers in public posts. Your sales engineering(SE) team will leverage internal technical blogs on their own. Promote SE self-service and prevent premature disclosure by clearly marking internal blogs with traffic light protocol(TLP). Incorporate TLP and the blogs into the SE onboarding process.

Creating a PMM gateway for all outputs is the worst outcome. I’ve brought this up at several organizations and heard several reasons why companies don’t include their researchers as contributors or allow direct outputs. The worst reason to date being they don’t want their researchers poached. The second worst was thinking that researchers couldn’t do the writing.

Researchers writing will help you win over the customer personas and roles needed to land a new customer.

Personas #

Economic Buyer: The person holding the purse strings. This person is the Wolf Blitzer problem. If Wolf Blitzer is talking about it, you need a market ready answer. PMM is a good resource for this. Everyone other persona and role is whispering in the ear of the economic buyer.

Technical expert / detractor: They are looking for technical outputs and solutions that solve day in the life issues for them. They may already have a solution in mind, which may not be you. This requires strong research led outputs and practical product solutions. PMM is unlikely to solve this. Research content that shows expertise and references product capabilities that solve day in the life issues is the key.

Champion: This is often a relationship managed directly by sales or sales engineering. Your research team is your hidden weapon. Feeding technical details via your internal blog to the SE team powers competitive knowledge as well as deeply technical conversations.

Leveling #

Diversity of experience presents a leveling option that allows for different verticals of expertise. When you create your leveling matrix, you can have the same levels as engineering. Senior Engineer, Staff, Principal, etc. Within those levels, you have to account for the verticals of expertise. Comparing your kernel hacker directly to your Kubernetes expert may not yield results that retain people, allow them to be fulfilled in their growth, and for you to help them plot a path to what they want to achieve.

Consider using the Four Stages of Competence throughout your leveling. This helps measure levels of competence within the vertical of expertises that they are achieving versus a specific comparisons.

Chart a course #

Iteration based retrospectives are critical for security research teams to grow. You have to cover

• What went well
• What could have gone better
• What you want to try differently

Have your team contribute their feedback ahead of the retrospective. This should be in written form via a shared medium like Confluence. Have your team rotate through roles in the retrospective for timekeeper and moderator. Set timelines for what they want to try differently, e.g, six weeks, and let them grow. Your role is to ensure they focus on processes and ideas and not people. A strong program manager can be a pivotal role in success for this process.

Summary #

Experienced researchers are critical for your team’s success. Hiring for diversity of experience and locale will improve your odds of success. Expansion of team and SOM needs software engineers and regional knowledge. Provide your team with the means to communicate and support with guardrails in the background. Enable growth and paths for success by measuring competence within verticals of expertise.

There is no blueprint for every team. Go forth, adapt, build, and grow.

Appendix #

Many of the items in this post were sourced or influenced from research team retrospectives.

Images created using midjourney.com

(c) Michael Bentley 2022

Contents may not be republished without written consent.