My First Rule

ELASTIC detection rule by Elastic · Elastic License v2

This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat activity.

[metadata]
creation_date = "2022/09/22"
maturity = "production"
updated_date = "2025/01/15"

[rule]
author = ["Elastic"]
description = """
This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat
activity.
"""
enabled = false
false_positives = [
    "This rule is not looking for threat activity. Disable the rule if you're already familiar with alerts.",
]
from = "now-35m"
index = ["auditbeat-*", "filebeat-*", "logs-*", "winlogbeat-*"]
interval = "30m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1
name = "My First Rule"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating My First Rule
Elastic Security leverages event data to monitor and alert on potential security incidents. The "My First Rule" is a foundational rule designed for onboarding, focusing on event data without indicating a specific threat. Adversaries might exploit event logging to obscure their tracks or trigger false alerts. This rule helps analysts familiarize themselves with event-based alerts, ensuring they can identify and respond to genuine threats effectively.

### Possible investigation steps

- Review the event data associated with the alert to understand the context and source of the event.kind:event.
- Check the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time.
- Identify the host or user associated with the event to assess if there is any unusual or unauthorized activity.
- Examine related logs or events from the same source to identify any patterns or anomalies that could indicate suspicious behavior.
- Consult with team members or use internal resources to determine if the event is part of normal operations or if it requires further investigation.

### False positive analysis

- Routine system events can trigger alerts, as the rule monitors all event data without filtering for specific threats.
- Identify and document common non-threatening events that frequently trigger alerts, such as regular system updates or scheduled tasks.
- Use exceptions to exclude these documented non-threatening events from triggering alerts, reducing noise and focusing on genuine threats.
- Regularly review and update the list of exceptions to ensure it remains relevant and does not inadvertently exclude new potential threats.
- Collaborate with IT and operations teams to understand normal event patterns and adjust the rule's exceptions accordingly.

### Response and remediation

- Verify the legitimacy of the event by cross-referencing with known benign activities or scheduled tasks to rule out false positives.
- Contain any potential threat by isolating affected systems or accounts if suspicious activity is confirmed, preventing further unauthorized access or damage.
- Remediate by reviewing and adjusting logging configurations to ensure accurate event capture and reduce the risk of adversaries exploiting logging mechanisms.
- Escalate the incident to the appropriate security team or management if the event correlates with other suspicious activities or if it indicates a potential breach.
- Enhance detection capabilities by updating alerting rules to include additional context or indicators observed during the investigation, ensuring better identification of similar threats in the future.

This is a test alert.

This alert does not show threat activity. Elastic created this alert to help you understand how alerts work.

For normal rules, the Investigation Guide will help analysts investigate alerts.

This alert will show once every 24 hours for each host. It is safe to disable this rule.
"""
references = ["https://www.elastic.co/guide/en/security/current/prebuilt-rules.html"]
risk_score = 21
rule_id = "a198fbbd-9413-45ec-a269-47ae4ccf59ce"
severity = "low"
tags = ["Use Case: Guided Onboarding", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
event.kind:event
'''



[rule.threshold]
field = ["host.name"]
value = 1

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

c77dbc9f-d45c-4cae-ae1e-79219559d270

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion