[MUSIC PLAYING] Hi, and welcome to this session about how to supercharge your security operations with Microsoft Defender for Endpoint. My name is Michael Von Horenbeeck. I am the CEO at The Collective. I am a security MVP. I'm a security aficionado. And I really love Microsoft's products.
Now, this session is about Defender for Endpoint, not the rest of Microsoft's products because, obviously, in 30, 35 minutes, there's only so much that we can cover, but I promise it will be well worth it because we're going to unravel some of the mysteries around Defender for Endpoint, its components, how to best deploy and to manage the solution.
Now, for more coverage about Microsoft's products or Microsoft security products, I've also written a book, along with some other authors, Microsoft 365 Security. And a lot of what I'm covering today is also covered in the book. So if you want to have additional information on top of what we cover here today, it may be a great additional resource.
Now, why Defender for Endpoint? Why is it so important? Why is a seemingly small security solution in a sea of other security solutions such a big thing? Well, it's because we live in a very challenging world. We live in a world where we're constantly being attacked by a variety of things. Now, when we take a look at the recent news, and especially if you take a look at what's happening on a daily basis, then we see different types of attacks. Ransomware is on the rise.
Alex Winer from Microsoft even share some new attack vectors. We saw that tokens are being replayed and that these types of attacks are becoming increasingly more common. We saw Paula Yanukovych talk about different types of attack and how easy some of them are executed, how little time it takes an attacker to actually advance within the environment.
So really, what we need is different types of solutions that help you protect your environment. And at the very least or very important in that entire chain, in that entire sea-of-attack surface that you may have is the endpoint. And by endpoint, I don't just mean your Mac OS or Windows laptops or desktops. We're also talking about servers and even mobile devices. They all represent an certain attack surface that has to be secured, not just by configuration itself, but also by looking at the activities that happen on the device, malicious or potentially malicious.
So with all those threats, how do we go about-- what do we look at? Well, I'm a big fan of the NIST cybersecurity framework. Why? Because it's very simple. Is it the only security framework that you can use to deploy and manage your security posture? Obviously it isn't, but what I like about NIST, as I said, it is so simple. It's got five phases. You identify, you protect, you detect, respond, and then you've got recover.
These are all types of activities that you have to perform in order to have a decent or more-than-decent security posture. And it starts by trying to understand what the threats are, the ones that really are a threat to your environment. What the risks that you have to counter, that you have account for, that you have to treat. And how do you do that?
Well, you do that by protecting your environment from the threats that you can protect yourself from. Now, it would be unwise to think that you can stop any and all attacks. The reality is that with everything that you have going on in your environment, with all the different types of attacks and the fact that there is always a human element, phishing, for instance, where someone can be tricked into doing things because they believe, they truly believe it is a legitimate thing.
So because of these things, it is impossible to protect your environment for 100%. So when the protection phase is not sufficient anymore and you start assuming breach, then we know that we have to have solutions, have to have ways to detect malicious activity as they happen, so these types of post-breach detections, which is where, for instance, an endpoint detection response system, like Defender for Endpoint comes into play.
And then closely related to the detection capabilities is the ability to respond to certain threats, which means that once you know that something malicious is happening, you have to know to how to adequately respond. And ideally, you can respond in an automated manner in order to drive down the time between detecting malicious activity or potential malicious activity and then blocking it from spreading within the environment or evicting it from the environment.
And all of that needs to happen within a certain, limited amount of time. Now obviously, the recoverability is also an important point, but that is something that is out of scope for Defender for Endpoint. It's not a backup solution. It's not a recovery solution. It's literally something that goes from the first phase, identification to detection to protection to detection and to response.
Now, when we take a look at how an attack typically unfolds, what we see is that there are different phases an attack follows. And what we've noticed-- not myself, obviously, but what the industry has noticed for a long time is that these types of attacks always follow the same pattern. And there are always certain phases they go through. Now, sometimes they skip one or the other phase.
And that really depends on how easy it is to get into a certain environment, but typically, what we see is that attackers, when they want to attack your environment or your company, then they will start by gathering intelligence. They will start looking for ways in. This may be a port scan on your firewalls. They may be looking at social media platforms, following your users, your administrators, trying to figure out which systems you're using and trying to get a lot of information on which potential vulnerabilities they could exploit to gain an initial foothold within the environment.
Now, depending on the attack avenue they're taking-- and there are a lot of them that they could be taking-- they'll move into the next phase with that intelligence, which is gaining initial access. And what we see there is that phishing is by far and by large the most-used way to gain access to your environment because it's easy to trick people.
It's hard to detect phishing and especially if phishing happens through a trusted third party, but what we see is that they will try and get you to do something because having a user, having an administrator perform a certain activity makes it easier to get into the environment. These zero-touch types of exploits, the zero-day vulnerabilities where they just send a request to a web server, and it's compromised, they don't exist that often. We've had a couple of them in 2021, but it's not something that happens very regularly.
So having that interaction or requiring that interaction is far more something that we see on a daily basis. So that initial access is either a phishing message via email, via Teams, via any other means or sometimes it's just leaving a USB stick behind because on that USB drive, there may be malicious code ready to run, which could run as soon as you plug it in or whenever the users open up a zip file or a file that's on that drive. So they feed off the curiosity of the users, of human nature, I would say.
And once that initial access has been performed, which means they've delivered the payload and someone double clicked, entered the credentials, did anything, there is malicious code that runs. That code typically exploits a vulnerability that exists on the device that it is run on. Despite all good intents and good efforts, the reality is that whenever code is written, there are bugs.
So we will continue to see exploits, we will continue to see vulnerabilities, and we will continue to see zero-day vulnerabilities, even if you're patching strategy involves patching almost the day after patch Tuesday, there is this window of opportunity where a newly-released zero day has not yet been patched.
Now, interestingly enough, I just mentioned that zero-day part, but quite frankly, if you take a look at the patching state of just regular Windows devices across the entire world, there are devices out there that haven't been patched in months, which means that there are old vulnerabilities. And these are the vulnerabilities that are being used the most.
Again, referring to the keynote at tech earlier this year, where Paula talked about the types of attacks that she used as a red teamer, she clearly said that she had no fun anymore because she was referring back to attacks that worked years ago and still work today. So that's really the world that we live in today and how people get into the environment.
Now, when that code runs, there is some exploitation. And then that code can do two things or three things, actually. Either they deliver immediate impact, which means they're going to encrypt the drive on the machine itself, and then they try to harm the device, but oftentimes, when it's not just generating impact directly, what they were trying to do is to establish foothold, which means that they're going to try and persist within the environment to do more damage over time, to sniff out the environment, see if there's anything else worth taking.
And typically, how that happens is that code runs a beacon, a beacon that phones home into the malicious infrastructure. And then from there, it gets in commands to execute within the environment. Now, once that is done, the whole game starts over again. There is a discovery phase within the network unless the attacker already know what they're trying to get to and they know to systems within the network, but typically, they'll look for what's available, where they can move to.
They'll perhaps even run, for instance, a bloodhound, which is a tool to identify attack paths within on-premises active directory. And then from there, they move from one system to another. They'll escalate privileges, ultimately, with a goal to have global admin or domain admin permissions. And once they get there, well, it's game over. Then they can exfiltrate data. They can create impact by ransomware-ing changing passwords, basically, owning your environment all over.
Now, what we're looking into with Defender for Endpoint is a certain set of phases. It's not something that we'll discover reconnaissance phases. Neither is it something like Defender for cloud apps that is designed to detect data leaks or other types of activity. It's literally something that touches the endpoint and looks at activities on the endpoint.
It fuels its information to other cloud apps so that they can have better detections, but its goal is to protect the devices from malicious code. And if it couldn't protect devices, it's to at least detect malicious activity that was run through code because code itself may not seem malicious, but what it does or tries to do could be.
Now, with that, I do want to make a very important note about Defender for Endpoint. "Defender for Endpoint" itself is also a marketing term, coined by Microsoft. And we know that they sometimes can be very confusing. Under the umbrella of Defender for Endpoint, we've got different components, each working independently yet together. And the biggest distinction I want to make there is between Defender for Endpoint, the EDR component and Defender Antivirus.
Especially when you take a look at the endpoint itself, there are several components that run-- several services that run on an endpoint. I'm talking about Windows endpoint in general here, where the EDR components they work together to collect information and then send it off to the cloud, where it's further analyzed. And then you've got the antivirus, which is basically the protection mechanism.
So the antivirus is responsible for scanning files, for blocking executables, but also for getting from the EDR components the request to block something. Now, why is this distinction important? It's also because it relates to how you deploy, how you manage the environment and how, as a security incident responder, you look at certain detection and alerts that come up in the Microsoft 365 portal.
An example thereof is where the M 365 portal, if there is an incident and the incident shows that the detection source was Defender Antivirus, it means that the antivirus was in line. So it detected the activity as it was happening, and it may have blocked the activity right before or as it was happening.
Now, with that same alert or a similar alert comes in, and the detection source is Defender for Endpoint, then we know it is an alert based on activity after it happened because the EDR components take log files. They analyze the log files after they have been generated, which means that depending on the type of incident and type of detection source, there is this window of opportunity where code may have run, and it should also alter the way that you, as a security incident responder, actually treat that incident.
Now, it's not something to be wary of because that's just typically how stuff works. EDR is post-breach and antivirus before that, but why am I going about at length-- or why am I going at length about this is because Defender AV is basically a Windows feature and is managed through the management channels that are available to Windows or to Mac OS or Linux, which means that we're dealing with SCCN, we're dealing with Intune, with GPO, really, or even manual scripts, PowerShell wise. For Linux, it would be Ansible and Puppet, but that's really how you deploy and manage the solution.
Defender for Endpoints has this component that you have to deploy on the machine for it to report into the cloud, but after that, it is entirely managed by the Defender for Endpoint portal, but we'll get to the management capabilities later. It's just something to point out.
Now, looking back at the image that we have before us, you can see on the left-hand side, all the components that run on the device itself, which are the different features, which is Defender for EDR components, the Defender AV components, but also everything that is attack-service reduction. Again, marketing went a little bit off board because you've got the principle of attack-surface reduction, but under attack-surface reduction, we've got attack-surface reduction rules. We've got exploit protection, network protection, et cetera, et cetera.
So these features make up the main feature or name of the principle of attack-surface reduction, and that is also part of Defender for Endpoint, although being part of Defender for Endpoint doesn't necessarily mean that you require a license for Defender for Endpoint for it to work. A good example thereof is attack-surface reduction rules.
These rules are core parts of Windows. You can leverage them as soon as you have a Windows license, although the advanced reporting which makes it so much easier to deploy attack-surface reduction rules are part of Defender for Endpoint, for which you would need a license. So it can get a little bit confusing sometimes, and it has no technical impact. It's just marketing. Let's keep it at that.
In the middle, we've got the Defender for Endpoint cloud environment, which is basically your tenant, in which there is all the AI stuff in there, the analytics that happen on the data that are being shipped into the cloud. There are automated investigation and response capabilities, which will help you do investigations on alerts.
There's sandboxing, where if there is a new executable found on a device that has never been seen before, it'll ship it off to the cloud. The cloud will run the executable, analyze the executable, and then create a verdict and send it back to the endpoint, telling it, yeah, you can let the application run or no, you should block the application, especially if it was deemed potentially malicious.
And then on the right-hand side, it's everything else Defender for Endpoint integrates with so. We have got the broader M 365 Defender suite, but we also got Microsoft Sentinel, Microsoft Expert Services. We've got the security graph API or the graph API and we obviously have Endpoint Manager, which is Intune, used to manage core components, part of the Defender for Endpoint feature family, I'd say.
Now, let's talk a little bit about onboarding. And onboarding means making sure that a device is registered to talk to the cloud, upload its data to the cloud so that it can be analyzed over there. Onboarding to Defender for Endpoint means that we run a little piece of code on the device. And we're talking mainly Windows here, to take an example.
So we're using a script, an onboarding script, which we can deploy using a CCM or GPO or Intune, again, through all the management channels that we talked before. And that itself will execute something on a device, which will register the device in the cloud and then make it known. Mind you that the onboarding itself doesn't mean that you're using Defender AV. It's Defender EDR.
It could mean that if you have no other third-party AV on the machine, that you are using Windows Defender AV, but you could just as easily use Defender for Endpoint on top of Sophos, McAfee, Symantec, and so forth and so on. And that's also a big misconception.
It's true that MDAV and Defender for Endpoint EDR, they work better together. Obviously, both Microsoft solutions. They have been developed together in a certain way, but it doesn't prevent you from running one or the other in conjunction with another antivirus.
In that point, or to that point, I should say, it's true that when you run Defender EDR on top of a third-party antivirus, then Windows AV should not be the Active antivirus. And as soon as you install a third-party AV-- and again, should because not all antiviruses behave in the same way-- Defender AV should go in a passive mode, which means that it does not intervene with normal operations of the third-party AV, but while Defender AV is in passive mode on the endpoint, the EDR capabilities or the EDR platform can still reach out to the component on the device and tell the component to block stuff if it figured out something is malicious. That's what we call EDR in block mode.
If not, if you don't have that capability, your EDR capabilities are just letting you know that it found something, and it becomes an alerting mechanism. Now, as I said earlier, detection is one thing, but being able to respond adequately is yet another. And time is of the essence. So as long as Defender AV is in passive mode with a third-party AV, Defender for Endpoint EDR can reach out and block stuff, which makes it really fast to intervene.
But if you forcefully disabled MDAV, which some third-party AV vendors recommend, you lose that capability. And again, that shows the disparity between MDAV-- Microsoft Defender Antivirus engine-- and the EDR components. So even when you do deploy Defender for Endpoint EDR with a third-party AV, I think you should have a strategy to move away from that third-party AV over time and then move to Microsoft Defender.
The EDR component, the onboarding thereof, is smooth and easy. You can do that in a couple of days, across a really big stage. MDAV could be or could require a lot more work, depending on the type of AV that you're using today, the exclusions that you have today, what your environment looks like, how much legacy you have because just replacing it like that typically results into lots of false positives, applications potentially being blocked that you don't want to, and so forth and so on. So there is a little bit more work involved there.
So what is the onboarding process-- and again, onboarding to Defender ETR-- look like? Well, as I said, we've got that onboarding script. Once you run that script, what it does, it writes into the registry a bunch of information. It writes the org ID, which is your tenant that the device should report into. And it adds the URL that it needs to talk to. It will add some verification signatures in there and some certificate information, all of which is used to register the device with the Defender for Endpoint tenant.
Then in the next step, the script will try and start the sense service, which is part of Defender for Endpoint. And then it's that service that will read the registry, reach out to the endpoint in the cloud, and try and register the device. Obviously, there are a couple of components that come into play for this to work.
First of all, the sense service must be able to start. If you've forcefully disabled it, then, obviously, it can't, so you have to update that on your devices. Secondly, the device needs to be able to communicate to the Defender for Endpoint portal, which means that it needs to have internet connectivity. Sure, that internet connectivity can happen through a firewall, obviously, and through a proxy server, but just make sure that if the proxy server uses authentication that it understands that the communication is happening from within the device's context, not necessarily the user context.
And when all of that works or failed, whatever it is, there is a status measure written back into the event log, one that you should be looking out for that says, yay, I onboard successfully or something came in between. I wasn't able to onboard. Obviously, if the device does not show up in Defender for Endpoint, you know something's off, but it beats waiting for an hour and then realizing there is nothing happening there.
So over the past couple of minutes, I've spoken a little bit about Defender for Endpoint, its benefits and what it's doing, but there's also the management infrastructure, which I refer to a couple of times. So when you manage a Windows device, you can do that in different ways. You either do it manually. In a more traditional environment, you're going to use a group policies.
And when I say more traditional, I don't mean outdated. Lots of organizations join their devices to on-premises domain and do use GPOs. There's nothing wrong with GPOs but focusing towards the cloud, GPOs are quite limited, a little bit set and forget. With a legacy of more than 20 years, obviously it's a very robust situation, but you're typically not going to use a GPO to deploy applications.
Even though you could do the onboarding for Defender for Endpoint because the onboarding script is fairly small, I think if you have an application management system and configuration management system like Intune or like SCCM that it makes it a much better option.
Now obviously, you can't use Intune directly with servers. So for lots of organizations, it's a combination thereof sometimes even a third-party system. Now, these systems can be used to run the initial onboarding. Once the onboarding is completed, then obviously, the shipping of the log files happens through the sensor agent on the device that talks directly to the cloud.
And any other configuration related to Defender for Endpoint, specifically to the platform, happens in the portal. And if it needs to reach the client, it uses that connection from the client to the cloud to communicate back to the client.
But how about policies for Defender AV? How about policies for attack-surface reduction rules? Well, that's a different story. There, you need a full-blown management infrastructure. Now, you need GPOs. You either do it with PowerShell scripts manually, you either use a SCCM or you use Intune, but there's also a fifth option for Windows.
And that fifth option is called the MBD management channel, whereby you're not using any of the management channels I just mentioned because each of these management channels requires the device to be registered. You have to be AD-joined to be able to use GPOs. You have to have the SCCM agent if you want to talk to SCCM. And you have to be Intune registered if you want to use Intune.
If none of that is an option and you don't want to do it manually, you can onboard a device and leverage that communication channel through MDE. Now, in order to do that, you still leverage the MEM, so the Intune portal, to create policies, but instead of pushing them down through the Intune management channel, it will actually leverage the existing management channel and talk back to the clients that way.
Now, compared to the full-blown capabilities of Intune and SCCM so forth and so on, the MDE Management channel can only leverage specific features. You can do AV policies. You can do firewall rules. You can do a firewall policy, but that's pretty much it. If you want to do a attack-service reduction rules, exploit protection, any of the other things, you can't really do it through that MDE management channel. Now, over time, obviously, these capabilities will come to a certain same level, but at this time, that's not yet the case.
When we're then talking about other platforms, like Apple and Linux, then we know that Linux today isn't supported by Intune, which means that we need to have a different platform. Sure, we can use Intune for Apple, which is fine, but most organizations that are really heavy Apple users may have another management system. And these management systems, obviously, are also supported, provided that they can push the application and push the policies that are required.
One of them could be Jamf, Jamf Pro. That works just beautifully. For the Linux capabilities, it's basically the same. You have to have binaries that you download on a Linux machine or that you download to the Linux machine. You have to run the executable, so make sure that the service runs on the Linux machines. And then you have to push the policy, which is basically a JSON file that is distributed centrally from a management infrastructure.
If you have got all these components in place, then you can successfully manage the MDE, EDR components, attack-surface reduction rules, insofar that it applies, Defender AV, and so forth and so on, all these capabilities through the management infrastructure.
Now, looking back, or looking forward, I would say, above and beyond regular antivirus capabilities, we have other attack-surface reduction capabilities, like attack-surface reduction rules. Now, attack-surface reduction rules is basically a Windows feature, which contains 18 or so rules that each of those rules limits or blocks a specific type of behavior, specific type of attack path or pattern that is commonly used in attacking your devices.
One of them could be trying to read credentials or dumping memory from LSASS. Another ESR rule prevents Office programs from spinning up sub-processes or child processes or even new processes. Others are blocking specific scripting languages, like JavaScript and so forth and so on. I mean, there's a plethora of rules that you can deploy across the environment. And provided that you deploy all of them in block mode, your security posture will jump dramatically.
Now, unfortunately, the truth is that there's a lot of software out there that either, in a bad way or legitimately, takes or performs any of these activities. And you don't want to block these applications from running. It could be your line of business application. It could be a control system. So you have to be careful with deploying these attack surface and reduction rules across the board.
So how do you typically go about? How do you ensure that these rules do not interfere with your day-to-day activities? Well, what you do is you deploy the rule, but instead of deploying it in block mode, you put it in an audit mode. What will happen is that on the machine itself, every time an activity would have been blocked by that rule, if it were to be set in block mode, it will generate an event. It will generate an entry in the event box.
So over time, a couple of days, a couple of weeks, you will actually amass a lot of events that you have to analyze. Now, here's the trick. I said earlier that attack-surface reduction is part of Windows. So you could already deploy these rules across your estate in audit mode. However, what you don't get is the reporting capabilities because an event log is local to the device.
So if you don't have Defender for Endpoint and you want to get these log files, then, or these event log entries, you have to set up event log forwarding or get a different way of grabbing the event logs for these devices and create your reports yourself. Now, the larger your environment, the more work it is. Obviously, it's not something that is fun to do or something that you want to do.
So in that point, this is where the additional value comes from Defender for Endpoint. It actually gives you these built-in reporting capabilities because it already established that communication channel between your device and the cloud. So it already uploads telemetry. And as part of that telemetry, it will look for these entries in the event logs and upload them to the cloud.
And then the M 365 security dashboard has a report specifically to attack-surface reduction rules that surface which rules would have blocked which entry, allowing you to figure out whether or not you should add an exclusion for such a process, whether you have been breached, perhaps, or whether there's something else that you need to do or even better, so that you can immediately move into block mode.
So once you've established that on a per rule-basis, you can move that rule into a block mode, deploy that, again, through your management infrastructure. And that's how you go from auditing these rules to putting them in block mode and dramatically increasing the security posture.
Now, lastly, you when we take a look at the different phases, we've got identification. We've got production, detection, and response. Let's take a little bit of a look at the detection and response capabilities.
A question I'm commonly asked is, hey, Michael. We've got Defender for Endpoint. Do we still need a SIEM? Well, the answer is, it really depends. If you have a SIEM today, then, yeah, sure. Why not use the SIEM? But what are you going to use it for?
Defender for Endpoint itself has everything it needs to be your security operations tool. And that is true, especially in smaller environments that don't have a lot of other systems within the environment. Now, I'm not saying that there's lots of organizations out there, but especially the smaller ones typically have a limited set of applications servers running within the environment.
And they could benefit from just using Defender 365 or Defender for Endpoint, and they would be just fine with the Defender for Endpoint capabilities because taking a look at what security operations means, it means that you need to be able to look at alerts and events. You need to be able to detect threats or new threats as they happen. And part of that is Microsoft's responsibility, but part of that is also your responsibility.
You need to be able to create custom detections for specific scenarios, but, again, that depends on your security maturity, I would say. You need to be able to respond quickly to those threats, preferably using automation. You need to be able to correlate information between what's happening on an endpoint or perhaps elsewhere in the environment. And all of that comes together.
Plus, if you work in a team with more than just one person, you want to make sure that if you assign a case or an incident to someone, that they know it's assigned to them, and that they can respond to that. You can collaborate on that.
Now, the letter is a little bit where I draw the line between, do you really have enough with Defender for Endpoint or do you need something else on top of that, a SIEM or a service desk or service management tool? And again, the larger you get, the more likely it is that you need a service, a ticketing tool and where you need to set up these integrations between Defender or Endpoint or whatever SIEM platform you have and your ticketing system itself.
So what we're going to do now is quickly browse through the portal and show some of these elements, starting with the ID phase itself. So what I will do here is I will move to the portal. And what you see here on screen is, first of all, the vulnerability management dashboard.
Defender vulnerability management, or previously known as threat and vulnerability management, is literally a solution that will identify all the weaknesses and the threats and the misconfigurations in your environment, like Secure Score does, but this just looks at the endpoint. So yes, what defender vulnerability management finds is also surfaced in Secure Score.
And it will look at different elements. When we take a look at the recommendations itself and go through the filter, then we see different categories or remediation types, if you will.
First one is software update, software upgrades, software uninstalls, configuration changes, and firmware updates. So it looks at all these different elements and we'll let you know, hey, this is out-of-date software where there is a vulnerability. Please update the software. This is software that is end-of-life, no longer supported, and it has vulnerabilities. Please uninstall or upgrade it to a different major version and so forth and so on.
So what can you expect? Again, referring back to that keynote from Paula that we saw on tech earlier this year, is all the different attack paths that may exist. Some of them are related to the configuration of your device. Some of them are related to the environment. As you can see here-- and again, this is a test environment, so there's only a limited set of recommendations. Some of them pertain to the attack-surface reduction rules.
As you can see here, the related component is security controls, where Defender vulnerability management is telling me, hey, if you want to increase the security of your environment, please deploy these rules, and deploy them in block mode.
And every time I do so across the environment, to all of these devices, you will see a jump or an increase in my score, basically a decrease in my risk score, but it also goes into updating server operating systems, as you can see here. I've got Windows Server 2022 running. There's 312 vulnerabilities detected on one device. So obviously, I should update that device . If I click on the recommendation, it will tell me which device was exposed, what the associated CVEs are, so basically everything that you will see there.
Now, this is a list that lives and that lives on because every patch Tuesday, that list grows longer. So let's assume that I patch every month, then every month, new information will come in. And once a month, I will get the, hey, update Windows, update Windows 2022 or your client operating systems.
And if we browse through that list, you will see that there's much more information on that. It also says what I need to do on the endpoint to configure Windows on the endpoint to become more secure, like enabling LSASS protection, aside from the ASR rules, obviously, by enabling SMB signing, which is more active directory-focused, by removing or eliminating NTLMv1 from the environment.
Basically, anything that can be used to exploit that device and does break into your environment is added as a recommendation. Some of them have a high impact, therefore a better impact on your score. Some of them, especially the lower you go on the list, will have a more limited impact, as in it will affect your score, but not as much as some of the higher level vulnerabilities and so forth and so on.
One important thing to note when you take a look at the recommendations is the highlighting of that little bug. The highlighting of that bug means that there is a public exploit known to be used already out in the wild, which means that there is a certain sense of urgency when you are or if you are going to patch and leverage any of these security recommendations.
The ones that have no highlighted bug basically mean you should do something about it, and there is no known exploit of that yet available or abused out in the wild. So it doesn't mean that it doesn't happen. It just means that the security analysts have not yet found evidence that it has been abused out in the wild. Anyway, small detail, but with a big impact.
So the vulnerability management system is more on the identification parts, but will lead to actions that will help protect the environment. But what we're really looking into and what the truth the true value is of the Defender for Endpoint EDR components is the ability to generate alerts and incidents of what's happening on a device.
What you can see here, for instance, is a list of incidents where by on one of these devices, I tried dumping the LSASS process memory, which is commonly also used by a hacking tools like Mimikatz. So what happened is that immediately afterwards, it was detected. So after that the telemetry was uploaded into the cloud, the cloud raised an alert and said, well, there is suspicious access to a LSASS service.
So by clicking on the alert, I can review what's happening on the device itself. And from there, I can pivot to either the timeline of the device. And then from there, I can also take action on a device as well.
So when we go to the timeline of a device, I can get more details about the alert and what's happening or what was happening right before that. So interestingly enough, as a security analyst, when I take a look at these types of events-- and again, this is not a course on how to do investigations on an endpoint. You can see all the activities that happened before the alerts and all the activities that happened after the alert, giving you more context on what it could have been, whether or not it's malicious, and whether or not you should respond.
And then from there, obviously, there is a bunch of activities that you can do, either collect an investigation package, which will download potential malicious code so that you can analyze that before you take action or you can immediately take action by initiating a live-response session to kill a process manually or to isolate a device, restrict execution, and so forth and so on.
So here is where you can see that Defender for Endpoint especially, the EDR capabilities in a platform, allow you to detect what's going on if you couldn't protect and then respond to them in an adequate manner.
Now, this is entirely manual, where I go through an alert, and I perform certain activities, but as a security operations analyst or threat incident responder, I can also create logic apps or flows that will automatically kick in whenever specific alerts happen or whenever I deem that something needs to be done, that I kick off that flow.
And then that flow will do something which could be send an email, raise an alert, let the sprinklers go off. Anything you can imagine, it can probably do that, making it a very, very flexible and comprehensive system. And all of that is quite integrated within the environment, giving you all that you need to supercharge your security operations.
Now, the last point I do want to make with the Defender for Endpoint is it provides tremendous value to security teams that may not have sufficient capacity, resources available, or the in-depth knowledge to do all of this. As I mentioned, there are specific elements, whereby something may be happening on the device that you are not super familiar about, for instance, when there is malware that's being dropped.
And then what you could do is take a look at an automated investigation and response. So let me log on to my platform for you here. And let me do MFA. There we go. And let me show you what such an automated investigation response looks like. So I am going to go to an older incident, which does involve actual malware. The other one was access to the LSASS process, which did not kick off an automated investigation, but this one actually did.
So I'm going to open up this incident. And here, you can see that there was an investigation. Now AIR is basically your security operations buddy. What it will do is depending on the type of alert and incident that is raised, it will start an in-depth analysis, which may mean that it collects information, that it will look at samples of the malware or any artifacts that may be there, but it will also look at processes, files, registry entries.
And it will use the micro framework and all known attack patterns to figure out whether or not this type of alert that was generated is actually malicious. And based on that, it will actually either recommend or perform the activity itself.
Now, as a security responder or an incident responder, what you can do is take a look at that investigation and, along with the system, figure out what am I dealing with? Which are the impacted entities, which could be a user or an endpoint? What's the evidence that was collected? And in this case, the evidence is a malicious piece of file. And then obviously, what did you do?
So there is a log file that says step-by-step, hey, I went through these steps. I analyzed this. I analyzed that. This is my verdict. And it guides you through the entire process, which makes this also super valuable for teams that don't have the bandwidth or the knowledge. This is a really, really, really important feature and a key point of the Defender for Endpoint platform.
It's not just EDR. It's all the components coming in together because the EDR detects something, collects it through the antivirus, analyzes it, and goes back to the antivirus to, for instance, block or remove or quarantine a threat that it has detected. So this too falls into the category of the response capabilities that exist within the platform.
Now, obviously, what we've done here is we've scratched the surface of Defender for Endpoint. We've taken a look at the vulnerability management capabilities, at the protection capabilities, at the detection and response capabilities, but there is an umbrella of features, all of which are part of this platform. And obviously, there are very intricate details that you have to consider when you are going to deploy and manage this solution in your environment.
However, one of the last key questions I'm going to try and answer is, why Defender for Endpoint over any of the other solutions that exist in the market? We've got XDR solutions from competitors that are non-Microsoft, I mean. And the answer is, it depends. Are these R tools bad?
No. Obviously, they aren't, but consider the fact that if you're a Microsoft-heavy shop, where you have lots of Windows devices, Windows servers, and you're in Office 365, then it makes sense to focus in on that vendor, to focus on Microsoft because Microsoft created Windows. They have, in my opinion, one of the best EDR components in the market, but that EDR component talks to everything else that is also Microsoft. It talks to Defender for Office 365, Defender for Identity, yeah, Defender for Identity, Defender for Cloud Apps. So they all have M 365 Defender Suite.
And it correlates information for you, creating that XDR capability. Add on top of that Microsoft Sentinel, which also is integrated with the rest of the environment and allows you to pull in even more additional logs. And you get a very powerful and integrated capability. And this is one of the reasons why I like it so much.
And to testify a little bit to that-- and it's not to boast my or my team's capabilities, but we have been running Microsoft Defender for Endpoint for a couple of years for our customers. We were one of the first service providers in Belgium to run a SOC entirely based on Microsoft, so no other vendors, no other features. And we've been able to do so quite successfully.
And that's a testimony to the quality of the product and how important it is because even as a small organization, we cannot afford to do lots of things manually. We've built extensive automations. We've made those automations available, like integrations with the Jira system, additional detection capabilities for, for instance, the use of lastpass enterprise.
All of that is possible to connect into and use and leverage the capabilities, which are, in my opinion, fueled by Defender for Endpoint because Defender for Endpoint contains all the bits and pieces that touch the endpoint, which are a really important part of your environment and then shares that information with all the rest, not in the least, for instance, also, Defender for Cloud Apps, where it can detect shadow IT just by enabling Defender for Endpoint.
So with that being said, I hope that you did like the session. And I do encourage you to ask any questions that you may have, and I'll try to respond to them as I can. Thank you so much for watching, and see you later.
[MUSIC PLAYING]