Trust Engineering: Building Security Leadership at Early-Stage Startups

So, hi everyone. Please give a round of applause for our next speaker, Mike Privet, who's going to teach you all about how to be the first security leader in the startups. Thank you. That's a much better applause than I thought I would get already. I'm doing pretty good. All right. So, hey everybody. I'm Mike Privet. I'm here today to talk to you about trust engineering and uh it's a framework for building security leadership at early stage startups. So, a bit about me for those who don't know who I am. Um, I'm Mike Privets. I've been a SISO. I've been a security leader. I've worked at a bunch of different companies large and small. Uh, some through entrepreneurship, some

through just direct placements uh through the years. And I've developed a somewhat of a specialty of being uh the first security hire for early to growth stage B2B SAS companies. Um, and that's like super niche and very specific. I didn't do that on purpose. it just sort of worked out that way and uh so as a result I've I've had to develop this like trust engineering framework for myself to to uh have success in the role but I'm not doing that currently right now I am the founder of return on security it's a research and market intelligence firm where I study the economics of the cyber security industry and I get to observe interesting patterns about how we work and and what

we do in the industry and to uh just get this out of the way. Uh, no, I'm not, uh, the Yeti from Run Zero, although we do look a lot alike. But here's Return on Security. Uh, for those who are interested, uh, this is a weekly newsletter. It's free and, uh, I've been doing it for about four years now. Um, so if you're interested in data and funding and acquisitions and IPOs and public earnings calls and the like, um, I capture it all and just share it out with some charts and graphs every week. But my real passion is uh memes. I I have to say uh posting is really where I shine. Uh and I've unlocked

recently doing this on LinkedIn. And the best is when people don't understand it. They don't realize that I'm joking. Uh so I really lean into that. But uh this has been more fun for me than probably most things. Um here's some more of my favorite favorite ones. You you never know what's going to go. uh interesting when you when you post these, but man, they're they're fun. All right, so here's a little bit of an agenda. I want to show you guys what we're going to talk about. We're going to talk about security at startups in general. Uh what's it like being the first security leader at a at a startup? It's not what you think. Um trust

engineering in you and and how you can uh work with it. um some practical implementation steps that uh that I've done uh through the years and that to help you along your way in the journey and then you know at some point we'll get to profit. It'll uh we'll we'll figure out how we get there but uh we'll this is the general flow of what we'll do today. All right. So startup uh security why do startups hire security leaders at all? You may ask. It's not because uh they want to be secure. I'll say that it's because they have external forces. They have some triggering function that says you should really hire somebody to to do this or you

should really take on this this uh function and uh do better. And it's almost always driven through key growth phases like the company's growing and and building a bigger customer base. Uh customer demands typically are what drives most of it. So they'll say, "Hey, tell me about your security program." And it's typically the founders or maybe one engineer who have to cobble together what that looks like um through various forms of documentation and through various um artifacts and customers really drive probably 90% of this effort. Like they they're the ones who are doing thirdparty risk management on you as a company as a as an early stage company u because you're not trusted, you're not

vetted. So they want to see that you have a lot of um diligence and care in this space. And then there's always competition. And so if uh from a from a sales perspective, if a company is maybe going against another company that has security in their pitch, that is often a a trigger to say, "Hey, we should probably do that, too." And uh or taking on just new markets. So any think about any of the heavily regulated spaces, healthcare, financial services, they all require a certain level of rigor and they all require certifications and they all require typically a named person in the seat to be accountable for this function. So these are the kind of

really the main reasons and then sometimes it'll be because of funding. Uh the team will have enough money to say we should really hire somebody to do this full-time so it's not you know 20 people's part-time job. But then you may ask well then how is securing startups different than a larger company or like a later stage company? And the answer is it's it's very different. Um it's not what you think. Um it is not enterprise security. Uh you do not have people resources. Uh you really don't even have that much time. Uh you just have a desire to get as secure as possible as quickly as possible uh within with a very small budget. So you have to be able to uh

