Minimum Viable Configuration for Microsoft Sentinel

mvc-sent

What is the the Minimum Viable Configuration (MVC) for Microsoft Sentinel aimed at protecting a small business (SMB), the setup steps, and the estimated costs.

Understanding the Goal of an MVC for Sentinel in an SMB Context

The goal isn’t to catch every sophisticated nation-state attack, but to provide fundamental visibility and detection for common threats targeting SMBs, such as:

  1. Compromised Credentials: Detecting suspicious sign-ins, impossible travel, etc.

  2. Malware/Ransomware: Leveraging endpoint protection alerts.

  3. Phishing & Email Threats: Monitoring Office 365 activity.

  4. Basic Cloud Misconfigurations/Anomalies: Using built-in cloud security alerts.

The MVC focuses on leveraging the security signals already generated by the Microsoft ecosystem (assuming the SMB uses Microsoft 365 and Azure AD).

Minimum Viable Configuration (MVC) Components

  1. Azure Subscription: The foundation for all Azure services.

  2. Log Analytics Workspace: The data repository where Sentinel stores and analyzes logs. Configured for Pay-As-You-Go pricing initially.

  3. Microsoft Sentinel Instance: Enabled on top of the Log Analytics Workspace.

  4. Core Data Connectors (Focus on Free/Included Tiers First):
    • Azure Active Directory (Entra ID):
      • Sign-in Logs (Requires Azure AD P1 or P2 license) – Crucial for credential compromise detection.
      • Audit Logs (Free) – Tracks admin activity.

      • Azure AD Identity Protection Alerts (Requires Azure AD P2 license) – High-fidelity alerts for risky users/sign-ins. If P2 isn’t available, rely more heavily on Sign-in log analytics.
    • Microsoft 365 Defender (Recommended if licensed): This single connector can ingest alerts from:

      • Microsoft Defender for Endpoint (if using MDE Plan 1/2 or Defender for Business)

      • Microsoft Defender for Office 365 (if using Plan 1/2)

      • Microsoft Defender for Identity (less common in pure SMB cloud setups)

      • Microsoft Defender for Cloud Apps

      • Benefit: Ingesting Alerts via this connector is often free.
    • Office 365 (Alternative/Supplement to M365 Defender):
      • Exchange Online & SharePoint Online audit logs (Standard Audit is generally free to ingest). Essential for tracking file access, mail rule changes, etc.
    • Azure Activity Log (Free): Tracks subscription-level events (creating VMs, changing settings). Important for basic Azure infrastructure security hygiene.
  5. Essential Analytics Rules (Start with Templates):
    • Enable built-in Microsoft Security templates related to the connected data sources. Focus on:

      • Suspicious Azure AD Sign-in activity (Impossible travel, unfamiliar locations, logins from known malicious IPs).

      • Anomalous Office 365 activity (e.g., mass file downloads/deletions, suspicious inbox rule creation).

      • Alerts forwarded from Microsoft Defender products (e.g., Malware detected, phishing email reported).

      • Basic Azure activity anomalies (e.g., unusual resource creation/deletion).
  6. Incident Management: Rely on the built-in Sentinel Incident queue for manual review and investigation.

What’s NOT in this MVC (to keep it minimal):

  • Third-Party Data: No logs from non-Microsoft firewalls, servers, or applications initially.

  • Advanced Analytics: No custom rules, machine learning models (beyond built-in ones), or complex threat intelligence feeds initially.

  • SOAR/Automation: No automated response playbooks initially. Response is manual review and action.

  • Extensive Workbooks/Dashboards: Rely on default views.

  • Long Data Retention: Stick to the default or included retention (often 90 days free with Sentinel).

