Ep. #16, Security Training with Elevate’s Masha Sedova

Guy Podjarny: Welcome back, everybody. Thanks for tuning back in to The Secure Developer. Today we have with us Masha Sedova from Elevate Security. Welcome, Masha.

Masha Sedova: Thank you so much for having me.

Guy: Can I ask you to just introduce yourself a little bit, and Elevate Security?

Masha: Yeah, absolutely. I've been in the security space for 16, 17, 18 years, I've lost count at this point. But it's a passion of mine for as long as I can remember.

I started in a very traditional space, mostly computer forensics and doing cyber crime analysis. But over the course of my career, I became obsessed with this idea of,

what it would look like if we could get people to want to do security, instead of have to? And, why don't people want to do security?

I started merging my passion for computer security with the study of behavioral science, which is the study of how people do things and why they do things, and habit change. And I started applying that into my work, initially while I was running a team called Security Engagement at Salesforce.

In that role I had the ability to be responsible for people's security behavior in general employees, as well as developers as they applied to creating secure code and fixing bugs in code. And also to customers, in getting them to adopt secure features in the Salesforce platform. I got to do that for a phenomenal five years and I built this amazing team.

From there I wanted to take a lot of my learnings and apply it to other companies and share what I had learned in best practices. And so that took me to starting my own company, that I've co-founded with a fellow security engineer named Robert Fly. We started Elevate Security at the beginning of last year, and it's been an amazing ride so far.

What we are focusing on is creating a platform that can measure, motivate and educate employees to be the strongest link in security,

however that looks like in different organizations. So really, getting employees to understand their role and be able to be advocates for security in their organizations.

Guy: That's cool, that's definitely is a worthy goal, and not an easy one at that.

Masha: Yeah.

Guy: How did you even get into security in the first place, into that forensics part?

Masha: Yeah, I love the idea of there being a group of good guys and there being a group of bad guys, and being able to defend the good guys on a regular basis against an evolving threat.

No two days are ever the same, so it was an incredible application of a standard computer science degree into one that had much more of a dynamic attacker/defender landscape. And then when we started including the human factor in there, I was all the way in.

Guy: I think security definitely has a certain mystique to it, from the outside, if you talk about the good and evil in and around the security attributes there.

When you get into the weeds of it, there's just that much more complexity of it. It's not quite what you see on the movies.

Masha: Yeah, you know I actually think that the mystique of security doesn't do the security field a lot of good. I think a lot of people know much more about security than they give themselves credit for, and they write it off and say, "I don't understand this whole complex security thing."

In fact, our ability to recognize threats and when we're being psychologically manipulated, to be able to give up information that isn't necessarily public information, a lot of people have intuitions around that and have experience in their life to figure out what's good and what's not.

With some basic tools and support, be able to understand where attacks can come from and how you can defend yourself,

I think a lot more people can be much more effective at security, and really should give themselves much more credit than they give themselves right now.

Guy: So, do you think the reason that people, or maybe the core, or one of the core reasons, that people make insecure decisions or kind of make security mistakes, is it indeed some sort of self assessment or self appreciation, I guess, of their skills?

Maybe I will just ask this a little bit broadly. If you had to sort of simplify down something quite complex, why is it that you think people don't apply security well or make insecure decisions?

Masha: I think there's quite a few reasons, but the one that I see most often is people think that security doesn't apply to them.

So what that looks like is, let's say I choose not to put on my seat belt because I think I'm a better driver than everyone else and I'll never get into a car accident, right? But in fact, you may not be in control of all those circumstances, and it's always better to put on your seat belt, for safety sake.

The same thing with security. You see, you think that it's something that happens to other people, so security breaches are something you see on the news, but it's not something that will happen to you.

Most people get desensitized to some of the things that they have access to that's of value.

Even if you handle really critical information on a regular basis, it can become normalized and you may not realize that that information that you have access to, whether or not it's emails or code or personal information of customers, that could fetch a really nice price on the black market. And there are people in the world that are quite motivated to get access to that data.

For many people, just being able to understand that they are in fact a target and that they do have access to things that are of interest, and if they don't take some basic precautions and have a baseline vigilance about their work, they will absolutely be the easiest target and will make the next headline.

The trick with security, it's not necessarily outrunning the tiger, but it's about outrunning your slowest friend.

