Live with Brad Gross: What are the implications of cyber liability?

All right, all right, we're live. What's going on, my friends? Say hi to us in chat. Uh, we have got an awesome live stream today. We're gonna be talking about liability with software companies. I'm joined here with my friend Brad Gross. Brad, you want to say hi?

Hey, good to see you, Wes. Thanks for having me. Nice to be here.

Heck yeah. Glad to have you. Yes, we are. No doubt about it. It's good to see you. We got Tristan checking in. Tristan, what's going on, man? Tristan's a longtime friend from my Perch days. Awesome, awesome security analyst. Mike Stern checking in. Got Matthew checking in. Good to see you guys. Everyone else come say hi. Brad, who are you? You want to talk about what you do, who you are?

Who am I? I am the, I am the all mysterious attorney for the MSP industry. So I have been a— I've been representing MSPs and tech companies for well over 20 years, counseled thousands of MSPs and service providers, and started programming on a TRS-80 Model 1 Level 2 43 years ago. So there's some street cred if I need that. I have that computer. Don't make me pull out that computer because I have it and it works. I got the tape drive. I got the separate monitor, the whole thing. So I've been heavily involved in the tech industry, not only just from a grassroots perspective, but from a legal perspective. I've literally counseled thousands of MSPs and service providers over the years. And cybersecurity is near and dear to my heart. So I'm looking forward to talking to you about it.

So just as a quick question, how the heck do you go from like a technical background like that into being an attorney? Like what shifted in you, man?

It's good. Well, I didn't want to go to medical school. I mean, really, that was it. That was really it. I thought I was going to go to medical school, and then I went to law school thinking I didn't want to see blood. And little did I know, I'd see as much blood in the courtroom as I would in medical school.

Maybe more blood in some ways, huh?

That was it. I started my career as a prosecutor in Nassau County, New York, and I was given, because I was the computer geek of the office, the first cyber harassment case in the US, prosecuted it to its conclusion. We went to trial. The guy basically admitted to it. It wasn't the most difficult, but he was fined $50 and walked out the door. And I— but I thought to myself, you know, I could sort of merge technology and computers and so forth with the law. And so started me on my journey.

Okay, so I couldn't have had a better guest join us. As you guys can clearly see, this is gonna be super duper fun. Um, okay, so I think as we jump in— by the way, Dylan Dow checking in. Dylan, thanks for the AO, my friend. Uh, and Mike Stern, I hope that's not hate with the Trash 80. I don't think it is. I think he's just, uh, having a good time.

It's, it's Trash 80. No, that's what they used to call it, which shows me that Mike Stern has some background with the TRC because if you know what you call it, a Trash 80.

He's got some, he's got some street cred there. Yeah, I entered into this world like a Tandy 1000, if you remember those, the green screens, all that. That was, that was my entry. I'm a small one.

Wasn't that like a small— that wasn't like a full size, was it?

It was like the screen, it's hard to show. It's screen's like, you know, about that big. So it wouldn't kind of desktoppy. We didn't even know what to do with it. Like someone gave it to us and like I would just use it to type and that was about it.

That's fine. That's it. It got you where you are today.

That's right. That's right.

That's right.

So here's what I'll be talking about for you folks joining today. Obviously, the National Cybersecurity Strategy just came out and let me hide chat for just a second so we can get our lovely faces in here and we'll talk about the implications of that too. And we're going to dive into that more tomorrow on this channel. But one of the things I think is really, really interesting here is this idea of what we talked about yesterday. Gina Easterly dropped a little bit of a bomb and clearly she dropped it intentionally because today the strategy got released. And one of the core kind of pieces to this is this idea of companies being held liable for insecurity. And that just brought up 1,000 questions on the livestream yesterday and really good conversation. And like this right here, Congress should advance legislation allowing software manufacturers to be held legally liable for the insecurity of their products. And it should also shield companies that develop software, secure software from legal liability. So like that idea of like safe harbor. And so I guess to start with this, Brad, as we jump in first, question for you. Does that even like make sense? Like, did you see this coming as like sort of a thought stream coming out of federal government?

Well, you know, does it make sense? Theoretically, it makes sense. When you read it on paper, it's sort of like asking people, you know, who's against pollution? Everyone's against pollution, right? Who wouldn't hold a software manufacturer responsible for the vulnerabilities that it puts out into the into the marketplace. When you put it like that, it certainly makes sense. But the devil is in the details. Yeah. The devil is in determining what you mean by putting defective, so-called defective software out there. And then, you know, implementation is everything. So while I think the statement has theoretical possibilities, practically, I think we're so far away from it, I don't see how it can be done.

