Real Identity Security Compromises. Real Strategies to Reduce the Blast Radius.

Review the Full Session Transcript

No time to watch the session? No problem. Take a read through the session transcript.

Carolyn Evans (00:07):

Good afternoon. Thank you for joining us today for our webinar, real Identity Security Compromises Real Strategies to Reduce the Blast Radius. My name is Carolyn Evans. I am the director of marketing at Referral Security and I'm today's moderator. Today you'll hear from two cybersecurity experts, one in identity and privileged access management, Brian Krist, who is a senior solutions engineer with reverse security and one in observability, searchability and security. Sharif Lael Elastic's principle solutions architect. Brian and Sharif will be available to answer any questions at the end of this webinar as well. So throughout, please send them through in the chat and we will get to them as soon as we can. With that, over to you Brian.

Bryan Christ (00:58):

Hey, Carolyn, thanks for the introduction. Thanks to the folks online who've joined us today. As Carolyn said, we're going to be having a discussion about how you minimize the blast radius and in the event of a breach or other incident, one of the things that I want to talk about today, just briefly before we get into this, this is not a zero trust webinar, but it would be absolutely foolish of me to not mention that a lot of the principles, a lot of the strategies that you're going to hear today are actually very much part of, if you look at NIST special publication on zero trust architecture, you're going to find that a lot of the things that we talk about and the strategies we talk about really are highly embedded and characteristic of NIST's model for the enhanced identity governance approach to zero trust architecture.

(02:00):

This slide here just simply illustrates from the zero trust journey what that looks like. Haley, if you want to go ahead and go on to the next slide. So when we start thinking about this idea of minimizing the blast radius, I think it could come across as a little tongue in cheek. It's not intended to be that way, but really the best blast radius is no blast radius, right? Don't have a breach if you can prevent it. And so kind of the cadence for our conversation today is we're going to sort of talk about this. We're going to have this conversation in somewhat of a chronological order where we talk about prevention, we talk about detection, and we talk about containment and ultimately recovery. So when it comes to prevention, again, the best blast radius is no blast radius. So I want to talk about some things that your organization should absolutely be doing to ensure that you don't have an incident breach in the first place off.

(02:59):

Eliminate passwords wherever you can. I know you've probably heard this password list is a really prevalent buzzword right now, but I give people this illustration. So if you look at the Verizon report, social engineering and phishing, they account for the lion's share of attack vectors. This won't completely eliminate it, but it certainly increases the friction. If a user doesn't know their password to something, it makes the path to socially engineering it out of them far more difficult. How do I quickly get something out of on a pick? Carolyn, she's on the line. If I wanted to scam Carolyn, how would I socially engineer something out of her that she doesn't readily know? So that makes it challenging. So we would say eliminate passwords wherever possible, both on accounts for standing privileges and also those that are highly sensitive keys to the kingdom kind of thing.

(04:01):

Again, I know folks are probably have had this drilled into 'em, but employee adaptive multifactor authentication here. And one of the things that I want to sort of harp on here is that not all factors of authentication are equal, right? So with the recent advent of things like push bombing, SMS, spoofing, those kinds of things, not all factors of authentication are equally as reliable. And then there's the other part of this, which is the adaptive. In other words, with the right solution set, you can dynamically adjust how you challenge users when you challenge them based on things like are they on network? Is this coming from outside the network? What time of day is, is it usual for this particular identity to even be requesting access? This next one, federated implementing federation. It kind of goes along with this idea of eliminating passwords. So the more that you can eliminate the passwords but then eliminate the need to supply a password, the better eliminating orphan dormant accounts.

(05:13):

This is a particularly, I guess favorite vector of attack for the bad actors. If they can get their hands on an account that should have been closed down or was abandoned and it doesn't look suspicious that it exists already, and so they can use it. Limiting standing account access. So we see this all the time. It happens in a number of ways, but I'll give you a couple of illustrations how this is violated. Sometimes in the onboarding of a new employee, help desk gets a call or a ticket and it says, Hey, we've got this new employee, and the next thing that is being asked is, well, what kinds of access should they have? And a lot of times the answer to that is, well make Mary look like Bob, which might be okay, but if Bob's been around for a long time, what if he doesn't sort of fit the mold of the employee for that department in terms of access?

