The Oracle Breach and the Importance of Threat Intelligence

All right. Welcome everybody, and Happy Monday. Can't believe we are in April 2nd quarter of, um, 2025. It's staggering to believe how, just how fast, um, the years running. And I think I said this last time, like I, the, the, the whole, um, you know, the days are, days are long, years are short. It's, it seems to be more and more coming that way. We, um, just FYI on Bob Miller, hopefully we will have him shortly.

Um, Andrew, He just texted me, he said he's just running a couple minutes, ladies having some technology Issues. Okay, we'll have Bob with us momentarily, but welcome everybody, and, um, I hope you all had a fabulous weekend. Just some, uh, banter before we get going. Um, one thing I just wanted to, um, highlight, and I think I have it handy here, is this, um, new, we, we, we talked about this, um, on one of the calls that it's actually the called the, uh, tool. Bob's here.

Lemme, lemme bring him in. I just wanted to share a, um, I was using Oracle. Sorry, my, my machine was locked up. Well played Bob. Um, I, I just wanted to share this particular article with everybody because so many of our clients are QuickBooks Fair. Like maybe just yes or no, like you have clients or your MSP runs QuickBooks, um, just maybe throw a yes or no in chat. This, this, um, particular blog is really interesting and it's something that we're starting to see, um, more of.

Um, and that is the use of legitimate, um, uh, technology, right? We're seeing this living, i, I, you know, monitor, terming it living off the lance, um, uh, LOL SaaS, right? Bob, it's, and, and what, what you're seeing is, you know, whether it's things like we've talked about with EM, client or other types of SaaS enterprise, quote unquote SaaS applications, or in this case, this particular one, and I know Chris LA's on, so I'm curious if he's seen this.

But basically what the threat actors are, are doing is opening up legitimate QuickBooks accounts. And therefore, Bob, I will, you know, impersonate, you know, I'm your supplier, you're this or that your other, and send you a legitimate email from QuickBooks. Um, and these are being very effective. So I just wanted to let you all be aware of this. If you're not, please look into this article. Um, this is a new, an up and coming one that we are seeing, uh, more pervasive.

I'm not sure Mac, have you seen this one at all in the A PG? No, we haven't. Um, not from, I mean, but that methodology doesn't sound like crazy new as far as the legitimacy of opening their own accounts. But I, I, I imagine this is a good thing actually to look at right now, considering it's tax season or, Yeah, yeah.

It's just Your taxes, you know, but this is definitely the time of the year people are gonna be, um, a little bit more likely to click on things, especially coming from that, Right? And not that, you know, we're sitting on this call going, oh my God, this is the most novel thing on earth, but to our customers, right. You know, because the, these are well played out threats, right, Bob? These are Yeah, well crafted.

I mean, it's not like it's, you know, when you look, you can't Even spot it because of URL being necessarily wrong. Yeah. You know what I mean? There's just a lot to it that makes it a lot more sophisticated. Absolutely. Exactly. Exactly. Like when you look at things like typo squatting or things that you know, you could do with a domain that if you're doing, you know, like our typically security awareness training will go, well look for this in the domain, or look for this in the domain.

Well, again, threat actors are going, okay, great, you're gonna look for these things. Well, we're gonna give you a legitimate domain. How's that? Um, so, um, yeah. Yeah. No coincidence, right, Chris? So, okay, well, let's get on into it because talk about a spicy Monday. This is, uh, one that, um, you know, it, it's, it's interesting on many, uh, accounts, I see it interesting from the perspective of, you know, when you read about it, right?

Mac, you have a, you know, internet facing web server and, you know, we, we have like talked ad nauseum about anything internet facing, right? Is fair game these days. I don't care if it's a web server, VPN firewall, like the fact, like, I, I want to scream from the mountaintops and slam my head into a brick wall. If you're not doing continuous monitoring on internet facing type devices these days, like, I don't know, like, I can't say that.

Um, and then, um, what, what's even more interesting that, and I'm really glad Eric's here today is, you know, we've, we've heard about, you know, breach notification, right? Especially for publicly traded companies. And as Eric's gonna talk about here, oh, there's some nuances, right, Eric, to what you can and what you can't say or why you can, or why you shouldn't say.

And, and, and it would seem like the loopholes are very much, uh, can be, can be in the favor of these large companies, if I'm paraphrasing you correct. Correctly. Yeah. I mean, look, it's not, it's not as easy as it seems. It's not a, a hard and fast rule that if there's a security incident, you report on it. Um, there's a, that there is a, a lot more to it, not necessarily in favor of the, the public companies, but, you know, sometimes it's in favor of the public in general.

And we'll talk about that. Okay. Fair enough. So, yeah, so last week, um, just setting the stage here, we had fun with Signal Gate, um, and that was an interesting one, right, Bob? Uh, oh yeah. Where, uh, um, that, you know, we spent some time, you know, debunking, I Think we managed to take everybody off. I mean, literally, I think we touched everybody. I missed that one. Darn it. Yeah. Um, I feel Like all the topics lately are super Jerry Springer esque of just, They are right On reality tv.

Like even what we're gonna talk about today, like, wow, Everybody's so sensitive. Yeah. Yeah. It is, it is. Getting a little surreal here with it. Um, and then, you know, so that was really interesting in the sense of, you know, just, you know, whether you agree that it, you should or shouldn't use it, but, but just again, how easy, you know, the, the sense of access control, right? The importance of access control and you know, who you're sharing information with.

Um, just that control alone is so critical, right? Phyllis, in terms of, you know, really understanding, um, again, it's just an, it's a really another inventory, but a really a strong process, right? You know, in terms of who you in include into your, your enterprise apps and, and what level, right? That, that you're sharing information. Yes. The fact that someone was accidentally added to a classified conversation that was not supposed to have access is, um, craziness, mind bargaining.

And, um, now that you ask me, I will say one thing, NSA, when I was at the National Security Agency, um, we actually came up with a policy commercial solutions for classified. So for secret and sensitive information, there are rules around it, and you need two layers of encryption in order to use commercial solutions for classified information, thus commercial solutions for classified. So there is policy around that.

