BSidesSF 2026 - How to sell your soul, err, your security program (Jenn Gile)

Hope everyone is ready for our next uh presenter, Jen Gel. Please give her a round of applause. And uh well, I hope as you can see by the title of the talk, by the end, we'll all know how to get hell yes for the security program. So, we'll find out soon enough. Please, let's get started. Thank you. Uh yeah, my name is Jen Guile. We'll talk a little bit more about me in a second. I'm gonna like block out the lights and can I get a show of hands? How many people here work in a security role? Okay, how many people have bought software? Okay, keep your hands up if you've bought software. You can look around at each other.

If you trust sales and marketing, keep your hand up. I see you, Stan. >> I have to. >> You have to. Okay. So, uh, you can put your hand down. I won't see you for the rest of the talk. So, we're here to talk about how you can use some very specific marketing skills to get your internal stakeholders or even, you know, external to kind of move from the uh f no to hell yes. Um, it's not about getting people to care about what you care about. It's figuring out how to talk about what they care about. So, my career has predominantly been about getting people to do things that they don't want to do.

Uh, who wants to be friends with me? Kidding. Um, so right now I'm one of the co-founders of open sourcemalware.com. It's a threat intelligence database for exactly what it sounds like, malicious open source. Uh I've been around in tech and in uh the federal government for the better part of 20 years. Pretty much every role that I've had has been about again getting people to do something that inherently maybe they don't want to do. And there's something special about doing that in tech, doing that for a vendor that sells to security or sells to engineering is you have to figure out how to communicate your message, build trust, build credibility without coming off like a marketer. And the reason for

that is kind of as many of you probably can, you know, say from experience or uh from things that you've heard in general in tech, sales and marketing aren't trusted. And there's good reasons for that. But rewind a couple of minutes. You looked around. You saw the number of people who had their hands up who said that they bought software. What does that tell you? That tells you at some point somebody said something in a way that got to you and got to the things that you value and the things that you worry about. And in all probability, they were using some skills from a discipline called product marketing. And so that's what we're going to be talking about

today is a set of skills that you can borrow from product marketing so that you can get, you know, engineering, uh, finance, procurement, whoever it is that's kind of throwing up blockers to start being a little bit more friendly. So let's think for a second. Uh, we use Face ID because, not because it's good security for the most part, because it's convenient. So if you think about largecale campaigns, this is an example of uh what would be called a BTOC campaign, a consumer campaign, often those campaigns rely on uh figuring out the pain that somebody's experiencing and getting rid of that pain. I don't want to manually put in my passcode. I don't want to have to think

about it. Face ID, I just look at it and move on. So, we're going to be talking about how you can reframe your security program so that rather than trying to get them to care about security, which spoiler, you can't. Uh, you can figure out what it is they care about and kind of couch your security program in that uh terminology. So, why do we need to do that? Well, security has what we would call a messaging problem. the thing that uh your quote unquote customers, your internal stakeholders care about. They care about developer productivity, uptime, release velocity, revenue, reducing cost, compliance maybe, uh, but they probably don't inherently care about the things that you're gold on as

security program owners, whether that's MTR, whether that's total new vulnerabilities, vulnerabilities over time, whatever those things are, the things that your KPIs in all probability are centered around is not something they care about. And so when you have this kind of a dissonance in tech, you know, if I was trying to sell a product to somebody who didn't care about any of the words that I was using, I would be pretty unsuccessful. Uh, how many of you have walked into a room as a security program owner and been unsuccessful in getting people to do what you wanted? Yeah, I mean, I can see you through the glare. I know you're out there. Uh, we're going to get past that. So product

marketing uh is a previous part of my life and it's got a skill set that is incredibly valuable for communication. You know, if you're in a technical role, you probably got to where you are because you were really good at that technical role. The next level up is being able to explain uh your needs, your goals, your outcomes to somebody who's not in that area. So product marketing is all about understanding customer needs, then aligning your product's positioning and messaging so that it clearly communicates value to a target audience. Now, almost 100% of the time, the person who's doing that work, who's figuring out how to communicate that value, they've never sat in your seat. They've never done your job. So

