Signature Metadata

Wiki
1

Metadata Tag Use Cases:

Metadata tags in the ET ruleset provide useful information for network security operators around the purpose, classification, and context of given signatures. There are two primary use cases for Metadata tags in signatures:

  1. Policy Crafting: You can leverage the metadata in ET rules to help select what rules that you want to include in your IDS policy. This can also be used to determine the action for given rules in IPS use cases where you might want to drop some rules while only alerting on others. For instance, by using Metadata tags, you could select all rules which have Critical ‘Severity’ and are Perimeter ‘Deployment’ to be set to Drop–this is possible with the signature metadata by writing scripts to filter on rules that have the appropriate tags and setting the rules. You can write your own scripts or use a tool like Suricata-Update, Pulled-Pork, or Oinkmaster to perform these actions.

  2. Event Enrichment: Metadata from rules can be included in the event messages generated by Suricata 4.1+ when an IDS rule is triggered. This means that the tag information can be loaded into IDS events that are sent to a logging system so you can perform event filtering within that tool. This can be very useful for threat hunting, grouping, and correlation, where otherwise, without metadata, this information would not be known by the logging system.

Metadata Tags Breakdown

Attack Target: The Attack Target is the intended target of an attack that the signature is detecting. Because signatures are directional, the signature may be from Client to Server or Server to Client; however, the attack target is the intended victim system. Possible values can include:

Client Endpoint, Server Endpoint, IOT, Mobile_Client, Network_Equipment, Web_Server, SQL_Server, SMTP_Server, SMB_Server, SMB_Client, or Client_and_Server.

Signature Deployment: The signature deployment tag identifies where the signature is designed to be effectively deployed. As IDS systems can be deployed in numerous different locations in a network, the Signature Deployment tag helps to identify how the signature should be deployed to reduce the likelihood of FP’s and FN’s. Possible values include:

  • Perimeter: Signature should be placed between Internal Clients and External Servers
  • Datacenter: Signature should be placed between External Clients and Internal/DMZ Servers
  • alert_only: alert_only indicates this rule should not be put into IPS mode. Some rules are designed to be informative and traffic matching them should not be blocked. For example, a rule indicating the use of APT package manager. This generally indicates an Debian based machine on the network. Some networks have Debian/Ubuntu computer, others don’t. Either way, this rule is designed simply to bring awareness to the traffic occurring over the network and not designed to detect anything malicious. As such, it’d be a good candidate to have the “alert_only” deployment tag on it.
  • Internal: Signature should monitor East/West traffic within an organization to detect lateral movement
  • Internet: Signature should be placed for detection on the internet, but not used internally due to FP’s
  • SSLDecrypt: This tag is used to identify signatures that require SSL Decryption to properly match in production networks as activity has only been observed within encrypted traffic where TLS/SSL decryption is required

Signature Severity: The Signature Severity identifies the threat level of the activity being detected. We classify the following signature severities:

  • Info: This is a signature meant to detect activity which may not be malicious in and of itself, but useful to record as part of an audit trail. It is often associated with other malicious activity or undesirable behavior
  • Minor: Minor signatures are often associated with reconnaissance, scanning, and other profiling activities. It may not directly indicate something malicious but often precedes malicious activity.
  • Major: Major signatures indicate an active attempt at compromise of a service or end system.
  • Critical: Critical means that an end system is likely to be compromised based on the activity detected in these signatures. This is the highest severity level.

Performance Impact: Performance Impact is meant to be an indicator of the computational / contextual cost of a signature. While individual signatures do not have a linear performance impact due to optimizations in the compilation phase, and the performance is ultimately dependent on the traffic, this field helps give some guidance as to the detection complexity.

  • Low: Signature matches in an inexpensive buffer, has efficient patterns to match, and is not subject to significant quantities of data.
  • Moderate: Signature has a combination of matching in a more expensive buffer, has more complicated patterns to match, is hard to anchor to a solid fast pattern, or matches on larger quantities of data.
  • Significant: Signature is likely to have a complicated pattern to match, weak anchoring, supplemental PCRE, and is likely to match on more expensive/quantitative buffers of data.
  • Unknown: The performance has not been quantified for this signature.

Affected Products: Affected Products are a list of software that is affected by the attack that this signature is detecting. The tag is the product which is impacted by the activity the signature is trying to detect.

