BLOG

 Pre-Draft Call for Comments | Incorporating Privacy in Awareness & Training

To help organizations incorporate privacy into their security awareness and training regimes, NIST plans to revise SP 800-50, Building an Information Technology Security Awareness and Training Program. In the nearly two decades since SP 800-50 was published in 2003, cybersecurity awareness and training resources, methodologies, and requirements have evolved considerably—and new guidance to inform this work has come from Congress and the Office of Management and Budget.  

Prior to drafting the update, NIST is seeking public comment on several topics, including the potential consolidation of companion document SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model, into the revised SP 800-50. The proposed title for SP 800-50 Revision 1 is Building a Cybersecurity and Privacy Awareness and Training Program. Comments are due by November 5, 2021. 

Your public comments will be used to influence future drafts, including an Initial Public Draft of the update which is scheduled to be released in early 2022 as SP 800-50 Revision 1.

Learn More

Blog From Microsoft

Hi, my name is Raymond Roethof, and I am a Microsoft Security enthusiast with over fifteen years of experience within the Microsoft landscape. My focus has been Microsoft Security, and specifically with the last three years out of six as a Red Teamer. In this blog post, I will go through an attacker or Red Teamer's challenges when Microsoft Defender for Identity is in place

Many organizations go through a digital transformation by the increasing use of cloud services. Understanding the current state of the cloud service is essential as maintaining the state is a shared responsibility between the company and its cloud provider.

Many Red Teamers and attackers use the on-premises environment as a stepping stone to the cloud. So, a company must understand the comprehensive set of security controls and capabilities available in Microsoft Azure, Microsoft 365, and on-premises. Active Directory can be a source for lateral movement and an excellent initial attack vector due to the high-value information it holds.

Microsoft Defender for Identity is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. Defender for Identity also protects Active Directory Federation Services (AD FS) in your environment by detecting advanced threats and providing visibility into authentication events generated by AD FS.

The default Active Directory authentication protocol is Kerberos, an authentication protocol based on tickets, and is known for being the target method of many attacks. Kerberos is an authentication protocol developed by MIT and adopted by Microsoft since Windows 2000. Kerberos can also be complicated and as a result, hard to secure.

This blog post will go through attacking Active Directory as a Red Teamer and having Defender for Identity in place to protect this high-value information. What do I have to consider before I make my next move? Let's find out how Defender for Identity makes my job so difficult.

Attack Kill Chain

As a Red Teamer or an attacker, you want to reach your goal as quickly as possible, preferably without noticing. The purpose and time it takes to perform the attack differs in every scenario. Attackers are mainly financially driven as Red Teamers have a specific pre-defined objective to reach.

Most of the attacks require multiple steps to reach their goal. Red Teamers or attackers use some form of an attack kill chain as a process.

(Figure 1 - an example of an attack kill chain process)