how do they do it? There's a set of skills that product marketers learn and we're going to be talking about a couple of them today. So the ones that we're going to focus on is about what we would call understanding the market. So if you're thinking internal stakeholders, that's understanding what is your uh market look like internally. Who are you selling your security program to? And then we're also going to be talking about based on that market, how do you create compelling messaging? Um, there's lots of other skills that product marketers use. Um, if you end up hooked on this if you're really interested in it. Um, connect with me on LinkedIn. I'll throw up a QR code that I swear has

no malware in it. Uh, and um, I'll send you the deck. I'll send you resources. And it's fine if you take pictures. So, I'm going to take you for the next oh, I guess 25 minutes or so on a journey to communicating value. The first thing that we're going to do is we're going to identify your buying committee. Why does that matter? Because your message, the success of your message depends on who you're talking to. The second thing you're going to be doing is researching that buying committee. We're going to talk through that. Once you know a little bit about them, you're going to start developing what's called a persona. I'm sure a lot of you have heard this term before.

There's lots of different ways to talk about it. I'll share the way I think about it. You'll be writing messaging and then you're going to be validating. So we're going to go through all five of these steps. Some will be short, some will be long. So step one, identifying your buying committee. I'm going to use throughout this presentation the example of an application security team or leader or engineer who needs to do this work. sub in sec ops, sub in uh incident response, sub in threat hunting, you know, whatever your team is, you're still going to go through this basic thought process. So, typically when you're selling a product, whether it's literally selling a product or

communicating internally, you're going to have three groups of people that you need to persuade. You're going to have your technical champions. Those are going to be the people who are most likely to actually understand the technology of what you're doing. They're probably going to be using your product or engaging directly with your product. You're going to have your budget holders. Um, that sounds exactly like what it sounds like or it is what it sounds like. And then you're going to have your influencers. Those people who uh maybe you don't need them to be actively excited about what you're doing, but they can kill your deal. Normally in this talk, I would pause here and I would have people shout

things out. I can't see you, so I can't pressure you with eye contact into doing it. So, we're gonna try this anyway. So, if I'm uh an application security person, who might my technical champions be within a company? Just shout it out. Engineering manager. Maybe let's go deeper. Developers, >> architects. So the people like if you're I don't know managing SCA and SAS and you're going to have all those findings those are the people who are going to be like triaging findings dealing with findings how about your budget holder who may be your budget holder here >> maybe the CISO who else >> CTO >> CIO probably a sea level however there's usually someone below the sea level

who's going to be signing off on things so it could be uh a head of infosc also it could be the head of product uh security depends on your organization. Okay. Who do you think your influencers might be? >> Malware practitioners. Okay. Let's think within a company. I've got the people who are going to use my product. I've got the people who are going to approve the budget. Who can kill whether or not my program runs? >> Also engineering managers. >> Department managers. Operations. think more operationally. Who else can kill it? >> Legal, trust, procurement. Okay, I think I think we got them all. Did I miss yourself? So, this is going to vary again team to

team, but generally you're going to have these three types of people involved when you're trying to sell your program. And if you can get them on your side, which is what all of this is going to be about, you're going to be way more successful. Once you've figured out who they are, hopefully this white isn't too blinding. Oh, it's not bad in here. Um, you're going to research. You're going to gather information. Even if you've sat in the chair of somebody who you're um trying to sell to, uh, don't be biased about your own experience. Don't make assumptions. You're going to start with research. This is going to look qualitative and quantitative. You know, qualitative is, you know, hopes, dreams,

what keeps you up at night, that kind of thing. Uh quantitative, you're going to look at your own data. If you're looking, you know, to really get engineering on your side, then you're going to look at engineering data. You're going to be looking for trends and patterns. Um, most people in tech kind of tend to bias toward that quantitative stuff, right? We feel really good about I pulled these numbers and this is what the numbers say. We are not numbers. So think about people. You want to do interviews. So we're going to focus on these interviews and getting to know the humans because a lot of this is psychology. Now for a fair number of my slides, I am

