As we delve deeper into this discussion, it becomes evident that my passion revolves around the intricacies of developing detection or rule generation for various SIEM tools. Crafting these rules is akin to solving a complex puzzle; each piece meticulously placed, yet unlike a finished puzzle, the work with detection rules is never truly complete. The initial creation of the rule might cover a good portion of the desired outcome, leaving ample room for refinement and enhancement. This ongoing challenge is what captivates me—it requires the engagement of cognitive abilities that are often left untapped, and importantly, these rules serve as the frontline defense against evolving cyber threats.
In the progression of this article, I aim to highlight two pivotal areas:
With over a decade of experience in building detection rules, my journey began with ArcSight, transitioned through Splunk, and most recently, has evolved within the realm of Chronicle using YARA-L. Initially, the prospect of learning the syntax and in turn writing these rules to safeguard an organization was daunting. The quest for perfection in each rule—minimal false positives and maximal fidelity—was not only time-consuming but gradually became an overwhelming pursuit. However, with time, I've gravitated towards the principle of simplicity. Adopting AI based platforms that achieve a great portion of the rule, allows for subsequent enhancements without getting bogged down in the minutiae. In this context, I personally lean towards solutions that provide efficiency and simplicity, such as the latest AI features.
In my recent endeavors, I've leveraged natural language queries within the Chronicle SIEM, coupled with AI, to transform these queries into actionable detection capabilities. This approach has significantly reduced the time investment from several days to just a few hours, a pace that could be further accelerated with more defined objectives. I selected a mix of straightforward cases and more sophisticated scenarios to demonstrate this methodology.
Let us embark on this journey.
Step 1 - Run a search in natural language and click generate query.
Built-in AI component brings back this UDM query:
metadata.vendor_name = "Palo Alto Networks" AND (metadata.product_name = "NGFW" OR metadata.product_name = "PAN-OS") AND (target.port = 80 OR target.port = 443) AND network.direction = "OUTBOUND" AND network.sent_bytes > 1000000000
Upon consolidating my findings and conducting a thorough review, I identify an opportune moment to devise a rule targeting data exfiltration or anomalous outbound traffic.
Step 2: Click Generate Rule
Step 3: Open in Editor and Save.
IMPORTANT NOTE:
The subsequent steps involve implementing this rule, activating its alerting mechanism, and then undertaking either a retrospective hunt or executing a test to evaluate the outcomes generated. This process yields invaluable insights, enabling me to refine and enhance the initial rule—which, at its inception, effectively addresses a good portion of the intended scope. It’s like magic.
Identifies unusually large outbound data transfers: The rule specifically focuses on transfers of over 1000 MB (1,000,000,000 bytes) occurring on common web ports (80 and 443) from within your network.
Potential Data Exfiltration Detection: While large transfers can be legitimate, this rule is designed to raise a flag for potential unauthorized data movement out of your environment.
How It Works:
The rule gathers the following information from triggered events:
The simple $e condition means that the rule generates an alert whenever all the event criteria are met.
Security Use Cases
Important Considerations:
Potential Enhancements
Another simple query in natural language. In years past, I would need to have a log source with the key value pairs to identify and trigger these rules. With AI, I almost don’t need to know anything about UDM, I can just ask.
Detects Bitcoin Mining Activity on AWS EC2 Instances: This rule is designed to specifically identify the "cryptocurrency:EC2/bitcointool.b" event type, which is indicative of Bitcoin mining within your AWS environment.
How It Works
The rule will trigger an alert if all the following conditions are met:
When triggered, the rule gathers and presents the following information:
The simple $e condition means the rule alerts whenever all the event criteria are met.
Security Use Cases
Important Considerations
Let's Talk Enhancements!
Here are some ways to improve this rule:
Correlation: Can you correlate with other event types (high CPU usage, unexpected network connections) to gain more confidence in the alert?
Known Miner Pools: Create an event trigger if the target_ip or target_hostname matches a known mining pool.
With the rule we will attempt to have our handy friend deliver information on, when and if, the cloudsqladmin account is used for Postgres SQL Databases within GCP. Again, we will follow the steps from Rule 1 and apply to each rule accordingly.
Detects Potential SQL Injection Attempts on GCP PostgreSQL Databases: This rule focuses on attempts to use the 'cloudsqladmin' utility to execute SQL commands. Since this utility has elevated privileges, it's a prime target for attackers attempting to manipulate your database.
How It Works
The rule will trigger an alert if all the following conditions are met:
When triggered, the rule collects and exposes the following information:
The simple $e condition means an alert is generated whenever the event criteria are matched.
Security Use Cases
Important Considerations
Potential Enhancements
Let's Strengthen Your Defenses!
To customize this rule, let's discuss:
Attack History: Have you seen past SQL injection attempts targeting your GCP databases?
Admin Workflows: How often do legitimate admins use 'cloudsqladmin' for database management?
Monitoring Allowed Traffic to Networks: The rule is designed to alert whenever network traffic is explicitly allowed to specific Autonomous System Numbers (ASNs) and IP addresses known to be associated with a known bad actor.
Emphasis on Detection: The rule's primary goal is to flag the allowed traffic, not to block it.
How It Works
The rule will trigger an alert if both of the following conditions are met:
When triggered, the rule gathers the following information:
The simple $e condition means an alert is generated whenever the event criteria are matched.
Potential Use Cases
Important Considerations
Let's Talk Customization
To make this rule more effective, consider:
As this exploration demonstrates, the integration of natural language queries with AI-powered tools like Chronicle's AI holds the potential to revolutionize the way we create and implement detection rules. By streamlining a process that was once labor-intensive, security teams can regain precious time, enabling a proactive posture against a dynamic threat landscape. Remember there’s ALWAYS room for improvement with your detection capabilities, regular reviews and constant upkeep will keep your operations the most protected. These were merely examples and could be used but would need to be modified to fit your environment and infrastructure.
Of course, technology is only one facet of a robust defense strategy. It remains crucial to understand the specific risks to your organization, tailoring rules to address those threats most effectively. Remember that rule creation is an iterative process. With AI assisting the initial steps, we can dedicate more focus to refining these rules for maximum impact.
I hope these examples spark inspiration and illustrate the vast potential within the realm of AI-assisted rule generation. I welcome any discussions on how to further optimize these concepts within your own security environment. Together, let's continue to push the boundaries of security innovation!