move quickly. You have to you have to be able to influence others at the same time and uh not have a lot of direct control or say over some of the implementation practices. but this is how you're going to be able to operate like this. This is the the groundwork you have to come in. So knowing that so like knowing why customers or knowing why companies hire security leaders to begin with and knowing where you kind of are positioned at in the first place, you know what experience sets you up for success if you are this person who's been tapped for the job. There's a couple things that I think have always been successful and like

especially going through the companies I've worked with, talking to a lot of founding teams, what they're looking for are a few key things. So, they want to know that you've worked at a startup before. They want to know um that you understand what startup life is about. Like, it's not a clock in clockout. It's not a nineto-ive. Um it's typically very urgency based. It's um you were trying to do something big and you have a dwindling clock and a dwindling budget to do this with to hit product market fit and to to take on your market space. So they want to know that you're used to that rigor. It does help if you've been a

SISO before uh or some kind of security leader or some sort of director of or VP of you know function like that just so they understand that you have done more than just hands-on keyboard and we'll get into more of that later. you've also built something from zero. So hopefully you've you've uh created something from like that did not exist because when you go into these early stage startups, there's often not a lot of structure that you can lean on. Like you have to make it up as you go along and you have to be confident in the direction you're going to go. And so if you're not used to doing that or if you're used to coming into a company

that has wellthoughtout plans and structures, you're not going to have a good time here. And then lastly, like you've operated in a resource constrained environment. Um, I often joke that, you know, I come in and say like, wait, it can't just be me in a laptop doing your entire security program. We've got to we've got to do some other stuff. We got to work with other people and build these programs out. But it's often it starts there. Like you just show up and you're just expected to start securing things. So now that you have the experience like what skills help you with this uh when you're the first leader at a at a startup well you have to do a lot of

translation. So translating is probably 99% of your job and this comes down to the fact that when everything is moving really quickly in a startup and you're trying to beg, borrow and steal time from the rest of the company to help you do secure things, you've really got to translate why you're asking them what to do. uh is important like it can't just be uh because NIS said so or because you know a framework or like I think it's a good thing to do. You have to actually go quite a few steps lower and tell them this is why these sets of activities or this group is actually important for us to focus on uh and this is why we have

to prioritize this over another thing or another set of things. Uh you've also got to do a lot of um balancing of techn technical depth. So you have to be able to talk deeply enough with your developers and engineering team to help them understand like what's the technical risk behind it. And then you've also got to then convince your management team, your executive team why it's worth the business decision to either take away resources from delivering software or other or other aspects to focus on this and how they all kind of tie together. And then you know along the way you just have to do a ton of communicating and a ton of ambiguity navigation. Again,

think things are just not going to be clear that often, but the more you do this and the the longer you're at the company, the more clear they will be if you can follow the kind of the framework I'm going to lay out. So, what are the expectations of the first security leader? They are again probably not what you think. Here's what you expect if if as you're coming in. Here's here's what I expected many times. I'm going to have all this time. I'm gonna have all this money and all this uh support, all this buy in, like I can I can finally do it right. Like real security impact. Um but uh the truth of it is a bit more like

this where uh you're just doing stuff like that. And uh yeah, sove I've felt this way quite a few times. And it really is like you have you're coming to terms with what you're working with or working without. You know, you you you're you're told that you're empowered to build things but with caveats, right? It's you know, choose any tool you want as long as it's free or as long as it doesn't disrupt, as long as it's really cheap or as long as it's already a part of our AWS accounts. Um so you own the road map so long as it's what sales um has promised of course. Uh because that's that's the number one goal. And then uh hey, we

really support security here until it slows down like shipping. So don't do that. Um but other than that, you're good. Like you'll be you'll be great. And then and this is the struggle I've seen. Um you know, I've been through this many times and I've seen others do this. There's what you think you were hired to do and then there's what they think you were hired to do. And they often are not the same. But there in lies your actual challenge is you have to make those meet. That's that is kind of the the art of this is that the sooner you can realize that oh there's a disconnect and then close that gap that's when you're starting on a better

