High Stakes in Threat Intelligence & Employee Accountability
The cybersecurity threat landscape is constantly evolving, but one vulnerability remains stubbornly consistent: human error. In a recent Right of Boom Cyber Call, hosted by Andrew, the discussion turned to a concerning trend—employers holding employees financially accountable for falling victim to phishing and social engineering attacks. The implications of this go far beyond HR and into the legal, operational, and strategic domain of Managed Service Providers (MSPs).
Attorney Eric Till shared a powerful real-world case: a CFO who fell for a phishing email was at risk of losing vested equity due to the resulting financial damage. The company claimed negligence as justification for clawing back the CFO’s stock options. This scenario prompts a critical question for MSPs: where does accountability begin and end in a breach caused by human behavior? Could the responsibility ultimately land on the MSP who failed to recommend stronger controls or training?
The conversation emphasized that while technical defenses like spam filters and endpoint protection are vital, the human element demands just as much focus—if not more. Nat, a VCISO, pointed out that MSPs have a unique vantage point due to their cross-client visibility. This allows them to design and implement smarter, more adaptive human-centric defenses.
To stay ahead, MSPs should implement foundational frameworks like CIS or NIST, conduct comprehensive security assessments, and deliver role-based security training—enhanced with real-world simulations to ensure it sticks. Monthly strategic check-ins with client leadership help keep cybersecurity top of mind, while regular social engineering tests provide real metrics on progress. Reviewing cyber liability policies is also essential to ensure coverage matches today’s evolving risks.
The core issue is liability. If an employee is blamed for clicking a malicious link, the question becomes: Who was responsible for preparing that employee? Was training documented? Were risks communicated clearly? And was the MSP proactive in advising on best practices?
MSPs must adapt. That means incorporating social engineering defenses into broader strategies, assuming compromise, segmenting networks, and preparing for lateral movement. It also means partnering with legal experts to update contracts and scopes of work to reflect today’s threat realities.
The takeaway? The line between user error and business risk is blurring—and MSPs are on the hook for ensuring their clients understand, prepare for, and mitigate those risks. By addressing the human element head-on, MSPs not only strengthen client relationships but also shield themselves from downstream blame and liability.
Guests
Video Transcript
And we'll give it three, give it like 10. Ooh, someone's reverberating. What happened there? Alright, so we'll give it 10 seconds and I'll go to chat and make sure everybody can hear us. All right. Welcome everybody. Happy Monday. First Monday in February. Can you, uh, hear and see us okay and, alright. Perfect. And for my, uh, resonant co-hosts and everybody, just so you know, with Restream, if you gotta type, just hit the pause, uh, the mute button. 'cause it picks up literally everything.
It's a real sensitive application. Um, alright, well, as we Good to see you, Ann. Chris, good to see everybody. Oh, Joe, how, how have you been? All right. Um, alright, so folks are coming in here and, um, let me set the stage here and we'll, we will get right on into, uh, into today. Alright. Um, so we, um, last week if you were on, um, I don't know if you, uh, net were you on as a, um, attendee last week, by chance? I wasn't able to make it last week. No. Okay. Really interesting one.
We did this, um, Microsoft teams, uh, vishing attacks, which seemed to be on the rise quite a bit. And, and basically what the ruse is, is that, um, you have a company that gets hammered with spam and almost in DDoS type, uh, ways of, of amount of emails coming in. And lo and behold, a teams, uh, or uh, someone on teams says, Hey, it's the help desk. We're here to help you.
And, uh, long story short, they, um, are able to, uh, get the, um, end user to download some either remote control to like a team, you know, team view or something like that. Or the Microsoft one that's really popular. I forget Quick Assist, I think it's called, I forget the exact name of it. But, um, long, long story short, we had, as we sent this out, one of our MSPs that watches us, Todd Schwartzman's all, Hey, we, we just dealt with that. And so, uh, that was last week.
So interestingly we we're gonna pivot a little bit. Some of it's related, certainly the phishing part is related. Um, but we're gonna start with Aaron first on threat intel side. Uh, big transaction, um, kind of made me scratch my head as I saw this, that you have MasterCard, um, buying recorded future. Um, and so, you know, I don't know if it means anything, but I really wanted to ask Aaron about this.
Someone that, uh, created the threat intel protocol, uh, many moons ago with a few other, other folks from Mitre. Um, you know, the fact that we're seeing financial services companies getting into the threat intel space. Um, could this mean, you know, that they're gonna step into the cybersecurity space knowing they have access to literally millions of businesses and, you know, telemetry there. Um, and then we're gonna pivot over to Eric being our guest, uh, with net finishing.
But over in Eric's world, we wanted to kind of, um, talk about the fact that there have been rumblings, real rumblings, and we can't share sources, but the fact that we're starting to see employers take action in the event of, um, basically negligence of social engineering and financial damages by employees clicking on phishing links and the resulting actions of damages to those companies. And, and is this a trend? Uh, let's look at the legal side of this.
And then lastly, uh, we'll go to net, um, and get her take as a, as a current ciso, but for years a v ciso, um, sitting with customers and advising them on policy and framework, et cetera, and how that all plays into, you know, what they should be doing with the clients. So let's start off with some intros. I'll start off with ladies first. Nat, wonderful to have you with us. For those that don't know you, welcome and please share a little about your background. Thanks, glad to be back.
Um, so I've been in it for over 25 years and I've been in MSP for the last 18. Um, I started by, um, opening an MSP before we called it MSP an IT services company. And that's when I fi found how much I loved the business side of it specifically. The better I understood the client's environment, their business, their struggles, the better I could advise them technologically. So I've stayed in that space along with being a project manager, service desk manager, lots of other hats as well.
But as VCIO and then vcso, um, I live and breathe security and compliance. Awesome. Thanks for joining. Na, really good to have you. And, uh, Eric, I'm gonna have you go in the middle 'cause I wanna ask Aaron something at the end, but obviously a lot of folks know you. You work with a ton of MSPs today. We're gonna be our, in essence, our guest 'cause we're gonna ask you some stuff. But, uh, welcome and please, anybody that may not know you. Yeah, thanks. So, I'm, uh, Eric Till I'm an attorney.
I've been practicing for 26 years or so, and for the majority of my career, it has been, uh, on behalf of MSPs. Um, first as, uh, as I was a partner in an, uh, in an MSP that as, as net mentioned, wasn't an MS. P back then, 'cause MSPs weren't a thing back then, but a, a IT service provider that we were very fortunate to, uh, have been able to grow to about 240 employees before exiting the, uh, several years ago.
Um, and then I went on to serve as the general counsel of the, uh, the company that bought us a company called Logic, a global, uh, IT service provider. Um, today I operate my own law firm where I represent primarily MSPs and those companies in the MSP system, including software companies, et cetera. Cool. Cool. Eric, your mic's a little in and out, if you could just take a look at that while Yep. While we go to Aaron. Aaron, no one knows you.
Uh, Eric, maybe mute just for a second because I'm getting variation. Uh, Aaron, uh, welcome back and it's great to have you as always. Thanks for joining us. Thanks for having me. Yeah, of course. Little do you wanna give everybody a quick overview of? Sure. Hey, I'm Aaron. I'm, uh, CEO of, uh, roost an automation platform. Uh, prior to that I was CEO of PERCH security, um, a so SIM solution for MSPs.
Uh, and then prior to that, um, I spent a majority of my career in cybersecurity and financial services. Um, my last step was focusing on, uh, cyber threat intelligence automation. Yeah, Aaron. So a few quick things. One, um, have you integrated deep seek into roost? Um, I wanna, Yeah, it's called Deep Roost. Deep Roost. Okay. All right. Um, and, um, how is, uh, flow going?
And for those that don't know about this vendor agnostic, uh, event, um, why might somebody that is thinking about automation or whatever, just give, give 'em a sense of what flow is. I really wanted, uh, in the cybersecurity space, we have, uh, uh, pretty vendor agnostic. Uh, RSA very vendor agnostic black hat, um, style security conferences. Uh, we don't have anything like that in the automation space when it comes to MSPs. Um, I was gonna say, what about right? A boom? I thought we had one.
I'm kidding. Um, and I really wanted to create that, uh, vendor neutral, um, automation conference for MSPs. That's why we didn't call it roos Econ. Um, we called it Flow. Um, and last year, uh, flow was, uh, uh, sold out for weeks in advance. Um, this year we're planning for double the attendees. Um, we sold out sponsorships and we're super excited. Um, one of the, uh, things to, to do if you, um, haven't been to a flow event or, um, you like to, uh, kind of hone your public speaking skills.
Um, so put in a call for papers for flow. The UR L is MSP flow events. Um, one of the best things you can do in your career is public speak. Um, and there'll be hundreds of MSPs out there wanting to see you succeed, um, and maybe your very first public speaking event. Yeah, I think it's really cool. Um, it's interesting, we have net so her pre, uh, COOI forget what, I forget what, um, Jude is these days.
President, C-O-C-O-O, um, who, and, and I can vouch for the vendor agnostic portion of this 'cause, uh, Kraft Kennedy didn't Bruce ca uh, sorry, Jude from Kraft Kennedy, um, has built his own automation platform, but came and spoke his and his, his, his, uh, presentation was phenomenal. Absolutely phenomenal. So, um, anyway, I just wanted to, to give you a, a plug for that, Aaron. Anytime it's vendor agnostic, I think it's awesome. Okay. So Phyllis, I'm gonna let hand it over to you.
Uh, hey, Jude's here. Wow. Um, okay. Phyllis, I'm gonna, um, let you, uh, ask Aaron some questions on this, uh, whole threat intel side of things because I thought it was really fascinating. Yeah, sure. Um, so Aaron, um, you know, before we, uh, talk about the MasterCard acquisition, as Andrew said, you, um, you know, one of the key, um, creators of, um, the most prominent threat intel, um, protocol.
And so just to level set everybody, um, you know, can you tell us what really is threat intel sharing, um, why it is so important, um, but yet why we don't see too much adoption, um, in the MSP space of threat intel platforms and perhaps, um, you know, some threat intel sharing. Uh, there's so many moving pieces there, and I think one of the easiest ways to understand anything in the cyber realm, um, is to try to imagine it outside of the cyber realm.
Um, because so much of what we do in cybersecurity is hidden behind marketing buzzwords, it makes it difficult to understand what it is people are actually doing.
And so if we wanna de cyber, what is cyber intelligence, um, compared to like normal physical intelligence outside of the cyber world, um, you have a threat actor who thinks they may be entering a building, um, once a day wearing a specific outfit, and you're sitting across the street in your car with binoculars 24 hours a day, uh, waiting to watch that person go in. Uh, that's the same exact thing that we're doing in the cyber side, uh, for cyber intelligence.
Um, one of the reasons why it may not be heavily adopted in the MSP space, uh, is because you're not regulated to do so. So if, uh, uh, regulator or maybe external auditor goes into a financial services company, they're gonna say, okay, show me your cyber intelligence program. Um, and a lot of threat intel platforms were purchased just to tick the box, uh, hey, look, I'm doing the threat intel thing, I bought this product. Right?
But the companies that are really doing threat intelligence have a team. That team could be one person, that team could be a hundred people. Um, and they're sitting around waiting and looking at what we call observables or observations of things that are going on in their environment or others, um, documenting that. And that's when we talk about threat intelligence protocols, um, the documenting of what we saw is what we're sharing and those threat intelligence protocols.
The, um, the another reason why MSPs may not be adopting beyond just you're not regulated to do so, um, is because 99% of a threat intelligence person's work effort, um, may not end up as an incident. Um, but yet that 1% or less, uh, may end up saving, you know, the entire industry or their business. Interesting.
Yeah, no, that's very, um, true and very well put, which is why, you know, we're always talking about false positives and false negatives and all of that, and trying to clean that up, um, which is like you just said, the majority of the job. Right? Yeah. Um, so let's kind of pivot over now to, um, another one of your areas of expertise, financial sector. Um, and so why do you think MasterCard, um, acquired recorded future, um, for a cool $2.6 billion?
And what do you think this means, um, for cybersecurity in financial sector? Um, I, the, there's probably multiple value points, and mind you, this is all my hypothesis. I have no evidence in any of this, right. But, uh, they probably offer, um, source some sort of dark web alerting, uh, for their customers. Um, and so there's probably, um, a lot of cost savings for them there, especially if they own the company doing the dark web alerting.
Um, a lot of times when they have an incident of, of their own and they've disclosed it, what do you get? You get free dark web alerting, right? And so that could, that further decreases, um, the cost of an incident, um, on their side. And then they do have a really good threat intelligence team, um, at MasterCard. Um, a lot of what they're trying to stop is fraud related.
And since, um, recorded Future is doing a lot of, uh, man, the dark web term is such an over hype marketing term, but it's doing a lot of like, uh, tour network monitoring, um, and other invite only communities, um, that the fraud people use. Um, since they're in those communities, um, their threat intelligence team can try to stop some of the fraud, um, before it gets too big, um, using the data from recorded future that they own further saving them more money.
Um, could we see, uh, more financial services companies do this? Um, I am not, uh, privy to the fraud budgets of all these companies, but I feel like if you thought whose budget within the bank paid for it, it's probably the fraud budget, not necessarily the, uh, cybersecurity budget that paid for it. Interesting. Phyllis, I was, I I did ask Aaron a friend of both of yours. I did ask Sunil, Sunil, you, um, who will be at, by the way, appearing at right a boom as a guest. Oh, cool. Um, yeah.
And Aaron, I asked him like, what is his take on this? As you know, the former chief data sciences, chief security data scientist that Bank America, if I have that term correct, but he said that interestingly, capital One bought a, um, this Kubernetes security firm actually as well. So he said this, there is a, and, and MasterCard had purchased a previous one. So he said it's not, um, that it hasn't happened before.
Um, but, uh, that, that, um, whether this, you know, becomes something they then turn into an offering, um, uh, is is to be seen. Yeah. It's one of the questions there from Keith, uh, uh, or statements, most MSPs cannot deploy complete security and compliance baseline. Uh, I'm not saying that MSPs aren't deploying security, there's a huge leap between, um, providing standard preventative and detective controls, um, and running a cyber intelligence program. Right.
Two completely, um, different things. Yeah. Yeah. And we saw that quite a bit, Aaron, in the days of perch. Right. You know, just getting, trying to get MSPs to share threat intel and, you know, we did some experimental stuff with that and it's, it is, is a, it is not an easy thing to do. Well, I mean, what's, uh, the, the altruistic nature of threat intelligence as a community, um, is really great. It's an awesome story.
You know, if you can get one MSP to do a full incident response to an incident that they have and then document their findings into, uh, a structured threat intelligence document that they could then share with the rest of the MSPs, you know, we used to call that one company's incident is another company's defense. Right? Right. But that, that, um, requires an MSP to wanna share all that data and to run a normal, uh, type of incident response that would create threat intelligence documents.
Yeah. What do you see, Phyllis, even in the MSIs sac with all the SL tts, I mean, there's all, you have traffic light protocol. Maybe share a little bit about that just from your perspective, where you guys house that. Yeah, and I, yeah, I, it's so funny, I was about to ask Aaron about financial sector the same thing.
Um, you know, I would say, um, the nice thing about being part of an ISAC just in general is you do have that legal protection of when you share something and when you share, for example, an IOC or something, you, you're protected that you know, someone can't come at you or, or whatever. I would say, um, we do have some sharing amongst the SLTs as far as like, this is how we responded, this is what was helpful, this is what was not helpful.
And they do try to showcase that in these monthly meetings or in their annual, um, ISAC conference. But like Erin says, um, you have to be willing to do that. You know, there is kind of, um, this tendency to not want to air your dirty laundry. However, if you're already been in the paper, then I think a lot of folks will be willing to do that. And typically, um, you know, it's the ones that already like, kind of had a quote unquote success story, um, that, um, like to be showcased.
So, um, I think that it would be great if we did that in the MSP community. You know, we have, like Eric has done that, uh, um, you know, a little bit at right of boom, right? About, you know, his experience and how ill prepared he was or how he helped his friend who worked for, um, you know, a major company and helped them kind of recover from that event.
How, but that, again, is a, um, someone just speaking to it versus what Aaron is saying is, you know, let's have a standard way in which we report these out so that people consume that. And then maybe you can say, okay, in, in a more methodical way, this is how it happened. This is what they needed, this is what they didn't have. Maybe that can help inform my program as well as if you did have that kind of program where you can disseminate it in such a way.
You know, the reason why someone's compromise becomes my defense is because I get that information in a timely manner. I can break it apart pretty quickly. I can figure out where, what the fields I need to consume right away, and then how I can inform the defenses of my network. And, you know, working with financial community, which in some sense you see financial sectors pretty more mature in some sense with cyber because of the regulation.
And of course, it's like the big banks are, are better than the smaller banks. What did you find there? If you can, if you have any stories? Um, so it, it all starts to, instead of looking at the end, look at the beginning, right? So, um, there was some, and I was trying to Google it, but a presidential directive that created the FS iac. Mm-hmm. Um, a long time ago, 15, 20 years ago at least.
And what the FS IAC is, is the financial, um, share financial services, information sharing and analysis center. Um, and it is a cyber intelligence, uh, broker, I guess for the financial services industry. Um, but it's also a community. 'cause they figured out that, hey, none of the banks are gonna help the other banks unless they're friends with each other too. Mm-hmm.
Um, and so, but what happened was the, um, regulators found out about the FSI, SAC started asking every bank, Hey, are you a member of the FSI sac? And that period lasted for, uh, a number of years until they realized, hey, there's a product that the ISAC is releasing. Oh, that product is cyber intelligence. Maybe we need to ask the banks what they're doing with it. Um, and then that was really the, um, growth of the, of the industry basically for threat intelligence.
Um, it's, it's interesting, like I would love to see a vibrant threat intelligence sharing community within the MSP space, but it's gonna be so difficult because, you know, if you think across all the financial services companies out there, maybe there's 5,000 threat intel analysts. Um, and we take the 60 plus thousand MSPs out there, how many threat intelligence analysts are there? Not 5,000, um, maybe 50, maybe five. Um, and so it would just be a really small community.
Um, and that's not negative to the MSP market. I mean, look at healthcare. Healthcare has their own intelligence sharing Yep. Comp, and it's a very vibrant isac. Um, but there's fewer folks in healthcare doing threat intelligence and financial services. Uh, right. My feeling is maybe there's 500 people, uh, in the healthcare industry actually touching threat intelligence with their hands, um, every day. Yeah. Um, yeah.
But I think it's, um, a great story to just say, like, when you go, when you go back and say, how did it get started? I think part of it is just get started. Right? Yeah. So, um, and, um, you know, some of the players are going to share more and some of the folks are going to consume more, and that's okay. Um, you know, we, we expect, for example, in the MSI sac, those local tribal and territorial governments, we have SL tt, state, local, tribal, and territorials.
Just like in the financial sector, the smaller banks are going to be consuming threat intel from, you know, the states. 'cause they're, they're bigger, they're larger, they're more well funded, so they'll have more resources. So, all right. Well, let me move on to my, my final question to you, Erin. Um, so what do you think, um, the effects of this acquisition will have on SMBs and in particular, those that are relying on MSPs, um, for cybersecurity?
Um, I mean, this is a, a threat intelligence player. Um, the biggest impact for this specific company is dark web monitoring, I guess, for MSPs. 'cause that's, uh, what they would be offering the most from a vendor like this. Um, if all the dark web monitoring, um, companies that were viable got purchased by a financial services company, sure there'd be an impact. Um, dark web monitoring is starting to become more commoditized, um, these days. So I'm not necessarily all that worried.
Um, I do think the lesson is maybe not the acquisitions, um, that the MSP market should continue to focus, um, on just learning what the financial services market's doing in cyber intelligence, um, and in other aspects of cyber in general. 'cause we tend to find ways to SBIs these products and get them in the hands of MSPs over time. It may not be a year, it may not be five years, it could be 10 years from now.
Um, but if you're familiarizing yourself with the types of tools and controls they put in place, um, that is a great lesson. Aaron.
Aaron, I'm just curious though, this is totally off the cuff, but now that you have so many companies running roost, could you share, you know, with automation, you know, if there was a, I don't know, you'd subscribe to Intel 4 1 1 or something, could, could you share, you know, easily, um, hey, for all everybody running Roos that has, um, some type of integration into their SIM or some type of integration into their, you know what I'm saying, into some security platform? Yes.
Um, you're gonna get me in a risk grant. Um, it's not a technical problem. What's that? It's not a tech, it's not a technical problem. Oh, okay. Um, it's a, um, risk measurement problem. Financial services is really, really good at measuring risk. Hmm. Um, that's why only some banks go outta business and not like all the banks. Right. They're really good at measuring risk and understanding risk, and they have risk teams.
Um, the biggest hurdle for us to automate, um, uh, sharing of observations, um, is really gonna be the risk story to MSPs that it's okay to share these observations, that it doesn't risk their business. It doesn't, um, risk their customer's data. Um, it doesn't, uh, uh, risk their brand. Um, and so we'll spend six months, uh, maybe building the technology, but we could spend, you know, six years, uh, trying to get the, uh, MSP market to, to realize it's not a risky thing. Got it. Got it.
Very cool. Hey, um, I know Aaron, you're gonna transition to Eric. I just have a 30 62nd question for na na. Um, we talked about ISACs, you know, that they're prevalent in financial services s ltts, for those that don't know, SLTT is the state local, um, territorial, um, that, uh, so these are your municipalities, government organizations, um, uh, uh, Indian reservations mm-hmm. Et cetera, et cetera, that share.
But, uh, net have you interacted, you know, in supporting a regulated company with ISACs as a vcso? Um, I'm just curious. Yeah, and a couple of different, um, verticals. Um, and I think a lot of it depends on the size of the client because it goes to staffing and depending on the size staff that they have, the amount of threat intelligence that they can ingest and have, and then analyze and decide if there's anything actionable with it, is going to vary from one entity to another.
It's not an across the board kind of a thing. And it's not really up to the MSP to dig through that data and dictate what each client needs to do, because it's all ev every client is unique, the risk tolerance is gonna be different. The way they run their business is different. So, um, I think it can be a valuable tool that you work together on, but I don't think the ownership should fall to the MSP for that reason. Yeah. And a lot of times it's their line of business app.
So like, it could be either core banking app as an example that MSPs aren't necessarily familiar with as well, so mm-hmm. That makes a lot of sense. Alright, Aaron, um, I'm gonna put you in the co-host role, uh, grilling Eric, but this is really fascinating. This one, I'm, I strap in here, folks. I, I, I find this, uh, really interesting, uh, what Aaron's gonna be chatting with Eric about. Hey, Eric.
So is there any chance an employee's involvement in a security breach could impact their eligibility for their stock options, bonuses, or other performance based comp? If, if you had asked me a month ago, I would say, no, there's, uh, there's no chance un until this, uh, this very issue came walking through my door, um, about three weeks ago. And I'll, I'll, I'll tell you the story.
So, um, one of my clients, um, their CFO, um, reached out to me, you know, not, uh, with an issue that, that his company was having, but, but rather it was a personal issue. And I think we touched on this a little bit at the, uh, on the last I recall seconds or so. But, but he said, Hey, and I, I got a story to tell you, and, and I've never, uh, I I, I've never experienced this before. So he tells me this story about his prior employer company that came from, he was their CFO as well.
Um, it was a startup. Um, and a lot of his compensation, like happens with, most startups came in the form of, of equity of some sort, whether it was stock grants or options or, um, or NSOs or whatever they were. And he said this, um, this prior employer of mine is not letting me exercise my options, right? I have these vested options. I've gone into the system, I've tried to exercise, and, and they just won't let me do it. They're just, they're not, they're not accepting it.
They're not approving it. And when we really dug and dug and dug into the issue, um, it came out that the CFO was the victim of a phishing scheme when he was employed by this, uh, by his prior employer. And he clicked on a link that he shouldn't have. And the, the, the threat actors got ahold of his credentials. He's, they're still not sure how or why or where, but, but they did. And, and they were able to log into various financial systems in the company, including their credit card systems.
And this, by the way, it was a payment processor, uh, was the, the company. So a lot of money going, going in and out. Um, and the threat actors were able to, to steal, you know, almost six figures worth of, of cash and marketable goods from, from this company. So, fast forward six months or so, the, the, the root of this issue is that his former employer is, is claiming that there are, quote unquote financial irregularities that are stemming from this, this cyber attack, this phishing scheme.
And because of these financial irregularities, they want to claw back his stock options, um, not only unvested stock stock options, but vested stock options as well. Um, and it is in, in, in my period, you asked the question, did I ever foresee it? No. Um, and I think that it's a really, really, uh, slippery slope.
Um, you know, if you're gonna start holding employees, uh, responsible for these things, and I, and I can't dive into the, the details here, but it doesn't appear to be that there's anything, uh, anything malicious happening. But if you're going to allow a company, so the court is gonna allow a company to start clawing back stock options or other equity grants from employees who fall victim to phishing schemes, um, it's an incredibly slippery slope. Slow.
So it sounds like this is, uh, folks are trying to figure out if this is accidental or willful, uh, misconduct. Um, yeah. How does that differ when it's a cybersecurity breach or social engineering? So I, I think it's, you know, whether it's it's, you know, negligence or gross negligence or willful misconduct or, or what have you, um, I think that if a case like this ever gets to trial, I think it's gonna be important.
And by the way, this, this really puts the human face right on, on these types of deals. Because if you, if you really think about it, um, you know, let's say this was a later stage company, right? And, and, and maybe these stock options are, are worth millions, right? And the, the, the, the equity agreement that that is po that that goes along with these stock options says that, you know, if there are financial irregularities, the company in its sole discretion, right?
Which is almost a discretion that is, that that is beyond review and its sole discretion can, can claw back these options. So, you know, as MSPs we're thinking, well, you know, we've gotta keep our company happy, or our clients or customers happy. Well, now does that per perhaps open up a cause of action, you know, uh, from an individual employee of the customer against the MSP that themselves for, for something that may have gone wrong?
But to answer your question, Aaron, um, you know, you look at the differences between simple negligence and, and maybe gross negligence or willful misconduct, right? The, the, the best way that I can describe it is, you know, simple negligence is, is forgetting to lock the door, right? And maybe gross negligence is for getting to lock the door and leaving the door wide open with a spotlight on the door that says, come steal my stuff. Right? That's, that, that, that's maybe gross negligence.
And I think that it is foreseeable, at least to, for a company to hold a, an employee responsible, um, for tho those higher standards, right? Willful misconducts, gross negligence fraud, right? But usually, Usually the, the remedy there is discharged, right? If it's really, really that bad, then maybe the employee loses their job, right? Maybe they're terminated, whether it's, you know, for cause or without, cause we can argue that, but, but historically that was the remedy.
You know, if an employee does something really, really bad, you terminate them, right? In this case, it's a former employee. Um, arguably what he did wasn't so bad. You know, the, the sec the, the company didn't offer security awareness training to its employees, for example, right? So, so I think that there's maybe even some, uh, some culpability there as well. Yeah. Eric, Aaron, could I just Yeah, go ahead. Yeah, Bob's question, is that where you're going? Yeah.
Bob was saying, Hey, who didn't authorize the, you know, the purchasing of the solutions that could help prevent this? Um, at the same time, I think the other, and the other extreme is scarier though, what, you know, you're maybe you've got a ton of social engineering, cybersecurity education that you're pumping out to all of your employees. Like I'm thinking about my own team, and it seems like almost every week they're doing something security awareness training. Yeah.
Um, and, uh, to imagine that they're still gonna fall victim. Um, and I am to blame, even though I've trained them several times per week. Yeah, Yeah. And, and, and, you know, you, you're training them, right? And, and that's, and that's important. You know, you, you probably have an Ms P that is, uh, looking after the, the health and safety and security of your networks. Um, you know, I, I think that there's a, as as lawyers like to say, it's a very fact sensitive issue, right?
Um, you know, is the employee doing the right thing? Is the company doing the right thing? Is the MSP doing the right thing in a situation like that? And, and assigning blame, right? Usually if we're doing it a, in a, you know, anyone, if any MSP is doing an investigation into a phishing attack, you know, the, the person is usually nameless and faceless, right? Oh, someone clicked on a, on a link, right? No one really cares who that someone is.
Well, all of a sudden I think we're gonna start to care about who that someone is. Aaron, just curious, from as a multi, you know, multiple entrepreneur that's investing in these types of things, you know, security awareness training, phishing simulation, like, how do you feel like, you know, if you're, if, if you know, it's one thing, you know, if it happens once or whatever, but how, how do you feel, I guess, as an employer, you know, if there's seemingly like, Hey, well I don't care.
It's Aaron's money, it's Ruth's money. I don't, why do I care? Like, I'm just curious from your role and perspective. I mean, it's just, uh, this is where it's kind of good to have been in the cyber intelligence, um, market, uh, before becoming an entrepreneur. And that is, uh, we're gonna train 'em all. Mm-hmm. Um, multiple times per week.
Uh, it seems like they're, I've got more questionnaires going out to the team, um, but at the same time, I have to operate like, um, every endpoint my employees used are compromised and I just start there. Oh, wow. Okay. And how do I, how do I run my business? Um, with the assumption that, uh, uh, every computer is compromised and, um, it's, uh, and this, these are my opinions and the things I do, I'm not telling other people, uh, to listen to me or do the same things.
Um, and so it's defense and depth, right? And so people, um, people are annoyed to use Max and Linux boxes. But you know what, when I was in cyber intel, we shared very little Linux and Mac os cyber intelligence or observations, um, because that's not where the threats were, right? And so, defense and depth, I'm gonna use an operating system, that's not what the threats are targeting defense and depth. I'm gonna have, you know, minimal privilege, um, as much as possible.
So we're gonna train 'em, but we're also gonna assume that the training didn't stick. Got it. And then segmentation and things like, basically as much as you possibly can do, assume, like you said, assuming everybody's compromised. Yeah. Interesting. That is, you know, that is interesting because, you know what I was just thinking of, and Eric, I'm curious what your thoughts are.
You know, we see this legislation that if an organization, um, doesn't implement a cybersecurity framework, reasonably, we've talked about that before on the cyber call, that, um, you know, you can be sued. So the idea is if you reasonably implement a cybersecurity framework, you, um, get some indemnification from being sued, or you can only be sued up to a certain amount.
So, um, here we're kind of like, before we're like, oh, hey, hey, person worker, if something bad happens, it's okay, just report it. 'cause we didn't wanna have that fear, but now we've slung this other way where it's like, oh, what? You know, and so I wonder, um, and we're talking about, hey, but that, that enterprise maybe didn't provide training. They didn't do this other, these other kind of best practices. What is it?
Could a, could an employee say, well, you didn't put in the appropriate controls to protect the network from dumb user. Like, could that be something that, you know, someone uses in, you know, to defend themselves? Because I mean, maybe it wasn't willful and, and are they still gonna get in trouble? Are they still gonna get fired? So they could, the the the, the answer there is that yes, they could, right?
And, and when you look at things, and yes, you can't, you know, most employees are equitable employees. You can fire 'em for any lawful reason, but, um, but when you look at things like equity grants and things like that, you look at language in there that says the employer in its full discretion if they determine that there's financial irregularities, right? And that's, that, that's really, really tough. But you look at, you take this through to its logical conclusion.
And if, if I'm gonna go be the CFO of some big company somewhere, and I know that I might have millions of dollars riding on the, my employer's, the health and safety of insecurity of my employer's network, right? What am I gonna do? Am I gonna start asking all sorts of weird questions, you know, in the, the, the pre-employment process? Get myself comfortable that my employer has the proper controls in place. Right?
You know, it, it seems that, that that might be where we're going here, which is a, a really ridiculous outcome. Right. Right. Okay, great. Yeah, thanks for that. So, um, net thank you for, for being here and offering your perspective on this. So, um, from your perspective, what unique advantages do MSPs have when acting as V CISOs to help clients develop these security policies to help protect, um, their business and of course their employees?
I think MSPs have a very unique perspective that internal, it just doesn't have. And that's that MSPs, by their nature see a variety of different environments the way the business is run. Um, and they can gather a whole bunch of informal case studies that they can then use to help build the basis for their recommendations. Um, and an internal IT team generally won't have that same type of experience, just like an internal CISO wouldn't.
So a VCSO would work with multiple clients, usually in different industries, usually using different frameworks and, um, be able to collect a variety of different information. So they could also say, well, I have this other client and they did X, Y, Z, and it worked well or it didn't work, so let's not do that even though it was your idea, here's why we shouldn't do it.
So I think they come with that sort of, um, well-rounded information that you just can't get if you sit in one seat in one company and only see one environment. So, um, how can MSPs help identify gaps in their current cybersecurity policies? Especially like the topic today of employee liability and legal risk management. And I'm curious, like, you know, just from your personal experience, how much of that have you done? Uh, first is to align to a framework.
First and foremost, the MSP shouldn't be dreaming up these things. We have standards out there. We have industry frameworks that work like CIS, um, even if you have a compliance like hipaa, it's not a bad idea to also incorporate CIS because HIPAA doesn't cover everything. PCI doesn't cover everything, et cetera. So putting a framework with a compliance to me, that's my way to go because you're just gonna get a more, more well rounded coverage.
Um, also make sure you're doing a security assessment. I think a lot of organizations kind of skip that step and they're like, well, we do an onboarding, we gather some information and we start making recommendations. But if you don't know where the all the gaps are, how can you really prioritize them? And how can you give a really good recommendation of what a security roadmap should look like if you don't have the full picture? So I would definitely start there.
Um, and then second to that, because we are talking about specifically our employees actions, um, as an MSP owner, consult with an attorney that specializes in employment law, especially if they understand the MSP field and have them review your policies and procedures. And especially if you're offering these to your clients, you don't want a client to get into a sticky situation and say, Hey, the MS P gave that to me right now, the MSP's on the hook.
So make sure you go through that process to vet out those policies, those procedures, and get, ask that attorney to identify any gaps that they may see or any risk that you as the MSP may not have seen, and help to mitigate those before you make those recommendations to clients. I have a, just another follow up question. We've talked about, you know, regularly checking in with your clients. So as a vcso, how often do you check in with clients? Is it quarterly? Is it every six months?
Is it yearly? What, what should that cadence be? So it's not a one size fits all. And I will say the least amount you should have some meaningful conversation with your client is once a quarter minimum. Ideal is monthly, but it always is going to depend, you know, on the relationship with the client, um, how they're prioritizing the role that you're doing for them and that kind of stuff.
But, um, ideally you wanna have a monthly touch point where you're having conversations, you're keeping things moving along, you have accountability to make sure you're doing what you're supposed to, they're doing what they're supposed to, and things keep progressing. 'cause if you don't show progress, you're not showing value. They could turn around and say, what are you doing for me? Right? So you have to constantly put in front of them the value you bring.
And then usually my rule of thumb is once a quarter, you should have a bigger conversation, whether it's about your security roadmap or whether it's about the results of a recent pen test or, you know, doing a tabletop exercise. Whatever it is, make sure that they see that value multiple times throughout the year and you're doing something that's making a difference, not just checking a box. Okay. No, that's good. I mean, the monthly thing is, is good to hear as well.
I just have one last follow-up. We talk about also having like, um, senior, um, buy-in from your customer. Do you recommend that on the monthly? Is that on the quarterly? Just just so people get a feel for, hey, who should be involved in these meetings?
That is, I love this question because so many times, either in A-V-C-I-O or VCSO type of role or talking to the wrong people, you're talking to people who can say no, but don't have the authority to say, yes, these are, uh, conversations about running the company. It happens to be in the context of security. Um, but you need to talk to your decision makers.
So I think you should have your decision maker included on all of your vcso calls that are related to anything pertaining to strategy, talking about your security roadmap, anything like that. Um, because they, well, they're also going to have information that people below them won't have. Like, you know, where's the company going in three years?
How do we align your security and your technology to help get that client there If we don't know where they're going in three years, and your IT director's not gonna have that information. Okay. Awesome. Thanks. Over to you, Eric. Great. Thank you Phyllis.
So Nat, you know, Erin and I talked a lot about social engineering attacks and the effect they can have on employees, but can you talk about some specific strategies that MSPs can implement to, to improve the human element of cybersecurity, to reduce the risk of, of social engineering attacks?
Because, you know, I asked because like, like Aaron said a few minutes ago, you know, his, his employees and he's constantly being inundated with, with security awareness training, not just every quarter, every year, but every week. Um, it probably feels like every day. Um, so what exactly can MSPs do it, you know, knowing that between security awareness training and, and uh, and, and phishing simulation platforms and things like that, they just don't seem to be working 100%.
Um, and I think the challenge is that one, people are busy, right? The, the staff that are clicking these links that they know they're not supposed to, they're so busy 'cause they have their other job to do, right? They're, they, and besides, they have to go skim through all these emails, 50 million emails we get every day, right? So it's a lot for them. And security's not, they're not security experts on top of it.
So, you know, they're hired to do a specific job and this kind of, if it's not natural for them, it can get in the way. Um, and I think what makes it more challenging is that the threat actors study human behavior. They try to, uh, manipulate people because they're humans, right? We are, we all suffer from the human condition. And, you know, for all of these reasons, the threat actors have gotten really, really good at understanding human behavior and taking advantage of that.
So I kind of turn it on its head. I don't think we should depend on a tool, right? I think having a security awareness training tool is important for lots of reasons. Doing phish testing is important for lots of reasons, but that's not where it ends. And I think we need to stop listening to vendors who are selling us this, who say, this is all you need. Our platform can be the thing that you need to stop phishing. It's not, there's so much more because it's the human element.
When people are, are trained in a situation to behave a certain way, they behave that way in that situation. So when they know something is training, they're thinking about security at a higher level, it's forefront in their day-to-day lives when they're doing their primary role, security's not at the forefront anymore until something triggers that thought. So, uh, what MSPs can do, like first we'll talk about technology, right?
One is making sure they have an email filter in place that has sandboxing so that it can test all attachments and links before they get delivered, right? We all know this part. Um, inbound and outbound, that's super important in case if somebody is compromised, they're not sending out the crap that they just got. And two, making sure that there's access controls to websites that they can go to in case if they click on something, it gets evaluated before they get there.
Um, third one, um, using your security awareness training platform, but kick it up a notch. Do role-based training. Everybody doesn't get the same training. Certain people in certain roles are going to have different attacks come toward them than others. And it's important to identify that and train toward that. Make sure you're training at least monthly and make sure you're using interesting content. I think this is where a lot of the PLA platforms fall short because it's not interesting.
People are just, they play it while they're doing something else because it's not engaging. If it's engaging, they'll pay more attention. Next topic is culture. One of the big issues is that our clients don't have a culture of security. We think about it right inside and out upside, downside, all different ways because we live it every day. But we need to help our clients change their company culture so that they incorporate that culture of security.
Um, one way to do that is to have the VCIO and the account manager have these conversations with the clients, um, and explain how they can have these conversations with their various teams. And then at the client level, they can have these conversations in every meeting. So one of the things I've done with clients before is to pick a topic of the month and then have each of the managers who are hosting meetings incorporate that topic into their conversation as it pertains to their team.
The financial teams would have different conversations than your IT support teams would have, or your sales teams would have, but they're all the similar topic for that month. Um, and another, uh, topic is to consider doing social engineering testing, which right now we don't have a platform for. You can hire an outside company who has a red team to, you know, scrape social media and other content and then create social, uh, engineering campaigns to test the client.
That's the best way to find out if your training is actually working because people have learned to click through tests, they learn the answers and they answer the questions, or they have been able to identify the fish testing. Most people don't do so well in real social engineering testing. So I think that's gonna be our next phase. Hey, uh, ne lemme just ask you, I think Ann made something really pertinent in here. I was gonna answer her, but I, I'll, I'll, I'll give this to you.
So Ann's like, um, it's, it's the stimulus response. Our reptilian brains, you know, stimulus response. We like to, you know, click everything. How, how, how much do you think, you know, social platforms, you know, whether it's Facebook, Instagram, you know, this dopamine fed response that we've just become so used to are, are, are, you know, part of that whole conditioning process. I think that's part of it.
But anybody who's been in it for, you know, 10, 15, 20 years, how many times have you had a user say, I had an error message. Oh, what was it? I don't know. I just clicked. Okay. Right. Humans have always done this. They, they're not interested in this side of the technology. They just want it to work, and they wanted to help them do their jobs. This isn't that interesting to them for, for most of them. And if anything, it's a little scary, so they don't wanna think about security too much.
Hmm. Got it. Good point. So Nat, one last, uh, one last question for you. So let's, uh, let's assume that, that things have gone horribly wrong, right? And, uh, a company's employee has been the victim of, of social engineering, and there's been some securities. How should an MSP, who's obligated to act as a, a vcso support both the client's leadership and the affected employee or employees?
I think this is a tricky situation because as a vcso, um, you want to be as transparent as you can with your clients. However, if you share too much information too early and that information is not validated yet, it can lead them down the wrong path. If you start saying things like, we think this happened, it could have been that, then sometimes one, you're creating more fear, which is worse than them kind of being in the dark.
But also you're not working from facts, you're not working from data, right? At that, especially early when you have an incident, there's a lot of hypotheses. And at that point, you know, you have to mitigate, you have to respond to the threat, get it under control, then you can give them the full story. You, if you go through anybody who's ever been through an incident, you know, this things change, right? You're going down a certain path and then you get a curve ball, right?
And you need to shift and, oh wait, this wasn't the thing, this was the thing. So I think it's really important that you monitor the data that goes out to clients as much as we want to communicate, right? That's a big part of being a vcso.
We communicate with our clients, we have a relationship with them, but it's more important and it's a better outcome that you wait until you have facts, things that have been verified and vetted, um, through your incident response team before, just giving them bits and pieces and maybes and hypotheses, even though it might be frustrating that you can't give them any information at that time, it's always better. You wait until you have facts.
Um, the other thing is making sure you, you have your IR plans with your clients and so many organizations, I can't even tell you how many, uh, how many clients I had who when I got them, they had templates that still said company name. They didn't even customize it to put their own names in and anything about them. So it's really important that your IR plan has been customized, that it's tested with pen testing, tabletop exercises, and that it's updated at least annually.
Um, so that way when they need it, it's ready for them. It's been customized, it has all the information that's pertinent to that organization, and that is worth gold when you're in the middle of an incident. And I think it's important, you know, we say all the time, it's not if an attack happens, it, it's when, right? And I think organizations still have these rose colored glasses that they think, it's not gonna happen to me. I'm too small, I don't have anything they want. But it happens.
And I think, you know, it's unfortunate, but most of the time the, the or the clients are most receptive after an event happens. I wish that weren't the case, but that is the case. So that is the time to make some meaningful changes within the organization, um, to help increase their policies, increase the user adoption, whatever it is, so that they can be ready for the next time. The other thing is, um, before an incident happens, um, go over their cyber liability policy, right?
So many times it's not, it's only once a year when the questionnaire comes up that it's even a conversation. You can ask your, the insurance three months before it's due to have a copy of the questionnaire so you can look at it ahead of time and help to prepare. You can ask at any point to see the client's questionnaire, um, or their coverage so that you could see what they have and whether it's it's enough to cover them through an incident.
Um, because many times, I mean, the, the average cost of an incident is $4.5 million, right now, average ransomware request is one and a half million. And most cyber liability policies don't even touch that. Yeah. Wow. Great stuff. Na, thank you for, uh, coming in at the end here and sharing, you know, the, the, the real world like perspective and interactions you're having every day with, with your customers. Um, really, really appreciate it. Aaron. I really appreciate you coming on.
I'm gonna put once again the flow link, um, in chat for those that want to get an understanding of that vendor agnostic automation conference that you guys are putting on. That's open to everybody. Um, and I think you made an excellent point about get outta your comfort zone. Go speak. Um, really appreciate it, Aaron. Thanks for coming on. Thanks for having me, Andrew. Yeah, absolutely. Uh, Eric, always a pleasure having you. Thanks for the perspective. This was a really interesting one.
Um, hope this is not the, uh, beginning of a precedent. Um, but, uh, but again, thanks for sharing. I'll keep everyone updated as the, uh, the case goes along. Yeah, awesome. And Phyllis, always great, great seeing you. Thanks. Wishing everybody a fantastic week and we'll see you next Monday. Take care. Thanks everyone. You folks.
Related Videos

The Vulnerability Crisis No One is Funding
The Vulnerability Crisis No One is Funding

The Vulnpocalypse Is Here & Your MSP Can Survive It
The Vulnpocalypse Is Here & Your MSP Can Survive It

The CyberCall: The 2026 Verizon DBIR Unpacked with Author Philippe Langlois
The CyberCall: The 2026 Verizon DBIR Unpacked with Author Philippe Langlois