It's a little bit ruthless, but hackers are inherently lazy. They want to go for the easiest target. So just don't be the easiest target and you're pretty good. Unless of course it's a government sponsored agency, in which case that's a different conversation.

Guy: There are some entities that that rule doesn't apply to them. Talk about that a bit as well, the notion that you just need to be better than the next one, right? Sort of the next company.

And funny enough I guess, we do that in the real world. We put these stickers on alarm systems that don't exist just to make a thing. It's like "Oh, you know what? Maybe I'll go to the next one who clearly doesn't have at least an alarm sticker." Maybe not an alarm system either, or those components.

How do we remind them, though? We think about security and there's no natural feedback loop. It doesn't hurt until it hurts really badly. How do we keep it in people's psyches, or how do we not get them to forget, and realize it might happen to them?

Masha: You're getting to really interesting questions. How do we perceive risks and threats? We perceive risks when it's immediate, it's imminent, it feels immoral.

There's a study on this, but the idea is, it's in front of us or I know it's about to happen or I've just recently seen it happen so I can recall it in my mind.

When we watch the news, we think occurrences on the news happen much more often than they actually do, but the nature of the news is that they don't actually happen that often, which is why they've made the front pages really.

Guy: Otherwise, it wouldn't be newsworthy.

Masha: Exactly, it wouldn't be news. And so security, in order for us to realize that it is as ubiquitous as it really is, is I think it's on the responsibility of security teams or people who have access to this information, to start disseminating it to people who are affected.

What that looks like in practice is,

if you're, let's say, an enterprise with a security team, it's important to show the incidents that you had to respond to and share it with developers who are writing your applications.

And say, "We had to defend this app against an onslaught of hackers." Either it worked really well because you developed it perfectly and securely, please keep doing that because this was the impact of your work, or this led to an incident and a breach because it wasn't written securely or wasn't tested appropriately. And so now we actually have this case on our hand.

Most developers that I talk to, specifically, don't actually believe security is an issue that happens at their company. They don't think it's real. If you could spend the time to prove to them that it is real, they would absolutely prioritize that work and they would understand that they're fixing something that's worthwhile.

But it's not priority because they don't actually think it's a real problem. I think that feedback loop that you were mentioning earlier is absolutely something that we have to consider sharing a lot more of, which is, I would say, not a practice that security teams are great at.

The partnership with PR teams also make it really difficult for security information to get shared because, my experience is that PR teams often are really nervous about incident information leaking and showing the company in a bad light, when in fact that should be an amazing lesson learned for people to evolve from. Often that information is locked down.

It's, "You will never speak of this shameful incident ever again," when in fact, that's the most valuable teacher we have.

Guy: Yeah, I think I love the analogies from everything you said to the activities that happen in the world of DevOps. DevOps is all around measurement and dashboards. One aspect is, "If it moves, measure it. If it doesn't move, measure it in case it moves." And just the notion of, I really like the idea of attaching that to security components.

I know that at Etsy, at the time, they created dashboards that show the simplest types of attacks like SQL injection attacks and the likes, but just charts the number of them on dashboards and put them up in the main dashboards, just along side the up time and the other core components just to show and remind people that, "Yes, we are getting attacks, many hundreds, if not thousands of times a day. Those are just the simple attacks, and there are sophisticated attacks that evade around and similar."

It used to be in the DevOps world, that you didn't talk about failures. You didn't talk about outages. I think really around the Velocity Conference and the pioneering DevOps conferences, where people will come out and unashamedly talk about an outage and how they messed up and then subsequently what they did to correct that.

Security is very, very scary. I still think, and O'Reilly is now running O'Reilly security and they try to be more, kind of inclusive in that aspect.

There's a bunch of other events, you know, DevSecCon, there's others, except they want to do that, they want to share it and it's still so hard, so so hard to get somebody to come in that says, "Hey, we had a failed breach," or maybe a successful breach on a failed data exfiltration.

They managed to get in, but they did not manage to get any data. Or even a successful one, but a near miss, something where we almost allowed them in. But it's just so scary to share these things.

Masha: Yeah. Or when it gets shared, the information story's so neutered of any valuable insights that it's almost as if it's not worth sharing at all. So, I hear you.

In my experience, that organizations that do have insight in that feedback loop, are much stronger for it.

Because if you can't admit that you have failure, the only thing it guarantees is that you're going to have a failure.

