Finance: a single investigation view for a Data & AI platform with Microsoft Sentinel

A bank ran a lakehouse in Microsoft Fabric with a handful of agents in Microsoft Foundry on top of it. Security itself was in order: Defender for Cloud was on, Purview classified, and Entra watched the sign-ins. The problem was that every signal lived in its own console. When a suspicious export happened on a Sunday evening, the analyst on duty had to put four screens side by side and reconstruct a timeline by hand, while the regulator expects a substantiated account within 72 hours.

The underlying layers keep doing what they are good at. Defender for Cloud covers the posture and the workloads of the platform, Defender XDR correlates the signals around endpoints, identities and mail into incidents, Purview supplies the classification and the DLP events, and Entra the sign-ins and service principals.

Microsoft Sentinel sits on top as the place where those streams meet. XDR incidents arrive through the Defender XDR connector, the diagnostic logs of the data services and the Azure activity logs go in directly, and the Purview audit connects the data layer. On top of that sit analytics rules for detections that only exist on a data platform: an export running outside its window, an agent registration suddenly asking for broader Graph permissions, a key used from an unexpected place. Workbooks provide the view for supervisory reporting, automation rules handle the first triage.

Defender XDR already correlates the Microsoft signals among themselves well, but the logs of the data platform itself do not land there. Sentinel is the only place where "a person" and "a dataset" end up on the same timeline, and that is exactly the question a regulator asks: who touched which data, when, and what happened next.

Leaving the four consoles in place was free and worked during office hours, but fell over at the moment it mattered. The existing SIEM of the network team could have taken the role, but then every Microsoft connector would have had to be rebuilt and the native incident correlation of XDR would be lost. Using XDR alone was considered and dropped on two points: the retention period is too short for an investigation that looks back months, and the platform logs do not fit in it.

• Ingest cost is a design choice here and not a billing detail: sending everything to the analytics tier is unaffordable, so the split across analytics, auxiliary and archive belongs in the design.
• Two incident queues (XDR and Sentinel) need a single owner, otherwise the same incident is worked twice and the third time by nobody.
• Detections for AI workloads are young. There is no mature rule library yet, so the first months are calibration rather than delivery.

Microsoft Sentinel (analytics rules, workbooks, automation rules), Microsoft Defender XDR, Microsoft Defender for Cloud, Microsoft Purview, Microsoft Entra ID, Microsoft Fabric.

• Turn on diagnostic logging before you write a detection; a rule about data you do not keep never fires, and you find that out during the investigation.
• Give every signal one owner, SOC or platform team, and record it with the rule. An alert without an owner is not an alert.
• Derive the retention period per log type from the supervisory requirement and not from convenience, because you cannot retrieve what you did not keep.

The most valuable rules of the first quarter were not the exotic AI attack scenarios but the boring ones: an export job running outside its window, a service principal with a new secret, a role left in place after a reorganisation. The first monthly bill also came in higher than budgeted because a verbose diagnostic category was on by default; since then the log split is part of the design decision and not of the delivery.