So for me, as a former NSA, it's pretty clear cut what you can and cannot do as far as classified information using commercial Phyllis. You mean they don't have two weeks to discuss what classified means? You mean you Pretty Clear rules around what classified information is too? There's no confusion there either. Yeah, we missed the whole debate. Like there was a whole chat of was it really classified or was it not classified that, yeah, so from your eyes it was classified, right?

Yeah, yeah, for sure. Highly, right? Because Phyllis is completely sane. That's the reason that's the answer is because, yeah. Okay. Well there we have it from a former nsa. Yeah, that was classified. She rests her case. Um, alright, so let's get into today's, um, topic, which I, I do, you know, some people out there might go, well, how does Oracle Cloud apply to me? You know, and MSPI think it's more so again, what lessons we can take here. Uh, lessons around, again, internet facing, anything.

And you know, Eric, I think around something you preach all the time, which is your contractual obligations with, you know, that or your contractual language of your, your partners that you're, whether it's cloud or vendor, whatever vendor it may be. And then are you going layers deep into your customers what they're signing with their largest customers, uh, when it comes to data privacy, breach notification, and things like that.

So there's, there are things to be learned here and, and I think some very important ones. So with that, Phyllis, I'll let you take it away with Mackenzie. Yeah, sure. Nice seeing you again, Mackenzie. Always. So, given the reports of Oracle's recent data breach, what are your thoughts on the nature and scope of this incident?

Well, there, you know, I was saying reality tv 'cause it is starting to feel like that as far as tracking the timeline of the past 20 days from two different cases, right? We, uh, which we'll talk about, one of 'em I'm sure bring it up, which is Oracle Health is its own breach, right? There's a notification process in play right now with hospitals and Oracle and what's been posted on the headlines.

And then a suspected whether or not they're correlated together or not from the threat actor side, um, a breach of Oracle's federated single sign-on based service, uh, or their server specifically. So what we've seen, you know, it feels like very cat and mouse right now, and this is why, you know, I like what Andrew was saying, is I try not to talk about, I try to be vendor agnostic when speaking about breaches.

I did put it on my Bingo card for 2025 that we would have some level of a semi supply chain breach or something close to it. And I think we're slowly getting up to that point with all the things that have been in the security headlines lately. So the Oracle Cloud one though, is concerning because it's been very much so a cat and mouse game.

Um, and the implications around if this is supply chain or if this is just a simplistic breach of the things we're talking about, like targeting of the edge, you know, dropping web shells, other malware, um, related to this case. But it also in the beginning was giving very script kitty from the point in which the threat actor was posting on breach forums. Now, there's no attribution that's been confirmed.

There's some light suspicion that's related to maybe a ransomware gang, but right now there's no affiliation confirmed for, you know, uh, nation state and a PT or ransomware operating group, some sort of crime group. So it's just giving, it's giving script kitty, it's giving just a little bit more dramatic than we want. Um, so timeline, I had to write down the timeline because that is what's been most interesting. I feel like we're watching Real Housewives.

So on three 20 we have the Threat actor posting the stolen data on breach forums. This is like encrypted single sign on creds LDAP passwords, uh, in trade request for decryption for access, gift of the information, uh, information on zero day exploits that were used, uh, database records, domain list, right? All the good stuff. But then they posted it with like undisclosed price, of course. Um, they also posted some other information.

The next day bleeping computer releases their article saying, Hey, by the way, this is everything. The threat actor is claiming to have all the information on what the threat actor had done as far as posting, uh, that they originally requested a hundred K in crypto. Uh, that didn't get, didn't get, I don't know, accepted for some reason. This actually happens a lot, right? We're in the negotiation. This is an active investigation likely, so that's not unor, not, not, not normal.

Um, they responded with a few things. So Oracle tells bleeping computer, no, this isn't actually happening. Uh, then the threat actor posts, uh, an internet, internet archive proof saying, yeah, actually here's the proton email address we use that has access to those servers, and small thing authentication information. So it's like, okay, then Oracle reaches out to internet archive and they're like, take that down right now.

So then they take it down, unbeknownst to 'em, there was a second one that was actually uploaded, uh, that would've also corroborated some of this. So then when they do that, the threat actor, this is the cat and ma mouse thing I'm talking about. Then the threat actor comes out and starts posting on Twitter, more proof of the data. Uh, they start doing something that, I don't know if I've ever seen this before or seen it before, where it picked up such momentum.

They start reaching out to researchers, threat, Intel known security industry experts and bloggers, reporters. They're like, all right, if you're not gonna listen to us, if you're gonna ignore us now, I'm gonna go out and I'm gonna send the receipts. I'm gonna give you all the dirty pictures. Let's go. So they do that. Um, essentially now posting on Twitter, they also post on YouTube an hour linking an hour long video.

I don't know if any of you guys lost that, of an internal discussion of Oracle employees discussing like, um, something on endpoint management and Al passwords relating to some of these systems. So you've got that drama, right? So we now we have videos on YouTube, we have stuff on Twitter. There is clearly Oracle maybe is just not picking up the phone. They're ghosting them a little bit. And the threat actor is like, I'm just gonna do some very interesting nefarious activities at this point.

They're probably irritated, they don't even care about what money they'll get out of it. Uh, then they also start posting, let's see, we're now at 3 26. They start posting complete configuration files as proof. So if we're gonna talk about like the credibility or the accuracy in this case, I'm, I would place my bets on the fighter threat actor right now in that same timeframe. Oracle re badges their cloud services as Oracle Classic instead of Oracle Cloud.

Well, there's no difference there too as well. Matt, Matt, can I just ask you a question right there just for a moment? Yeah. It seems like this is the, uh, Microsoft's legacy. Remember the Microsoft Oh, it's a legacy. Yeah. Is that, that's how I interpret it. Like, oh, it's an old, it's an old system. That's exactly what they responded with eventually too. Okay. So, you know, fast forward we're on, they release Oracle Health, they disclose that there's a breach with that.

