Security Working Backwards Through the Kill Chain with Conversant Group’s J. A. Smith

This is Textron tv. Well, the great pleasure of being joined by John Anthony Smith. John is founder and chief Security Officer with Conversant Group.

Welcome, John. Thank you for having me. Talking about one of my favorite subjects.

We'll get into that in just a moment, but tell us a little bit about, uh, conversing Group and what you do there. Yeah, so Conversing Group was actually born as an outgrowth of my Passions for Defense. Uh, so, uh, I actually founded the company 15 years ago with the intent of, uh, preventing breaches to say it simply.

And, uh, about a year into our company's, uh, founding, actually, we were presented with the opportunity to help an organization, uh, recover from a breach. Um, what, as we all probably know at this point, organ Breach Patterns started shifting. Uh, years ago, uh, it was said that, you know, from the time an attacker initially gained access, they would usually be in the environment siphoning off data for six to nine months.

This was a common thing to say, but about 10 plus years ago, that trend started changing and threat actors started becoming far more destructive. And it obviously they were financially were and are financially motivated. So that actually forever changed our trajectory because what we learned early on is that breach context is absolutely critical to actually properly assess and harden defenses.

So Conversant Groups brand, and now all of our subsequently born brands from Conversing Group have come to be known, uh, for actually breach recovery, breach context assessment and breach context born defenses. And so that is the focus of Conversing Group, is we actually prevent breaches by leveraging what we learn from working breaches. What a great place to do it from, unfortunately, that, that it happens, but fortunate that you've got that, uh, knowledge and experience to build it from, you know, I think that's one of the challenges of most organizations is, you know, we used to believe, you know, well, if we get breached someday, now it's yes, we all have and, and will continue to get breached.

It's, you know, what do you have in place and also how do you respond to it? I'm really curious about what have you learned? Maybe, maybe what are we doing wrong with, um, how we respond to this?

'cause a lot of people have to pay ransoms. A lot of, you know, not too good outcomes happen when there are breaches. Yeah.

So I'll explain that a bit. So from Conversing Group has been born three other entities. Phoenix 24 is the one I'll speak of, uh, immediately because it's important in the context of your question.

Phoenix 24 has helped hundreds of organizations recover from reach. But what we see play out time and time again is that o eight out of 10 companies plus have no path to a recovery except to pay a ransom and unfortunately paying a ransom and is a horrible way to recover an organization from a breach. And so what I would say, what in, in, in response to your question as to what are we getting wrong, we are not collectively making the assumption that a breach will occur, and from that paradigm actually orchestrating our systems to survive.

And so what do I mean by that? If you do in fact assume that you will be breached, then you should be spending a tremendous amount of time limiting the ability of an attacker to massively destroy your environment simply. And you should have confidence in a recovery.

Eight outta 10 companies that we recover from breach have no path except to pay a ransom. Why is that? Because they're not orchestrating their backup defenses from a breach context.

Traditional backup products, which are commonly used in organizations, uh, products like Commvault Veeam, uh, and things like this, uh, not that there's anything flawed of those particular products, but to orchestrate them from the breach context requires a different way of thinking. It does not mean that you follow the best practices given to you by Veeam and Convault because they don't have breach context either. And so if you follow the vendor's guidance just about for any product, uh, related to backups commonly, your backups will not survive.

And so to answer your question, what are we doing wrong? We're looking at hardening our defenses in the wrong direction. We should be focused on protecting our data from being destroyed and masked and guaranteeing a recovery first before we do anything else.

I am not saying you shouldn't have MFA, uh, at rest encryption and things like this, but we sure do spend way more energies on that than we do on guaranteeing a recovery. If I would describe it as kinda like all the things we have in place in terms of defenses are kind of for not, if ultimately we can't recover as a directory, if that's what gets, you know, ConEd out in a, in an attack, um, it is kinda like just the general backup scheme is make sure you could restore from a backup, right? You're taking it a whole nother level, which is make sure you can recover from a breach from something that's tried to get access to that and potentially destroy it.

Yeah, I I'll say, you know, there are essentially three types of recoveries. There's the recovery that we're all familiar with. User delete something, override something, messes up a file, it needs to be recovered.

Then there's the recovery that we talked about for years. I will call these DR and business continuity recoveries, right? A fire, tornado, hurricane flood has destroyed the data center and we need to bring our operations back online in a secondary facility.

What it changed over 10 years ago now is that there's a third type of recovery called mass destruction. Threat actors gain access to your environment and they massly destroy your data, your servers and everything that provides facility for your users to work. Unfortunately, nearly no one has orchestrated their controls in that context.