(06:24):

Maybe because of tenure has access to systems that somebody in that department wouldn't ordinarily have access to. So then if the help desk is honoring that and says, okay, well I'll make Mary look like Bob, well then what you've done is you've actually given Mary a lot more privileges above and beyond what she should have. So you really need tools in place to ensure that when you provision users, you do so in those standing accounts with only the right amount of access, no more, no less sort of Goldilocks rule. This other one sort of goes hand in glove with that, right? So what I described as a manual process, onboarding users, the call, the help desk make mart look like Bob kind of deal. But even better than that is if you can automate your provisioning and deprovisioning and even your transfer. So that's another way that these kinds of standing privilege accounts get elevated beyond what they should be.

(07:23):

So if I go back to that illustration of Mary and Bob, if Bob was in a former department transferred to a new department and no one thought to tear down the old entitlements that really aren't appropriate for his new job role. And of course again, that's how you get into that situation where you say, well make Mary look like Bob. Well, if Bob came from another department and he has more than he should, so that's sort of the problem space there is that he shouldn't have carried those over in the first place, but now you've doubled down on that by cloning him to a new user. So if all of this is automated, if you have a system in place that can look at something like a transfer, look at department attributes and then make adjustments to entitlements automatically with or without the approval of a human being depending on the case, but you're doing a much better job of keeping those standing privileges limited to only the access they need, and you're doing that through automation.

(08:18):

One of the first things I talked about was eliminating passwords. So for your end users, again, providing a tool that allows them to sort of out of sight, out of mind on that, but then you have a whole nother problem space. When you look at the attack vector, the anatomy of an attack, what the actors are ultimately going for is the keys to the kingdom, right? That's where they're able to do all the really nasty stuff with encrypting all of the company secrets, the exfiltration holding it hostage for ransom. So if you're vaulting and randomizing the keys to the kingdom, we actually saw this, I won't name the name, but we saw this in a very prevalent case here recently where there was this idea that we're safely tucking the keys to the kingdom away, but they weren't randomizing it. And so that's a big component of it.

(09:11):

Make sure these things are changing on a routine basis so that even if somebody manages to gain access to something, its usefulness is very finite. Periodically, spot check all of this with certification. So if you've got automation in place, you're doing all the right things, there's still immense value in having a human being periodically audit this user population and say, well, is automation doing what we expect it to be doing? And if not, course correct. So it serves kind of two purposes. One, providing that sort of the safety net, that check and balance that we're doing the right thing, but then also if things are not quite right, you can adjust. And lastly, I know folks again probably have heard this a million times, but the human element tends to be the weakest element, and so good training for your organization is absolutely critical because in the illustration that I gave with Carolyn, even if it's out of sight, out of mind, if it's stashed away securely in some kind of zero knowledge tool with enough convincing, I might be able to have Carolyn Crack open something like Vera Safe and go in there and get those credentials out when she shouldn't.

(10:32):

And so it's really important to train your staff on best practices to identify phishing and scam and things like that. So I hope that gives you an idea of where we're coming from on the VEA security side when it comes to prevention. I'm going to turn it over to Sharif here who's going to talk about what Elastic does to help also keep you safeguarded from the very beginning. So Sharif, over to you. Haley, if you want to thank Brian to the next slide.

Sheriff Lawal (11:00):

Thank you, Brian. That was actually pretty detailed. Absolutely enjoyed listening and picking a few things from that. So from an elastic standpoint, what exactly does prevention look like? Well, it's very important to make sure that malicious actors, when they of course drop and detonate malicious software in your machine, A few things to keep in mind when these events of court, they're trying to do a either exfiltrate company secrets or intellectual property, any valuable data that you might have as an organization. Secondly, they're trying to gain access to your valuable credentials, as Brian said, the keys to the kingdom. So we want to make sure that that malware does not execute within an environment. So Elastic has got pre-execution prevention with our endpoint security as well as post execution prevention. So what exactly does the post execution prevention mean? I mean, there are a lot of intelligent threat actors. They'll build malware that are super intelligent. They'll be appropriately just to go by, get past your detection and prevention technologies and what they do when they eventually get past, they will now start executing malicious code. But when this happens,

Sheriff Lawal (12:13):

Oh, okay, so someone's talking about my audio, I'm going to go ahead and switch to system audio. Okay,

Sheriff Lawal (12:23):

Second. It should be better now. Alright, so when these smallware get past the great thanks, Jeff. When we get the detection and prevention tools that you have in place, they'll start executing malicious behavior by executing malicious code, elastic detection and prevention engine, which is our endpoint security agent can perform what we call retrospective analysis of whatever we pass before with a certain kind of judgment in the moment that piece of software executes certain strange activities within the environment, we can change that judgment back and automatically block it. It's also important to have continuous visibility into your environment, to the point where you cannot collect things at kernel level data from your host and send that into Elasticsearch, which I'll talk about in a little bit as well. Next slide, Haley.

(13:18):

So Elastic Endpoint Security provides you the capability to stop attacks with our malware prevention, which is a machine learning based malware prevention that's proven to be about over 99% effective and stop malware. It'll also automatically quarantine any malicious activity or any malicious software that we see in your environment with next to nothing impact in terms of resources to your machines. So less than less 1% CP utilization is what we typically see across the board. Next slide. Yeah, so Elastic Endpoint Security also provides you deep data visibility across all of the three major operating systems, windows, Mac, os, as well as Linux next Haley.

(14:06):

So a part of your solid cybersecurity strategies to have a good detection mechanism in place. It's important to be able to gain insight in terms of investigation in your environment and also the ability to respond when you need to, which we'll talk about in a little bit as well. If you move to the next slide for me Hailey. So Elastic is actually prebuilt over 700 prebuilt detection rules in our security engine. So this detection rules can collect data from different sources. It could be from your identity services engine or with reverse security or from your cloud environment or from your Windows logs, Linux logs or whatever logs that you have within your environments. This data will come into Elastic and we do have correlation prebuilt with the rules that elastic prebuilt for you out of the box. So this rules will then be used to correlate the events that come in from these different sources to determine if there's been any malicious activity that's support from all of these different sources that you have in the environment.

(15:03):

Next slide. We also have prebuilt machine learning detection jobs that we've built into the Elastic Security engine. All you have to do is go into the UI and enable this jobs to automatically detect any anomaly in terms of user activity. I heard Brian mentioned something before about a Ray Howard for a user to log onto the system. All of this can also be picked up by a tool like Elastic. If a user is logging in from a strange location connecting to a strange location after logging in between a certain range of time that it shouldn't really be logging in, the system can automatically pick on all of these different anomalies in the user behavior and automatically send you an alert, but take certain actions as part of this anomaly detection jogs. Next slide. So Elastic is done so well to make sure that we're very well mapped across the different Mitre attack techniques, especially from initial access all the way to privilege escalation. We do have different mappings across the board there as well. Next slide. Haley over here, Brian.

Bryan Christ (16:13):

Yeah, so hopefully folks on the line you picked up on this. We sort of quietly transitioned into a conversation about detection. I really appreciate as we, Sharif and I were planning for this webinar. He shared the screen that you just saw with all of the different Mitre attacks. And so the idea here being that elastic is going to look comprehensively at all of these different kinds of attack vectors, and I'm going to sort of wrap up this conversation about detection. It could have bookended and we'll move on to a conversation about containment. But one of the things that assuming they're able to get into your network, a couple of things that we've observed when you sort of pick apart the anatomy of an attack is they're really looking to do reconnaissance once they get in. So that's the key getting in. And so hopefully between what we've shared with you and what Sharif has shared with you about preventing it in the first place, this never happens, but assuming they get in, there's a pattern here and what they like to do is they sort of like to set up camp, do reconnaissance, because ultimately what they're going to be looking to do is to maybe move laterally and elevate, and again, they'll rinse and repeat that process until they get to the keys of the kingdom.

(17:29):

And so some of the things that we can provide through the proverb is security fabric on this front is we can look for newly created accounts. I was reading up not too long ago about a really prevalent exploit and this is exactly what happens. They get in and they created a new account, a very kind of benign sounding name that would hopefully just anyone would just gloss over. So they create this account and maybe they deploy something like some C two, which is commanding control software, which allows 'em to get back into the system. The other thing that I mentioned, and of course this is part of that moving laterally, is they're going to look for highly privileged security groups. So maybe if they can move into another account that has another group membership or participates in a different group with elevated permissions, then that gets them one step closer.