Um, the funny thing that we caught related to that one is some of the customers that were reaching out on Oracle Health or claiming things were saying they were being extorted by a threat actor named Andrew. I'm not even making that up, I'll find you that. So I don't know, Andrew, we might have to talk after this. You really might need a game plan. Um, but yeah, they come out to the headlines to Bloom. Bloomberg basically reports Oracle states. This is a legacy system.

Uh, this is an old system. These are old creds. They haven't been used in eight years. Well, then the threat actor posts a screenshot saying, actually, here's the creds being authenticated since like 2020 in recently in 2025. Um, yeah. And apparently they also demanded, they claim they demanded 20 million originally from Oracle. So no, no surprise. Oracle was like, no, we're not doing that. No negotiation.

Then, then they posted, now we're full circle after they had requested 20 million posted the breach forum stuff. Um, so yeah, initial thoughts, vendor agnostic aside, I feel like threat actors, he's putting it on, they're putting it on display of how urgent you can get now working with, you know what, I'm gonna leverage the media and headlines and I'm gonna show just enough proof because if you are not going to negotiate with me, then I'm going to do as much reputational damage as possible.

And I do feel like Oracle kind of fell for that a little bit. Yeah. So, so just quick question, Eric, like, again, long ways off, right from a clash, you know, we know there's clash action lawsuits and all this stuff, but how damaging can it be to an organization? And this is, this is the lesson I want MSPs to hear. Oh, no, no, there's no breach. Oh, there is maybe a breach.

Oh, well, it's an old system, and when you start changing the story and there's a lot of factual da, like, can you walk us through the potential, right? We know there's, it hasn't been no one's, you know, gotten judge and jury yet, but like changing stories and coming out with this kind of stuff. What is the dam potential damages that we need to be aware of, of saying things? Uh, you know, to give you the, the, the classic lawyer response is, it depends, right? It, it could be nothing.

There could be no damage. It could be $10 billion in damage. We, we don't know at this point. It just depends on the, the depth and breadth of it. I mean, it's, you, you think about any security incident and you know, max gone through a thousand more than I have, but what you know today is different than what you to, you know, tomorrow and what, you know, two days from now is gonna be even different again.

So the fact that there are differing stories as time goes on, isn't at all surprising to me at least. Uh, but you can guarantee that the plaintiff's bar, the class action bar is, is licking their chops over this. But I don't think that anyone has enough information yet, uh, to determine, you know, how far, if at all that's gonna go Y Yeah, totally get that.

I'm just saying like, for us to take away as learning, opening our mouths and keeping our mouths shut when, when a threat actor like can very easily go, oh, really? You don't think it's true here? Here is the evidence. It is true. Yeah. Right? Yeah.

And, and, and that, that's absolutely, it can, it can certainly be damaging, but it could also be true that whoever was saying that it wasn't true, maybe genuinely thought it wasn't true, you know, until they, they put out more things, you know, or I don't know how many employees Oracle has, but it's probably a lot.

Um, and, and this could just be the left hand not talking to the right hand, but, you know, in terms of, of takeaways, and we're gonna talk about this a lot more later, um, you know, you've gotta make sure if you're dealing with company with third party providers like Oracle, uh, that your contracts with them are online and they talk about what has, what, what Oracle has to do to notify you their customer in the event of an incident. Yeah. That, that's the big piece here, Eric, right?

This is the big piece for MSPs, whether it's an Oracle or Microsoft, uh, whoever. Yeah. And you, last thing I'll say and get back to Phyllis, you often talk about, or MSPs will tell you, well, it's Microsoft. It doesn't matter what I say. And what's your response? You were, you negotiate with 'em all the time, right? All the time. And, and, and I can't tell you how many times I hear from MSPs, oh, it's so and so, they're not gonna negotiate their agreement.

Of course, they're gonna negotiate their agreement. They might not like it, right? They might make it a little bit painful, but at the end of the day, they will negotiate with you. Everyone will negotiate with you. Cool. Billis back to you. Okay. We, you briefly talked about the threat actor. And so, um, rose 8, 7 1 6 8 claims, um, to, you know, they, they wanna claim, um, take credit for this, and they said they've exfil 6 million records, um, across over 140,000 tenants.

So, um, how credible do you think these claims are? And, um, you know, what does this say about cloud security? Yeah, well, so credibility, right? I feel like the more, the more things they're posting out of their angst right now, um, is leaning towards the threat actor being credible, but even if it wasn't the full picture, like what Eric's saying, what we don't know, maybe they don't know the full picture.

They're doing just enough damage, reputationally to kill the trust that Oracle has with everyone else in the media, with their customers, probably even to the extent with their employees, because their comm strategy is clearly ad hoc or reactive.

And, you know, I, I think this is a, you know, the thing we'll probably talk about, and this is like the key understanding of transparency and transparency between, you know, person to person you have a relationship with is very different from transparency and incident response.

Because there's a balance between need to know, especially during an active investigation, what you do know, what you can disclose without doing more damage, um, or impacting yourself to your customers a little bit more, while also balancing due diligence to your customers actually telling them what's going on. Yes, we're experiencing this, this is, you know, it's still under investigation. We don't know, um, likely, you know, we know they're already involved with incident response.

We wouldn't a doubt have been reached out reaching out to law enforcement and involving this because we all sm smell an Intel senate briefing, SEC filing, right? Like, we all know what's going to come more class action lawsuits. It's a matter of time. But in an active investigation, transparency is really difficult because that need to know, has to be determined, not by generally the incident responders.

You get attorney-client privilege out the gate, all the NDAs out the gate, all the Eric Tilts clone surrounding them, breach counsel, right? There's probably so many people involved that it's, without a doubt, it doesn't matter how credible this threat actor is, they've just posted just enough information to kill all of that public relations strategy that they had in place. And it's damaging from a recovery aspect too, because they could be in the middle of just getting restoration in place.