So let's talk about some of those practicalities then that stand in the way, because it would seem to me that some of those, like, Who's— we talked about this yesterday— who's the arbiter in this case? Like, what determines like negligence? Or like, what's the barrier line between someone that gets safe harbor and someone that should be held liable? What do you— how do we even go about thinking through that?

I don't think you can. I think that, you know, when you're talking about, you know, we throw out terms like negligence, breaching a duty of care. The question is, how do we determine what the duty of care is? Does it go by the software manufacturer? Does it go by the people using the software? Are they going to be the ones for whom we need to determine what the duty is? How is the software going to be used? And under, you know, what conditions all of this will occur? For example, let's just take Windows, Microsoft Windows, right? Basic kind of foundational operating system. Who uses it? Everybody uses it. How do you set up a duty of care when everybody, every industry— I mean, pick an industry How do you set up a duty of care when every industry uses it? And, you know, it's fascinating to me that people say, well, they ought to be responsible. Someone, Microsoft, should be responsible. I don't know who's setting up that duty of care and how do you determine what it is. I think it's at this point somewhat impractical.

Yeah, I think we could even use, like, take the Exchange attacks that have happened from last year is probably a great example of that. So many people using on-prem Exchange. Microsoft, as soon as details came out around all of this. They published them, they made them known. The carriers will tell you they had a lot of claims made from those Exchange, uh, uh, attacks that came out of it. Um, what do you do? Like, use that as an example. Is there anything that would happen? Let's fast forward this, what CISA is saying now, and let's say it goes into some kind of legislation of some kind. What would a scenario like that look like, do you think?

Well, I mean, it's tough because now you have to show either that they They put, you know, the analogy that we're talking about, if we're going to fast forward, it would be an analogy to like a product liability, right? That's sort of the analogy. If we're trying to put it in a framework, we're going to put it into the framework of product liability. You took a product, you put it out into the marketplace, and it damaged, it hurt people. In this case, it hurt people because it had a vulnerability. Okay. You know, when you think about a product liability, situation though. It's not a perfect fit, and here's why. Here's why. When a manufacturer puts something out that is inherently defective, okay, then it is by itself, um, a menace, right? The thing is a menace. It could hurt you, it could cut you, it can— whatever it is. The issue with something like Xchange, it's not a menace in and of itself. It's not a menace. It doesn't hurt you, it doesn't cut you, it doesn't damage you. It You know, it's, um, if people— when Firestone puts out a tire, okay, and it's defective, well, that's a product defect. But a tire can only be used in a certain number of ways, right, under a certain number of conditions on a certain type of car. Exchange could be used in lots of different industries in lots of different ways with lots of different add-ons and so forth. So it's going to be, in my view, virtually impossible to go down the road and simply say as a blanket statement, we're gonna hold Microsoft or any other company, right? I mean, we've used Microsoft as an example. We're gonna hold them responsible if they have vulnerabilities. It's too speculative, it's too ambiguous.

Okay, that makes sense. Tris, great question. I'm gonna get to your question in just a second. Following that line of thought, so because what I've heard from other people is like, hey, look, you use the tire analogy. If I make a defective tire and maybe I cover it up and I don't say anything about it, and then a bunch of people get in wrecks, it makes sense that there's liability there. Or if I'm a car manufacturer, like the whole reason we have these recalls is because of liability concerns around the recalls. That's why they're serious about it. I have a Ford and they just sent me another letter that's like, we urge you to take care of this brake thing that's like a remote chance of happening, you know? Sure. Or the medical side, if I make a pacemaker and I cover up something or I know that it's got a defect But what you're saying is it's just a lot more difficult in the cyber side than it would be in some of those physical examples.

Absolutely. Absolutely. And I think that, you know, we also have to draw a very big line, not a thin line, but a big line between companies that take their software and throw it out into the marketplace knowing there's a problem, knowing there's a defect. Right. Obviously, then companies that don't know there's a defect, but discover them as the product is used. You see, for example, while we could put out something like Exchange, let's say, you know, Microsoft puts out Exchange, we know there are things, you know, we know that there will be problems. This we know. I mean, anyone who programs and is in the industry knows there's gonna be some vulnerability. But I think as a society, what we've did is that The value of exchange as it is now is more valuable being used by everybody and incorporated and integrated into society with its potential flaws than not putting it out and waiting for every flaw to be exposed. And when you look at it that way, what is the value of what is being put out now? How valuable is it? How much is it being used? And so on, understanding that there might be flaws. Well, then the whole idea of holding them accountable and so forth starts to become diluted.

