Deep Security 11 has reached end of support. Use the version selector (above) to see more recent versions of the Help Center.

Define a Log Inspection rule for use in policies

The OSSEC Log Inspection engine is integrated into Deep Security Agents and gives Deep Security the ability to inspect the logs and events generated by the operating system and applications running on the computer. Deep Security Manager ships with a standard set of OSSEC Log Inspection rules that you can assign to computers or policies. You can also create custom rules if there is no existing rule that fits your requirements.

Log Inspection Rules issued by Trend Micro are not editable (although you can duplicate them and then edit them.)

To create Log Inspection rules, perform these basic steps:

• Create a new Log Inspection rule
• Decoders
• Subrules
• Real world examples
• Log Inspection rule severity levels and their recommended use
• strftime() conversion specifiers
• Examine a Log Inspection rule

For an overview of the Log Inspection module, see Analyze logs with log inspection.

Create a new Log Inspection rule

1. In the Deep Security Manager, go to Policies > Common Objects > Rules > Log Inspection Rules.
2. Click New > New Log Inspection Rule.
3. On the General tab, enter a name and an optional description for the rule.

4. The Content tab is where you define the rule. The easiest way to define a rule is to select Basic Rule and use the options provided to define the rule. If you need further customization, you can select Custom (XML) to switch to an XML view of the rule that you are defining.

   Any changes you make in the Custom (XML) view will be lost if you switch back to the Basic Rule view.

   For further assistance in writing your own Log Inspection rules using the XML-based language, consult the OSSEC documentation or contact your support provider.

These options are available for the Basic Rule template:

• Rule ID: The Rule ID is a unique identifier for the rule. OSSEC defines 100000 - 109999 as the space for user-defined rules. Deep Security Manager will pre-populate the field with a new unique Rule ID.
• Level: Assign a level to the rule. Zero (0) means the rule never logs an event, although other rules that watch for this rule may fire.
• Groups: Assign the rule to one or more comma-separated groups. This can be useful when dependency is used because you can create rules that fire on the firing of a rule, or a rule that belongs to a specific group.
• Rule Description: Description of the rule.

• Pattern Matching: This is the pattern the rule will look for in the logs. The rule will be triggered on a match. Pattern matching supports Regular Expressions or simpler String Patterns. The "String Pattern" pattern type is faster than RegEx but it only supports three special operations:

  • ^ (caret): specifies the beginning of text
  • $ (dollar sign): specifies the end of text
  • | (pipe): to create a "OR" between multiple patterns

  For information on the regular expression syntax used by the Log Inspection module, see https://www.ossec.net/docs/syntax/regex.html.

• Dependency: Setting a dependency on another rule will cause your rule to only log an event if the rule specified in this area has also triggered.
• Frequency is the number of times the rule has to match within a specific time frame before the rule is triggered.
• Time Frame is the period of time in seconds within which the rule has to trigger a certain number of times (the frequency, above) to log an event.

1. On the Files tab, type the full path to the file(s) you want your rule to monitor and specify the type of file it is.
2. On the Options tab, in the Alert section, select whether this rule triggers an alert in the Deep Security Manager.

   Alert Minimum Severity sets the minimum severity level that will trigger an Alert for rules made using the Basic Rule or Custom (XML) template.

   The Basic Rule template creates one rule at a time. To write multiple rules in a single template you can use the Custom (XML) template. If you create multiple rules with different Levels within a Custom (XML) template, you can use the Alert Minimum Severity setting to select the minimum severity that will trigger an Alert for all of the rules in that template.
3. The Assigned To tab lists the policies and computers that are using this Log Inspection rule. Because you are creating a new rule, it has not been assigned yet.
4. Click OK. The rule is ready to be assigned to policies and computers.

Decoders

A Log Inspection rule consists of a list of files to monitor for changes and a set of conditions to be met for the rule to trigger. When the Log Inspection engine detects a change in a monitored log file, the change is parsed by a decoder. Decoders parse the raw log entry into the following fields:

• log: the message section of the event
• full_log: the entire event
• location: where the log came from
• hostname: hostname of the vent source
• program_name: Program name. This is taken from the syslog header of the event
• srcip: the source IP address within the event
• dstip: the destination IP address within the event
• srcport: the source port number within the event
• dstport: the destination port number within the event
• protocol: the protocol within the event
• action: the action taken within the event
• srcuser: the originating user within the event
• dstuser: the destination user within the event
• id: any ID decoded as the ID from the event
• status: the decoded status within the event
• command: the command being called within the event
• url: the URL within the event
• data: any additional data extracted from the event
• systemname: the system name within the event