Um, so yeah. And when it comes to cloud security, this is just another example of that. We need more robust cloud security plans, not just plans, regular security audits, vendor risk, third party management audits across your multiple cloud service platforms, whatever you're using, as well as SaaS applications, as well as your internal applications you're building. Like, there are so many security audits that need to go on.

And then MDR, not to be a plug, I always have to plug this, but like having some sort of SOC or continuous monitoring of the cloud, because identity context is very different from just monitoring on-prem. You know, right now we're still 27 to one probably shifting that number even further of cloud to on-prem. So it's never going to stop. You have to do that fidelity tracking of those cases.

And cloud security is one takeaway from this, but I, I do think that it doesn't matter if the threat actor's credible, to be honest, they've, they've posted just enough to gain some credibility. They don't need to post anymore. Right? Right. And so when you talk about cloud security, you know, let's, you know, let's get your commentary on, um, you know, when anything is inter internet facing, you know, the likelihood of it getting exploited is pretty high.

So what do you wanna say to MSPs who are quote unquote, too busy to do that continuous monitoring on their clients' firewalls, VPNs, like you said, you talked about SAS and all these things. Well, unfortunately, we have to evolve. We have to adapt into this new world. Um, this would be my big push always for, you know, the, the phrase of the year of looking into is exposure management and posture management. And it goes back to the basics.

If you don't know what you have, if you don't have visibility on it, then you don't have actionable intel. That's valuable. MSPs need threat intelligence, they need posture management, they need these things, but how do they do it in a way that is of ease to them and the vendors that they are working with? Um, if you don't know what you have, if you don't know the assets, you don't know the platforms, then you don't know what vulnerabilities are sitting out there.

And the other side of that is, right, that that's actionable intel that they can use to be able to harden their attack surface. But what's an interesting flavor of intel are public breaches like this that say, Hey, how do you look internally to see, even if these services are related to you? Like we said, we don't know the outcome of this breach in particular, in the impact of it.

If it's just, you know, exfiltrated data that's gonna go live and it's not a bigger deal, or if it's deeper than configuration files, if it's a deeper supply chain attack where there's a, some sort of SolarWind situation where it's a backdoor that gets implemented. You know, having those discussions internally is difficult.

But I think MSPs really need to focus on the concept of posture manager, which is visibility, and then it's context so that they have more control over being able to manage, you know, multi-tenant situation, vast amounts of customers and networks, but they have the visibility of it. Um, because these aren't gonna slow down, right? We're not gonna slow down on some of these, um, zero days or vulnerabilities hitting the edge appliances.

Um, this is not gonna slow down, but we also have to consider things like this, which are cloud services and cloud-based vulnerabilities that are inherently going to continue to happen. Um, and so focusing on normalizing the MSPs, what that actionable intel is, but also continuous monitoring. I mean, it's, right, security's a journey. It's not a destination we have to, it's the cloud is a bigger proponent of that right now. It's proof that we, we really need to monitor it all the time.

So I'm gonna modify the last question to you just a little bit. You know, we talk about threat intel as you know, many MSPs aren't super mature and aren't, you know, so like how, when you talk about actionable threat intel, how is it that that organizations can get actionable threat intel? How is it that they take that action if you yourself are kind of immature? You know, because we always say, oh, you know, get this threat intel, do this, that and the other.

And so often we hear, well, it's noisy. I don't need more data, I just need some, you know, something actionable. How, how is it that, um, we can help MSPs? Or what is it that MSPs should be doing to get that actionable threat intel? Well, so it's a little thing. You know, one thing, it's shared responsibility without using a cheesy term. Uh, but it is shared responsibilities. You, it's, it's looking at the vendors that you work very closely with, specifically MDR vendors.

They know everything inside your closet, right? We can see it all. We may not have access for remediation aspect or to be able to perform the hardening for you, but we can give you enough context to what your risk profile is related to some of the intel that we often see actionable. Intel allows that communication to go over to the MS P saying, Hey, you use this product. This is something we do, right? We can scan our client bases. If we see a vulnerability that's got a nice 9.

0 CVS score, we're gonna be able to do some internal scanning, and then we're gonna do a lot more white glove hands-on, like, you need to patch this now. Um, if it was something related to the screen connective actionable intel, Hey, we've already totally isolated this, this access in the server, but we're calling you right now to help to, to let you know this is, you know, DEFCON one type of level, we need to work together.

So there is this both shared responsibility, but then agreed upon collaboration that needs to occur. I, I think a part of that risk third party vendor management we're talking about too, is going through some of those third parties, you have partnerships or you use their technologies and seeing what intel offering they give you, that's gonna be valuable. An email in your inbox isn't necessarily going to be valuable.

However, if they're willing to call you up and be on the phone with you and actually give you insight to what you are not able to see across, especially for MSPs across many environments that's actionable. And that's helpful. The other thing is, you know, just with within the visibility or within the context of determining intelligence and having some sort of fancy word, like, do I need to build out a program?

No, not necessarily, but you should have an internal process for remediation and like continuous hardening that you have a dedicated process team people who can do that. So that you're working in, again, a more functional routine of we've got this intel, we can see visibility into all of our environments of our exposure management, and now we can move over to this team to say, Hey, we're putting in tickets. We need you to do X, Y, Z.

In the meantime, we've worked with our SOC and they're doing critical heightened awareness monitoring of it. So I think when we think of intelligence, we think it's some sort of fancy magic wand of a program we need to build, but that's not necessarily the case at all. It's just defining the processes both internally and those collaborative processes of shared responsibility and divvying up the workload and just being aware of it.

And that's, you know, actionable is one thing, but for us it's also proactive. We're giving you actionable intel because we've already spent the time proactively scanning, hunting and triaging to look for potential, um, you know, impacted environments or targeted environments. Um, but that's our responsibility, not necessarily the MSP's responsibility. Awesome. Thanks. Over to you, Bob. All right. Hello Mackenzie. It's good to see you. I know, it's good to see you too.

Um, so you know, again, you were talking about in terms of security posture, you know, with a breach like this, I mean this, like you said, this is a time that other people can kind of learn from it. What do you feel like are kind of best practices as it relates to enhancing cloud security? Yeah, so again, just visibility. It's back to the basics. It's understanding, um, all the cloud platforms you use, single sign-on, various ones that you've chosen.

Unfortunately, people tend to do a lot, especially for MSPs, it's gonna be pretty disparate across all of their environments. So doing those security audits, regular ones in conjunction with continuous monitoring of your cloud environment, but also those, that's important. But I would say especially with the SAS sprawl, we world, we live in primarily a lot of people are still using hybrid environments and federation services.

We may not be able to scan for every single cloud service that exists out there. So it may be more difficult to do white glove notifications from our stands. I think that the best thing you could do, especially with knowing how prominent cloud cases are for us, for our SOC compared to on-prem only based exploitation, is having that conversation with your provider and with your partners of understanding exactly, you have your detection mechanisms that are applied. How are you hunting?

How are you, how are you validating the alerts that are coming up from a cloud basis? There's nothing in the rule book that says you can't have conversations with your provider of how they do things. And I think that that's extremely important. We obviously love a more comet situation where they have their own IT or SOC or a small, small internal where they have access immediately. They can understand and translate and see the things we are seeing.

But you still need to, if you are doing that 24 7 aspect, you need to have conversations to say how exactly are you performing these cloud triage, cloud response case triages? Um, what does that validation process look like? What are you looking at? Because not every cloud response flavor is the same. And if you don't understand that, then outside of us disabling an account or resetting a password for you, right? That context isn't helpful.

So I think the best practice is, you know, again, third party risk management, in this case cloud security hardening and continuous monitoring. But having those conversations of what is our cloud footprint? What does it look like? How are we protecting sensitive data within these environments? Who are our privileged users and what does that privileged access, authentication layering look like? And then who is our soc? What are they looking at and how are they determining that?

And what does that communication process look, look, look like for us to remediate more left of boom, hopefully, right? And less right of boom. So as far as best practices go visibility and start opening up the conversation that there, again, there's no rule in the playbook place to start. That's if you can't do it, right? Yeah. So I mean, you know, the, in watching somebody like the size and the scale of Oracle, um, because this reminds me of the SolarWinds, you know, incident as well.

You get a lot of third parties who wind up getting involved in being a part of that investigation. Um, you know, the, the FBI doesn't show up unless there's a real reason, but in this case, they showed up. So there is a real reason. So the, um, but the question is what do these external agencies, how, what part do they play in general about investigating an incident of this scale and then, you know, how does one go about collaborating with them as part of the process?

Well, I do think it comes down to like a culture issue, to be honest. 'cause I've worked with enough companies where they were like, no, we don't wanna call the FBI because they're afraid calling any law enforcement will actually expose them to more risk. And then Eric's on the phone with them. Um, so they, they, they typically may not wanna go that direction. But it is not unknown fact that having these communication plans includes these external entities.

An incident response team is really valuable. This is just another day for them. So they know what they're looking at. Like especially a mature one, something like CrowdStrike or Microsoft or IBM's team or Palo Alto's, unit 42, right? They see this all day every day. And unfortunately they're just sort of a fly on the wall to business decision makers when it comes to the actual things. However, it doesn't mean that they don't have good advice.

'cause they have, they can give the consultation of what they see and what likely the patterns of what an adversary would do based on actions that that victim org takes for the FBI and for law enforcement, we get this a lot actually. We'll get some partners that will reach out to us that says, do you have an FBI contact? Because even if it's like a smaller security incident, but we could, we're able to do attribution like, yeah, everything's fine. You're not really right.

A boom, you do have some level of compromise, some level of exposure, you should look into it. And then maybe we were able to do some sort of light attribution to say, you're being targeted by this nation state or by this ransomware group, here's their profile. Right? All that information's overwhelming to them. And then they'll be like, do you know someone at the FBI? It's like, I think there's a lot of them, but we will try to pack one down for you. Having it plan in place.

A communications plan includes where you bring in those external, you know, based support. Yeah. And that could even be external general counsel. People forget about that. Uh, that goes inti inside with your in internal general counsel as well as your breach council. That could be, um, external public relations or marketing firm or communications firm.

I mean, we're already throwing out enough NDAs that there is, there's no rules to how you need to form your support and what is considered need to know and disclosure. And the FBI gets a bad rap sometimes with, without bringing them in. They've seen a lot of these and they can provide more assistance than most people realize.

Um, so I, I would say when it comes to the collaboration between those two, as long as you have things like a plan in place, attorney-client privilege, NDAs, everything, understanding the IR team is limited in their role, but they are great consultants and what they've likely seen like that is the best type of preparation, um, an organization can do. Yeah, I agree. They're there to help, right? So, um, we've worked with 'em in a couple instances.

In some cases they notify us of things that they're seeing that to warn us and say, Hey, you know, we see things that are related to your network and they're showing up in some places that you don't have access to. Yeah, you might want to just be even more vigilant or go check 'em out. So, I mean, they really are there to, at least our experience in our regions, they're, they're there to help and they are on the list.

Um, most people don't know that you usually have to talk to your local law enforcement before you can talk to the FBI, because that's part of the procedure that the FBI follows. You know, be sure and follow that, that order of operations. And you're not wrong. There's so much involved in an incident that is not typically understood until you're actually into that thing.

You know, things like employee, how they feel, the stress, the communication plan, both internal and external, you know, the cyber insurance, how that plays, how you should really have that configured on the front side. All those things are really critical elements that you just don't get until you get into the weeds on having to deal with one of these things. So anything you can do to practice or talk to other people who are experts at it, the better off your organization's gonna be.

Because I can tell you now the next question I got, I'm, I'm, I'm gonna rephrase a little bit because as far as comm plans go, I think we can all agree this, this did not appear to be an ideal communications methodology for a mature organization. I know they're strapped for cash, but it seems to me that they could have probably, probably had something slightly better, you know, in their playbook for that. So why don't we talk about it from, from this direct perspective.