That makes sense. So take me— walk me through again a fast-forward scenario. The Uber breach that happened a while back, right? And the CISO intentionally chose to sort of COVID it up or not disclose it. Do the— does the physics of all this change in those kinds of scenarios where, like, you know, we've chosen to say we knew about something, or even take the Kaseya attack that happened a while back. One of— I don't know about this for if it's— but one of the accusations was that the vulnerability was known and it was being worked on but had not been publicly addressed in any sort of form or fashion before REvil took advantage of it, right? Like, what do those scenarios look like in a future age where some of this from CISA comes out?

Well, I think that if you're going to follow CISA's line of thinking, line of logic, then all of those in those cases, uh, companies would definitely have had responsibility. I mean, if you follow along their logic and what they want to do, the, um, you know, and without commenting on individual cases because none of us were involved in those, right? Um, I think that at least when you read what came out in the press, let's say about the Uber, uh, the Uber situation, the CEO had a lot of knowledge. I mean, it wasn't just knowledge of, you know, there might be a problem. And we'll see where things go. And I think he had a lot of knowledge and hid it from the board, and then tried to change it into, well, we didn't treat it as a vulnerability as much as an exploitation program that people were talking about. And so, okay, when you start going down that path, you're sort of at rock bottom. And I think that even under today's standards, there's probably accountability that can be had there, as opposed to companies that maintain, as, as I just said, exploitation programs, right? We'll pay you to tell us what those exploits are. Now, obviously, we're aware of them, but we're not issuing press releases and so forth about them, because that will cause more harm than good. It goes back to what I was saying earlier, which is sometimes it's better to leave something in the marketplace, knowing there are some defects, but realizing that it'll affect very few people, than blasting something out and saying, 'There are problems, stop using it,' and so forth. Uh, so I think that we have to find a middle ground. I don't think that simply saying we're going to hold manufacturers responsible is the way to go. I think it will stifle innovation. I think it will scare the hell out of companies. And I think it would be difficult to prove in any event. You know who it would generate, uh, revenue for?

You?

Plaintiff's attorneys. I'm not a plaintiff. Okay, but well played, sir. You— I like that. Um, yeah, plaintiff's attorneys.

Okay, that makes sense. I suppose, I suppose if it was you, you'd be like, yeah, I'm all in favor of this, this is great, let's do it, call me.

Have you been injured by Windows? Headaches because of Windows?

Oh, that cracks me up. So, okay, so let's get into the motive. Two great questions coming in. We will get to those. I just want to finish this line of thinking. Sure. So it seems like the motive out of all this from CISA, if there is a pure motive, is, look, we've got to— we got to get the private industry to do more. Because if you look at all these big major, you know, systemic kinds of things that have happened over the years, it typically is at the fault of, you know, some kind of vulnerability that wasn't addressed and handled. So is there a better way than like trying to theoretically push liability of a fear factor to, to software manufacturers? Can you think of a better way?

Well, I think that there are a couple of things that are going— you're going to start to see. One of them, of course, comes out of the insurance industry. Okay. I think, you know, people say that there's no regulation in the MSP industry. Yes and no. Yes and no. While there isn't really any state or federal regulation over that industry. By default, insurance companies are starting to regulate MSPs. They're starting to, in their underwriting process and their due diligence process, look into the solutions that they're using, and then they will raise their rates or lower them depending on the solutions that you have, or maybe not even insure you, right? They'll just simply say, we're not insuring you. By definition, that's regulating MSPs. I think that you might start to see some of that in the software industry. As companies seek insurance and the insurance company says, what software solution, what SaaS provider are you using? What, what, you know, what do you have in place? And if you don't have the right stuff, or if the manufacturer you're using is known to have lots of exploits and so forth, what we might find is higher insurance rates, which will by definition be a regulatory way of doing things. We were also Was it yesterday or 2 days ago? We got the comment from, uh, um, from Matt— about Matt Lee— about, uh, self-regulatory organizations, right? So that's another way, and that is sort of what President Biden's new framework that he just released today starts to hint at. It starts to hint at these public-private partnerships in which the government is not going to control it, but will certainly have an oversight, uh, purpose. And you're going to have these private organizations, uh, that are going to set industry standards, and companies are going to be either in the industry standard or they're going to be out of the organization, and they won't have credibility, they'll be fined, and so on and so forth. I think that you might start to see that as well.