Setup Steps

  • Prerequisites:

    • An Azure Subscription.

    • Appropriate Permissions: Contributor or Owner on the Azure subscription/resource group; Global Administrator or Security Administrator role in Azure AD/Microsoft 365 to authorize connectors.

    • Relevant Licenses: Microsoft 365 Business Premium (includes Defender for Business, Azure AD P1), M365 E3/E5, or standalone licenses (Azure AD P1/P2, Defender plans) are highly recommended for the data sources.
  • Step 1: Create a Log Analytics Workspace

    1. Log in to the Azure portal (portal.azure.com).

    2. Search for “Log Analytics workspaces” and click “Create”.

    3. Choose your Subscription and Resource Group (create a new one if needed, e.g., RG-Security).

    4. Provide a Name (e.g., LAW-CompanyName-Security).

    5. Select a Region (choose one geographically close or with specific compliance needs).

    6. Select the Pricing Tier: Start with Pay-as-you-go.

    7. Review and Create.
  • Step 2: Enable Microsoft Sentinel

    1. Search for “Microsoft Sentinel” in the Azure portal and select it.

    2. Click “Add” or “Create”.

    3. Select the Log Analytics Workspace you just created.

    4. Click “Add Microsoft Sentinel”. Deployment takes a few minutes.
  • Step 3: Configure Data Connectors

    1. Once Sentinel is deployed, navigate to your Sentinel workspace.

    2. Go to Configuration -> Data connectors.

    3. Find and configure the following connectors (prioritize based on your licenses):

      • Azure Active Directory: Connect Sign-in logs and Audit logs. Requires authorization. If you have Azure AD P2, also connect Azure AD Identity Protection.

      • Microsoft 365 Defender: If you have relevant Defender licenses, connect this. It streamlines alert ingestion. Requires authorization. Configure it to sync alerts. This is often the most cost-effective way to get Defender alerts.
      • Office 365: If not using the M365 Defender connector for O365 data, or if you want raw logs beyond alerts, connect this. Select Exchange and SharePoint. Requires authorization.

      • Azure Activity: Connect this. It’s straightforward and free.
    4. For each connector, open its page, click “Open connector page”, and follow the specific prerequisites and configuration steps (usually involves ticking boxes and granting permissions).
  • Step 4: Enable Analytics Rules

    1. In Sentinel, go to Configuration -> Analytics.

    2. Go to the Rule templates tab.

    3. Filter by Data Sources (e.g., Azure Active Directory, Office 365, Microsoft 365 Defender).

    4. Look for rules tagged Microsoft Security. These are often high-quality and maintained by Microsoft.

    5. Select relevant templates (e.g., “Sign-ins from IPs that attempt sign-ins to disabled accounts”, “Malware detection by Microsoft Defender Antivirus”, “Suspicious inbox manipulation rule”, “Impossible travel activity”).

    6. For each chosen template, click “Create rule”.

    7. Review the rule logic (you can accept defaults for MVC). Ensure it’s set to Enabled.

    8. Configure Automated response later; leave it empty for MVC.

    9. Create the rule. Start with 5-15 key rules covering identity, endpoint, and email threats.
  • Step 5: Monitor Incidents

    1. Regularly (daily is recommended) check the Threat management -> Incidents blade in Sentinel.

    2. Review new incidents, assign them, investigate the alerts and entities involved, and close them with appropriate classifications.

Expected Monthly Costs

