Table of Contents
These queries help in automating the detection of potential threats by running at specified intervals, which enables a more proactive approach to security monitoring.
To begin, log into the Azure portal and select the Azure Sentinel service. Inside Azure Sentinel, identify and select the workspace in which you want to configure the scheduled query.
Once in the Azure Sentinel dashboard, navigate to ‘Configuration’ and select ‘Analytics’. Here you’ll find a list of existing rules, and the option to create new ones. For built-in scheduled queries, look for templates or existing rules that allow you to schedule a query:
When creating or editing a rule, you’ll need to define the query that will run on schedule. Use the Kusto Query Language (KQL) to define the query criteria. Below this, you’ll set the logic for the rule, such as:
Example of a KQL scheduled query to detect potential brute force login attempts:
SigninLogs
| where TimeGenerated > ago(1h)
| summarize Count = count() by UserPrincipalName, IPAddress
| where Count > 100
Determine the conditions that will trigger a security incident or an alert. This can be based on:
You’ll then configure how incidents are created and managed, such as:
Azure Sentinel allows you to set an automated response to a triggered alert. This can range from sending a notification email to invoking a Logic App for more complex workflows.
Finally, review the settings for the scheduled query rule. If everything is configured correctly, click ‘Create’ or ‘Apply’ to save the rule.
Example of an Alert Rule Summary:
Field | Value |
---|---|
Name | Brute Force Detection |
Description | Detects multiple failed login attempts |
Severity | High |
Query Frequency | Every 5 minutes |
Query Period | Last 6 hours |
Trigger Threshold | Alert if count > 100 |
Incident Grouping | Group by UserPrincipalName and IPAddress |
By configuring built-in scheduled queries, Security Operations Analysts can ensure their systems automatically check for suspicious activity and are alerted in real-time, increasing the chances of catching and mitigating threats before they escalate.
In summary, configuring built-in scheduled queries requires accessing the appropriate security service (e.g., Azure Sentinel), defining the query and rule logic, setting the trigger threshold, and determining the response strategy. Doing so effectively will streamline the security monitoring process, allowing analysts to focus their efforts on resolving and investigating critical threats.
Answer: False
Explanation: Scheduled queries in Microsoft Sentinel can be configured to run at various intervals, not just once a day. They are highly customizable regarding how often they execute.
Answer: Data export policy
Explanation: While query definition, trigger condition, and query name are essential components of a scheduled query, a data export policy is not a required component for configuring scheduled queries in Microsoft Sentinel.
Answer: Every 5 minutes
Explanation: The scheduled queries in Microsoft Sentinel can be run as frequently as every 5 minutes, allowing for near real-time monitoring.
Answer: True
Explanation: Scheduled queries can be configured to trigger playbooks when certain conditions are met, enabling automated responses to specific events or alerts.
Answer: Low, Medium, High
Explanation: In Microsoft Sentinel, you can assign Low, Medium, or High severity levels to the alerts generated by scheduled queries. Informational is not a default severity level option for alerts in Microsoft Sentinel.
Answer: To the incident page within Microsoft Sentinel
Explanation: The results of a triggered scheduled query typically appear on the incidents page within Microsoft Sentinel to be reviewed and actioned by security analysts.
Answer: False
Explanation: Scheduled queries can be created not only via the Azure portal but also using other interfaces such as PowerShell and Microsoft Sentinel APIs.
Answer: To temporally prevent alerts from firing if they’ve recently been triggered
Explanation: The suppression setting is used to reduce alert fatigue by temporarily preventing alerts from firing if the same alert has recently been triggered.
Answer: False
Explanation: While Microsoft Sentinel allows for retrospective analysis, it is not practical to analyze data for the past year with every execution of a scheduled query due to performance and cost considerations. The period of query execution usually covers a much shorter time frame.
Answer: Both A and B
Explanation: When configuring a scheduled query, it is essential to consider both the logic of the query to capture the right events and the response actions to take when a query is triggered, such as playbooks or incident creation.
Answer: To periodically run detection logic against log data and create alerts or incidents
Explanation: Scheduled query rule analytics in Microsoft Sentinel is designed to run detection logic on a schedule and generate alerts or incidents based on the findings, which helps in proactive threat detection and response.
Answer: True
Explanation: Microsoft Sentinel supports cross-workspace queries, which means scheduled queries can be set up to gather and analyze data from multiple workspaces.
If this material is helpful, please leave a comment and support us to continue.