So— to— okay, that makes a lot of sense. So, so a lot of what you're saying is like the market will kind of figure this out both on the insurance side of the house because they're the ones that control the claims process. So they're going to obviously steer things in a way that forces people to do good so that they have lower and less claims. That makes sense. And then I do think the public-private partnership makes a lot of sense. Like I, in my banking days, we saw that with FSISAC. They're not a regulatory— just literally a nonprofit. But you know what they do when they get a bunch of banks together and they say, this is what we're going to do and we're going to work with regulators to communicate this. The regulators listen because it's a makeup of a large cohort of their industry. And so I even think like, I don't know if you've seen, Brad, and I'm not necessarily asking for like a public opinion, but just if you would, if you can, what CompTIA is doing with Trustmark, they've kind of brought CompTIA back. They've recycled that. They now have an audited, a third-party attested pathway that's CIS Control aligned towards the Trustmark certification. I think that's great. And I think if it takes off, and we see a lot of MSPs really commit to it, that could potentially be a future. And I could potentially see even carriers starting to recognize that. So now you have the tie-in there. Is that kind of like the goal of what you're talking about?

That's what we're talking about. And in the spirit of candor, I sit on CompTIA's Cybersecurity Advisory Council. So I'm right there with you.

Okay. Talk about it more then.

I think that the Trustmark is an exact— is a perfect example of the type of SRO format that we're talking about. People want to be a part of it. People want to be in because it's sort of like the Good Housekeeping seal of approval, but it's for cybersecurity and it's for a technology-based infrastructure. So I think that once you start to get buy-in to that from a consumer level, well, then you're going to get buy-in from the enterprise, from the, from the organizational level. And we're actually going to start to see some oversight. You know, the stock market is a self-regulatory, uh, organization. Um, the BAR, uh, as I mentioned at prior podcasts, the, uh, the BAR is, is an SRO. You know, once you're in it, you have standards that you're going to hit, and you actually feel— it's not just the fines that companies might get if they, um, if they, they go against or they violate the principles of the SRO. It's a feeling of, of you want to be in it, you know, you want that credibility. You don't want it on your record that you've been kicked out or you've been fined, or somebody could go do a Google search and say, yeah, they're part of our SRO. They have been censored, uh, you know, a few times in the past. It's not what you want. It's, um, it's almost a self-propelling, uh, self-motivation thing.

Okay.

And I think that short of legislation, which I'm not sure how the government could do, short of the insurance companies regulating, which I think is coming, an SRO might be the good way, might be a good way to go.

So in your mind, is it possible that like the Trustmark, CompTIA approach could one day in 5, 10, 15 years for the MSP industry be the true equivalent of like the bar for attorneys? Is that an outcome?

100%. And not, you know, not— I'm truly being objective here, but it sounds like an endorsement. CompTIA has been ahead of this curve for years.

For years.

The Trustmark is not something that's just come out a year or two ago. It's been around for quite a while. And it's built momentum and built momentum to the point where now it has industry credibility, as it should. So I think that, yeah, if we skip ahead 10 years from now, that's exactly what we're going to see. We're going to see CompTIA's Trustmark and other organizational standards in place, because it's just going to take the, that tipping point where people say, I'm fed up, right? People haven't actually said I'm fed up yet, right? Right. The tipping point hasn't been reached. It will be. Not yet.

Solid. So help— here's my ignorance here. Let me just show it. Can I— I can't call my— correct me if I'm wrong— I can't call myself an attorney if I'm not licensed or whatever through the bar. Is that a correct statement?

The actual You're a— you can't call— you can call yourself an attorney once you have a juris doctor degree, right? You've passed law school. Now you're an attorney. You can't practice in a state unless you are admitted through that state's bar.

Okay. And is there like legislature that would like— let's say I'm, you know, like, what's that movie with Leonardo DiCaprio where he pretended to be a lawyer, whatever the name of that movie is? Can— if I just pretended to be an attorney, And let's say I did get my juris doctorate or whatever. Okay, let's say I did it and I just started practicing law without license through the bar. Do I— is that like a prosecutable offense?

Yes, it's a prosecutable offense.

Okay.

So in the state I'm sitting in, in Florida, of course.

Okay.

And they would say, is this person licensed to practice in the state of Florida? No.

Okay.

Then actually the state can step in. So that's sort of a public-private—

got it.

So for lack of a better way of putting it.

Got it. So step one would be let's get CompTIA and Trustmark moving forward. Let's get it be the attested partnership. And then to build that, that public partner approach, we would need state legislature to say, we like what you're doing, we're stepping in. So now to be called an MSP, state of Florida would say you can't use the word MSP unless you've been approved through this pathway. That would have to be what would happen to make this work, right?

That's exactly— that's in the MSP space.

Okay.

