Enhancing LCE Report Performance
Enhancing LCE Report Performance February 4, 2015 (Revision 3) Table of Contents Introduction ............................................................................................................................................................... 3 Decreasing LCE Query Times ............................................................................................................................... 3 Leveraging Event Rules ............................................................................................................................................................................... 3 General Event Rules Format ................................................................................................................................. 3 What to Ignore? ............................................................................................................................................................................................. 4 Lab Analysis Scenario ............................................................................................................................................ 4 Configuration.................................................................................................................................................................................................. 4 Type Analysis of Lab Events ...................................................................................................................................................................... 5 What can be Ignored? .................................................................................................................................................................................. 6 Small University Analysis .................................................................................................................................. 12 Large University Analysis ................................................................................................................................... 15 E-commerce Company Analysis ....................................................................................................................... 20 For More Information ........................................................................................................................................... 24 About Tenable Network Security ...................................................................................................................... 25 Appendix 1: Event Rules Table ........................................................................................................................... 26 Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 2 Introduction Systems generate quite a lot of log data; while some of it is useful, other information may be extraneous. With a little analysis and testing, it is possible to reduce the amount of logs collected by Log Correlation Engine™ (LCE) by 25% to 45% so you can focus on the data that matters. This document describes four examples of configuration files for four different environments, where each LCE ignored over 25% of the events. Tuning LCE’s Event Rules file has tremendous advantages: shorter query times slightly faster events per second less need for more LCEs less data stored for archiving larger amounts of time can be stored faster text searches This document describes how to create Event Rules settings that dramatically decrease the amount of events logged to disk, and includes strategies and examples for log filtering. This document does not focus on maximizing events per second. For that type of information, please refer to the “Tuning for Performance” section in the “Log Correlation Engine 4.4 High Availability and Large Scale Deployment Guide”. Decreasing LCE Query Times Depending on a particular environment, there are several ways to decrease the amount of time to perform a LCE query. Among the more traditional methods are: Add more LCEs to the environment Run LCE with more CPU and memory, but mostly a faster disk Run a virtualized LCE in a higher performance environment (faster disk, CPU and memory) and also a faster network Limit what you log (do I really need NetFlow, etc.?) Leveraging Event Rules The Event Rules can be configured to cause a set of events to be ignored and not logged to disk. The Event Rules section can be located in the LCE GUI under Configuration, Advanced, Event Rules. This has certain performance advantages: The text is not analyzed for log storage, reducing the variety and complexity of logged patterns Events that are ignored are not there when performing queries, thus reducing query time This strategy complements a customer who is storing all of their logs in a product such as Splunk, while still letting them take advantage of full correlation and reporting. It also provides additional performance for a customer who isn’t willing to spend more money on additional hardware or LCE licenses. General Event Rules Format A typical Event Rules entry specifies a set of IP address, sensor, user, type, event name and other details that are to be ignored. For example: Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 3 Events that are ignored are dropped and not logged. It is not possible to review dropped events once they are filtered. The Event Rules box can be resized by selecting and dragging the lower right corner of the window. What to Ignore? From a threat and risk point of view, certain event types do not necessarily need to be logged. For example, logins and login failures help to track potentially malicious activity. However, while logins and login failures may be valuable, logouts may not be needed since they double the amount of tracked authorization logs. In addition, certain events may generate multiple normalized logs for the same event, which is known as coalescing. For efficiency, if only one log per event needs to be kept, it is possible to select only that one event type and ignore the other logs related to that event. In addition, certain IP addresses can be safely ignored. For example, it may not be important that Windows Firewall denies traffic from the broadcast address of 255.255.255.255. Cutting down on logging traffic from certain IP addresses for these types of events can cut down on storage requirements and improve the efficiency of LCE queries. Lab Analysis Scenario The following section describes the lab environment used for event analysis, including the configuration Configuration The following configuration was used for the analysis described in this document: 6 computers Traffic from 4 home users (PVS &TNM) including 8 mobile devices, Xbox, FIOS, etc. Active botnet scanning Daily scanning Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 4 865,000 events in 24 hours Type Analysis of Lab Events The breakdown in event “types” on the example lab network was: 865,000 events 675,000 events for connections, firewall, logouts, network, process, and system 6 specific event types constituted 78% of the total events Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 5 What can be Ignored? The bulk of the events shown in the screenshot above are the approximately 204,000 “Windows_Permitted_Outbound_Connection” event type. To determine which IP addresses were related to these “connection” events, the IP Summary tool can be used to show a list of the IP addresses with the highest related counts: As shown above, the IP address of 239.255.255.250, which is associated with the UPnP service, accounts for almost 96,000 events. In addition, the 255.255.255.255 broadcast address relates to over 12,700 events. Sorting by the “firewall” event type and then selecting the IP Summary tool also shows almost 122,000 combined events that may possibly be ignored when tuning LCE: Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 6 As shown in the screenshot above, the 255.255.255.255 broadcast address accounts for over 122,000 events where the type is “firewall” where the normalized event contains “Windows”. While the “logout” event type may help determine how long an attacker or insider had access to a particular system, if LCE is configured to log process execution, it would likely be more useful to know which processes were executed and the times at which a user executed them. For many environments, the “logout” event type can be safely ignored if process execution is being logged. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 7 In the lab environment used for this example, network traffic was fairly evenly distributed. Over 13,000 internal ICMP traffic events were logged; in this case, it would be easier to ignore these events through the Tenable Network Monitor (TNM) using a libpcap rule (see the filter-expression option description in the LCE 4.2 Client Guide under the Tenable Network Monitor section) than ignoring the events through LCE. The “process” event type will often include many events that can be filtered and ignored, depending on the environment being observed. In the screenshot below, many of the issued commands from Linux systems were generated by process accounting of two CentOS systems running SecurityCenter, Nessus, PVS, and LCE. While these events are somewhat difficult to filter efficiently, events such as “Windows-Process_Exited” can often safely be ignored because they will have a corresponding entry in “Windows-New_Process_Created”. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 8 Based on the Event Rules used by LCE below, we can see that about 258,000 events out of the total of about 865,000 events have been filtered out. With little effort, 30% of the overall events have been ignored, allowing the user to focus on the 70% of events that may have an impact on their environment. In environments where Linux and/or Unix systems communicate with each other on a frequent basis, additional filtering may include events such as “Linux-Audit_Crypto_Key_User”, where SSH is used to communicate between systems. In the example Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 9 below, two systems running Tenable’s SecurityCenter and LCE generated about 34,000 events, which can easily be filtered and ignored: Similarly, scheduled vulnerability scans can easily be identified by the time of day or night at which they occur. Nessus scans scheduled for midnight can create network traffic spikes to help identify which events can be filtered. The two screenshots below show a Nessus scan schedule for midnight, and then the events generated from the IP address of the Nessus scanner (192.168.1.40): Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 10 Many unmatched events will also be identified and may be able to be filtered. While it may be an option to ignore the “unmatched” event type along with a corresponding IP address, it may be more efficient to deselect the “Store Unnormalized Logs” option in the “Configuration”, “Advanced”, “Storage” section of the LCE GUI, as long as there is no valid reason to retain any of the events from those logs. By adding these event types to LCE’s Event Rules (including scans from Tenable’s Nessus Enterprise Cloud), we now see that a total of 343,000 out of 865,000 events have been ignored, which removes about 39% of the total event base. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 11 Small University Analysis Using a small university network for LCE analysis also yielded interesting results. The university utilizes PVS and Tenable Network Monitor (TNM) to observe the activity of about 5,000 computers and systems, which are also scanned weekly with Nessus. Using SecurityCenter and LCE, about 238,000 events were gathered over a 24-hour period; sorting with the “Type Summary” tool, we can see which types of events were the most prevalent on the network. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 12 Sorting the “Type Summary” tool by “Count” (as shown above) requires SecurityCenter 4.7 or higher. In the screenshot above, the “network”, “detected-change”, “process”, “login-failure”, and “dns” event types combine for a significant percentage of the overall events observed. Drilling down into the “network” event type shows the specific types of events that occurred in the 24-hour period: Even though the PVS detects the BitTorrent protocol as a potential vulnerability, from a risk prioritization standpoint in a university setting, these events can be fully ignored. The “PVS-Windows_RDP_Session_Started” event indicates Internetbased malware and botnet connections, and should be kept for more detailed review. Likewise, the two SSH-related events should be kept because, despite being somewhat redundant, cover two different parts of the SSH protocol. “Detected-change” events can also be filtered to remove specific types that are not necessarily important when prioritizing risk. As shown below, the “PVS-Outbound_External_Connections” and “PVS-New_Port_Browsing” event types are somewhat redundant to each other; one logs the external nature of a new browse event, while the other logs new ports observed while browsing. Since much of this traffic occurs on ports higher than TCP 1024 and TNM is in use on the network, it would be safe to ignore both of these event types. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 13 The “process” and “login-failure” event types could be filtered, but it would be recommended to not ignore these events because login failures and process accounting will be valuable during the incident response process. Appending rules for the above to the LCE Event Rules allows us to ignore about 70,000 events out of the total of 238,000, or about 29%. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 14 Large University Analysis A larger university setting poses a different set of challenges and requirements for LCE tuning. One example of a larger university positioned LCE Clients across 20 servers with heavy logging enabled. In one sampled 24-hour period, about 9.2 million events were generated by all systems being observed. Viewing the “Type Summary” shows the breakdown of the majority of the events. As shown above, the largest percentage of the 9.2 million events were generated from the “system”, “login”, “logout”, “accessdenied”, “process”, “login-failure”, and “detected-change” event types. Looking into each event type individually will show which specific events could be filtered from the overall results. The “system” event type contains the largest number of events, some of which may be filtered and ignored. The “WindowsObject_Operation” and “”Windows-Operation_Performed_On_Object” are somewhat difficult to use; they only log the object ID and not the actual object, such as an actual file name, and can be considered for exclusion since thousands of events per second may be generated from these events. However, sometimes the fact that a specific user accessed an object would be reason enough to keep the “Windows-Object_Open” event and not filter it from the overall results. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 15 The “login” event type also generates a large number of events across a network, but not all of these are directly from user logins, and most of the specific login types can prove to be extremely useful. As shown below, the “WindowsCredential_Validation” event is used primarily for internal systems. For this event, almost 718,000 of this type of event were generated on one machine. In this particular case, it would be recommended to filter and ignore these events; while this event type may contain some sort of privilege escalation, there are plenty of other Windows logs that can be used to identify a potentially malicious user. “Logout” events are also included for logging in this large university setting, but can be safely ignored. As mentioned previously in this paper, when object access and process accounting are enabled, the importance of logout information is secondary to the actual actions taken by a user. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 16 The intent of the “access-denied” event type is to look for any type of connection to a resource on an operating system for which the connection is denied. One example would be to log the action of a user who clicked on a network share to which they did not have access. In practice, there are often differences in the access control lists (ACLs) between Windows servers, so the types of items that are denied may vary. Much like logout events, “access-denied” events may not be as useful as process accounting and object access logs, should those be enabled. In a larger university setting, logging all “process” events may prove to be extremely cumbersome. In many cases, it would be recommended to ignore the “Windows-Process_Exited” event, as the vast majority of these events will be redundant with “Windows-New_Process_Created” events. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 17 Similarly, many “login-failure” events can also be excluded. “Pre-authentication failed” events are generally part of Windows protocols used to leverage established trust relations and sessions, and because systems will generate these types of events almost continuously, they will usually provide little value across the overall log set. For the events shown in the screenshot below, it would be recommended to exclude the “Windows-Pre-authentication_Failed” and “WindowsKerberos_Preauthentication_Failed” events: Still using the large university setting as an example, some of the “detected-change” events found could be excluded depending on other types of logging that may be enabled. This particular site generated about 113,000 events in which a user’s IP address changed. Since logs are always tagged with the username after these events occur, the information would technically not be needed since individual user accounts can be searched for across all logs. While keeping user IP address change logs may be useful in some scenarios, running a User Summary would be sufficient to filter for user activity (shown in the second screenshot below): Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 18 In the screenshot above, it is shown that only two user accounts made up for the bulk of the “user-IP-change” events. For this example, we would choose to filter out these events to prevent additional overhead. After updating LCE’s Event Rules with the changes already mentioned, over 4.2 million out of the 9.2 million events would be excluded, resulting in a 45% drop in the amount of logs handled by the LCE. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 19 E-commerce Company Analysis A company with a primary focus on e-commerce will clearly have different logging needs than small or large universities. One particular e-commerce company with heavy internet traffic was used as a case study; it deployed PVS and TNM to monitor network traffic across the network and through its firewall. Over 1,000 network devices were present, as well as thousands of desktops, workstations, and servers deployed across its architecture. In addition to this, email traffic was generated by about 10,000 users. Monitored by six LCEs, over 74.7 million events were recorded over a 24-hour period. Some event types exceeded over 1 million events logged, with several more in the range of 100,000 to 1 million events. Looking at the Type Summary in the screenshot below, certain types can be excluded for better efficiency in log and event monitoring. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 20 For this company, the “connection” event type was the most prevalent. The logging of Fortigate generated over 1.7 million events, of which just over half were “Fortigate_TCP_Connection_Timeout” events. In general, the TCP, UDP, and ICMP connection events would be kept, and the connection timeout events would be removed due to network coverage by PVS and TNM. While there may be a system attempting to communicate to another system outside the company, logging just that one event type could constitute over 10% of the overall event total. The “process” event type, a very large number of Windows, Linux, and Unix events were recorded, and not many (if any) of these events should be filtered. It should be noted that the organization does not log Windows process exit commands, so filtering this event type would not be very helpful. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 21 In the screenshot below, the event type of “intrusion” is largely triggered from the company’s Snort IDS. For this reason, the top 4 events shown are fairly useless; combined, these account for about 9.5 million events, which is well over 10% of the overall traffic. It would be recommended to add these events to LCE’s Event Rules for exclusion, and if a blanket filter was not possible for a specific event, another option would be to filter these types of alerts with a corresponding IP CIDR filter in LCE. The “network” event type also picked up numerous Snort protocol decode message events, such as TCP resets in the middle of a stream. Coming in at about 3.7 million events in a 24-hour period, it would be recommended to filter this event type to ignore the events. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 22 Events of the “firewall” type should be noted. With over 4 million blocked firewall events, there may be some ports that may not be of interest for logging. In the second screenshot below, ports 80 (HTTP) and 31300 (LCE Client) may be subject to exclusion depending on the sources or causes of the logging (such as a misconfigured LCE Client). The “Port Summary” tool helps to determine which ports are being logged and will help in the investigation of these types of events. Other events observed in the company’s environment were 1.2 million “logout” events and 633,000 LinuxAudit_Crypto_Key_User events. Both of these event types were also safe to ignore in this environment. Once the exclusions were identified and added to the company’s LCEs’ Event Rules, over 23.7 million of the total of 74.7 million events were ignored, equaling 32% of the overall log set. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 23 For More Information Tenable has produced a variety of documents detailing the LCE’s deployment, configuration, user operation, and overall testing. These documents are listed here: Log Correlation Engine 4.2 Architecture Guide – provides a high-level view of LCE architecture and supported platforms/environments. Log Correlation Engine 4.4 Administrator and User Guide – describes installation, configuration, and operation of the LCE. Log Correlation Engine 4.4 Quick Start Guide – provides basic instructions to quickly install and configure an LCE server. A more detailed description of configuration and management of an LCE server is provided in the “LCE Administration and User Guide” document. Log Correlation Engine 4.4 Client Guide – how to configure, operate, and manage the various Linux, Unix, Windows, NetFlow, and other clients. Log Correlation Engine 4.4 OPSEC Client Guide – how to configure, operate, and manage the OPSEC Client. LCE 4.4 High Availability Large Scale Deployment Guide – details various configuration methods, architecture examples, and hardware specifications for performance and high availability of large scale deployments of Tenable’s Log Correlation Engine (LCE). LCE Best Practices – Learn how to best leverage the Log Correlation Engine in your enterprise. Tenable Event Correlation – outlines various methods of event correlation provided by Tenable products and describes the type of information leveraged by the correlation, and how this can be used to monitor security and compliance on enterprise networks. Tenable Products Plugin Families – provides a description and summary of the plugin families for Nessus, Log Correlation Engine, and the Passive Vulnerability Scanner. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 24 Log Correlation Engine Log Normalization Guide – explanation of the LCE’s log parsing syntax with extensive examples of log parsing and manipulating the LCE’s .prm libraries. Log Correlation Engine TASL Reference Guide – explanation of the Tenable Application Scripting Language with extensive examples of a variety of correlation rules. Log Correlation Engine 4.0 Statistics Daemon Guide – configuration, operation, and theory of the LCE’s statistic daemon used to discover behavioral anomalies. Log Correlation Engine 3.6 Large Disk Array Install Guide – configuration, operation, and theory for using the LCE in large disk array environments. Example Custom LCE Log Parsing - Minecraft Server Logs – describes how to create a custom log parser using Minecraft as an example. Documentation is also available for Nessus, the Passive Vulnerability Scanner, and SecurityCenter through the Tenable Support Portal located at https://support.tenable.com/. There are also some relevant postings at Tenable’s blog located at http://www.tenable.com/blog and at the Tenable Discussion Forums located at https://discussions.nessus.org/community/lce. For further information, please contact Tenable at [email protected], [email protected], or visit our web site at http://www.tenable.com/. About Tenable Network Security Tenable Network Security provides continuous network monitoring to identify vulnerabilities, reduce risk and ensure compliance. Our family of products includes SecurityCenter Continuous View™, which provides the most comprehensive and integrated view of network health, and Nessus®, the global standard in detecting and assessing network data. Tenable is relied upon by more than 20,000 organizations, including the entire U.S. Department of Defense and many of the world’s largest companies and governments. For more information, visit tenable.com. Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 25 Appendix 1: Event Rules Table The following table contains all of the filter types that can be used for a rule. Each rule created must contain one or more filters, start with a “Name”, and end with either “ignore”, “Command”, or a log source. If “Command” is used, an action must be given. If the filter is matched, the “Command” will execute. Entering “ignore” at the end of the filter will ignore all events that are matched by that filter. If a log source is used, it can be either be “cef” or “syslog”, and if the rule is matched the log will be forwarded to the log server in either “cef” or “syslog” format. See each example in the table below for additional details. Filters Description Usage IPS Filter on source or destination IP address or CIDR. Name: Ignore local logins +Types: login +IPs: 127.0.0.1 ignore Examples: 192.168.1.1, 192.168.0.0/16 SrcIPS Filter strictly on source IP address. Examples: 192.168.1.1, 192.168.0.0/16 DstIPS Filter strictly on destination IP address. Examples: 192.168.1.1, 192.168.0.0/16 Events Filter on LCE normalized event name. Example: Cisco-IDS_Command_Execution Sensors Filter on sensor name, available in the LCE sensor summary view or specified in the syslog_sensors.txt file. Example: XPmarketing01, Win7payroll02 Types Filter on LCE event type. Example: login, lce, intrusion, scanning, system Ports Filter on the source or destination port. Example: 80, 443, 8080 Protocols Filter on the protocol of the event. Example: 1 for ICMP, 2 for IGMP, 6 for TCP, 17 for UDP Name: Ignore local login failures +Types: login-failure +SrcIPs: 127.0.0.1 ignore Name: Ignore local file access +Types: file-access +DstIPs: 127.0.0.1 ignore Name: Ignore Application Changes +Events: Application_Change +IPs: 192.168.1.0/24 ignore Name: Ignore Application Changes +Events: Application_Change +IPs: 192.168.1.0/24 +Sensors: Exchange-10 ignore Name: Ignore local file access and system +Types: file-access, system +IPs: 127.0.0.1 ignore Name: Ignore lce / login events on port 22 +IPS: 192.168.1.1 +Types: lce,login +Ports: 22 ignore Name: Ignore DNS Query +Event: PVS-DNS_Client_Query +IPS: 192.168.1.0/24 +Protocols: UDP +Ports: 53 ignore Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 26 Users Filter on the username in a log. Example: Bob, Phil, Dan Text Filter on any text token in the log (tokens can include spaces and punctuation, but not commas). Name: Ignore System login +IPS: 192.168.1.0/24 +Types: login +Users: SYSTEM ignore Name: Ignore 404 errors +IPS: 192.168.1.0/24 +Text:404 page not found ignore Example: Login, Failure IText Filter on any text token in the log, but the text considered would be case insensitive (tokens can include spaces and punctuation, but not commas). Name: Ignore 404 errors +IPS: 192.168.1.0/24 +IText:404 page not found ignore Example: Login, Failure Vulnerable “yes” or “no” – yes if you want to only match logs that correlate to vulnerable hosts. Example: “yes”, or “no” Threshold The number of events required over a specified length of time to trigger the rule. The timeframe can be expressed in “second”, “minute”, “hour”, “day”, “week”, “month”, or “year”. Example: 5 in a minute MaxQueue The number of events that will be placed into the event processing queue before being dropped from rule evaluation. Example: 100 Name: E-mail vulnerability correlations Vulnerable: yes Command: echo “body: $log" | sendmail [email protected] "subject: $name” Name: Potential SSH account username/password guessing +Events: SSH-Invalid_User, SSH-Failed_Password +IPs: 10.0.0.0/8 -IPs: 10.0.0.1, 10.0.0.7-15 +Sensors: DMZ-1, DMZ-2 -Users: (unknown) syslog: 10.10.10.10 "Possible password guessing evidence: $log" -priority 97 -port 514 Threshold: 5 in a minute RateLimit: 1 per minute MaxQueue: 100 Threshold: 5 in a minute RateLimit: 1 per minute MaxQueue: 100 Name: Potential SSH account username/password guessing +Events: SSH-Invalid_User, SSH-Failed_Password +IPs: 10.0.0.0/8 -IPs: 10.0.0.1, 10.0.0.7-15 +Sensors: DMZ-1, DMZ-2 -Users: (unknown) syslog: 10.10.10.10 "Possible password guessing evidence: $log" -priority 97 -port 514 Threshold: 5 in a minute RateLimit: 1 per minute MaxQueue: 100 Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 27 Ratelimit The maximum number of triggers that will occur over a specified length of time, regardless of the number of triggering events. The timeframe can be expressed in "second", "minute", "hour", "day", "week", "month", or "year". Example: 1 per minute Name: Potential SSH account username/password guessing +Events: SSH-Invalid_User, SSH-Failed_Password +IPs: 10.0.0.0/8 -IPs: 10.0.0.1, 10.0.0.7-15 +Sensors: DMZ-1, DMZ-2 -Users: (unknown) syslog: 10.10.10.10 "Possible password guessing evidence: $log" -priority 97 -port 514 Threshold: 5 in a minute RateLimit: 1 per minute MaxQueue: 100 Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. 28
© Copyright 2024