breaking the cardinal rule of how much text to put on a screen. What's on here, don't worry about it. It's okay if you can't read it. I'll send it to you later. The point is that this is all about preparation. Generally, when you're going to do a stakeholder interview, you kind of want to have three categories of questions. You want to ask them about their role. So, that can be, you know, tell me what you do. Even if you think you know what they do, tell me what you do. Uh, one of the things that I love asking is why does your role exist? Why does your program get funded? Why why do you have a job at

this company? Uh, what are your goals? So, that's the second category. what are you trying to achieve this year? Uh what what are your you know concerns in 2026? And then pain. Here's where maybe you start to ask for pain specific to your program. I would encourage you to keep it a little bit generic at first. And you are definitely going to get uh a mix of people who um might not be super positive about your program. They may have some very tactical negative things to say to you. And your job, and it's going to be really hard at this stage, is to say, "Okay, thank you for the feedback. You're not going to commit to

doing anything. You're not going to uh, you know, try a solution and troubleshoot. This is your research period." Now, some tips that I would say will make this go better for you is um when possible, interview a set of people, not a single person. Um, unless you work at a really small company and it really is just one person who's going to be who you need to convince, try to get that bigger sample size. Um, if possible, record the interviews under the, you know, cone of I will not share this with anybody. So hopefully you've built up enough credibility that they'll let you record it and um, taking some notes. But what can be really useful,

I'll talk about the role of AI later, is if you can record all of these interviews, that's going to make your life a lot easier when you're trying to synthesize that information and look for trends. Um, then kind of the obvious things, you know, being empathetic, uh, working on your active listening skills. This will all make those stakeholder interviews go a lot smoother. Okay, now we're to the part where a lot of people probably have heard about personas. Maybe you've worked somewhere that has one of those posters on the wall with somebody who's maybe like standing like this and her name is Jane and her hopes and dreams. This is not what we're talking about here. Uh I'm

not a fan of those style of personas. We don't need to talk about their dog's name and, you know, what they do on their weekends. Uh, in my mind, a persona is a little bit more workbound. People have different opinions. If there's product marketers in the room who feel differently, we can argue later over drinks. Um, I like to frame personas around kind of five areas, but it's really it's a researchbased um, description of a group of people, not a specific person. So, you're going to be uh, describing their motivators. What are they trying to achieve at work, perhaps a little bit in their career? um attitudes, you know, how do they feel about your function? If we think back a

step to all of those buying committee people, some people are going to be like on the warmer end, you know, maybe GRC is kind of friendly to you, and some people are going to be on the spicy end, like maybe the developers are sick of you because you've got some noisy tooling. Um, you're going to describe their responsibilities. Um, really important. Understand what their metrics are. Understand how do they get their bonus? um how do they know if uh they're succeeding, if their boss is happy with them? And then again, what are their pain points? Not just their pain points related to you and security, but like you know, thinking about developers, a pain point for a developer is I didn't

ship a thing. Not so much, you know, the core of uh I didn't ship a thing because security was on my back. So be broad there. I'm going to walk you through a sample persona that I created. Um, it is for an engineering leader. Um, I'll probably reiterate another five times that this is a sample. Don't use it. Um, but kind of be thinking as you're thinking about who you're working with and who you would run a want to write a persona about, like how you might approach this. So, the first thing I like to do with a persona is have a summary about the person. Again, I'm breaking the rules here. There's a lot

of text on this slide. The point of the massive amount of text is more to show you that this truly is a writing exercise. If I came in here and showed you a bunch of bullets, you might get the wrong idea that you can just write some bullets and then magically understand people. You're going to write more of a narrative. Uh in this case, we're saying that the engineering leader is an influencer. Um they're a key stakeholder because uh their teams are primary end users of the programs. We need their buyin. Uh they can advocate for tools. They can advocate for budget, but they can also kill stuff because uh they don't like tools that create

