feat(microsoft-defender-o365): mvp1 - email focused - collect and match defender for o365 alerts (#470)

[Megafredo]

Parent Issue: #470

User stories

(No explicit user stories were defined in the brainstorm or in Feature issue #307. Reusing the Feature Overview from #470 as the closest equivalent, per user confirmation.)

As part of our phishing simulations, we want to introduce a Microsoft Defender for Office 365 collector capable of retrieving alerts related to injected emails and automatically matching them against the expected injection outcomes.

MVP1 focuses exclusively on email-related events. The goal is to automate the validation of phishing simulations by determining whether an injected email has been detected or blocked by Microsoft Defender for Office 365.

Chunk PRs

• CHK.1 - Project architecture setup:
  • Issue: feat(microsoft-defender-o365): mvp1/chk1 - project architecture setup #471
  • PR: feat(microsoft-defender-o365): mvp1/chk1 - project architecture setup (#471) #491
• CHK.2 - Define Microsoft Defender for Office 365 business configuration:
  • Issue: feat(microsoft-defender-o365): mvp1/chk2 - define business configuration (pydantic base settings) #493
  • PR: feat(microsoft-defender-o365): mvp1/chk2 - define business configuration (pydantic base settings) (#493) #494
• CHK.3 - Setup the collector engine and execution loop:
  • Issue: feat(microsoft-defender-o365): mvp1/chk3 - setup base engine and main loop wiring #495
  • PR: feat(microsoft-defender-o365): mvp1/chk3 - setup base engine and main loop wiring (#495) #496
• CHK.4 - Implement Microsoft Defender API authentication:
  • Issue: feat(microsoft-defender-o365): mvp1/chk4 - implement microsoft defender api authentication (msal) #497
  • PR: feat(microsoft-defender-o365): mvp1/chk4 - implement microsoft defender api authentication (msal) (#497) #498
• CHK.5 - Register and handle expectation signature types:
  • Issue: feat(microsoft-defender-o365): mvp1/chk5 - register expectation signature types #499
  • PR: feat(microsoft-defender-o365): mvp1/chk5 - register expectation signature types (#499) #500
• CHK.6 - Retrieve source data from Microsoft Defender for Office 365:
  • Issue: feat(microsoft-defender-o365): mvp1/chk6 - fetch source data from graph security api #501
  • PR: feat(microsoft-defender-o365): mvp1/chk6 - fetch source data from graph security api (#501) #502
• CHK.7 - Map Microsoft Defender data into OAEVData models:
  • Issue: feat(microsoft-defender-o365): mvp1/chk7 - map api data into oaevdata models #503
  • PR: feat(microsoft-defender-o365): mvp1/chk7 - map api data into oaevdata models (#503) #504
• CHK.8 - Implement matching logic between expectations and collected data:
  • Issue: feat(microsoft-defender-o365): mvp1/chk8 - matching integration between expectations and oaevdata #505
  • PR: feat(microsoft-defender-o365): mvp1/chk8 - matching integration between expectations and oaevdata (#505) #506
• CHK.9 - Generate trace data from matching results:
  • Issue: feat(microsoft-defender-o365): mvp1/chk9 - generate tracedata from matching results #507
  • PR: feat(microsoft-defender-o365): mvp1/chk9 - generate tracedata from matching results (#507) #508
• CHK.10 - End-to-end validation:
  • Issue: feat(microsoft-defender-o365): mvp1/chk10 - end-to-end validation #509
  • PR: feat(microsoft-defender-o365): mvp1/chk10 - end-to-end validation (#509) #510

Mermaid dependency schema

graph LR
    CHK1["CHK.1 - Architecture / Blank Collector scaffold (#491)"]
    CHK2["CHK.2 - DefenderO365Config (#494)"]
    CHK3["CHK.3 - Base Engine wiring / main loop (#496)"]
    CHK4["CHK.4 - MSGraphAuthClient / MSAL auth (#498)"]
    CHK5["CHK.5 - SUPPORTED_SIGNATURES (#500)"]
    CHK6["CHK.6 - DefenderO365DataFetcher (#502)"]
    CHK7["CHK.7 - to_oaev_data() (#504)"]
    CHK8["CHK.8 - Matching integration (#506)"]
    CHK9["CHK.9 - to_traces_data() (#508)"]
    CHK10["CHK.10 - End-to-end validation (#510)"]

    CHK1 --> CHK2
    CHK1 --> CHK5
    CHK2 --> CHK3
    CHK2 --> CHK4
    CHK4 --> CHK6
    CHK6 --> CHK7
    CHK6 --> CHK9
    CHK7 --> CHK8
    CHK7 --> CHK9
    CHK8 --> CHK10
    CHK9 --> CHK10
    CHK3 --> CHK10

Loading

Note: git branch bases follow a simplified sequential chain (CHK1→CHK2→CHK4→CHK6→CHK7→CHK9, with CHK3/CHK5 based on CHK2/CHK1 respectively, CHK8 based on CHK7, and CHK10 based on this Umbrella branch) since a PR can only have a single base branch — this diagram reflects the full logical contract dependencies, not the literal git graph.

Closes #470