Confidence - a percentage measure of the likelihood of a TP: 0-33% being low, 33%-66% being medium, and 66%+ being high

Deprecation Reason: -The reason why a rule has been disabled or changed state

  • Duplicate - it’s been found this rule is a duplicate of a previous rule
  • False Positive - Multiple customers have reported FPs for this rule
  • Performance - This rule has been found to perform inadequately in production
  • Age - The logic in this rule has been superseded by later rules
  • Relevance - Investigation has found this rule’s targeted behavior is no longer relevant
  • Moved to Open - this ETPRO rule has been moved to ET Open

Malware Families: Malware Families define if one or more family of malware has been observed with the signature. Some signatures may be focused on detecting individual malware family strains, while others may be observed across multiple families (e.g. when behavioral techniques are used), while some signatures may not be associated with a given malware family

Target: Where relevant, specify which side of the alert is the target of the attack

  • src_ip
  • dest_IP

Create Date: This is an automatically generated field that identifies the date when the signature was originally created.

Update Date: This is an automatically generated field that identifies the date when a signature was last modified. Note that this date (as well as the revision) is only incremented when the rule content is modified, it is not modified when rule metadata is changed.

Tags: The Tags field is used to hold any additional tags which do not fit into

MITRE Tags: There are four tags which can be used to identify the MITRE metadata.

  • MITRE Tactic ID: This is the MITRE supplied ID for a given Tactic, e.g. TA0043
  • MITRE Tactic Name: This is the longform name that is supplied by MITRE associated with the Tactic ID: E.g. Reconnaissance
  • MITRE Technique ID: This is the MITRE supplied ID for a given Technique, e.g. T1593
  • MITRE Technique Name: This is the longform name that is supplied by MITRE associated with the Technique ID: E.g. Search_Open_Websites

tls_state: This metadata tag describes the nature of traffic against which this signature will be effective. (or ineffective) As such, tls_state was introduced to better reflect the different TLS scenarios that apply to a signature

  • plaintext: This signature fires on traffic which has not been observed encrypted.

  • TLSDecrypt: This tag is used to identify signatures that require SSL Decryption to properly match in production networks as activity has only been observed within encrypted traffic where TLS/SSL decryption is required. TLS traffic must be decrypted for this alert to be effective. Example: malware has been observed sending stolen credentials via an HTTP Post via Discord API. Discord API requires TLS to be used, and therefor, this rule requires TLS Decryption

  • TLSEncrypt: TLS Handshake is included. This signature will be effective against encrypted traffic. As such, his signature uses the SNI value (or certificate details) of an TLS connection to alert on traffic for an observed c2 server. As TLS Decryption commonly removes all TLS headers, this signature requires the traffic to be not decrypted to ensure it fires correctly

Non-Metadata Rule Fields

Ruleset: The Ruleset is either ETPro, ET (for ET Open), or GPL for signatures provided from the GPL list.

Category: Category is both a descriptor for the activity to group like rules with like rules based on the type of activity, as well as how signatures are separated into distinct rule files.

Former Category: If a rule is moved between two categories, the Former Category will be updated with the original category. This is important for both when a rule is moved to the Deleted file and when rules are moved to new categories.

Classtype: Classtype provides a field to provide additional summarized context for a signature which is not only in the signature itself, but is also recorded in log messages.

CVE Reference / References: References identify external tags which can be used to map the signature to other types of activity.

Rev: Rev identifies the iteration the signature is on. This number increments each time the signature text is modified, but is not impacted by metadata changes.

SID: Auto-generated field which uniquely identifies a signature. The ET Open range is 2,000,000 – 2,400,000, while ETPro is 2,800,000 to 2,999,999

Description: This field is not available in the rule files but is available in the SID-Description.json/SID-Description-ETOpen.json file in the ruleset download directory. This is a longform description created by the threat research team.

NOTE:

You may see older rules that are missing certain metadata tags that you would typically expect to see. This is usually due to the implementation of a metadata tag being more recent than the rule that is missing the tag. In certain scenarios, depending on what the metadata tag is attempting to describe, back porting values for that tag may be quite difficult and to avoid causing further confusion or littering the ruleset with inaccurate metadata, we opt to not backport metadata values for those tags until we have a reliable and viable solution to do so.