path to to actually closing this and making some real meaningful impact. So if you're not, you know, there's uh there is a silver lining to this. So it's not all doom and gloom. I don't want you to think it's bad. It just does require a certain personality and a certain willingness to to run into things that are chaotic and a bit uh on fire at times and uh are not well defined. Uh so if you like defining those things, if you like building things up like that and making it up as you go along and and iterating, then you can probably have a good time. And so this is where trust engineering comes into place. You know

what what is trust engineering? It's no it's not a Gartner term. I'll say that. Um but we will uh who knows if they will make it one. It would not surprise me if they uh co-opted this. But uh you're already to hear folks. So trust engineering for me is uh it's a way to position yourself as a business leader first and a security leader second. And this is an incredibly important thing in my mind. Uh that is very different than doing security at a larger later stage company. Bigger companies have wellestablished security programs, well established IT groups. You can come in and do security almost for the sake of security. Like I kind of hate to say it

that way, but you can come in and do a security function very deeply. You can care about a lot of things very deeply. When you're early stage startup, security is actually not the first thing. It's uh it's a way you have to kind of flip your mind is because if you don't focus on this aspect uh being a business leader first and supporting the business where they are then they can't continue to do what they're trying to do make money survive pay you a salary keep keep you on and build your security program over time. So why is trust engineering the way to do it and why is it important? In short, it just helps you build

bridges. Like, it just helps you find credibility where you don't have it yet because you're early on in stage. And so, if you're the first security hire, they may not even know what to expect. They being the the the company or the executive teams who hired you, they may not even know what to expect out of you um or what they what they can get from you uh as a security leader in this function. So, you need to build the credibility very quickly. You also need to establish connections with your developers and your customers and or engineers. you can just swap developer and engineer interchangeably. Um, and then it helps you manage expectations and you can align security to the

business which is I know is something that is probably a tired trope in our industry but it's you know it's something that um is actually super important at these early stage uh for a number of reasons. All right. So now that you know about trust engineering, now you know, you know, why it's important and like what you're faced against at these early stage companies, you know, what can you actually do? How do you do trust engineering? So I've come up with the five steps, and these aren't necessarily uh exhaustive, but these five have worked pretty well for me uh along the way, and I think they could work well for you as well. So number one, aligning

with sales and marketing, which is often a surprise like most people don't ever think to start there. Number two, making security work visible. You know, think I'm sure many people in this room are familiar with that. Using compliance as a security tool, you know, there is a way you can uh you can do this. Uh making clear decisions. This is a this is a really important one. And then you can finally build a scalable road map. So aligning with sales and marketing, this is uh one that surprised me when I when I figured it out. But when I ran towards this one first, it made a huge difference in in like the quality of life I had at the company and also made

uh make things a lot smoother so I could actually go do other security work. But by proactively addressing the existing customer security concerns, you take a little bit of pressure off the sales and the marketing team immediately. They get a little bit of relief. Um, you can streamline your security questionnaires and answers and you can then ultimately turn security into a competitive advantage from a sales perspective. And this this can be tricky because what you'll discover when you when you do align with sales and marketing is that many many securityesque things have been promised to customers that may not be real. They may not be true at all. So it's it's up to you to figure out what

that what that gap is and then either one make it true or quickly shut it down and say this isn't real. Like stop saying we do zero trust and we don't do zero trust. Like remove that from the the marketing language. But what this gets you is you make the sales cycle smoother. You get tagged in the sales cycle. So then people know that you're on point to handling some of these things that come up like customer questions, security questionnaires or the like. Uh you then get to you have a less chaotic outreach, meaning people don't always bombard you with super uh random questions on Slack again and again and again. If you if you if you