This is highly variable, but let’s break it down:

  1. Log Analytics Ingestion:

    • Free Tier: Many security alerts ingested via the Microsoft 365 Defender connector and Azure Activity logs are free. Office 365 standard audit logs are also often free.

    • Paid Data: The primary cost driver will be paid data sources ingested. Azure AD Sign-in logs are a common paid source. The volume depends heavily on user count and activity.

    • Estimate: For a small business (e.g., 10-50 active users), ingesting only essential paid logs like Azure AD Sign-ins might result in 0.5 GB to 5 GB per month (this is a rough estimate). Some sources estimate ~1GB/month per 100 users for just sign-in logs, but activity varies hugely.

    • Cost: Log Analytics Pay-As-You-Go ingestion is roughly $2.76 per GB (price varies slightly by region, check current Azure pricing).
  2. Sentinel Analysis Cost (Pay-As-You-Go):

    • Sentinel charges for analyzing the data ingested into Log Analytics. The PAYG rate is often similar to the Log Analytics ingestion rate, around $2.46 per GB (check current pricing).

    • Important: Data sources that are free to ingest into Log Analytics (like M365 Defender alerts, Azure Activity) are typically also free to analyze in Sentinel. You only pay Sentinel analysis costs on the paid data ingested into Log Analytics.
  3. Log Analytics Retention:

    • The first 90 days of data retention are typically included free with Sentinel enabled.

    • Storing data beyond 90 days incurs a small storage cost (e.g., ~$0.12 per GB per month). For an MVC, sticking to 90 days is recommended.

Cost Summary Estimate for MVC:

  • Scenario 1: Strict MVC using mostly FREE alert sources: If you rely heavily on the free ingestion from the M365 Defender connector (for endpoint/email alerts), Azure Activity, and standard Office 365 audit logs, and don’t ingest Azure AD Sign-in logs (or have very low volume), your direct Sentinel/Log Analytics costs could be very low, potentially $0 – $20 per month.

  • Scenario 2: MVC including Azure AD Sign-in Logs: If you add Azure AD Sign-in logs (highly recommended for security), assuming 1-5 GB/month ingestion:

    • Log Analytics Ingestion: 1-5 GB * ~$2.76/GB = $2.76 – $13.80

    • Sentinel Analysis: 1-5 GB * ~$2.46/GB = $2.46 – $12.30

    • Total Estimated Direct Cost: Roughly $5 – $30 per month.

Crucial Caveats on Cost:

  • Licensing Costs: This estimate does not include the cost of Microsoft 365 licenses (e.g., Business Premium, E3, E5) or standalone Azure AD P1/P2 licenses required to generate the security signals in the first place. These are often the larger part of the overall security spend.

  • Data Volume Variance: Actual data volume can vary significantly based on user activity, configured logging levels, and enabled features.

  • Pricing Changes: Azure pricing can change. Always refer to the official Azure pricing calculator for the most current information.

  • Commitment Tiers: If data volume grows significantly (e.g., consistently over 100 GB/day, which is unlikely for this SMB MVC), Commitment Tiers for Sentinel and Log Analytics offer discounts but require upfront commitment.

In conclusion, a minimum viable Sentinel setup focusing on free alert ingestion and essential paid logs like Azure AD Sign-ins can be quite affordable for an SMB, likely falling in the $5 – $30 per month range for direct Azure consumption costs, plus the necessary Microsoft 365/Azure AD licensing costs. Remember that someone needs the time and basic knowledge to monitor the incidents generated.

A better KQL Query to report failed login by country

SigninLogs
| where ResultType != 0  // Non-successful sign-ins
| where TimeGenerated >= ago(30d)  // Last 30 days
| extend Country = tostring(LocationDetails.countryOrRegion)
| where Country != “AU”  // Exclude Australia
| summarize FailedLogins = count() by Country
| order by FailedLogins desc

The above is an improved version of a KQL query you can use to report on failed logins to Entra ID over the past 30 days. It also excludes a country (here Australia) if desired.

image

image

The country codes are here:

https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

Note: if you copy and paste directly from here you will probably have the change the “ when you paste into your own environment as the wrong “ gets taken across!

Distributed Password cracking attempts detected by Sentinel

image

Over the past couple of days I’ve inundated with failed logins from locations all around the world. You can see a partial list of the those IPs reported in Sentinel above.

image

But, for the first time I also found this alert had triggered an incident in Sentinel – Distributed Password cracking attempts in Microsoft Entra ID, as seen above.

Here is the list and locations so far:

IP Address Origin (Country) Potential Organization (if identifiable)
31.141.37.30 Russia Provider: Rostelecom
38.222.57.97 United States Comcast Cable Communications
190.99.43.237 Argentina Telecom Argentina
187.55.129.25 Brazil Vivo (Telefônica Brasil)
186.77.198.100 Brazil Oi S.A.
24.152.24.225 United States Cox Communications
102.212.239.10 Uganda Uganda Telecom
131.161.44.200 United States Microsoft Corporation
177.222.169.132 Brazil TIM Brasil
31.155.228.215 Romania UPC Romania
168.228.92.190 Brazil NET Virtua
186.235.247.106 Brazil Oi S.A.
177.124.90.249 Brazil Vivo (Telefônica Brasil)
189.84.180.196 Brazil Oi S.A.
190.89.30.3 Brazil Vivo (Telefônica Brasil)
201.77.175.53 Brazil Oi S.A.
206.0.9.157 United States Comcast Cable Communications
138.0.25.140 Brazil Oi S.A.
176.29.230.49 Ukraine Ukrtelecom
191.99.34.144 Brazil Claro Brasil
87.116.135.139 France Orange S.A.
170.82.15.6 Brazil Claro Brasil
84.54.71.37 Spain Telefónica
170.231.164.96 Brazil Oi S.A.
45.231.208.166 Mexico Megacable
190.14.176.31 Colombia ETB (Empresa de Telecomunicaciones de Bogotá)
85.106.118.20 Italy TIM (Telecom Italia)
191.189.9.96 Brazil Claro Brasil
152.249.19.25 Argentina Telecom Argentina
189.34.199.125 Brazil Vivo (Telefônica Brasil)
41.225.129.174 Nigeria MTN Nigeria
85.96.249.52 Italy Vodafone Italia
197.26.214.34 South Africa MTN South Africa
187.183.41.6 Brazil Claro Brasil
177.126.234.232 Brazil Vivo (Telefônica Brasil)
149.86.137.85 United States AT&T

Always nice to have Sentinel on the job letting me know what’s going on!

KQL Query to report failed login by country

If you are interested to see how many failed logins your Microsoft 365 environment has had in the past 30 days you can run the following KQL query in Sentinel:

SigninLogs
| where ResultType == 50126
| where TimeGenerated >= ago(30d)
| extend Country = tostring(LocationDetails[“countryOrRegion”])
| summarize FailedLoginsCount = count() by Country
| order by FailedLoginsCount desc

you can then make a slight change and get all the successful logins

SigninLogs
| where ResultType == 0
| where TimeGenerated >= ago(30d)
| extend Country = tostring(LocationDetails[“countryOrRegion”])
| summarize LoginsCount = count() by Country
| order by LoginsCount desc

In my case, I found that only around 1% of my total logins were failed logins and all of these came from countries outside Australia.

Here is also a visualisation of the location of failed logins by country

image

Note: if you copy and paste directly from here you will probably have the change the “ around countryorregion when you paste into your own environment as teh wrong “ gets taken across!

Connecting Defender EASM logs to Sentinel workspace

A very important security task is to ensure you are collecting all the logging data for your services and sending them to a central location for storage and analysis.

Here’s how you can send the logs from Defender EASM into Sentinel.

You’ll need to have already established both Sentinel and Defender EASM instances. Underneath Sentinel is a Log Analytics Workspace that is where all the logging data for Sentinel is accumulated. It is into this workspace that the Defender EASM logs will be sent.

image

Log in to the Azure portal and navigate to Defender EASM as shown above. Select the Data connections option from the menu on the left. From the window that appears on the right select Add connection under Log Analytics as shown.

image

A dialog will appear from the right hand side prompting you for further information as shown above.

Open a new browser tab and navigate to Sentinel.

image

Select the Settings option at the bottom of the menu on the left hand side as shown above. From the windows that appears on the right select Workspace settings as shown.

image

In the Log analytics workspace for Sentinel select the Agents option under Settings from the menu on the left as shown.

In the window that appears on the right you will find both the Workspace ID and an API key as shown. Both of these will be required back in the Defender EASM connectors page.

image

Return to the Defender EASM connectors page configuration and give this connection an appropriate Name. Enter the Workspace ID and Api key from the Sentinel Log Analytics page. Select All content and Daily for frequency.

Save these settings.

image

If everything is correct you should now see that the Log Analytics connexion now displays you settings under Connected as shown above.

The logs from Defender EASM will now start becoming available for you in Sentinel to use in things like KQL queries.

Time to enable more logging

Having logs enabled is a good thing because it allows you to track down information after the fact. This is especially handy when you are performing a security investigation. Here is some additional logging that I recommend you enable.

image

Start by navigating to:

https://entra.microsoft.com

You’ll need to login with an administrative account that has rights. Expand the menu on the left of the screen until you see Monitoring & health and shown above.

image

Under this option you will find the menu item Diagnostic settings as shown above, which you select. This will display your diagnostic settings on the right. Here you can see that I am currently sending logs to a Log Analytics workspace, which is linked to Microsoft Sentinel for analysis. If you aren’t already sending your logs to a Log Analytics workspace you can set one up via the Add diagnostic setting hyperlink. I will assume here you already have something set up.

image

Select the Edit settings hyperlink and under Edit settings column on the right, as shown above.

image

Scroll down the categories of logs listed and ensure they are all select so the logging data will be sent to Microsoft Sentinel via the Log Analytics workspace.

If you have already enabled this logging I suggest you go back in and check that all categories are selected as Microsoft has now added some additional items:

– EnrichedOffice365Auditlogs

– MicrosoftGraphActivityLogs

– RemoteNetworkHealthLogs

which I had to enable.

When you have completed your category selections press the Save button in the menu bar at the top of the window to update your preferences.

This now means that you’ll have even more data in your Sentinel environment to help keep you secure.

Using Sentinel to determine application usage

examinatyion using a magnifying glass

In recent article:

Block applications on Windows devices using Intune

I outlined how to prevent an application from running on a Windows device. It would be nice to know how many people are running this application prior to it being blocked (and even before). You can achieve this using Sentinel.

Many don’t appreciate

The extra value that Microsoft Defender provides

apart from security. In a nutshell, Defender for Endpoint sends signals from devices into the Microsoft cloud that something like Sentinel can take advantage of. This is something that can be taken advantage of to see application usage.

DeviceNetworkEvents
| where InitiatingProcessFileName contains “msedge.exe”
| project TimeGenerated, RemoteUrl, RemoteIP, DeviceName, InitiatingProcessAccountName
| summarize count() by bin(TimeGenerated,1day),DeviceName
| render columnchart

an example of this is the above KQL query, which when run provides an output like:

image

The result is basically a bar graph, over whatever time you specify, of how many times an application has been used. This is a great indicative way to get a feel for how often a device is running a particular application (here msedge.exe). The different bar colours show each particular device and each bar height represents the total usage of that application for one day.

The great thing is that you can further customize and enhance this query to suit your needs to product the output your require. You can then take that query and embed it into a Sentinel workbook so that it is available as part of a dashboard.

There is just so much that you can do and all it takes is becoming familiar with the tools Microsoft provides in your environment.


CIAOPS Business Dojo–December

pexels-oleg-magni-861233

In this month’s Business Dojo we take a look at create a security offering with Microsoft Sentinel. These are virtual events, hosted using Microsoft Teams, that will provide you with deep dive into a business topic from the Microsoft Cloud.

Costs:

Non CIAOPS Patrons = AU$99 inc GST

Date:

Wednesday December 22nd 0930 – 1100 Sydney AU time

If you are interested in attending please complete the expression of interest application here to be considered for the event:

https://bit.ly/patronbiz

and you’ll be sent more details.