And so while most companies today, uh, arguably have restoration capabilities for, uh, recovery type one and recovery type two, nearly no one, eight out of 10 have no facility for top number three. And so, uh, to your, to your point, um, we really have got to refocus our efforts, and I would argue that most defenders are at a disadvantage. Why?

Because breach context largely gets locked up by lawyers and it's not publicly disclosed. Right? And so how do you know how to orchestrate Commvault being Cohesity, rubric, arons, whatever it is, you're backing up your systems.

How do you know how to actually orchestrate that to prevent a, a threat actor from destroying your backup and recovery capabilities? And how do you know how to actually reduce the likelihood of mass destruction if you don't have breach context? You can't get it.

You can soften off bits here and there for some of, from some of the public disclosures and what gets leaked, but largely the data is locked up. I I think that one of the ways, um, that mass destruction happens is encryption of your, somebody encrypts your backups in a way and you have to pay for the key. Are there other types of mass destruction things that could happen to your data or What are those?

Yes, sir. Absolutely. So, uh, as you, if you were to trace the history simply of how this came to be initially, uh, when encryption came on the, on the scene, and then they were holding data for ransom, it initially was localized encryption.

They would encrypt a pc and then eventually they started encrypting the shares for which the user had access to. And then eventually, rather than doing that, they actually, um, actively acts the environment. So once they gained initial access, they started moving laterally and then encrypting en mass at the OS level.

What has changed now is it's no longer that simple threat actors not only attempt encryption at the OS level, they also attempt encryption at the hypervisor level. So if they can gain access to VMware Zen server, hyper V, Azure, AWS, Google Cloud, they will attempt destruction and encryption actually, of the underlying virtual files themselves that actually host the data, right? Vmd ks in the case of the ware, mm-Hmm.

Second, uh, secondarily be, uh, to that, those things, uh, we've seen a trend over the past year plus of threat actors being far more willing to not only encrypt data, but mass delete data in our recovery practices. We see groups now, if they get any indication whatsoever that the organization will not pay a ransom, they commonly, you can call it childish, you can call it whatever you like, but they start deleting data. Uh, it, you know, you would, you would say, well, why, why are they doing this?

If they're financially motivated, why would they start deleting data? Then? There's no intention of the client, there's no reason for them to pay the ransom is because they don't care.

Mm. Um, I mean, there's all kinds of reasons. I'm sure.

True. They simply don't care because they've just, they've hacked several companies. They're just get trying to find one to pay.

You might think of this as, um, someone kidnapping and sending a finger to the parents of their victim, right? Um, or whoever's supposedly to pay the ransom for the person that's been kidnapped. This is a similar tactic, right?

They're essentially cutting off the finger, or in this case, deleting the data to try to invoke an action. And so what we see, Mitch, is that they, they are very willing to delete today. We've seen them delete whole volumes, whole file servers, whole servers in Azure, um, and actually delete blobs and, and also buckets in Azure and AWS Interesting.

Yeah. I can see it as if you were just going after one victim, you're gonna do whatever to try to get them to respond. If you're going after wide numbers of them, which they are, okay, so you don't respond, I'll move on to the next one that will Right.

Go on to the easiest victim or easy, easiest organization that's gonna get to respond. So not everyone, not everyone will, will end up paying. Well, tell us a little bit.

So you've described about kind of thinking about this completely differently. Don't think about it as a normal backup strategy, right? A backup and restore recovery.

So put us in the mindset and sometimes it's hard to kind of flip it and, and let's have a different mental model about how we think about this. Introduce us in, introduce us to that thinking. How would we start to think about this differently?

Yeah. So the, the attack pattern is essentially this, I'll walk you through the breach pattern. The breach pattern at a high level exists, um, for essentially all breaches.

There are certain steps, they mock skip, but essentially the pattern is the same all the time. All breaches are essentially the same. Uh, the first step is the threat actor will attempt to compromise credentials.

Uh, a compromised credentials could also be they leverage a vulnerability in a publicly exposed, um, say net Citrix NetScaler or A VPN technology like Florida client, uh, just insert any VPN technology here, right? Then once they've gained, uh, access or an ability to log into a system, then they attempt to actually establish persistent access depending on the nature of the vulnerability that may grant them persistent access in and of itself. But what we see threat actors commonly doing is once they gain access to an endpoint, a server, whatever it is, they will install a tool, a remote access tool, usually a commercially available remote access tool so they can keep coming back.