work with them, you can say, "Hey, we have a process of this. We have a way to do this. We have an intake way to do this." and that we can help you uh make uh some control over that chaos and you can also tie security work into revenue generation. So you can say yep we help with closing that deal because the breeze through the security and compliance question piece of the of the section. So you can say yep we helped do that. And to me, this is kind of one of the most interesting parts about working at an early stage company because, you know, in larger companies, you're typically too far removed from the

revenue generation part of the company itself. Like, you know, they make money somehow, like, oh, they're a bank or something. Uh, they probably sell bank products, but you don't actually get to see like customers saying yes or like no. You don't actually get to see that final step and how what you do does or does not impact that. uh if if at an early stage company if security is slowing down a deal they will let you know every 15 minutes on Slack that it's slowing you down. So you get to see that from a different perspective than a lot of other places too uh making security work visible. So just centralize any security functions like I said earlier like

there'll probably be about 10 or 15 people at the company who have done parts and pieces of security as their part-time job for since the company started. uh so they will be very happy to take it off uh their plates and for just hand it right to you. Um and then a great way I found making security work visible is just uh create internal documentation and external documentation that's just basic common questions and answers. So you know what do we do for our password policy? Make sure that's published internally and externally so nobody has to go ask you on Slack or ask you repeatedly for these same kind of basic questions and answers. You have a

standard way to do it. Uh you can even go so far as to make a we have a standard questionnaire answer uh document for these security questionnaires since they're all a bit different. Um but doing these creates like real artifacts that you now have something to leave behind and that people can use. And a big a big benefit of this is it takes the burden off of others who are already doing this part-time who maybe don't want to do it or maybe want it to be done but uh know they're not the best equipped for it and have have a full-time job doing something else. And it helps you control the narrative of security and helps you show the

organization how you as a new security leader are in control of the program. And that's kind of really what it comes back to. And again, it goes back to like what is true versus what was promised from uh from any any stakeholder you can think of. Now using compliance as a security tool is number three. Um I know a lot of people you know everybody knows that compliance does not equal security but when an early stage startup there is no difference they are they are one and the same. So stop treating them as separate things just make them all one and the same and that's why I say you know never waste a good framework. Always use uh

compliance's name in vain and shove security in there whenever you can. Um and you can easily use compliance to justify security or justify decisions on terms of priority. It works better than you think. Um, and part of that is, um, because you can actually, you know, make it feel like you have a plan. Uh you can tie it into, um, you know, revenue. Again, I I know I come back to that a lot, but like that's what early stage startups are about is customers and revenue. Um, and you're you're there supporting that. And you know, you can also help people understand um because people outside of security, they don't really understand security that often, but they do

understand compliance because there is a definitive start and there's a definitive end and you get a gold star like I did it. Mission accomplished until next year when we scramble and do this again. But you can actually talk in these terms because the job of security is never done. Compliance is done accord on paper. We all know that's not true, but that's this is how it's viewed outside of our our industry. So, you just have to lean into that. Um, and I have I have a long form post here about never wasting a good compliance framework. Um, where you can just do just that. Just like lean into it. Number four, making clear decisions. This one, honestly, I can't stress

enough how important this is. They don't even have to be the right decisions. In fact, they just have to be a decision. Something as simple as saying, uh, how do we respond to this contractual language? Like, will we respond in six hours or 24 hours? And you can just decide, oh, you know, I think 24 is probably more appropriate. And then let the customer push back if they're going to. You can say, hey, this this is just our stance. This is how we perform um this particular function and this is what we agree to. You actually have a lot more leeway when you make clear decisions like this early on than you might realize. Um, and so even how

deciding how you respond to a question, how you respond to the driveby like beg bounty like, oh, you have a you have a DNS entry issue on your website. So, you know, level 10 vulnerability, pay us money or um we'll exploit it. Uh, so you can decide how you how you handle those things and just document your process and uh you can also help decide what people should care about, what's a real risk, what's not, what should they what should they come to you with and where you should be involved and whatnot. And the more you do this, the more they'll bring you in because they like, okay, this person made a decision. That's good. We now have a clear path and it