(18:21):

The other thing that we can do is we can look for unusual requests on the off chance that they've gained credentials to a user who may be able to access something like a privilege access management solution. We want to look for things like why is this account being checked out when it's never been checked out in the last nine months? So we can look for this sort of anomalous behavior and then hopefully shut that down right then and there. Haley, if you want to move on to the next slide, I think this is where Sharif is going to talk about containment here. Sharif, over to you.

Sheriff Lawal (18:58):

Thank you Brian. So container recovery. So within Elastic we do have a couple things to help out with containment and exactly how to do that with Elastic. We'll talk about recovery in a little bit as well. So it's important to be able to investigate and understand the extent of the, I guess, cybersecurity breach damage within the environment before you start taking certain containment actions. Of course you can take some actions before you go into full blown investigation, but it's also very important to be able to see the extent of the damage that's been done. So we'll be talking about that as well. Also, it's important to be able to take certain automated response actions such as send in something to SOAR that can read through the data that's been sent there and takes some actions with a workflow. If we move on to the next slide, I can dig into those in a little more detail.

(19:48):

So take for example, an attack is a cord within your environment and you want to be able to quickly see what exactly happened, who did what, the name of the user, the machine name, and also what file, the modified, what kind of processes were executed. We also want to know if there's certain artifact of that attack that we're also seen across your environments in other areas could be on-prem, it could be the cloud, it could be other users that experience in the same kind of compromise. So you want to be able to get into the weeds of that and understand how far and how deep the extent of the attack is. So something with the timelines with Elastic will help you to be able to do that and basically gain insights into the extent of the damage so you can start to quickly take all the necessary actions that you need to take.

(20:36):

Next slide there Haley. So taking automated response actions is also very important. So a good example here is we noticed within Elastic using both pre-built detection rules as well as our machine learning detection anomaly jobs, and we start seeing something that's strange about the user, an anomaly with a user activity in terms of where they're visiting or where they're logging in from. We can now send this or generate an alert and send that out to a store platform over webhook or a dedicated one of prebuilt. For example, we do have a prebuilt ServiceNow integration as well as all the vendors. So we'll send that there and from there we'll configure that to basically send a piece of a message to be reverse security over API, for example, to recalculate or to change the recore of a user before then taking further actions like restricting the user access and completely blocking the user. So all of these are part of a pretty good containment actions that you could take as an organization to reduce the blast radius of an attack within the environment. Next slide. Over to you Brian.

Bryan Christ (21:47):

Yeah, super thrilled that you brought up Soar on that last screen. So we are not a SOAR platform and I hope folks you have picked up on this that there's a lot of complimentary technology between what Elastic does and Reverse security does. And Sharif brought a really good example up, which was they could reach out to our software stack and they could elevate the risk score within the system. That is actually something that we would recommend doing and we can do that directly with Elastic or if you have a SOAR platform already in place, we can serve in sort of that orchestration and automation capacity. When we're talking about containment, I've got a couple examples of here, I want to talk through a few of them just to give you a few illustrations. Raising the security threat level, this is exactly what Sharif was talking about.

(22:42):

Sometimes when I'm explaining this to others I'll somewhat call it raising the DEFCON level. So here's a few ways that we can do that within the reverse security fabric. I talked early on in the prevention piece about multifactor authentication or two-step authentication. I mentioned that some factors were inherently better than others. I also talked about user populations may be treating them different. If you're in this containment phase where something's bad's happened, you've surveyed and you said, Hey, we need to quickly take action. One of the things you can do is you can categorically turn on two-factor authentication for all. So the set of rules that is maybe treating a contractor different than employee or being a little more graceful when you're on network versus off network, we can alter those rules and we can treat users differently based on that. Again, Sharif brought this up, but risk scores.

(23:43):

So within the system we can apply risk scores to both users and we can apply risk scores to accounts. So some accounts in your organization may be inherently more privileged than others. Maybe your Twitter account is privileged, but it's not as privileged as a domain administrator account and active directory. So we can apply risk scores to that and in some sort of elevated security threat, we could actually raise the scores on all of this and then it would have, whether you want it to or not, it would be a decision, but almost certainly a default behavior would be to require human approval. So in a lot of organizations, so I'll talk about our product for a minute, Revera privilege allows operators to check out, check in the keys to the kingdom, and sometimes you don't want that tool to get in their way, so you just automatically approve those because it's sort of business as usual.

(24:45):

But in this particular environment where you're in a containment mode through these mechanisms, you want to force a human being to review that and say, Hey, why is Bob trying to check out the administrator credentials on this particular server? So adding that extra layer of security temporarily while you're in containment. Sharif talked about this, about taking some hard actions. So one of the things that we can do is we can lock down accounts. So if you have a suspicion that certain accounts or group of accounts have been compromised, you can have empower your firefighter team with just a handful of clicks to lock out users and shut down their profiles. You can also empower users to change their passwords. So part of what Vera Pass does is part of the brave security fabric. This allows users to change the passwords and through some combination, this is sort of the orchestration side of the things, empower users to rapidly change their passwords, not only just on one target system, not just on one account, but all of them, right?

(25:48):

So if you suspect a breach, one of the best things you can do is you can have your employee population quickly change those passwords for the keys to the kingdom. I like to give this kind of illustration. If my keys were sitting on the living room table and I had somebody come over and all of a sudden my house key was missing, what would I do? I know what the answer is. It's a rhetorical question. If you used to believe that somebody made off with the keys to the kingdom, the first thing you're going to do is change the door locks. So one of the things that we empower you to do in this containment phase is with a couple clicks of a button, you can rapidly and quickly change the password, all of the connected systems. So in that analogy, we're basically virtually changing all of the door locks so that if there is a suspicion that some sort of privileged secret is in the hands of a bad actor, you have that peace of mind that whatever they had is now no longer valid. Haley, if you want to move on to the next slide, I think we'll turn this back over to Sharif who's going to talk about the recovery component of all of this. Of

Sheriff Lawal (26:54):

Course. Thanks Brian. Let's imagine that you do have an environment that's actually been compromised for whatever reason. We have a prebuilt built into elastic, of course, a rollback feature that basically allows you to roll back all of the changes that's been made by specific malware environment. Of course, let's take ransomware for example. Ransomware compromised environment starts to encrypt the different files on your file system and prevent you from taking certain actions because you can't load certain files. So Elastic endpoint security technology actually supports rollback that allows you to completely roll back all of the changes that's being performed by the malware. And this VSS snapshot or shadow copies I guess gets taken every two hours based on the configuration within Elastic by default. And this configuration can also be changed to any configuration of your choice to basically support your rollback. So even if a compromise whatever happened for any reason, elastic has got you back in terms of ruling back to a previous state on your machine. That's really it. Next slide, Charlene.

Bryan Christ (28:04):

Thanks Sharif. I'm glad you brought up this conversation of rollback because when we talk about recovery, there are common elements throughout any organization's. Disaster recovery plan. Rolling back to a previous known good state is a critical piece of every organization's DR plan. One of the things that is sort of an interesting artifact of using something like a privilege access management solution is, well if I'm constantly vaulting and randomizing the password, but then I have to back up to a snapshot, let's say two days ago, well now I don't necessarily know what the password was. So that's why in something like a privilege access management solution and in that recovery phase, you need a good break glass solution. So I'm going to talk about break glass for a minute. Break glass is in that emergency where you can't go through the normal workflows of human. Maybe you have a system that's completely compromised.

(29:04):

You need to be able to empower your firefighter team to get to credentials so that they can do the recovery. And in some cases, you'll need to be able to access credentials that again, were maybe two days old. So my guidance here is if you're looking at a privileged access management solution, certainly we would advocate for Vera privilege that you want to ensure that it has a good break glass story, a good break glass mechanism that at the same time that you're circumventing some of the standard controls because it is an emergency condition, you're not sacrificing audit capabilities. There's also a reinstatement component that's essential to recovery. Recovery. If we talk about containment, where we're locking down accounts, we're quickly disabling profiles. Once you've get into this recovery period, it's going to be super helpful to undo that and undo that in a clean, efficient and low friction way.