friction or slow down releases. Um I like to include a little like uh how do we get them on our side blurb. And so with this person, an example is like be empathetic about their frustrations for their team's experience. You know, this engineering leader is responsible for humans. That's got an emotional component to it. Um and then you know, showing how your programs can help them be successful. I do tend to include titles uh more as an example but uh a persona is not the same as a title. So this is sort of a generic engineering leader. The second section, so I talked about attitudes in there. I've got a little bit of a narrative here on their attitude toward

application security. You want this to be unique to your organization. you know, if you have a history of your engineering team really um disliking security and having like a lot of negativity there, you're going to write that up. So, in this example, they've got a rather negative attitude toward application security because of various things that have happened in the past. We have their responsibilities listed, their key metrics. Um, you know, you're probably going to see things like Dora metrics if you're looking at engineering, perhaps things about uptime and performance. Uh, and very likely if it's a leadership type of person, they're going to have some kind of people oriented metric. You know, are they thinking about retention perhaps?

Um, and then their pain points. How are we doing on time? All good. Okay. I can't do math when it starts at 2:25, so I'm just going to keep going. All right. Step four. You have uh let's see here. We identified our buying committee. We did some initial research. We wrote persona about the people who are important to us. Now, we're going to write a messaging guide. Now, a messaging guide, this is almost like um a script to some degree. You're not going to like go into your meeting with your engineering reader and you know, read it to them, but you can use it to uh write emails, to write proposals, to think about your next uh pitch to them.

So, your messaging guide is a framework for communication that's going to be persuasive to a specific person. Um, the messaging guide is going to have a problem statement. These are typically going to be customized to a specific um, product or program or single thing, not like your entire security program. You want it to be a little bit narrow. So, what does your product solve? Because your security program is a product. Um, what kind of impact does it have on this persona? What value does it have for them? Both technical and business value. What kind of evidence can you show them that um supports what you're going to state? And then what do you want them to

do? So again, we'll walk through this your problem statement. Uh in this case, I'm giving an example of I want to implement a new SCA tool. Well, uh even when SCA tools are terrible, um the known bad can almost be preferable to a unknown future, right? So in this case um you know we're saying our problem statement is the SCA tool doesn't align with our software development practices. It's disruptive. It's inaccurate. We move on to impact. Why does it matter that it's disruptive and uh inaccurate? Well, it matters because it delays releases. It causes developer friction. It increases our MTR. It slows innovation. Now business value and technical value. I very intentionally split these out.

And the reason for that, especially in tech, is we have a tendency to go for features first, right? We talk about the widgets, we talk about the buttons you can push. Let's talk about the business value first. So, for example, we think that this new tool is really going to help um reduce the amount of time that developers are spending on security issues because it's going to give them more confidence in the findings because it's going to be more intelligent findings. It's going to help them catch risk early. So, those are uh business drivers. If you're talking to a senior leader, those are the things that they're going to care about. But then you're probably going to have to talk

about technical value at some point with these personas. You know, you have a technical program. This is where your features go. Okay, this particular tool, we like it because it has program analysis and reachability and fix recommendations and whatever like the bells and whistles, the reasons you want to buy it. the evidence. Now, this could be evidence that's coming from, you know, in this case, the SCA tool. Maybe uh we did some testing and here's what we found in our limited testing. Maybe we want to do some testing. So, we don't have personalized evidence yet, but we kind of have like, you know, here's what we're being promised. Here's what I learned at BIDES. This is what I think

could happen. And then most importantly, what do you want them to do? You may hear a call to action or a CTA used in like marketing speak, but think about it in terms of um what you want the action to be. I actually think I heard both of our keynote speakers this weekend talking about their calls to action for us, right? You know, getting involved in the community, um getting involved in how uh the country consumes AI. Well, you want to think about what your calls to action are for your internal stakeholders. So perhaps your CTA is, I want you to support a POV. You know, if I'm going to run a POV of a new tool,

I'm going to need engineering on board. Uh perhaps another call to action would be, I want you to advocate on my behalf, like please be a champion for me. Um it could be that you want them to support the transition to a new tool. Now, you've done a lot of writing and thinking, and maybe you feel good about what you have so far. Maybe you don't, but you've got to validate it. You know, think about this like a technical problem before you roll something out at scale and start using it. Work on the validation. There's a few different ways that you can do this. They're all kind of um fairly like what you would expect.

