In this post , we covered an introduction to tactical detection where we used sigma rules to build unified detection rules used across SIEM solutions. We also covered detection engineering, types of detection engineering in threat intelligence and detection engineering frameworks. We covered also the answers for TryHackMe Intro to detection engineering room and TryHackMe Tactical Detection Room.
Definition of detection engineering in threat intelligence
Detection engineering is the continuous process of building and operating threat intelligence analytics to identify potentially malicious activity or misconfigurations that may affect your environment. It requires a cultural shift with the alignment of all security teams and management to build effective threat-rich defence systems.
Detection Engineering Frameworks
- MITRE ATT&CK – The foundational framework of adversary tactics, techniques, and procedures based on real-world observations.
- Alerting and Detection Strategies (ADS) Framework | Palantir – A blueprint for creating and documenting effective detection content.
- Detection Engineering Maturity Matrix | Kyle Bailey – A detailed matrix that serves as a tool to measure the overall maturity of an organization’s Detection Engineering program.
- Detection Maturity Level (DML) Model | Ryan Stillions – Defines and describes 8 different levels of an organization’s threat detection program maturity.
- The Pyramid of Pain | David J Bianco – A model used to describe various categorizations of indicator’s of compromise and their level of effectiveness in detecting threat actors.
- Cyber Kill Chain | Lockheed Martin – Lockheed Martin’s framework that outlines the 7 stages commonly observed in a cyber attack.
- MaGMa (Management, Growth and Metrics & Assessment) Use Case Defintion Model – A business-centric approach for defining threat detection use cases.
- Synthetic Adversarial Log Objects (SALO) | Splunk – Synthetic Adversarial Log Objects (SALO) is a framework for the generation of log events without the need for infrastructure or actions to initiate the event that causes a log event.
- The Zen of Security Rules | Justin Ibarra – Outlines 19 aphorisms that serve as universal principles for the creation of high quality detection content.
Detection Engineering Tools
- Sigma
- YARA
- Snort/Suricata
- SIEM
What are sigma rules and what is the rule of Sigma in detection engineering?
Sigma is an open-source generic signature language developed to describe log events in a structured format. This allows for quick sharing of detection methods by security analysts.
For the expression of detection logic for various logs, the Sigma syntax offers a straightforward and potent framework. Proxy logs, Windows events, application logs, firewall logs, cloud events, Linux audit logs, and many other log types can have rules written for them by Sigma.
Sigma offers the vocabulary required to spell out detection logic and incorporate metadata useful for delving into warnings produced by your rules. Sigma helps you to better arrange and distribute detection rules you write to colleagues and threat intelligence networks.
Sigma’s most potent feature is that it was made to work with any search and detection software you already own. Sigma rules can be converted into Elastic, Splunk, Arcsight, Carbon Black, Graylog, NetWitness, Humio, Crowdstrike, Elastalert, and numerous other free and commercial formats using the Sigma converter tool. Vendor lock-in is avoided and you may utilize your detection logic for searches in your investigations, as a foundation for threat hunting inquiries, and across other detection systems by saving your rules in Sigma syntax.
Detection Engineering Lifecycle
Developers of successful programs follow the Software Development Lifecycle (SDLC), but what about detection engineers? Threat actor spotting and halting security teams should give much thought to how they develop and maintain detection logic. In the alternative, low quality detections, alert fatigue from false positives, and more attacks going unnoticed until after the breach blows out would all result.
Leading security teams’ detection engineers are implementing Detection-as-Code into the “Detection Development Lifecycle.” For any threat detection program, this is an essential element, and it entails having a clear procedure for creating and maintaining detections. We discussed the Detection Development Lifecycle in our prior post on the Threat Detection Maturity Framework, and since it is so important, we wanted to share our Snowflake approach.
Threat actors are becoming more and more well-funded, extremely skilled, and always innovating to take advantage of new technologies and paradigms like cloud and serverless computing, so threat detection teams will never be able to create detections for every conceivable adversary strategy. To guarantee high fidelity, successful defenders therefore require a repeatable method for building detections with risk and intelligence-based prioritizing, as well as ongoing monitoring and testing. These procedures are divided macro-level into two categories: detection creation and detection maintenance.
- Requirements Gathering
- Design
- Development
- Testing and Deployment
- Monitoring
- Continuous Testing
Detection Engineering Workflow
- Starting with the design, or building, of a workflow based on the internal architecture that may be followed is crucial for the convenience of operationalizing the current activities. Amazing workflows that may be used as a guide to create bespoke workflows based on internal environment include the SIEM Use Cases Development Workflow by Alex Teixeira and the Detection-as-Code from RSA Conference. The provisioning, development, testing, distribution, deployment, and upkeep of detecting material in the production are made easier by the processes.
- The team’s present maturity level with regard to People, Process, and Technology—the three pillars of cybersecurity—will be clarified by Kyle Bailey’s Detection Engineering Maturity Matrix, which will also guide future discussions on where and how to allocate time, money, and effort to advance the program to the “Optimized State.”
- This can be shared with response teams for review and input. The Alerting and Detection Strategies (ADS) Framework by Team Palantir assists with the granular documentation template that can be referred to create a custom template according to internal needs/requirements for documenting about the created detections and response workflows. Note: The Blue Team Funnel part below discusses the frameworks and knowledge-bases.)
- Organize a detection lab for testing and development; running the tests on specialized hosts or virtual machines impedes teamwork. As part of testings that assist us to be informed of the security gaps, detection coverage, and other security tool coverage, this should be as near to the true production environment with all the security tools stack installed. It should also contain defensive and offensive tools. Atomic tests, opponent simulations, and purple teaming exercises are all possible in the labs.
- Team SpecterOps has developed several concepts, including the Funnel of Fidelity, Capability Abstraction, Detection Spectrum, and Detection-in-Depth, which facilitate our efficient and effective rule creation by enabling us to comprehend about the different abstraction layers and fine-tuning of the detections to have high-fidelity along with broadest coverage possible.
Room Answers | TryHackMe Intro to detection engineering
Which detection type focuses on misalignments within the current infrastructure?
Configuration
Which detection approach involves building an asset or activity baseline profile for detection?
Modelling
Which type of detection integrates with defensive playbooks?
Threat Behaviour
In total, how many requWhich framework looks at how to make it difficult for an adversary to change their approach when detected?
pyramid of pain
What is the improved Cyber Kill Chain framework called?
The Unified kill chain
How many phases are in the improved kill chain?
18
What is the flag?
THM{Sup3r-D3t3ct1v3}
Room Answers| TryHackMe Tactical Detection
What did we use to transform IOCs as detection rules in a vendor-agnostic format?
sigma
What is the original indicator found by the authors of the documentation? Write it as written in the spreadsheet.
bad3xe69connection.io
What is the full file path of the malicious file downloaded from the internet?
C:\Downloads\bad3xe69.exe
In the Sigma Rule baddomains.yml, what is the logsource category used by the author?
proxy
Upon translating the Follina Sigma Rule, what is the index name that the rule will be using, as shown in the output?
winlogbeat-*
What is the Alerter subclass, as shown in the output?
debug
Change the Uncoder output to Elastic Stack Query (Lucene).
Which part of the ElastAlert output looks exactly like the Elastic Query?
filter
Translate the Log4j Sigma Rule into a Splunk Alert (SPL).
What is the alert severity, as shown in the output?
3
What is the dispatch.earliest_time value, as shown in the output?
-60m@m
Change the Uncoder output to Splunk Query (SPL).
What is the source, as shown in the output?
WinEventLog:*
The FullEventLogView application comes installed on your Windows machine. Use it for the following questions.
What is the “Accesses” value in the log details when you try reading our Secret Document’s contents via cmd?
ReadData (or ListDirectory)
Event ID 4663 is always preceded by?
4656
What Event ID signifies the closure of an “object”?
4658
Event ID 4658 helps determine how long a specific object was open. What description field will you check in between events to be able to do so?
Handle ID
Fill in the Blanks: The Tempest and Follina rooms are examples of leveraging ______ ____ tactics.
purple team
What CVE is the Follina MSDT room about?
Answer Format: CVE-XXXX-XXXXX
CVE-2022-30190
Video Walkthrough
