The following is a summary of our detection and correlation rule lifecycle, describing how new rules are conceived, built, tuned, and validated. Additionally, rules are contributed from the open-source community and are validated by Armor as well as additional third parties prior to being included in our rule library.
Anatomy of a Detection Rule
To properly convey the lifecycle of our detection rules, it’s first important to understand the differences between the detection and correlation data models, and the data shaping models that underpin our rule library. Our detection capabilities are based on 3 major components:
- Schemas – a standardized event model for each type of event; there are both product-specific schemas and generic schemas, with generic schemas being extensible by other schemas.
- Parsers – a set of queries or code routines that extracts values from raw logs and shapes them into a structured data object matching the corresponding schema definition.
- Rules – a query that reads schema-conformant data to detect specific actions that are indicators of attack or indicators of compromise; similar to schemas, these may be product-specific or generic rules with generic rules being applicable to any log source that conforms to its schema.
Anatomy of a Correlation Rule
Correlation rules are similar in form to detection rules but serve a separate purpose. Correlation rules identify patterns between disparate instances of a given event or set of events. For example, where a detection rule may create a medium-severity incident for several successive failed login attempts that may indicate a brute force attack, a correlation rule might look for brute force indicators followed by a successful login and subsequent suspicious behavior.
In the genericized example above, while detection rule A and detection rule B may not be sufficient in isolation to raise an incident, correlation of the two alerts together, in sequence, or otherwise related, or in combination with additional enrichment data, we can produce an incident with a high level of confidence that it is a true positive. Correlation rules needn’t necessarily include outputs from multiple detection rules and may also be used simply to enrich an event. This drastically reduces the compute requirements for enrichment-based correlation while delivering equivalent security outcomes.
Armor Rule Library
All Armor XDR subscription levels include access to the Armor Rule Library which, as described above, contains a curated list of rules that provides broad, in-depth coverage of a majority of attack vectors. You can view its coverage using our MITRE ATT&CK Navigator tool that we’ve customized to include our pre-built layers.
This library primarily consists of data stored in the Sigma format and is translated into artifacts for platform-specific Terraform consumption using automated CI/CD jobs.
Custom Rules
At the Professional and Enterprise subscription levels, customers may request Armor build custom rules for specific use cases not covered by the Armor Rule Library. You can do so by submitting a Rule Request in the Armor Support Portal.
All customers have direct access to their cloud-native SIEM platform and can at any time leverage the schema, parser, and deployment automation work that Armor has deployed to your environment and build their own custom rules.
Rule Tuning & Deselection
Detection and correlations rules are tuned and maintained using the techniques described in this article. This section defines in greater detail the process of deselection of a rule for an individual organization, as well as the retirement of rules.
In cases where rules are no longer applicable (e.g. an application or device is removed from the environment and the log sources on which a rule relies are no longer sending telemetry, etc.) a rule (or its containing rule pack) can be removed from the environment by removing it from the rules.hcl or packs.hcl file in the provided Terraform code. This process can be managed by either the customer or by Armor.
In cases where rules in the Armor rule library are superseded by newer rules or are determined to no longer be relevant, they are first deprecated in a patch release and subsequently removed in the next major release. Removal of rules from the library should be coordinated with the deselection of rules as described above.