How would a, how would a company go about ensuring transparency and maintaining customer trust in the situa? What's the, what should be the best view of that apple, in your opinion? Bob, let me just interject. They're focused on protecting TikTok, you know, that that's where the, that's where the focus is. Yeah. So first and foremost, the, the other thing that does TikTok is bombs. You might want to figure out which one you're actually fooling with.

I think they're playing with both at the moment. It'll Be fine once Elon Musk buys TikTok. So it'll be fine. Everything will be good. It'll Be fine. I think, uh, a signal chat, first thing you gotta do, right? Start a signal chat. Make sure you name it what the incident is so it's very clear. And the more emojis, the better to emphasize emotions. Um, yeah.

So I mean, like I said on the concept of transparency, transparency and incident response is very different because there is, it's an active investigation and inactive investigations, you may not know the full scope and damage or impact, and that means you may not know what recovery efforts or restoration efforts look like. So you are sort of between a rock and a hard place before you have need to know who needs to know.

And then also balancing that fine line of notifications out to your customers. And do you notify during an investigation and or are your lawyers telling you mm-hmm. Wait on it. Um, obviously in this case, there was, this is a really great bad example of how to respond to a threat actor. Um, a hundred percent. And I do think that the threat actor was probably making a lot of demands, a lot of urgent, and they just cut off comms.

And that was just, you have to realize you're, you're, you know, negotiating with someone who's, you know, holding a bank hostage, right? Like you're, you're dealing with a little bit of a hostage situation in some case. So by cutting off comms could be even more damaging. Yeah. Um, I would, In my mind, you're just ta you're taking on too much risk by not communicating something, right? Yeah.

So you just need to be, but there are, there, you can craft the language, you can get help from whatever attorneys you have available to you. You can craft language that at least keeps people notified that yes, something's going on. We don't know what it is yet, but we're in the middle of an investigation and we'll update you as that becomes noticeable.

And then you also have to have, if an individual company sends you a a request, you gotta be a way to show an audit trail between them asking it and you answering it. Yes. Otherwise you're taking on more risk, right?

So having a process where there's one way to communicate and then whatever the official blurb is that's, you know, blessed off on by, you know, the, the group that is actually dealing with the incident is as long as people in your organization know to follow that rule and that rule only, um, then you can minimize the risk. Yeah.

But if you don't tell them something, they're gonna make up a story and then you're gonna have a hundred variations of stories floating around out there and you it, that's a lot harder to deal with than if you were just saying, Hey, well look, we know we got something going on. We're not sure of the extent we're gonna have to dig into this. It may take us a while, be patient. We'll keep it as informed as long as possible. Right?

I mean, that's as simple as it needs to be to kind of keep the stories from going this bad, which this one obviously did so Well. When we talk about comm strategy, like you said, people forget that a part of that strategy is internal comms to your individual business units.

Because you have to understand, and this was a big one during tabletop tests back in the day, um, which was understanding the individual business units and the processes that they have, because their communications are gonna be very different. They, if it's a sales org or finance or something and there is loss of access or a disruption in a service that requires them to do their job.

If you don't understand that process, then you're gonna be kind of left blind and you're gonna spend, again, more time creating up with some sort of communication standard. So you have one aspect where other business units may not be impacted, while some business units may be directly impacted, and they're going to have to understand how to explain that in an appropriate manner, let alone the company leaks.

We've seen this time and time again where employees are the ones out there being like, oh, snap ransomware, blah, blah, blah. Lemme just post it on LinkedIn. I mean, I haven't seen it in a few years, but I have seen it before where they were like, our company got ransom today. Like, okay, immediately fired. So Yeah, The internal comms are just as much risk to a hundred percent than just the external comms.

'cause we can, we do better when we, you know, we got NDAs in that place, now we're looking at employee contracts and there's, I think that's a tabletop test that would be an interesting one, Bob, is everyone sits down and it's a communications. I've done these before, the executive level ones where you're like, here's how bad it is now how do you, how do you not spin this? How do you get out of this? Yeah.

What is, well, we, we, we do, we do have a few of those in the games that we play now, right? Because we show that that's painful. I don't care what you think. It's painful, right? So, yeah, because it, it takes up resources to deal with. So anything you can do to keep from having to chew resources up while you're working a real problem, it's just beneficial. All right, Phyllis, I'm handling it back to you. Sorry, I had to unmute myself. I was, I was enjoying, um, Mackenzie.

So Of course, So Eric, um, uh, under the SEC's new cybersecurity disclosure rules, um, what do you think about how Oracle handled this? You know, so I think we beat beat it to death, but just to summarize, publicly deny then, you know, confirm it privately, you know, what, what does this mean from a regulatory, um, standpoint? So from a regulatory standpoint, you know, maybe they've, they've run afoul of, of regulatory requirements from a, from a, a, a, a public sentiment standpoint.

I think that we can all agree that, that they certainly could have done things better. But you know, if you look at the, the regulations and, and believe me, I've looked at the regulations, um, there's a lot of complexity. It's not as simple as there's a security incident, therefore we need to file an eight K, right? Um, and for those who don't know, an eight K, it's just a statement of material events that, that, that public companies are, are required to follow or required to file rather.

So, you know, they get a new CEO that's a material event. Um, they get a new purchasing guy, that's probably not a material event. So, so what the regulations require is that you req is that you file an eight K, um, usually when there's an event, but then you have to look at all the complexities because not all of the rules apply to everyone equally, you have to look at whether the company is considered in, in the, the critical infrastructure sector.

Um, if they are, they have more stringent requirements. If they aren't, they have less stringent requirements. So assuming Oracle is not in the critical infrastructure sector, the general rule is that you have four days to file after, not after the event, but after it becomes a material event. And we'll talk about that in a little bit. So They are, they are critical infrastructure though, just fy they are, yes. It sector is critical infrastructure, All of them. Yes. Yes. All right.