Note: With the digital transformation to the cloud and the complexity of most attacks, a one-size-fits-all kill chain is not feasible anymore, but the Cyber Attack Kill Chain is a good indication of how a Red Teamer or attacker performs an attack. The graphic shown above is more focused on compromising an endpoint, for example. 

 Reconnaissance of Active Directory

 Reconnaissance is a critical and consistent step in any kill chain. Most information found is likely used during an attack at a later stage. Information like server names, IP addresses, operating systems, forest architecture, trusts, service principal names (SPNs), groups and memberships, access control lists, and well-known security misconfigurations is probably part of every reconnaissance phase within Active Directory.

 The challenge as a Red Teamer (or an attacker - assume I'm referring to both throughout this blog) starts with Defender for Identity being enabled at the reconnaissance phase.

 A Red Teamer needs to have a valid set of credentials, a hash, or any form of authentication to communicate with Active Directory. Attacks like phishing e-mails can contain a malicious payload that runs under the user context. This way, a Red Teamer or attacker can perform an attack as an authenticated user. Without any authentication, a Red Teamer uses an attack like AS-Rep roasting and password sprays. If you are a Red Teamer or an attacker, Defender for Identity detects this kind of attack and alerts in almost real time.

 Lateral Movement Active Directory

 The ultimate objective for a Red Teamer is data. For most organizations, data is one of the most valuable assets. Getting access to all data at the initial entry is rare for a Red Teamer or attacker, so it is common to see lateral movement during an attack.

Let us say a Red Teamer gets a foothold, either remotely or on the network, within the environment without being noticed as an authenticated user. The next step would be to seek identities with higher privileges or an identity to access high-value assets, like data.

Attacks like Kerberoasting are also common since service accounts mainly have high privileges to services that contain high-value assets. Kerberoasting is also an attack that Defender for Identity detects. Defender for Identity also detects newer attacks like PetitPotam as well since version 2.158.14362.

Extended Detection and Response

With Extended Detection and Response (XDR), Microsoft delivers a new approach to provide intelligent, automated, and integrated security across domains to help defenders connect seemingly disparate alerts and get ahead of attackers. Due to signal sharing between Microsoft Defender for Endpoint and Defender for Identity, an indicator shows if the endpoint contains an alert within Defender for Endpoint. An analyst can isolate the endpoint within seconds, and as a Red Teamer, you will need to find another entry point to continue your journey. The analyst is also probably more alert and now monitoring the environment even closer as a result.

(Figure 2 - an illustration of an attacker navigating a minefield)

Every step we take next as a Red Teamer or an attacker is like walking in a minefield.

From on-premises to the cloud

Although many organizations go through digital transformation by the increasing their use of cloud services, attackers can use the on-premises environment as a stepping stone to the cloud. One of my blog posts describes creating a forged security token to authenticate to Azure AD using a private key from the AD FS server. Unfortunately for me, Defender for Identity now detects this method of attack as well:

(Figure 3 - A screenshot showing the alert status of an AD FS DKM key read with supporting evidence)

Curriculum 

This training program includes 16 modules. The post includes a presentation for each module, preferably recorded (when still not, we are working on the recording) and supporting information: relevant product documentation, blog posts, and other resources.

The modules listed below are split into five groups following the life cycle of a SOC:

Part 1: Overview

- Module 0: Other learning and support options

- Module 1: Get started with Azure Sentinel

- Module 2: How is Azure Sentinel used?

Part 2: Architecting & Deploying

- Module 3: Workspace and tenant architecture

- Module 4: Data collection

- Module 5: Log Management

- Module 6: Enrichment: TI, Watchlists, and more

- Module X: Migration

- Module Z: ASIM and Normalization

Part 3: Creating Content

- Module 7: The Kusto Query Language (KQL)

- Module 8: Analytics

- Module 9: SOAR

- Module 10: Workbooks, reporting, and visualization

- Module Y: Notebooks

- Module 11: Use cases and solutions

Part 4: Operating

- Module 12: A day in a SOC analyst's life, incident management, and investigation

- Module 13: Hunting

- Module 14: User and Entity Behavior Analytics (UEBA) 

- Module 15: Monitoring Azure Sentinel's health

Part 5: Advanced Topics

- Module 16: Extending and Integrating using Azure Sentinel APIs

- Module 17: Bring your own ML

Part 1: Overview

Module 0: Other learning and support options

The Ninja training is a level 400 training. If you don't want to go as deep or have a specific issue, other resources might be more suitable:

• Already did the Ninja Training? Check what's new​ in the Ninja training.
• While extensive, the Ninja training has to follow a script and cannot expand on every topic. The FAQ companion to the Ninja Training tries to closed this gap.
• Azure Sentinel's official learning path is best if you want step-by-step training to use Azure Sentinel's features.
• You can now certify with the new SC-200 certification (Microsoft Security Operations Analyst) which covers Azure Sentinel. The  SC-200 is not a Ninja Training certification, but the exam is largely based on Ninja Training materials, making it a good learning path for the certification. You may also want to consider the SC-900 certification (Microsoft Security, Compliance, and Identity Fundamentals), for a broader, higher level view of the Microsoft Security suite.
• Premier customer? You might want the on-site (or remote these days)  4 day Azure Sentinel Fundamentals Workshop. Contact your Customer Success Account Manager to arrange.
• Already a Ninja? Just keep track of what's new, or join our Private Preview program for an even earlier glimpse. 
• Have a specific issue? Ask (or answer other) on the Azure Sentinel Tech Community. As a last resort, send an e-mail to AzureSentinel@microsoft.com.

Think you're a true Sentinel Ninja? Take the knowledge check and find out. If you pass the 
knowledge check with a score of over 80% you can request a certificate to prove your ninja 
skills! 

1. Take the knowledge check here. 
2. If you score 80% or more in the knowledge check, request your participation certificate 
here. If you achieved less than 80%, please review the questions that you got it wrong, study 
more and take the assessment again.

Module 1: Get started with Azure Sentinel

Short on time? Watch the Fall Ignite presentation
Already know? The Spring Ignite session focuses on what's new and an how to use demo
Get deeper? Watch the Webinar: MP4, YouTube,Presentation

Microsoft Azure Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Azure Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response (read more).

If you want to get an initial overview of Azure Sentinel's technical capabilities, the latest Ignite presentation is a good starting point. You might also find the Quick Start Guide to Azure Sentinel useful (requires registration). A more detailed overview, however somewhat dated, can be found in this webinar: MP4, YouTube, Presentation.

Lastly, want to try it yourself? The Azure Sentinel All-In-One Accelerator  (blog, Youtube, MP4, deck) presents an easy way to get you started. To learn how to start yourself, review the onboarding documentation, or watch Insight's Sentinel setup and configuration video.

Learn from users

Thousands of organizations and service providers are using Azure Sentinel. As usual with security products, most do not go public about that. Still, there are some.

• You can find public customer use cases here,
• Insight released a use case about an NBA team adapting Sentinel.
• Stuart Gregg, Security Operations Manager @ ASOS, posted a much more detailed blog post from Azure Sentinel's experience, focusing on hunting.

Learn from Analysts

• Azure Sentinel is a Leader placement in Forrester Wave.

• Microsoft named a Visionary in the 2021 Gartner Magic Quadrant for SIEM for Azure Sentinel.

Module 2: How is Azure Sentinel used?

Short on time? Read this presentation.

Many users use Azure Sentinel as their primary SIEM. Most of the modules in this course cover this use case. In this module, we present a few additional ways to use Azure Sentinel.

As part of the Microsoft Security stack

Use Sentinel, Azure Defender, Microsoft 365 Defender  in tandem to protect your Microsoft workloads, including Windows, Azure, and Office:

• Read more about our comprehensive SIEM+XDR solution combining Azure Sentinel and Microsoft 365 Defender.
• Read The Azure Security compass to understand Microsoft's blueprint for your security operations.
• Read and watch how such a setup helps detect and respond to a WebShell attack: Blog Post, Video demo.

To monitor your multi-cloud workloads

The cloud is (still) new and often not monitored as extensively as on-prem workloads. Read this presentation to learn how Azure Sentinel can help you close the cloud monitoring gap across your clouds.

Side by side with your existing SIEM

Either for a transition period or a longer term, if you are using Azure Sentinel for your cloud workloads, you may be using Azure Sentinel alongside your existing SIEM. You might also be using both with a ticketing system such as Service Now. 

For more information on migrating from another SIEM to Azure Sentinel, watch the migration webinar: MP4, YouTube, Deck.

There are three common scenarios for side by side deployment:

• A best practice, if you have a ticketing system in your SOC, is to send alerts, or incidents, from both SIEM systems to a ticketing system such as Service Now, for example, using Azure Sentinel Incident Bi-directional sync with ServiceNow or by sending alerts enriched with supporting events from Azure Sentinel to 3rd party SIEMs.
• At least initially, many users send alerts from Azure sentinel to your on-prem SIEM. Read on how to do it in Sending alerts enriched with supporting events from Azure Sentinel to 3rd party SIEMs.
• Over time, as Azure Sentinel covers more workloads, it is typical to reverse that and send alerts from your on-prem SIEM to Azure Sentinel. To do that:
  • With Splunk, read "Send data and notable events from Splunk to Azure Sentinel using the Azure Sentinel Splunk App."
  • With QRadar read Sending QRadar offenses to Azure Sentinel
  • For ArcSight, use CEF Forwarding.

You can also send the alerts from Azure Sentinel to your 3rd party SIEM or ticketing system using the Graph Security API, which is simpler but would not enable sending additional data. 

For MSSPs

Since it eliminates the setup cost and is location agnostics, Azure Sentinel is a popular choice for providing SIEM as a service. You can find a list of MISA (Microsoft Intelligent Security Association) member MSSPs using Azure Sentinel. Many other MSSPs, especially regional and smaller ones, use Azure Sentinel but are not MISA members.

To start your journey as an MSSP, you should read the Azure Sentinel Technical Playbooks for MSSPs. More information about MSSP support is included in the next module, cloud architecture and multi-tenant support.  

Part 2: Architecting & Deploying

While the previous section offers options to start using Azure Sentinel in a matter of minutes, before you start a production deployment, you need to plan. This section walks you through the areas that you need to consider when architecting your solution, as well as provides guidelines on how to implement your design:

• Workspace and tenant architecture
• Data collection 
• Log management
• Threat Intelligence acquisition

Module 3: Workspace and tenant architecture

Short on time? Watch the Nic DiCola's Ignite presentation (first 11 Minutes)
Get Deeper? Watch the Webinar: MP4, YouTube, Presentation

An Azure Sentinel instance is called a workspace. The workspace is the same as a Log Analytics workspace and supports any Log Analytics capability. You can think of Sentinel as a solution that adds SIEM features on top of a Log Analytics workspace.

Multiple workspaces are often necessary and can act together as a single Azure Sentinel system. A special use case is providing service using Azure Sentinel, for example, by an MSSP (Managed Security Service Provider) or by a Global SOC in a large organization. 

To learn more about why use multiple workspaces and use them as one Azure Sentinel system, read Extend Azure Sentinel across workspaces and tenants or, if you prefer, the Webinar version: MP4, YouTube, Presentation.

There are a few specific areas that require your consideration when using multiple workspaces:

• An important driver for using multiple workspaces is data residency. Read more about Azure Sentinel data residency.
• To deploy Azure Sentinel and manage content efficiently across multiple workspaces; you would like to manage Sentinel as code using CI/CD technology. This is, in general, a recommended best practice for Azure sentinel:
  •  Read deploying and Managing Azure Sentinel - Ninja style for a comprehensive CI/CD methodology.
  • Or use a simpler solution to deploy and Managing Azure Sentinel as Code and extend this capability across workspaces and tenants using Azure Lighthouse. 
• When managing multiple workspaces as an MSSP, you may want to protect the MSSP’s Intellectual Property in Azure Sentinel.

The Azure Sentinel Technical Playbook for MSSPs provides detailed guidelines for many of those topics, and is useful also for large organizations, not just to MSSPs.

Module 4: Data collection

Sept 2021 update: our latest webinar on data collection scenarios by Edi Lahav and Yaniv 
Shasha. YouTube, MP4, Deck

Short on time? Watch the Nic DiCola's Ignite presentation (Mid 11 Minutes)
Get Deeper? Watch the Webinar: YouTube, MP4, Deck.

The foundation of a SIEM is collecting telemetry: events, alerts, and contextual enrichment information such as Threat Intelligence, vulnerability data, and asset information. You can find a list of sources you can connect here:

• Documentation of the connectors which are part of the connectors gallery.
• The Grand List of sources you can connect to Azure Sentinel, whether part of the gallery or not (note: this list is no longer being updated).

How you connect each source falls into several categories or source types. Each source type has a distinct setup effort but once deployed,  it serves all sources of that type. The Grand List specifies for each source what its type is. To learn more about those categories, watch the Webinar (includes Module 3): YouTube, MP4, Deck.

The types are:

• Built-in service-to-service connectors allow Azure Sentinel to connect directly to cloud services such as Office 365 or AWS CloudTrail. Some of the service-to-service connectors, such as AAD, utilize Azure diagnostics behind the scenes. 

• Direct refers to sources that natively know how to send data to Azure Sentinel or Log Analytics. These include Azure services or other Microsoft solutions that support sending telemetry (often referred to as "diagnostics") to Log Analytics and 3rd party sources that use the ingestion API to write to Log analytics or Azure Sentinel directly. The Microsoft direct sources are listed in addition to the Grand List and in the blog post "Collecting logs from Microsoft Services and Applications."

• The Log Forwarder is a VM that enables collecting Syslog and CEF events from remote systems. If a source is listed in the Grand List as CEF or Syslog, you will use the Log Forwarder to collect from it. Learn more about the Log Forwarder in this webinar (plus a bonus: learn how to use it to filter events):  YouTube, MP4, Deck.

• The Log Analytics agent collects information from Windows or Linux hosts. In addition to OS events such as Windows Events, the agent can collect events stored in files. Learn more about the Log Analytics agent in this blog: collecting telemetry from on-prem and IaaS server using the Log Analytics agent. The Azure Monitor Agent is a new generation agent currently in preview that offers advantages such as Windows events filtering. The Log Analytics agent is being deprecated on 31 August 2024, so if you have not yet deployed the Log Analytics agent you should consider whether it is possible for you to start using the Azure Monitor Agent (see next bullet point).

• The Azure Monitor Agent (AMA) is the replacement for the Log Analytics Agent. The Azure Monitor agent introduces several new capabilities not available in the Log Analytics agent such as filtering, scoping, and multi-homing. At the time of writing this update, AMA isn't yet at parity with the Log Analytics agent, although this will change over time. Consider whether the features you need for your Azure Sentinel deployment are supported in AMA, or whether to continue to use the Log Analytics agent for now and migrate at a later date. You can sign up for the Everything You Ever Wanted to Know About Using the New Azure Monitor Agent (AMA) with Azure Sentinel on Nov 22 here.

• ELK's Logstash and Beats can be used as an alternative to both the agent and Log Forwarder using the Azure Sentinel Logstash output plug-in.

• Integrate Threat Intelligence (TI) sources using the built-in connectors from TAXII servers or Microsoft Graph Security API. Read more on how to in the documentation. TI can also be important as a custom log using a custom connector or as a lookup table. You can read more about how TI is used managed in Azure Azure in the TI modules later. 

If your source is not available, you can create a custom connector. Custom connectors use the ingestion API and therefore are similar to direct sources. Custom connectors are most often implemented using Logic Apps, offering a codeless option, or Azure Functions.

Module 5: Log Management

While how many and which workspaces to use is the first architecture question to ask, there are additional log management architectural decisions:

• Where and how long to retain data.
• How to best manage access to data and secure it. 

Retention

• If you want to retain data for more than two years or reduce the retention cost, you can consider using Azure Data Explorer for long-term retention of Azure Sentinel logs: Webinar Slides, Webinar Recording, Blog)
• If you prefer another long-term retention solution, export from Azure Sentinel / Log Analytics to Azure Storage and Event Hub or move Logs to Long-Term Storage using Logic Apps. The latter advantage is that it can export historical data.
• Lastly, you can set fine-grained retention periods using table-level retention Settings (and documentation)

