The Security Research Product Function
Product teams build, security research teams help navigate
Note from Zack
Hey all!
This is a “repost” of a blog I wrote two years ago. This is when I first started working at Datadog, and I was building a security research team from the ground up. It started with just me, and now its close to 50 people. Incredible Security Researchers, Detection Engineers, Software Engineers and Threat Hunters all make up this wonderful org.
I wanted to revisit this post and see if it held on after two years. It’s surprisingly close to what I imagined this org could be. So, if you are looking to join a Security Research team for a security product, or you are a founder and are considering building one, this post is for you.
The baddies put dinner on the table
Imagine this. You have an idea for a security startup. It helps catch the latest threats in the newest platforms, identifies vulnerabilities in places no one has ever looked, or informs customers of risky things before they make an impact. So, what value do you bring to an organization that buys your product? You may have a slick UI, a laundry list of integrations, and 1-click onboarding, but do you actually catch “the latest thing”? What does “the latest” thing mean? And when that latest threat or vulnerability becomes old news or table stakes, does your value proposition and marketing material crumble?
Lots of security product marketing firms talk about the latest thing happening. Then, they tell you their products can help solve and remediate that latest thing. Why do these companies figure these things out before you or your firms?
Well, one reason is that, unlike the product marketing firms for almost all other industries, without “the baddies”, we wouldn’t exist! The business of cybersecurity is built similarly to the military-industrial complex. An existential threat exists, and we must build defenses to combat it. So, the military-industrial complex relies on highly technical scientists, engineers, and intelligence professionals to learn about the myriad of threats, their historical implications, and their probable paths forward to adjust their defensive strategies. Security companies follow a similar model.
If the baddies were so predictable, we’d all be out of a job.
So, back to your startup: what can you do to a) keep apprised of the latest movements by the baddies and b) ensure you have all the tablestakes features of yesterday’s baddies covered?
Enter: The Security Research Organization
When I first started in security, I was fascinated by “the mission” of protecting others using my knowledge. Like many other hackers, deep technical problems fascinated me. I only wanted to learn how threat actors found their way into companies or how a vulnerability was exploited. At the time (early 2010s), firms wanted to hire hackers to dive deep into these technical problems, so it was a natural fit for my curiosity.
I didn’t know that firms were figuring out that they were positioning research teams not only to build products but to market and sell them. And, cleverly enough, they were adjusting their go-to-market strategies because they wanted to avoid the snake oil sales tactics. Think of the prototypical arms dealer in a movie or a used car salesperson in a cartoon. You just felt like something was unethical when you bought a product.
I joined two startups as the first security researcher. As I was hacking away and “finding the baddies, " I realized that showing what we did inside and outside the product mattered just as much as finding the thing itself. This was when I started to love product firms' business and marketing aspects as much as the hacking side. It was a multi-faceted role, akin to a Product Manager function.
One way to describe product management functions is that you are ".. the CEO of a product line." It would help if you had enough expertise to define and drive technical requirements to engineers, empathy to create and design a product that represents a pleasant user journey for your target personas, and a knack for positioning your products to showcase value and capture a total addressable market.
Security research teams are similar, but unlike "the CEO" of a product line, you can think of them as "the CTO" of your product lines.
Engineering: The business needs security research to influence the engineering teams to accurately measure and "catch" what we want to catch and to scale and automate our expertise. They want us to "move" our research methods into features.
Design: Security research helps translate complex technical topics into intuitive user journeys. Many security researchers came from firms that bought security products, so they are acutely aware of the pain points of bad user journeys.
Marketing: While studying for my MBA, I've read 100s of business case studies. In many of them, marketing teams ARE the experts of a product line. This may be true in manufacturing or consumer goods, but it's not the case in security. Nuance, staying up to date on the threat landscape, and history all matter in a marketing campaign. Security researchers can bridge that gap and be subject matter experts to "gut check" marketing material.
Security product startups recognize the value of this function. I've gotten several emails and LinkedIn messages from folks who want to chat about early-stage researcher positions, compare notes on showcasing the importance of this function (think metrics), and get advice on how to break into the field as a product researcher.
But, this function is more than just a CTO. It's your eyes and ears on the threat and vulnerability landscape. And they have to be as agile as the baddies themselves.
Let them cook: security research drives feature sets
I've had several long discussions with research leaders throughout the years. Although approaches to the discipline may differ depending on the product market fit, the business, and the threat landscape they are operating in, they are all navigators. The analogy here is a ship is a firm, the Captain is the CEO, and the product researcher lets them know what's out there. I've found it easiest to explain to others using The Kano Model. But let me add a security research product function spin to it.
The Kano Model is an interesting concept in product development. It buckets product features into three categories: the wow features (green), the satisfied features (blue), and the must-have features (red). The advantage of a security research function is that it can help accelerate the orange arrow by quickly orienting to the landscape of the attacker and driving your product to scale with it. Here's an example of a threat detection product:
The Musts: A research team helps build your core ruleset, and maps those core rules to MITRE ATT&CK. You can showcase coverage of ATT&CK to your customers, and your research team can drive that coverage.
The Satisfied: In-product notifications of new rules and frequent touchpoints keep customers satisfied. They know a product function in your firm that constantly curates rules and adds, updates, or deprecates rules without customer interaction. They also leverage news articles, the latest research, and networking to implement rulesets that may not be the first in the industry. Still, you can quickly adapt and add coverage when you learn about it.
The Wows: The research team finds a new threat actor group or vulnerability that no other firm has found. They add new rules and help protect customers of your product before all the others. This is short-lived, as others follow suit, but being the first to be protected is a huge advantage when discussing product wins.
The baddies also operate on the Kano Model. Phishing, a well-understood security attack, plagues security teams and end users today. The table stakes phishing attack should contain a look-alike page to the brand they are targeting. If the attackers host the site on reverse proxies to avoid being caught, that may be a more "satisfied" feature. Circumventing security controls in email inboxes by sending QR codes instead of links is a "wow" feature. So, we must drive the "wow" QR code down to "satisfied" and build products to compensate. The same thing can be said about reverse proxy hosting: we should expect table stakes detection of this sooner rather than later.
The cost matters a lot here, too. Having your research team spend less time on any Must, Satisfy, or Wow feature can be beneficial. In our threat detection example, spending all of your time on the "Wow" features leaves customers dissatisfied with basic coverage needs. Conversely, focusing only on table stakes coverage means you must be current on the latest and most significant threats and vulnerabilities. It will only provide coverage when they are well understood.
So, let your research team cook, but make sure they can do it in a structured way that helps your product, not hinder it!
In Conclusion
There's a LOT more to cover in this topic, but I wanted to give you a brief introduction to the value of a product security research team. It's a model I've seen grow immensely in the last 5-6 years. If you go to LinkedIn and type "security research director/vp/manager", you'll see the title mostly in product organizations. You'll probably recognize many of these brands, and the hope is that you can realize them BECAUSE a research team has helped put out great content and features along that firm's life.
Detection Engineering is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
I’ve built early versions of this at a couple of orgs, and this is spot on. In the earliest stages of security companies, it’s usually a small, cross-functional, user-focused team working closely with product, engineering, marketing — and sometimes even sales.
These teams spend a lot of time prototyping and acting as an in-house power user, bending the product to new use cases and clarifying, simplifying, and improving along the way.
Great post.