Important
The improved Microsoft 365 Defender portal is now available. This new experience brings Defender for Endpoint, Defender for Office 365, Microsoft 365 Defender, and more into the Microsoft 365 Defender portal. Learn what’s new.
Applies to:
- Microsoft 365 Defender
The recommended methods to deploy Microsoft 365 Defender in your Security Operations Center (SOC) will depend on the SOC team’s current set of tools, processes, and skillsets. Maintaining cyber hygiene across platforms can be challenging because of the vast amount of data coming from dozens if not hundreds of security sources.
Security tools are interrelated. Turning on one feature in a security technology or changing a process may in turn break another. For this reason, Microsoft recommends that your SOC team formalize a method for defining and prioritizing use cases. Use cases help define requirements and test processes for SOC operations across various teams. It creates a methodology for capturing metrics to determine if the right roles and mix of tasks are aligned to the right team with the right skillsets.
Develop and formalize use case process
The SOC should define a high-level standard and process for developing use cases, which would be regulated by the SOC Oversight team. The SOC Oversight team should work with your business, IT, legal, HR, and other groups to prioritize use cases for the SOC that will eventually make their way into the SOC team’s runbooks and playbooks. Priority of use cases are based on objectives, such as compliance or privacy.
SOC Oversight activities related to use case development include:
- Requirements
- Staffing or training needs
- Software licenses
- Vendor contracting
- Managing plan
- Maintaining use case registry
- Maintaining/updating templates
To facilitate the runbook and playbook creation processes, create a use case decision tree. This figure shows an example.
Once a high-level use case standard has been defined and approved, the next step is to create and test an actual use case. The following sections use anti-phishing and threat and vulnerability scanning scenarios as examples.
Use case example 1: New phishing variant
The first step in creating a use case is to outline the workflow using a story board. Here’s an example of a high-level story board for a new phishing exploit notification to a Threat Intelligence team.
Invoke the use case workflow for example 1
Once the story board has been approved, the next step is to invoke the use case workflow. Here is an example process for an anti-phishing campaign.
Use case example 2: Threat and vulnerability scanning
Another scenario where a use case could be used is for threat and vulnerability scanning. In this example, the SOC requires that threats and vulnerabilities be remediated against assets via approved processes that include scanning of assets.
Here is an example high-level storyboard for the threat and vulnerability management of assets.
Invoke the use case workflow for example 2
Here is an example process for threat and vulnerability scanning.
Analyze the use case output and lessons learned
After a use case has been approved and tested, gaps among your security teams should be identified, along with people, processes, and the Microsoft 365 Defender technologies involved. Microsoft 365 Defender technologies should be analyzed to determine if they are capable of achieving desired outcomes. These can be tracked via a checklist or a matrix.
For example, in the anti-phishing scenario example, the SOC teams could have made the discoveries in this table.
| SOC team | Requirement | People to meet requirement | Process to meet requirement | Relevant technology | Gap identified | Use case change log | Exempt (Y/N) |
|---|---|---|---|---|---|---|---|
| Threat Intelligence and Analytics team | Data sources are properly feeding the threat intelligence engines. | Threat Intelligence Analyst/Engineer | Data feed requirements established, threat intelligence triggers from approved sources | Microsoft Defender for Identity, Microsoft Defender for Endpoint | Threat Intelligence team did not use automation script to link Microsoft 365 Defender API with threat intel engines | Add Microsoft 365 Defender as data sources to threat engines
Update use case run book |
N |
| Monitoring team | Data sources are properly feeding the monitoring dashboards | Tier 1,2 SOC Analyst–Monitoring & Alerts | Workflow for reporting Security & Compliance Center Secure Score | Alerts in Security & Compliance Center
Secure Score monitoring |
No mechanism for SOC analysts to report successful new phishing variant detection to improve Secure Score | Add a process for tracking Secure Score improvement to Reporting workflows | N |
| Engineering and SecOps Team | Change control updates are made in the SOC team runbooks | Tier 2 SOC Engineer | Change Control notification procedure for SOC team runbooks | Approved changes to security devices | Changes to Microsoft 365 Defender connectivity to SOC security technology requires approval | Add Microsoft Defender for Cloud Apps, Defender for Identity, Defender for Endpoint, Security & Compliance Center to SOC runbooks | Y |
Additionally, the SOC teams could have made the discoveries outlined in the table below in regard to the threat and vulnerability management scenario outlined above:
| SOC team | Requirement | People to meet requirement | Process to meet requirement | Relevant technology | Gap identified | Use case change log | Exempt (Y/N) |
|---|---|---|---|---|---|---|---|
| SOC Oversight | All assets connected to approved networks are identified and categorized | SOC Oversight, BU owners, application owners, IT asset owners, etc. | Centralized asset management system to discover and list asset category and attributes based on risk. | ServiceNow or other assets. | Only 70% of assets have been discovered. Microsoft 365 Defender remediation tracking only effective for known assets | Mature asset lifecycle management services to ensure Microsoft 365 Defender has 100% coverage | N |
| Engineering & SecOps Teams | High impact and critical vulnerabilities in assets are remediated according to policy | SecOps engineers, SOC analysts: Vulnerability & Compliance, Security Engineering | Defined process for categorizing High Risk and Critical Vulnerabilities | Threat and Vulnerability Management Dashboards | Defender for Endpoint has identified high impact, high alert devices with no remediation plan or implementation of Microsoft recommended activity | Add a workflow for notifying asset owners when remediation activity is required within 30 days per policy; Implement a ticketing system to notify asset owners of remediation steps. | N |
| Monitoring Teams | Threat and vulnerability status is reported via company intranet portal | Tier 2 SOC analyst | Auto-generated reports from Microsoft 365 Defender showing remediation progress of assets | Alerts in Security & Compliance Center
Secure Score monitoring |
No views or dashboard reports being communicated to asset owners regarding threat and vulnerability status of assets. | Create automation script to populate status of high risk and critical asset vulnerability remediation to the organization. | N |
In these example use cases, the testing revealed several gaps in the SOC team’s requirements that were established as baselines for the responsibilities of each team. The use case checklist can be as comprehensive as needed to ensure that the SOC team is prepared for the Microsoft 365 Defender integration with new or existing SOC requirements. Since this will be an iterative process, the use case development process and the use case output content will naturally serve to update and mature the SOC’s runbooks with lessons learned.
Update production runbooks and playbooks
Once use case testing has been remediated for all gaps, the lessons learned and metrics collected in them can be incorporated into your SOC team’s production runbooks (operating processes) and playbooks (incident responses and escalation procedures).
Maintenance of the SOC team runbooks and playbooks can be organized in a multitude of ways. Each SOC team may be responsible for their own, or there may be a single centralized version for all teams to share in a central repository. Runbook and playbook management for individual organizations is based on size, skillsets, roles, and segregation of duties. Once a runbook has been updated, the playbook update process should follow.
Use a standard framework for escalation
Playbooks are the steps the SOC teams will need to follow when a real event occurs, based on the successful integration and test of the use case. Therefore, it is imperative that the SOC follows a formalized approach to incident response, such as the NIST Incident Response Standard that has become one of the leading industry standards for incident response.
The NIST four step incident response process includes four phases:
- Preparation
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident activity
Example: Tracking preparation phase activity
One of the core foundations of an escalation playbook is to ensure there is little ambiguity as to what each SOC team is supposed to do before, during, and after an event or incident. Therefore, it is good practice to list out step by step instructions.
For example, the Preparation phase could include an if/then or XoR matrix of tasks. In the case of the new phishing variant example use case, such a matrix could look like this:
| Why is Escalation Warranted? | Next Step |
|---|---|
| Alert in SOC Monitoring rated as critical triggered > 500/hour | Go to Playbook A, Section 2, Activity 5 (with a link to the playbook section) |
| eCommerce reported potential DDoS attack | Invoke Playbook B-Section C, Activity 19 (with a link to the playbook section) |
| Executive reported a suspicious email as spear phishing attempt | Go to Playbook 5, Section 2, Activity 5 (with a link to the playbook section) |
After executing the Preparation phase, organizations should invoke the remaining phases as outlined by NIST:
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident activity