Yes. Right. For software, we could start to see those type of, those types of organizations for software companies as well. You can't offer a, quote, security solution. Again, this is, this hasn't happened yet. So we're just talking here. But you can't offer a security solution. You can't market it as a certain type of thing unless you are meeting certain standards, you're part of an organization and so on.

Okay, got it. And so you not to put words in your mouth, you see— tell me if this is right or wrong— you see this is the beginning of a pathway. That's the ultimate potential outcome, is to be the word MSP, or whatever the term becomes, is a legally defined, enforced through a private-public-private partnership pathway. That's— you see that this in motion now?

I see that. I believe, my personal opinion, and I, and I haven't counseled thousands So I've seen the good, bad, and ugly. I think that's the way it should be. Now, do I see that's the way it's going? Candidly, I don't see that happening in the MSP space right now.

Why is that?

Because I don't see enough interest on the parts of states. I don't think that— okay, I don't think states, governments, I don't think citizens in general realize the importance of MSPs, how ubiquitous they are. It's sort of flying under the radar. And as a result, that type of thing that you're talking about now hasn't really appeared on the radar screen of the legislature, but it's getting there.

So again, that, that makes sense then, because let me show this. Let me share this back out. So this came from the Solarium Commission. I talked about this on the livestream yesterday as well. You know, this whole— this recommendation is intended to clarify the blah, blah, blah. Circumstances— the commission drafted legislation in support of this recommendation, but Congress has not introduced it. Staff will continue to conduct research and analysis to meet the intent. And then there was another one somewhere in here. That's not the one I was thinking of. Or basically they said at the end, I could go find it again. It doesn't matter. Basically, they said at the end, we're just waiting for some event to happen to push that forward. In other words, like, yeah, we talked about the Kaseya attack, the ConnectWise attack, the SolarWinds attack. But let's be honest, they didn't have quite enough of a major, major, major, major impact to force Congress to say, uh-uh, we're done, this is too much. And that's what we're waiting for to happen, a tipping point of sorts.

Didn't move the needle enough. It moved it, punk. You know, that needle has to, that needle has to, you know, move to the point where it's almost like a ski slope. Okay, yeah, this is nothing. If it moves like that, now you're starting to Now you'll see some, some real, some real interest. But, you know, until then, you have a lot of great— like what you just showed there. It's a lot of recommendations where all the industry is aware of it. Isn't it fascinating that the industry, people like you and me and others that obviously you deal with all the time, we're so aware of these issues. It's the public that doesn't know about it. Yeah, it's just a question of when the public becomes as aware as you and I are aware. That's when you're going to start to see things happen.

And it's always this way, isn't it? It's always— you look at any major systemic thing that's happened and everyone finally goes crazy. You go talk to the experts and they're like, hello, we've been screaming this for like years and years. And I think even the insurance carriers, like they'll tell you, you know, we've still never had yet a systemic major cyberattack that's cost, you know, it's like, like, like the equivalent of a hurricane that's pushed through and caused like, you know, the same equivalent happened here in Florida. That has not yet happened in the cyber realm. We've— we haven't even come close. Like, we— there's not even been something that's cost into the hundreds of millions yet in terms of like one systemic cyber event. And so— but you and I and everyone else watching on this livestream is like, yeah, that day is going to come though, right? And so that's the tipping point is what you're saying. Something like that would be—

that's it. The requirement. That's what we're looking— that's what I hate to say. That's what we're looking for. But that's what we're looking for.

Yeah, right. Yeah. It's both good and bad, right? We don't want to see that happen. But the inevitability is at some point that does happen.

Okay. That's Solid.

So I want to get to some of the questions here. Tristan asked a really good one about open source as we were originally talking about the liability pieces. Right. And so this, this like, how would you handle like on the liability side, open source or improper library implementation? What if a bug comes from a new chip and the hardware emulation causes the bug? Or like another example would be Log4j, you know, something that comes into the library, it's open source that everyone uses. How the heck do you— that probably just goes back to your point of this is exactly why liability is not going to be an outcome that works, I'm guessing. But what do you think?

That's why it's going to be so hard to pick out a duty of care. Right? What standard do you use? Do we now say, well, no one should be using open source? I got news for you. Anyone who programs knows everybody uses open source to some extent. Everybody uses it. So now what? We ban open source under the theory that something could be? How far will that put us back? And is it even logistically possible?

It's not, right? Because you shut open source down, you shut the world economy down because like you said, everything's down, right?

You have it. You think you've seen bad things? You ain't seen nothing.