Guy: Indeed. Sweeping it under the rug doesn't help. So, with that actually, let's talk a little bit about your role at Salesforce at the time. Because I think that was a part of your responsibility there at the time, right? Can you tell us a little bit about what that team was or that role was?

Masha: As I was mentioning earlier, it had three components to it. The first one was general employee awareness. This was something that applied to all of the employees at Salesforce, which was about 25,000 at the time.

My responsibility there was making sure that employees were mindful of not clicking on phishing links, reporting suspicious activity, reducing malware infection rates, and being careful of social engineering attacks on the phone.

From there, my role evolved into focusing on how do we create the most effective, secure code in the platform? And that involved finding and fixing bugs faster.

The last one was customer support, and what I mean by that is, we had features in our product that customers could turn on, things like two-factor authentication or IP range restrictions, but customers were still given the choice to turn it on, even though it protected all of their data.

From a brand perspective, obviously, if something happened to one of our customers, it looked bad on the company, right? So it was in our best interest as well to make sure that our customers were as secure as possible, even if it was on them to turn on those features.

Guy: Yeah, I think probably even make the argument that it's indeed an aspect of the product, kind of the usability of your security solution. And in turn, whether people actually use the right secure settings and all that, is indeed a part of your goal.

All three sound really interesting to talk about. But just given our podcast, lets hone in a little bit on that second, on the secure practices. Tell us a bit on some examples of good programs or tricks, or whatever that helped out.

Masha: Let me frame a little bit about

one of the challenges that we wanted to solve, which is a challenge that exists across many organizations. And that was the ratio of security professionals to developers in the organization.

The statistics I'm going to have is not Salesforce specific, but will be roughly accurate to the industry. So, lets say there's one security product review person for every hundred developers, which might even be generous. Sometimes it's one to 200. I've seen even higher numbers than that.

But that one poor security person was responsible for reviewing the code before it got shipped, and signing off to say, "Yep, this passed our security tests, it's good to go. I know that hackers won't get into it." You can imagine what are some of the issues that come out of this, right?

That doesn't scale well. There's backlogs that get introduced, bugs are found way too late in the release stage, are sent back to the developers for fixing, at which point product releases are then delayed, which puts everything else into firefighting mode.

I really wanted to focus on, how do we solve this core issue? It was almost a process issue as much of an education issue, as much a security issue. It would be fantastic if all the developers everywhere knew everything there was to know about cross-site scripting, an SQL injection, and be on top of their security game.

There are some companies that absolutely invest in that training, but it does take a lot of upkeep and maintenance and making sure that there's a lot of training and hands-on training, specifically to the code base as it continues to evolve and that knowledge is shared.

In absence of that being a solution, which I actually think that if you are small, do that because it doesn't scale, but do that for as long as you can because you give the gift of enabling developers to take the security coding knowledge wherever they go.

The second thing that I think is worth considering is security, for better worth, should not be tacked on at the end, as an assessment, a "check the box" before it goes out the door. It should be part of QA, right?

The same way that you have quality and you have dependability and you test your edge cases, so you should also test for your security edge cases.

In which case, you may only need a couple of people on the team to know what it is they're looking for in that code. It could be your peer testers, it could be your QA engineer, making sure at least one person on the team understood what they were checking for and could escalate before it got too late, before things were already done and dusted.

What I focused on was identifying one security champion in every one of scrum teams. Most of them volunteered, some of them were voluntold at the time to dive into a security bootcamp.

So they understood, for their product, what were the common bugs that we saw? What were the best solutions? What were critical features that absolutely needed escalation to the security team?

This was, sort of themes along architecture and design, things that if you're designing anything related to crypto or authentication, please include the security team. There's definitely a certain line where being immersed in security full time is really required.

And then there's a point where you don't need the security team and empowering those security champions with the knowledge of basically saying, "I have tested all of our code for cross-site scripting and SQL injection and C-serve. These are basic known bugs with basics test we can run against it, and we know that it's good to go."

So having, essentially, someone who, traffic control for security, say, "Yes this needs escalation," "No, it doesn't," to make sure that the issues that needed to get escalated were seen by the security team, that the issues that didn't need escalated weren't seen by the security team and were handled as soon as it came up, so it didn't delay the process.

What we found is that teams with these type of champions, 100% of them shipped their code on time, or if they had delays, none of them were security-related delays.

So pushing it further upstream, to not having security be a blocker, was absolutely critical.

Guy: That sounds super useful. I guess it's, to an extent, it comes down to dissemination knowledge versus having tools to run it, or I guess maybe the counter-forward is, yes, starting point number one is, you're not going to make all developers security experts, it's just not going to happen, acknowledge that.

So you can train them and you should still level-up their expertise but they're not going to become the same professionals that dedicate their careers to it.

But, on the flip side, there is tooling and some automation for it, and I guess champions, fair to say, they kind of walk a line in between, around scaling the training to a subset of the individuals who have better either aptitude or interest, or others just wanting to devote more time to it.

How do you see, I guess in that sequence, you've got the broader training, you've got the champions, what's the utopia there of tooling in that ecosystem? If you fast forward to a perfectly handled DevSec-type setup, DevSecOps-type set up, in a few years time, how do you see that interaction of training and knowledge versus tools? Or I don't know if it's versus?

Masha: In any capacity, whether or not it's in DevOps or educating on phishing or malware or password use, the human brain is the most fickle thing to deal with. And so, getting people to care, to do it on a regular basis, when they are busy, when they are hungry, when they are hungover or tired,

there's just so many things in there that is such a complex and dynamic system that if you can solve it with tools, you absolutely should.

Training really should be one of your last resources, because it is hard to do. Retention of just basic audio/visual content is, at best, 20%. So even if you have amazing content, depending on how you present it, 20%.

If it's discussion-based or you teach people by doing it's 80% to 90%, but then you have this huge amount of effort where you have to engage people in discussions and that's an ongoing basis, right? It's not like you learn one thing and you know it forever.

So there's a lot of things fallible with training, and I think we over-use it way too often. Where possible, tooling absolutely should exist, and one of my favorite examples is password management.

We tell people, "Have a secure, unique password for every one of your sites," and for years, decades, we didn't give anybody any tools. All we said was, "Don't write it down on a sticky note." And yet it was totally impossible for all of us to remember this.

Now I don't even tell people about secure practices. I say, "Just please download a password manager and use it." That's it, that's the only thing I educate on. And that tool has solved things that education has never been able to do.

Same thing back to this conversation about secure development and secure DevOps, where possible, tools should absolutely be implemented. The trick with them and I think the reason why we don't see it more ubiquitously, is because many coding environments and code bases are very unique to every organization.

To get it totally right, to make sure that there's not false alarms, it takes a lot of on-site customization. It's hard, from a vendor's space, to come in and build a perfect set of tools for your environment that I can then go and resell to every other company as well.

The companies that I've seen do it best are the mammoth companies who do it, who build it themselves in-house, and build the tools custom, and then deploy it custom. And that is not a solution that most organizations can afford. But there are some vendors that get pretty close, but never custom.

Guy: Yeah, that's a good perspective. If you can't automate it, that's probably your most scalable, most efficient elements. But there's just so much to it, including their personal one.

We had Molly Crowther from Pivotal here on the show. And she talked about how at Pivotal they have cognitive psychologists as a part of their team, which is already kind of mind blowing on its own, right? And that they tried to deal with the fact that in general, they try to teach the developers to be very empathetic to users, very trusting, the whole set up.

And also, maybe the concept of DevOps and Agile, which they practice at the extreme, is very trusting by nature, very accepting of mistakes, and introducing the mindset or contrasting that with the mindset of not trusting the user. What if an evil user comes along and does something, was really quite hard. They're still battling it, you know.

They're doing the job there by trying to instill the notion that when you introduce those kind of QA tests, when you actually run those tests, how do you push aside for a sec your trusting nature that you've just been trained to do, and put a bit of an evil hat on?

I guess, do you have, when you've encountered that type of test and you want to get people engaged or think about it, are there, do you have some best techniques on what gets people engaged and how they jump in?

Masha: The best example, this might sound a little self-serving, but the best example based on my experience is actually the very first product that we built at Elevate, based on my work at Salesforce. What we did is introduce several hackers that are on the landscapes, so a hacktivist, a cyber criminal and government-sponsored hacker, and then we walk through a group dynamic.

Somebody, every individual, to go through and understand what it is they have access to, that is of most interest to one of these hackers. Then we ask them to put on the persona of exactly that hacker, and attack themselves.

You know yourself better than any attacker ever would, but then walking through a path of, "How would I be psychologically manipulated? Do I fall for reward or curiosity or fear best? And how could that be used against me? Why would it even be used against me?" Understanding that people who are motivated by this.

If you can do it in a way that is light-hearted, and in a way that has an element of fun, it cuts through some of the seriousness of, "Oh my God, I'm about to get hacked," or "Someone could actually break into my code or steal this data," which is real. Quite a reality.

I actually think that bit of a shock and awe factor, seeing yourself, or your code from the perspective of an outside, nefarious hacker, is one of the best ways to takeaway from a training, or from a lecture, or whatever the education methodology is.

A baseline sense of paranoia, and saying, "This is real, and I need to be vigilant, and I need to know when I should turn it off and turn it on. But I now have this level of vigilance that I can apply to certain situations, because I now know what I'm looking for."

Because if you just tell me "Oh, watch out for SQL injections," and you don't tell me why, or who, or what it is they're trying to get from me, the minute it's not that direction, but a different one, I won't see it coming. Because I'm only looking at the front door, and the hacker is going to go in through the back window.

But if you can teach me about the ecosystem around why I should even care in the first place, what are the methodologies and the tools that an attacker might use, and give me the resources to come to certain conclusions on my own, I am much more capable of defending myself and my organization. I am also capable of writing more resilient code, creating more resilient processes, and just having much more of a sustainable, secure ecosystem.

Guy: Yeah. That's a really, really good tip. I actually apply this in talks that I give around security, where I engage the audience in hacking a vulnerable application. What you describe right now is very broad and I can see how that can be applied to phishing, or to many others, but it can also apply to to just trying to break in.

Now I've got a vulnerable application, the audience might sort of shout out, "Now, you know there's a cross-site script in here, what might you try?" And, you know, I have this very unsubstantiated belief that, hopefully there's no hard data behind this, that probably helps with the retention as well. I guess they did say that 89% retention if you've got people engaged and doing. But you have to invest in building that up.

Masha: Yep, exactly.

Guy: That definitely sounds like a really good tip.

Masha: Sounds like you're already on it.

Guy: We talked about developers here, by nature of this podcast and the audience that listens to it, but you deal with training the broader employee population as well, people, act secure. How do you see the two differ, if at all? How would you say it's different to train developers versus to train everybody in the security?

Masha: I find training developers, actually to be much harder than regular employees because, sorry in advance for all of the developers listening to this,

there's a certain amount of arrogance associated with, "I already know this," or "I'm smarter than this." So it's really hard to get past that that shield of, "You're wasting my time."

In fact, it's not entirely a developer's fault because I have to say, most security trainings have been a waste of time for many employees and aren't respectful of people's time or intelligence. So, you know, I can't blame entirely. But there's a certain arrogance that comes from dealing with very smart, especially engineering types and sometimes that arrogance isn't well placed.

I'll give you some examples. I've run many hundreds of phishing tests over my career, and I have found that the top group that clicks on phishing links is marketing. With about one degree of difference of opening, clicking on phishing links, are developers.

Marketing, I feel, is forgiven because their entire job is to click on incoming emails and resumes and links, and I get it, that's fine. But developers feel like, especially if it's a well crafted attack, "I would totally see this, it wouldn't affect me. Plus, my machine's so locked down," without understanding the nuance of some really sophisticated pieces of malware that maybe directly targeted.

Again, "It won't happen to me, and if it does, I'll catch it in a second." It is that arrogance that absolutely gets a lot of developers into trouble, from, at least, my own tests.

I think things like phishing best practices, educating people on what not to click, in particular, very specific malware targeted to developers is something that is worth educating anybody on, but obviously make it role-specific.

I think that there is immense value in teaching developers specifically how you write better code as well. So, I think, unfortunately, developers might have two doses of security, but it's not just limited to them. So if you're in customer support, you need to be mindful of--

Guy: Sharing customer data

Masha: Exactly. Every role has additional layers of how it applies specifically to the data that they have.

Guy: Yeah, indeed. I can definitely see the developer aspects. I think maybe the crowd that is worse, in terms of confidence in their skills, is security. Security people might be kind of the next tier up there, although hopefully security consciousness, they're a little bit higher up.

Masha: Yeah. Knock on wood for that one.

Guy: Not always. And I would also add that the developers probably have a bigger sphere of influence. If you compromise a developer, you can compromise their code, which in turn compromises their users. And it's a big deal.