Logs Security

• Use resource RBAC or table Level RBAC to enable multiple teams to use a single workspace.
• If needed, delete PII data from your workspaces.
• Learn how to audit workspace queries and Azure Sentinel use, using alerts workbooks and queries.
• Use private links to ensure logs never leave your private network.

Dedicated cluster

• More than 1TB/d? You can have your own Log Analytics dedicated cluster. 

Module 6: Enrichment: TI, Watchlists, and more

One of the important functions of a SIEM is to apply contextual information to the event steam, enabling detection, alert prioritization, and incident investigation. Contextual information includes, for example, threat intelligence, IP intelligence, host and user information, and watchlists.

Azure Sentinel provides comprehensive tools to import, manage, and use threat intelligence. For other types of contextual information, Azure Sentinel provides Watchlists, as well as alternative solutions.

Threat Intelligence

Sept 2021 update: Sign up for the Explore the Power of Threat Intelligence in Azure Sentinel
webinar on Oct 25 here.

Short on time? watch the Ignite session (28 Minutes)
Get Deeper? Watch the Webinar: YouTube, MP4, Presentation

Threat Intelligence is an important building block of a SIEM.

In Azure Sentinel, you can integrate threat intelligence (TI) using the built-in connectors from TAXII servers or through the Microsoft Graph Security API. Read more on how to in the documentation. Refer to the data collection modules for more information about importing Threat Intelligence. 

