Cisco Cisco Firepower Management Center 4000

Page of 1844
 
32-38
FireSIGHT System User Guide
 
Chapter 32      Understanding and Writing Intrusion Rules 
  Understanding Keywords and Arguments in Rules
You can use the 
metadata
 keyword to add descriptive information to a rule. You can use the information 
you add to organize or identify rules in ways that suit your needs, and to search for rules.
The system validates metadata based on the format:
key value
where 
key
 and 
value
 provide a combined description separated by a space.
This is the format used by the Cisco Vulnerability Research Team (VRT) for adding metadata to rules 
provided by Cisco. 
Alternatively, you can also use the format:
key=value
For example, you could use the 
key value
 format to identify rules by author and date, using a category 
and sub-category as follows:
author SnortGuru_20050406
You can use multiple 
metadata
 keywords in a rule. You can also use commas to separate multiple 
key value
 statements in a single 
metadata
 keyword, as seen in the following example:
author SnortGuru_20050406, revised_by SnortUser1_20050707,
 
revised_by SnortUser2_20061003, revised_by
 
SnortUser1_20070123
You are not limited to using a 
key value
 or 
key=value
 format; however, you should be aware of 
limitations resulting from validation based on these formats.
Avoiding Restricted Characters
License: 
Protection
Note the following character restrictions:
  •
Do not use a semicolon (;) or colon (:) in a 
metadata
 keyword.
  •
Be aware when using commas that the system interprets a comma as a separator for multiple 
key value
 or 
key=value
 statements. For example:
key value, key value, key value
  •
Be aware when using the equal to (=) character or space character that the system interprets these 
characters as separators between 
key
 and 
value
. For example:
key value
key=value
All other characters are permitted.
Adding service Metadata
License: 
Protection
The rules engine applies active rules with 
service
 metadata that match the application protocol 
information for the host in a packet to analyze and process traffic. If it does not match, the system does 
not apply the rule to the traffic. If a host does not have application protocol information, or if the rule 
does not have 
service
 metadata, the system checks the port in the traffic against the port in the rule to 
determine whether to apply the rule to the traffic.
The following diagram illustrates matching a rule to traffic based on application information: