Architecting a SOC on
Defender XDR and
Thijs Lecomte &
Microsoft Sentinel
Robbe Van den Daele
Speakers
Robbe Van den Thijs Lecomte
Daele
Security Consultant & Head of Managed
SOC Engineer @ The Services @ The Collective
Collective Security MVP
What are we going to discuss?
1. Architecture 4. Detection Engineering
2. Multi-tenant authentication 5. Data Collection
3. Automated deployments 6. Playbooks / Automations
4. Exclusion Management 8. Case Management
1. Architecture
Single-tenant architecture
Multi-tenant architecture
Multi workspace setup
REGULATORY DATA MULTIPLE
COMPLIANCE OWNERSHIP TENANTS
Multi workspace setup
- MSSP should deploy a workspace for each
customer in the customer tenant
- Keep architecture as simple as possible for each
‘customer’
- Make sure you have a central management system
Managing a multi workspace setup
Incidents → Multi workspace incident view
Managing a multi workspace setup
Queries → Multi workspace queries
- Using workspace() expression with union operator
- Can be used in analytic rules (not recommended for
MSSP’s)
- Max 20 workspaces (5 recommended)
- Incident exists in main tenant
- Good for investigations, threat hunting, and workbooks
Workspace manager
Protecting intellectual property as MSSP
Hosting content in Restricting content Contractual
MSSP tenant in customer tenant agreement
Protecting intellectual property as MSSP
Contractual
Hosting content Restrict access agreement
Incidents & alerts in customer tenant? No Yes Yes
Customer transparency? No No Yes
Straight-forward setup? No Yes/No Yes
Protective controls? Yes Yes/No Yes/No
2. Authentication for multi-
tenant deployments
What are the options?
GDAP Lighthouse Guest Users Named Admins
What are the options?
GDAP Lighthouse Guest Users Named Admins
User object in customer tenant? No No Yes Yes
Auth properties in customer tenant? No No No Yes
Granular roles supported? Yes/No Yes Yes Yes
Admin Accounts? Yes Yes No Yes
Customer has access control? No No Yes Yes
What are the options?
MSSP Preferred
(MTO) Customer Preferred
GDAP Lighthouse Guest Users Named Admins
3. Automated deployment
The need for automated deployment
REDUCING FOUR EYES AUTOMATIC
MANUAL EFFORT PRINCIPLE VALIDATION
What are the options?
Azure Sentinel Workspace
DevOps Repositories Manager
Native Implementation? No Yes Yes
Automated Deployment Yes Yes No
Customization possible? Yes Yes No
Four-eyes principle Yes Yes No
Automatic validation (naming…) Yes Yes* No
ARM vs Bicep
Personal choice
Ease of exporting
Supported resources
• Everything Sentinel-related
• Data Connectors?
• Defender Custom Detections
• Other Defender resources
The Collective Setup
• Overrides
• Specific data sources
• Variables per customer
• Timing of deployments
• Deploy everything or only changes
Sample Setup
Generic
templates
Validation
Customer
&
workspace
deployment
Customer
templates
4. Exclusion management
Why do you need exclusions?
• Decrease false positive
• Avoid negative impact
Where to add exclusions
• Analytic rules/custom detection rules
• Sentinel Automation Rules
• Defender Alert Tuning
• Defender Indicators
• MDI exclusions
Best practices
• Exclusion register
• Customer notice / approval
• Approval
• CI/CD Integration
• Avoid incidents
Decision tree
5. Detection Engineering
Why?
CLOSE GAPS IN DETECTION REDUCED DWELL TIME DETECT ADVANCED ADVERSARIES
MECHANISMS EVADING TRADITIONAL
DETECTION SOFTWARE
Building detection rules
How? Adding tools or data sources
Changing data collection logic
Types of detection rules How?
(SUSPECTED) ANOMALIES ITEMS OF
THREATS SPECIAL INTEREST
Types of detection rules How?
C2 USAGE OF DNS LOOKUP OF
COMMUNICATION UNUSUAL TLD’S ILLEGAL SITE
Adding tools or data How?
Adding tools or data How?
Data collection logic How?
Where do you start?
Identify crown jewels and
evaluate data value
Search capture points
Start with a basic but diverse
coverage
SOC Optimization – Basic Detection Gap Analysis
SOC Optimization – Basic Detection Gap Analysis
Advanced Detection Gap Analysis
Detection Engineering Responsibilities
‘Traditional’ detection engineer
Building detection rules building detection rules
How? Adding tools or data sources
SOC engineer building
data collection and
normalization
Changing data collection logic
6. Data collection
Data Collection
AGENTS FORWARDERS CODELESS API INTEGRATION
CONNECTOR
PLATFORM
Agents
Microsoft Monitor Microsoft Defender Azure Monitor
Sysmon
Agent for Endpoint Agent
• Legacy • Less flexibility • More flexibility • Extra agent
• Less flexibility • Easy deployment • Data • MMA or AMA
• No data • No data transformations still needed
transformation transformation available • Good for edge
• Connected to • Connected to • Associated to cases
Log Analytics Defender XDR DCRs
Workspace • Azure ARC
• End of life
Forwarders
• Forward data from device where no
agent install is possible
• Network appliances, hypervisors, etc.
• Syslog, beats, log4j, SNMP, etc.
• Mainly used in on-premise scenario’s
Forwarders
Azure Monitor Agent Logstash
• Easier than Logstash • Local filtering
• Normalization and • DCR support
transformation via DCR • Can run in containers
• Variety of input plugins
• No ARC onboarding
Codeless Connector Platform
API integration
• Two ways
• Workspace ID & Key (old way)
• Log Ingestion API
• When data source does not have
polling API
• When you want a ‘push’ scenario
7. Playbook & automations
Automation - Playbooks
Security products
Ticketing systems
(ServiceNow)
Build automated and Azure Logic Apps
scalable playbooks that Additional tools
integrate across tools
Common use cases
• Synchronization/notification
• Enrichment
• Action
• Password reset
• Device Isolation
Playbooks for MSSP’s
Have a uniform way to reset a password,
independent of the customers’
willingness/trust in automation.
Parameter usage
• Single Logic App Across customers
• Parameters configuring:
• Actions
• Exclusions
• Notifications
Logic Apps vs Azure Functions
• Native triggers
• Disadvantages:
• Loops
• Complex object/array changes
Azure API Management
• Sub-playbooks
• Multi-tenant scenario
• Rate limiting
8. Case Management
Incident Management
SENTINEL ITSM TOOLING 3RD PARTY
SOAR
Sentinel Limitations
• Multiple queues
• Customizations
• Fields
• Status
ITSM Tool
• Integration into other business
processes
• Lacking SOAR capabilities
3rd party SOAR
• Feature rich
• Strong investigation experience
• Automation location – Sentinel?
• Additional price
The Collective Implementation
• JIRA Cloud
• Heavily customized
• Custom sync engine
• Automation within Sentinel
• Customers’ tenant
9. Closing off
Closing off
Doing the right
01 02
Complexity thing isn’t easy
Building a SOC requires a lot of Least Privilege & Native has it’s
different specializations disadvantages
Personal Approach Native
04 03
Every XDR & SIEM deployment Leverage, then build
is different – threat is as such
Please evaluate this session in the App.
THANK YOUAre there any questions?
Next Sessions
The art of knowing your SIEM & XDR Data- Bert-Jan Pals (19&20)
Attack Path Based Detection Engineering – Olaf Hartong (16)
Mastering PIM – Louis Mastelinck (21)