Microsoft Defender ATP Azure Sentinel Connector omits lot of important Alert information
Hi It is sad to see Microsoft defender ATP Connector at Azure Sentinel does not get all the required alert information as compared to Graph API. Details like User information, IP Information, Threat Category & Threat Family are omitted. Building any custom playbook to get these data is additionally charged although ingestion of Microsoft data is free. Connector needs improvement. Thanks
Understand New Sentinel Pricing Model with Sentinel Data Lake Tier
Introduction on Sentinel and its New Pricing Model Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform that collects, analyzes, and correlates security data from across your environment to detect threats and automate response. Traditionally, Sentinel stored all ingested data in the Analytics tier (Log Analytics workspace), which is powerful but expensive for high-volume logs. To reduce cost and enable customers to retain all security data without compromise, Microsoft introduced a new dual-tier pricing model consisting of the Analytics tier and the Data Lake tier. The Analytics tier continues to support fast, real-time querying and analytics for core security scenarios, while the new Data Lake tier provides very low-cost storage for long-term retention and high-volume datasets. Customers can now choose where each data type lands—analytics for high-value detections and investigations, and data lake for large or archival types—allowing organizations to significantly lower cost while still retaining all their security data for analytics, compliance, and hunting. Please flow diagram depicts new sentinel pricing model: Now let's understand this new pricing model with below scenarios: Scenario 1A (PAY GO) Scenario 1B (Usage Commitment) Scenario 2 (Data Lake Tier Only) Scenario 1A (PAY GO) Requirement Suppose you need to ingest 10 GB of data per day, and you must retain that data for 2 years. However, you will only frequently use, query, and analyze the data for the first 6 months. Solution To optimize cost, you can ingest the data into the Analytics tier and retain it there for the first 6 months, where active querying and investigation happen. After that period, the remaining 18 months of retention can be shifted to the Data Lake tier, which provides low-cost storage for compliance and auditing needs. But you will be charged separately for data lake tier querying and analytics which depicted as Compute (D) in pricing flow diagram. Pricing Flow / Notes The first 10 GB/day ingested into the Analytics tier is free for 31 days under the Analytics logs plan. All data ingested into the Analytics tier is automatically mirrored to the Data Lake tier at no additional ingestion or retention cost. For the first 6 months, you pay only for Analytics tier ingestion and retention, excluding any free capacity. For the next 18 months, you pay only for Data Lake tier retention, which is significantly cheaper. Azure Pricing Calculator Equivalent Assuming no data is queried or analyzed during the 18-month Data Lake tier retention period: Although the Analytics tier retention is set to 6 months, the first 3 months of retention fall under the free retention limit, so retention charges apply only for the remaining 3 months of the analytics retention window. Azure pricing calculator will adjust accordingly. Scenario 1B (Usage Commitment) Now, suppose you are ingesting 100 GB per day. If you follow the same pay-as-you-go pricing model described above, your estimated cost would be approximately $15,204 per month. However, you can reduce this cost by choosing a Commitment Tier, where Analytics tier ingestion is billed at a discounted rate. Note that the discount applies only to Analytics tier ingestion—it does not apply to Analytics tier retention costs or to any Data Lake tier–related charges. Please refer to the pricing flow and the equivalent pricing calculator results shown below. Monthly cost savings: $15,204 – $11,184 = $4,020 per month Now the question is: What happens if your usage reaches 150 GB per day? Will the additional 50 GB be billed at the Pay-As-You-Go rate? No. The entire 150 GB/day will still be billed at the discounted rate associated with the 100 GB/day commitment tier bucket. Azure Pricing Calculator Equivalent (100 GB/ Day) Azure Pricing Calculator Equivalent (150 GB/ Day) Scenario 2 (Data Lake Tier Only) Requirement Suppose you need to store certain audit or compliance logs amounting to 10 GB per day. These logs are not used for querying, analytics, or investigations on a regular basis, but must be retained for 2 years as per your organization’s compliance or forensic policies. Solution Since these logs are not actively analyzed, you should avoid ingesting them into the Analytics tier, which is more expensive and optimized for active querying. Instead, send them directly to the Data Lake tier, where they can be retained cost-effectively for future audit, compliance, or forensic needs. Pricing Flow Because the data is ingested directly into the Data Lake tier, you pay both ingestion and retention costs there for the entire 2-year period. If, at any point in the future, you need to perform advanced analytics, querying, or search, you will incur additional compute charges, based on actual usage. Even with occasional compute charges, the cost remains significantly lower than storing the same data in the Analytics tier. Realized Savings Scenario Cost per Month Scenario 1: 10 GB/day in Analytics tier $1,520.40 Scenario 2: 10 GB/day directly into Data Lake tier $202.20 (without compute) $257.20 (with sample compute price) Savings with no compute activity: $1,520.40 – $202.20 = $1,318.20 per month Savings with some compute activity (sample value): $1,520.40 – $257.20 = $1,263.20 per month Azure calculator equivalent without compute Azure calculator equivalent with Sample Compute Conclusion The combination of the Analytics tier and the Data Lake tier in Microsoft Sentinel enables organizations to optimize cost based on how their security data is used. High-value logs that require frequent querying, real-time analytics, and investigation can be stored in the Analytics tier, which provides powerful search performance and built-in detection capabilities. At the same time, large-volume or infrequently accessed logs—such as audit, compliance, or long-term retention data—can be directed to the Data Lake tier, which offers dramatically lower storage and ingestion costs. Because all Analytics tier data is automatically mirrored to the Data Lake tier at no extra cost, customers can use the Analytics tier only for the period they actively query data, and rely on the Data Lake tier for the remaining retention. This tiered model allows different scenarios—active investigation, archival storage, compliance retention, or large-scale telemetry ingestion—to be handled at the most cost-effective layer, ultimately delivering substantial savings without sacrificing visibility, retention, or future analytical capabilities.Local IPs ( 10.60.0.0/24 ) in ClientIP field in OfficeActivity logs?
Started seeing this more often recently and it started to cause some uptick in alerts across multiple customers (we are an MSP). It seems to me like a backend workflow is failing to write true source IPs to OfficeActivity logs, resulting in some 10.60.0.0/24 IPs being recorded as the ClientIP. Could this be some backend IP belonging to a Microsoft services? This can't be related to the customer since we see the same thing across up to 37 tenants/customers. This includes FileDownloaded operations which is what caused alerts and brought the issue to our attention. To make sure this also wasn't some kind of correlation to device, I checked the logs further and it's happening where IsManagedDevice == false and even anonymous file access. Is anyone else seeing this and can anyone from Microsoft confirm whether this is a mistake or bug somewhere upstream? Sample KQL: // Query 1 OfficeActivity | where TimeGenerated >=ago(30d) | where ipv4_is_private( ClientIP ) | where IsManagedDevice == false | summarize min(TimeGenerated), max(TimeGenerated), Operations=make_set(Operation), NumberUsers=dcount(UserId), make_set(UserId), UserAgents=make_set(UserAgent) by ClientIP // Query 2 OfficeActivity | where TimeGenerated >=ago(60d) | where isnotempty( ClientIP ) and ipv4_is_private( ClientIP ) | summarize count() by bin(TimeGenerated, 1d)
IIS Logs for Data Collection Rules - No x-forwarded-for
Hi, I use IIS logs in AMA to collect webserver logs in Sentinel. This rule do not collect the field x-forwarded-for and I need this. I read on github that the MS team is working on adding support for the extensions fields but not sure when it happens. Any of you solved this and how?
ASIM built-in functions in Sentinel, are they updated automatically?
Are the ASIM built-in functions in Sentinel automatically updated? For example, the built-in parsers such for DNS, NetworkSession, and WebSession. Do the built-in ones receive automatic updates or will the workspace-deployed versions of these parsers be the most up-to-date? And if true, would it be recommended to use workspace-deployed version of parsers that already come built-in?
Sentinel Data Connector: Google Workspace (G Suite) (using Azure Functions)
I'm encountering a problem when attempting to run the GWorkspace_Report workbook in Azure Sentinel. The query is throwing this error related to the union operator: 'union' operator: Failed to resolve table expression named 'GWorkspace_ReportsAPI_gcp_CL' I've double-checked, and the GoogleWorkspaceReports connector is installed and updated to version 3.0.2. Has anyone seen this or know what might be causing the table GWorkspace_ReportsAPI_gcp_CL to be unresolved? Thanks!
Single Rule for No logs receiving (Global + Per-device Thresholds)
Hi everyone, I currently maintain one Analytics rule per table to detect when logs stop coming in. Some tables receive data from multiple sources, each with a different expected interval (for example, some sources send every 10 minutes, others every 30 minutes). In other SIEM platforms there’s usually: A global threshold (e.g., 60 minutes) for all sources. Optional per-device/per-table thresholds that override the global value. Is there a recommended way to implement one global rule that uses a default threshold but allows per-source overrides when a particular device or log table has a different expected frequency? Also, if there are other approaches you use to manage “logs not received” detection, I’d love to hear your suggestions as well. This is a sample of my current rule let threshold = 1h; AzureActivity | summarize LastHeartBeat = max(TimeGenerated) | where LastHeartBeat < ago(threshold)I have no Microsoft Office 365 logs.
First of all, thanks in advance. In one tenant, I've configured Sentinel with several data sources, but the Microsoft 365 connector isn't logging events. I've done this about 20 times for different clients. The connector appears connected. I disconnected the connector and deleted the resource from the content center. Of course, I've waited; it's been a month since I did it the first time. I've tried checking Exchante, Teams, etc., to test combinations. I don't know if you know of any way to troubleshoot, see why the logs aren't arriving? Do I need to do something in Microsoft 365? Auditing is enabled, because when I go to Purview, audit, I can search for logs. I can't think of anything else. Thanks!!!
Trend Micro Vision One Connector Not working
Hi All, Before I get nuked in the comments to raise an issue on the Sentinel Repo. Here me out 😇 Around a month ago, the logs stopped ingesting. A quick snoop around revealed the reason. But I'm not sure if I should raise an issue, or try to fix the issue, risking voiding any future support I can get, since the connector and the app that comes with it are market solutions. Function app was not running due to a dependency issue. Spotted this on the diagnostic logs, under the "exceptions" table. "module named _cffi_backend not found" a python package google tells me, thats used to interact with C code. So logically, I need to find the requirement.txt and make sure the dependency is there. Also make sure the python version on the runtime and Azure matches, The logs were initially flowing as usual . I had completed integrating Trend Micro using Azure Functions based connector around 7 months ago. Worked like a toyota helix until now. So once again, would like to know the community's thoughts on it. Thxx