Once imported, Threat Intelligence is used extensively throughout Azure Sentinel and is weaved into the different modules. The following features focus on using Threat Intelligence:

• View and manage the imported threat intelligence in Logs in the new Threat Intelligence area of Azure Sentinel.
• Use the built-in TI Analytics rule templates to generate security alerts and incidents using your imported threat intelligence.
• Visualize key information about your threat intelligence in Azure Sentinel with the Threat Intelligence workbook.

Watch the Webinar: YouTube, MP4, Presentation

Watch the Understanding Normalization in Azure Sentinel webinar: YouTube, Presentation
Watch the Deep Dive into Azure Sentinel Normalizing Parsers and Normalized Content webinar: 
YouTube, MP3, Presentation

Sign up for the Turbocharging ASIM: Making Sure Normalization Helps Performance Rather Than 
Impacting It webinar on Oct 6 here.

Part 3: Creating Content

What is Azure Sentinel's content?

Azure Sentinel security value is a combination of its built-in capabilities such as UEBA, Machine Learning, or out-of-the-box analytics rules and your capability to create custom capabilities and customize built-in ones. Customized SIEM capabilities are often referred to as "content" and include analytic rules, hunting queries, workbooks, playbooks, and more.

In this section, we grouped the modules that help you learn how to create such content or modify built-in-content to your needs.  We start with KQL, the Lingua Franca of Azure Sentinel. The following modules discuss one of the content building blocks such as rules, playbooks, and workbooks. We wrap up by discussing use cases, which encompass elements of different types to address specific security goals such as threat detection, hunting, or governance. 

Module 7: KQL

Short on time? Start at the beginning and go as far as time allows.

Most Azure Sentinel capabilities use KQL or Kusto Query Language. When you search in your logs, write rules, create hunting queries, or design workbooks, you use KQL.  Note that the next section on writing rules explains how to use KQL in the specific context of SIEM rules.

We suggest you follow this Sentinel KQL journey:

1. Pluralsight KQL course - the basics
2. The Azure Sentinel KQL Lab: An interactive lab teaching KQL focusing on what you need for Azure Sentinel:
   1. Learning module (SC-200 part 4)
   2. Deck, Lab URL 
   3. a Jupyter Notebooks version contributed by jjsantanna, which let you test the queries within the notebook.
   4. Learning webinar: Youtube, MP4;
   5. Reviewing lab solutions webinar: YouTube, MP4
3. Pluralsight Advanced KQL course
4. Optimizing Azure Sentinel KQL queries performance: YouTube, MP4, Deck.
5. Using ASIM in your KQL queries: YouTube, Deck

You might also find the following reference information useful as you learn KQL:

• The KQL Cheat Sheet
• Query optimization best practices

Module 8: Analytics

Writing Scheduled Analytics Rules

Short on time? watch the Webinar: MP4, YouTube, Presentation

Azure Sentinel enables you to use built-in rule templates, customize the templates for your environment, or create custom rules. The core of the rules is a KQL query; however, there is much more than that to configure in a rule.

To learn the procedure for creating rules, read the documentation. To learn how to write rules, i.e., what should go into a rule, focusing on KQL for rules, watch the webinar: MP4, YouTube, Presentation.

SIEM rules have specific patterns. Learn how to implement rules and write KQL for those patterns:  

• Correlation rules: using lists and the "in" operator or using the "join" operator
• Aggregation: see using lists and the "in" operator above, or a more advanced pattern handling sliding windows
• Lookups: Regular, or Approximate, partial & combined lookups
• Handling false positives
• Delayed events: are a fact of life in any SIEM and are hard to tackle. Azure Sentinel can help you mitigate delays in your rules.
• Using KQL functions as building blocks: Enriching Windows Security Events with Parameterized Function.

To blog post "Blob and File Storage Investigations" provides a step by step example of writing a useful analytic rule.

Using built-in analytics

Short on time? watch the Machine Learning Webinar: MP4, YouTube, Presentation

Before embarking on your own rule writing, you should take advantage of the built-in analytics capabilities. Those do not require much from you, but it is worthwhile learning about them:

• Use the built-in scheduled rule templates. You can tune those templates by modifying the templates the same way to edit any scheduled rule. Make sure to deploy the templates for the data connectors you connect listed in the data connector "next steps" tab.
• Learn more about Azure Sentinel's Machine learning capabilities: MP4, YouTube, Presentation
• Find the list of Azure Sentinel's Advanced multi-stage attack detections ("fusion") are enabled by default.
• Watch the Fusion ML Detections with Scheduled Analytics Rules webinar: YouTube, MP4, Presentation.
• Learn more about Azure Sentinel's built-in SOC-ML anomalies here. Sign up for a webinar on customized SOC-ML anomalies and how to use them here on Sept 14.

Module 9: Implementing SOAR

Sept 2021 update: sign up for the What’s New in Azure Sentinel Automation webinar on Oct 28 
here.

Short on time? watch the Webinar: YouTube, MP4, Deck

In modern SIEMs such as Azure Sentinel, SOAR (Security Orchestration, Automation, and Response) comprises the entire process from the moment an incident is triggered and until it is resolved. This process starts with an incident investigation and continues with an automated response. The blog post "How to use Azure Sentinel for Incident Response, Orchestration and Automation" provides an overview of common use cases for SOAR.

Automation rules are the starting point for Azure Sentinel automation. They provide a lightweight method for central automated handling of incidents, including suppression, false-positive handling, and automatic assignment.

To provide robust workflow based automation capabilities, automation rules use Logic App playbooks:

• Watch the Logic Apps Sentinel playbooks Webinar: YouTube, MP4, Deck
• Read about Logic Apps, which is the core technology driving Azure Sentinel playbooks.
• The Azure Sentinel Logic App connector is a link between Logic Apps and Azure Sentinel.

You can find dozens of useful Playbooks in the Playbooks folder on the Azure Sentinel GitHub, or read "A playbook using a watchlist to Inform a subscription owner about an alert" for a Playbook walkthrough.

While Azure Sentinel is a cloud-native SIEM, its automation capabilities do extend to on-prem environments, either using the Logic Apps on-prem gateway or using Azure Automation as described in "Automatically disable On-prem AD User using a Playbook triggered in Azure"

Module 10: Workbooks, reporting, and visualization

Short on time? Watch the Webinar: YouTube, MP4, Deck

Workbooks

As the nerve center of your SOC, you need Azure Sentinel to visualize the information it collects and produces. Use workbooks to visualize data in Azure Sentinel.

• To learn how to create workbooks, read the documentation or watch Billy York's Workbooks training (and accompanying text).
• Those resources are not Azure Sentinel specific, and apply to Azure Wrokbooks in general. To learn more about Workbooks in Azure Sentinel, watch the Webinar: YouTube, MP4, Deck, and read the documentation.

Workbooks can be interactive and enable much more than just charting. With Workbooks, you can create apps or extension modules for Azure Sentinel to complement built-in functionality. We also use workbooks to extend the features of Azure Sentinel. Few examples of such apps you can both use and learn from are:

• The Investigation Insights Workbook provides an alternative approach for investigating incidents.
• Graph Visualization of External Teams Collaborations enables hunting for risky Teams use.
• The users' travel map workbook allows investigating geo-location alerts.
• The insecure protocols workbook (Implementation Guide, recent enhancements, and overview video) let you identify the use of insecure protocols in your network.
• Lastly, learn how to integrate information from any source using API calls in a workbook.

You can find dozens of workbooks in the Workbooks folder in the Azure Sentinel GitHub. Some of those are available in the Azure Sentinel workbooks gallery and some are not. 

Reporting and other visualization options

Workbooks can serve for reporting. For more advanced reporting capabilities such as reports scheduling and distribution or pivot tables, you might want to use:

• Power BI, which natively integrates with Log Analytics and Sentinel.
• Excel, which can use Log Analytics and Sentinel as the data source (and see a a video on how)
• Jupyter notebooks covered later in the hunting module are also a great visualization tool.

Module Y: Notebooks

Short on time? Watch the short introduction video 
Get Deeper? Watch the Webinar: YouTube, MP4, Presentation

Jupyter notebooks are fully integrated with Azure Sentinel. While usually considered an important tool in the hunter's tool chest and discussed the webinars in the hunting section below, their value is much broader. Notebooks can serve for advanced visualization, an investigation guide, and for sophisticated automation.

To understand them better, watch the Introduction to notebooks video. Get started using the Notebooks webinar (YouTube, MP4, Presentation) or by reading the documentation.

An important part of the integration is implemented by MSTICPY, a Python library developed by our research team for use with Jupyter notebooks that adds Azure Sentinel interfaces and sophisticated security capabilities to your notebooks.

Module 11: Use cases and solutions

Sept 21 update: sign up for the Create Your Own Azure Sentinel Solutions webinar on Nov 16 
here.

Short on time? watch the "Tackling Identity" Webinar: YouTube, MP4, Deck

Using connectors, rules, playbooks, and workbooks enables you to implement use cases: the SIEM term for a content pack intended to detect and respond to a threat. You can deploy Sentinel built-in use cases by activating the suggested rules when connecting each Connector. A solution is a group of use cases addressing a specific threat domain.

The Webinar "Tackling Identity" (YouTube, MP4, Presentation) explains what a use case is, how to approach its design, and presents several use cases that collectively address identity threats.

Another very relevant solution area is protecting remote work. Watch our ignite session on protection remote work, and read more on the specific use cases:

• Microsoft Teams hunting use cases and Graph Visualization of External Microsoft Teams Collaborations
• Monitoring Zoom with Azure Sentinel: custom connectors, analytic rules, and hunting queries.
• Monitoring Windows Virtual Desktop with Azure Sentinel: use Windows Security Events, Azure AD Sign-in logs, Microsoft 365 defender for endpoints, and WVD diagnostics logs to detect and hunt for WVD threats.
• Monitor Microsoft endpoint Manager / Intune, using queries and workbooks.

And lastly, focusing on recent attacks, learn how to monitor the software supply chain with Azure Sentinel.

Azure Sentinel solutions provide in-product discoverability, single-step deployment, and enablement of end-to-end product, domain, and/or vertical scenarios in Azure Sentinel. Read more about them here, and sign up for the upcoming webinar on Nov 16 on how to create solutions here.

Part 4: Operating

Module 12: Handling incidents

Sept 21 update: sign up for the Decrease Your SOC’s MTTR (Mean Time to Respond) by Integrating 
Azure Sentinel with Microsoft Teams webinar on Nov 10 here.

Short on time? Watch the "day in a life" Webinar: YouTube, MP4, Deck

After building your SOC, you need to start using it. The "day in a SOC analyst life" webinar (YouTube, MP4, Presentation) walks you through using Azure Sentinel in the SOC to triage, investigate and respond to incidents.

Integrating with Microsoft Teams directly from Azure Sentinel enables your teams to collaborate seamlessly across the organization, and with external stakeholders. Sign up for the Decrease Your SOC’s MTTR (Mean Time to Respond) by Integrating Azure Sentinel with Microsoft Teams webinar on Nov 10 here.

You might also want to read the documentation article on incident investigation. As part of the investigation, you will also use the entity pages to get more information about entities related to your incident or identified as part of your investigation.

Incident investigation in Azure Sentinel extends beyond the core incident investigation functionality. We can build additional investigation tools using Workbooks and Notebooks (the latter are discussed later, under hunting). You can also build additional investigation tools or modify ours to your specific needs. Examples include: 

• The Investigation Insights Workbook provides an alternative approach for investigating incidents.
• Notebooks enhance the investigation experience. Read 'Why Use Jupyter for Security Investigations?" and learn how to investigate with Azure Sentinel & Jupyter Notebooks: part 1, part 2, and part 3.

Module 13: Hunting

Short on time? watch the Webinar: YouTube, MP4, Deck
(Note that the Webinar starts with an update on new features, to learn about hunting, start at slide 12. The YouTube 
link is already set to start there)

While most of the discussion so far focused on detection and incident management, hunting is another important use case for Azure Sentinel. Hunting is a proactive search for threats rather than a reactive response to alerts. 

The hunting dashboard was recently refreshed in July 2021 and shows all the queries written by Microsoft's team of security analysts and any extra queries that you have created or modified. Each query provides a description of what it hunts for, and what kind of data it runs on. These templates are grouped by their various tactics - the icons on the right categorize the type of threat, such as initial access, persistence, and exfiltration. Read more about it here.

To understand more about what hunting is and how Azure Sentinel supports it, Watch the hunting intro Webinar (YouTube, MP4, Deck). Note that the Webinar starts with an update on new features. To learn about hunting, start at slide 12. The YouTube link is already set to start there.

While the intro webinar focuses on tools, hunting is all about security. Our security research team webinar on hunting (MP4, YouTube, Presentation) focuses on how to actually hunt. The follow-up AWS Threat Hunting using Sentinel Webinar (MP4, YouTube, Presentation) really drives the point by showing an end-to-end hunting scenario on a high-value target environment. Lastly, you can learn how to do SolarWinds Post-Compromise Hunting with Azure Sentinel and WebShell hunting motivated by the latest recent vulnerabilities in on-premises Microsoft Exchange servers.

Module 14: User and Entity Behavior Analytics (UEBA)

Short on time? Watch the Webinar: MP4, YouTube, Deck