You're going to be conducting interviews again. Like you can go back to that core group that you spoke to initially and say, "Hey, you know, here's kind of what I wrote up." Like don't keep it secret that you're doing this. That's weird. Um, here's what I wrote up. Like, am I understanding you correctly? You know, there's something about being able to describe to somebody what their problems and their pain points are that builds credibility. So, you can start to get that reinforced. You can get feedback from them. Um if you have some trusted adviserss you know in the company that like you trust them not to you know spray something to the executives or to

the wrong people you know share your your rough drafts with them and then don't be afraid to POV this next time that you're going to do a small project you know try it out just with that small project before rolling it out. So some of the questions that I get at this stage are usually around um do I keep this secret? Do I publish these? How do I use these? Ultimately that kind of comes down to your program, your culture. You know, how do you um communicate? You know, you may keep it just within your team. Uh maybe if you're a team of one, this is just, you know, your very own internal cheat sheet. I probably wouldn't publish this

on your company SharePoint. Seeing stuff like this out of context can be a little bit weird for people. And then the question that I always get is, can an AI do this for me? Can't it do it for me? And the answer is no. Um, I'm curious. I'm going to take a pause here. Uh, we've been talking this weekend about how AI can accelerate us. Why do you think I'm saying AI can't do this for you?

Yeah. You gonna have that robot talk to those people? Everybody really likes those AI uh chat things that they get when they call customer service, right? Yeah, definitely do that. Um yeah, so talking to people is a peopleto people thing. Um and why else? Why can't you just uh take your recordings and feed it into your LLM of choice and say, "Okay, spit out a persona and a messaging guide." Yeah, body language. That's a really good one. I heard a couple things. What else? One at a time. I can't see you, so you're going to have to self-pol. Build trust. Yeah. What else? AI can't do empathy. Um, AI doesn't do nuance very well, right? Um, I think one

of the things that I've heard frequently is AI doesn't understand sarcasm. Yeah, that's great. Or, yeah, that's great. Not the same thing. Um, so no, AI can't do it for you. However, once you've gotten through these kind of steps, there's a few ways that I would recommend using AI. I personally use it when I do this type of work. Um, it's really great for synthesizing interviews. You know, if I asked a specific question about pain points and I asked the AI, you know, uh, tell me the trends that you're seeing for this particular question. You know, if you did a lot of interviews, it's really good for that kind of filtering. Um, it's good for, um, like challenging

your assumptions. If you don't have somebody you trust internally, you could say, "Hey, I wrote this up. Like, what might I be missing here?" Uh, but what I think it is amazing for, and what I again personally use it for is making skills. Um, once you have developed your personas, once you've developed your messaging guides, um, turn them into skills. In this case, it's Claude. And um if you create a couple of skills and say, you know, anytime I'm going to write an email to uh somebody with an engineering titer title, reference this skill or anytime I want to fill in the blank, reference this skill. So the um examples that I showed you, I did go

ahead and build a couple of cloud skills and then I gave it a prompt and I'm going to read the prompt because I think it's interesting. Uh I said I am trying to improve my communication with engineering leaders at my company. We have very different metrics and sometimes it seems like they don't complement each other. Can you make a matrix for me that explains each of my key metrics, maps them to a metric that engineering tracks and explains how they relate? Here are the apps metrics list of metrics. So, in the skills that it has, it has the um persona guide which explains the metrics and it has a messaging guide which explains how those

metrics apply. I've done this exercise with a couple of different LLMs over the span of at least 6 months or so multiple times and every time I get incredible results. So, like 100% do this. Um the screenshot that I have for you here, which you should experiment with this on your own, it shows a table and I know I've kind of hidden it. So it's got uh an appseac metric uh meanantime to remediation. It has a corresponding um couple of engineering metrics. It says the relationship between them and then it offers like a little bit of a narrative. So this is a way that you can start to think about um somebody else's point of view without having to have