How much of like imagine all of AWS just goes down in a heartbeat, right? It's amazing how many like startups that are out, even like well-established vendors, it's all running open source software that's cobbled together in a more pleasing way or it's got management on top. So yeah, 100%, 100%. Okay. What about this one here? I don't know who this one— oh, it looks like Jason is where this one came in from. Doesn't this produce more scenarios where there would be a constant pushing the buck mentality when it comes to accepting responsibility for negative events, therefore further delaying potential identification of cause and resolution. Thoughts on that?

Well, I, you know, it's a good question about pushing the buck. And, you know, right now that's what we have, right? Everybody points to everybody else, uh, and, and we've spread responsibility, um, and liability so thin that no one takes responsibility and no one takes, you know, no one, no one is culpable. Um, I think that we have to come up with a way And I'm not sure we're going to do it on this particular webcast, but we definitely have to come up with a way where there is accountability at every level, okay, at every level. Now, what level of accountability should there be? We don't know. We don't know, right? But, you know, we know, for example, at a foundational level, if you knowingly or willfully send something out there that's a menace to society, right, we know there's culpability. Okay, we start with that. But from that to where we are today, there is so much gray area, right? There's so much gray area that I think that we're going to have to start to segment it and then get accountability at each level and go from there.

Okay, that, that makes sense. So I want to hear back from the audience. You got a great opportunity to ask Brad some questions you might want to know, some free legal advice, right, Brad? Just what are your thoughts?

I'm not billing you. No, I think, I think my microphone stopped working. Is this on?

Yeah. I mean, you could try. I don't think I can afford you. That's going to be the problem, you know? So, yeah, I want to hear back. Do you have questions for Brad on this or what are your thoughts around this? I tend to agree, Brad, that like, I guess I get the intent behind CISA trying to push the fear factor of liability. But yeah, when push comes to shove, good luck establishing that. I tend to agree. I'm curious what others think as well. Matt, bro's checking and already paying for his legal advice. So yeah, there you go, Matt. I'm glad you're on today. Uh, but yeah, let me know what you guys think in chat. Go ahead, Brad.

We have to— in this whole thing about when we look at the comments that were made and so forth, we have to take a pause, deep breath, and step back and resist the urge. And trust me, I'm not pro-company, I'm not pro-enterprise. I, I try to stay objective about these. But we do have to resist the urge, that mob mentality, right? Something went wrong. Whoever put out this software— see, another vulnerability. See that? We have to— they should be accountable. We have to resist that. It's going to lead down a very bad path. And again, you know, again, not necessarily taking the corporate side, but if you think about it, again, going right back to where we started, an operating system, right? An operating system is designed— when it's, when it's, um, when it's produced, when it's put out, it has to work. Let's say Windows, it has to work with a piece— with lots of different PCs, with lots of different chipsets, lots of different memory configurations. I mean, think about it, look who I'm talking to, you know that, right? Hardware configuration, software, then hardware and software interact to form a third thing, and the operating system is supposed to work work with that, then you have to think of all the people that misuse it, that plug other devices in. It's amazing that these things even work at all. And then when a vulnerability comes out, we turn around and we say they have to be held responsible. Well, you know, be careful. Let's, let's pause because we all enjoy the ability to take any flash drive or any device and have it, you know, Bluetooth it and then interact with our, with our system. Be careful before we go that mob mentality of, but if anything goes wrong, if there's a vulnerability, assuming they didn't know, right, it wasn't malicious. If there's a vulnerability, there's accountability. I think we have to resist that.

Yeah, agree. And I, I think what you see the EU doing is a hard shift opposite from that, right? Like especially the privacy side of things. But they seem to be very happy to come after and fine, especially US companies left and right over any tiny thing they don't like. Even, you know, you use the Lightning instead of like the USB-C. In phones, right? Like they seem to just have a totally hard pivot difference than we do in the stateside on how they interpret all this, right?

Yeah. I think also there's tolerance levels that differ between us and those across the pond, shall we say. So, and that has to be considered also, you know, what is our tolerance level for holding companies accountable? Are we willing to increase costs? Are we willing to not have as much innovation? Are we willing to be told on a moment's notice, "Stop using whatever you're relying on right now because there might be a vulnerability." And how many of us would actually do that, right? It's sort of like the fire alarm that goes off in the hotel. Does everybody really go running for the door? Do you sit back and lay down and think, "It'll go off in a minute," right? We have a different mentality here in the US, and that has to be accommodated as well.

