Introducing Microsoft Sentinel graph (Public Preview)
Security is being reengineered for the AI era—moving beyond static, rulebound controls and after-the-fact response toward platform-led, machine-speed defense. The challenge is clear: fragmented tools, sprawling signals, and legacy architectures that can’t match the velocity and scale of modern attacks. What’s needed is an AI-ready, data-first foundation—one that turns telemetry into a security graph, standardizes access for agents, and coordinates autonomous actions while keeping humans in command of strategy and high-impact investigations. Security teams already center operations on their SIEM for end-to-end visibility, and we’re advancing that foundation by evolving Microsoft Sentinel into both the SIEM and the platform for agentic defense—connecting analytics and context across ecosystems. And today, we announced the general availability of Sentinel data lake and introduced new preview platform capabilities that are built on Sentinel data lake (Figure 1), so protection accelerates to machine speed while analysts do their best work. We are excited to announce the public preview of Microsoft Sentinel graph, a deeply connected map of your digital estate across endpoints, cloud, email, identity, SaaS apps, and enriched with our threat intelligence. Sentinel graph, a core capability of the Sentinel platform, enables Defenders and Agentic AI to connect the dots and bring deep context quickly, enabling modern defense across pre-breach and post-breach. Starting today, we are delivering new graph-based analytics and interactive visualization capabilities across Microsoft Defender and Microsoft Purview. Attackers think in graphs. For a long time, defenders have been limited to querying and analyzing data in lists forcing them to think in silos. With Sentinel graph, Defenders and AI can quickly reveal relationships, traversable digital paths to understand blast radius, privilege escalation, and anomalies across large, cloud-scale data sets, deriving deep contextual insight across their digital estate, SOC teams and their AI Agents can stay proactive and resilient. With Sentinel graph-powered experiences in Defender and Purview, defenders can now reason over assets, identities, activities, and threat intelligence to accelerate detection, hunting, investigation, and response. Incident graph in Defender. The incident graph in the Microsoft Defender portal is now enriched with ability to analyze blast radius of the active attack. During an incident investigation, the blast radius analysis quickly evaluates and visualizes the vulnerable paths an attacker could take from a compromise entity to a critical asset. This allows SOC teams to effectively prioritize and focus their attack mitigation and response saving critical time and limiting impact. Hunting graph in Defender. Threat hunting often requires connecting disparate pieces of data to uncover hidden paths that attackers exploit to reach your crown jewels. With the new hunting graph, analysts can visually traverse the complex web of relationships between users, devices, and other entities to reveal privileged access paths to critical assets. This graph-powered exploration transforms threat hunting into a proactive mission, enabling SOC teams to surface vulnerabilities and intercept attacks before they gain momentum. This approach shifts security operations from reactive alert handling to proactive threat hunting, enabling teams to identify vulnerabilities and stop attacks before they escalate. Data risk graph in Purview Insider Risk Management (IRM). Investigating data leaks and insider risks is challenging when information is scattered across multiple sources. The data risk graph in IRM offers a unified view across SharePoint and OneDrive, connecting users, assets, and activities. Investigators can see not just what data was leaked, but also the full blast radius of risky user activity. This context helps data security teams triage alerts, understand the impact of incidents, and take targeted actions to prevent future leaks. Data risk graph in Purview Data Security Investigation (DSI). To truly understand a data breach, you need to follow the trail—tracking files and their activities across every tool and source. The data risk graph does this by automatically combining unified audit logs, Entra audit logs, and threat intelligence, providing an invaluable insight. With the power of the data risk graph, data security teams can pinpoint sensitive data access and movement, map potential exfiltration paths, and visualize the users and activities linked to risky files, all in one view. Getting started Microsoft Defender If you already have the Sentinel data lake, the required graph will be auto provisioned when you login into the Defender portal; hunting graph and incident graph experience will appear in the Defender portal. New to data lake? Use the Sentinel data lake onboarding flow to provision the data lake and graph. Microsoft Purview Follow the Sentinel data lake onboarding flow to provision the data lake and graph. In Purview Insider Risk Management (IRM), follow the instructions here. In Purview Data Security Investigation (DSI), follow the instructions here. Reference links Watch Microsoft Secure Microsoft Secure news blog Data lake blog MCP server blog ISV blog Security Store blog Copilot blog Microsoft Sentinel—AI-Powered Cloud SIEM | Microsoft Security
need to create monitoring queries to track the health status of data connectors
I'm working with Microsoft Sentinel and need to create monitoring queries to track the health status of data connectors. Specifically, I want to: Identify unhealthy or disconnected data connectors, Determine when a data connector last lost connection Get historical connection status information What I'm looking for: A KQL query that can be run in the Sentinel workspace to check connector status OR a PowerShell script/command that can retrieve this information Ideally, something that can be automated for regular monitoring Looking at the SentinelHealth table, but unsure about the exact schema,connector, etc Checking if there are specific tables that track connector status changes Using Azure Resource Graph or management APIs Ive Tried multiple approaches (KQL, PowerShell, Resource Graph) however I somehow cannot get the information I'm looking to obtain. Please assist with this, for example i see this microsoft docs page, https://learn.microsoft.com/en-us/azure/sentinel/monitor-data-connector-health#supported-data-connectors however I would like my query to state data such as - Last ingestion of tables? How much data has been ingested by specific tables and connectors? What connectors are currently connected? The health of my connectors? Please helpManaging Multi-Tenant Azure/365: Workarounds for Cross-Tenant Limitations in Purview and Fabric
I am working in a Microsoft Azure/365 multi-tenant setting due to some constraints. I am using Purview (Tenant1) and Fabric (Tenant2), M365 in (Tenant 2). I'm facing issues with various solutions due to cross tenant limitation for eg: Data Quality Connection, Metadata ingestion, lineage, etc. To overcome this I am exploring various workarounds. Key Question: 1. Are there proven workarounds or solutions to manage data estate in this scenario? (Can't merge /migrate tenants)Trusted Signing Public Preview Update
Nearly a year ago we announced the Public Preview of Trusted Signing with availability for organizations with 3 years or more of verifiable history to onboard to the service to get a fully managed code signing experience to simplify the efforts for Windows app developers. Over the past year, we’ve announced new features including the Preview support for Individual Developers, and we highlighted how the service contributes to the Windows Security story at Microsoft BUILD 2024 in the Unleash Windows App Security & Reputation with Trusted Signing session. During the Public Preview, we have obtained valuable insights on the service features from our customers, and insights into the developer experience as well as experience for Windows users. As we incorporate this feedback and learning into our General Availability (GA) release, we are limiting new customer subscriptions as part of the public preview. This approach will allow us to focus on refining the service based on the feedback and data collected during the preview phase. The limit in new customer subscriptions for Trusted Signing will take effect Wednesday, April 2, 2025, and make the service only available to US and Canada-based organizations with 3 years or more of verifiable history. Onboarding for individual developers and all other organizations will not be directly available for the remainder of the preview, and we look forward to expanding the service availability as we approach GA. Note that this announcement does not impact any existing subscribers of Trusted Signing, and the service will continue to be available for these subscribers as it has been throughout the Public Preview. For additional information about Trusted Signing please refer to Trusted Signing documentation | Microsoft Learn and Trusted Signing FAQ | Microsoft Learn.
Ingesting Akamai Audit Logs into Microsoft Sentinel using Azure Function Apps
Introduction Akamai provides extensive audit logs that can be valuable for security monitoring and compliance. To integrate Akamai Audit logs with Microsoft Sentinel, we can use Azure Function Apps to retrieve logs via the Akamai EdgeGrid API and send them to Log Analytics Workspace. In this guide, we will walk through deploying an Azure Function App that fetches Akamai Audit Logs and ingests them into Microsoft Sentinel. Prerequisites Before starting, ensure you have: An active Azure subscription with Microsoft Sentinel enabled. Akamai API credentials (EdgeGrid authentication: client_token, client_secret, and access_token). A Log Analytics Workspace (LAW) where logs will be ingested. Azure Function App deployed via VS Code. Python installed locally (Use the VSCode for the local deployment). High-Level Architecture Azure Function App calls Akamai API to fetch audit logs. Logs are parsed and sent to Microsoft Sentinel via Log Analytics API request to Azure Function App. Scheduled Execution ensures logs are fetched periodically. Step 1: Create an Azure Function App To deploy an Azure Function App via VS Code: Install the Azure Functions extension for VS Code. Install Azure Core Tools: npm install -g azure-functions-core-tools@4 --unsafe-perm true Create a Python-based Function App: func init AkamaiLogsFunction --python cd AkamaiLogsFunction func new --name FetchAkamaiLogs --template "HTTP trigger" --authlevel "anonymous" Step 2: Install Required Python Packages In your Function App directory, install the required dependencies: pip install requests akamai.edgegrid pip freeze > requirements.txt Step 3: Configure Environment Variables Instead of hardcoding API credentials, store them in Azure Function App settings: Go to Azure Portal > Function App. Navigate to Configuration > Application settings. Add the following environment variables: AKAMAI_CLIENT_TOKEN AKAMAI_CLIENT_SECRET AKAMAI_ACCESS_TOKEN WORKSPACE_ID (Log Analytics Workspace ID) SHARED_KEY (Log Analytics Shared Key) Step 4: Implement the Azure Function Code Create AkamaiLogFetcher.py with the following code: import azure.functions as func import logging import requests from akamai.edgegrid import EdgeGridAuth from urllib.parse import urljoin import os app = func.FunctionApp() # Azure Function HTTP Trigger @app.function_name(name="AkamaiLogFetcher") @app.route(route="fetchlogs", auth_level=func.AuthLevel.ANONYMOUS) def fetch_logs(req: func.HttpRequest) -> func.HttpResponse: logging.info("Processing Akamai log fetch request...") # Akamai API credentials (move these to Azure App Settings for security) baseurl = 'https://YOURBASEHOSTURL.luna.akamaiapis.net/' client_token = os.getenv("AKAMAI_CLIENT_TOKEN", "xxxxxxxxxxxxxx") client_secret = os.getenv("AKAMAI_CLIENT_SECRET", "xxxxxxxxxxxxx") access_token = os.getenv("AKAMAI_ACCESS_TOKEN", "xxxxxxxxxxxxxx") # Initialize session with authentication session = requests.Session() session.auth = EdgeGridAuth( client_token=client_token, client_secret=client_secret, access_token=access_token ) try: # Call Akamai API response = session.get(urljoin(baseurl, '/events/v3/events')) response.raise_for_status() # Raise an error for HTTP errors # Return response as JSON return func.HttpResponse(response.text, mimetype="application/json", status_code=response.status_code) except requests.exceptions.RequestException as e: logging.error(f"Error fetching logs: {e}") return func.HttpResponse(f"Failed to fetch logs: {str(e)}", status_code=500) Step 5: Deploy the Function to Azure Run the following command to deploy the function: func azure functionapp publish <YourFunctionAppName> Step 6: Setting Up the Logic App Workflow Create a new Logic App in Azure: Navigate to the Azure Portal -> Logic Apps -> Create. Choose Consumption Plan and select your preferred region. Click Review + Create, then Create. Add an HTTP Trigger: Select Recurrence as the trigger. Configure it to run every 10 minutes. Configure the HTTP Action to Fetch Logs from Akamai Function App API: Use the HTTP action in Logic Apps. Set the method to GET. Enter the Function App URL. Add the required headers (content type). Parse the JSON Response: Use the "Parse JSON" action to structure the response. Define the schema using a sample response from Akamai Audit Logs. Send Logs to Microsoft Sentinel: Use the "Azure Log Analytics - Send Data" action. Map the Akamai Audit log fields to the Log Analytics schema. Select the appropriate Custom Table in Log Analytics or use CommonSecurityLog. JSON Request body for Send Logs trigger Completed Logic App will look like this: Step 7: Testing and Validation Run a test execution of the Logic App. Check the Logic Apps run history to ensure successful Function App calls and data ingestion. Verify logs in Sentinel: Navigate to Microsoft Sentinel -> Logs. Run a KQL query: RadwareEvents_CL | where TimeGenerated > ago(10m) Summary This guide demonstrated how to use Azure Function Apps and Logic Apps to fetch Akamai Audit Logs via API and send them to Microsoft Sentinel. The serverless approach ensures efficient log collection without requiring dedicated infrastructure.👉 Microsoft Entra in Action: From Conditional Access to Identity Protection
One of the areas I’m most passionate about is identity-driven security. Microsoft Entra makes it possible to apply Zero Trust principles directly at the identity layer. ⚡ Conditional Access – the backbone of modern access policies. 👤 Privileged Identity Management (PIM) – ensuring just-in-time, least privilege for admins. 🛡️ Identity Protection – risk-based policies to stop compromised sign-ins in real time. In my labs, I’ve seen how these features transform security posture without adding friction for users. Coming soon: - Step-by-step breakdown of a risky user detection scenario. - A visual guide to Conditional Access controls for critical apps. Would love to exchange insights with others experimenting in this space — what Entra features are you finding most impactful? #MicrosoftEntra | #ConditionalAccess | #IdentityProtection | #MicrosoftLearn | #PerparimLabsPhishing Triage Agent in Defender XDR: Say Goodbye to False Positives and Analyst Fatigue
Phishing remains one of the most common and dangerous attack vectors in cybersecurity. With the rise of user-reported suspicious emails, Security Operations Center (SOC) teams are overwhelmed by the volume and complexity of triage. Enter the Phishing Triage Agent, a new capability within Microsoft Defender XDR and Security Copilot that uses AI to automate phishing classification, reduce false positives, and accelerate incident response. Image from Microsoft Learn - Microsoft Security Copilot Agents What’s the Issue? SOC analysts regularly handle a high volume of suspicious email reports, dedicating substantial time to reviewing each submission, though many prove to be non-threatening. More than 90% of cyberattacks originate from phishing, making it a primary method used to breach organizational defenses. This results in numerous alerts and potential incidents that must be triaged, prioritized, and investigated. Traditional rule-based systems, which were once effective for detecting known threats, now face challenges as attackers adapt their tactics and techniques. The continually changing threat landscape requires defenders to address not only advanced phishing attempts but also alert fatigue and the possibility of missing significant incidents. In this context, scalable and efficient solutions are important for enabling defenders to focus on investigating and mitigating real threats rather than addressing false positives. Image from Microsoft Learn - Type view for the Mailflow status report Why It’s Urgent Phishing is a very popular entry point for attackers, with such attacks growing more frequent and advanced, leaving SOC teams struggling with incident management. The Phishing Triage Agent uses LLMs and state of the art Threat Intelligence to quickly analyze and categorize reported emails, helping analysts focus on real threats. Integrating easily with current workflows, it offers adaptive, AI-driven insights for rapid threat detection and improved situational awareness. Through ongoing learning, it stays aligned with evolving attacker tactics and helps strengthen email security. Image from Microsoft Learn - Defender for Office 365 Phishing block Use Cases Automated Triage: Classify phishing emails without manual rules. False Positive Filtering: Reduce noise and analyst fatigue. Explainable AI: Provide clear reasoning behind verdicts. Threat Prioritization: Focus on high-risk incidents with enriched context. Compliance Auditing: Maintain logs and transparency for regulatory needs. Image from Microsoft Learn – Incident Queue with Phishing Triage Agent How It Works The agent activates when a user reports a suspicious email and does the following: Analyzes the message using LLMs. Classifies it as normal email or phishing. Enriches the incident with threat intelligence. Provides a verdict with natural-language explanation. Escalates or resolves based on severity and confidence. Image was created with AI It integrates with Security Copilot, enabling AI-assisted investigations and automation across Microsoft Defender XDR. Image from Microsoft Learn - Transparency and explainability in phishing triage Pros and Cons This section outlines the main advantages, limitations, and licensing requirements of the Phishing Triage Agent solution. Pros Cons License Needed Scales phishing triage across the enterprise Requires SCU provisioning and Defender licensing Microsoft Defender for Office 365 Plan 2 Reduces false positives and analyst fatigue Currently in preview; may evolve Security Copilot subscription Provides explainable decisions Requires integration with Defender XDR SCUs and plugin configuration The Phishing Triage Agent is a game-changer for SOC teams. By combining AI-powered analysis with human oversight, it accelerates detection, sharpens response, and strengthens organizational security posture. As phishing tactics evolve, this agent ensures your defenses stay ahead. Getting Started with Phishing Triage Agent The Phishing Triage Agent in Microsoft Defender XDR and Security Copilot helps SOC teams automate and accelerate phishing email analysis. Here’s how to get started: Check Prerequisites Ensure your organization has the necessary licenses: Microsoft Defender for Office 365 Plan 2 Security Copilot subscription Security Compute Units (SCUs) provisioned Defender XDR integration enabled Microsoft Defender for Office 365 service description License options for Microsoft 365 Copilot Enable Phishing Triage Agent Go to the Microsoft Defender portal: Settings > Email & Collaboration > Policies & Rules Enable the Phishing Triage Agent under Automated Investigation & Response (AIR). Automated investigation and response examples - Microsoft Defender for Office 365 Integrate with Security Copilot In the Security Copilot interface: Add the Phishing Triage Agent as a plugin Configure it to trigger when users report suspicious emails via Outlook or Defender for Office 365 Use plugins in Microsoft Security Copilot Test the Workflow Simulate a phishing report by submitting a suspicious email. The agent will: Use LLMs to analyze the message Classify it as phishing or safe Enriching the incident with threat intelligence Provide a natural-language explanation Escalate or resolve based on severity Security Copilot Phishing Triage Agent in Microsoft Defender Review and Tune Use the Mailflow status report and Incident Queue to monitor: Classification accuracy False positives Analyst workload reduction Mail flow insights in the new EAC in Exchange Online Prioritize incidents in the Microsoft Defender portal Train Your SOC Team Share explainable AI outputs with analysts to build trust Use the agent’s verdicts to guide manual investigations and reinforce learning Security Copilot Phishing Triage Agent in Microsoft Defender (Preview) Iterate and Improve Review phishing trends Update triage policies Leverage Security Copilot’s adaptive learning to stay ahead of evolving threats What is Microsoft Security Copilot? About the Author: Greetings! Jacques “Jack” here. I am excited to share this remarkable technology with our Defender community, as it has the potential to greatly enhance organizational protection. My role as a Microsoft Technical Trainer has shown me how valuable solutions like Security Copilot and Security AI Agents can be in strengthening defenses and accelerating response to threats. By sharing these advancements, I hope to empower you with the tools needed to safeguard your environment in an ever-evolving security landscape. #MicrosoftLearn #SkilledByMTT
Log Ingestion Delay in all Data connectors
Hi, I have integrated multiple log sources in sentinel and all the log sources are ingesting logs between 7:00 pm to 2:00 am I want the log ingestion in real time. I have integrated Azure WAF, syslog, Fortinet, Windows servers. For evidence I am attaching a screenshots. I am totally clueless if anyone can help I will be very thankful!