So what are their filing requirements? Right? So you have to file within four days. Um, and, but it's four days of determining materiality. It's not four days of figuring out there's an event. It's four days of determining materiality. And we'll talk about that in a, in, in a little bit. But then there's this get outta jail free card.

And, and we were talking about this a little bit before the, the show today, the get outta jail free card is, look, if you think, if you're a public company and you think that you are somehow going to be prejudiced by this reporting requirement, you can pick up the phone and call the Attorney General and say, look, Mr. Or Miss Attorney General, here's the facts. Here's what happened, here's why I don't want to report. Um, so the attorney general then says, yay or nay, right?

And then if they say, yay, then then you can delay this reporting. If they don't, then you can't, then you do have to file the ak. So, so there there is a lot of complexity because I mean, you think about all the, the, the, the security incidents we've all been through. If we had to disclose the security incident within four days of figuring it out and tell the whole world, Hey look, we've had a security incident, um, that could be bad.

It could be bad for us, it could be bad for the public, right? So, so there's a, there's a balancing act there. So can you tell us then, what is a material cybersecurity incident? Because, um, you know, in my mind it like, seems pretty significant. It seems like it caused significant damage. And when you hear like, oh, you know, this many things breached and so on and so forth. Yeah. Um, it sounds like this was pretty substantive.

So I can tell you what a security incident is, but what is material is different from company to company to company, right? That's such a lawyer answer, but okay. Yeah, I know it's true. And I'll tell you why. It, it's, it's true because it, the, the regulations and we're talking about the SEC reporting regulations, they, they have a definition in there of a, a cybersecurity incident.

And they define it as, and, and I'm quoting this, it's an unauthorized occurrence on or conducted through a registrant's information systems that jeopardizes the confidentiality integrity or availability of a registrant's information systems or any information residing there, right? That's a pretty generic description of what a security incident is. So now we think about materiality.

Every company out there, you know, all public companies, some private companies, they have materiality thresholds. And, and you look at a potential loss, for example, one company that has a loss of 250,000, $500,000, it might be material that same loss applied to a different company might be immaterial. So every company you have to do an independent investigation of what's material or what is not material. Um, you know, and, and we can, we can make up a thousand different scenarios, right?

If if all of the information that was allegedly exfiltrated here is encrypted information and they can't get it without the keys, probably not material. Um, if it's unencrypted, PHI and there's 400,000 incidents or records of unencrypted PHI, well, it probably is material, um, where you draw that line, that's a decision for the company and its, its lawyers to make. Okay? I mean, just outta curiosity, can the SEC come back and be like, no, you're wrong. It is material.

'cause like if it could absolute, I was a company, I'd be like, not material. Not material. Yeah. And, and then you argue about it and, and, and it's, it's ultimately a decision for the prior of fact. Um, you know, I don't know if I'd wanna get into a dispute with the SEC about what's material, right? And, but you know, you look at what a reasonable person would think and what they do, and, and that's kind of how you'd, uh, you'd make that determination. Okay. Over to you Mackenzie.

Oh, for me, for which one? Do I have questions now? You have questions for Eric Girl? Oh, You're right. I totally do. Uh, alright.

Oh, well, we've kind of talked about this a little bit, but Eric, when it comes to MSPs and it comes to learning a nice lessons learned from this specifically, um, how would you recommend they prepare their incident response plan, especially when it comes to breach disclosure language, everything you're talking about about material, and I, I feel like I've had this experience in the past at, at the government level, the attorney general was like 48 hours, right?

If you can prove for sure there's material evidence that you had a breach and that 48 hours was very valuable. So how would you recommend MSPs work with their incident response plans to prepare during this language? So, so I think that you have to look at your, your, your, your agreements with your customers and what are your agreements with your customers require, and then that will guide your incident response plan.

So if, if you look at this, I think that there's, there's two big things you have to look at. Number one is what do your agreements with your customers say about your information security requirements? Do they say anything about your information security requirements? I can tell you that, that when I get ahold of a new client, a new MSPs, MSA, it usually doesn't say anything about information security requirements.

So for those that do, there's usually a, a statement that's, that's, you know, to the effect of, you know, the MSP is going to implement, you know, reasonable and appropriate safeguards designed to protect the confidentiality and availability of their customers data, right? That's a pretty generic way to say, look, we're gonna use commercially reasonable efforts to keep your data safe. Right?

Well, that's not just, well, we're gonna use a firewall, or we're gonna use EDR and we're gonna have a SOC and we're gonna do this. Right? Part of that, part of these, these administrative controls you have to have are, and you talked about this this earlier Mac, you know, do you, what do you do to gauge risk of your supply chain? Right? Do you do anything? Do you just look at SOC two reports? Do you just check the box if they have a SOC two report? Even if you don't look at it?

So, so you've gotta be really, really careful about what you're agreeing to with your customer, because your customer will hold your feet to the fire. If you say you're gonna maintain appropriate security controls that are designed to keep their, their their data safe. You have to go upstream and make sure, and, and we'll talk about this in a little bit, but make sure that your agreements with your suppliers, with your supply chain have similar language that you can rely on.

The second thing that, that you have to pay attention to are what are the reporting requirements? And we've talked about this as it relates to Oracle, but what about it for the Ms P, if the MS P becomes aware that there was some exfiltration of their customer's data, whether it was because of the MSP's own misdoings or because of something in the supply chain, what obligation do they have to tell their customer about it?

And this is where I often see a disconnect because they'll, they'll have an agreement with their customer that says, well, we're gonna let you know Mr. Customer within, you know, uh, two business days, three business days, 72 hours is A-G-D-P-R standard. Right? But then if you look up at your agreements with your cust, with your, your vendors, does it say the same thing? Um, and, and that's what the MSP has to, to be of.

So it's safe to say, as a takeaway, your MSA should include some sort of breach language in it. Not just breach language, but also just information security language. Absolutely. But, but Eric, this what you just said, these points one and two, I just want to really double down that Brian Blakely talks about, right. And that this is where the, the gold lives for MSPs in sales conversations, not about security controls.