(30:12):

Same with lowering the threat level. When you get back to a place of normalcy, it's important that you be able to quickly also unwind the things that are getting in your way that are slowing down normal productivity. Also, when you think about recovery and what you need to be doing in there, I think it goes without saying that any good solution set that can help with recovery should also be updating tickets. I probably should have mentioned this on the containment slide as well. There's a little bit of overlap between containment and recovery. It's not like all of a sudden magically you're out of containment into recovery. There's a period of time where the two lines sort of blur together. But being able to update tickets and keep people informed when all of this is going on, and I mentioned at the very onset that certification is important in the preventative state. The certification and attestation is also important in the recovery state. It being able to certainly know with surety that your organization has gone back to a state where the bad actor is now out of your environment, the threat has been eliminated, and that may take the form of an ad hoc certification of the identities within your organization and making sure, again, going back to the principle of least privilege, they have only what they're supposed to have more no less.

(31:52):

Haley, if you want to move on to the next slide, that really does conclude the content of our webinar today. Both reverse security and Elastic have some free offers that we would like to extend to the audience. I'll talk a little bit about our 90 day trial. So you heard me talk about prevention, you heard me talk about making sure that users don't know passwords, so it's sort of out of sight, out of mind. They would have to do something out of the ordinary to expose passwords. So we do have a 90 day trial right now of Brera Safe coupled with Brera one-off, which is a strong multifactor authentication soft token if you will, and it uses biometrics unlike other models, it uses PKI infrastructure, not a shared secret model. So brings a lot of security to the table, a lot of convenience with the biometrics, and it gives your user population a way to safely stash those credentials. And so we would invite you to take us up on our 90 day no obligation trial, kick the tires on it and see what it can do for your organization. Sharif, if you want to talk about what Elastic has to offer, I'm sure the audience would love to hear it.

Sheriff Lawal (33:14):

Absolutely. Thank you Brian. So Elastic Cloud, absolutely. We do have a free trial for 14 days where you can deploy your elastic search cluster. You're able to take advantage of different data tiers to basically store data for even longer, just to allow you to play with the different tiers that's available and also the three different solution areas that's available within Elastic. I know we're talking about security today, but there's the search observability and security that's available. Feel free to try it out. You can also choose any cloud provider of your choice, even though it's Elastic Cloud, we'll manage the control plane, but you can make your data reside in any region of your choice and also any cloud provider of your choice run by Elastic. Of course, if you have any questions, feel free to reach out. Thank you.

Bryan Christ (34:02):

Haley, if you want to move on to the next slide again, that does conclude our presentation today. We have an opportunity for the next little bit to take some questions from the audience. Haley, Carolyn, do we have any,

Carolyn Evans (34:18):

There was one that came through a few minutes ago. I know we're over a couple of minutes, so maybe we'll just to quickly touch on this one. What about communicating back to the platform to do some of the response actions like changing passwords, increased risk score, lockdown accounts, et cetera, via the API?

Bryan Christ (34:35):

Okay, I guess I'll talk to that. I think there's two pieces of that. So again, we're not a SOAR platform, but because we have a robust API, we can talk to something like Elastic directly. So Sharif mentioned this, they could affect changes through our API to enhance the risk score and risk banding within Revera privilege and Revera identity, which would have a cascading effect of basically clamping down security. And of course SOAR platforms will do the same thing. They will have the ability to reach out and make changes through APIs. And so we have a very rich API that allows you to do much of what we talked about today through automation. And then on the orchestration piece, there may be cases where you have to do some of this through one of the firefighter operators or things like that. But absolutely a good solution stack like this is going to provide those kinds of tools and automation.

Carolyn Evans (35:40):

Okay. Alright, well we will wrap it there. We will send out a recording of this webinar to everybody and you can share it. We'll also include links to those trials if you are interested in participating in either. And if you do think of other questions, please just respond to the email and we will get you in touch with the right person to get you the answer that you need. On behalf of Brian and Sharif and River Reverse Security and Elastic, thank you very much for your time.

Sheriff Lawal (36:11):

Thank you everybody. Thanks for joining us.

Bryan Christ (36:13):

Thank you.