So one more question for you. I feel like if we put ourselves in the shoes of an MSP, like I'll just pick one that I know I have permission to use, put yourself in the shoes of, a Robert Shafi. So he was caught up in the Kaseya attack of a couple of years ago, and he definitely had to struggle through— I don't know how much, but, you know, all the aftermath and damages of a problem not of his choosing and not of his cause and having to deal with potentially, you know, litigation for, you know, people coming after him for their outages and all these kinds of problems. He'd probably sit here on the call and say, yeah, that all sounds well and good, but why I'm suffering from this, not my upstream provider that caused this. How is that fair? What are your thoughts on that?

So it's not fair. But you know what? This gets us into a different, potentially into a different conversation, which is the agreement that an MSP has with its customer. Okay. I have always said, I have always said, this is sort of my mantra, that mismanaged expectations are the root They are the root of liability. Mismanaged expectations, not failure to provide a service, failure to facilitate something, mismanaged expectations. And MSPs have to understand that their customers don't know that there are third-party providers, that there are upstream providers. And if the upstream provider fails, and it could fail, and many do from time to time, that the liability should not be imputed to the MSP. They have to explain that to the customer. If you don't explain it to the customer, then the customer looks at you and says, fix it. Well, we can't fix it because SEIA did this. We can't fix it. Well, you brought SEIA to the table. I don't know what you're talking about, right? Fix it. But if you had explained by contract that, look, we're a third-party facilitator, we're a third-party reseller, okay? There are things that we provide directly, then there are things we facilitate. And we're not going to take liability for things we facilitate in the same way that we do for things we actually provide. And you agree to that, because we understand that if the customer says yes, well, you're in a much stronger position. So, you know, this sort of bleeds into the contract and explaining to customers what they need to know.

Got it. Okay. That, that makes a lot of sense. So there's definitely some takeaways there then, right? Both in terms of communicating this to your clients and making sure your MSAs define such, right?

Absolutely. Your relationship, your meaning, if you're an MSP or a service provider, your relationship with your customer is a creature of contract. Treat it like that. Treat it like that. And you'll avoid a lot of the liability and a lot of the headache.

I think you're right. And I think that's the big wake-up call the past year has had for MSPs of like, I've been pretty lackadaisical on this. My MSA is just a copy-pasta recycled version that everyone else has used, and I just try to be nice to my client and take care of any problem they have when it comes up. And I always thought that'd be good enough. And then something hits the fan and all of a sudden, yeah, they just realize exactly that statement right there.

I often gave, for years I gave a presentation at industry events called How to Avoid Being a Terrified MSP. That was the title. And one of the one of the slides that I would show. The headings is a quote, and it said, 'I can't believe that guy is suing me. I just went to his kid's bar mitzvah last year,' right? That's an actual quote that I got from an MSP. You know, MSP calls me up, says, 'I'm being sued,' whatever it is. 'You know, I can't believe this guy's suing me. I went to his kid's bar mitzvah last year,' right? That we're all friends until we're not friends. Yeah, so for sure. For sure. Again, this is sort of now we're in the MSP agreement area, but nonetheless, they do conflate, right? Liability of software companies, lowering liability, what you're willing to accept and what you have to share, allocate risk with your customer. It definitely merges in with the, with the whole agreement area for sure. Yep.

Yep. Okay. That makes a lot of sense. Looks like Jason said, I like this quote. At the end of the day, I feel like this is just going to be the old college try, right? See if I can bring this back up. Wrong quote. There it is. But there's so many wrinkles for me to feel like it's realistic. Yeah, that, that, that, that makes sense. Maybe one last question for you.

College try, right?

That's where we iterate to success, right? We don't just, you know, hit it out of the ballpark. You got to get at that over and over and over.

Exactly right.

Yeah, that's well said. So if anyone has any thoughts or questions, give us feedback. There's a whole bunch of you guys in chat, so I'd love to know what you think. Maybe just one more question for you, Brad. I know you've had a chance to at least glance at the new documentation that came out from the White House on the National Cybersecurity Strategy. Anything in particular that stands out to you beyond what we've been talking about today?

Well, I'll tell you, it's— I, when I first started reading it at like 7:30 this morning or 8:00 this morning, you know, I'm reading it and I'm thinking this is just going to be a lot of puffery, a lot of we're going to strengthen things and we're going to redirect and refocus our efforts kind of thing. And to be frank, a lot of it is that, you know, maybe purposely, maybe just because they're not exactly sure which direction they're going to go in yet. But there was, or there were sections that certainly ring the bell that, you know, we're listening, you can hear the bell ringing about software companies being liable for what they're doing. Now, They stop short in the report of saying we're going to hold software liabilities liable. They don't go that far, but they definitely say it's time to stop putting the burden on the individual user who by contract and user license agreement agrees to a whole bunch of, you know, limitations of liability and then gets screwed in the end. It's time— well, they didn't use the word screwed, but you know what I'm saying. It's time for— they call for an end for that. And a public partner, a public-private partnership to look into this. You know, that in my view goes back to SROs. So while I don't think that there were— you're going to read this report and, and say, oh, there's clear guidance here, you know, now we're going to follow this recipe and at the end we're going to have this beautiful dish. It's not like that, but it definitely points in a direction along along the lines of what we've been talking about today, that things have to change. There are ways to change it, and we need to start moving toward those things.