actually run a program that relied on these metrics. So I think that this is a really tremendous way to make this work scalable for you so that you do this work once and then it starts to inform everything that you do. And I think we're really good on time so we can start to take some questions. What do we have? >> Yes, actually we're perfect. Well, before we start taking questions, maybe we can give a round of applause. >> Thank you. >> Me a second. Yes. If you also if you have now any questions that you want to ask, please go to uh besides sf.org/q&a. Um we have first question here. I'm the first security hire at a place where the

engineering managers hold negative views of security. What magic can I will to build trust and buy in? >> I don't have magic for you. Um I've seen this movie a bunch of times. Uh usually what it looks like is pitching in with their team, going in uh finding ways to remove problems from their plate. Do that for a couple months. you know, whether it's uh reducing a backlog, whether it's getting rid of something everybody hates, whether it's just like starting an office hours, uh start by doing things for them rather than asking them to do things for you. So there is magic. Go do things for them. >> Um I think we're still waiting for a

couple of questions. Uh you mentioned in the evidence some metrics that people can use by maybe collaborating with vendors. How would since we saw at the beginning that people don't trust sales from the vendors, how would you recommend to collaborate to get those metrics that actually matter internally? Yeah, I mean definitely as you're thinking about like if you haven't done a POV and personally collected metrics yourself, um if you're trying to uh get some metrics from a vendor, um I might start out with really understanding what metrics would be helpful and fundamentally understanding those metrics and then if you ask for them for a vendor like have them go a layer deeper and explain how they got there

and it's going to fall apart immediately if it's smoke and mirrors. if it's legit, they're going to be able to explain how they got there. And you may be like, okay, like if I look at it sideways, I agree with you or yes, I agree with you or no, I don't. But like have that kind of validating conversation. >> Um, have you noticed security stakeholders using AI like CHP to justify reducing security spending by claiming the risk is low? What are your thoughts? >> Uh, interesting. I have not actually um most where I've seen security leaders uh using AI advocating for AI is about um making do with the resources that they have. Uh I have a friend in the Seattle

area who works for Adobe and uh a really hard to solve problem for them was WF rules and there's no way they were going to be able to hire enough people to write all of the WAF rules that they needed. It's a very like diverse uh ecosystem of WS and so they've been using AI to essentially solve a problem that they could not adequately solve before. And so it's more like hey we're going to prove how valuable we are the security engineers that we have in the seat by showing you the cool new things that we can do with AI. I have not seen a lot of bad decisions but I'm not saying they're not happening.

>> Yeah. I think don't have question so far yet but I have a question. So how would since interviewing a lot of people can take a lot of time and especially the larger organization grows the more for example influencers that you might have uh what is the magic number at which you should stop interviewing everyone and everything. >> I would focus almost like concentric circles of who's the most important. So if uh your biggest point of friction is with engineering then just do your interviews there and don't spend a lot of time you know in procurement or things like that and then I generally like you know three to five interviews within the same kind of like focus area.

You don't need to interview every single engineering manager you know in your company if there's like 20 of them. At some point there's like diminishing returns and you won't get value out of it. And uh have you found interviews to be all agreement and then the personal support fails apart at any push back from others? How do you find actual truth during the interview and based on what people say? >> I think the question is saying what if people lie to you? >> I think people I think what that means is people to tend to be nicer and agree with you more. That's how you validate. >> Yeah. >> Yeah. That's why you test. Um you're

going to find out pretty quickly if your assumptions are false if you start to put it into practice and it fails. >> And what are some of the biggest mistakes that engineers make when communicating biggest business value >> using their own metrics? Um, and so when I think about, you know, security people who I've worked with who are trying to um, get decisions made in their organizations, if they're really fixated on using their own metrics or have a mentality of I have to get people to care about security, that's generally going to fail. >> Okay, I think uh, we're done with the with the questions. I think it was great presentation. something also I've mentioned yesterday during the talk that

we need more presentations on marketing to security internally and um well I hope your opinion from the beginning when everyone raised the hands of uh the sales whether or not they trust sales and marketing that now you are going to be all product marketers and uh sell the program so please please give another round of applause for Jen thank you