Understanding Tactical Detection and Detection Engineering | TryHackMe Intro to Detection Engineering

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.

Full blog post is here.

Blue Team Cyber Security & SOC Analyst Study Notes

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

1. Sigma
2. YARA
3. Snort/Suricata
4. 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.

1. Requirements Gathering
2. Design
3. Development
4. Testing and Deployment
5. Monitoring
6. 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 & Tactical Detection

Room answers can be found here.

Video Walkthrough