may change, but at least they told us which way to go and what what to do again. So the benefits of this is that it gives you teams of direction. Uh it helps you prioritize and focus and and it builds confidence in your ability to lead and like gives you that underlying trust and you know you can just help you manage expectations internally and externally. And then number five, building a scalable road map. Um, so this is where you can, you know, you want to focus on the pieces that uh are really appropriate for your company and the risk level they have. Like you can't just solve all security things, but you want to make sure that compliance is

deeply integrated in your security roadmap such that you can say the reason we're doing these things, the backing we have behind this like my rationale for doing this is because this meets compliance, this meets a regulatory framework and these things help me prioritize what's important based on our company's risk posture. Doing that just gives people like immediate kind of like understanding that you know what's going on and then it just helps you balance needs. So you can say for example if a new compliance framework comes out or a new regulation like PCI just changed and has you know more strict regulations now you can add that into the road map and focus on that. And the benefit of this too is

that you know it works with what you have. Um, it doesn't it doesn't assume that you're going to go out and buy a bunch of tools and and hire a bunch of people, but it gives you a way to like think through this process. Uh, and it helps you develop diplomacy and influence. And I've always said, you know, security is more about diplomacy than it is defense. And especially true in early stage startups, it just you're influencing a different set of actors at this time. Um, and again, it goes back to you bonuses helping you manage expectations. So trust engineering will elevate your approach to leading security at startups if you can follow this this path. And

here's a uh framework I've come up with the ABC model. Always be selling uh always be selling the value of security like your bonus depends on it uh because it definitely does. Um and then you know the underlying goal with that is like you know make um the organization realize that you're the profit center they didn't know they had or they didn't know they they needed. And uh you will be much better off for this. Um and then if you can do these things and as you're coming on to the as a new uh security leader, you will then have like the institutional runway to do more of the fun stuff you want to do or more

interesting stuff you want to do. You're like, "Okay, now that we've gotten past this compliance cycle, I really want to dive into our cloud security. I really want to take apart how we're our code pipeline." And because a lot of times frameworks um and compliance, they don't actually get to the enough depth on the actual security issues. They're a starting point. They're not the end point. But if we can get some of this stuff like eat your vegetables first, then you can get to this other interesting stuff. So I just I'll leave you with this is you know security isn't just about risk. It's also about trust. Trust is what earns you the right to lead. And

if you're the first security hire, you're not building a security program. you were building a business function that did not exist um that just so happens to do security. But it's the way to the way to think about this is just remember you're you were building something net new for a business. Uh and it doesn't matter what the what the function is. You're building the business function to survive and be successful in the company itself. And that's that's what I got. Could you like

And I've also got Q&A if you want to do that too. But we can either one. Yeah, I think you have actually five minutes. There is for there is a question that someone has already asked. And if you if anyone wants to maybe to contribute to more questions, please go to besidesf.org/q&a. There's a Yeah, here is a QR code. Yeah. So, we have a bit of time. Cool. Good. All right. So the question is can you tell us about common pitfalls traps working with early stage startups or mistakes you've made that we can learn from? Um so working with them honestly you know you have to really sus out the expectations I think number one

is you know whoever's doing the hiring it's most often like the founding team uh in this case so it could be the CEO could be the CTO you need to make really quick uh to understand like what do you think this role does because and have them say it in what they believe the role does because it would probably be very different than what you believe it is or maybe what you want it to be at first. Um, and so I think having that having that come out and uh be upfront and say, "Hey, here's here's how I think I can help with that." But I want you to know that like, you know, I'm not