Azure Sentinel newly introduced User and Entity Behavior Analytics (UEBA) module enables you to identify and investigate threats inside your organization and their potential impact - whether a compromised entity or a malicious insider.

Learn more about UEBA in the UEBA Webinar (MP4, YouTube, Deck) and read about using UEBA for investigations in your SOC. 

Module 15: Monitoring Azure Sentinel's health

Short on time? watch the videos on monitoring connectors, 
security operations health or workspace audit.

Part of operating a SIEM is making sure it works smoothly and an evolving area in Azure Sentinel. Use the following to monitor Azure Sentinel's health:

• Measure the efficiency of your Security operations (video)
• Monitor Data connectors health (video) and get notifications on anomalies
• Monitor agents using the agents' health solution (Windows only) and the Heartbeat table (Linux and Windows)
• Monitor your Log Analytics workspace: YouTube, MP4, Presentation, including query execution and ingest health
• Cost management is also an important operational procedure in the SOC. Use the Ingestion Cost Alert Playbook to ensure you are aware in time of any cost increase. 

Part 5: Advanced Topics

Module 16: Extending and Integrating using Azure Sentinel APIs

Short on time? watch the video (5 minutes)
Get deeper? Watch the Webinar: MP4, YouTube, Presentation

As a cloud-native SIEM, Azure Sentinel is an API first system. Every feature can be configured and used through an API, enabling easy integration with other systems and extending Sentinel with your own code. If API sounds intimidating to you, don't worry; whatever is available using the API is also available using PowerShell.

To learn more about Azure Sentinel APIs, watch the short introductory video and blog post. To get the details, watch the deep dive Webinar (MP4, YouTube, Presentation) and read the blog post  Extending Azure Sentinel: APIs, Integration, and management automation.

Module 17: Bring your own ML

Short on time? watch the video

Azure Sentinel provides a great platform for implementing your own Machine Learning algorithms. We call it Bring Your Own ML or BYOML for short. Obviously, this is intended for advanced users. If you are looking for built-in behavioral analytics, use our ML Analytic rules, UEBA module, or write your own behavioral analytics KQL based analytics rules.

To start with bringing your own ML to Azure Sentinel, watch the video, and read the blog post. You might also want to refer to the BYOML documentation. 

• https://docs.microsoft.com/en-us/azure/sentinel/bring-your-own-ml
• Azure Sentinel Build-Your-Own ML Model video

 In an ongoing effort to provide practical and actionable guidance to help organizations manage growing cybersecurity risks, NIST has released a draft ransomware risk management profile. The Cybersecurity Framework Profile for Ransomware Risk Management, Draft NISTIR 8374, is now open for comment through October 8, 2021.

The draft profile, prepared by the National Cybersecurity Center of Excellence (NCCoE), identifies security objectives from the NIST Cybersecurity Framework that can help prevent, respond to, and recover from ransomware events. It can be used as a guide to managing risk—including helping gauge an organization’s readiness to mitigate ransomware threats and react to potential impacts. The profile addresses issues that were raised in public comments on a preliminary draft released in June.

Read More

 Registration is OPEN for the 8th annual New York Metro Joint Cyber Security Conference & Workshop (Oct. 14/15). Find out more at https://infosecurity.nyc

How to Gain More from your Connection to an OT Network

One of the most productive and non-intrusive tools in the Cyber Security Engineer’s bag is passive Network Traffic Analysis (NTA).  Providing network maps, inventory, and firmware information among other benefits provides insights that are not generally known any other way.  Manual inventory collection methods are error-prone and expose this information to interception over corporate email networks, shared file folders, etc.  But how do we implement this kind of system without causing any bumps in the road for real-time processes?  What are the risks?  Which methods are best?  The best sensor does no good unconnected and is of little value connected in the wrong part of the network. 

 To discuss this, I will use a diagram that was developed for my last blog post Designing a Robust Defense for Operational Technology Using Azure Defender for IoT (microsoft.com).  This diagram (below) shows an example OT network monitored by Azure Defender for IoT. Defender for IoT is an agentless passive Network Traffic Analysis tool with strong roots in Operational Technology, now expanding to IoT. Defender for IoT discovers OT/IoT devices, identifies vulnerabilities, and provides continuous OT/IoT-aware monitoring of network traffic.  The recommended locations for Azure Defender for IoT  (AD4IoT) are shown in red color.  Why have these locations been chosen?  To explain this, we will break this network into pieces and address these issues for each type of traffic.

 Starting with the lower portion of this sketch, let’s look at traffic flows around the PLCs. 

  1. The first arrow shows traffic between a PLC and its ethernet-connected Input/Output (I/O) modules.  This traffic utilizes simplistic protocols and is very structured and periodic.  It can be leveraged as a threat to the overall OT system and is more vulnerable when I/O is remote from the PLCs in unsecured areas.  Malicious applications could perform inappropriate control actions and/or falsify data.  Firmware problems in I/O modules often go unpatched unless some form of undesirable behavior is experienced. In certain families of PLCs or controllers, the Defender for IoT can provide data on firmware levels and types of I/O modules if this data is requested by an HMI or historian. 

 The mechanism to monitor this traffic is to span switches used in the I/O subsystem as shown here.  If they are unmanaged switches, taps may be located at the connection to the PLC or controller.

 2. The second arrow identifies traffic from Variable Frequency Drives or similar equipment often interfaced with the PLCs or Controllers.  This communication may be Modbus, Rockwell Protocols, or CIP.  Equipment could be damaged or destroyed by inappropriate commands sent to such devices.  Good engineering practice would put bounds of reasonability around all potential setpoints, but this may not be the case.  These protocols are well understood and in the public domain.  A man-in-the-middle attack could affect this type of equipment.  Monitoring these communications can identify inappropriate function calls, program or firmware changes, and parameter updates. As above, switch span or taps are the mechanisms to monitor this traffic.

 3. Custom engineered systems may utilize well-known, open OT protocols such as Modbus, OPC, or others.  This traffic should be monitored even if it is not fully understood as the behavior patterns should be very predictable.  It is common for these systems to utilize unusual functions and atypical ranges for data.  This is the result of a developer reading a protocol spec with no actual field experience with the protocol.  Custom alerts can be configured and tuned based on the nature of the data.  Since such systems are engineered to order for a specific purpose, the damage could have long-term implications on plant production.

 4. Traffic crossing OT Access-level switches should always be monitored.  This is the primary point at which PLCs or controllers communicate with HMIs, engineering stations, and sometimes historians.  The problem here is that these switches carry the actual OT control traffic.  Any action that could compromise this traffic affects the reliability of the OT system.  Many switches at the I/O and access layers may be unmanaged devices.  By unmanaged, I mean that they are not configurable and therefore cannot support a SPAN (or mirror) session. 

 Unmanaged switches is not an insurmountable hurdle.  Two possible paths may be followed from this point.  The least intrusive is to install network taps.  The security engineer should consult with the OT engineer on the most valuable locations for taps.  Since a stand-alone tap monitors only one data stream, the most valuable assets (compromise targets) should be monitored. These would normally be at least the engineering station, historian and/or alarms server (if appropriate), and HMIs, particularly those with engineering tools installed.  If it is necessary to monitor all traffic, a tap aggregator may be used.

Another approach would be to replace the unmanaged switches with managed switches.  This may sound daunting but usually is not.  Most managed switches are configured to “wake up” in a basic mode which approximates an unmanaged switch.  So replacement, while requiring a system shutdown, can be accomplished rather quickly and have the system up and functioning again.  Once this is done, the configuration can be added to provide basic security and copy traffic to a SPAN or mirror port.  Make sure these configurations are saved as most switches make changes to operating memory which is not stored on power reset.  It is generally recommended to discuss this change with your OT support personnel and/or OEM service engineers.  They probably have some standard switch configurations that they apply when a customer requests managed switches.  Additionally, they should be able to provide you with approximate bus speeds needed to support OT traffic with mirroring.

What are the risks? In the case of switch SPAN (SwitchPort ANalyzer), or mirror sessions, the only concern of serious significance is the current traffic level on the switch.  If a SPAN session is added to a heavily loaded switch, the SPAN may drop packets because the SPAN session is a lower priority than actual switching traffic. This could mean that some packets might slip through unmonitored.  However, it does not affect the normal functioning of the switch for ICS traffic.  Some switches, if they are greatly overloaded can revert to ‘flood mode’ in which they act as a network hub.  This situation is extremely rare.  If switch SPANning is chosen as a method, it is wise to monitor network traffic on the switch prior to adding the session.  Assume that a full switch span will double the switch backbone traffic. 

 If network taps are installed, the risks are insignificant.  Passive taps should of course be chosen.  Passive means that the tap continues to pass control traffic even if it loses power.  Passive taps are simply inserted in-line with the existing traffic, see sketch below.  Installation needs to be coordinated with OT engineers to limit the impact on operating processes. 

 Next, we will discuss special equipment including analysis devices and robotics.  This portion of the overall diagram is shown below.  

Network traffic to analyzers typically looks like normal PC traffic using common IT protocols.  Most analyzers have some form of controller that is designed for a specific function.  Sometimes the PC is the controller, utilizing specialized I/O boards included in the machine. Some analyzers or groups of analyzers may be managed by mini computers.   In any case, from a network security perspective, these devices appear on the network as computers, not analyzers per se.  Patching of these customized machines often lags behind the upgrade strategies used for standard IT equipment.  Upgrades to analysis systems must be approved by, and often be implemented by the OEMs which may be expensive and involve downtime. Because of infrequent patching and/or OS upgrades, this equipment can become a security liability on a lab network. Ideally, lab equipment should be separated either physically onto separate networks or via VLANs, but such changes may require extensive planning and testing and still can be disruptive to ongoing lab processes.

Most major medical laboratories utilize either a LIMS (Laboratory Information Management System) or a middleware server to collect analytics data from these devices and forward that data to a patient information database managed either locally or in the cloud (see sketch below).  Hence, the traffic to/from the analyzer will be most easily recognized by the ultimate destination at the middleware or LIMS.  Since these potentially vulnerable machines may process interactions with users on the lab network for input data or maintenance functions, they should be monitored more closely than fully patched IT machines.  This presents a challenge to lab IT managers who may want to gain a handle on this type of OT equipment in their network but may not have good inventory information. 

Since medical testing facilities utilize normal switched networks, monitoring should be installed at an appropriate location to ‘see’ all the traffic from analyzers to the middleware or LIMS server.  This could be either core or distribution level switches depending on the network design.  Standard SPAN or mirror traffic can be used.

Dual-homed machines present special security challenges since they could be converted to active routers by malware.  It is common for expensive lab or analysis equipment to be leased.  OEM terms and conditions specify how this equipment may be used and what service it requires to achieve contracted performance.  This is often monitored via a ‘secure’ datalink to the manufacturer’s support site.  These may or may not be bi-directional.  These links are generally firewalled, either by the OEM, by the customer or by both.  Bi-directional links are inherently a threat.  Remote access to a computer on the lab network can put much more than that computer in jeopardy. 

In robotic applications, the primary issue is the speed of response.  The control systems are complex, utilizing high-level programming toolsets.  The low-level communication may not utilize standard ethernet framing.  Robot protocols vary widely and include Ethernet/IP, DeviceNet, Profibus-DP, Profinet, CC-Link, and EtherCat protocols.  Physical media may be Cat5/6, but RG-6 coaxial, twisted pair, RS-485, and fiber are also used.  Monitoring the low-level communication between controllers and robots requires careful coordination with the equipment designer and should not be attempted casually.  Network monitoring should utilize taps. Switch SPAN, or mirroring is not recommended. 

 As described above, most industrial robots are programmed using a computer workstation.  Downloading and selection of programs may be manual or automated using standard network protocols. So, monitoring should focus on the programming workstations and the source of robot program selections.  Robot program file downloads may be transferred from a central server.  These could occur over SFTP, FTP, SMB, or other methods. 

 Finally, we would like to address the OT interface to the business (Enterprise) network.  This can be a gateway for potential threats to OT systems.  Some vulnerabilities that may be unsuccessful in the IT network space may cause severe problems in the OT space because the machines may not be patched.  Out of date and unsupported operating systems may be in use.  As a result, traffic that enters from the Enterprise network and ultimately reaches the OT network should be monitored. 

 Generally, good practice prevents any direct traversal of the DMZ.  For instance, remote desktop sessions should be hosted by a RAS server in the DMZ which is then used to open a remote desktop session into an OT machine with different credentials. Elaborate credential systems with short password lives attempt to increase the challenge for attackers attempting to gain control.  Well designed implementations keep all machines in the DMZ patched up-to-date which should limit the effect of known vulnerabilities. 

 Zero day vulnerabilities will always be a threat prior to discovery.  So, monitoring sessions entering the DMZ from the Enterprise and those leaving the DMZ for the OT network are an important part of a security design.  Similarly, monitoring traffic from the OT network to a Historian server and Enterprise connections to that same server could uncover issues.  Since these sessions are often encrypted, efforts should focus on the legitimacy of the Enterprise hosts, times of access, data rates, and other indicators to validate these externally generated sessions.

 The DMZ is also used as a connection point for a variety of other facility systems such as IP phones; perimeter security systems; weather stations; contracted supply systems like water purification, compressed air supply and the like; wireless devices; etc.  In most cases, these various systems are assigned separate VLANs and subnets.  By monitoring all the VLANS in this zone, suspicious traffic can be identified and managed.  Traffic originating from any of these devices to the ICS network should not normally exist. 

