Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains how Microsoft Sentinel receives security data from Microsoft services, cloud platforms, on-premises systems, third-party products, and custom applications.
For the SC-200 exam, this topic matters because Microsoft Sentinel is only useful when it has the right data sources connected. A Security Operations Analyst must understand how data connectors work, how logs are ingested into a Log Analytics workspace, how Microsoft Sentinel normalizes data, and how the Content Hub helps deploy connectors and related security content.
In a real SOC, data connectors directly affect detection coverage, incident investigation, threat hunting, alert quality, and response workflows. If the correct data is not connected, Sentinel cannot detect, correlate, or investigate activity from that source.
Key Concepts
What Is a Microsoft Sentinel Data Connector?
A data connector is the mechanism Microsoft Sentinel uses to collect security data from another system.
That source could be:
- Microsoft 365
- Microsoft Defender XDR
- Microsoft Defender for Endpoint
- Microsoft Defender for Identity
- Microsoft Defender for Cloud
- Microsoft Entra ID
- Microsoft Intune
- Azure services
- AWS
- Third-party SaaS platforms
- Firewalls
- VPN appliances
- Linux servers
- Windows servers
- Syslog sources
- Custom line-of-business applications
The connector establishes a path between the data source and the Microsoft Sentinel workspace so that logs and alerts can be ingested, stored, queried, and used for detection.
In simple terms:
Data source generates logs → Data connector sends logs to Sentinel → Sentinel stores data in Log Analytics → Analysts query, investigate, detect, and respond.
What Is Data Ingestion?
Ingestion is the process of bringing log data into Microsoft Sentinel.
Microsoft Sentinel is built on top of a Log Analytics workspace, and that workspace stores the ingested data. Once the data is in the workspace, it can be used for:
- Analytics rules
- Incident generation
- Hunting queries
- Workbooks and dashboards
- Entity correlation
- Automation workflows
- Investigation graphs
- Threat intelligence matching
- Reporting and compliance use cases
For the SC-200 exam, remember that Microsoft Sentinel does not automatically know about every event in your environment. You must connect the appropriate data sources first.
Why Data Normalization Matters
Different products generate logs in different formats.
For example:
- Microsoft 365 audit logs have one structure.
- Azure activity logs have another structure.
- Firewall logs may use syslog or Common Event Format.
- Endpoint logs may use device-specific schema.
- Custom business applications may export logs in CSV or another format.
Without normalization, analysts would have to manually interpret each product’s native log format. That becomes difficult during incident response because different log sources may use different field names, timestamps, event IDs, usernames, IP address fields, and severity values.
Normalization helps convert data into a more consistent structure so it can be queried, correlated, and investigated more effectively.
This is important for SOC work because incidents often span multiple systems. A single attack may involve:
- A phishing email
- A suspicious sign-in
- Endpoint malware execution
- Lateral movement
- Privilege escalation
- Cloud resource modification
- Data exfiltration
To investigate that chain of activity, Sentinel needs data from multiple sources in a usable format.
Common Types of Sentinel Data Sources
Microsoft Cloud Data Sources
Microsoft Sentinel can ingest data from many Microsoft services, including:
- Microsoft 365
- Microsoft Defender XDR
- Microsoft Defender for Endpoint
- Microsoft Defender for Office 365
- Microsoft Defender for Identity
- Microsoft Defender for Cloud
- Microsoft Entra ID
- Microsoft Intune
- Azure Activity logs
- Azure resource logs
These connectors are especially important for SC-200 because much of the exam focuses on Microsoft’s integrated security ecosystem.
Azure Infrastructure and Platform Data
Sentinel can collect security-relevant data from Azure infrastructure and platform services.
Examples include:
- Azure Activity logs
- Azure subscription activity
- Azure resource logs
- Azure Firewall logs
- Network security group flow logs
- Microsoft Defender for Cloud alerts
- Key Vault logs
- Storage account logs
- App Service logs
This helps analysts detect suspicious administrative activity, cloud misconfiguration, resource abuse, and attacks against Azure workloads.
Microsoft 365 and SaaS Data
Microsoft 365 can generate a large amount of useful security data, including:
- Exchange Online activity
- SharePoint activity
- OneDrive activity
- Teams activity
- Audit logs
- Email security events
- Defender for Office 365 alerts
This is important because many attacks begin with identity compromise or phishing. Microsoft 365 data helps analysts investigate email-based attacks, suspicious user activity, mailbox abuse, and collaboration platform misuse.
Endpoint and Device Data
Endpoint data may come from:
- Microsoft Defender for Endpoint
- Windows event logs
- Linux logs
- Sysmon logs
- Third-party endpoint tools
- EDR platforms
- Intune device data
Endpoint telemetry is critical for determining what happened on a device. It can help answer questions such as:
- Was malware executed?
- Which process launched the suspicious command?
- Was PowerShell abused?
- Did the attacker create persistence?
- Was lateral movement attempted?
- Should the device be isolated?
Network and Firewall Data
Sentinel can ingest logs from network security products such as:
- Palo Alto firewalls
- Check Point firewalls
- Cisco devices
- VPN appliances
- Syslog sources
- CEF-compatible products
Network logs help analysts identify:
- Suspicious outbound traffic
- Command-and-control activity
- VPN anomalies
- Brute-force attempts
- Lateral movement
- Connections to known malicious IPs
- Data exfiltration patterns
Third-Party Cloud and SaaS Sources
Microsoft Sentinel is not limited to Microsoft services. It can also ingest data from external platforms such as:
- AWS
- Third-party SaaS applications
- Third-party identity providers
- Third-party firewalls
- Third-party EDR tools
- Custom applications
This is one of the main reasons organizations use Sentinel as a SIEM. It can centralize logs across a hybrid and multi-cloud environment.
On-Premises Data Sources
Microsoft Sentinel can also collect data from on-premises environments.
Common methods include:
- Agent-based collection
- Syslog forwarding
- Common Event Format ingestion
- Windows event forwarding
- Azure Monitor Agent
- Log forwarding appliances
- Custom log ingestion
This is important for hybrid organizations that still have domain controllers, file servers, VPN concentrators, firewalls, Linux systems, or legacy applications running outside the cloud.
Agent-Based vs Agentless Connectors
Agent-Based Collection
Some sources require an agent to collect and forward logs.
Agent-based collection may be used for:
- Windows servers
- Linux servers
- Syslog systems
- Custom log sources
- On-premises environments
- Legacy systems
An agent is useful when the source system cannot directly send logs to Sentinel through a native API or cloud integration.
Agentless Collection
Other connectors can collect data without installing an agent.
Agentless connectors often rely on:
- Native cloud APIs
- Microsoft service integrations
- REST APIs
- Direct service-to-service connections
- Built-in Microsoft connectors
For example, Microsoft 365 and Azure services often integrate with Sentinel through cloud-native connectors rather than requiring an agent on a server.
REST API-Based Connectors
Some technologies support integration through a REST API.
REST stands for Representational State Transfer. In practical terms, an API-based connector allows Sentinel or an associated integration to retrieve data from the source system through a supported web-based interface.
This is common with cloud platforms, SaaS applications, and modern security tools.
For the exam, understand the concept rather than memorizing every connector. Microsoft expects you to know that Sentinel can ingest data through built-in connectors, APIs, agents, syslog, CEF, and custom methods.
Syslog and Common Event Format
Syslog
Syslog is a common logging standard used by Linux systems, network devices, firewalls, appliances, and security tools.
In a Sentinel deployment, syslog data may be forwarded into the Log Analytics workspace so analysts can query and correlate it with other security data.
Common Event Format
Common Event Format, often abbreviated as CEF, is a standardized log format used by many security products.
CEF is useful because it gives different vendors a more consistent way to send security events. Sentinel can ingest CEF data and make it available for detection and investigation.
For SC-200, remember that syslog and CEF are especially relevant for non-Microsoft and on-premises security devices.
Custom Log Sources
Sentinel can also ingest logs from custom applications.
For example, an organization may have a custom line-of-business application that generates logs in a structured format such as CSV. If the logs can be collected and parsed, Sentinel can potentially ingest and analyze them.
This matters in real environments because not every critical application is a Microsoft product or a commercial security tool. Some organizations need to monitor custom business applications, internal portals, legacy systems, or specialized operational systems.
Manual Data Uploads and Air-Gapped Scenarios
Most Sentinel deployments rely on automated connectors. However, some environments may have special restrictions.
For example:
- Military environments
- Highly regulated environments
- Isolated networks
- Air-gapped systems
- Environments with no direct internet connectivity
In these cases, logs may need to be exported, transferred, and uploaded manually or through controlled forwarding mechanisms.
This is not the normal cloud SIEM pattern, but it is important to understand that Sentinel has flexible ingestion options.
Microsoft Sentinel Content Hub
What Is the Content Hub?
The Microsoft Sentinel Content Hub is a centralized location where you can find and deploy Sentinel content.
Content Hub packages may include:
- Data connectors
- Analytics rules
- Hunting queries
- Workbooks
- Parsers
- Playbooks
- Watchlists
- Solution templates
- Other Microsoft or third-party security content
The Content Hub helps analysts and administrators quickly add detection and monitoring capabilities for specific products, services, or security use cases.
For example, instead of manually building every connector, workbook, and analytics rule from scratch, you may be able to install a relevant solution from the Content Hub.
Content Hub vs Data Connectors
A data connector is the actual mechanism used to bring data into Sentinel.
The Content Hub is where you find installable Sentinel solutions and security content, including data connectors and other supporting components.
Think of it this way:
| Concept | Purpose |
|---|---|
| Data Connector | Connects Sentinel to a data source and ingests logs or alerts |
| Content Hub | Catalog of installable Sentinel content, including connectors, rules, workbooks, and hunting content |
This distinction is exam-relevant because a scenario may ask whether you need to connect a data source or install a Sentinel solution that includes multiple pieces of content.
Free and Paid Content
Many Content Hub items are free, especially Microsoft-provided connectors and solutions.
Some connectors or solutions may depend on third-party products or services that require separate licensing. For example, a third-party security product may have a Sentinel connector available, but the product itself still requires a paid subscription.
From an operational perspective, always distinguish between:
- Sentinel connector availability
- Third-party product licensing
- Sentinel ingestion costs
- Data retention costs
- Required permissions
- Required configuration on the source system
Azure Portal vs Microsoft Defender Portal
Microsoft has been moving Sentinel capabilities toward the Microsoft Defender portal.
Historically, Sentinel administration was commonly performed in the Azure portal. More Sentinel functionality is now available through the Microsoft Defender portal.
You may see Sentinel-related configuration in:
- Azure portal:
portal.azure.com - Microsoft Defender portal:
security.microsoft.com
For the SC-200 exam and real-world administration, be prepared for both portals. The concepts are more important than the exact blade location because Microsoft frequently updates the portal experience.
Key point:
Microsoft Sentinel is increasingly integrated with the Defender portal, but some environments and documentation may still reference the Azure portal.
Why Portal Changes Matter for Analysts
Portal changes matter because analysts and administrators need to know where to perform tasks.
Examples:
- Configure data connectors
- Install Content Hub solutions
- Review incidents
- Run hunting queries
- View workbooks
- Manage analytics rules
- Configure automation
- Investigate entities
- Review Defender XDR incidents
For exam scenarios, focus on the security function being performed rather than memorizing a single portal path.
Kusto Query Language Introduction
What Is KQL?
Kusto Query Language, or KQL, is the query language used in Microsoft Sentinel and several Microsoft security portals to search and analyze log data.
KQL is used for:
- Investigating incidents
- Reviewing alerts
- Hunting for threats
- Building analytics rules
- Creating workbook queries
- Filtering noisy data
- Correlating activity across tables
- Summarizing patterns
- Searching for indicators of compromise
KQL is similar in concept to SQL because it is used to query structured data, but the syntax and workflow are different.
For SC-200, KQL is a major skill area. You should understand how to filter, project, summarize, join, extend, and parse data.
Microsoft Security Operations Context
How Data Connectors Fit Into SOC Work
A SOC analyst relies on connected data sources to answer investigation questions.
For example, if an alert indicates suspicious sign-in activity, the analyst may need to review:
- Entra ID sign-in logs
- Conditional Access results
- User risk events
- Device information
- Endpoint activity
- Mailbox activity
- Cloud application activity
- Related alerts in Defender XDR
- Network traffic logs
If those data sources are not connected to Sentinel, the analyst may only see part of the attack.
Data connectors determine the visibility available to the SOC.
Example SOC Workflow Using Sentinel Data Connectors
1. Triage the Alert
An incident is generated in Microsoft Sentinel.
The analyst reviews:
- Incident title
- Severity
- Status
- Assigned owner
- Related alerts
- Entities involved
- MITRE ATT&CK tactics and techniques
- Source product
- Timeline of activity
The analyst checks whether the incident is based on data from connected sources such as Microsoft Defender XDR, Entra ID, or a firewall connector.
2. Identify the Involved Entities
The analyst reviews entities such as:
- User accounts
- Devices
- IP addresses
- Files
- URLs
- Mailboxes
- Cloud resources
- Processes
- Domains
Entity mapping is important because it allows Sentinel to understand which objects are involved in an incident.
3. Query Supporting Logs
The analyst uses KQL to search relevant tables.
Examples:
- Sign-in logs for identity activity
- Office activity logs for mailbox or SharePoint activity
- Security event logs for Windows activity
- CommonSecurityLog for CEF firewall data
- Device events from Defender for Endpoint
- Azure activity logs for cloud control-plane changes
The specific table depends on which connector ingested the data.
4. Determine Scope and Impact
The analyst investigates:
- Which user was affected?
- Which device was involved?
- Was the sign-in successful?
- Was malware executed?
- Did the attacker access email?
- Did the attacker move laterally?
- Was data accessed or exfiltrated?
- Were other users or devices affected?
This requires correlated data from multiple sources.
5. Contain or Remediate
Depending on the incident, the analyst may take actions such as:
- Disable or reset a user account
- Revoke user sessions
- Isolate a device
- Block an IP address
- Block a URL or domain
- Remove malicious email
- Create a firewall block
- Escalate to endpoint, identity, email, or cloud teams
- Trigger a playbook
The available response actions depend on the connected tools and permissions.
6. Document Findings
A SOC analyst should document:
- What triggered the alert
- Which data sources were reviewed
- What entities were involved
- Whether the activity was confirmed malicious or benign
- Scope of impact
- Containment actions
- Remediation steps
- Escalation details
- Recommendations for detection improvement
Good documentation helps reduce repeat investigations and improves SOC maturity.
7. Improve Future Detection
After the incident, the analyst or detection engineer may improve coverage by:
- Enabling additional data connectors
- Installing Content Hub solutions
- Creating or tuning analytics rules
- Creating watchlists
- Building hunting queries
- Adding workbook visualizations
- Automating common response steps
- Mapping detections to MITRE ATT&CK
- Reducing false positives
This is where Sentinel becomes more than a log repository. It becomes part of the detection engineering and incident response lifecycle.
Exam-Relevant Takeaways
What You Need to Remember for SC-200
- Microsoft Sentinel uses data connectors to ingest logs and alerts from Microsoft, third-party, cloud, and on-premises sources.
- Ingested data is stored in a Log Analytics workspace.
- Sentinel depends on connected data sources. If a source is not connected, Sentinel cannot analyze its logs.
- Data ingestion brings logs into Sentinel so they can be queried, correlated, visualized, and used for detections.
- Normalization helps make logs from different systems easier to analyze together.
- Microsoft Sentinel can ingest data from Microsoft 365, Azure, Defender products, Entra ID, Intune, AWS, firewalls, Linux, Windows, syslog, CEF, and custom applications.
- Some connectors are agent-based, while others are agentless or API-based.
- Syslog and CEF are common for non-Microsoft and network/security appliance logs.
- The Content Hub is used to find and install Sentinel solutions, including connectors, analytics rules, workbooks, hunting queries, and other content.
- Microsoft is moving Sentinel experiences into the Defender portal, but Azure portal references are still common.
- KQL is used for investigation, threat hunting, analytics rules, and workbook queries.
- SC-200 scenarios often test which data source, connector, rule, query, or portal feature should be used for a security operations task.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| You need to bring Microsoft 365 audit logs into Sentinel | Microsoft Sentinel data connector | Connects Microsoft 365 data to the Sentinel workspace for investigation and detection |
| You need to collect firewall logs from a third-party appliance | Syslog or CEF connector | Network appliances commonly send logs through syslog or Common Event Format |
| You need to deploy a package of Sentinel content for a specific product | Microsoft Sentinel Content Hub | Content Hub provides installable solutions that may include connectors, analytics rules, workbooks, and hunting queries |
| You need to investigate suspicious activity across multiple log sources | Microsoft Sentinel with KQL | Sentinel centralizes data and KQL allows analysts to query across tables |
| You need endpoint-level process and device telemetry | Microsoft Defender for Endpoint connector or integration | Defender for Endpoint provides endpoint detection and response data |
| You need identity sign-in and user risk data | Microsoft Entra ID data connector | Entra ID logs help investigate authentication, Conditional Access, and identity risk |
| You need email threat data such as phishing or malicious attachments | Microsoft Defender for Office 365 / Microsoft 365 connectors | Provides email and collaboration security events |
| You need cloud workload security alerts | Microsoft Defender for Cloud connector | Defender for Cloud provides alerts and posture information for cloud resources |
| You need to visualize trends from ingested logs | Microsoft Sentinel workbooks | Workbooks provide dashboards and visual reporting |
| You need to search for suspicious behavior that has not generated an alert | Hunting query | Hunting is used for proactive investigation |
| You want a query to automatically generate incidents when a pattern is detected | Analytics rule | Analytics rules turn query logic into detections |
| You want to automate triage or response after an incident is created | Automation rule or playbook | Automation rules manage incident-level workflow; playbooks use Logic Apps for deeper automation |
| You have a custom application exporting structured logs | Custom log ingestion | Allows Sentinel to analyze data from internal or line-of-business applications |
KQL Notes
How KQL Fits Into This Topic
This lesson only introduces KQL at a high level. The key point is that KQL is the language analysts use to search and analyze the data brought into Sentinel by data connectors.
KQL can be used in:
- Logs
- Hunting
- Analytics rules
- Workbooks
- Incident investigation
- Entity investigation
- Detection engineering
The table you query depends on the data connector.
For example:
| Data Source | Possible Table Example |
|---|---|
| Microsoft Entra ID sign-ins | SigninLogs |
| Microsoft 365 activity | OfficeActivity |
| Azure control-plane activity | AzureActivity |
| CEF firewall/security logs | CommonSecurityLog |
| Windows security events | SecurityEvent |
| Defender endpoint telemetry | Defender-related advanced hunting tables |
Table names vary depending on connector, configuration, and portal experience.
Simple KQL Example: Reviewing Recent Sign-In Failures
Example only:
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultDescription
| order by TimeGenerated desc
Query Logic
This query searches recent failed sign-ins.
| KQL Line | Purpose |
|---|---|
SigninLogs | Queries Entra ID sign-in data |
where TimeGenerated > ago(24h) | Limits results to the last 24 hours |
where ResultType != 0 | Filters for sign-ins that did not succeed |
project | Selects only the most useful columns |
order by TimeGenerated desc | Shows newest events first |
How This Helps in an Investigation
An analyst could use this query when investigating:
- Password spray activity
- Suspicious sign-in attempts
- Failed logins from unusual IP addresses
- User account compromise attempts
- Conditional Access failures
Exam Relevance
For SC-200, understand that KQL is used to query Sentinel data. You may be asked which operator helps filter results, select columns, aggregate data, or correlate activity.
Important operators to know:
| Operator | Purpose |
|---|---|
where | Filters rows |
project | Selects columns |
extend | Creates calculated fields |
summarize | Aggregates data |
join | Combines data from multiple tables |
order by | Sorts results |
ago() | Defines a relative time window |
parse | Extracts structured values from text |
Common Exam Traps
Confusing Data Connectors with Content Hub
A data connector ingests data.
The Content Hub is a catalog for installing Sentinel solutions and related content.
If the question asks how to bring logs into Sentinel, think data connector.
If the question asks how to install a solution package for a product or workload, think Content Hub.
Forgetting That Sentinel Requires Data Sources
Sentinel cannot detect what it cannot see.
If an exam scenario asks why incidents are not being generated for a specific system, one possible issue is that the correct data connector is not enabled or configured.
Confusing Microsoft Defender XDR and Microsoft Sentinel
Microsoft Defender XDR focuses on Microsoft security product correlation across endpoints, identities, email, apps, and cloud signals.
Microsoft Sentinel is a SIEM/SOAR platform that can ingest Microsoft and non-Microsoft data across the environment.
Use Sentinel when the scenario involves:
- SIEM
- Multi-source log ingestion
- KQL queries against workspace data
- Data connectors
- Content Hub
- Analytics rules
- Workbooks
- Hunting across collected logs
Use Defender XDR when the scenario focuses on:
- Defender incidents
- Endpoint/email/identity/app correlation
- Microsoft 365 Defender investigation
- Advanced hunting across Defender tables
- Built-in Microsoft XDR response actions
Assuming All Connectors Are Free to Use End-to-End
A connector may be available at no cost, but the source product, third-party service, data ingestion, and retention may still have costs.
For real environments and exam scenarios, consider:
- Licensing
- Sentinel ingestion cost
- Data retention cost
- Connector prerequisites
- Required permissions
- Source system configuration
Choosing Manual Upload When an Automated Connector Exists
Manual uploads are possible, but they are usually not the preferred approach for ongoing SOC monitoring.
For production monitoring, automated connectors are usually better because they provide continuous data flow.
Manual methods are more relevant for special cases such as isolated networks, one-time investigations, or air-gapped environments.
Ignoring Syslog and CEF for Third-Party Devices
For firewalls, network devices, and security appliances, syslog and CEF are common ingestion methods.
If the exam describes a non-Microsoft appliance, do not assume there is always a native Microsoft connector. Syslog or CEF may be the appropriate answer.
Overlooking Permissions and Configuration Requirements
Data connectors often require permissions in both Sentinel and the source system.
A user may need rights to:
- Configure Microsoft Sentinel
- Access the Log Analytics workspace
- Enable diagnostic settings
- Read source logs
- Configure API access
- Install agents
- Configure syslog forwarding
- Deploy Content Hub solutions
Real-World SOC Analyst Notes
Data Coverage Drives Detection Quality
A SOC cannot investigate what it cannot see.
Before tuning analytics rules or building advanced hunting queries, verify that the right data sources are connected. Missing connectors can create blind spots.
Examples:
- No Entra ID logs means weak identity investigation.
- No endpoint telemetry means limited malware analysis.
- No firewall logs means poor network visibility.
- No email logs means phishing investigations are incomplete.
- No cloud activity logs means limited Azure control-plane visibility.
Alert Fatigue Starts with Bad Data and Poor Tuning
Connecting every possible data source without planning can create excessive noise and cost.
A good SOC should decide:
- Which logs are required for detection?
- Which logs are required for compliance?
- Which logs are required for investigations?
- Which logs are too noisy?
- Which logs should be retained long term?
- Which alerts need tuning?
More data is not always better if the SOC cannot triage it effectively.
Sentinel Cost Considerations
Microsoft Sentinel costs are heavily influenced by data ingestion and retention.
In real environments, teams should consider:
- Which logs are high-value
- Which logs are high-volume
- Which logs need long retention
- Whether some data should go to basic logs or archive tiers
- Whether verbose logs should be filtered before ingestion
- Whether workbooks and detections justify the ingestion cost
For SC-200, you do not need to be a billing expert, but you should understand that Sentinel ingestion has operational and cost impact.
Evidence Preservation Matters
When investigating incidents, analysts should preserve useful evidence, including:
- Relevant KQL query results
- Alert details
- Incident timeline
- User activity
- Device activity
- IP addresses
- File hashes
- URLs and domains
- Screenshots or exports where appropriate
- Actions taken during containment
This supports escalation, root cause analysis, and post-incident reporting.
Escalation Paths Depend on the Data Source
Different incidents may require different teams.
Examples:
| Incident Type | Likely Escalation Team |
|---|---|
| Suspicious sign-in | Identity / Entra ID team |
| Malware on endpoint | Endpoint / desktop / EDR team |
| Phishing campaign | Email security / messaging team |
| Firewall traffic anomaly | Network security team |
| Azure resource compromise | Cloud operations / cloud security team |
| Custom app logging issue | Application owner / development team |
Sentinel helps centralize the evidence, but remediation often involves multiple teams.
Automation Safety
Automation can save time, but it can also create risk.
Before automating response actions, consider:
- Could this action disrupt users?
- Could it affect production systems?
- Is the detection reliable enough?
- Should the action require approval?
- Should the automation only apply to high-confidence incidents?
- Should it notify a team instead of taking direct action?
- Is change control required?
For example, automatically disabling accounts or isolating devices may be appropriate for high-confidence threats but risky for noisy detections.
Quick Reference Summary
- Microsoft Sentinel uses data connectors to ingest logs and alerts.
- Ingested data is stored in a Log Analytics workspace.
- Sentinel can ingest Microsoft, third-party, cloud, on-premises, syslog, CEF, and custom log data.
- Data ingestion enables analytics rules, incidents, hunting, workbooks, automation, and investigation.
- Normalization helps make different log formats easier to analyze together.
- Content Hub is where Sentinel solutions and content can be discovered and installed.
- A connector brings in data; Content Hub helps deploy packaged content.
- Some connectors are agent-based; others are API-based or agentless.
- Syslog and CEF are common for network appliances and third-party security tools.
- KQL is used to query ingested data for investigation, hunting, and detection.
- Microsoft Sentinel administration may appear in Azure portal and Microsoft Defender portal.
- Missing data connectors create detection blind spots.
- More data can increase cost and noise, so connector planning matters.
- SC-200 scenarios often test tool selection, connector purpose, KQL usage, and Sentinel workflow understanding.
Flashcards
Q: What is a Microsoft Sentinel data connector?
A: A data connector is the mechanism Sentinel uses to connect to a data source and ingest logs or alerts into a Log Analytics workspace.
Q: What is data ingestion in Microsoft Sentinel?
A: Ingestion is the process of bringing log and alert data from connected sources into the Sentinel workspace.
Q: Why is normalization important in Sentinel?
A: Normalization helps make logs from different systems easier to query, correlate, and investigate.
Q: Where is Sentinel data stored after ingestion?
A: In a Log Analytics workspace.
Q: What is the Microsoft Sentinel Content Hub used for?
A: The Content Hub is used to find and install Sentinel solutions, including connectors, analytics rules, workbooks, hunting queries, parsers, and playbooks.
Q: What is the difference between a data connector and the Content Hub?
A: A data connector ingests data; the Content Hub provides installable Sentinel content and solutions.
Q: Which ingestion methods are common for firewalls and network appliances?
A: Syslog and Common Event Format.
Q: What is CEF?
A: CEF stands for Common Event Format, a standardized log format commonly used by security products.
Q: What is KQL used for in Microsoft Sentinel?
A: KQL is used to query log data for investigation, hunting, analytics rules, workbooks, and detection engineering.
Q: Why might an organization use an agent-based connector?
A: Agent-based collection may be needed for servers, legacy systems, syslog sources, or on-premises environments that cannot connect through a native cloud API.
Q: Why might a Sentinel connector require additional cost even if the connector itself is free?
A: The source product may require licensing, and Sentinel ingestion and retention may create Azure costs.
Q: Which portal may be used for Microsoft Sentinel management?
A: Sentinel functionality may appear in the Azure portal and the Microsoft Defender portal, depending on the feature and tenant experience.
Q: What happens if the correct data connector is not enabled?
A: Sentinel may not have visibility into that data source, which can prevent detection, investigation, and correlation.
Q: When would manual log upload be more relevant?
A: Manual upload may be relevant for special cases such as air-gapped, isolated, or highly controlled environments.
Q: Why is connector planning important in a SOC?
A: It determines visibility, detection coverage, investigation quality, alert volume, and ingestion cost.
Practice Questions
Question 1:
A company wants Microsoft Sentinel to detect suspicious activity from its third-party firewall. The firewall supports syslog and Common Event Format. What should the security team configure?
A. Microsoft Defender for Office 365
B. A Sentinel syslog or CEF data connector
C. Microsoft Entra ID Protection
D. A Sentinel workbook only
Correct Answer:
B. A Sentinel syslog or CEF data connector
Explanation:
Firewall and network appliance logs are commonly ingested through syslog or Common Event Format. A workbook can visualize data after ingestion, but it does not bring the firewall logs into Sentinel.
Question 2:
A SOC analyst wants to search Sentinel data for suspicious sign-in failures from the last 24 hours. Which language should the analyst use?
A. PowerShell
B. JSON
C. KQL
D. YAML
Correct Answer:
C. KQL
Explanation:
Kusto Query Language is used in Microsoft Sentinel to query ingested log data for investigation, hunting, analytics rules, and workbooks.
Question 3:
An organization installed Microsoft Sentinel but does not see incidents related to Microsoft 365 activity. What should the analyst verify first?
A. Whether the Microsoft 365 data connector is enabled and configured
B. Whether all users have Global Administrator permissions
C. Whether a workbook has been deleted
D. Whether device isolation is enabled
Correct Answer:
A. Whether the Microsoft 365 data connector is enabled and configured
Explanation:
Sentinel depends on connected data sources. If Microsoft 365 logs are not being ingested, Sentinel cannot use that activity for detection or investigation.
Question 4:
A security engineer wants to deploy a Microsoft Sentinel solution that includes a connector, analytics rules, hunting queries, and a workbook for a specific product. Where should the engineer look?
A. Microsoft Sentinel Content Hub
B. Microsoft Teams Admin Center
C. Microsoft Purview compliance portal
D. Windows Event Viewer
Correct Answer:
A. Microsoft Sentinel Content Hub
Explanation:
The Content Hub provides installable Sentinel solutions and content packages, which may include connectors, analytics rules, hunting queries, workbooks, parsers, playbooks, and other components.
Question 5:
A company has a custom line-of-business application that exports structured logs. The SOC wants to analyze those logs in Sentinel. Which approach is most appropriate?
A. Ignore the application because Sentinel only supports Microsoft logs
B. Use custom log ingestion if the logs can be collected and parsed
C. Use Defender for Office 365 Safe Links
D. Use only Microsoft Secure Score
Correct Answer:
B. Use custom log ingestion if the logs can be collected and parsed
Explanation:
Microsoft Sentinel can ingest data from custom applications if the logs can be collected in a usable structure and parsed appropriately. Sentinel is not limited to Microsoft-native logs.