interested in a position that's where I just do your Sock 2 audit every year. And like maybe that's fine for some I just don't prefer to do that. Um, so I try to tease that out in the beginning and say, "All right, how how has um, you know, how do you actually see this role evolving? Um, or do you just see this as part-time?" And you can you can ask some questions to see how much they truly value the role or if they're just trying to hit a checkbox. And personally, I just avoid the the checkbox one because that's not a lot of fun. Um, oh, we got a couple more. Um, okay. How do you know when to

expand security team and how do you sell it? This is a great one. Well, you know, expansion, it's got to be um it's got to be tied to enabling developer productivity or uh contributing faster or providing some way to give you like a competitive edge on uh a deal. So like if you can tie if you can one way I like to do this is to like let's let me figure out something that the developer teams the engineers really want like a technology uh for example that I could also get benefit from as a security person and then I champions like okay I want that and then the other team gets to use it as well I'd like to put that

in this in the security budget and pay for it and they get to be the consumers of it. Uh and so they get like a secondary kind of voice, the champion, you know, why they should uh bring on this new technology. Uh and then that helps like getting more people and more more votes saying yes in that aspect. Let's see what else we got. Uh oh, I am turned off by the politics of director and VP stuff. Should I still consider the first security I see? Yeah, this is a great one. So, you know, politics and and are they're not the same at startups. Um, you know, the the the thing about working at large

companies in uh corporate America is that you become really good at corporate politics, but then also just remaining in corporate America. Like it's not really a transferable skill down to the lower uh smaller companies in a lot of ways. Um, so you have far less um, uh, politics in the same way where you're you're really just managing around people's personalities or typically lack thereof. Uh, in larger companies, you have a lot less of that. Um, and for the simple fact that it doesn't take 20 people by committee to make a single decision about a policy. You can say, I think this looks good. What do you think? And they're like, yeah, that sounds pretty good. I' I'd add this.

Like, cool. It's now published. And then it's amazing. you can like walk away and then you know somebody can have feedback and you can iterate on it but it's it's a different level. Um the politics really comes down to like when you're when you're especially at a smaller company is then translating that back up to their board of directors because it really depends on what type of company it is how um how comfortable the the board is on the tech or the security front. Uh so you may get really wild variations of like what their capabilities are on that front. Uh, and then that becomes like a different exercise of helping the board make sure

you're focused on the right things as opposed to like helping like the the seauite involved. Yeah, I say try it out. I think you'll be surprised if you're still in here. Oh man, that's a lot of questions. This is awesome. Uh, for uh maybe one. We have one minute left. Okay. So, if there is one, you can answer quickly and then Okay. Uh, is it better to use compliance instead of FUD to justify your budget requests? Yes. Yes. You may feel icky about it, but do it anyway. It's way better than FUD because you're not lying. You just say like, "Hey, that we have to be compliance regulations." You can you can just say, "And while I'm

doing this, uh, part of the compliance regulation is that I have to be really up to date on my threat detection." Well, then I get to create whatever whatever that means, whatever threat detection is. I've got to like bucket that in. And I'm like, "All right, because of this, I probably need to buy like a CSPM. I probably need to do these things. I need some developer work over here." And then that can give me the right visibility into these things. And you can you can build your back your way into compliance without FUD. Just just make it transparent and say, "Hey, this is a make or break for insert framework and obviously don't lie about it, but be

you be truthful about it." Um, and I've seen it work before. You know, I've had uh, you know, hey, we're going to fail our PCI audit if we don't make these steps. I've had the auditor tell me that. And so I say, "Hey, we have to do this or we you lose our PCI, which is, you know, a huge part of our business." And my, you know, Mastercard and Visa stop working with us. That's not going to be good for anybody. And then all of a sudden, the work gets done. Um, so I didn't lie, but I did maybe I did encourage the auditor to say these things, but still like you it's it was

an important thing that would not have gotten done otherwise. So you can use it, that's why I say use compliance in in vain. You can you can do it to your advantage um to basically social engineer your way to security. Well, thank you so much, Mike. Please give him a round of applause. Maybe maybe a new edition of our newsletter with all the remaining questions.