đź”»Incident Response: When live action jumps off, having 3-4 high-impact IR Custom Detections that automatically Restriction App Execution, Isolate, or Disable User can help limit impact while the compromised devices/identities are being investigated by the SOC.
🔻Risk-based Analytics: Want to augment 365D Device & Identity Risk levels with your own risk definitions? Create your own “C-UEBA” Custom Detections & use the Low, Medium, High severity levels.
You can also leverage a Logicapp/Function to pull (only) CD content into the Threat Hunting data store via Graph. You can dynamically update the content that is being searched for by using externaldata jsons. đź”»Threat Hunting: Need some daily hunts? Leverage Custom Detections & configure the streaming API to export Alert/AlertEvidence jsons to Log Analytics or Azure Storage. You will need a strategy, schema, and internal expertise.
Please do not take every Sigma rule you can find, convert it to KQL with Uncoder, and create a Custom Detection with it. 👉Custom Detections are not designed to replace Sentinel Analytic Rules (SIEM) or the native detections that the 365 Defender products generate. When the TVM, IAM, CASB, & MDI tables are joined with the Device tables, awesome cybersecurity detections become possible! 💡Microsoft has learned that many of it’s largest & most successful MDE deployments have well-defined & continuously-managed Custom Detection programs that leverage this functionality to augment native detections & deliver automated responses (SOAR) for custom criteria. While many individuals have experience with custom analytics from traditional EDR tools, working with 365D Custom Detections is a unique experience and most of the 365D tenants I see have 3-4 random rules that were created 12-18 months ago in an enablement workshop (by a now-inactive UPN) and forgotten.
0 kommentar(er)