You know, talking about the business requirements and contractual obligations they have upstream with their biggest customers. Like that is a, that's an intriguing conversation to some, to a business leader, an executive, when you talk about a company that maybe represents 50, 60, 70% of their revenue. Yeah. Like that's a conversation they'll talk to you about and have interest in protecting that revenue. Yeah. Not, Hey, we need to get MFA everywhere. We need to SSO everywhere.

Not trying to be sarcastic to everybody. I'm just saying that's where you can get an executive's attention. Yeah. Especially 'cause when that executive goes home at night and turns on the news and they, they hear about this Oracle issue, and, and then you're gonna talk to them the next day or the day after about these supply chain issues. Absolutely. It, it gives a, a ton of credibility.

And lastly, it's about, you know, as Brent Adamson said it, right, a boom, it's not about telling, it's about giving them the right questions to ask for their teams to get alignment. Right. And, and again, if, and it's this nuance, people are like, well, we do that, and it's like, no, I've heard enough sales conversations to know yet you, you know, it's pain money decision and or banned or whatever. Tick.

No, it's, these are the, like, we work with a lot of companies just like, here's, here are the questions that you need to ask yourselves to make an informed decision about risk. Yeah. Are you willing to take on this risk with your largest customers that represent X amount of your revenue? Sure. And here's the things to go through and look at. Yep. Well, I think that ducktails in the next one I have, how should MSPs be advising their clients when it comes to third party cloud vendor risks?

Especially with the context of the SEC disclosure. Is it enough to say, you know, we use Oracle, or do companies actually need to have like a legal responsibility to monitor and report upstream now to their clients? So it, it's a great question. And, and, and before I answer, I gotta get outta my soapbox for a minute. And, you know, I represent about 400 MSPs around the world and, and MSPs as well.

And I would, I can probably count on two hands the number of my clients that have me or have some attorney review their third party supplier agreements. The vast majority of MSPs, um, don't, they either don't read 'em or they don't think they can negotiate them, or they don't wanna pay a couple bucks to have someone review it and they just go ahead and sign it.

And, and that can be really, really bad because I talk to my clients all the time about the fact that when something goes wrong and, and oftentimes it's gonna emanate above you, it's gonna emanate from your supply chain, you know, something goes wrong, it affects you, therefore it affects your clients. Well what happens? Well, I can't protect you a hundred percent. Right? I could, but you'd never get any business done. 'cause you know, what's, whatever, signed your contracts.

But my job is to make sure that if you're left holding the bag, at the end of the day, that bag that you're left holding is as small as possible. So how do we do that? We make sure that our third party supplier agreements aren't promising us any less than you're promising your customers, right.

To make sure that that risk appropriately travels from your supply chain through you to your customer, and that when your supplier screws up, like maybe they have here, that you have, your customers might have recourse against you, but you're gonna have appropriate recourse against your supplier as well, and not enough MSPs pay attention to that.

Um, and that I think is, is, I mean, you know, we've heard about the Kase and the SolarWinds and now the Oracles of the world, um, that's where things like this can, can go awry. Right? I would imagine So I also think too, um, on that is we're not looking at, you know, you view it from a liability and a notification stance, but some of those vendor reviews, I mean, we even go through before we purchase any sort of new product or tool that we're gonna be using internally. Yeah.

We have our security and compliance team look through the agreement to understand exactly what that tool does, but what it has access to. Absolutely. These agreements that can change a lot if it's having access to sensitive information. Yeah.

Versus just having access to another system where, hey, we can do a lot of, uh, you know, uh, reduction in risk just by knowing all we have to do is turn off that one vendor tool versus that one vendor tool runs our most important infrastructure so we can't turn it off. And then the liability aspect in that language becomes more Important. Yeah, no doubt.

And, and you know, I would say that less than half of the vendor contracts that I review, um, have language about reporting requirements of security instance. Sometimes they'll, they'll say, you know, they'll have the generic security statement that they're gonna use appropriate control of design to keep the customer's data safe, but still time don't even have that.

But those that do have that don't say, don't take it a step further and say, look, if there is an exfiltration, we're gonna notify you. We're gonna notify you at all or within a reasonable period of time. And oh, by the way, we're gonna indemnify you if that breach was our fault. Um, the vast majority of vendor agreements don't say that, but, but to your point, they, uh, they definitely need to. And, and you're right.

My, my customers, my clients are, are tired of me asking when, you know, they'll send me a contract for review. It actually happened this morning. One of my large MSP sent me a, a new vendor contract for review, and they said, Hey, can you review this? And I said, no, you need to tell me what you're using them for, what data they're gonna have access to. Are they gonna have access to your data, your customer's data? Both.

Um, it's, it's very, very important to, to just peel back the onion a little bit more than, than you normally might. Yeah. Yeah. Wow. Awesome, Eric. And, and, uh, you know, I know we gotta end there, but boy, couldn't you take that to a whole extreme to start talking about access to data for LLMs, APIs, et cetera. I mean, there's a whole treasure trove and Bob, we talked about having Sunil at write a boom 26 on this latest Sands, uh, report that he wrote. So stay tuned.

Uh, there, um, Eric in closing era, ed choa put in. Eric, how about a bullet list of the top X things we should look for in a vendor agreement? I don't know if you would do a blog on that or something of that nature if you've done it, but, uh, yeah, I can put something together absolutely free legal work. Yeah. Oh, no, happy to do it. Yeah. Yeah. Um, so, so, so Matt, first of All, thank You for, uh, coming on and, uh, really, really fascinating looking at all these angles.

Uh, Eric, thanks for sharing the legal, and Bob is always thanks for jumping on and, and, you know, sharing your expertise, expertise from the MSP Phyllis, wonderful to have you back. And, uh, wishing you all a fantastic, safe, healthy week ahead. We'll look forward to seeing you, uh, next Monday. Take care everybody. Thanks everyone. Thanks Al.