Once they've established persistent access, they will attempt to elevate access. Uh, what this means is essentially they will try to harvest or privilege credential from someplace, either off the machine, off of shares, off of password vaulting technologies, whatever it's may be, leveraging that credential, uh, that they eventually will find. I can assure you, they will find it.

They will move laterally. Once they've moved laterally, they will start to identify your critical data, uh, and they'll identify your backups and they will attempt to next filtration. Uh, most, most, uh, events today involve some form of exfiltration because they want to extort you, right?

They essentially don't want to just encrypt or delete your data. They want to make you pay or try to force you to pay by extorting you at the risk of dumping your data on the public internet. And then after they've exfiltrated enough data, uh, some of the events will involve backup destruction.

To your point, Mitch, sometimes they encrypt the backups, other times they delete the backups. We've seen them delete the volumes. We've seen them format disks, we've seen them delete VM dks, delete data stores.

I mean, essentially anything and everything you possibly imagine, they will attempt to prevent your path to a recovery. And lastly, once they have prevented your path to recovery, some of the events, especially all the ones that involve mass destruction or encryption, they're going to attempt that just that they're going to either delete in mass or they're going to encrypt in mass, or they're going to partially delete and partially encrypt there. And there's all kinds of mixes thereof.

And sometimes even I will tell you, they attempt double encryption, they'll encrypt the OS and then they'll encrypt the actual underlying virtual files. So it makes your life very difficult to actually recover from one of these events. And so how do you disrupt that?

Your question is, is how do we think differently? You think in reverse you don't solve for the path of the attacker. You have to make the assumption that a breach will happen.

And if a breach will happen and their intent, intent is to get to your data, then you have to begin, begin with their end game in mind, right? You start there, your system of defenses have to start from your data and work their way outward, essentially. What does that mean?

That means you have to orchestrate your infrastructure in a manner to make it very difficult for them to destroy your system simply without you noticing it, right? So if you start at the end of that pattern, this means you make it very difficult for them to get to your vmd ks, your servers and be able to encrypt them or delete them in mass your storage platforms. Once you've done that, then you harden your backup defense.

So you make sure that you have a path to recovery. You make sure that the backups will survive. And I can tell you this is a very difficult job, and it's to my point earlier in both of these categories, and frankly every one of these breach pattern tranches, as we like to call them, without breach context, defenders are at a disadvantage to my knowledge, there is only one path to actually assess your organization and your infrastructure against the breach, um, tactics of threat actors.

That's to leverage a service we have, right? We have several assessment practices that actually do just this. But to answer your question, you've got to think in reverse.

You've gotta solve for the end game. You've gotta protect your ability to recover, and you've gotta drastically reduce the likelihood of mass destruction by segmenting systems and harboring them against the breach context. Yeah, I was thinking of multiple strategies.

There's sort of obfuscation, there's keeping, you know, backups and different, different methods, different places instead of all in one service or one technology in multiple of those, right, in different platforms. Uh, Mitch, we like to say, if I could just chime in. Sure, Yeah, please.

We like to call this, you've got to obfuscate and complicate access enough that the threat actor simply gives up. And so another statement I like to say is, as an IT administrator, if you can do it, you must assume that the threat actor can too. Mm-Hmm.

And so when you say, when you ask me about how do you think differently, that's the lens you gotta look through. If I can do it as an IT guy or gal, then you have to assume the threat actor can do it as well. And so from that perspective, how are you gonna obfuscate and complicate access to systems?

Yeah. Think about it. Um, you know, if your administrators have access to all of that, that's one of the key accounts to get ahold of, right?

Absolutely. And how many breaches do you think that they get ahold of in the in privileged credentials? All of them.

All of them? Yeah, absolutely. That's what they're going for.

That's the, uh, lateral losing lateral move up, right? Yep. Tell us, uh, so tell us what, what is going through one of those assessments?

Like, uh, when you sit down, um, with a customer and say, here's, here's kind of the process that we'll go through and yes. We'll, there'll be unique things about your environment, but what we tend to do in most engagements, Yeah, there are three, there are three processes I would, I, I'll, I would name, there is, uh, one I'll start with, we call it the ransomware Backup and resiliency assessment, the RBRA. That assessment is, is squarely focused on an organization's ability to recover.

Will your backup survive? And what is the likelihood that a threat actor will be able to discover and attempt a destruction? And so in that assessment, we are squarely looking at an organization's ability to recover.

And we do that through the lens of breach. So we actually assess any backup product, the UN and the underlying associated infrastructure. To your point, Mitch, you said you gotta keep copies, you gotta store them in different places.

And these are, this is the lens that we're looking through. We actually have a principle that we created. You cannot Google this, to my knowledge, it's not on Google.

We call it five four, three, two, one. Essentially, the model is born from breach. Over the process of now over eight years, we've been building out this model.

We are assessing you in the RBRA against that model because we know that the closer you get to that model, the closer you will reduce your risk to zero of a threat actor being able to enact a destruction event that will prevent a recovery. Essentially, we're obfuscating and complicating accessing up that most threat actor groups will simply give up. And so that's one assessment.

We have another assessment, uh, we call it the A TDP, the actionable Technical Defense Plan. Essentially what we do is we look at all the breach pattern tranches working in reverse, of course, we start with mass destruction, move to backup destruction, look at data exfiltration, lateral movement, elevated, uh, permissions, persistent access, and then compromise credentials. So we have worked backwards across the pattern and then we come back with essentially a massive report and a massive planning tool of all the issues, uh, that we've discovered across all your controls and infrastructure orchestration.

I would say to most organizations, you don't want to go through a process like that until you've focused on the last two tranches first Mm-Hmm. Because those are the most important and it's those that make the assumption of breach. Right?

And so the last ASCE assessment vehicle we have is actually our hardening planning exercises, which also follow the breach pattern that essentially that is an A TDP with hardening. Rather than giving you all of our findings, what we do is we assess you in reverse across the tranches, and we build a hardening plan and we actually present the plan really quick. Any on a one to two week timeframe, we'll do discovery plus the creation of the plan, plus the presentation of the plan, and then we make a plan of action born from that plan.

So who's gonna do what and when. And then while, once we then, uh, started the active hardening against what we've already discovered, we continue doing more discovery. So essentially we work along those tranches until we get all the way to the end, or the client wishes to stop hardening systems in reverse.

Uh, frankly, uh, the hardening planning exercises are my favorite, largely because they are focused on the breach pattern and they are focused on, uh, active hardening rather than waiting to the end for a big report. Uh, we're, we're presenting that data rapidly telling the organizations what to do, and we're hashing out who, when and what, um, immediately rather than waiting weeks for a final report. It makes a lot of sense what you're saying about why not harden things first?

'cause you know, there'll be things you're gonna have to do, right? That's what that assessment art process is, and then the follow up action plan, and then Right. Do kind of the the middle path, if you will.

That way you're not going down things you could have fixed upfront anyway. So let's look at it from an improved stand, almost like pen testing, right? Let's make sure we think we're in a, the best posture we can be.

We'll do pen testing and of course then we'll find other things and make it better. So it sounds pretty similar. Um, I would, I would argue this is better than pen testing.

Oh, I'm sure it is. No, I just said Kind of because pen testing is only as good Hackers That you've hired to pen test you. Right.

And, and commonly in pen tests, they actually ask you to turn your controls off, Right? Yeah. The difference here is we're actually looking at your security controls, looking at your infrastructure and telling you what about your configuration is flowed from a breach context and what the likelihood of that configuration toggle switch of leading to your breach might be Understood.

Okay. Very good. Um, so how do people engage you?

What's, if someone's interested in finding out more or learning from your experiences working with companies that have been breached and and how to, how they could benefit from your knowledge and experience, what are your engagement models look like? Yeah, so essentially, of course we have a public website where, you know, organizations can read more about us. Um, the way, the way we engage is generally is, uh, once an inquiry comes in, we assign it to an account executive and essentially we start conversations.

But, uh, to actually get engaged with us is relatively rapid. Uh, we, um, there's essentially two paths we call it to, you can meet us in peace time or you can meet us in war time. Uh, uh, we have companies that meet us both ways.

I would say to anyone watching this video, please for the love of God, meet us in peace time. Assess your controls against breach context before your breach occurs, that you will have confidence in your ability to recover. So how you engage, email us through our website.

Call us, uh, with the number on our website. Our number's 4 2 3 3 0 5 7 8 9 0. Great.

com, correct? That's correct. Well, John Anthony, it's been a pleasure talking with you and learned a lot.

Um, I'm, I really like the approach a lot because there's so many times we spend a lot of effort on the kind of protecting the layers and we never get to the crown jewels of how you're protecting that. 'cause we ran outta time, money, resource, all of the above, right? So that's correct.

And assume that you've actually just find the problem perfectly. That's it. Very good.

Well, thank you for joining us. It's a pleasure talking with you. com and uh, John Anthony and team can give you a hand help you with that assessment.

Let's hope it's in peace, time. Take care, John. Thank you.