I for the life of me cannot figure out why my Playbook is visible in the Defender portal under Sentinel Automation, but I am unable to use it in any automation rules. Based on the documentation url listed under the grayed out Playbook, I have added the permissions for the service principal. The workspace lives in the same subscription under a different resource group than the Teams notification Playbook I am trying to configure. Has anyone ran into this issue before? I am new to Sentinel in general so I did not get to experience the old location in Azure as it now redirects to the Defender portal. It also seems like most of Microsoft’s current documentation refers to the “old” way of configuring playbooks in Azure.

A context graph is described as a persistent layer linking telemetry with organizational knowledge, asset ownership, tickets, prior investigations, so an AI system can interpret alerts without querying raw logs from scratch every time. If that's how it works, could a mature context graph reduce how much raw historical data you actually need retained in an expensive SIEM tier, since the graph already holds the relevant relationships rather than requiring a fresh query across raw logs? Or does the graph just sit on top of the SIEM without changing the underlying retention need at all.

Herkese merhaba

Geçtiğimiz birkaç ay boyunca, düzenlenmiş Kubernetes ortamlarında tekrar eden bir sorunu çözmek için çalışıyoruz: tedarik zinciri onayları, kabul politikaları ve denetime hazır uyumluluk raporlaması arasındaki boşluğu, operasyonel verileri harici SaaS satıcılarına aktarmadan kapatmak.

Kesinlikle küme içinde çalışan ve görüntü geçişinden kurcalamaya dayanıklı uyumluluk kanıtlarına kadar tüm yaşam döngüsünü işleyen, kendi kendine barındırılan bir mekanizma istedik. İşte üzerinde karar kıldığımız mimari ve yaklaşım:

* **Giriş ve Tedarik Zinciri Geçidi:** Bölmenin yürütülmesinden önce Cosign imzaları, SLSA kaynağı ve SBOM kontrolleri yoluyla politikaya dayalı kabulün uygulanması. Sadece CVSS puanlarını engellemek yerine CISA KEV eşleştirmeyi ve temel görüntü EOL tespitini dahil ettik. * **OpenVEX Kullanımı:** Yalnızca güvenilir imzalayanların bulguları otomatik olarak reddedebilmesini sağlamak için tedarikçi OpenVEX onaylarını kriptografik olarak doğrulamak. * **Kuru Çalıştırma ve Acil Durum Baypasları:** Cam kırma senaryoları için zorunlu kayıt işleminin yanı sıra, politika etkisini önizlemek için geçmiş dağıtım kararlarına karşı ne olursa olsun analizi eklendi. * **Kriptografik Kanıt Paketleme:** Denetimler için ham CSV'leri veya JSON'ları dışa aktarmak yerine, kanıt paketleri (PDF'ler ve SOC 2, ISO 27001, NIS2 ve CRA gibi çerçevelerle eşlenen yapılandırılmış raporlar) bir DSSE zarfı içinde imzalanır. Denetçiler, küme erişimine ihtiyaç duymadan kümenin genel anahtarı aracılığıyla orijinalliği doğrulayabilir. * **Çalışma Zamanı Eşlemesi:** Falco çalışma zamanı uyarılarını kabul politikası kararlarına ve ilk görüntü meta verilerine geri bağlamak. * **Kesin Gizlilik:** Sıfır telemetri veya tarama sonucu sızıntısı—her şey küme kontrol düzlemi içinde kalır.

Sıkı uyumluluk veya hava boşluklu iş yükleri kullananlar için: şu anda dış denetçiler için kurcalamaya dayanıklı kanıt toplama işlemini nasıl gerçekleştiriyorsunuz ve kırılma camı iş akışınız politikanın uygulanması açısından nasıl görünüyor?

I have over 4 years of SOC Analyst experience using Azure Security tools. I want to move into Engineering. Using a free tier azure account I practiced an Automation where i enriched an IP with VirusTotal API, sent the incident details with a revoke session button in an email using gmail connector in logic apps . I want to learn few more Automations to explain in the interview. Any Automation ideas that can be practiced using the free tier are appreciated.

I'm interested in how people actually create realistic cloud activity when learning and testing things like cloud detections, SIEM rules, incident investigations, or security tooling.

For example, if you wanted to test whether your security monitoring could detect something happening in Azure, how would you create the activity?

Would you:

• Perform everything manually?
• Use scripts/APIs?
• Use attack simulation frameworks?
• Use Terraform or another IaC approach?
• Build dedicated test environments?
• Replay existing telemetry?
• Use intentionally vulnerable labs?
• Something else?

What happens after the initial setup?

How do you keep the environment producing realistic activity rather than becoming a static environment that nobody touches?

What is the most annoying part of this process today?

I'm trying to understand the real-world workflow rather than looking for tool recommendations.

Hi everyone!

Curious if this is allowed - if not - please delete!

I’m partnering with a reputable consulting firm on a search for a long-term Microsoft Sentinel Architect for a 9–12 month transformation engagement. This is a fully remote, 40-hour-per-week role open only to candidates located in the US. We’re looking for someone with enterprise-scale experience across Microsoft Sentinel and SIEM solutions, who can build out analytics rules, detections, and investigation workflows, drive security analytics initiatives, integrate Sentinel with Microsoft Defender and other security platforms, and support broader SOC modernization efforts.

Please DM me privately!

Good evening folks, we’re scratching our heads a little bit and hoping the community can help ease some concerns!

We have a long-standing Sentinel deployment in Azure (pre-Defender native) and are seeing mass ingestion failure in the attached Log Analytics workspace. All services are in UK South region.

This appears to be affecting all log sources to a varying extent, including Microsoft-native connectors and logs forwarded from our on-premises syslog forwarders.

Bulk of issues appear to have started from between 12:00-13:00 UTC today, with sporadic ingestion spikes around 15:00 UTC and 19:00 UTC.

Not seeing any associated service disruption in our tenant, which I’d have expected to have if this were a widespread issue. We do have some correlation with an alert received from a third-party SOC we engage with for one of our clients, relating to missed heartbeats, which is naturally leading us to think it’s an issue beyond our deployment.

Anybody else seeing issues in their LAW(s)?

As of August 1, 2026, Microsoft Threat Intelligence APIs in Microsoft Graph are available to customers with Microsoft Defender XDR and/or Microsoft Sentinel licensing. No separate Microsoft Defender Threat Intelligence API license is required.

This means we can bring Microsoft Threat Intelligence directly into SOC investigation and response workflows instead of keeping threat intelligence as something analysts only consume manually in the portal.

The available playbooks cover enrichment scenarios such as:
🔹 Automated triage
🔹 IP/domain reputation enrichment
🔹 Passive DNS
🔹 Reverse DNS
🔹 Web components
🔹 Trackers
🔹 Cookies

The playbooks use Microsoft Graph to query threat intelligence data and can authenticate using Managed Identity with the ThreatIntelligence.Read.All application permission.

https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Microsoft%20Defender%20Threat%20Intelligence/Playbooks/readme.md

Docs: https://learn.microsoft.com/en-us/graph/api/resources/security-threatintelligence-overview?view=graph-rest-1.0

I'm hoping someone here can explain this to me. I'm coming from a Splunk background and have recently deployed Sentinel/MDO alongside it (not ideal, but it's a long story). I can't wrap my head around how Sentinel deals with time. The general "TimeGenerated" field that appears across all data sources appears to be the time of log *ingestion*, not log creation. In other words, a user sign-in event might say it happened at 17:09:16, but *actually* happened at 17:07:37, and was ingested two minutes later. In my line of work (cybersecurity) milliseconds matter and the discrepancy is killing me. Some logs (e.g. signin) have fields like "CreatedDateTime", but that field isn't standardized across all log sources so it makes it very difficult to use.

This seems like a gaping design flaw to me, but maybe I'm missing something?

Hi,

I am having an issue with creating a new automation playbook for enriching incidents via a kql query.

It looks like there is no longer a "Run query and list results" and "Run query and list results (V2), just a "Run query and list results) which if I look at the code is actually the V2 one.

I am pretty sure I solved this issue before by using the non V2 action.

I have put in my kql query which is hopefully right.

Used dynamic content for the other boxes

Incident workspace subscription id, incident workspace resource group name, Log Analytics Workspace drop-down, incident workspace workspace name.

Now I have the Time Range Type and when I press the drop-down the only option is enter custom value. In my other playbook I then enter "Set in query" and pressed tab. This now adds another drop-down for "time range" and I have tried putting things in there with no success like PT24H.

Flow:

MS sentinel incident trigger

Entites - Get Accounts (dc - Entities)

For each (dc - Accounts)

Compose 1

Compose Time Anchor (f - if(empty(outputs('compose_1')?['ApprovalTime']),triggerbody()?['object']?['properties']?['lastActicityTimeUtc'],first(outputs('compose_1')?['ApprovalTime']))

Run query and list results

Create html table (f - body('Run_query_and_list_results')?['value']

Add comment to incident V3 (f - concat('Entra sign-in check for ', items('For_each')?['Name'])

Thanks

Anyone else running into an issue when writing KQL where tab to complete doesn't work in Log Analytics Query space? For the last couple of weeks pressing tab will move out of the KQL window rather than completing the field I'm typing. I also can't use the tab key to type an actual tab character and it's driving me insane. This is only happening in my work Sentinel, my own personal lab isn't having this issue but I can't think of anywhere this would be configured.

If so, can you share a high level explanation of how you “normalized” the logs? I had v2 audit logs flowing without much issue, but the optional fields are killing me.

We aren’t using the new API as it’s worthless without filtering capabilities b/c of the insane volume in the audit logs (more like debug logs tbh). We use a pipeline to filter out categories that aren’t security related, then export the dataset to Azure blob storage. Azure Data Factory (ADF) takes it from there and does some minor ETL before sending to a DCE via API.

The issue I’m running into is the “optional” fields in the audit logs that make it hard to define a schema. For example, one log will have the “origin” and “origins” fields, and another will just have the “origins” field. I can likely account for this w/ schema drift in ADF, but the transformation in the Sentinel DCR will fail at ingestion.

It’s incredibly frustrating and these are the worst audit logs I’ve ever had to work with. Any insight into how others are handling this is appreciated!

Can anyone share feedback who have done this previously?