Microsoft Defender XDR: Building Detection Beyond the Defaults

M365 FM - Microsoft Defender XDR - Building Detection Beyond the Defaults 00:00:00 Speaker: Defender XDR is deployed almost everywhere now. Most tenants have it switched on. Most licenses are paid for and most teams run it like a smarter antivirus. It blocks the known bad thing. It sends an email. Someone clicks through a queue. But in reality, that isn't detection. That's consumption. Because the model behind the defaults was built for the average customer, and the average customer doesn't exist. It's nobody's tenant, not yours. So today we're going to fix that. We'll look at how incident correlation really decides what belongs. Together. We'll write custom detections in Kql will tune noise with a method, add automation, bring in sentinel build response playbooks, and then measure whether any of it works. If you work in security, subscribe now. So the next detection engineering episode finds you. But before we get into the architecture, a quick word on who supports this show sponsor segment. Stellar Migrator for exchange security posture changes during a migration and most teams don't plan for that. When mailboxes move, the signals defender sees move with them, sign in patterns, shift mailbox permissions get rebuilt, forwarding rules and delegates show up in places they weren't before. Your detection logic reads all of that as behavior, so a messy move makes for messy signal. That's where stellar migrator for exchange fits. It's a tool for moving mailboxes within the Microsoft ecosystem, including between exchange environments and into Microsoft three hundred sixty five. The point is simple clean identity and clean mailbox state make detection logic cleaner. Fewer odd leftovers means fewer false positives later. That's all you need to know. There's a link in the description if you want to look closer. Now back to the core problem. What does default actually mean? The default detection assumption. Start with who the defaults are built for. They're built for the median tenant. Broad, safe, generic. Microsoft has to ship something that works for a ten person accounting firm, and for a bank with sixty thousand seats. So the logic has to be careful. It can't assume much about your business because it knows nothing about your business. Here's what you get out of the box. Built in alerts across endpoint identity, email and cloud apps, automated investigation and remediation, which looks at an alert and decides whether the evidence holds up and attack disruption, which can contain a user or a device while an attack is still running. That's real value. I'm not dismissing it, but look at what all three of them share. They react to patterns that are common across many customers. They are tuned to be right most of the time for most people, and they work best on attacks that look like the ones Microsoft has already seen. That's the part that matters because your risk doesn't look like everyone's risk. Think about what you actually protect. Maybe it's a finance mailbox that approves wire transfers. Maybe it's an admin account that touches production. Maybe it's a research share that would end the company if it leaked a generic detection doesn't know any of that. It treats every mailbox, every account and every server as roughly equal. And that assumption is broken. So what does it cost you? Two things. And they pull in opposite directions. First, silence where you need signal. The attack that targets your specific weak point doesn't match a template. So nothing fires. No alert, no incident, no ticket. Just a quiet log that nobody reads second noise where you don't need it. Broad rules fire on normal behavior in your environment because your normal isn't the median normal. Your IT team runs a script that looks like an attack. Your finance team logs in from three countries. The rule fires anyway over and over. Now put those two together. Analysts spend the day on alerts that mean nothing, and the one that matters doesn't exist yet. That's the flaw in the model. It isn't the product. It's the assumption that someone else's defaults can describe your risk. So this episode is a move from one model to another. The old model you consume alerts. Microsoft decides what's suspicious. You react. The new model, you engineer detections. You decide what matters in your tenant. You write the logic, you correlate it, you automate the response, and you measure the result. Same platform, different relationship to it. But to engineer anything, you need to see how the platform is actually built because you can't change what you can't see. So let's open it up. What defender XDR actually is architecturally, most people describe defender XDR as one product. It isn't. It's four products wearing one coat. Each one watches a different part of your environment. Defender for endpoint. Watches. Devices. Processes. Files. Network connections. Registry changes. Defender for identity watches, your domain controllers and your identity infrastructure. Defender for office three hundred sixty five watches, email and collaboration so mail flow teams SharePoint and defender for cloud apps. Watches what happens inside your SaaS apps and your cloud sessions for workloads, for sets of sensors, and all of them feed one portal. That portal is the Unified Defender portal at security, Microsoft dot com. It's where incidents, alerts, hunting, and response actions live side by side. And here's the part that's changing the shape of the whole thing. Sentinel is moving in. Microsoft has been pulling its Siem into the same portal, so the queue you work in doesn't care anymore whether an alert came from an endpoint sensor or from a firewall log. One place, one incident model will come back to Sentinel properly later. For now, just hold the direction in your head. The boundary between XDR and CM is getting thinner. Now a portal is a view. It isn't the architecture. To understand how the thing actually works, you need a flow model and I'll give you one that works well when you can't see a diagram. Three layers event reasoning orchestration. Layer one is the event layer. This is raw telemetry. A process starts. A user signs in an email, lands a file, gets shared externally. Every sensor in all four workloads writes down what happened with a timestamp and the entities involved. No opinion yet, just facts. Layer two is the reasoning layer. This is where something looks at those facts and decides what they mean. Detection logic fires, alerts get created, and then correlation takes those alerts and groups them into incidents. This layer turns a thing. Happened into a thing happened that matters. And here's what it connects to. Layer three is the orchestration layer. This is what you do about it. Automated investigation, attack disruption, playbooks, approvals, containment actions. It's the layer that acts, event reasoning, orchestration. Keep that order because everything in this episode maps onto it. Writing Kql detections lives in the reasoning layer. Tuning noise lives in the reasoning layer. Playbooks live in orchestration, and measuring quality means looking back across all three, but the layers need somewhere to share data. And that brings us to the part most teams never look at. Where do the signals actually live? They live in advanced hunting, specifically in the advanced hunting tables. Think of them as the shared data plane under the entire platform device process events holds process activity, identity logon events, holds sign ins, email events, holds mail Cloud app events. Holds what users do in your cloud apps, and there are tables for alerts and for incidents themselves. So the output of the reasoning layer becomes queryable data two. That matters more than it sounds. It means the same tables that an analyst uses to hunt are the tables your custom detections run against. There's no second hidden data store behind the scenes. If you can see it in advanced hunting, you can build logic on it. And if you can't see it there, your detection can't see it either. So the architecture hands you a very direct deal. Microsoft collects the events. You get read access to the same data plane Microsoft's own logic uses, and the gap between default and engineered is mostly the work you do on top of that shared layer. That's the structural opening. But before you write logic against those tables, you need to understand what happens to the alerts that logic produces. Because alerts don't stay alone for long. Something groups them, merges them, and decides which ones belong to the same story. That's correlation, and it's the most misunderstood part of the whole platform. Alerts are not incidents. Let's start with the definition. Because people use these two words like they mean the same thing. An alert is one observation. A sensor saw something, a rule matched, and the platform wrote it down a suspicious PowerShell command on one laptop, a sign in from a strange location. A mail message that got reclassified after delivery. An incident is a story. It's a set of observations that someone or something decided belong together. That difference sounds small, but it changes how you work. An alert answers what happened here? An incident answers what is the attacker doing? Those are very different questions. Attackers don't produce one event. They produce a chain, a phishing email, then a click, then a sign in, then a mailbox rule, then a file download. Each step is its own alert, often from its own workload. So defender does the grouping for you when alerts share things. We are the same device, the same user, the same mailbox, or the same file. The platform links them into one incident. You open one item instead of seven. You see the timeline, the affected assets, and the order of events. That's real work saved. It's why correlation exists at all. But look at what that grouping assumes. It assumes the overlap is the connection. If two alerts touch the same user, they probably belong to the same attack. If they don't share an entity, they probably don't. That's a reasonable guess. It's also just a guess, and it gets made automatically before any human has looked at the evidence. Most of the time it's fine. When it's wrong, it's wrong. Quietly, nobody sees the alert that should have joined the story but didn't. Nobody sees the unrelated alerts that got glued together by a shared server. Now, here's something that tells you how much trust teams really place in this grouping. Inside an incident, analysts still triage alerts one by one. Open an incident with twelve alerts. What happens? Someone clicks. The first alert, reads. It decides if it's real, clicks. The second reads. It decides the incident gave them a container, but the work inside it is still alert sized. Each one gets its own verdict, its own notes, its own classification. Why? Because the incident doesn't carry a verdict of its own. It's a folder. The meaning lives in the pieces, and the analyst has to rebuild the story by hand to decide whether the folder is a true, positive or noise. That's not a flaw in the analyst. It's a flaw in the model. The grouping saved clicks, but it didn't save judgment. And that brings us to a number. Leadership loves to track incident count. You'll see it on dashboards incidents this month down eighteen percent. It feels like progress, but incident count is a vanity metric. It tells you how many followers the platform created. It says nothing about whether those folders were right. Think about what can move that number. Fewer incidents might mean fewer attacks. It might also mean broader merging where five separate intrusions got packed into one. Or it might mean a rule got switched off and a whole class of activity went dark. The count dropped in all three cases, and only one of them is good. So the real measure is incident quality. Did the incident contain the whole attack? Did it leave out the unrelated noise? Did the analyst reach a verdict faster because the story was already assembled? Quality is harder to count, but it's the only version that tells you something true, and you can't improve quality if you don't know how. The grouping decides which entities count, how long the window runs, what happens at the edges. So that's where we go next inside the logic of correlation itself. How incident correlation really works. Correlation runs on shared entities. An entity is a thing. An alert is about a device, a user account, a mailbox, an IP address, a file hash. When two alerts point at the same entity, the platform treats that as a link and links pile up into an incident. Think of it as matching, not understanding. The engine doesn't read the alert and ask whether the story makes sense. It checks whether the alerts touch the same objects. A phishing alert names a mailbox. Assign an alert, names the same user. A malware alert names the laptop that user works on. Those three overlap, so they merge. Then there's time overlap alone isn't enough because the same laptop can show up in alerts months apart. So correlation also looks at how close the alerts are in time and at whether the sequence fits in attack. A click, then a sign in, then a process on the device all within hours reads as one chain. The same three events spread across a quarter don't. And this merging works across workloads. That's the whole point of XDR. The email alert came from one product. The identity alert came from another. The endpoint alert came from. A third correlation pulls them into one timeline. So you see the attack as the attacker lived it, not as each sensor saw it. Now the weak spots matching on shared entities fails in two directions. It joins things that shouldn't be joined and it misses things that should be. Start with over merging. Picture a service account that runs backup jobs on forty servers. Every alert on any of those servers, names that account. So an unrelated alert on server three and another on server thirty one, both point at the same user and the engine glues them together. Now you have one incident that looks like a wide campaign, and it's really two separate boring events. Jump hosts do the same thing. Every admin passes through them. So every admins activity shares a device and that addresses do it to hundreds of people. Leave your office from one public IP. So an alert tied to that address can link users who have never met. The result is a bloated incident. Analysts open it, see sixty alerts and can't tell which belong to the attack. So they either spend an hour untangling it or they close the whole thing under. Merging is the opposite problem, and it's sneakier. Consider an attacker who steals a password and signs in from a clean machine, one you don't manage. No device in your fleet ever touches the session. The identity alerts fire, but there's no endpoint event to connect them to. No shared device, no shared file hash. The only common entity is the user, and if the alerts name that user in slightly different ways, the link may never form. So the same intrusion sits in your queue as separate items. An identity alert here, a cloud app alert there. Each looks small. Nobody sees the chain because the one thing that would join them never appeared. Which brings up how you should read an incident once you have one. Most people treat the incident graph as a picture, a diagram with nodes and lines. They glance at it, nod, and go back to the alert list. Use it as a reasoning tool instead. Look at the lines and ask why each one exists. What entity connects this alert to that one? Is it a real link like the same compromised user or a shared object like that service account? Every edge in the graph is a claim the engine made. Your job is to check the claim and look at what's missing. If you know an attack should have touched a mailbox, a device, and a cloud session, and the graph only shows two of them. The third is a gap. The shape of the graph tells you where the engine ran out of evidence. That last point matters most. When correlation fails, it rarely fails because the matching logic is broken. It fails because the evidence the matching needs was never created. No alert, no entity, no entity, no link. So the gap in the incident is usually a gap in detection. Something happened, nothing fired. And the story has a hole in the middle. And that's where we need to look next at the places inside real tenants where those holes keep appearing, where correlation breaks inside. Real tenants start with the environment. Most of you actually run hybrid. Part of your identity still lives on premises. Domain controllers in a server room or in a data center. You inherited defender for identity watches them through a sensor, and that sensor feeds the same platform as everything else. But here's the problem. Those signals don't always arrive on time, and they don't always arrive whole. A sensor drops its connection. A domain controller sits behind a rule nobody documented. A new controller comes online and nobody installs the agent. So the cloud sign in shows up right away, and the on premises half of that same story shows up late or in pieces or never. Correlation depends on both halves existing at the same moment. When one half is missing, the link has nothing to hold on to and you won't see an error. You'll see a smaller incident than the attack deserved. Now add the products defender doesn't own. Almost every tenant has a few. A firewall from one vendor, a web proxy from another, a third party email gateway sitting in front of exchange, a cloud access tool that a different team bought two years ago. Each one produces alerts, and some of those alerts describe exactly the activity you care about, but defender doesn't link what it can't read. If those alerts never enter the platform, they never become entities. They stay in their own console, in their own queue, with their own naming. The attacker moved through your firewall and then into your mailbox. And no system on earth connected the two because they were never in the same place. So what does that cost you? First, the work gets done twice. Two analysts or the same analyst on two different days. Triage what is really one event. Each opens their own item, reads their own evidence and writes their own notes. Minutes pile up and none of it adds knowledge. Second and worse, the chain breaks. An attack that unfolds across identity mail and endpoint only looks like an attack. When you see all three steps together, split them apart and each piece looks like a low severity oddity. A medium alert here, an informational one there. Nobody escalates an oddity. Here's how that moment typically shows up. A user reports a strange email on Monday. That's ticket one from the mail workload. On Tuesday, a sign in from an unfamiliar country triggers an identity alert. That's ticket two and it lands with a different analyst. On Wednesday, a firewall from another vendor flags unusual outbound traffic from the finance subnet. Ticket three in a separate tool entirely. Three tickets three owners three closing notes that say no further action. But it was one intrusion. One person, one stolen session, three days of quiet movement. Each ticket was closed correctly based on what that analyst could see. And the sum of those correct decisions was a wrong one. That's the failure. It isn't carelessness. It's a structure that never gave anyone the full picture. So how do you fix a gap like that? You can't fix it by staring at the incident graph. The graph only shows what the platform already knows. The fix sits one layer down in the logic that decides what gets written as an alert, and what entities that alert carries, which means you need to speak the language that layer runs on the one underneath, hunting underneath custom detections underneath almost everything you can change. Kql Kql. As the detection language, most teams treat Kql as a hunting hobby. Someone on the team likes it. They write clever queries on a quiet afternoon, paste them into a shared note, and everyone else keeps clicking through the queue. That's a waste of what it is. KCL is the control surface. It's the one place where you decide what counts as suspicious in your tenant. Every custom detection is a query. Every hunting result is a query. Even the way you check whether correlation missed something is a query. If you can't write it, you're waiting for someone else to write it for you. So let's build the mental model. First, think of a table as an event stream. Rows keep arriving, each one a fact with a timestamp. A query is a hypothesis. You run against that stream. If an attacker did this, I'd see rows that look like that. You write the guess, run it, and the stream tells you whether you're right. That framing keeps you honest. A query isn't a search. It's a claim about attacker behavior that the data can confirm or kill. Now which streams exist? Five tables will carry most of what you build. Device process events holds process creation, what ran, what launched it, and with what command line device events is the white table for everything else on the device like registry changes, driver loads and security related actions. Identity logon events hold sign ins across your identity. Sources. Email. Events. Holds. Mail. Flow with sender, recipient and verdict. And cloud app events. Holds what people do inside your SaaS apps once they're in. Learn what each one records and which columns. Identify the user, the device, and the mailbox. That's the schema reading that matters. The column names tell you which entities your alert can attach to. And as we saw with correlation, entities are what link the story together. Now the pattern it has for moves and the order is the whole skill filter early. Cut the table down. Before you do anything else, set the time window. Name the action you care about. Every row you drop in the first lines is a row you never pay to process project narrow. Keep only the columns you need. A wide table carries dozens of fields and dragging them through the rest of the query slows everything down for no reason. Summarize count, group and measure. This is where a pile of events becomes a pattern like this account failed twelve times, then succeeded. Join last. Bring in a second table only when the first one is already small. A join on two huge sets is where queries go to die. Filter project. Summarize. Join When a query is slow or times out, the fix is almost always that one of those four got done out of order. And speaking of mistakes, three of them show up constantly. The first is the unbounded time range. A query with no time filter scans everything the table holds. It's slow, it's costly, and a detection built on it may simply fail to run. Always set a window and make it match the question. The second is the expensive join. Someone joins two large tables early before filtering either one and wonders why the portal hangs. Shrink both sides first, then join. The third is string matching on huge columns, searching the full command line of every process event for a word using a loose. Contains check forces the engine to read text. It didn't need to read match on a precise field. When you can narrow the rows first, then do the text search on what's left. Fix those three and most of your slow queries. Stop being slow. But here's the limit of everything we just covered. A good query sitting in a node is still just a note. It only finds something when a person remembers to run it. The attacker doesn't wait for your Thursday afternoon. A query becomes a detection when it runs on a schedule without you. 00:18:45 Speaker: From hunting query to detection rule, a detection has a life. It doesn't just appear, run forever and stay correct. It moves through stages. Hypothesis query validation. Rule tuning. Retirement. Start with the hypothesis. You write down what the attacker does in plain words. After a stolen sign in, they create an inbox rule that hides mail. That sentence comes first before any code. Then the query. You turn the guess into Kql and run it against real data. Then validation, which most teams skip. You check the results by hand. Do the rows match what you meant? How many are normal activity? If you can't explain every row, you're not ready. Only then does it become a rule. And after that comes tuning because the first version is never the last one. Finally, retirement, a rule that no longer earns its place gets removed on purpose, not by neglect. Hold that sequence. Most broken detections skip the stage and it was almost always validation. Now the mechanics inside defender. You build custom detection rules from the advanced hunting page. You write the query, run it, and choose to create a detection rule from it. The portal then asks how often the rule should run, and that choice matters more than it looks. You have two families of options scheduled and near real time scheduled. Rules run at a fixed interval every hour, every three hours, every twelve hours or once a day. They look back over a window of data, find matches, and raise alerts. They're flexible. They can handle heavier logic like a summarize with a join because they have time to chew on it near real time, which you'll see called continuous runs. As events stream in, alerts appear within moments, not hours. That speed is what you want for the things that can't wait. Like a mailbox rule created right after a risky sign in. But it comes with limits. The query has to stay simple. Only certain tables are supported and you can't lean on heavy aggregation. So the trade off is plain speed against complexity. Use near real time for high confidence single event signals use scheduled for patents that only show up when you count or compare over time. Next, the part that trips people up the output columns. A rule is a query, but the platform needs more than rows. It needs to know when the event happened and what it was about. So your query must return a timestamp column and it must return identifying columns for the entities involved a device ID, a user's account or object ID, a mailbox address, a file hash. Leave them out and the rule either refuses to save or saves and produces alerts that attach to nothing. Remember what we said about correlation entities are the links. An alert with no entity is an orphan. It can't join an incident, can't trigger a response on the right device, and can't tell an analyst who to call. That's also why a careless summarize breaks rules. When you aggregate, you throw away the columns you didn't group. By then, the entity fields vanish, so you have to carry them through, project them back or group by them on purpose. Always check the final lines of your query and ask one thing. If this fires, what does the alert point at then the metadata. This is what the analyst reads. At three in the morning you set a title and it should say what happened, not what the rule is called. Inbox rule hides mail after risky sign in beats rule forty seven. You set a severity which should reflect the damage. If it's real, not how clever the query is. You set a category so the alert lands in the right bucket like persistence or credential access, and you map it to a meta technique. That mapping isn't decoration, it's how you later measure coverage and how you see which parts of an attack you can't yet detect. Add a description with the next step for the analyst and the rule is ready to ship. But writing the rule is the easy part. A query can be perfect and still be pointless if it detects something nobody needed detected. So the harder question comes before any KCL. What deserves a rule at all? Choosing what to detect threat informed prioritization. Most teams answer that question the wrong way. They open the Mito attack matrix, see hundreds of techniques, and decide to cover them all. A spreadsheet appears, every cell gets a color and the project becomes fill in the grid. But the matrix describes what attackers do everywhere. It doesn't tell you what would hurt you. That's the flaw. It's a map of the world and you're trying to defend one house in it. So start somewhere else. Start with business risk. Ask a plain question. If an attacker got in tomorrow, what would they go after and what would that cost? Not in technical terms. In money. In downtime. In legal exposure, in headlines. The answer to that question is your detection strategy. The matrix comes later as a tool for checking your work. Now make the answer concrete for things to map first. The crown jewels, the systems and data that end the business if they leak or stop the payment platform, the customer database, the design files, write them down by name and note which devices and which cloud apps touch them. Second identity tears. Not every account is equal, and your detection logic shouldn't pretend they are. A tenant admin sits in a different class than a sales rep. So does the account that runs your sync service, sort accounts into tears, and decide that activity on the top tier gets a tighter rule and a faster response. Third, high value mailboxes. The finance lead who approves transfers. The executive assistant who sees every calendar. The legal inbox. Attackers know these business email compromise lives here, so your rules should too. Fourth privileged roles global admin exchange admin anyone who can create a rule grant consent or change a policy. Count them. Most tenants find more than they expected, and some of those accounts haven't signed in for a year. That list is short on purpose. An afternoon with the right people in a room can produce it. And once you have it, the rule candidates almost write themselves a new device signing into a tier zero account, a forwarding rule on the finance mailbox. A role assignment nobody requested, which raises the next tension coverage versus depth coverage. Says detect something for every technique. Depth says detect a few things well. And the honest answer is that depth wins early. Ten great detections beat one hundred generic ones. A great detection has a clear hypothesis. It carries entities. It was validated against real data. It has an owner who knows what a true positive looks like. One hundred generic rules copied from a blog and switched on in one weekend give you the opposite. Nobody knows why half of them exist. They fire on normal activity, analysts learn to ignore them. And now you've built noise, not coverage. So pick the ten that map to your crown jewels first. Make each one solid, then widen. Where do the next ten come from? You already have the source your own incident history. Every incident you've handled is a free lesson. Pull the last year for each real one. Ask three things. How did we find out? What did the attacker do before we noticed? And which step could a rule have caught earlier? That second question is the useful one because it points at the gap. If the intrusion ran for four days before someone spotted it, there were four days of behavior with no detection attached. Near misses count two. The phishing email a user reported the sign in and analyst flagged by hand. If a person caught it, a query probably could have. Now, one more lens. This one is for the people who fund the work. Treat your detection backlog as a risk register. Every idea for a rule is a line item. It names a risk, the asset behind it, the likelihood and the damage. Rank the list by what it protects, not by how interesting the query is. When an executive asks why you're spending three weeks on mailbox forwarding detection instead of something flashy, the answer is on the page. This protects the account that moves the money, and the register shows trade offs, what you're building, what you're deferring, what risk you're accepting by waiting. That's a conversation leadership understands because it's the same one they have about every other risk. So you've got the priorities crown, jewels, tears, mailboxes, rolls and a ranked backlog. Now build and the first family of detections to build because it's where most attacks begin is identity. Custom detections for identity attacks. Identity is where most intrusions start. Now, in a cloud first tenant, there's no network edge to break through. The perimeter is a sign in page. An attacker doesn't need malware or an exploit. If they can walk through that page with a valid password or better with a valid session. And once they're in, they look like a user. That's the problem. So identity detections are the first family to build, not because they're the most advanced, but because everything else mail files, endpoints usually follows from a stolen identity. Let's start with a pattern everyone knows and almost everyone gets wrong. Impossible travel. The basic version says a user signed in from two countries within an hour. So raise an alert. And in a real tenant that fires constantly, someone connects through a VPN. A phone roams onto a mobile carrier that routes through another country. A cloud proxy exits from a data center in another region. Analysts see it ten times a day and learn to wave it through. Done well, the logic changes. You exclude your known VPN and proxy ranges. You require the second sign in to come from a device or app the user has never used, and you raise the severity only when the account sits in a higher tier. Same idea. Three extra conditions and the alert starts meaning something. The second pattern is MFA fatigue. Here the attacker already has the password. They trigger sign in after sign in, and the user's phone buzzes with approval prompts. Then at some point, tired or confused, the user taps a proof so you look for the burst. Many failed or interrupted MFA attempts in a short window, followed by one success. Count the attempts per user group by a time bin and set a threshold that fits your tenant. The sequence is the signal one declined. Prompt is nothing. Fifteen in ten minutes and then an approval is an intrusion. The third pattern joins two weak signals into a strong one. A new device, plus a privileged action. A first time device. Sign in is normal. People get new laptops. A role assignment or a consent grant is normal to for admins. But both together from an account that never behaved that way within the same hour. That's worth waking someone for. This is where your identity tiers from the last section pay off. You apply the rule to the top tier only so the volume stays small and the confidence stays high. Now the harder case token theft. Here the attacker never needs the password or the MFA prompt. They steal a session token, often from a browser, on an infected machine or through a proxy phishing page. Then they replay it from the identity system's view. The sign in already happened, and it was legitimate, so the signal moves to what the session does afterward. You look in cloud app events for a session that suddenly changes the same session ID appearing from a new IP address and a new user agent. A user who normally reads mail starting to download files in bulk, or touching admin settings right after a location change. No single event proves theft. The shift in behavior inside one session does. That brings up false positives, and the best fix for them is context from another workload. An identity alert alone often can't tell you if something is wrong, but join it to the endpoint and the picture sharpens. Take the sign in event and ask whether the device behind it is managed, compliant, and known. A risky sign in from a device that defender for endpoint has never seen is far more interesting than the same sign in from a laptop that's been in your fleet for two years. So you write the join and you write it last after you've filtered both sides down. Identity events on one side, device inventory or recent endpoint alerts on the other matched on device ID or account alerts that survive the join. Carry more evidence and the ones that don't get dropped before an analyst ever sees them. And one last point, the one that decides whether any of this works. Entity mapping. When you finish the query, you choose which column holds the user, pick the wrong one and the alert attaches to the wrong object. Maybe it lands on a display name that matches three people. Maybe it uses a sign in name in one table and an object ID in another, so correlation never links them. Map to the stable identifier, the account object ID, and check that every table you join agrees on it. If the alert doesn't land on the right user, nothing downstream works. Not the incident, not the containment, not the playbook. So that's identity. Passwords, prompts, tokens, and the context around them. But identity isn't the only way. In. The other front door is the inbox. Custom detections for email and collaboration abuse. Once an attacker owns an identity, the mailbox is the first place they go not to read mail to change how mail behaves. The classic move is the inbox rule, a new rule that forwards every message to an outside address, or a rule that moves anything containing words like invoice or security alert into a folder nobody opens, or one that marks mail as read and deletes it. The attacker wants to see your conversations and they want you to stay blind to theirs. So you hunt in cloud app events for the rule creation actions. New inbox rule set inbox rule mailbox forwarding changes. Then you add the conditions that matter a forward to a domain outside your tenant. A rule with no name or a name that's a single character or just dots. A rule that targets a folder like RSS feeds or conversation history places where no human ever looks any one of those is odd. Two together on a high value mailbox is a near-certain intrusion. And watch the timing. A rule created within an hour of a risky sign in carries far more weight than one created on a quiet Tuesday. Near real time works well here because the attacker moves fast once the rule is in place. Now a different kind of signal, one that comes after the mail has already landed. Email filtering makes a call at delivery, clean or suspicious or blocked, but verdicts change. A link that looked harmless at nine o'clock gets weaponized at eleven o'clock. The platform later reclassifies the message and pulls it from inboxes, but only if it catches it. By then, someone may have clicked. So you look at the gap, join email events to URL, click events and ask which users clicked the link in a message whose verdict changed after delivery. That click happened in the window when everyone thought the mail was safe. Those users are your exposure. You alert on them and you check their sign ins for the next few hours. That's a detection nobody gets by default. It only exists because you asked the question. Collaboration is the next path and it's quieter still. Once inside, an attacker doesn't always stay in male teams and SharePoint hold files and files are what they're after, so you watch for external sharing spikes. A user who normally shares two documents a month suddenly shares forty with an outside address or anonymous links created in bulk or a single account, downloading hundreds of files from a document library in ten minutes. The pattern is a baseline and a burst. Count the actions per user per day. Compare today against the last thirty and flag the jump. Set the threshold from your own data, not from a blog post. A sales team downloads in bulk before a quarter ends, and a rule that ignores that will bury you. Now put it together because none of these exist alone. Business email compromise is a chain, a phished password at the identity layer, a forwarding rule at the mail layer, a mass download in the cloud app layer, and then the fake invoice sent from a real mailbox to a real customer. Each link on its own looks small. A sign in a rule. A download three alerts. Three workloads, three possible owners. This is exactly where the correlation gaps we covered earlier bite. So your detections should share an entity. The same user maps the same way so the platform has something to join on. Then the chain becomes one incident instead of three tickets. Built the rules as links, not as islands ask of each one what comes right before this and what comes right after that covers the front doors. Identity and mail. But the attacker often lands on a device in the end, and devices talk constantly. They produce the noisiest signals you have, and some of the most revealing custom detections for endpoint behavior. Most endpoint detection started with files a known bad hash, a known bad name, a signature that says this binary is malware. Block it and that still works for commodity threats. But a file is the easiest thing for an attacker to change. Recompile, repack, rename, and the hash is new, so the detection that matters moves from what the file is to what it does. That's behavior based thinking. You stop asking is this program bad? And start asking, is this sequence of actions normal here? The sharpest version of that is living off the land. The attacker brings nothing new. They use tools already on the machine. PowerShell cmd w s script Ms. Rundell thirty two Regsvr32 binaries signed by Microsoft. Trusted by default and present on every device you own. Security people call them LOL bins. A file scanner sees nothing wrong because nothing is wrong with the file. So the signal sits in the relationship between processes. Think about parent and child word. Opening a document is normal. Word launching PowerShell is not outlook. Spawning a script. Host a browser, starting CMD, a PDF reader calling Mshda. Each of those pairs has almost no legitimate reason to exist in device process events. You read the initiating process and the new process side by side, and you write the rule on the pair. Then look at the command line PowerShell with an encoded command, a hidden window, and a download string is a different animal than PowerShell. Running your admins inventory script search util. Fetching a file from the internet. Rundle thirty two. Loading a DLL from a user's temp folder. The tool is trusted. The way it's used isn't now persistence, because an attacker who wants to stay needs a way to survive a reboot. You watch the places windows runs things automatically run keys in the registry. Scheduled tasks created from a command line. New services pointing at odd paths. Start up folder drops in device registry events and device process events. You look for a. Write to one of those locations by a process that has no business writing there. A scheduled task created by a script host pointing at a file in a user profile is a good example. Admin tools create tasks. Admin tools don't usually run from AppData. Credential access follows the same logic. Access to the Lsass process by anything that isn't a known security tool registry. Hive exports of Sam or security. A tool dumping memory with a built in utility. Those are rare specific actions, and rare plus specific is the shape of a good rule. So you've got the behaviors. And now comes the part that decides whether these rules help or hurt. Endpoint rules need the most tuning of anything you'll build. Why? Because legitimate software does strange things all the time. An installer spawns a script host. A management agent runs encoded PowerShell because that's how it parses complex commands. A developer tool launches child processes from odd paths. Your own IT team writes scripts that look to a detection exactly like an attack. Every one of those is a true match on the logic and a false alarm in practice. So the work isn't writing the rule, it's shaping what the rule ignores. And here's where teams make a costly choice. They allow list by hash. A hash is exact. It also means the rule goes silent for that one file version and breaks the moment the vendor ships an update. So the list grows forever and someone is always chasing the latest build. There's a better anchor allowlist by signed publisher and by path together. This process signed by this vendor running from this folder may do this behavior. Publisher alone is too loose since a signed binary can be abused or copied elsewhere. Path alone is too loose too. Since attackers write into common folders, the combination is narrow enough to be safe and stable enough to survive and update. Keep the hash for the rare case that truly needs it, but step back and look at what you've just built. Parent child rules. Command line rules, persistence rules, credential rules. Each one is correct. Each one will also fire on something harmless in a tenant with thousands of devices running all day. That's a lot of alerts and volume has a way of becoming its own problem. 00:36:03 Speaker: A white noise is a structural problem. Let's start with a claim that might sound unfair to the people who live in the queue. Alert fatigue is not an analyst failing. It's a design outcome. Someone built a system that produces more alerts than a human can read, and then measured the humans on whether they read them. When a tired person skips the fortieth alert of the morning, that's the system doing exactly what it was configured to do. So stop asking why the team isn't more careful. Ask what the model produces and who decided it should. Here's a way to make that visible a cost model. And it's just multiplication. Take the minutes it takes to triage one alert. Multiply by the alerts that arrive each day. Multiply by the number of analysts who touch them. That's your daily cost in hours, and most teams have never calculated it. Run it with ordinary numbers six minutes per alert, three hundred alerts a day. That's thirty hours of work every day before anyone investigates anything real. And if sixty percent of those alerts are harmless, eighteen of those hours bought you nothing. Not nothing in theory, nothing as in the same answer every time. This is fine. Now put a price on it. Those hours come out of a salary budget, and they come out of the time you'd have spent building the next detection noise doesn't just waste effort, it eats the capacity you need to fix it, and that leads to the cost that matters most. The one you can't see on a dashboard. Noise hides real incidents. Think about what happens to attention when most alerts turn out to be nothing. People learn correctly that most alerts are nothing, so they get faster, they skim, they close on pattern instead of on evidence. That's a rational response to the data they've been given. And then the real one arrives. It looks like the others. Same format, same severity label, same title style. It sits in the queue between two false alarms and the analyst gives it the same four seconds. Nobody was lazy. The signal simply had no way to stand out from the pile it was buried in. That's the boy who cried wolf effect. And it's not a story about honesty. It's about base rates. When the false alarms outnumber the true ones, fifty to one attention gets spent accordingly. So where does the noise come from? Three places mostly. The first is broad rules. A detection written to catch every possible variant of a behavior will also catch every harmless version of it. PowerShell with a download string sounds precise. In a tenant with a software deployment tool, it fires all day. The rule did its job. The scope was the mistake. The second is unmanaged exclusions. Someone suppressed an alert last spring to get through a bad week. Nobody wrote down why or who approved it or when it should end. Now it's just there. Some exclusions are too wide and hide real activity. Others are too narrow. So a near identical alert still fires from the next device. Either way, nobody owns the decision. The third is noisy software management agents, backup tools, vulnerability scanners, and developer utilities. They do things that look like attacks because mechanically they are the same actions. A scanner that probes every device on the network looks a lot like reconnaissance. Nothing is wrong with the scanner. The detection just can't tell the difference without help. Notice what all three have in common. None of them is a mystery. Every source of noise has a cause. You can name and a place in the configuration where it lives, which means noise is fixable, but only if you stop treating it as weather. Most teams tune like they are reacting to a bad mood. An analyst complains. Someone adds an exclusion, the queue gets a little quieter and everyone moves on. No measurement, no record, no plan to check whether it worked or whether it quietly broke something else that isn't tuning. It's guessing with a delete button. Tuning needs a method, a disciplined tuning method. Start with numbers. Before you touch a single rule. Pull the data which alert sources produce the most volume and which of those have the worst false positive rate. Those are two different lists, and you need both. Volume tells you where the time goes. False positive rate tells you where the time is wasted, a rule that fires four hundred times a month and is right every time isn't a tuning problem, a rule that fires forty times and is wrong. Thirty eight of them is sort by both and look at the overlap. The rules near the top of each list are your first targets. You can get this from the incidents and alerts views in the portal filtered by detection, source and by classification. Or you can write a query against the alert tables and group by title. The analyst classifications are the key input here. Every time someone marks an alert as a false positive or a true positive, that's a data point. If your team skips the classification step, you have no baseline. So make that the first habit to fix. Now the rule of change one change, one hypothesis, one review date. That's the whole discipline. And it sounds almost too simple, but think about what happens without it. Someone adds three exclusions and edits a threshold. On the same afternoon, the Q drops by thirty percent. Great. Except which change did that? And did one of them also silence something real? You can't tell because you changed everything at once. So write it down before you act. I believe this alert fires on our deployment tool, and if I exclude that tool signed process from this one rule, volume drops by about a third with no loss of true positives. That's a hypothesis. It can be wrong. Then set a date two weeks out and check. Did volume fall? Did any true positive disappear? If yes to the second you roll it back? Now the tools defender gives you a few and they do different jobs. Alert tuning rules which you'll find under the alert tuning settings let you act on a pattern. You pick the alert type, define conditions on the entities involved, and then choose what happens. Hide the alert, resolve it automatically or mark it as informational. There. The right tool when a specific known good behavior keeps triggering one specific detection suppression is the blunter cousin. It quiets an alert so it stops creating work. Use it with care, because a suppressed alert often leaves less of a trail than one that's been resolved. Automatic resolution sits in between. The alert still gets created and recorded, but it closes itself with a reason attached that keeps a record. You can count how often it fired, and you can see if the pattern changes. When you can choose between hiding something and resolving it with a trace. Pick the trace. Whichever tool you use, the next rule matters more than the tool scope. Exclusions narrowly, an exclusion should name an entity and a condition. This device group. This signed publisher. This command line from this path never. The whole rule. Here's why excluding a whole rule doesn't fix the noise. It deletes the detection. You want it to silence one deployment tool, and instead you've told the platform to stop caring about that behavior everywhere. For every user, forever. The attacker doing the same thing on a different machine now walks past a rule that's technically still switched on. So ask the narrowing question every time. What is the smallest description of the harmless case? Write the exclusion to match that and nothing broader. If you can't describe the harmless case precisely, you don't understand the noise yet. And that's a reason to investigate more, not to exclude more then the part. Almost nobody does document every exclusion. Each one gets three things written next to it an owner. A named person who answers for it. A reason in a sentence a stranger could follow and an expiry date. Owner reason expiry. The owner matters because exclusions outlive the people who made them. The reason matters because six months later, no one remembers the bad week that caused it. And the expiry matters most because it forces a decision. When the date arrives, someone has to look at the exclusion and say still needed or remove it without a date. The default is silence, and silence means it stays. You can keep this in a simple register. A spreadsheet works. A list in your ticket system works. What doesn't work is a memory, because here's where this goes. If you skip that last step, an exclusion with no expiry doesn't stay a fix. It slowly turns into a place where the attacker can operate without being seen. And that's what we need to look at next. Exclusions, blind spots and tuning debt. Think about how an exclusion gets born. Someone is having a rough week. A rule fires on a deployment tool. Again, they add an exclusion, the queue calms down and they get on with their day. Reasonable. Nobody does anything wrong. But a year later that exclusion is still there. The person who wrote it has moved teams. The deployment tool was replaced in the autumn, and the exclusion now covers a folder path on a whole device group that anyone with local rights can write into. So an attacker drops a script into that folder. The rule that would have caught it is still switched on. It simply has a hole in it shaped exactly like your old convenience. That's how a permanent exclusion becomes an attacker path, not by one big mistake, by a pile of small, reasonable ones nobody ever revisited. And here's the uncomfortable part attackers look for. These folder exclusions are public in many setups, and a local admin can often read them off a machine. Your list of things we don't watch is useful to anyone who gets in, so you need a calendar, not a feeling. Once a quarter review, every suppression, every tuning rule, and every exception. All of them in one sitting for each one, ask three things. Is the owner still here? Does the original reason still hold and did anything in the environment change that makes it wider than it used to be? If you did the work from the last section, the register already has an expiry date on each entry. The review is then just a walk through the ones that came due. Keep it, extend it with a new date or delete it. No fourth option. Leave it. Nobody's complained isn't a decision. It's drift. Now one place deserves its own pass defender for endpoint exclusions. These are the settings that tell the platform to skip a file, a folder, a process, or an extension during scanning and monitoring. Treat that list as a risk inventory because that's what it is. Every line is a place where you've chosen to see less. Read it the way an attacker would. Which paths are writable by normal users? Which exclusions are wildcards? Is there a whole drive or a temp directory in there? Which ones exist for software you no longer run? Sort them by how much ground they cover, and the top of that list is where your real exposure sits. A single broad exclusion can outweigh fifty good detections. Pull the list into a spreadsheet, add the owner and the reason, and mark every line you can't explain. Those are your first removals. Which brings us to the idea that makes all this visible to people who don't live in the portal tuning debt. It works like any other debt. Every exclusion you add without an owner or an expiry is a small loan against your future visibility. It solves today's problem, and the interest shows up later as a blind spot. Leave enough of them and you're paying more than you can see, and you can count it. How many exclusions have no owner. How many have no expiry? How many are older than a year? How many cover a whole rule instead of an entity? Those four numbers tracked each quarter tell a leadership team something they already understand how much unreviewed risk the tenant is carrying and whether it's going up or down. A number leadership can read in 10s changes the conversation. We have forty one exceptions. Nobody owns gets a decision. We should tidy up our tuning, gets a nod and nothing else. Now a pattern to notice. Everything in this stretch has been about subtraction, cutting broad rules down, removing stale exclusions, writing narrow ones with owners attached and what's left once you've done that work is a queue where most of what appears is real. That's the condition you need before the next step, because a system that acts on its own is only as safe as the signals it acts on. Feed it noise, and it makes noisy mistakes at machine speed. Quiet the queue first, then automation becomes something you can trust. Automation Insight defender XDR defender already acts on its own before you write a single playbook, the platform is investigating alerts and fixing some of what it finds. It's called automated investigation and remediation. Think of it like a junior analyst who never sleeps. An alert fires on a device. The platform opens an investigation. It looks at the files, the processes, the persistence points, and the other devices that touched the same evidence. Then it reaches a verdict malicious, suspicious or no threats found. If something is malicious, it proposes actions. Quarantine the file. Stop the process, remove the registry key. Clear the scheduled task. What happens next depends on one. Setting the autonomy level, you choose that level per device group. It comes in a few steps at the low end. The platform investigates but takes no action. It tells you what it would do and a person decides in the middle. It handles some things on its own and asks approval for the rest. At the top, it remediates everything without asking, and a person reviews afterward. Those steps are not about intelligence. Every level runs the same investigation. They differ in a single question who presses the button now? A different kind of automation, one that doesn't wait for an investigation to finish attack disruption. This is built for the moment. An attack is already in motion. Say defender correlates signals across identity, endpoint, and mail. The combined picture matches a known pattern like ransomware staging or a hands on keyboard intrusion using a stolen account at that point. Minutes matter more than certainty, so the platform acts. It can contain a device cutting its network access except to defender itself. It can disable a user account so the stolen session stops working across the tenant. You didn't write that rule. Microsoft did. It only triggers on high confidence matches. That's the design. Disruption is narrow on purpose because the actions are painful when wrong. A contained laptop is a person who can't work. A disabled account might be your CFO. That tension is the real question. When should the machine act alone? Don't answer it with a feeling. Answer it by risk. Look at what the action costs if it's wrong, and what waiting costs. If it's right. A quarantined file on a standard workstation. Low cost to be wrong. Since you restore it in a click, that's a fair candidate for fully automated. A device that runs your production line or a domain controller being wrong there means an outage an analyst should approve first, so you tier IT standard user devices go to the higher autonomy setting servers and critical systems stay semi-automated where the platform proposes and a person confirms the newest or most uncertain device. Groups stay at the lowest level until you've watched how the platform behaves in your environment. That last point leads to the idea. Underneath all of it, a trust model automation should earn its scope. You don't hand a new system full authority. On day one. You start narrow and you look at the evidence, check the investigation results. How many verdicts were right? How many remediations did an analyst reverse? If the platform has been correct for sixty days on one device group, that's a reason to widen its authority there. If it keeps flagging your own management tool as malicious, that's a reason to fix the signal before giving it more power. Precision comes first. Scope follows, and this connects straight back to the work you just finished. A quiet tuned queue is what makes the numbers readable. In a noisy tenant, you can't tell whether automation is accurate because the inputs are already mixed. Clean the signals and the trust question becomes measurable instead of emotional. But notice what built in automation can and can't do. It acts on Microsoft's detections using Microsoft's logic in Microsoft's order. It knows nothing about your approval chain, your VIP list, or your ticketing system. It can't disable a user, notify a manager and open a case in your own tools. For that, you need something you control, not an autonomy setting. You need orchestration. Why? Sentinel joins the picture. Defender XDR knows Microsoft's signals better than anything else you own. It sees the process tree on the laptop. It sees the sign in the mailbox rule and the OAuth consent, and it joins them because Microsoft built both sides of the connection, that depth is real. No third party tool will match it inside this ecosystem, but depth has an edge. Defender can only reason about what flows into it. A lot of your environment never does. Think about what sits outside the firewall at the data center edge, the switches and wireless controllers, the VPN concentrator, the proxy that logs every outbound request, the line of business app that your finance team runs, and the SaaS tools that defender for cloud apps doesn't connect to. Then there are custom logs. The batch job that writes to a file, the legacy system that only speaks syslog, the on prem database that records who touched which row. None of that lands in advanced hunting. So when an attacker moves through that gap, defender sees half the story. A stolen account signs in through the VPN, hits an internal app, and pulls data out through a proxy defender catches the sign in. The rest happens in places it can't read. Your correlation, as we saw earlier, can only link what it can see. That's where Sentinel comes in. The shorthand is simple defender sees Microsoft deeply, Sentinel sees everything broadly. Sentinel is a CM and a cloud native one. It takes in logs from almost any source, stores them in a workspace, and lets you run the same query language across all of it. The firewall table and the sign in table sit side by side. A single query can follow one IP address from a network, log into an identity event and then into an endpoint alert. That's a question defender alone can't answer. Microsoft has been closing the distance between the two. The Unified Defender portal now carries Sentinel inside it. One Q one incident model. An analyst opens a single incident and sees alerts from defender workloads next to alerts from Sentinel rules grouped by the same correlation logic. No second console, no copy in case numbers between systems. That changes how people work. But it also raises a design question that the portal can't answer for you what belongs where. Here's a frame that holds up in practice keeping defender anything where the native depth is the whole point. Endpoint behavior, identity protection signals, email verdicts, cloud app activity from the connected apps. Those detections run closest to the data they use the richest telemetry they feed automated investigation and attack disruption. Directly moving them out would only weaken them. Route to Sentinel anything that needs breadth. Detections that join network logs to identity rules over third party data. Long retention for compliance. So you can look back eighteen months when someone asks about an old breach. Cross source hunting, where the answer lives in three systems at once, and a quick test for the gray area. Ask whether the detection needs data. Defender doesn't have. If yes, it belongs in Sentinel because it has to be. If no, ask whether it benefits from defenders built in response. If yes, keep it in defender. Notice what that frame does. It stops the argument about which tool is better. They're not competing. They cover different surfaces. The real work is deciding where each rule lives. But there's a catch, one that surprises people after the first invoice. Connecting the two isn't free. Every table you send to Sentinel costs money to ingest and store. Every duplicate alert costs analyst time. The choices you make in the first week, often by clicking enable all shape both bills for years. So the integration needs a design, not a checkbox. 00:52:24 Speaker: Designing the Defender and Sentinel integration. Start with how the connection behaves. It's more useful than most people expect. The defender XDR connector in Sentinel syncs incidents and alerts when defender creates an incident. It shows up on the Sentinel side with its alerts and entities attached, and the sync runs both ways. An analyst closes the incident in one place and the status updates in the other. Assign it, comment on it, change the severity and the change follows so you don't maintain two queues. You maintain one story told in two systems, but that connector only moves incidents. It doesn't move the raw data behind them. And that's the first real decision you can send just the incidents and alerts. Or you can also stream the raw tables, things like device process events, email events, and identity logon events into the Sentinel workspace. Incident only is cheap. You get the portal view, the automation hooks, and the cross system status. What you give up is hunting, advanced hunting, and defender keeps about thirty days of data. If the question is about something from five months ago, the telemetry is gone. Raw ingestion fixes that. You get long retention, and you can join defender tables to firewall logs in a single query, but you pay for every gigabyte and endpoint tables are huge. A device generates thousands of process events a day across thousands of devices, so the trade off is plain capability against cost. And the answer isn't all or nothing. Which brings up tiering. Not every log earns the same price tag. Sort your data by value. Some tables feed detections you run every day identity sign ins, cloud app events, email events. Those go into the full analytics tier where rules can query them fast. Other tables matter only when an investigation starts. Verbose network logs raw process events from low risk devices. Those can sit in a cheaper tier or in the data lake, where you pay less to store them and query them only when needed. A third group you need only for compliance. Keep it long and cheap and never query it unless an auditor asks. So for each table, ask one question which rule or investigation would break if this data vanished tomorrow? If the answer is none, it doesn't belong in the expensive tier. Do that review once at setup, then again every quarter because both your detections and your data volumes drift. Now the problem that shows up in week two duplicate incidents. Here's how it happens. Defender raises an alert on a suspicious sign in the connector brings that alert into Sentinel. Then a Sentinel Analytics rule running over the same raw table files on the same behavior. Two alerts, one event, and now two incidents or two tickets and an analyst working both. The first fix is to decide who owns each detection. If defender already covers a behavior, don't write a Sentinel rule for it. Turn off the creation of incidents from Microsoft security alerts in Sentinel, since the connector already brings the real ones through, that one setting prevents a lot of doubles. The second fix is grouping in the unified portal. Correlation merges related alerts from both systems into one incident, but it only merges what shares entities, so keep your entity mapping consistent across both sets of rules. Same user identifier, same device ID. Sloppy mapping is how duplicates survive. That leads to the author in question. Where do you write a new rule? Use defender custom detections when the data lives in defender tables, and you want the result to trigger native response. Alerts from those rules can feed automated investigation, device containment, and the same incident logic as built in alerts near real time is also available only. there. Use Sentinel Analytics rules when the query needs data from outside defender. When you need longer lookback than advanced hunting holds, or when you want to run a scheduled rule against a joined set of tables. One simple test works does the rule need anything? Defender can't see Sentinel otherwise defender. So now the data is in one place. The incidents flow both ways. The costs have a ceiling and the duplicates have an owner. What's still missing is the part that acts. A queue full of good incidents is only a better list. Next, the response engine response playbooks. From alert to action. A playbook is a decision. That's all it is. Somebody at some point decided, when this happens, we do that. And right now, in most teams, that decision lives in a wiki page or in one senior analyst's head, or in a Slack message from two years ago, a playbook takes that decision, writes it down in steps, and makes the steps run on their own. So the question isn't what can we automate? It's which decisions do we already make the same way every time? Those are your first candidates. If three analysts would all respond identically to the same alert, a person doesn't need to be in that loop. Now, the mechanics in Sentinel playbooks are built on Azure Logic apps. A logic app is a workflow, a trigger, then a series of steps, each one calling a service. Read a user from. Enter ID, post a message to teams. Call the defender API. Open a ticket. There's a connector for most of the tools you already own, but a playbook doesn't start itself. Something has to fire it. That's the job of automation rules, and they sit in front of the playbooks as the trigger layer. An automation rule watches for incidents or alerts, checks conditions, and then does something. It can run a playbook. It can also assign an owner, change severity, add a tag or close the incident. You write a condition like incident created, severity high contains a user entity from the privileged tier, and then attach the playbook that should run. So think of two layers. The rule decides when the playbook decides what keeping them apart pays off. One automation rule can call several playbooks in order, and you can retire a playbook without rewriting every trigger that used it. Now, what do people actually build? First four playbooks cover most of the value isolated device. When an incident confirms a compromised endpoint, the playbook calls defender for endpoint and cuts the machine off from the network. defender itself stays reachable so the analyst can still investigate disable a user. The playbook marks the account as disabled in enter ID and the stolen password stops working. Revoke sessions different from disabling and often better, it kills every active token for the user, so a replayed session dies on the spot, while the person can sign back in cleanly after a password reset block an indicator, a bad IP, a domain, a file hash, the playbook adds it to the block list so the next attempt fails at the door. Each of these is a single action that's on purpose. Small playbooks are easier to test, easier to trust, and easier to combine later. But here's the mistake that sinks a lot of first attempts. They go straight to the action and alert arrives, and the playbook disables the account, no questions asked. And then it turns out the attacker was the CFO signing in from a hotel in another country, and now the finance lead can't approve payroll. So enrichment comes first. Pull context, then decide, then act before any action. The playbook gathers. What a human would look up. Is this user in the VIP group? What's their risk level right now? Did the device show other alerts in the last day? Is the IP address on the thread feed or is it a known corporate range? Who is the manager? What time is it for this user? Each answer is a call to an API and each one takes seconds. Then comes a condition. If the user is low risk, the device is unmanaged and the indicator matches a known threat. Proceed. If the user is a VIP stop and ask a person. The logic reads. Just like the checklist an analyst would run, except it runs in four seconds at three in the morning every time. And that brings up the last piece of design approval gates for high impact actions. The playbook doesn't act. It asks. It posts to a teams channel or sends an email with the incident summary, the evidence it collected, and two buttons approve or reject. The workflow waits. If a named person approves, it continues. If nobody answers in thirty minutes, it escalates to the next person on the list. That gives you speed, where the risk is low and a human decision where the risk is high, the analyst isn't doing the work anymore. They're making the call with all the context already on the screen. So you have triggers, playbooks, enrichment, and approvals. That's a working response engine. And it's also a very efficient way to break your own tenant if nobody puts limits around it. Guardrails. Safe automation at scale. Every playbook is wrong. Sometimes not because the logic is bad. Because the data changes, the environment shifts. A rule written in March meets a situation nobody pictured in March. So you don't design for the day. It works. You design for the day. It's wrong. That's blast radius thinking for each playbook. Ask one question before it ever goes live. If this fires on the wrong target, how far does the damage spread? Take revoke sessions, wrong target and one person signs in again. Annoying five minutes lost. Take isolate device, wrong target and a laptop goes dark. Worse, but you can reverse it. Now take a playbook that disables accounts fired by a rule that matches too widely. A bad day produces fifty disabled users before lunch. The action is the same. The radius is what changed. So write the radius down next to each playbook one user, one device, one group or the whole tenant then match the safeguards to the size. The first safeguard is a list of things the playbook must never touch. VIPs, executives, finance approvers, the people whose lockout becomes a phone call to your boss service accounts because disabling one can stop a payment, run a backup or an entire application, and nobody notices until something downstream fails. Critical servers, two domain controllers, the hosts that run production. The machines where isolation means an outage. Keep these as exclusion lists in a watch list or a security group, and make the playbook. Read the list as its very first step. Is this target on the list? If yes, don't act. Route it to a person with a clear note on why that's the same idea as the approval gates, but harder. Some targets shouldn't be automated at all, no matter how confident the signal looks. Second limits on the playbook itself. A rate limit says this playbook may disable at most five accounts per hour. The sixth request stops, and page is someone. It sounds minor, but it's the thing that turns a runaway loop into a small incident, because the failure you're afraid of usually isn't one bad decision. It's one bad decision repeated four hundred times at machine speed. Next, a kill switch. One switch, one place that turns the automation off, a setting that the playbook checks at the start of every run, so anyone on call can flip it and stop everything in seconds. Don't make people hunt through logic apps at two in the morning to find the right one. Test the switch two. A kill switch nobody has pressed is a hope, not a control. Then a rollback path for every action. No. The undo. Isolated a device. There's a release action. Disable the user. Re-enable blocked an indicator. Remove it. Write the reverse steps as their own small playbook. So reversing a mistake takes one click instead of a scramble forth a record. Every automated action should leave a trace. What ran, which incident triggered it, which target, what evidence it used, who approved, and what the result was. Write that into the incident comments and into a log table you can query later when an auditor asks why a director's account was locked on a Thursday, you don't reconstruct it from memory. You read the entry, and when something goes wrong, the log is how you find the cause in minutes instead of days. And last, a pilot never launch a new playbook against the whole tenant. Pick a small group first. A few dozen devices. A team that knows it's being used as the test. Ideally in an area where a mistake is cheap. Run in a mode where the playbook proposes but doesn't act, and compare what it would have done against what an analyst actually did. then turn on real actions for that group. Only widen the scope when the numbers hold and not before. So now you have a response engine with limits, lists, switches, and records. That raises the question every executive asks sooner or later. Not is it clever? But is any of this working? Measuring detection quality. Most security reports start with account alerts. This month, incidents closed, tickets opened, the number goes on a slide and the slide goes up the chain. But account tells you how busy the system was. It says nothing about whether it worked. A tenant can double its alert volume and be less safe because the extra alerts were noise. It can halve the volume and be safer because the cuts were the right ones. Same number, opposite meaning. So the shift is from activity to outcome. Stop asking how many alerts fired. Start asking how many were right, how fast you saw the problem, and how fast you stopped it. That takes a few specific measures and they all start from one input. You already have the analyst verdict. Every alert that gets closed as true, positive, false, positive, or informational is a data point. If your team skips that classification, none of what follows is possible. So that's the first habit to enforce. True positive rate is the share of alerts that turned out to be real activity. False positive rate is the share that turned out to be harmless. There are two sides of one coin, and you track them per rule, not just across the whole tenant. A tenant wide average hides everything. One rule at ninety five percent false positives disappears inside a fine looking overall number. Precision is the cleaner way to say it. Of everything the rule flagged how much was worth flagging. Low precision means analysts spend their day proving nothing happened. And as we saw earlier, that's where real incidents go to hide. Now, the two time measures, which matter more than most teams admit time to detect, is the gap between when the malicious activity started and when an alert fired time to respond is the gap between the alert and the action that contained it. Track them separately because they break for different reasons. Slow detection usually points at a missing rule, a late data feed, or a rule that runs on a slow schedule, slow response points at cues, unclear ownership, or a playbook that waits too long for approval. A tip on reading them use the median, not the average. One incident that sat untouched over a holiday weekend will drag an average into nonsense. The median tells you what a normal day looks like. Then look at the slowest tenth separately because that's where the real exposure lives. So far, every measure looks backward. They grade the alerts you already have. But there's a question they can't answer. What about the attacks you have no rule for? That's the job of the coverage metric. Take your prioritized list, the techniques tied to your crown jewels and privileged roles, the ones you chose earlier. Instead of copying the whole matrix, then count how many of them have a detection that has actually been tested and proven to fire. Divide. That's your coverage. Notice the word tested. A rule that exists but has never been proven is a rumor. If you have forty prioritized techniques and twenty two have a rule that fired in a real test, your coverage is fifty five percent. That number tells leadership something no alert count can. How much of the ground you decided to defend is actually defended? Now bring it down to the individual detection. Each rule gets a scorecard for things on it volume, how often it fired over the last ninety days, outcomes. How many of those were true positives? How many false? Last review date when a person last looked at it with fresh eyes and an owner saw the scorecard has someone to land on. Put those on one row per rule and patterns. Jump out. A rule with high volume and zero true positives is a candidate to tune or retire. A rule that has never fired in a year is either perfect or broken, and you can't tell which without checking a rule with great precision. And no review in eighteen months is probably still fine, but the data it depends on may have changed underneath it. That last case brings up the weak spot and everything above. Every metric in this section assumes the rules work the way you think they do. A silent rule looks identical to a healthy one on a dashboard. Zero alerts might mean zero attacks, or it might mean the query broke after a schema change and nothing has fired since. So the numbers only mean something if the detections have been tested on purpose against real behavior before an attacker does it for you. Testing detections, validation, and purple teaming a rule you've never fired on purpose is a guess. So the first test is the simplest one. Run the behavior the rule is supposed to catch, then check whether the alert appears. This is the atomic approach. You take one small attacker action one technique, and you reproduce it in isolation encoded PowerShell from a word child process. A scheduled task created from a script host a registry write to a run key. Each one is a single controlled step with a known expected result. The rule fires or it doesn't and it doesn't is the useful outcome. That's a gap you found on your own schedule, not an attacker's. Run these on a test device in a device group built for that purpose. Then check three things. Did the alert fire? Did it land on the right user and device? And how long did it take? A rule that fires eleven minutes late because of the schedule you picked. Tells you something about time to detect that no dashboard would. Now you don't have to build every test by hand. Defender gives you some of it already. For endpoints, you can run attack scenarios from the portals, simulation features and the Guided Evaluation Lab. These reproduce known behaviors like credential dumping attempts or suspicious script activity, so you can see what the built in detections catch. That's useful as a baseline, but notice what it proves. It proves Microsoft's detections work on Microsoft's scenarios. Your custom rules need your own tests for email. There's attack simulation training in defender. For office three hundred sixty five, you launch a simulated phishing campaign with a credential harvest or a malicious link, and you watch what happens. Who clicked, who reported it. Did the policies block the message, or did it reach the inbox that test the people and the controls together, and it feeds the email detections we built earlier with real click behavior. But testing one rule at a time only gets you so far. Attackers don't run techniques in isolation. They chain them. That's where purple teaming comes in. It's a loop between two roles. The red side runs a technique the way an attacker would. The blue side watches and records what they saw, what they missed, and what fired late. Then comes the step that makes it work. The blue side tunes right there in the same session. Right? The missing rule. Narrow the noisy one. Fix the entity mapping. Then the red side runs the technique again. Run, miss, fix rerun. Same afternoon. And the output isn't a report that gets filed. The misses go straight into the detection backlog ranked by the risk. They uncover a technique that slipped past with no alert, aimed at a privileged role jumps to the top one that fired but with poor context goes lower as a tuning task. That's how testing becomes the source of your next rule. Instead of a separate exercise, nobody connects to the work. If you don't have a red team, you can still do this. Pick three techniques from your prioritized list. Each month one person runs them, another watches the queue. It's slower and it still finds real holes. Then there's the test. Most teams forget the one that checks whether yesterday's rule still works. Rules break quietly. Microsoft renames a column or changes how a table is populated. A new agent version alters what a process event contains. A product update shifts a field from one table to another. Your query still runs and still returns. Nothing. No error, no alert. Just silence. That looks like safety. So run regression tests. Keep your atomic tests as a standing set one per rule and rerun them on a schedule monthly at least, and always after a schema or product change. Compare the results to the last run. A rule that fired in March and stays quiet in June, has either been fixed by luck or broken by an update, and you need to know which. Treat this like a smoke alarm check. You don't test it because you expect a fire. You test it because the cost of finding out late is the whole house. But look at what all this testing creates. A growing set of rules, tests, results, and backlog items. Each one needs someone responsible and a clear path from birth to retirement. Without that, the tested rule today becomes the forgotten rule next year. 01:09:41 Speaker: A detection as code and lifecycle governance. Open the portal and look at your custom detections list. Now ask a simple question who changed the last one and why? In most tenants, nobody can answer. Someone edited the query in a browser tab, hit save, and moved on. The old version is gone. There's no review, no record of what the rule used to do, and no way to roll back when the edit turns out to be wrong. That's how most teams treat detections like settings. But a detection is code. It has logic inputs and side effects, and a bad change can blind you just as easily as a bad deployment can break an app, so treat it that way. Store every rule in version control. A git repository works fine. Each detection becomes a file. The query, the schedule, the severity, the metadata all in one place. Then changes. Go through a pull request. One person proposes. Another reads it. Does the query filter early? Does it return the entity columns? Is the exclusion narrow and does it have an owner and an expiry? That review catches the broad rule before it ever reaches the queue. You also get history for free six months from now, when a rule goes quiet, you can see exactly which commit changed it and rolling back is one click. Now the deployment side defender exposes custom detections through the Graph Security API so you can create, update and disable rules from a script. Wire that to a pipeline, emerge to the main branch triggers a build. The build validates the query syntax, and the deploy step pushes the rule to the tenant. Nobody touches the portal to make a change that does two things. First, it removes drift because the repository becomes the source of truth and the tenant simply mirrors it. Second, it lets you test before you ship, run the query against a test tenant or a saved data set. Confirm it returns what you expect and only then promote it. But code in a repository still needs rules about who owns it and what it looks like. Start with ownership. Every detection gets a named owner, a person, or a team written into the file. When the rule misfires at night, that's who gets the question. A rule with no owner decays because nobody feels responsible for tuning it. Then severity standards write down what high, medium and low mean in your tenant. High might mean page someone now likely active compromise of a privileged identity. Medium means review within the business day without a written standard, ten authors will pick ten meanings and your queue order becomes noise again. And naming. Pick a convention and enforce it in the pull request something like workload, technique, behavior. Identity token replay. New device privileged action sorts well, searches well and tells an analyst what happened before they open it. Suspicious activity four tells them nothing. Last piece of the life cycle and the one almost nobody writes down. Retirement. A rule should earn its place continuously. Set criteria. Up front, it fired zero times in twelve months and its test still passes. Keep it. It may simply be catching nothing because nothing happened. It fires often, and analysts close it as harmless ninety percent of the time, even after tuning. Retire it or rewrite it. The data source it depends on no longer exists. Remove it. The technique it covers is now handled better by a built in detection. Remove it and. Note why retiring isn't deleting. Disable the rule. Keep the file in the repository and record the reason. If the situation changes, you can bring it back. All of this gives you a system that's reviewable, repeatable, and honest about what's live. But a repository and a pipeline don't run themselves. Someone has to write the pull requests, read the verdicts, and decide what gets retired. Governance only works if the people around it are set up to carry it. The operating model behind good detection. Everything so far needs people and people need to find jobs in most teams. One person does all of it the same. Analyst Triages the cue writes the odd query tweaks an exclusion and answers the CISO. That works until the queue grows. Then the rule writing is the first thing to go. So separate the roles. Even if one person wears two hats, the detection engineer owns the rules. They write the query, run the tests, keep the repository clean, and retire what's stale. The analyst works the queue and makes the verdict on each alert. The incident commander takes over when something real is unfolding. They decide who contains what, who talks to the business, and when the incident is over and the executive sponsor clears the path. Budget, priorities and the authority to say, yes, we'll lock that account for jobs, for different questions. And when nobody owns the first one, the rules just sit there aging. Now, the part that holds all four together, the feedback loop. Every verdict an analyst enters is information about a rule. True. Positive. False. Positive. Informational. If that verdict never reaches the person who wrote the rule, the rule never improves. The analyst keeps closing the same noisy alert week after week, and the engineer thinks everything is fine. So close the loop on purpose. Once a week, the detection engineer pulls the verdicts for each rule. Which ones were closed as false positive more than half the time? Which ones? Nobody could classify because the alert lacked context. Each of those becomes a ticket. Narrow the exclusion. Add the missing column. Change the threshold. Then the analyst gets told what changed. That last step matters. When analysts see their verdicts turn into fixes, they classify more carefully and the data gets better. Next, the people above all this executives don't want rule counts. They want three answers. What risk did we reduce? How much time did we save and what exposure did we close? Risk reduced is the coverage number from earlier moving up against the techniques tied to your crown jewels. Time saved is analyst hours and you can calculate it alerts removed by tuning times minutes per alert. Plus the worker playbook now does on its own, an exposure closed is the tuning debt number falling plus the gaps your purple team found and fixed. Put those three on one page once a month. Show a trend line, not a snapshot. Median time to respond. Dropped from forty minutes to twelve. Lands better than any dashboard screenshot. Now what if you have two people, not twelve? Then don't try to do all of this. Start small and be strict about it. Three rules pick the three detections that cover your highest risk. Probably one for identity, one for email, one for endpoint. Write them well, test them and give each an owner one playbook. Choose the simplest, lowest radius action, like revoking sessions for a confirmed compromised user with an approval gate and a kill switch. One metric, just one precision on those three rules or median. Time to respond. Track it every month and report it. That's a small start, and it's enough because it proves the loop works. Once it does, you add a rule, then another. The system grows from evidence, not ambition. But notice what you've just built roll by roll and metric by metric. It's a different way of thinking about the whole platform, and that's worth stepping back to look at. Reframing the model. Look at where this started. A tenant switches on defender XDR. The portal fills with alerts. The team opens them one at a time and reacts. Some are real, most aren't, and the whole operation depends on a single belief. The vendor knows what matters. So the job is to keep up with what the vendor sends. That's the old model. Consumer alerts react and it fails in a very specific way. It treats detection as something you receive like a delivery. The box shows up, you open it, and whatever is inside becomes your workload. Nobody asks whether the contents fit your business, because the model never gave anyone the job of asking. The new model flips the direction. You engineer context. You decide which identities, mailboxes, and devices carry the most risk, and you write detections around them. You correlate. So one intrusion shows up as one story. Instead of three tickets, you automate the decisions you already make the same way every time with limits around them. And you measure. So that is it. Working has an answer with a number in it, same platform, same licenses, different relationship to it. Now a trap hides in that shift. It's easy to hear all this and picture a project. Build the rules via the playbooks, set up the dashboard and call it done. But that's the old thinking. Sneaking back in deployment as a milestone detection quality doesn't work that way. Attackers change their methods. Microsoft changes its schemas. Your own environment changes every time someone adopts a new tool, merges a company, or reorganizes a team. A rule that was sharp in January is slightly off by June and nobody touched it. The ground moved. So quality is a discipline, something you do weekly in small pieces. Read the verdicts. Tune one rule test one technique review, one expiry date, boring, repeatable work. And it's the only kind that keeps the system honest. And you should be clear about the limit, because pretending otherwise is how teams get complacent. No rule set is ever finished. You'll never reach a point where coverage is complete, noise is gone and the backlog is empty. There will always be a technique you haven't written for, an exclusion that's aging, and a data source that quietly broke. The goal isn't completion, it's direction. Each month, the numbers that matter should move the right way. Precision up. Time to respond. Down. Tuning debt falling. Tested. Coverage rising. If they do, you're ahead of where you were. If they stall, you know where to look. That's the whole shift. And it fits in one sentence. Stop asking what the platform detects. Start asking what you've told it to look for. Which leaves only the question of what happens if you don't. Conclusion. Review request and LinkedIn call to action. Here's the consequence. Plainly, a tenant that never tunes its defaults will meet its incident through a default alert. Nobody read that alert sits in the queue between two hundred others marked medium. If this kind of detection engineering content helps you think differently, leave a review. It takes a minute and it helps more people find it. Connect with me. Mirko Peters on LinkedIn. Tell me which topic should come next and share this with the team. Buried in alert noise right now. They're the ones who need it today. From defaults to detection. That's the shift.