Rules examine this decoded data looking for information that matches the conditions defined in the rule.

If the matches are at a sufficiently high severity level, any of the following actions can be taken:

• An alert can be raised. (Configurable on the Options tab of the Log Inspection Rule's Properties window.)
• The event can be written to syslog. (Configurable in the SIEM area on Administration > System Settings > Event Forwarding tab.)
• The event can be sent to the Deep Security Manager. (Configurable in the Log Inspection Syslog Configuration setting on the Policy or Computer Editor > Settings > Event Forwarding tab.)

Subrules

A single Log Inspection rule can contain multiple subrules. These subrules can be of two types: atomic or composite. An atomic rule evaluates a single event and a composite rule examines multiple events and can evaluate frequency, repetition, and correlation between events.

Groups

Each rule, or grouping of rules, must be defined within a <group></group> element. The attribute name must contain the rules you want to be a part of this group. In the following example we have indicated that our group contains the syslog and sshd rules:

<group name="syslog,sshd,">
</group>

Rules, ID, and Level

A group can contain as many rules as you require. The rules are defined using the <rule></rule> element and must have at least two attributes, the id and the level. The id is a unique identifier for that signature and the level is the severity of the alert. In the following example, we have created two rules, each with a different rule ID and level:

<group name="syslog,sshd,">
	<rule id="100120" level="5">
	</rule>
	<rule id="100121" level="6">
	</rule>
</group>

You can define additional subgroups within the parent group using the <group></group> tag. This subgroup can reference any of the groups listed in the following table:

Group Type	Group Name	Description
Reconnaissance	connection_attempt web_scan recon	Connection attempt Web scan Generic scan
Authentication Control	authentication_success authentication_failed invalid_login login_denied authentication_failures adduser account_changed	Success Failure Invalid Login Denied Multiple Failures User account added User Account changed or removed
Attack/Misuse	automatic_attack exploit_attempt invalid_access spam multiple_spam sql_injection attack virus	Worm (nontargeted attack) Exploit pattern Invalid access Spam Multiple spam messages SQL injection Generic attack Virus detected
Access Control	access_denied access_allowed unknown_resource firewall_drop multiple_drops client_misconfig client_error	Access denied Access allowed Access to nonexistent resource Firewall drop Multiple firewall drops Client misconfiguration Client error
Network Control	new_host ip_spoof	New host detected Possible ARP spoofing
System Monitor	service_start system_error system_shutdown logs_cleared invalid_request promisc policy_changed config_changed low_diskspace time_changed	Service start System error Shutdown Logs cleared Invalid request Interface switched to promiscuous mode Policy changed Configuration changed Low disk space Time changed

Description

Include a <description></description> tag. The description text will appear in the event if the rule is triggered.

<group name="syslog,sshd,">
	<rule id="100120" level="5">
		<group>authentication_success</group>
		<description>SSHD testing authentication success</description>
	</rule>
	<rule id="100121" level="6">
		<description>SSHD rule testing 2</description>
	</rule>
</group>

Decoded As

The <decoded_as></decoded_as> tag instructs the Log Inspection engine to only apply the rule if the specified decoder has decoded the log.

<rule id="100123" level="5">
	<decoded_as>sshd</decoded_as>
	<description>Logging every decoded sshd message</description>
</rule>

Match

To look for a specific string in a log, use the <match></match>. Here is a Linux sshd failed password log:

 Jan 1 12:34:56 linux_server sshd[1231]: Failed password for invalid
	user jsmith from 192.168.1.123 port 1799 ssh2

Use the <match></match> tag to search for the "password failed" string.

<rule id="100124" level="5">
	<decoded_as>sshd</decoded_as>
	<match>^Failed password</match>
	<description>Failed SSHD password attempt</description>
</rule>

The following table lists supported regex syntax:

Regex Syntax	Description
\w	A-Z, a-z, 0-9 single letters and numerals
\d	0-9 single numerals
\s	single space
\t	single tab
\p	()*+,-.:;<=>?[]
\W	not \w
\D	not \d
\S	not \s
\.	anything
+	match one or more of any of the above (for example, \w+, \d+)
*	match zero or more of any of the above (for example, \w*, \d*)
^	indicates the beginning of a string (^somestring)
$	specify the end of a string (somestring$)
|	indicate an "OR" between multiple strings

Conditional Statements

Rule evaluation can be conditional upon other rules having been evaluated as true. The <if_sid></if_sid> tag instructs the Log Inspection engine to only evaluate this subrule if the rule identified in the tag has been evaluated as true. The following example shows three rules: 100123, 100124, and 100125. Rules 100124 and 100125 have been modified to be children of the 100123 rule using the <if_sid></if_sid> tag:

<group name="syslog,sshd,">
	<rule id="100123" level="2">
		<decoded_as>sshd</decoded_as>
		<description>Logging every decoded sshd message</description>
	</rule>
	<rule id="100124" level="7">
		<if_sid>100123</if_sid>
		<match>^Failed password</match>
		<group>authentication_failure</group>
		<description>Failed SSHD password attempt</description>
	</rule>
	<rule id="100125" level="3">
		<if_sid>100123</if_sid>
		<match>^Accepted password</match>
		<group>authentication_success</group>
		<description>Successful SSHD password attempt</description>
	</rule>
</group>

Hierarchy of Evaluation

The <if_sid></if_sid> tag essentially creates a hierarchical set of rules. That is, by including an <if_sid></if_sid> tag in a rule, the rule becomes a child of the rule referenced by the <if_sid></if_sid> tag. Before applying any rules to a log, the Log Inspection engine assesses the <if_sid></if_sid> tags and builds a hierarchy of parent and child rules.

The list of available atomic rule conditional options is shown in the following table:

Tag	Description	Notes
match	A pattern	Any string to match against the event (log).
regex	A regular expression	Any regular expression to match against the event(log).
decoded_as	A string	Any prematched string.
srcip	A source IP address	Any IP address that is decoded as the source IP address. Use "!" to negate the IP address.
dstip	A destination IP address	Any IP address that is decoded as the destination IP address. Use "!" to negate the IP address.
srcport	A source port number	Any source port (match format).
dstport	A destination port number	Any destination port (match format).
user	A username	Any username that is decoded as a username.
program_name	A program name	Any program name that is decoded from the syslog process name.
hostname	A system hostname	Any hostname that is decoded as a syslog hostname.
time	A time range in the format hh:mm - hh:mm or hh:mm am - hh:mm pm	The time range that the event must fall within for the rule to trigger.
weekday	A weekday (sunday, monday, tuesday, etc.)	Day of the week that the event must fall on for the rule to trigger.
id	An ID	Any ID that is decoded from the event.
url	A URL	Any URL that is decoded from the event.

Use the <if_sid>100125</if_sid> tag to make this rule depend on the 100125 rule. This rule will be checked only for sshd messages that already matched the successful login rule.

<rule id="100127" level="10">
	<if_sid>100125</if_sid>
	<time>6 pm - 8:30 am</time>
	<description>Login outside business hours.</description>
	<group>policy_violation</group>
</rule>

Restrictions on the Size of the Log Entry

The following example takes the previous example and adds the maxsize attribute which tells the Log Inspection engine to only evaluate rules that are less than the maxsize number of characters:

<rule id="100127" level="10" maxsize="2000">
	<if_sid>100125</if_sid>
	<time>6 pm - 8:30 am</time>
	<description>Login outside business hours.</description>
	<group>policy_violation</group>
</rule>

The following table lists possible atomic rule tree-based options:

Tag	Description	Notes
if_sid	A rule ID	Adds this rule as a child rule of the rules that match the specified signature ID.
if_group	A group ID	Adds this rule as a child rule of the rules that match the specified group.
if_level	A rule level	Adds this rule as a child rule of the rules that match the specified severity level.
description	A string	A description of the rule.
info	A string	Extra information about the rule.
cve	A CVE number	Any Common Vulnerabilities and Exposures (CVE) number that you would like associated with the rule.
options	alert_by_email no_email_alert no_log	Additional rule options to indicate if the Alert should generate an e-mail, alert_by_email, should not generate an email, no_email_alert, or should not log anything at all, no_log.

Composite Rules

Atomic rules examine single log entries. To correlate multiple entries, you must use composite rules. Composite rules are supposed to match the current log with those already received. Composite rules require two additional options: the frequency option specifies how many times an event or pattern must occur before the rule generates an alert, and the timeframe option tells the Log Inspection engine how far back, in seconds, it should look for previous logs. All composite rules have the following structure:

<rule id="100130" level="10" frequency="x" timeframe="y">
</rule> 

For example, you could create a composite rule that creates a higher severity alert after five failed passwords within a period of 10 minutes. Using the <if_matched_sid></if_matched_sid> tag you can indicate which rule needs to be seen within the desired frequency and timeframe for your new rule to create an alert. In the following example, the frequency attribute is set to trigger when five instances of the event are seen and the timeframe attribute is set to specify the time window as 600 seconds.

The <if_matched_sid></if_matched_sid> tag is used to define which other rule the composite rule will watch:

<rule id="100130" level="10" frequency="5" timeframe="600">
	<if_matched_sid>100124</if_matched_sid>
	<description>5 Failed passwords within 10 minutes</description>
</rule>

There are several additional tags that you can use to create more granular composite rules. These rules, as shown in the following table, allow you to specify that certain parts of the event must be the same. This allows you to tune your composite rules and reduce false positives:

Tag	Description
same_source_ip	Specifies that the source IP address must be the same.
same_dest_ip	Specifies that the destination IP address must be the same.
same_dst_port	Specifies that the destination port must be the same.
same_location	Specifies that the location (hostname or agent name) must be the same.
same_user	Specifies that the decoded username must be the same.
same_id	Specifies that the decoded id must be the same.

If you wanted your composite rule to alert on every authentication failure, instead of a specific rule ID, you could replace the <if_matched_sid></if_matched_sid> tag with the <if_matched_ group></if_matched_ group> tag. This allows you to specify a category, such as authentication_ failure, to search for authentication failures across your entire infrastructure.

<rule id="100130" level="10" frequency="5" timeframe="600">
	<if_matched_group>authentication_failure</if_matched_group>
	<same_source_ip />
	<description>5 Failed passwords within 10 minutes</description>
</rule>

In addition to <if_matched_sid></if_matched_sid> and <if_matched_group></if_matched_ group> tags, you can also use the <if_matched_regex></if_matched_regex> tag to specify a regular expression to search through logs as they are received.

<rule id="100130" level="10" frequency="5" timeframe="600">
	<if_matched_regex>^Failed password</if_matched_regex>
	<same_source_ip />
	<description>5 Failed passwords within 10 minutes</description>
</rule>

Real world examples

Deep Security includes many default Log Inspection rules for dozens of common and popular applications. Through Security Updates, new rules are added regularly. In spite of the growing list of applications supported by Log Inspection rules, you may find the need to create a custom rule for an unsupported or custom application.

In this section we will walk through the creation of a custom CMS (Content Management System) hosted on the Microsoft Windows Server IIS .Net platform with a Microsoft SQL Database as the data repository.

The first step is to identify the following application logging attributes:

1. Where does the application log to?
2. Which Log Inspection decoder can be used to decode the log file?
3. What is the general format of a log file message?

For our custom CMS example the answers are as follows:

1. Windows Event Viewer
2. Windows Event Log (eventlog)
3. Windows Event Log Format with the following core attributes:
   • Source: CMS
   • Category: None
   • Event: <Application Event ID>

The second step is to identify the categories of log events by application feature, and then organize the categories into a hierarchy of cascading groups for inspection. Not all inspected groups need to raise events; a match can be used as a conditional statement. For each group, identify the log format attributes which the rule can use as matching criteria. This can also be performed by inspecting all application logs for patterns and logical groupings of log events.

For example, the CMS application supports the following functional features which we will create Log Inspection rules for:

• CMS Application Log (Source: CMS)
  • Authentication (Event: 100 to 119)
    • User Login successful (Event: 100)
    • User Login unsuccessful (Event: 101)
    • Administrator Login successful (Event: 105)
    • Administrator Login unsuccessful (Event: 106)
  • General Errors (Type: Error)
    • Database error (Event: 200 to 205)
    • Runtime error (Event: 206-249)
  • Application Audit (Type: Information)
    • Content
      • New content added (Event: 450 to 459)
      • Existing content modified (Event: 460 to 469)
      • Existing content deleted (Event: 470 to 479)
    • Administration
      • User
        • New User created (Event: 445 to 446)
        • Existing User deleted (Event: 447 to 449)

This structure will provide you with a good basis for rule creation. Now to create a new Log Inspection rule in Deep Security Manager.

To create the new CMS Log Inspection Rule:

1. In the Deep Security Manager, go to Policies > Common Objects > Rules > Log Inspection Rules and click New to display the New Log Inspection Rule Properties window.
2. Give the new rule a name and a description, and then click the Content tab.
3. The quickest way to create a new custom rule is to start with a basic rule template. Select the Basic Rule radio button.
4. The Rule ID field will be automatically populated with an unused ID number of 100,000 or greater, the IDs reserved for custom rules.
5. Set the Level setting to Low (0).
6. Give the rule an appropriate Group name. In this case, "cms".
7. Provide a short rule description.
   
   
8. Now select the Custom (XML) option. The options you selected for your "Basic" rule will be converted to XML.
   
   
9. Click the Files tab and click the Add File button to add any application log files and log types which the rule will be applied to. In this case, "Application", and "eventlog" as the file type.
   

   

   Eventlog is a unique file type in Deep Security because the location and filename of the log files don't have to be specified. Instead, it is sufficient to type the log name as it is displayed in the Windows Event Viewer. Other log names for the eventlog file type might be "Security", "System", "Internet Explorer", or any other section listed in the Windows Event Viewer. Other file types will require the log file's location and filename. (C/C++ strftime() conversion specifiers are available for matching on filenames. See the table below for a list of some of the more useful ones.)
10. Click OK to save the basic rule.
11. Working with the basic rule Custom (XML) created, we can begin adding new rules to the group based on the log groupings identified previously. We will set the base rule criteria to the initial rule. In the following example, the CMS base rule has identified Windows Event Logs with a Source attribute of "CMS":

    <group name="cms">
    	<rule id="100000" level="0">
    		<category>windows</category>
    		<extra_data>^CMS</extra_data>
    		<description>Windows events from source 'CMS' group messages.</description>
    	</rule>
    

12. Now we build up subsequent rules from the identified log groups. The following example identifies the authentication and login success and failure and logs by Event IDs.

    <rule id="100001" level="0">
    	<if_sid>100000</if_sid>
    	<id>^100|^101|^102|^103|^104|^105|^106|^107|^108|^109|^110</id>
    	<group>authentication</group>
    	<description>CMS Authentication event.</description>
    </rule>
    
    <rule id="100002" level="0">
    	<if_group>authentication</if_group>
    	<id>100</id>
    	<description>CMS User Login success event.</description>
    </rule>
    <rule id="100003" level="4">
    	<if_group>authentication</if_group>
    	<id>101</id>
    	<group>authentication_failure</group>
    	<description>CMS User Login failure event.</description>
    </rule>
    <rule id="100004" level="0">
    	<if_group>authentication</if_group>
    	<id>105</id>
    	<description>CMS Administrator Login success event.</description>
    </rule>
    <rule id="100005" level="4">
    	<if_group>authentication</if_group>
    	<id>106</id>
    	<group>authentication_failure</group>
    	<description>CMS Administrator Login failure event.</description>
    </rule>

13. Now we add any composite or correlation rules using the established rules. The follow example shows a high severity composite rule that is applied to instances where the repeated login failures have occurred 5 times within a 10 second time period:

    <rule id="100006" level="10" frequency="5" timeframe="10">
    	<if_matched_group>authentication_failure</if_matched_group>
    	<description>CMS Repeated Authentication Login failure event.</description>
    </rule>

14. Review all rules for appropriate severity levels. For example, error logs should have a severity of level 5 or higher. Informational rules would have a lower severity.
15. Finally, open the newly created rule, click the Configuration tab and copy your custom rule XML into the rule field. Click Apply or OK to save the change.

Once the rule is assigned to a policy or computer, the Log Inspection engine should begin inspecting the designated log file immediately.

The complete Custom CMS Log Inspection Rule:

<group name="cms">
	<rule id="100000" level="0">
		<category>windows</category>
		<extra_data>^CMS</extra_data>
		<description>Windows events from source 'CMS' group messages.</description>
	</rule>
	<rule id="100001" level="0">
		<if_sid>100000</if_sid>
		<id>^100|^101|^102|^103|^104|^105|^106|^107|^108|^109|^110</id>
		<group>authentication</group>
		<description>CMS Authentication event.</description>
	</rule>

	<rule id="100002" level="0">
		<if_group>authentication</if_group>
		<id>100</id>
		<description>CMS User Login success event.</description>
	</rule>

	<rule id="100003" level="4">
		<if_group>authentication</if_group>
		<id>101</id>
		<group>authentication_failure</group>
		<description>CMS User Login failure event.</description>
	</rule>

	<rule id="100004" level="0">
		<if_group>authentication</if_group>
		<id>105</id>
		<description>CMS Administrator Login success event.</description>
	</rule>

	<rule id="100005" level="4">
		<if_group>authentication</if_group>
		<id>106</id>
		<group>authentication_failure</group>
		<description>CMS Administrator Login failure event.</description>
	</rule>

	<rule id="100006" level="10" frequency="5" timeframe="10">
		<if_matched_group>authentication_failure</if_matched_group>
		<description>CMS Repeated Authentication Login failure event.</description>
	</rule>

	<rule id="100007" level="5">
		<if_sid>100000</if_sid>
		<status>^ERROR</status>
		<description>CMS General error event.</description>
		<group>cms_error</group>
	</rule>

	<rule id="100008" level="10">
		<if_group>cms_error</if_group>
		<id>^200|^201|^202|^203|^204|^205</id>
		<description>CMS Database error event.</description>
	</rule>

	<rule id="100009" level="10">
		<if_group>cms_error</if_group>
		<id>^206|^207|^208|^209|^230|^231|^232|^233|^234|^235|^236|^237|^238|
			^239^|240|^241|^242|^243|^244|^245|^246|^247|^248|^249</id>
		<description>CMS Runtime error event.</description>
	</rule>

	<rule id="100010" level="0">
		<if_sid>100000</if_sid>
		<status>^INFORMATION</status>
		<description>CMS General informational event.</description>
		<group>cms_information</group>
	</rule>

	<rule id="100011" level="5">
		<if_group>cms_information</if_group>
		<id>^450|^451|^452|^453|^454|^455|^456|^457|^458|^459</id>
		<description>CMS New Content added event.</description>
	</rule>

	<rule id="100012" level="5">
		<if_group>cms_information</if_group>
		<id>^460|^461|^462|^463|^464|^465|^466|^467|^468|^469</id>
		<description>CMS Existing Content modified event.</description>
	</rule>

	<rule id="100013" level="5">
		<if_group>cms_information</if_group>
		<id>^470|^471|^472|^473|^474|^475|^476|^477|^478|^479</id>
		<description>CMS Existing Content deleted event.</description>
	</rule>

	<rule id="100014" level="5">
		<if_group>cms_information</if_group>
		<id>^445|^446</id>
		<description>CMS User created event.</description>
	</rule>

	<rule id="100015" level="5">
		<if_group>cms_information</if_group>
		<id>^447|449</id>
		<description>CMS User deleted event.</description>
	</rule>

</group>

Log Inspection rule severity levels and their recommended use

Level	Description	Notes
Level 0	Ignored, no action taken	Primarily used to avoid false positives. These rules are scanned before all the others and include events with no security relevance.
Level 1	no predefined use
Level 2	System low priority notification	System notification or status messages that have no security relevance.
Level 3	Successful or authorized events	Successful login attempts, firewall allow events, etc.
Level 4	System low priority errors	Errors related to bad configurations or unused devices or applications. They have no security relevance and are usually caused by default installations or software testing.
Level 5	User-generated errors	Missed passwords, denied actions, etc. These messages typically have no security relevance.
Level 6	Low relevance attacks	Indicate a worm or a virus that provide no threat to the system such as a Windows worm attacking a Linux server. They also include frequently triggered IDS events and common error events.
Level 7	no predefined use
Level 8	no predefined use
Level 9	Error from invalid source	Include attempts to login as an unknown user or from an invalid source. The message might have security relevance especially if repeated. They also include errors regarding the admin or root account.
Level 10	Multiple user generated errors	Include multiple bad passwords, multiple failed logins, etc. They might indicate an attack, or it might be just that a user forgot his or her credentials.
Level 11	no predefined use
Level 12	High-importance event	Include error or warning messages from the system, kernel, etc. They might indicate an attack against a specific application.
Level 13	Unusual error (high importance)	Common attack patterns such as a buffer overflow attempt, a larger than normal syslog message, or a larger than normal URL string.
Level 14	High importance security event	Typically the result of the correlation of multiple attack rules and indicative of an attack.
Level 15	Attack Successful	Very small chance of false positive. Immediate attention is necessary.

strftime() conversion specifiers

Specifier	Description
%a	Abbreviated weekday name (e.g., Thu)
%A	Full weekday name (e.g., Thursday)
%b	Abbreviated month name (e.g., Aug)
%B	Full month name (e.g., August)
%c	Date and time representation (e.g., Thu Sep 22 12:23:45 2007)
%d	Day of the month (01 - 31) (e.g., 20)
%H	Hour in 24 h format (00 - 23) (e.g., 13)
%I	Hour in 12 h format (01 - 12) (e.g., 02)
%j	Day of the year (001 - 366) (e.g., 235)
%m	Month as a decimal number (01 - 12) (e.g., 02)
%M	Minute (00 - 59) (e.g., 12)
%p	AM or PM designation (e.g., AM)
%S	Second (00 - 61) (e.g., 55)
%U	Week number with the first Sunday as the first day of week one (00 - 53) (e.g., 52)
%w	Weekday as a decimal number with Sunday as 0 (0 - 6) (e.g., 2)
%W	Week number with the first Monday as the first day of week one (00 - 53) (e.g., 21)
%x	Date representation (e.g., 02/24/79)
%X	Time representation (e.g., 04:12:51)
%y	Year, last two digits (00 - 99) (e.g., 76)
%Y	Year (e.g., 2008)
%Z	Time zone name or abbreviation (e.g., EST)
%%	A % sign (e.g., %)

More information can be found at the following websites:

https://www.php.net/manual/en/function.strftime.php
www.cplusplus.com/reference/clibrary/ctime/strftime.html

Examine a Log Inspection rule

Log Inspection rules are found in the Deep Security Manager at Policies > Common Objects > Rules > Log Inspection Rules.

Log Inspection rule structure and the event matching process

This screen shot displays the contents of the Configuration tab of the Properties window of the "Microsoft Exchange" Log Inspection rule:

Here is the structure of the rule:

• 3800 - Grouping of Exchange Rules - Ignore
  • 3801 - Email rcpt is not valid (invalid account) - Medium (4)
    • 3851 - Multiple email attempts to an invalid account - High (9)
      • Frequency - 10
      • Time Frame - 120
      • Ignore - 120
  • 3802 - Email 500 error code - Medium (4)
    • 3852 - Email 500 error code (spam) - High (9)
      • Frequency - 12
      • Time Frame - 120
      • Ignore - 240

The Log Inspection engine will apply log events to this structure and see if a match occurs. For example, if an Exchange event occurs, and this event is an email receipt to an invalid account, the event will match line 3800 (because it is an Exchange event). The event will then be applied to line 3800's sub-rules: 3801 and 3802.

If there is no further match, this "cascade" of matches will stop at 3800. Because 3800 has a severity level of "Ignore", no Log Inspection event would be recorded.

However, an email receipt to an invalid account does match one of 3800's sub-rules: sub-rule 3801. Sub-rule 3801 has a severity level of "Medium(4)". If the matching stopped here, a Log Inspection event with a severity level of "Medium(4)" would be recorded.

But there is still another sub-rule to be applied to the event: sub-rule 3851. Sub-rule 3851 with its three attributes will match if the same event has occurred 10 times within the last 120 seconds. If so, a Log Inspection event with a severity "High(9)" is recorded. (The "Ignore" attribute tells sub-rule 3851 to ignore individual events that match sub-rule 3801 for the next 120 seconds. This is useful for reducing "noise".)

Assuming the parameters of sub-rule 3851 have been matched, a Log Inspection event with Severity "High(9)" is now recorded.

Looking at the Options tab of the Microsoft Exchange Rule, we see that Deep Security Manager will raise an alert if any sub-rules with a severity level of "Medium(4)" have been matched. Since this is the case in our example, the alert will be raised (if "Alert when this rule logs an event" is selected).

Duplicate Sub-rules

Some Log Inspection rules have duplicate sub-rules. To see an example, open the "Microsoft Windows Events" rule and click on the Configuration tab. Note that sub-rule 18125 (Remote access login failure) appears under sub-rules 18102 and 18103. Also note that in both cases sub-rule 18125 does not have a severity value, it only says "See Below".

Instead of being listed twice, Rule 18125 is listed once at the bottom of the Configuration page: