Cybersecurity Insights - Is Cybersecurity Everyones Responsibility with Masha Sedova

Welcome everyone. I'm your host, Matthew Rosenquist, CISO and cybersecurity strategist. And today we're going to talk about cybersecurity risk assumptions, specifically around employees. Either love them or hate them, but yes, employees. My guest is Masha Sadova, who is a co-founder and president of Elevate Security. She's also an experienced board member and industry speaker. Welcome, Masha.

Thanks, Matthew. Really excited to be here.

Hahaha, you say that now. Okay, now you posted a, shall we say, provocative post on LinkedIn recently postulating common myths around employees. Now, I jumped in the conversation, as I often do, with some, shall we say, dissenting opinions. And today we have the opportunity to openly and constructively discuss our perspectives and this interesting, interesting topic. So let's start off by kind of chatting about one of the first myths that you mentioned, right? The myth was around security is everybody's responsibility. And you'd indicated the truth is, It's not. And you said, and I'm going to read this verbatim here, "We can't expect our designers, engineers, and sales folks to get security as we do. That's our job." So, can you kind of discuss your thoughts around this? Add some color before I come in and drop a boulder or something.

Yeah. You know, in security, there are some things that we keep repeating again and again as they're truth, and security is everyone's responsibility. Everyone's responsibility is probably the number one thing that I hear us say all the time. And I thought it would be a very interesting mental exercise before I even wrote this post and say, what would it look like if we agreed that it wasn't everyone's responsibility? And the thought process for me as I went down that rabbit hole was we would be in a much better state if we actually came to realize that the truth of what we see on a daily basis is that security is not everyone's responsibility. We really want it to be. We really do. We hope if we say it enough times, it will suddenly be the truth that we will wake up one day and the employees in our organizations, our developers, our salespeople, our designers will, will take on the security mantle with as much responsibility as we as security professionals who get paid to do this. For our jobs and they take it with as much seriousness and responsibility and all of a sudden our organizations will be much more secure, right? We will have solved the problem of user risk in our organizations and that is never going to happen. As much as we want it to be the case, security will never be democratized to every employee at the level that we need it to be to successfully defend our organization. So the sooner we realize that we can't ever get to that end state, the better we can start designing our programs around it.

Okay. So let me attack this in, again, a constructive way. You know, you're saying security, the myth is security is everyone's responsibility. And you actually reversed that and said security is not everyone's responsibility. And we can talk about that. We can talk about how to make that happen or not make that happen. You also expressed it's impossible to do that, but you made a measure, a caveat in there that said, you know, they will not have that same level of expertise, diligent passion, whatever, as we as security professionals. So I kind of see this as a straw man argument here. Because it isn't necessarily binary. I don't think anybody in the industry is saying our end users, that developer or the person that empties the trash can, needs to have the same level of expertise or vigor or passion. But, and that's where the straw man would come in, but it's not black or white, right? It's not binary. Either they do have the same level of passion or they have no level of passion. In my mind, I see it as a scale, and I have seen organizations. So when I was with Intel, right, I built and managed cybersecurity for all of their mergers, acquisitions, divestitures, site closures worldwide. And there were cases where I would walk into an organization that we just acquired and talk with the executives and developers and basically everybody, and they would have the mindset, security is not my problem. That's those guys over there or those gals over there or that person over there, right? Not my problem. I'm gonna just do my job. And we saw in every single instance that didn't work out very well for security. Now, in some cases we saw kind of a blending. Yeah, it's their job, but I keep an eye out. I kind of help out. I know my stuff and they don't. So yeah, I know what's kind of secure and what's not. Okay, great. That's a little less risk. We saw some where we had actual advocates, especially in the development environment where there would be an advocate going, hey, I'm the lead architect or I'm the lead designer. I want security in my infrastructure that I'm building this thing in, but also in my products. The security guys, as great as they are, let them control the firewall, let them control the email spam filters. I'm the expert in here and I'm going to help advise them. I'm going to work with them on how we should be securing our development environment. And we've seen things above that, right, where it's not only development, it's IT. And you had this sense of community. And in most cases in those situations, it's where that company had already been brutalized. And when a company is brutalized, you take ransomware or malware or a wiper like that, It doesn't just affect the CEO. It also affects that poor developer who was writing code and now it's destroyed. It's gone. Their work for 6 weeks is gone. Right? And that really kind of brings up that passion going, I don't want that to happen again. And honestly, I can't necessarily trust the security guys. They don't know my work or anything else. I need to be a part of this and now I felt the pain. I'm going to be part of it. And that was something that we drove in Intel, you know, when I was there in the different groups that I managed, but also, you know, leaving Intel, you know, I'm a CISO and I advise all over the world. That's something we drive because, and I said this on stage, I would rather have a security-savvy workforce than a stack of firewalls because it's their decisions. That often can cause problems, but also they can not only be the worst, right, risk. I mean, I'm looking at data here, you know, PurpleSec says 98% of cyber attacks involve some form of social engineering, right? 25% of all data breaches involve phishing. That's from Verizon. 90% of all malicious data breaches are from social engineering, and the list goes on. So we know they are a potential ingress point of bad things. Right. And having them at least smart and savvy and motivated can reduce a lot of that. And then on the back end, I may be CISO, but I really don't know the inner workings of what's going on with every single developer and the code and tools and platforms that they're using. They do. They can detect when something's off or something's wrong. Something is different. I can't. The tools, the security tools probably can't. Maybe if something blows up, but they can have the insights early on. This doesn't seem right.

So I totally— and elevate it. Yeah. So, so I understand and I don't disagree that having an organization where more employees are security savvy than not isn't a better outcome. I 100% agree with that. And I'm like, okay.

So we agree. Security-savvy employees are a better outcome.

Better than not security-savvy employees. Yes. Okay.

Yes, yes.

I think to all of your points, and for me, it boils down to a concept of security debt. When you have an organization where security-savvy employees, every time they're making a decision, if they are security-minded, security-savvy, they're going to opt in for decisions. To the examples that you have where a developer may choose to double-check their code or an, or, or Somebody may double-check on a process in finance before—

Or not click that phishing email.

Exactly, right? And so, there's less cleanup we have to do, right? So, there's less security debt. Every one of these decisions is adding up. And that is ultimately what it means to have a more secure culture and more secure-minded organization. And I 100% agree with that. And there are ways you can influence. That said, for many organizations, this has been their core strategy. I can only be secure if my employees continue to make the right security decisions. If my developers do not catch this, all their eggs in that basket, that's it. If they do not raise their hand when, when they see something, then I'm screwed, right? Then, then, then I'm not caught. Then I don't get this phishing link or I don't catch this process. And so what I'm suggesting is that yes, we need to be making organizations that have this security backbone for our workforce. That's awesome 'cause it's way less cleanup. However, we also need to fully recognize that that will fail, that at some point will fail because human beings are human, right? And if we were able to patch the human OS, I hate that, but— The what? The where? Yeah, yeah. We, I mean, we would have done it a long time ago. We've been trying to communicate to employees, be better, be smarter, you know, come along for the ride. And what ends up happening, and this is a lot of the work that we're doing at Elevate Security is mapping individual risk. And what you see is that the majority of your employees, close to 60%, are going to fall into the, yeah, I'm not going to make a mistake at all. I'm part of the security champion.

Catch all the mistakes.

This is great.

Don't say never. We never say never. It will happen.

Those are not the ones I'm paying attention to. It's these high-risk employees, these 80— this 8% of employees in our workforce that are going to cause 80% of incidents. And if we think about the fact that, you know, how do we plan for failure? And so in such a way that we can gracefully fail so that employees can be human, employees will make mistakes, and that ultimately we can get to a place where we aren't expecting our education and our awareness programs for someone to suddenly get baptized into security and never make a mistake. That is unrealistic. We have to understand that there's this bell curve of risk where some people, yeah, they'll get it and they will take it very seriously and they will be your champions and they will be the people who flag controls in your organization or places where you deviate from controls. But there's very much a part of your organization who provide extreme value to your departments that had nothing to do with security, so you can't fire them. Right? You can't remove their access because they're working on your next vaccine or closing that big deal that— or it's your CEO. And, you know, they're there. It is our part, our responsibility in security to understand how do we enable those people to lean into their work and do it well without the expectation that they have to take all this training, understand all these protocols, like be on top of all of these threats. In order to be able to be a successful member of our organization. Like, I would— I love the mental challenge of what does it look like when security isn't everyone's responsibility and employees have this freedom to achieve their digital aspirations without all the friction that we put on these people and we still get to be secure.

See, I was with you. I mean, we had a lot of things in alignment there. I was with you right up until the point that you said it's not their responsibility because we agree. We agree that we manage risks and the way we mitigate risk is through controls. There is no set of controls that is infallible, whether it be wetware, right? Human social engineering or even technical. There's not a firewall that can't be breached. There's not a, you know, an ACL system that is perfect or anything like that. So we know all our technical controls can fail, which means we tend to do either layered security or, or, you know, add-on, additive type securities to be able to reduce that, to cover those gaps. And I was with you with all of that because all of that in my mind, absolutely true. This is how we do it. Defense in depth, layered security. Yes, yes, yes. And then you said, but it's not their responsibility. And that just took a huge set of controls and you tossed it out the window. And that's what I have issue with. I know even the best security behavioral training advocacy, everything, right? It's still going to fail sometimes, just like our technical tools will. Right. And I've gone into organizations before where phishing You know, we did a test on phishing to see how susceptible they were, and it's double digits. I've seen organizations with a 30% failure rate, right, on a single phish. One-third of the organization almost clicked on it, right? And I've gone into those organizations and reduced that down to under 1%. Now, it still means that 1% is going to fail. Someone's going to click on it, but that reduces what you were exactly talking about, that debt of now I have to, I don't have to deal with the other 29%, right? My technical and other controls might be able to mitigate or at least manage that risk, that 1% risk, but getting rid of 29%, that's a huge value. And that's just phishing. That doesn't look at all the other potential issues. And that's just preventative. That doesn't look at responsive. Detective controls, or when I have to go and I have to respond and resolve something. Again, if I've got security-savvy employees, they're part of that team. And I ran crisis response for Intel as well. So I landed the, basically the CERT team, and I was the incident commander for the company. And when we had an organization that was like, hey, that's not my problem. Go talk to IT. I'm going to go get lunch because my systems are down. Right. You let me know when it's done. That took a long time to fix. When the employees were jumping in going, hey, what can we do? We see this. I can do this. Can we shut this down? Hey, tell me how I can help. That's when the recovery time was much, much faster.

Sure.

So again, I see— don't get rid of that control. That's something we need to advocate. It's everyone's responsibility, not to the same level as the security. That's our full-time job. Yeah, right. But if you're a developer, making sure your product is accessible and it performs within specs and it's secure, that's part of your role. Yeah, you know, um, and I would even say it goes down to the person that empties the trash. And I'll give you a real example, right? I would go into, to different companies and I would literally talk to the people and the vendors that would come in at night and I would tell them, from now on, starting today, if you find a system that's unlocked as you're dusting and cleaning, I want to know about it, right? It's now your responsibility because that person's not being secure. You see a USB drive on someone's desk, I want to know. We're going to work together. We're going to change everyone's behaviors. And it did, right? And it doesn't have to be brutal, right? We're all trying to, we all have the same business goals of whatever the organization is. We're just trying to do it securely. And there's trade-offs there, right? Between the friction and the cost and the security. But getting the employees or any trusted people to be part of that and to buy in is a huge, huge benefit.

So I, yes, until a certain point. I want to unpack phishing in a little bit more detail because I think that's something all of our listeners can, Can relate.

We all get hit with it. Yeah.

Okay. So we create a phishing test, 30% of our organization clicks on it, right? That's it. So we have a couple of choices. We can send out emails and say phishing detection is everyone's responsibility. Keep an eye out in your inbox. It's really important, right? And so, you know, that notification will be helpful for about 10%, right? So now we're maybe at 20% of our organization's like, well, security told me. Whoa, whoa, whoa.

You're making an assumption. You are making an assumption.

I'm making an assumption, but I'm assuming that security training this is for illustrative purposes, but I'm assuming we roll out a security training that a subset of people will say, "Oh, okay, like, thanks. That was the— I didn't know. Now I know," right? So we've reduced the certain amount of— there's knowledge around, "Hey, oh, now this is my responsibility. I have a certain amount of— I now have the knowledge to detect this better." There are then other things that we can start layering on that help reduce this in a much, much deeper way than we have before. And what I have seen is many organizations stop at that point where they say, "I rolled out the training and I told them it was their responsibility. I don't know why they're not doing it. Let's just keep hammering it. And then, every time they don't do it, we'll escalate it to the point of firing because we told them—" Beat them over the head until they comply.

Yes.

Until they comply or we have a case built up so we fire them, right? Like, and that's what it means for many organizations that security is everyone's responsibility because it is an excuse for us as security professionals to not appropriately resource employees in order to meet this threat.

I 100% agree. 100%. And again, it's layers, right? If we have those, we still need the technical controls. We need to understand the business. We just don't rely on one set of controls. And if you're just relying on employee training, even if you get down to 1%, 1% is going to get through, and that's enough to cause a lot of damage.

That's exactly right. That's exactly right. And so, I think back to the original core value value of core reason of posting it is questioning the assumptions we use to build our programs. And if people go in saying security is everyone's responsibility and I need to just tell them that it's their responsibility or else, we have failed ourselves as an organization. Because when we assume that it is not, it could be, it's great if someone's like, you know, it's my responsibility, that's awesome. But if we empower them, and I'll give you some examples of things I have never seen done in the industry and I think in phishing, but if we, support and help people in these capacities, it would be a huge leg up. So, studies have shown that we make way worse decisions when we're hungry. What if I say, hey, you know what, we're not caffeinated properly.

We're not caffeinated.

Like, I make my dumbest decisions an hour before my lunch block, which is on my calendar. So, can you just hold off on any externally, like, unknown emails to my inbox until I'm out after lunch so that I am more capable of making security responsible decisions or during happy hours, right? I know I'm going to have a glass of wine. Please just make sure any external sender that I've never talked to before comes in with flashing red lights. So like, you can help me be a human around security. Or people who are bad at phishing, like, can they self-select into phishing practice? You know, it's like, hey, let me just like, can I fail safely so that I can practice this? But there are so many things that we can be doing in security, if we stop the assumption that I told them to do it and why aren't they doing it, and actually say, what are the tools that we have at our disposal? There are so many brilliant people in security who I feel like just accept the status quo as people are the weakest link and they should know better. So I'm going to just spend a lot of time on detection response and cleaning up. As opposed to actually investing in the proactive piece. And you were saying a lot of the things that you, a lot of the benefits, and I 100% agree. When we have people who are enabled to make security decisions well, it significantly reduces our security debt. We have to do so much less security janitorial services after the fact. And if you don't think about it, proactively, like, we're all doomed to just the life of cleaning.

Yeah, you can never keep up. So, and I like where we're going here because, you know, I want to talk more about what are those best practices. Now, there's assumptions here before we get into that, and you mentioned a few of them, but the assumption is that it is beneficial to get employees to take part, right? To assume some level of responsibility or care or forethought, something, because we do want to be able to prevent things. It's a lot less costly and impactful than, you know, rapidly detecting and responding, recovering. So we do want that. And I see it sounds like we agree on that. So having security-savvy employees or just some level is better than none. Agreed. Okay. So what are— and I can think of a few, you know, in the practices, you know, in my career in working with— you had mentioned a great word, empowering, empowering them. And I've seen, first off, even before you empower them, you know, you have to be able to communicate with them so that they understand there's something of importance to them also at risk. So when I sit down with developers, right, I almost always use the example, if you're, you know, the person next to you clicks on a link and ransomware happens, guess what? Chances are your files that you've been working on for 2 weeks, they also get encrypted or they get deleted. Right? And that puts a personal stake in there. Oh, well, I don't want them to do that and they don't want me to do that. Okay, maybe that is worth my time, a little more effort. Right? So once we establish there is a benefit, and we've also seen organizations put in financial incentives or other types of incentives, rewards, badges, extra bonuses, extra— I've seen one company actually put an extra day off, right? They gave, they gave PTO. If you didn't click on any phishing for the entire— you get an extra day off. Have a nice day. Yeah, I've seen some. Everybody's chomping at that one, right? Especially towards the end of the year when they're so close, they don't click on anything. Right.

It's like days since last accident for manufacturers. Exactly. Last phishing click. Yeah. So it's group accountability. Yeah. Yeah.

And I've also seen them use penalties, which is typically psychologically it's not as strong, right? If you click on it, I'm going to force you to take 8 hours of phishing training. Right? Shoot me in the head now, right? I hate that. But again, different cultures and different businesses have different expectations and some things work. But again, if we can find good practices to help advocate them. The other thing for different cultures, you know, that I've used is if they suspect a phishing, and we're stuck on phishing, but this applies to other things too. You know, if somebody suspects a phishing, I have them send it to me or actually the IT guys who then the security guys look at it. But we'll take that, and if there's like an attachment or a link, we'll dump it into a sandbox, right? Explode it and see what happens. We'll generate the report and we'll actually tell them, we'll show you, let me show you if you would have clicked on this, what would have happened? It would have sent you here. It would have done this. It would have been looking for these vulnerabilities, so on and so forth. And that's not only— it's kind of sexy in a certain way, intellectually going, wow, I avoided that. And this is way cool. This is what would have happened. And it, again, it just kind of buys in that, hey, I'm, as a security professional, I'm not your enemy. I'm not here to beat you over the head with a club or a nightstick. I'm here as a partner and I'm going to work with you. If you've got suspicions, awesome. I would rather be called 50 times with a false positive than not get called when something bad actually does happen. Them. Yeah. And so working with that, that works. I mean, what are your best practices in advocating that, you know, people should, or, you know, step forward and get that kind of behavior? Yeah.

I mean, what you're talking about is the relationship to failure and making it safe to fail. And if you don't create a culture where people feel like it is safe to fail and safe to admit it, you're just not going to get the level of reporting and open dialogue you want from your organization. And that's That's super critical in detecting things that bypass all of your security controls. And you're talking about— this is, this is the core foundation of what it means to have a very healthy security culture. The thing that I notice time and time again is that the people who exhibit those behaviors are already your security champions. They're the core thing that is missing in most programs that I come in and look at and consult on is an understanding of the nuances of which employees need more focus focus and attention. Which employees need your time and your demo environment of, let me explode this phishing email in a sandbox? Because the people who volunteer for that brown bag are already the people who get that security is interesting and important and a part of their responsibility. The people who are causing your incidents are in the— those repeat offenders are also not opening up your emails, are also ignoring all of your trainings and your outreaches. They're the people who think security doesn't apply to them. And are making repeat mistakes.

Or they know better. Or they know better. Or they know better. Engineers always, "Oh, I know security.

I know better." Oh, we are actually publishing a report at the start of January that Elevate Security, along with Cyentia, which is a research firm, where we map risky users by departments. And it's the question I have gotten for years. And we finally have the dataset across 8 years of behavioral data for 300,000 employees. And I will tell you that engineers are up there. They're not number 1, but they are up there. They're up there. They're up there.

One of the things I used to do when we would acquire an engineering company is I would seek out the head engineers and I would sit down with them face to face. Typically, I'd buy them lunch. Yeah. Sit down and I would go, listen, we're acquiring you. We're going to put security controls in, so on and so forth. But let's be brutally honest, you are smart enough that you can get around them. And they would all smile like, yep, yep, we can. And I know that. Yeah. I said, so instead, let's have a discussion on why you shouldn't do that. Yeah. And we would talk about, okay, we're going to put this control in place, and they would come back and go, oh no, no, no, no, we do it this way so it doesn't matter. Yeah. I would go, yes, but let me tell you about these attacks that took advantage of what you just did. And they would go, oh, okay, okay, we won't violate that policy. Well, what about this one? This just seems stupid. Okay, let's talk about that. And I would go down the list and typically it would take an hour and a half. Kid you not. And we would go through all of them until we got to the end and they understood why these crazy policies really aren't that crazy. And that it isn't just them being secure. They're subject to everybody else being insecure. And so if they don't have those extra controls, they get victimized by other people outside of their organization, still within the company. And that made a huge difference. That's where I spent more percentage-wise, more time with anybody, even more than the executives, to advocate for security and get everybody on board because super smart people think they know it, right? It's the Dunning-Kruger effect. And we have to understand that's one of the barriers. We don't just deal with technical vulnerabilities. We deal with behavioral and process vulnerabilities as well.

So, Matthew, I have no qualms with the methods that you just laid out, and I've seen them work to great success. The thing that I continually see currently missed in the industry is some basics of risk management. If we don't ensure that the people who participate in these kinds of conversations or these high-touch programs that require a lot of time and thought and are actually quite effective at getting people on board, we don't guarantee that the people who need that conversation are in the room because we skipped the step that actually maps which employees are riskier than others. We, you know, often it's a one-size-fits-all. At best, it's role-based. Even in this conversation, we said engineers, right? Which is about as good— and that's a huge population for people. And there is no other part of security that lacks the level of visibility into our level of risk than the user and the human element. We're able to map with different levels of severity our unpatched servers, our audit findings, our incident response, our incident tickets. And we can say, hey, These are our P0s. These are our critical, our SEV1s. These are the ones that require the highest amount of time and attention. This is going to be the thing that I'm gonna, you know, do white glove service and make sure all like this is handled. But we have no concept of which of our employees are higher risk than others. For many organizations, we haven't even defined what is a high-risk user. For at best, You know, most people will say, well, give me an understanding of these people click on simulated phishing. But that is the best level of signals that most organizations—

that isn't very good. That's not in depth.

It's a very low fidelity signal and it's very, yeah, and it's very contrived.

Snapshot in time. It's, oh yes.

And there's so many other signals. If you wanna focus on engineers, you know, focus on people who have privileged accounts or mishandling certain access levels or checking code, and people who maybe have introduced incidents in the past and make sure they are in the room about why security policy exists, not the people who are really excited and probably are like your default security champs. They already get it. They totally get it. And so if we skip the data, the risk, the measurement piece of understanding where our risk is distributed, you're going to miss the fact that there's a— there is— it's It's 8% of your organization that if you spent the time on those people, you are going to make a huge change in the way that you're cleaning up. Because it feels like we confuse activities for impact when it relates to the human element. And we haven't— this was the third myth that I posted on LinkedIn is that people are the weakest link. And my argument is that it is just human risk is just not managed on par with the way we manage the other areas of risk. And if we think about it like a risk that we can quantify and appropriate and add appropriate levels of interventions and controls, like you're mentioning, we're going to be in a much better place. Yeah.

And I actually, I, I take the different perspective. Humans are the weakest link because they are the easiest path, but it doesn't have to be. As you're saying, and I love where you're going here. We look on the technical side and we do that risk analysis, right? What is the likelihood? What is the impact? Who's the threat? What are their methods? And we're able to go deeper, much, much deeper than what we do on the human side. Yeah. Right. We only look, okay, what's their role? Maybe if they're new or not, right? Maybe if we just fired them. I mean, some real wide kind of strokes here. Right. And, you know, I've been actually working with some other startups and they're looking to narrow that down to look at the actual behaviors and exposure level. Right. What do they do on social media? What do they do here? You know, attention spans and all those other things because we lack that on the behavior side. And it sounds like you're doing work in that space to be able to get that more granular, richer data so that we can apply those same fundamentals that we do on the technology side, right? And we just assume they're there. And yet we're so superficial on the behavioral side. That's right. And like Peter the Great said, right, if you're trying to defend everything equally, you're defending nothing. Exactly. And yet it's that 8% you're talking about. That is where we need to have our disproportionate disproportionate amount of effort and focus. But how do you identify that 8%? Yeah, and that becomes the challenge.

That's a lot of the work that we're doing at Elevate Security. It's essentially creating a security credit score for your employees.

Well, okay, so tell me more about Elevate Security. What are you providing then for your— because not that I'm trying to do a marketing or anything, but I'm now interested because, you know, this is a weak spot. How does Elevate Security kind of fill in that richness of data that we're missing in the world?

Yeah, if you think about this, you and most security teams already have data in their environments around the decisions employees are making on a regular basis, good and bad. Do people browse to sites that are blocked? Do they try to download malware? Are they clicking on links that have gotten past your email gateway? There are so many datasets available in your environment right now that are not being used. And what we do as a platform is integrate with these security technologies and create the security credit score for every person in the company. So, you're able to see on an ongoing basis what kind of security abilities people have, good and bad, in what areas, when that risk changes over time. And then, once you understand that risk distribution, we're able to provide through workflows the targeted intervention. Some people just need a light nudge back on track. Some people need a little bit more bubble wrapping so they don't hurt themselves themselves in the organization, right?

That's a very politically correct way of saying it. Wow. Wow. I applaud you for that. That's very nice.

You know, there's different things you can do around, you know, adapting MFA controls and step-up authentication for some people, deploying some protective technologies like web isolation browsing for some people, you know, changing the sensitivity.

Bob doesn't get to see the internet, okay?

Bob, you don't get to see it. That's right. Yes. Like, Bob, until you can do the following, No internet for you, right? But the idea here is you're appropriately matching safeguards and controls for the people who really need it and giving positive reinforcement for the people who are great and let them run free in their environment because they have great—

Run free and naked. Do whatever you want. No, okay.

And it's also really cool because you can start, as we are seeing this whole wave of zero trust and thinking about how do we uplevel our identity and access, Understanding the individual risk level of individuals based on where they are at a point in time as we think about access controls is core because we know about the device posture, but for many organizations, we're blind as to who's driving this vehicle, right? And so critical piece of input to be able to adapt access appropriately.

So do you see the output of Elevate tying in? Because we've already talked about the technical, measures in depth, do you see it as dovetailing it in so that again, we could use it for zero trust, right? We know the configuration and the trustworthiness of the platform. We're using identity to validate who's actually sitting at that keyboard. Right. But that hidden element of, okay, it's Bob, we know it's Bob, Bob's an employee, but that extra layer of, yeah, Bob isn't very smart and he's going to do lots of bad things. We need to put that bubble wrap around him. Yeah, you know, that needs to happen. So do you see your product as dovetailing to give that extra vision, that depth as part of that trust picture?

