Purple Team

Organizations who invest in detection engineering have an edge towards identification of threats. However, there is no industry standard to define the framework around the development of detection rules and every organization use their own approach according to their threat landscape and internal resource capability available.

There is an industry misconception that the responsibility of detection rule development relies only in the detection engineering team or the blue team. A collaborative approach can aid towards the development of rules which are not only effective but also aligned with the threat actors that the business is most likely to face. Threat Intelligence can feed the detection engineering team with TTP (Tactics, Techniques, Procedures) trends from recent APT (Advanced Persistence Threat) campaigns which can enable detection engineering teams to prioritize alerts. From the other hand, the Red Team (internal or external) can validate through testing the detection rule and also provide insights on detection logic. Therefore applying a working together culture can assist detection engineering teams to build effective and reliable detection’s.

Palantir, Incident Response Team has created and open sourced the Alerting and Detection Strategy Framework. The framework has been utilized also by blue teams and even though it hasn’t been updated for years it covers important components. However, a standardized approach needs to be adopted by the information security industry that will assist organizations to understand the drivers behind rule development and to ensure maturity over time in the detection engineering space.

iPurpleTeam, has developed the following framework considering various components that are required to safeguard that rules will be developed in an threat aligned and reliable manner.

Rule Objective

The rule objective should define what kind of behavior the rule will attempt to detect.

Source

Detection engineers should expand their sources of information by utilizing Threat Intelligence feeds or by receiving direct input from the Threat Intelligence team, use lessons learnt from past incidents such as rules which have failed to detect a threat and require tuning or from Red Team reports. Identification of the source can assist to identify in which category the rule will fall, for example proactive defense if the root source is threat intelligence or remediation if the source is a red team report. Typically, rules correlated with remediation should be prioritized, even though detection rule development should be balanced between remediation and pro-activeness to achieve best results. Specifically, the source must contain one of these three components:

• Threat Intelligence
• Red Team
• Incidents

Categorization

The rule should be categorized according to the ATT&CK framework.

Tactic	Technique	Procedure	MITRE ID

Detection Strategy

In 2020, Jared Atkinson discussed in an article the capability abstraction and how this model can be leveraged by detection engineers to understand technique indicators at different layers in order to create robust detection’s. This model can be part of the detection strategy to identify the necessary indicators of the technique and what data sources are required when building the detection logic.

Rule Development Process

Prior to any rule development it is critical to understand what are the log sources available and the rule type. As every organization is different and the technology stack and active directory configuration might vary it is necessary to identify the data sources that will be part of the overall detection strategy. It is important to highlight that not all the rules serve the same purpose. Some might be signature based with a focus for example to identify a specific tool, behavioral if the objective is the detection of a particular TTP or could be classified as rules that will attempt to detect an anomaly i.e. PowerShell is executed from a Word document.

Priority

Rules should be classified based on the impact to the asset or to the domain. For example a detection rule which can identify lateral movement or arbitrary code execution has highest priority compare to a rule which is deployed to identify host or active directory enumeration. The priority level criteria are defined as:

• Critical
• High
• Medium
• Low

Validation

Detection rules should be validated ideally by an independent team such as the Red Team. The detection engineering team and the Red Team in alignment should coordinate and schedule a date which the rule under development will be tested for it’s validity. Each alert must have a true positive validation and the Red Team should attempt not only to trigger the alert but also to define a detailed methodology that will attempt to evade that specific rule. Validation should cover multiple tests in order to fully assess the confidence level of the alert. Rules should be validated in a controlled environment and also in Production.

Deficiencies

During the rule validation stage any deficiencies should be recorded. The number of deficiencies should determine the reliability of the detection rule and the confidence rating. Even if the rule has defects during initial deployment, identification of what the rule cannot detect will determine the scope of the next review in order to increase the rule efficiency.

Deficiencies	Status	Comments
<Insert Deficiency>	Yes/No	<Insert Comment>

Deployment and Integration

Validated rules should be deployed into the associated SIEM and integrated with other security technologies which are part of the network. The rule should be scheduled to run at regular time intervals with detailed reporting and response procedures.

Maintenance and Improvement

Rules should not be static. A number of techniques even the old ones from time time are changing and might introduce different evasion points. Rules should be aligned with any new developments of the behavior which are trying to detect. Detection rules should be also measured for their efficiency by following a true positive vs false positive ratio. A review process at a scheduled date will provide assurance that the rule is still current and effective and there are no changes to the behavior which the rule attempts to detect that will require the rule to be adjusted. During the review process it is critical that threat intelligence and red team insights are also considered so the rule can be aligned with the current threat as even common TTP’s might change from time time at a procedure level.

Confidence Level

Rules should be measure for their efficiency. If a rule for example detects a specific sub-technique but there are logs which cannot be enabled due to performance reasons that will increase the visibility and therefore the rule efficiency the confidence level should drop. The following levels could be used to measure confidence:

• Strong
• Fair
• Low

Response

When the alert is triggered it is important for the SOC analysts that will respond to the alert to have clear response steps. Outline what the response procedures will be, will enable all team members to familiarize themselves of what their response would look like to that particular alert, the severity of the alert and the triage that will occur.

Resources

A detection rule must be supplemented with publicly disclosed resources that will assist detection engineers to gather further insights about the particular threat which the rule target to detect.

Templates

Every organisation might approach the same topic differently according to their maturity level and threat landscape. However, for these organizations which will utilize the Detection Rules Development Framework the following templates can be used to supplement the activities described in the article:

• Detection Rules Development Framework – .md format
• Detection Rules Development Framework – .docx format