Do you see it as an SRO for every industry, or do you sort of see it as like an SRO for all things like, like SaaS, all things software, regardless of the industry?

I think, I think, you know, that you're going to have to look at an industry-by-industry type of analysis. I do too. The, you know, there's too much—

there's too much uniqueness for each industry, right?

Right. For sure.

Okay. Okay. This has been awesome. Really appreciate you joining me today, Brad. This is super enlightening. And I mean, I think I'm encouraged by the pathway here. I think we've— free business has always found a way to get through. It's never clean. It's always messy. It always comes with a lot of turmoil and grief. But boy, you look at where we're at now compared to 3, 4 years ago, we're much further ahead in a direction. And so I'm excited to see what the next few years continue to hold. So this has been really enlightening.

Great. I appreciate you having me on, and I agree with you. I think that we're moving in the right direction. We don't quite know. It's a— there's a lot of fog in front of us, so we're not quite sure what we're going to find as we move forward, but we are moving forward.

Fully agree. So how can MSPs get in touch with you?

Oh, if they want to reach me, well, they could reach me at brad@bradleygross.com. Go to the website, bradleygross.com. I also have a podcast, two of them actually.

All right, pop those out for us. What are those?

TechnologyBradcast.com, which is a, which is a podcast devoted to the MSP industry in general. And then we have the Cybersecurity Bradcast, which just launched a couple weeks ago, two episodes, a third is about to be up. And that is devoted to cybersecurity issues for technology industries in general. Not just MSPs, all companies.

I think I found them both. So here's this one. Is this one right? Technology Broadcast. Give me a quick view of this. Give me a couple.

So on that particular, on that broadcast, on that website, what you're going to find there is anywhere from 8 to 12-minute audio podcasts about bad things that happen to good MSPs. And how to avoid being, you know, in that position. What to do if you find yourself in that position. What things mean. Why should you have a good MSA? What does a declination notice mean? Scope denial, scope creep. How are you going to deal with it? How do you increase fees when you're in the middle of a contract that doesn't talk about whether you can increase fees or not? Right? The kind of situational realities that every MSP faces. That's the Technology Broadcast.

Love it.

Love it. Cybersecurity is exactly that. It is going to talk about cybersecurity-related issues to companies generally. They could be technology companies, but it's technology companies generally. And it mirrors a course that I teach to law students about corporate cybersecurity responsibilities. So Tune in, see what you can find. I hope it helps.

There you go. So, so, Lucas, I see you in chat there. Um, what's that website? So I found just literally Googling, it came right up first link. So yeah, Cybersecurity Bradcast, you see that right here. And then also this one, Bradley— this is bradleyghost.podbean. But say you found it by searching the Technology Brad— because the word Bradcast is pretty unique, it's easy to find, right?

Technologybradcast.com. Or cybersecuritybradcast.com. They're two different, but they are sister podcasts.

Got it. Got it. And I appreciate it.

Thank you, Wes Spencer.

You got it. And then your website is here, bradleygross.com. So check that out. And what all services do you provide for MSPs?

Well, for MSPs or technology companies in general, we provide, you know, within that niche, we are very broad. Any sort of transactional requirement you might have from master agreements, customer agreements, licensing agreements, intellectual property, merger and acquisition, corporate, uh, type things. We will litigate in federal court. I try to keep clients out of federal court, but sometimes it's a necessary evil. So it's sort of a full-functioning, uh, law firm in the niche of technology and solution provider industries.

Right on. Awesome. So there you have it, two easy ways to get a hold of 2 great podcasts. And now you know how to get a hold of Brad. Brad, super enlightening. Thank you for spending some time with us today. Really, really great stuff. Excited to see where all this is going. So thank you so much.

Thank you, Wes. I look forward to seeing you at the next event on the road.

Looking forward to it. For me, it's going to be— you're going to be at IT Nation Secure?

I believe so. Yes. As a matter of fact, I should— I will see you there, my friend.

All right, Brad. Thank you so much, my friend.

Take care.

Take care. Bye.