Subnet-to-subnet traffic could be cause for concern.  This is another area where Defender for IoT can help.  By mapping the assets, assigning them to VLANs, subnets, and user assigned subsystems, communication between the various device groups can be easily seen greatly aiding efforts to perform or monitor network segregation.  

 The visual network map produced by Defender for IoT in conjunction with the filtering capabilities on the map make it easy to identify interconnections between various plant control systems. Having a powerful visual of group-to-group communication makes the effort of segmentation much easier.  This process is a long and tedious one using arp tables on switches.  Also, if this effort is underway, the map will show areas that may have been overlooked.

 Conclusions:

 Well-engineered connections to ICS networks can yield valuable results, including accurate inventories, network maps, and improved security with no risk to the reliability of the underlying OT systems.  This information can be combined, in Azure Sentinel or other SIEM/SOAR solutions, with agent-based Defender for endpoint data to produce a complete picture of OT networks.  Custom-designed playbooks can assist your analysts in responding to OT or IoT issues.  

Teamwork between OT engineers and IT security personnel can yield benefits for both groups while presenting a more challenging landscape to potential intruders.

As we know, each organization is unique and have different use cases and scenarios in mind when it come to security operations. Nevertheless we've identified several use cases that are common across many SOC teams.

Azure Sentinel now provides built-in watchlist templates, which you can customize for your environment and use during investigations.

After those watchlists are populated with data, you can correlate that data with analytics rules, view it in the entity pages and investigation graphs as insights, create custom uses such as to track VIP or sensitive users, and more.

Watchlist templates currently include:

• VIP Users. A list of user accounts of employees that have high impact value in the organization.
• Terminated Employees. A list of user accounts of employees that have been, or are about to be, terminated.
• Service Accounts. A list of service accounts and their owners.
• Identity Correlation. A list of related user accounts that belong to the same person.
• High Value Assets. A list of devices, resources, or other assets that have critical value in the organization.
• Network Mapping. A list of IP subnets and their respective organizational contexts.

Watchlists templates insights in entity pages

We've created the watchlists templates schemas to be super easy and extensible, in order for you to populate it with the relevant data. more information about using the watchlists templates can be found here.

What’s next?

Beside surfacing the watchlists templates data inside the entity pages, we're working on embedding this information in the UEBA anomalies, and the entity risk score which is planned next. Understanding if a user is a VIP/Terminated or an asset is an HVA is important to provide both context and security value for the analyst while investigating.

In collaboration with the Microsoft Threat Intelligence Center (MSTIC), we are excited to announce Fusion detection for ransomware is now publicly available!

These Fusion detections correlate alerts that are potentially associated with ransomware activities that are observed at defense evasion and execution stages during a specific timeframe. Once such ransomware activities are detected and correlated by the Fusion machine learning model, a high severity incident titled “Multiple alerts possibly related to Ransomware activity detected” will be triggered in your Azure Sentinel workspace.

In order to help your analyst quickly understand the possible attack, Fusion provides you with a complete picture for the suspicious activities happened on the same device/host by correlating signals from Microsoft products as well as signals in network and cloud. Supported data connectors include:

• Azure Security Center
• Microsoft Cloud App Security
• Microsoft Defender for Endpoint
• Microsoft Defender for Identity
• Azure Sentinel scheduled analytics rules. Fusion only considers scheduled analytics rules with tactics information.

The screenshot below shows a Fusion incident with 22 alerts. It correlates low severity signals that were detected around the same timeframe from the network and the host to show a possible ransomware attack and the different techniques used by attackers.

For more information, see Multiple alerts possibly related to Ransomware activity detected.

Why Fusion detection for ransomware?

Ransomware attack is a type of attack that involves using specific types of malicious software or malware to make network or system inaccessible for the purpose of extortion – ‘ransom’. There is no doubt that ransomware attacks have taken a massive turn in being the top priority as a threat to many organizations. A recent report released by PurpleSec revealed that the estimated cost of ransomware attacks was $20 billion in 2020 and with downtime increasing by over 200% and the cost being 23x higher than 2019.

Preventing such attacks in the first place would be the ideal solution but with the new trend of ‘ransomware as a service’ and human operated ransomware, the scope and the sophistication of attacks are increasing – attackers are using slow and stealth techniques to compromise network, which makes it harder to detect them in the first place.

With Fusion detection for ransomware that captures malicious activities at the defense evasion and execution stages of an attack, it gives security analysts an opportunity to quickly understand the suspicious activities happened around the same timeframe on the common entities, connect the dots and take immediate actions to disrupt the attack. When it comes to ransomware attacks, time more than anything else is the most important factor in preventing more machines or the entire network from getting compromised. The sooner such alerts are raised to security analysts with the details on various attacker activities, the faster the ransomware attacks can be contained and remediated. A detection like this will help analysts by giving the compilation of attacker activity around execution stage helping reduce MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond).

Examples of the Fusion detection for ransomware

In the Incident 1example, Fusion correlates alerts triggered within a short timeframe on the same device, indicating a possible chain of attacks from how the attackers got in through possible RDP brute-force attack, followed by the use of a ‘Cryptor’ malware and potential phishing activities using malicious document associated with the EUROPIUM activity group, to the detection of Petya and WannaCrypt ransomware in the network.

Incident 1

Incident 2below is another example of the Fusion ransomware detection that was confirmed as true positive. This incident correlates alerts showing ransomware activities at defense evasion and execution stages on the same host, along with additional suspicious activities detected during the same timeframe to show you possible techniques used by attackers to compromise the host.

Incident 2

In these Fusion incidents, the alerts related to ransomware/malware detection might indicate that the ransomware/malware was stopped from delivering its payload but it is prudent to check the machine for signs of infection. Attackers may continue malicious activities after ransomware was prevented – it is also important that you investigate the entire network to understand the intrusion and identify other machines that might be impacted by this attack.

What’s next after receiving the Fusion detection?

After receiving Fusion detentions for possible ransomware activities, we recommend you to check with the machine owner if this is intended behavior. If the activity is unexpected, treat the machine as potentially compromised and take immediate actions to analyze different techniques used by attackers to compromise the host and to evade detection in this potential ransomware attack. Here are the recommended steps:

1. Isolate the machine from the network to prevent potential lateral movement.
2. Run a full antimalware scan on the machine, following any resulting remediation advice.
3. Review installed / running software on the machine, removing any unknown or unwanted packages.
4. Revert the machine to a known good state, reinstalling operating system only if required and restoring software from a verified malware-free source.
5. Resolve to recommendations from alert providers (e.g. Azure Security Center and Microsoft Defender) to prevent future breaches.
6. Investigate the entire network to understand the intrusion and identify other machines that might be impacted by this attack.

As you investigate and close the Fusion incidents, we encourage you to provide feedback on whether this incident was a True Positive, Benign Positive, or a False Positive, along with details in the comments. Your feedback is critical to help Microsoft deliver the highest quality detections!