Use Microsoft 365 Defender and Sentinel to Defend Against New Zero-Day Threats: Part II

In part one, we identified four steps to deal with vulnerabilities:

• Identify the impact of the zero-day on the environment.
• Detect abuse of the vulnerability.
• Implement Defender updates for additional detection (and possible protection).
• Mitigate vulnerability through product updates or configuration changes.

Part one covered the first three steps and this article covers mitigation. We’ll also discuss reporting and some tips about non-Microsoft products that can be helpful.

Mitigating Vulnerabilities

Mitigation of a vulnerability might be the last step in this series, but it is the most important and difficult one. There is no one-size fits all approach to mitigating zero-days, especially since zero-days can impact multiple platforms and product from operating systems to application servers and browser applications. The kind of mitigation can also differ. Some mitigations might require a manual update, others will require a change in your configuration, and some might even be mitigated by an automatic update pushed by the vendor.

I can’t provide a mitigation method for every possible zero-day, but it is important to have a plan in place to deploy when a vulnerability requires a sudden product change or upgrade. Too often, I see teams scrambling during a zero-day with no clear guidelines on what to do. Every organization should have a process predefined on what steps to take during such a scenario. This plan should include the following:

Responsibilities

This first point might be the most important: who is the person/team responsible for mitigation? This does not need to be the team that rolls out the actual patch, but there needs to be one person/team responsible for coordinating all efforts. Within some organizations, I have seen confusion about which tasks are executed by the security teams, and by the infrastructure/endpoint team. My recommendation is to pick somebody from the security team, as they will have the most precise point of view on the criticality of the vulnerability.

Communication

During a zero-day, many different people are involved ranging from the security team to the End-User Computing team, and perhaps even the CEO. Higher management can be excluded from communications, but this should not be forgotten. Security is essential for any good C-level management, and there is a good chance they will read some information about this zero-day in the news or through newsletters.

Besides your management, all impacted teams should also be included. An example could be the ERP team if a patch is rolled out to the operating systems hosting the ERP application.

Roll-out plan

When a mitigation is available, it must be pushed to every affected system. The timeline of the mitigation depends on the criticality of the systems and the severity of the vulnerability. Your mitigation plan should describe how fast a critical patch can be distributed throughout the organization. Imagine if a new Log4J comes out: do you want to wait two days to validate a patch before rolling it out, or will you bite the bullet and roll the patch out faster? When a new vulnerability appears, this point should not be a discussion. Instead, the plan should be agreed upon beforehand by the different stakeholders. These discussions should include what kind of downtime is allowed and how long a patch should be tested before it can move from acceptance to production.

An underestimated feature of Microsoft Defender for Endpoint is Threat Analytics, which includes reports on vulnerabilities and potential mitigation steps. You can use this kind of report to see what mitigation steps are recommended by Microsoft. These reports provide a concise way to list possible mitigation steps for well-known vulnerabilities.

Reporting

Reporting the status of a vulnerability across the organization is critical. While you can always email the latest status to every stakeholder, this never delivers up-to-date information, nor is it a good communications experience.

Good information is available in the different dashboards of Microsoft Defender for Endpoint. While this is real-time information, it is not a great experience for somebody from upper management. The Microsoft 365 Security portal is not user intuitive, and it can be difficult for an executive to find the required information. Besides, providing read access to everyone who wants to track the mitigation of vulnerability is not ideal.

I prefer to use a specific reporting tool such as Power BI to communicate. Power BI is a bit more user-friendly, and it allows you to display the exact ‘high-level’ information which is required. Power BI can be connected to Microsoft Defender Vulnerability Management to export a list of all vulnerabilities and their mitigation status. An example report is available on GitHub. While the report is a bit older, it provides an example of how data can be exported from Defender into Power BI and what kind of visualizations are possible.

Looking beyond Microsoft

While the main thrust of this series focuses on Microsoft products, other products can help you during the mitigation process. I often use the GreyNoise and Shodan products. GreyNoise is a cloud-based product with an extensive network of honeypots to monitor the exploitation of specific vulnerabilities. From this data, GreyNoise can provide insights into:

• What vulnerabilities are being actively exploited? If a vulnerability is being exploited, you might want to speed up your mitigation process as the chances of being breached are higher.
• Can the exploitation attempts be linked to certain attack groups?
• What kind of IP addresses/ranges are executing the exploitation? This information is surfaced in CSV format or through an IP and can be imported in your SIEM as Threat Intelligence or in your Firewall to block connections from these specific IP addresses.

GreyNoise is a paid product, but during more considerable vulnerabilities, they offer free CSV lists of IP addresses seen actively exploiting the vulnerability.

Shodan is a search engine focused on scanning all internet-connected devices. Their bots crawl the internet and inventory every open port and additional information about the version of the service behind the port. Let’s take the example of an Apache server available on the internet. When Shodan identifies this, they will query the version used and connect the product version to the vulnerabilities affecting this product.

With this information, Shodan can identify which vulnerabilities are active on your public-facing infrastructure. This information can be seen through the portal, or you can create notifications to alert you on any new vulnerability that is identified.

Microsoft recently released Microsoft Defender External Attack Surface Management (MD EASM) to address the same use case. Although, I still use Shodan actively as I find the user interface much better, and the information it provides is clearer.

Vulnerabilities Won’t Stop

Over the last year, many different vulnerabilities have affected Microsoft 365 organizations. This trend will not decrease in the future. With the number of applications and services in use, vulnerabilities will become more apparent, and there is no way to avoid this. The most important thing is to be aware of what vulnerabilities are active in your environment and have a plan to mitigate these flaws. When a new zero-day is announced, the question should not be how this should be handled, but how to execute the predefined process.