Yeah, absolutely. Yeah, we're, we're the only platform that gives this level of deep insight across your datasets. To be able to understand what risky behaviors your employees are doing across multiple channels and then actually kick off these workflows to appropriately bubble wrap in other technologies and adjust policies and settings. We also have the ability to provide hyper-targeted feedback for folks in Slack or in Teams or in email and say, "Hey, Bob, that was not a great thing you did. Do you know you actually browsed 3 times more, your sites 3 times more often than your team?" This is what you should do differently about it. And it's a very different conversation, um, as it's near real time, as it's hyper-personalized. And it changes the conversation from like, thou shalt be responsible for security, to, hey, you know, like, this is the bar and this is where you are related to the bar, and this is how you get back on track, Bob.

Okay, so moving away from talking about Elevate here, um, the last question that I have for you is, you know, we've talked about lots lots of great things that can be done and more data that can be gathered and risk managing not only the technical side but the behavioral side. How important in your mind, because again, a security person may be going, "Yes, yes, yes, absolutely, this makes total sense. I want this. I need this." How critical is getting senior management to buy in to these behavioral controls? Doing the training, providing feedback, or even allowing the bubble wrap to be dispensed because that creates friction and that may limit Bob from getting the information that he needs as part of his job. How important is senior management to be part of this decision to buy off and get behind it?

Super critical, and I'm going to explain why. It's a concept called security drift. So you, let's say you have Bob who's a developer and Bob has one week to ship code on time and he either has the choice to ship code on time or insecurely, or he has, or he'll need to ship it late but securely because he doesn't have enough hours in the day to do all the testing and, and, and management.

This happens all the time. Yes. I love this example already. Really real. So what is Bob gonna do?

Is he gonna ship on time, or is he gonna ship securely and late? And what he chooses to do is set by the security culture of the organization, which is set by the values that the executive team and the management hold. What Bob will get fired for and rewarded for is what Bob will do. If he gets rewarded for shipping on time, and that is set by executives, then he will ship on time, and he will hope to that no one will notice. And the first time it happens, maybe nothing, nothing gets— there's no issue. So he'll say, oh, it's great, I get my bonus and I like— nothing happens. And Bob and all of his teammates are going to make that decision again and again and again. And every time they do, the bot— this is where the security drift concept comes in. It moves a little bit closer to acquiring so much security debt in our organization that it leads to a breach. It's a probability game, and the probability expands a little bit more every single time. Now, if you have an organization that is the opposing force that says— this executive that say, you know what, we really care about security and we're going to incentivize it, reinforce it, and acknowledge when people make decisions in favor of this, whether or not it is controls or spending the time on the training or whatever is the appropriate thing for the moment, If the organization rewards at an executive level, then that is the decision every employee is going to make on a daily basis. And ultimately, you, you manage your security debt so that you're reducing the probability of an incident happening because you have less tiny little exposure points happening on a regular basis. So super critical. It doesn't happen without, without the management backing because it gets reinforced for other things. That aren't security. And that's, that's what it comes down to.

I think you're spot on. I absolutely love it. In fact, I would take it a step further because I tend to be very vocal when I go into these companies and talk with them. I'll actually sit down with the executives and go, you know, we've got the Bob situation. They can either ship on time or they can ship late. And you want him to ship on time and for it to be secure. Ultimately, if Bob is ever faced with that situation, ship on time or ship late but secure, it's not Bob's failure. It's your failure as the executive because you have not put in the appropriate expectations, controls, maybe resources, adjusted timelines, whatever, to make sure your product can ship on time and be secure. So it's not Bob, he's just the tail at the end of the process. It's your failure and you need to get ahead of that. So Bob is never put in that position. He should never have to consider those, those trade-offs. And I think that is optimally, if we can convince management in understanding not only I'm going to buy in, but I'm also going to take responsibility as part of my entire CI/CD process to make sure this can happen appropriately. Now you've got transformational change. That's it. So, totally agree. All right. Thank you very much. I know we're at time here. My sincerest appreciation, Masha, for you joining me today and having these wonderful conversations. Hopefully you'll forgive me if I said anything offensive. I enjoyed it. I really, I really believe, right, conversations like this really help everybody. So thank you again, and thank you everybody for watching, and we will see you all next time.