We've had some big attacks like that with XcodeGhost and with a bunch of Chrome extensions where malware is becoming a bigger and bigger issue. I can definitely see the preventing that education, or I can see the attitude keeping the knowledge out and subsequently the damage can be multi-fold.

Definitely worth doing the broader security education, not just the security coding, to keep developer's machines and keep themselves secure.

Masha: One of my favorite avenues of attack that I've seen, red teams particularly, people who are hired to break in.

They're good guys paid to hack in, but their favorite way of attacking developers is going through a lot of engineering docs.

There's a lot of things documented around, "This is how we check in code," and "This is our testing process." They'll hop on group channels, they'll compromise one developer's laptop, hop on a chat channel, scroll through history, where they'll be like, "Oh yeah, the credentials to this site is here."

So you're sharing internal, and thinking you're internal and safe, and you have your whole architecture and your process of how you check in code, or your onboarding docs, essentially for your new engineers. You download one of those, you go through some of your chat logs, you get all the appropriate credentials, assuming you're not handling them correctly which tends to be most of the case, you put those two things together, you don't need the most sophisticated hacker in the world to be able to to pivot from that point on.

Guy: Yeah, indeed. So I think that's, in general, this conversation has a really good point. When we talk about secure development or securing developers, I would say 99% of the conversation comes down to secure coding. But, an area that is very likely discussed is developers securing themselves and just securing their environments and not falling for those.

Because developers are early adopters. You install stuff from the web day in and day out, the number of development pipelines that pipe into sudo bash, which is terrible, downloading something from the web and just pipe it blindly into some shell script, is quite troubling. So some of those best practices around securing our own systems, our own environments, is really, really key.

Masha: Yeah

Guy: Happy to have the chat. I think there's probably room for whole sets of best practices around developers securing their environments.

Masha: Yeah, although, I would still say that my favorite tips apply to developers as much as anybody else, which is manage your passwords securely, back to the password management thing, and make sure that they're all different.

Please install two-factor authentication on every piece of software you have. It doesn't matter if your passwords get stolen, in that case.

I appreciate that it can introduce additional complexities when you're trying to test, but if you have two-factor built in from an API perspective, just find ways of including that, because that is one of the best ways to defend against hackers if you can create, you can have 2FA on as many applications, especially the most critical ones.

And the third one is more of a mindset thing, really, is know that your internal environment is not any safer than the internet. And so be careful what you post, and if you do post things, make sure it's locked down and the people who see it are only the people who need to see it and nobody else.

Guy: Yeah, definitely sound advice. I think you gave me a great favorite here to tee up, which I often like to close out with, the question around around the favorite practice, or a pet peeve, I guess, isn't it?

Would you say that's also kind of your pet peeve? What is your, if there's one thing that annoys you, that you want people to address, that you have sort of a security pet peeve, what would that be?

Masha: My pet peeve has two audiences to it. The first one is security teams who always say, "Users are the weakest link." I personally think that's totally inaccurate.

I think we as security professionals have done a terrible job of empowering other people, our employees, developers, general users, to know how to defend themselves in the organization and it's on the security team to do a better job.

But then the flip side of that, for developers or for any employee in any company say, "Well, security's not my job. There's a security team that is paid to go into work every day," that is where a lot of things go wrong as well.

If you remember the earlier thing we talked about, where there's one to 100 people. A security person can't possibly cover everything that's happening. They can't know all the things, the ins and outs of, what you look at and you do on a regular basis.

They don't know what normal is and not normal is in the weeds of your daily work. And so it's everybody's responsibility to say, "This is weird. There's something going on with my phone, my machine, my browser, and it's worth me escalating it and finding help."

Because the longer you wait, the longer you allow, say, an attacker to move around on a network. Knowing that everyone is a vital part of this equation is really critical.

Guy: Yeah, definitely. It's everybody's problem.

Masha: Mm-hm

Guy: Well, thanks a lot for all the great insights here. I think we can continue talking here for a while here, but I think we're already at time.

If people want to find you on the internets or check out Elevate Security's offerings here, where can they find you?

Masha: Our website is elevatesecurity.com, and we have a blog there that we occasionally post insights around the space. I'm also on LinkedIn, Masha Sedova, and on Twitter, @modMasha.

Guy: Cool. Well, thanks a lot, Masha, for coming on.

Masha: Thank you so much, it's been great.

Guy: Thanks, everybody, for tuning in and join us for the next one.