Move to Defender for Endpoint: some personal experience
What to expect
Microsoft Defender for Endpoint and my personal experience, thoughts and ideas to implement and operate with this product, is what you can expect. Based on a real scenario and from the field. I will cover topics from moving from a thrid-party endpoint security solution to Microsoft Defender Antivirus + Defender for Endpoint (DFE).
Our objective was and still is to move close to cloud-native and utilize Microsoft cloud technologies to run state of the art information technology.
Defender for Endpoint was the ideal solution to us, because it is perfectly integrated into the Microsoft cloud platform. Since we were already hosting production and security workloads with Microsoft, and our future plan is to adapt more and more, DFE was a natural and easy choice. Furthermore we are convinced of the product to secure our enterprise with industry-leading technologies. Adding the fact, that it was included in our license step-up, there was nothing more speaking against it.
Please also have a look at my other posts:
- Microsoft Defender: a review - a comprehensive guide to Microsoft Defender and DFE interaction
- Defender for Endpoint configuration - a technical perspective showing the capabilities of DFE
Also see Microsoft Defender Suite contents and all about M365 security on my blog.
Before we get started, I want to refer to the deployment guide by Microsoft. They describe a deployment of DFE detailed and with even more information, both technical and the guidance.
Licensing of Defender for Endpoint is differentiated in Plan 1 (included in Microsoft 365 E/A3) and Plan 2 (E5 / Security). As we wanted the whole potential of DFE, we choose an E5 license. Also keep in mind, that there is a Defender for Endpoint Server license to stay compliant when onboarding servers. Source
Let's take a look at the features of DFE: (state of February 2022)
Move to Defender for Endpoint
So then, in the next paragraphs I will give suitable information and advice to a journey to and with Defender for Endpoint. In addition to the technical implementation, I would particularly keep an eye on these things.
The most important thing in advance: enlighten the management, clarify the responsibilities and get the resources you need.
Understanding the current environment
First and foremost its key to know exactly what assets you are going to deal with. What device types are out there, which OS do they run and probably how old are they? Which applications does your organization use and how could they be affected of Defender? A lot can be validated within a test stage, so I would also advice you to plan enough time for the whole project and Make sure everything is working well before you make a move you can't go back from.
Then, you will definitely need to dive into the current security landscape of the solution at the time. How is the configuration, especially exclusions or is there anything that is adapted uniquely to your need? Try to gain an insight of the behavior of the product and all operational tasks.
Specify the end result
Next, make yourself thoughts of the final state, so Microsoft Defender Antivirus does enforce which settings and is configured like for example a best practice. Microsoft Security Compliance Toolkit is a good source for a security baseline to orientate on Windows OS, M365 Apps, Edge and much more. For the Defender for Endpoint cloud part I did a base configuration post, which you could follow along. For both cases, you should have a concept and a documentation on how your technical concerns are realized.
But also for the non-technical side you should be clear in mind. The security team should work out a sheet on who is responsible for what and when, how they plan to run all operations and how the process on mitigating a threat or similar could be. There is a lot to consider, which would go beyond the scope for this post.
When everything in configuration is done and set as desired, you can go and do tests on some insensitive clients and servers. It is important to take the greatest range of applications possible to cover as much as possible. If the business allows it, you should definitely also onboard productive devices and consider user feedback. Control your results and make sure Defender acts as it should.
To really proof that Defender for Endpoint interrupted some kind of application or work flow I would first go to the device in the Device inventory and check its timeline. Bold marked events are principally the events you should take a look at, as those constitute of something unusual or associated with an interruption of DFE are. This view is also available over the whole organization. Opt for Action center at the top and switch to history. All automated or manual actions are mentioned here. (be aware that this shows all M365 Defender actions)
In my case, we did onboard it with the local script and then checked how the system responded. To verify the state you can either look at:
- Task manager, multiple services starting with the name Sense should be running
- Services, named Windows Defender Advanced Threat Protection service
Defender for Endpoint portal
To ensure communication between the sensor and the cloud, you can check the state in the machine inventory:
And run a detection test, which is found under Settings>Endpoints>Onboarding:
After a few minutes, you should get a test alert yieled in the alerts page of the device. If this is the case, you can be pretty sure that it is working properly.
Once you feel good with all the tests and have all backoffice work done, you can start enrolling to all machines. If all devices are running on a newer operating system this is usually not a problem. With a GPO you can easily set up a one-time scheduled task, that runs the onboarding and if you use Intune this is even easier. At this point please switch to Defender for Endpoint configuration where all onboarding scenarios are featured and described.
Supervise Defender portal
Time after time the Defender portal should get part of your daily routine. Its important to observe the data and information, especially after deploying the onboarding script. My advice: make use of the reports section in M365 Defender.
Then Vulnerability management provides insight to a lot useful and important data collected by your devices. Metrics and charts show visualized data and analytics can help to understand your environment and plan for the future. Recommendations shows all security concerns, rated by a weakness score, including exposed devices and the impact if you remediate it. For a fact, the top recommendations are updating the OS and Office suite as well as updating top applications like Google Chrome or Adobe products. Software inventory does an attempt on asset management by showing all applications across your organization and their potential weakness. Weaknesses literally list up affected CVEs. The Event timeline finally is a chronological log on new vulnerabilities, exploits, zero-day vulnerabilities or configurations assessments and so on.
One more thing I would do at this point, is to create an export of already onboarded devices, their attributes (health state, last sync or communication, antivirus signature version) and compare it to an asset management or Active Directory computer export sheet. This should aid you to see if you caught all endpoints and may point out about things that should be looked at again and determine the future course.
Security Operations (SecOps) is another league that must not be forgotten. Once everything is onboarded and running, your effort goes into operation. Because all endpoints will populate data, generate alerts and incidents you would be at end of capacity soon, but most of the actions happen automated through the Defender intelligence. What I would advice is to enable notifications on medium and high severity alerts and keeping an eye on the alerts and incidents page.
- Be sure about the product and your expectations both on a technical layer on a general layer
- Understand the product and its features, do research about it and know its capabilities, specifications and limitations
- Explain the benefit to your organization, enlighten the management and decision makers
- Define a security concept and write down everything for documentation
- Clarify the responsibilities
- Plan your project and get the resources you need
- Get the corresponding license plans to stay compliant
- Know your assets (devices, applications etc.) and their behavior
- Understand existing security processes and your environment (if available)
- Understand potential malicious or harmful contents, threats or other types of unwanted events that you could be confronted with later
- Specify your objective and desired state
- Consolidate your strategy
- Start structured configuration and implementation
- Do as much testing as possible (dev env. and production cases)
- Obtain user feedback, adapt and adjust
- Start enrolling the solution and communicate to people
- Observe enrolling state and corresponding management portals, control your results and compare it to the origin strategy and set the future course
- Supervise operational tasks and hand over to SecOps