A county purple team briefs leadership on Defender visibility limits at a high level. Which statement is most accurate for authorized planning?
Select an answer to reveal the explanation.
Short Explanation
Not every camera in the building sees the same hallway. User-mode and kernel-mode views differ, and that gap matters when county testers plan fair lab checks. Pretending there are zero blind spots sells leadership a fairy tale.
Full Explanation
County purple-team planning must account for architectural visibility boundaries in Defender-class endpoint stacks. User-mode observation (user processes, many script hosts, user-land APIs) differs from kernel-mode observation (drivers, certain callbacks, deeper system events). Those boundaries create different blind spots and different test designs: a technique visible to one layer may be partially or wholly opaque to another. Accurate high-level briefings state that defenders and authorized testers must plan around those limits rather than assume omniscience.
User-mode and kernel-mode visibility are not identical, so architectural distinction does matter. Defender does not see every possible kernel and firmware event with zero blind spots. Visibility limits are not 'macOS-only'; they apply to municipal Windows fleets that counties actually run.
Exam caveat: the most accurate authorized-planning statement acknowledges user-mode versus kernel-mode observation limits. Absolute claims of perfect visibility or irrelevance of the distinction are traps.
Operational check: in a county lab under ROE, document which exercise actions produce user-mode telemetry, which require kernel-oriented sensors or other controls, and where firmware or early-boot activity would need complementary tooling. Update purple-team scope documents so leadership expectations match measurable visibility, not marketing absolutes.