Log Correlation Engine Best Practices

Log Correlation Engine Best Practices August 14, 2012 (Revision 3) Copyright 2012. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. The ProfessionalFeed is a trademark of Tenable Network Security, Inc. All other products or services are trademarks of their respective owners. Tenable Network Security, Inc. 7063 Columbia Gateway Drive, Suite 100, Columbia, MD 21046 410.872.0555 sales@tenable.com www.tenable.com

Table of Contents Introduction... 4 Log Types..... 4 Application Execution Logs... 4 Background... 4 What You May Be Missing... 4 Forensic Analysis... 5 Summarizing Applications... 5 Detecting New Applications... 7 Windows Application Crash Analysis... 7 Statistical Application Process Anomalies... 7 Authentication Logs... 9 Background... 9 What You May Be Missing... 9 User IP Tracking...10 Network Login-failure Sweeps...10 Brute Force Login Detection and Successful Password Guesses...11 Statistical Increases in Logins and Login Failures...11 Policy Alerting...13 Never Before Seen Logins and Login Failures...13 DNS Logs and Passive Monitoring...15 Background...15 What You May Be Missing...15 Example DNS Logs...15 Benefits of Passive DNS Logging with the PVS...16 DNS Summary Reporting...16 Searching, Alerting and Reporting on DNS Logs...17 Failed DNS lookups...18 DNS Query Anomaly Activity...19 Detecting Continuous DNS Lookup Errors...20 Monitoring DNS Servers in General...20 Firewall Logs...20 Background...20 What You May Be Missing...21 Analyzing Outbound and Internal Firewall Events...21 Statistical Firewall Events...23 Network Intrusion Detection Logs...23 Background...23 What You May Be Missing...23 Server Monitoring...24 Correlating IDS Events with Vulnerabilities...25 Detecting Intrusion Scans and Sweeps...25 Never Before Seen Intrusion Events...26 Statistical Spikes in Intrusion Events...27 Continuous Scanning and Intrusion Events...27 User ID Tracking for IDS Events...28 NetFlow and Network Monitoring Logs...28 Copyright 2002-2012 Tenable Network Security, Inc. 2

Background...28 What You May Be Missing...29 Logging by Session Length and Session Size...29 Proxy Detection...31 PVS Encryption and Interactive Session Detection...32 Correlating Network Sessions with Botnet Threatlists...33 Detecting Statistical Network Deviations...34 Web Server Logs...35 Background...35 What You May Be Missing...35 Automating Web Server Probe and Attack Detection...36 Detecting Long Term Web Errors...36 Activity Monitoring...37 Database Activity Monitoring...37 Background...37 Passive SQL Boundary Monitoring...38 Searching Sniffed SQL Statements...39 Statistical and Never Before Seen Events for Passive SQL Logs...40 Monitoring Database Systems in General...40 File Access and Web Browsing Activity...41 Background...41 What You May Be Missing...42 Statistical File-Access Anomalies...42 Forensic Investigation...43 Files Downloaded from Threatening Addresses...44 Detecting New Types of File Access...44 User Activity Monitoring with Central Authentication...45 Background...45 Which Authentication Logs?...46 Multiple and Migrating IPs per User...46 Additional PVS User Activity Events...47 Pivoting From Events to Users...47 About Tenable Network Security...49 Copyright 2002-2012 Tenable Network Security, Inc. 3

INTRODUCTION This document describes best practice strategies that leverage Tenable s Log Correlation Engine (LCE) for a variety of application, security, system, user, and compliance monitoring scenarios. Each section considers the types of logs that can be gathered and how the LCE s set of correlation, anomaly, reporting, dashboard, and alerting functions can be used most effectively. This document provides users ideas and inspiration to develop new approaches for how the data they are collecting can be used for more effective dashboards, alerts, and reports. In addition, it provides insight into what users may not be logging and how this can impact incident detection or compliance monitoring. For a more advanced discussion of the LCE s correlation functions, please refer to the Tenable Event Correlation paper available on the Tenable Support Portal, which is designed to complement this paper. Normalized event names reported by the LCE are created from various words indicative of the event and are typically separated by dashes and underscores such as Port_Scan or Cisco-Login_Failure. However, when referring to the name of the event within this document, the dashes and underscores are often omitted and written with just the base keywords such as Port Scan or Cisco Login Failure. It is assumed that readers are familiar with the LCE s asset creation, asset filtering, log normalization, log compression/search, correlation, and working with LCEs as well as statistical events. If you have suggestions to further extend this document, please email us at support@tenable.com or post your suggestions and use cases to the Tenable Discussion Forums. LOG TYPES APPLICATION EXECUTION LOGS Background Desktops, laptops, and servers regardless of their operating system can be configured to log when an application is executed. In some cases, the operating system will log when an application crashes or has errors. If you have many systems or even a single system that is very busy, the amount of application logs generated and collected can be overwhelming. On Microsoft Windows systems, application execution logs will be created if the Audit process tracking security policy has been enabled. When enabled, logs of application executions will be sent to the Windows event log and can then be gathered by an LCE Windows client or with a remote WMI query from a Linux WMI client or a remote LCE Windows client. On Linux, FreeBSD, and Mac OS X systems, LCE clients and the underlying operating system can be configured to gather process accounting logs. All normalized and correlated events related to process execution, process errors and reports are given an LCE type of process. What You May Be Missing If you do not have your system configured to generate and collect application logs, you are missing out on the following benefits: Copyright 2002-2012 Tenable Network Security, Inc. 4

> Incident Response data: Application logs provide a record of what sort of activity was occurring on a host that was compromised or used for malicious activity prior to, or after an event. > Auditing metrics: Application logs help prove to an auditor that only certain programs are being run on certain hosts. > Activity summary: Gathering these logs allows you to quickly search and summarize the activity of all of your monitored systems for usage of a particular type of program. Forensic Analysis Having an audit trail of all commands run on a system is very useful, but requires manual searching of the logs to figure out what program ran at which times. In the screen capture below, there are 5,923 Windows New Process Created events: These logs can be viewed and filtered to gain an understanding of what applications were being run. There are two methods to search for application names of interest. The first method lets users search the matching logs for normalized process accounting events. When invoking the Raw Syslog Events analysis tool, an additional text filter can be used to refine the matching logs displayed. In the screen capture above, if the user clicked on the 5923 event count for the Windows New Process Created event, a list of each event would be displayed. Clicking on the Show Filters button opens a menu in which the user can select the Raw Syslog Events analysis tool. When this tool is selected, a new menu item is displayed that allows the user to specify additional text for searching. If the user wanted to only see logs for an application named Example.exe, entering that text and launching a new query would find those logs, if they exist. This sort of filtering principle can be used to create reports, alerts, and dashboard elements as well. The second method leverages full log searches. If you have configured your LCE to collect and compress all received logs for searching, you may simply conduct a search for a string, such as Example.exe, and see which logs match. Gathering logs in this manner can be useful to quickly create a report of logs for a forensic investigation. Summarizing Applications A forensic log of all application executions is indeed useful for forensic analysis but does not provide an activity summary or generate an alert when new types of applications are run. The LCE can perform some very powerful alerting and reporting of application events. Following is a screen capture of 24 hours of process type events that includes output from the LCE: Copyright 2002-2012 Tenable Network Security, Inc. 5

The LCE will summarize a variety of items for each system from which it receives Unix or Windows application execution logs, as indicated in the table below: Event Daily Command Summary Daily Hung Summary Daily User Summary Hourly Command Summary Hourly Hung Summary Description List of all Unix or Windows commands that have run at least once in the past 24 hours on each system. List of all Windows applications that ended up hanging or crashing in the past 24 hours on each system. For Windows and Unix systems, the user IDs associated with each command are tracked and reported every 24 hours for each system. Summarizes all Unix and Windows applications that have run in the past 60 minutes. Summarizes all Windows applications that have crashed or hung in the past 60 minutes. The 24 hour summaries are excellent log sources that can be used for daily reports. Searching these summary logs is also much faster than searching the raw application logs. For example, consider a scenario where there are one million application logs every day from across one hundred servers. If we wanted to search thirty days of these logs to look for Example.exe we would have to search thirty million logs. However, if we filtered our events to match on Daily Command Summary logs, we would likely have one of these from each of our hundred servers. Thirty days of these logs would be three thousand logs, which can be searched much faster than querying thirty million. Summarizing which Windows applications are crashing is not only a useful IT monitoring feature but can also determine if a worm or malicious attacker is attempting to exploit client application software, which will likely result in crash and segmentation fault logs. Copyright 2002-2012 Tenable Network Security, Inc. 6

Detecting New Applications The LCE also attempts to identify the first invocation of new applications on your systems. For each command processed, the LCE keeps track of previously seen commands and, if a new one is found, a New Command event is generated. Creating alerts, trend lines, and reports for New Command events can help identify change that may indicate a security issue. Creating alerts within the LCE that identify change on production systems or servers is a useful way to identify when a new command that indicates software installation has run on an asset in violation of the change control policy. Detecting new applications in use does not imply that the software was recently installed. For example, an attacker may break into a system and run the tcpdump program. The tcpdump program may have been there since the operating system was first installed but the first use of it was by the attacker, not the administrator. In the screen capture above, there were 157 New Command events. When new servers come online and start sending their logs to the LCE, it is common to get an event spike while the LCE is building up a database of what normally runs on each system. The LCE also considers the hour of the day that an application runs. This is also useful to identify subtle changes that may account for suspicious activity. Windows Application Crash Analysis We have already seen that the LCE summarizes hung and crashed Windows process logs. This event stream is very useful to create alerts, dashboard trends, and reports. Following is an example screen capture of a sanitized log from some laptops at Tenable: It is common for infected systems to have applications that crash, become hung, and fail. The LCE can indicate if Windows or Unix-based malware does get into your network and spreads to other systems. As a virus or worm propagates through your network, you may experience crashes from several different computers in a short period of time. The LCE subscribes to a variety of Unix and Windows events that indicate reboots and other major system errors. If more than three errors or reboots occur in a five minute period, a Multiple System Crashes event is issued. Statistical Application Process Anomalies The LCE s stats daemon can be an important tool in your monitoring strategy to process accounting logs. It will profile the normal activity level of any normalized event, including events normalized into the process type category. Statistical increases in the number of applications being invoked can indicate a higher load on a system. Higher loads could come from increased usage, from a denial of service attack or from failing applications. For example, a spike in usage of explorer.exe could be caused because malware is probing files on the network. It could also be caused by a domain controller pushing out a new security policy on the network. Statistical alert names are based on combinations of the generic event type and the amount of deviation such as Statistics Process Medium Anomaly or Statistics Network Minor Copyright 2002-2012 Tenable Network Security, Inc. 7

Anomaly. Some LCE users use the statistical alerts with a *Large* filter so they can easily track any larger statistical events on their servers. For example, they may create a report or dashboard element that indicates large statistical changes by using the stats type filter, an event name of *Large* and perhaps an asset of their servers of interest. Other LCE users may want to see all statistical alerts related to process accounting for a given asset over time. For example, it would be reasonable to create a dashboard element that lists all statistical process events for the past seven days for a Web server by using a similar filter as above, but using an name of *Process* instead. Consider the following dashboard example: We have created two dashboard elements, both a table type. The top element shows all process event types for the past seven days. The bottom element shows all statistical (from the stats event type category) events that were related to process event types. This second dashboard was accomplished by filtering on the stats event type and filtering on *Process* for the event type name to limit events to just the statistical process events. Viewing the dashboard this way is useful because at a single glance, you can not only see the normal process peaks and valleys over the past seven days, you can also see which days and periods of time had statistical anomalies. Copyright 2002-2012 Tenable Network Security, Inc. 8

AUTHENTICATION LOGS Background The LCE gathers logs from hundreds of applications, devices, and operating systems. Logs that indicate a login occurred are given an event name and normalized to the login event type. Similarly, login failures are normalized to the login-failure event type. Logs that indicate some form of denied access, but not necessarily a failure to present credentials or attempt to authenticate, are normalized to the access-denied event type. Gathering real-time login and login failure logs in one location with the LCE can be of great value for reporting, trending, compliance monitoring and monitoring for hostile attempts to access your systems. Using the LCE s ability to filter events by assets lets you create powerful comparative reports and dashboards that can show you login and login failure trends between regions, technologies, data centers, or organizations. The following is a screen capture of 24 hours of login failures for a Tenable customer that makes use of Cisco products, IMAP for email, SecurityCenter, and a variety of Windows and Unix operating systems: What You May Be Missing If you do not have your system configured to collect login or login failures, you are missing out on the following benefits: > Compliance reporting: Many compliance standards require organizations to compile access control reports that include login and login failures. > Brute force attack detection: Collecting login or login failures help detect brute force password guessing attacks and shows statistical increases in login events. > User activity monitoring: Authorized logins can be used to tie user IDs to IP addresses, which allows the LCE to correlate other non-login events to that same user Copyright 2002-2012 Tenable Network Security, Inc. 9

ID. This lets you look at intrusion, firewall, NetFlow and many other types of logs by user ID instead of IP address. > Central authentication reporting: Gathering login and login failure events from many different types of applications enables you to centrally report and monitor all authentications across your network. User IP Tracking The LCE can be configured to learn network user IDs and track which IP addresses they are coming from by parsing logs with a valid login. Once a user ID and IP address is learned, any other event normalized by the LCE will have that user ID associated with it. This allows LCE users to pivot between events, IP addresses, and users by changing their analysis tool. For example, after selecting a spike in firewall-denied events, a user could choose the User Summary tool and would then be presented with a list of users and their firewall-denied event counts. This is a very powerful feature of the LCE and an entire section named User Activity Monitoring with Central Authentication is devoted to this topic later on in this paper. Network Login-failure Sweeps The LCE looks for login failure events from a single IP address that occurs on more than 5 unique hosts in the past 60 minute or 24 hour period. If such a series of events occurs, a Network Login Sweep event will be generated in the intrusion event type. Following is a sanitized screen capture of typical events from this type of correlation performed on a live office network: The LCE does not care if the source IP of the address is from inside or outside of your local network. This means that the Network Login Sweep event can be generated if you have legitimate types of login failures from internal processes such as patch management, Copyright 2002-2012 Tenable Network Security, Inc. 10

vulnerability auditing or network management. It can also mean that an external IP address has scanned your network and caused login failures across many systems. Depending on your threat profile, you may want to create alerts, reports, or dashboard elements that consider these events with an inbound direction filter to only alert on external login sweeps. If you want to filter out login failures from your network scanners or patch management systems, consider creating an asset list of your local network that does not include them. For example, if you had a Nessus scanner at 192.168.1.100 and wanted to ignore login failure alerts from it, you could create a special asset list that contained 192.168.1.1-99,192.168.1.101-255 and then look for login failures or events from LCE to see where that asset was considered to be the source. Brute Force Login Detection and Successful Password Guesses The LCE also monitors login-failure event types to look for password guessing attacks on one host. If more than 30 login failures of any type occur from a single IP address within 60 minutes or within 24 hours, a Password Guessing event is generated. This activity is logged to the intrusion LCE event type as shown below: The Password Guessing event is seen listed above mixed in with other intrusion event types. The LCE also identifies login failures followed by a successful login from the same source IP address. The concept is to alert when a given IP address has both tripped a login failure brute force password event and then a valid login has indeed occurred. In practice, vulnerability scans from Nessus and other types of security auditing tools will induce login failures as various default accounts are attempted. With Nessus, you can minimize these types of false positive login failures by configuring your scans to only leverage credentials supplied by the scan policy. You can also use the negative asset filtering to ignore these types of alerts from your scanning infrastructure. Statistical Increases in Logins and Login Failures The LCE correlations discussed so far have hard coded values that identify login failures by looking for 30 failed login attempts in a row. The number 30 may seem arbitrary, but it is sufficiently higher than what a normal user will encounter when legitimately mistyping a password or forgetting a password a few times before logging in. The LCE stats daemon will track anomalies in logins, login-failures, and logouts just like any other type of normalized event. Consider the following screen capture that shows 7 days of any type of statistical anomaly event with the word Login in it: Copyright 2002-2012 Tenable Network Security, Inc. 11

Filtering on the stats event type and an event name filter of *Login* provides a quick match on login and login-failure event types. Past performance is used to determine what an anomaly is. When the stats daemon generates an alert for a set of login failures or logins that have been different it is because of how they compare to activity in the past. The stats daemon learns what is normal and only generates an alert when the learned normal activity has a spike that is multiple standard deviations away from a normal grouping. Following is the log message associated with the single Statistics Login Large Anomaly event: In this case, host 172.29.1.136 had a series of Windows Login With Credentials events occur between 6:00 am and 7:00 am. On average to date, this time window had.07 (hardly any at all) during that time period, but today we had 60. This is a big change. Could it be cause for alarm? Is l33thax0r attacking your database server or is an IT administrator simply coming into work early to apply some patches? The stats daemon is not intended to answer these questions. It only focuses on finding the anomalies. This is also the primary reason why all stats events are in their own type and not associated with discrete types such as putting the statistical login events in the login event type. Tenable encourages LCE customers to create alerts, reports, and dashboard views for all anomalies on a per-asset or per-system basis or even view all of the statistical anomalies at once. This way any anomaly, large or small, is not necessarily a bad thing. It simply means a resource is being used differently than before. The administrator can make a judgment call based on other factors. For example, when reviewing anomalies for a secured DNS server, a spike in logins could imply that there was an increased need to login. The administrator can determine if this need was legitimate or not. Copyright 2002-2012 Tenable Network Security, Inc. 12

Policy Alerting The Policy Alerting built into the LCE and SecurityCenter 4 user interface can provide tremendous flexibility to alert for login failure types. Following is a screen capture that shows an alert to check for 60 login failures of any type in a 30 minute period. Notice that this alert runs every 30 minutes and the event query we have also has a 30 minute window. For most LCE alerts, you want the query frequency to align with the time window of the query. In some cases, you may want to use an alert to look for a low and slow type of attack. For example, perhaps you would like to schedule a 24 hour query for more than 24 login failures. Some botnets try to guess passwords at such a slow rate, so spikes in login-failures never really occur. Scheduling a 24 hour query every hour would help detect these types of events. Never Before Seen Logins and Login Failures The Never Before Seen form of LCE correlation can also be used to look at login, login failure, and logout events. This feature subscribes to most LCE normalized events and keeps track of which events have been seen for each host on your network. It alerts when a new event has occurred that has not yet been seen. When a server first comes online, its logs will have a certain footprint. These will all be alerted on by the LCE as being something new. Now consider what happens to a production server once it has been online for some time. We would hope that we do not see anything new in those logs such as a new type of login event or a new type of error. From a login or login-failure perspective, it is important to realize there are often multiple types of authentication mechanisms supported by operating systems today. For example, most Secure Shell (SSH) systems support usernames and passwords as well as a variety of public and private keys. In 2009, it was discovered that there was a weak key (which could be used as a backdoor) in Debian SSH implementations. As worms and exploit kits became available, Linux users worldwide saw a spike in login failures on non-vulnerable systems as well as public/private key logins to vulnerable Debian systems. Following is a screen capture of Never Before Seen events from a 24 hour period on a server farm of about 500 systems: Copyright 2002-2012 Tenable Network Security, Inc. 13

There have been two instances of a Never Before Seen Login Event. Drilling into this event, the following sanitized log could be seen: The two different hosts had a Windows Successful Network Login event. The use case for this type of monitoring is very similar to working with events from the stats daemon. It depends on the context of the server or asset you are monitoring. Tenable places all nbs event types into one group, which enables you to see all events that have never occurred for a single host all at once where they can be analyzed efficiently. If new login, login failures, and logout events are occurring, you should question why. Is a system administrator legitimately accessing a service with a new method? Has an upgrade to the operating system created a new type of login? Has an attacker or malicious insider attempted to access something in a manner different from authorized users? Only context and consideration of the asset or system generating the new event can answer these questions. Copyright 2002-2012 Tenable Network Security, Inc. 14

DNS LOGS AND PASSIVE MONITORING Background Performing the conversion of a domain name to an IP address is the first step in most Internet communications. The LCE can work with logs from devices that provide Domain Name Service (DNS) to network users and with logs from devices that log DNS activity. The LCE will process DNS related logs with the following types: > application Logs from DNS servers related to the application itself such as the start of a zone transfer between two DNS servers. > dns Logs that indicate a query from a DNS name to an IP or vice versa have occurred. Logs can come directly from a DNS server, such as BIND, or they can be passively logged by a product such as the Tenable Passive Vulnerability Scanner (PVS). Queries for DNS names that have failed are also typically logged to this category. > error Any logs related to the DNS application that indicate some sort of error. > startup Any logs from a DNS appliance or DNS service that indicate a reboot, restart, or service availability. The LCE will also make use of certain web-access and file-access events that have logged an HTTP query for some DNS based reporting. A web proxy or a PVS will be able to log or sniff web traffic to URLs such as http://www.nessus.org/plugins and treat www.nessus.org as a DNS query. If you have a DNS server, such as BIND, and you are only logging application logs about DNS and are not logging actual DNS queries, you will not have any forensic or reporting ability for DNS. If you are only logging perimeter web proxy logs, you do not have visibility into email, FTP, and many other non-web DNS queries. If you have a PVS sensor, and have only configured it to sniff vulnerabilities you will not have access to real-time DNS query (and web transaction) logs. What You May Be Missing If you do not have your system configured to log DNS queries, you are missing out on the following benefits: > The ability to search DNS records for malicious names as well as names of interest. > The ability to summarize the queries to understand what sort of web sites and network resources a given node has used. > The ability to log DNS query errors can help identify misconfigured and compromised endpoints. Example DNS Logs Following is a log from DNS BIND that indicates a zone transfer is starting: Oct 15 14:24:12 ve-du0c named[03043]: [ID 424333 daemon.info] zone someplace.net.dk/in/internal: Transfer started This would be normalized to an event name of Bind Zone Transfer Started and an event type of application. Copyright 2002-2012 Tenable Network Security, Inc. 15

Following is a log that indicates that a DNS query has occurred: <134>named[7273]: queries: client 192.168.0.16#52742: query: spamalot.someplace.org IN A + This log would be normalized to an event name of Bind Query IPv4 an event type of dns. Benefits of Passive DNS Logging with the PVS Following is a screen capture of DNS lookup events observed by the PVS at an active university of 2,500 students. There are multiple DNS servers on campus, but none of them have been configured to log DNS transactions nor send their logs to the LCE. In the screen capture, 514,743 DNS lookups have been observed in a 24 hour period. All of these events have been normalized to an event type of dns and the PVS event name of PVS DNS Client Query. If DNS queries were present from other log sources such as BIND, they would also be present in this view. The PVS not only sees DNS queries from these DNS servers, it also sees DNS queries that have been made directly to the Internet. For example, a system compromised as part of a botnet may have its own list of DNS servers to query. DNS Summary Reporting In the screen capture above, there were more than half a million DNS queries in a 24 hour period. This sort of data is useful from a statistical anomaly point of view or to review each DNS query performed by a host forensically. We will discuss strategies for searching DNS query logs in the next section. For now, it is sufficient to note that the LCE summarizes all DNS and Web queries. The LCE analyzes DNS query logs from the PVS, from DNS servers and also from web queries logged by the PVS or web proxy devices. LCE uses an efficient in-memory storage system to automatically create summary alerts. LCE is also intelligent in that it does not consider queries to recursive DNS names that are used by anti-virus companies and antispam service providers. Following is a screen capture from the same university with the half million DNS queries in one day: The Domain Summary event is generated any time the LCE reaches capacity for the amount of data it is tracking. Once a domain is seen, possibly from a host doing a DNS lookup for cnn.com, that domain will only be reported once until LCE encounters so many Copyright 2002-2012 Tenable Network Security, Inc. 16

unique host DNS pairs that it needs to reset itself. How often this occurs depends on the number of total unique queries. Following is a sanitized screen capture of what a Domain Summary event log looks like: This summary is useful for forensic analysis, employee monitoring and creating reports. For this particular network, the LCE has taken the half a million DNS queries and reduced this to around 11,000 events. In actuality, those 11,000 Domain Summary reports consider all previous DNS queries that occurred before this 24 hour period. The following is a screen capture that is typical of a network where users frequently go to the same destinations. You can see a general downward trend in Domain Summary events. Even if a user visits gmail.com, facebook.com, or yahoo.com hundreds of times a week or day, it will only get reported in the Domain Summary log once. Searching, Alerting and Reporting on DNS Logs Generally, there are two types of searches conducted on DNS events: those looking for specific DNS entries, and those looking for keywords. If you have a domain name of interest, entering this string into the LCE s Raw Logs search tool can help you identify occurrences of it in any log. This is useful because domain names often show up in logs associated with logins, transmission of email, web logs and more. If you want to look for a domain name of interest while working with normalized events, you can filter on a set of events you want, such as a Bind Query IPv4 event, and then choose the Raw Syslog Events filter with an additional Syslog Search Terms filter for your domain of interest. If you would like to alert when activity to a certain domain occurs, consider scheduling an LCE alert that leverages an event such as the Bind Query IPv4 analyzed with the Raw Syslog Events tool with an additional filter for the domain you would like to have an alert for. The following is a screen capture that uses the Bind IPv4 DNS lookup filtered for nessus.org every 15 minutes: Copyright 2002-2012 Tenable Network Security, Inc. 17

As with most LCE scheduled alerts, we have aligned our query of 15 minutes with a schedule of 15 minutes to avoid over or under-counting potential DNS activity. As a final point with normalized DNS logs, do not forget that if you have User ID to IP address tracking enabled on your LCE, you can combine the Domain Summary log with a user ID query and you have just created a report for all the domain names that user has visited. The second type of DNS search is to look for keywords that indicate the presence of web sites and activity that should not be occurring on your network. There are many different types of Internet destinations that may be not authorized for your network. Adult content, drug use, political blogging, gambling, video games, terrorism, visits to competitor web sites, visits to social networking sites, and visits to potentially suspicious countries are just some of the types of items that can be searched for in DNS logs. When working with large user populations of DNS queries, it is important to note that simple keyword searches in DNS logs can have false positives. For example, searching for sexually explicit terms could result in hits for visits to adult websites as well as medical websites. Searching for short keywords such as sex could match on sites that contained the word, such as ufosexist, but do not really have anything to do with the offensive topic. Finally, put yourself in the position of the user you may be monitoring. Visits to Facebook, Gmail, and even CNN can present users with advertisements that cause DNS lookups of interest. Just because it appears that a user that has had some queries for some potentially interesting or suspicious domains, it does not mean the user intended to go there. Failed DNS lookups We have all typed in an address for a web site or an email incorrectly at some point. This likely resulted in a query to the DNS servers for a domain name that did not exist. These types of events are logged by DNS servers and can also be passively discovered with the PVS. Following is a screen capture of seven days of PVS DNS Client Failed Query events from a small ISP: Having a record of failed DNS queries is not as interesting as knowing which hosts on your network are doing this and the frequency with which they are performing these queries. Copyright 2002-2012 Tenable Network Security, Inc. 18

When a node is infected with malware that can be used to attack other computers or send spam email, it is very likely that the computer will perform many DNS lookups for websites and email servers that do not exist. A key principle of botnets is that their command and control nodes are constantly moving to new locations. DNS is primarily used to allow compromised nodes to find new command and control resources. In the process of communicating with these nodes, it is likely that DNS queries for various parts of the botnet infrastructure fail. With spam, if a compromised node is sending out many emails, it is possible that the attempts to connect to the email servers fail because they do not exist. This usually results in a DNS query failure. Finally, you may have a network that has a computer on it that has not been compromised, but is not correctly configured for DNS. It may be pointing to DNS servers that are out of date or are no longer in production. DNS Query Anomaly Activity The LCE stats daemon will report on any DNS spike. This includes both DNS query logs as well as DNS lookup failures. The following event types can be generated by the stats daemon regarding DNS queries: > Statistics-DNS_Minor_Anomaly > Statistics-DNS_Anomaly > Statistics-DNS_Medium_Anomaly > Statistics-DNS_Large_Anomaly When analyzing these types of events, consider splitting your analysis into two groups: servers and assets that perform a lot of DNS lookups and those that do not. An email server makes lots of DNS lookups compared to a corporate desktop driven by a user. Based on volume of users and activity, the stats daemon will likely detect changes in DNS activity that reflect changes in legitimate email message volume, web site popularity and even employee workload. However, a spike could also be associated with activity from comprised servers, malicious email campaigns targeted at your organization and denial of service attacks. When analyzing a non-server spike in DNS activity, see if you can corroborate any type of other activity on the host. For example, if a user installs an RSS reader and then regularly starts reading RSS feeds from 100 new web sites every day, this could generate a large spike in DNS lookups compared to traditional email and web browsing. Such activity would likely be reported by the stats daemon as a minor or regular anomaly. If the spike on any host is the result of DNS lookup failures, inspect a sample of the DNS lookup failure logs to see what was occurring. If they are for internal resources, you likely have a misconfigured system, domain controller, or DNS server. If the domains are random, outside of your network and/or highly random in nature, you may have a compromised system that is sending spam, or attacking other computers. Copyright 2002-2012 Tenable Network Security, Inc. 19

Detecting Continuous DNS Lookup Errors The LCE identifies when an internal or external host generates continuous intrusion, scanning, error, DNS lookup error, hung applications, virus or social-network event types. From the LCE s point of view, a continuous event is one that occurs at least once for two 20 minute periods. This may seem arbitrary, but it has been shown to be very effective at a variety of customer sites in finding systems that have had a number of issues. Following is a screen capture showing multiple different types of events from the continuous event type category: Continuous events are all labeled with the tag Long Term. By default, the LCE watches for activity from a host in periods of 20 minutes. It will reissue an alert as the activity continues for 20 minutes, 40 minutes, etc. In the above screen capture, the DNS lookup errors occurring continuously are related to the Long Term DNS Failures events. Below is an example log of generated by LCE: Long_Term_DNS_Failures - There has been 140 minutes of continuous failed DNS activity from host 192.168.1.58 (lap11109.home) and the most recent event was failed-query towards host 192.168.1.1 (Wireless_Broadband_Router.home) at 2/7/2011 03:21:09 We can see that the level of DNS lookups has been continuing for 140 minutes. In this case, 192.168.1.1 is the local DNS server and it does not know how to use the.home domain name suffix. When issues like this occur on live networks, use a similar analysis approach as what was recommended for statistical anomalies. Continuous DNS lookup failures for servers are analyzed differently than for a desktop. It is likely that your email gateway performs a lot of DNS lookups that fail while sending email on a daily basis. However, this may not be true for a desktop, a router, or a wireless access point. Monitoring DNS Servers in General As noted in the introduction, each DNS server will generate a set of logs that are normalized into the LCE event types of application, error, login/login-failure, and startup. The underlying operating system will also contribute its logs to the LCE event categories of error, login/login-failure, process, startup, and system. There are many approaches to analyzing these events and monitoring them for their impact to compliance, security, and availability. FIREWALL LOGS Background The LCE normalizes firewall logs from a variety of appliance, router, software and operating system based solutions. Firewall events are normalized into the following types: Copyright 2002-2012 Tenable Network Security, Inc. 20

> connection any allowed network connection > error any type of error from the firewall function > firewall any denied network connection > login any type of authentication log from administrators > scanning some firewall applications offer intrusion detection and prevention functions and report port scans > system any events from a firewall appliance concerning operation The main events that LCE users rely on to monitor firewall logs are the firewall events that indicate denied network sessions. When these occur inbound, it means that an external computer made a connection attempt to an internal resource and was denied. This could be because of a scan, or could also mean that a connection was denied but was not malicious. For example, many smart phones will attempt to auto-provision their email settings and test for POP or IMAP accounts on multiple default ports. The LCE can also analyze allowed connections that pass through a firewall. These connections are normalized to the connection event type. Summarizing these events can tell you the top ports in use, the allowed ports in use and if user ID-to-IP tracking is enabled, which users are the most active on the network. What You May Be Missing If you do not have your system configured to collect firewall logs, you are missing out on the following benefits: > The ability to detect external scans as well as internal outbound denied requests that indicate compromise. > The ability to audit network sessions (unless you are monitoring them with the Tenable NetFlow Monitor or Tenable Network Monitor LCE clients). > The ability to identify firewall changes, access events, configuration changes and errors, all of which have ramifications for compliance monitoring and general well-being. Analyzing Outbound and Internal Firewall Events Analyzing perimeter firewall logs should focus on identifying which ports are being probed for and from which remote IP addresses the probes are occurring from. Using a direction filter to consider inbound firewall logs can be used to identify these boundary probes. The following is a screen capture of seven days of denied firewall logs, both inbound and outbound and internal to a data center: Filtering this same data for inbound, outbound, and internal events shows very different graphs. Inbound: Copyright 2002-2012 Tenable Network Security, Inc. 21

Internal: Outbound: From a policy point of view, if your perimeter is facing the Internet, you can expect to see large amounts of continuous scans and sweeps from the hundreds of botnets and malicious viruses that are present on the Internet. However, inside your firewall, your internal applications and users will drive your inbound denied firewall events as well as your outbound ones. In the above graphs, the outbound graph is the most interesting. About five days ago, there were two spikes in outbound attempts. These can be investigated to see what ports were denied and which systems these came from. A key principle of compromising a system via malware, botnet farming, direct attack, or through social engineering is to achieve some sort of control over the end point. This could be through a custom application, leveraging the web, leveraging an FTP server or many other techniques. However, it is unlikely that a manual attack or an automated exploitation framework will know your organizations outbound egress filtering. As such, a compromised system will likely trip your outbound firewall rules if you have them established. A matrix dashboard element is useful to create at-a-glance views of denied firewall logs. Creating a matrix that lists an asset or network range on each row and then separate columns for Inbound, Outbound and Internal firewall views can help easily identify when you have a resource that has tried to go someplace and was denied. Consider creating an alert for assets that you know would never generate an outbound firewall deny rule. For example: > For your web server farm, there is a firewall with an egress filter that only allows port 80 and port 53 outbound connections. Creating an alert that identifies when a web server asset has a denied outbound firewall event can quickly identify when a system has been compromised, misconfigured or an administrator was prevented from doing something prevented by the firewall policy. > For a LAN where all desktops and laptops are required to use a web proxy, all nonproxied web requests can be identified by the firewall. Any log of this type likely indicates a misconfigured system, an employee attempting to circumvent corporate policy or a system that has been compromised and is not leveraging the system s proxy settings. > If all outbound email is required to be sent through the local mail server, then any type of outbound port 25 denied event could indicate that the host is attempting to send unauthorized email. This could indicate a user not complying with the local policy, a user with a misconfigured email client or even one that has been compromised and is attempting to send email (e.g., exfiltrating data, unsolicited bulk email). Copyright 2002-2012 Tenable Network Security, Inc. 22

Statistical Firewall Events The LCE stats daemon will create alerts for statistical increases in denied firewall events. Any type of increase found by the stats daemon is focused on your internal IP addresses, not those of an attacking external IP address. Analysis of these types of events tends to focus on identifying why these changes in behavior have occurred. The following is an example screen capture of seven days of statistical firewall events: When an internal system has a worm or virus that attempts to propagate to other hosts on the Internet or internally, if outbound firewall rules and logs are in place, it is likely that this type of traffic can create a deviation from normal web traffic. Similarly, some applications such as RSS readers, torrent clients, chat clients, voice over IP and even video conferencing tools can create changes in firewall logs because of how they attempt to probe available open ports. NETWORK INTRUSION DETECTION LOGS Background The LCE aggregates Network Intrusion Detection Systems (NIDS) events via flat files and syslog data. NIDS events are categorized into the following LCE types: > application status logs such as reloading signatures > intrusion generic IDS events that indicate probes > error if the IDS encounters an error message > scanning port scans and network sweeps > virus IDS events associated with virus propagation The LCE normalization process attempts to categorize IDS events into the high level types listed above while using unique event names such as Snort TCP Sweep. The LCE can also be configured to normalize events with the raw event name of the NIDS technology in use. To enable this, the lced.conf file must be configured with the IP address of the NIDS sensor or management console. If the LCE is managed by SecurityCenter, correlation of vulnerabilities and IDS events occurs automatically. The latest patch audits and scan vulnerabilities from Nessus as well as the latest observed vulnerabilities from the PVS are used to indicate IDS events that target systems and ports. Correlation only occurs if the lce.conf file is configured to process events from certain IP addresses as IDS sensor or management log sources. What You May Be Missing If you do not have your system configured to generate and collect Network Intrusion Detection logs, you are missing out on the following benefits: > Network IDS systems can be prone to false positives. Sending these logs to the LCE can help identify truly compromised systems. Copyright 2002-2012 Tenable Network Security, Inc. 23

> Directional filtering can identify when your key assets begin to attack other systems. > If your LCE is using User ID-to-IP address tracking, you can view IDS events by user, which often has different ramifications than viewing by IP address. Server Monitoring A common form of attack detection is to look for outbound IDS events from your servers. The concept is that if you do have a server that is compromised, it will likely be used to attack other systems. We do not recommend attempting to alert on outbound scanning, intrusion or backdoor events unless you have monitored your servers for a while and are comfortable that these events do not occur as part of daily operations. Unless you have a locked-down environment, we do not recommend alerting on outbound IDS events from your user population because of the potentially high false positive rate. Some IDS technologies will label the source and destination IP addresses of an event differently. For example, a VNC login failure reported by one IDS technology may use the source IP address of the client as the source IP address of the event while another technology may actually use the server IP address. This can cause some outbound events to be reported when in fact, they really indicate inbound attacks and probes. In some environments, it is more reliable to use Never Before Seen intrusion events and a directionality filter of outbound events to look for compromised servers attacking an outbound system. If you can safely assume that your servers are not compromised, and any type of false positive IDS event will likely be generated right away, then creating an alert that looks for a Never_Before_Seen-Intrusion_Event leaving your servers will be of high value. Below is an example outbound alert configured to test every 15 minutes: As with most LCE policy alerts, we matched the query time length (15 minutes) with our frequency (perform the query every 15 minutes). For this example, we had an asset list named Virtual Servers in the Ranges group of assets that contained all of the IP addresses for our virtual servers. We also used a Direction of outbound. This means that the source IP address of the Never Before Seen Intrusion Event must match one of the IPs in the Virtual Servers asset list and the destination IP address must be not on that list. Copyright 2002-2012 Tenable Network Security, Inc. 24

You may ask what happens if a compromised server attacks another server on that list? This is a good question and could be solved with either a second alert using a direction of Internal or creating a single alert for this event without a directional filter. Correlating IDS Events with Vulnerabilities Creating alerts for correlated events is very easy. The LCE filter screen has an option to select targeted IDS events. Any IDS event, regardless of type, will be matched. Creating alerts based on this filter in 15 minute windows is useful to detect compromised systems. For server attacks, correlation occurs on the port level. For example, if a Windows computer is seen to have a vulnerable IIS Web server on port 80 but not on port 443, the LCE will only alert if a relevant attack against port 80 is logged. For client attacks against email, browser, chat and other non-server applications, vulnerabilities from Nessus patch audits and client-side detected vulnerabilities with the PVS are correlated independently of the port logged by the IDS sensor. The following is an example screen capture of a correlation between a Dragon IDS event and Nessus plugin 18028: Your first correlated event of this type may likely be a false positive. There are many default IDS events that alert on the use of VNC, Windows Terminal Services, Skype, and other common applications also scanned and reported by Nessus. This is an excellent way to identify what type of applications your IDS finds potentially odd or worth reporting. Detecting Intrusion Scans and Sweeps The LCE identifies when one attacking IP address induces multiple different types of IDS events on one host, or when one attacking IP address induces IDS events on three or more target IP addresses. LCE also considers any type of system log that indicates an intrusion attempt but not necessarily from a network IDS device. LCE finds both slow probes that last hours or days as well as large scans such as hostile vulnerability scans of your network. Results of this scan are sent to the intrusion event type category. Two event types are generated. These are the Intrusion_Host_Scan and the Intrusion_Network_Scan. The host scan alert identifies many unique IDS event types from one attacking IP to another and the network scan identifies any type of unique IDS events from one host to three or more targets. The following is a screen capture of intrusion events. Host and network scan alerts from this LCE can be seen at the top: Copyright 2002-2012 Tenable Network Security, Inc. 25

In the above screen capture, it can be seen that there was a large number of unique Snort events occurring just after 6:00 PM (the start of the darker grey area). The Intrusion_Host_Scan was generated based on the large number of unique types of normalized Snort events targeted at various hosts. Never Before Seen Intrusion Events The LCE performs never before seen analysis of all normalized events including intrusion events. All normalized events, including intrusion and scanning, are correlated at the host level to alert on events that have never been seen before. The value of a never before seen IDS event is immense because there is typically a false positive footprint associated with any IDS set of logs. Even with very good tuning, an IDS will likely have a set of events that are associated with normal traffic and even normal daily probes from attackers. With this model in mind, the ability to recognize when a new IDS alert has occurred automatically is very powerful. Never before seen event names are of the form Never Before Seen {TYPE} Event such as Never_Before_Seen-Intrusion_Event. They are also all of the event type nbs. They are directional in nature such that the first time an IDS event is observed leaving a server it will be logged distinctly from the first time a server is attacked with the same event. This creates several opportunities to alert with high-quality events. Copyright 2002-2012 Tenable Network Security, Inc. 26

If your vulnerability scanning process creates a footprint of intrusion events, the effect of the never before seen correlation filter is dramatically lessened because a large set of probes and attack logs will be generated during the scan. If you filter the IP addresses of your scanner from your IDS sensor(s), this will allow you to highlight real new events. Statistical Spikes in Intrusion Events The LCE includes a statistical event profiling daemon (the stats daemon) that identifies spikes in event patterns. The stats daemon analyzes all of the events of the previous hour and creates alerts if any event exceeds a standard deviation in event counts when compared to the historical activity of the server. All event types are considered, including IDS event types of intrusion and scanning. The LCE classifies statistical events as Minor, Statistical, Medium, and Large. The following intrusion and scanning statistical anomaly events can be generated by the stats daemon: > Statistics-Intrusion_Minor_Anomaly > Statistics-Intrusion_Anomaly > Statistics-Intrusion_Medium_Anomaly > Statistics-Intrusion_Large_Anomaly > Statistics-Scanning_Minor_Anomaly > Statistics-Scanning_Anomaly > Statistics-Scanning_Medium_Anomaly > Statistics-Scanning_Large_Anomaly An increase in IDS event activity could mean that your systems are being scanned more aggressively than they have been in the past. It could also indicate that your systems are compromised and are actively scanning or attacking other servers. When creating IDS dashboards, it is possible to create a table of statistical events that relate to anomalies in IDS event logs. To create a table of intrusion event anomalies, use a filter of type stats and an event name of *Intrusion*. It is also useful to create a similar table for scanning event anomalies. Continuous Scanning and Intrusion Events The LCE looks for events to continue from a certain IP address for periods of time longer than 20 minutes. The intent is to find activity that is potentially hostile and sustained. For example, a compromised system participating in a botnet may scan so many hosts that multiple port scanning events occur from your IDS for multiple hours. Similarly, if actual attacks and virus propagation events are reported by your IDS, the LCE will attempt to identify this continuous activity. For example, in the following screen capture, there have been 12 Long Term Network Scanning events. Drilling into this event record identifies 12 incidents, perhaps all from one host, of an IDS technology sending alerts for attacking systems. Copyright 2002-2012 Tenable Network Security, Inc. 27

There are three correlations available: > Long_Term_Intrusion_Activity > Long_Term_Network_Scanning > Long_Term_Virus_Or_Malware_Activity It is important to realize that for these correlations, time is the most import component and not the number of actual intrusion events. For example, you may have an IDS sensor that has millions of events of day, but buried in them are real events from a compromised system that scans 100 new hosts every hour. User ID Tracking for IDS Events If your LCE is configured to track User IDs by IP address, then using the User Summary analysis tool can quickly identify which user may be compromised, have a virus infection or could be a hostile insider. NETFLOW AND NETWORK MONITORING LOGS Background The LCE aggregates a variety of network activity logs: > Firewalls that are configured to log allowed connections. These are normalized to the event type of connection. > Applications and operating systems that log connections to services such as sendmail logging a network connection to send an email message. These are also normalized to the event type of connection. > NetFlow logs collected by the Tenable NetFlow Monitor (TFM) agent. These are normalized to the event type of network. > Network logs promiscuously sniffed by the Tenable Network Monitor (TNM). These are also normalized to the event type of network. > Information about hosts that have been discovered by the Passive Vulnerability Scanner but isn t necessarily a new vulnerability will be logged to the network event type. This includes new hosts, new open ports, and new ports that are being used to browse the network. Copyright 2002-2012 Tenable Network Security, Inc. 28

> Real-time file sharing logs sniffed by the Passive Vulnerability Scanner. PVS logs for FTP, NFS, HTTP, SMTP, SMB, and other file sharing event logs are normalized to the fileaccess event type. > The PVS will also log when it observes a network session that is encrypted or when it is likely and interactive session with a human typing commands. These events are also normalized to the network event type. For this section, we will concern ourselves with network event types from the TFM, TNM, and PVS. What You May Be Missing If you do not have your system configured to generate and collect network activity logs, you are missing out on the following benefits: > The ability to log all connections and not rely solely on logs from firewalls, proxies, and servers. This helps identify compromised traffic or traffic that makes you non-compliant. > The LCE includes the ability to correlate any network session with high-quality lists of botnet infected IP addresses. Collecting network logs enables the LCE to correlate this information with firewall allowed connections and files observed being downloaded by the PVS for a more complete view of network activity. > Including NetFlow and promiscuous network monitoring data enables you to easily identify which ports are browsed the most, served the most or have the most transactions. > When you do have a compromise and the attacker uses a non-standard port or protocol the inclusion of NetFlow or sniffed network sessions provides a record of the event. Tenable customers that purchase both the Passive Vulnerability Scanner (PVS) and the Log Correlation Engine may find it convenient to install the Tenable Network Monitor (TNM) and the PVS on the same sniffing host. This ensures that all passively sniffed vulnerabilities, all passively sniffed file sharing, and all network sessions are logged. Logging by Session Length and Session Size Events normalized by the LCE from the TNM and the TFM are divided into three categories: > Short sessions lasting less than 5 minutes. > Sessions that transfer more than 1 MB of data. > Sessions that last longer than 15 minutes. The TNM and the TFM also have discrete events to log every non-tcp packet such as UDP or ICMP. These are configured at the client and can generate many logs, but can be an excellent source of forensic information. The following is an example screen capture of a 24 hour period of network events for a set of several dozen web servers, email servers and streaming audio servers: Copyright 2002-2012 Tenable Network Security, Inc. 29

Reading from top to bottom provides the following types of information: > There were 436 sessions that the PVS identified as coming to a port on a server for the very first time. There may be large numbers of these due to dynamic high port usage of RPC and FTP transactions. > There were several sessions that the PVS identified as being either encrypted or interactive. The PVS will log an event name for these sessions based on the direction of the session as seen relative to the configured network ranges that the PVS is monitoring. > There were several Suspicious Proxy events. We will discuss where this event comes from in the next section. > Not surprisingly, there were a great deal of logged ICMP events. When a system is compromised and it starts pinging other systems, the ICMP logs can be useful for forensic analysis. However, logging every ping packet can consume a disproportionate amount of disk space. Copyright 2002-2012 Tenable Network Security, Inc. 30

> There was a breakdown of TCP sessions based on the length of the session. The LCE normalizes a TCP session at various levels from approximately 15 minutes right through multiple days. > The bulk of the TCP events were TNM-TCP_Session_Short. > The next group of events broke down sessions based on the amount of data they sent starting at 1 to 10 MB. > The last type of event is a set of UDP packets sniffed by the TNM. The LCE can handle sniffing and logging ICMP and UDP packets, but if you run into performance or disk storage issues, consider dedicating an LCE to network monitoring, or turning off collection of those protocols at the TNM or TFM. Another approach is to consider where you place your TNM. It may be that there is so much legitimate ICMP and UDP chatter on the internal network, it is not worth collecting. All network events can be filtered on by IP address or port or asset group. For example, it is very easy to observe all sessions on port 22. Similarly, creating a view of all port 22 traffic would quickly identify any long TCP sessions that could be management sessions or perhaps TCP sessions that had large amounts of data transferred over them. The following is a typical log from the TNM: Sun Oct 12 12:09:40 - TNM- TCP_Session_Whole_1GB[1901036510]:10.227.6.52:1488 -> 10.246.18.81:445 [u:0 d:1901036510] 1223823056 1223827780 4724 The entire size of the session is logged in bytes in square brackets and this is later broken out with u: to indicate uploaded bandwidth and d: to indicate downloaded bandwidth. The last three numbers are the timestamp of the session start, the timestamp of the session end and the number of seconds the session lasted. Proxy Detection The LCE considers the sequence of network sessions that terminate to discover when a host may be performing a proxy of TCP connections. LCE looks for a connection from system A to system B and then a session from system B to a third system C. This type of proxy can identify many legitimate and malicious types of activity including: > SSH connections to a server followed by SSH connections to a second server (i.e., SSH tunneling). > VNC sessions into a Windows host followed by VNC sessions to a second host (i.e., VNC tunneling). > Web proxies on any port where a connection occurs to the web server and a second web session is established to the second host (i.e., Web proxy chaining). Systems such as multi-user web based email systems, authorized web proxies, SSH bastion hosts and public anonymous FTP servers will likely have inbound and outbound TCP sessions that trigger LCE. To best use the LCE, create asset lists within SecurityCenter or the LCE user interface that contain IP addresses that do not normally have session interaction. Copyright 2002-2012 Tenable Network Security, Inc. 31

The LCE will also alert on instant proxy devices and create logs when it sees a host receive a connection and then start a connection soon after. It performs this type of analysis on PVS real-time logs for VNC, RDP (Windows Terminal Services), and SSH (Secure Shell) sessions. For example, if you have a public-facing FTP server and a web server, it is very unlikely that the web server makes any connections to anyone else as it receives queries on port 80. However, it is likely that the FTP server will make connections to hosts downloading files. As such, consider creating alerts or dashboard elements for the systems that are less likely to have two legitimate sessions look like they have allowed someone to proxy access to a network resource. When a Suspicious Proxy alert is generated, the LCE attempts to summarize all other TCP sessions that occurred during that time period. PVS Encryption and Interactive Session Detection The Passive Vulnerability Scanner (PVS) will generate a log message for any session it observes that is random enough to be encrypted or have a latency pattern of packets that possibly indicates a human typing. These events are generated for inbound, outbound, and internal to the range of IP addresses or networks that the PVS is configured to monitor. PVS will not only identify encrypted sessions that you expect to be encrypted, such as port 22 SSH traffic or port 443 HTTPS traffic, it will also identify ports that you may be unaware are carrying encrypted data. For example, the following is a set of sanitized logs for a PVS Internal Encrypted Session event between a Nessus scanner hosted at Amazon and a system with a private IP address: The Nessus scanner was running on port 8443. The event was considered internal because the network address ranges the PVS was given to monitor included both the Amazon server IP addresses and the internal 192.168.1.0/24 range. There are several benefits and strategies you can use to help monitor encryption and interactive sessions on your network with the PVS: > It is an excellent forensic resource when dealing with a compromised system or potential botnet. > Alerts can be created for production systems to look for encryption or interactive sessions that should not be occurring. > SecurityCenter or LCE users can summarize the ports and assets encrypted or interactive sessions are occurring on to identify potential backdoors and compromised systems. Copyright 2002-2012 Tenable Network Security, Inc. 32

Correlating Network Sessions with Botnet Threatlists The LCE correlates network sessions with hostile or threatening Internet addresses. For each network session, the LCE tests the source and destination IP addresses against the list of hostile addresses. All network sessions that correlate with these IP addresses are normalized as secondary events to the threatlist event type. For example, if the TNM observed a connection from a threat listed IP address, it is logged normally and a second event is generated. The focus of this correlation is to see when your systems connect outward to a known hostile IP address. When this occurs, it is very likely that one of your systems is infected or being controlled by a botnet. The following outbound events are generated by the LCE: > Inbound_Threatlist_Connection generic connection attempts occurring from threatening IP address to one of the IP addresses on your network > Outbound_Threatlist_Connection_FTP an outbound session was observed from one of your systems to an external threatening IP address on the port commonly used for the File Transfer Protocol, port 21 > Outbound_Threatlist_Connection_SSH an outbound session was observed from one of your systems to an external threatening IP address on the port commonly used for Secure Shell, port 22 > Outbound_Threatlist_Connection_HTTP an outbound session was observed from one of your systems to an external threatening IP address on the port commonly used for unencrypted web browsing on port 80 > Outbound_Threatlist_Connection_HTTPS an outbound session was observed from one of your systems to an external threatening IP address on the port commonly used for encrypted web browsing on port 443 > Outbound_Threatlist_Connection_IRC an outbound session was observed from one of your systems to an external threatening IP address on the port commonly used for Internet Relay Chat communication on a port from 6660 through 6669 > Outbound_Threatlist_Connection_Low_Port an outbound session was observed from one of your systems to an external threatening IP address on a port between 1 and 1024 > Outbound_Threatlist_Connection_High_Port an outbound session was observed from one of your systems to an external threatening IP address on a port between 1025 and 65535 The main reason for separating outbound connections by ports in discrete events is to mitigate false positives on threat listed web sites. Outbound connections over ports 80 and 443 should all be investigated, but often there are potential issues for false positives including: > A malicious web site and hundreds of other legitimate web sites may share the same IP address due to common Internet site hosting configurations. > Hostile web sites are often fixed very quickly so what was once a hostile web site is now rendered harmless to the user. In general, any type of multipurpose Internet resource could be listed as a threat but still contains many different legitimate types of data. For example, an IRC server could be Copyright 2002-2012 Tenable Network Security, Inc. 33

blacklisted because it carries a channel used to control a botnet even though there are thousands of legitimate conversations occurring. When you have an inbound connection or set of connections from a threatlisted IP address, perform the following types of analysis: > Identify the port or ports targeted. > Identify if any network sessions were longer than any others. For example, a botnet may be sweeping the Internet looking for exploitable MySQL services. If it connected to 50 MySQL servers on your network and 49 of the connections were only a few bytes, but the last MySQL server had multiple sessions, long sessions or other types of activity, the system may have been exploited. > Attempt to identify any other log sources (IDS, firewall, syslog data, etc.) from that IP address to identify if any other types of malicious activity occurred. > If you identified a port as being of interest, check to see general activity on that port from any host, not just the hostile IP address. > See how far back in time you may have had events that contained evidence of visits from that IP address before it was considered to be a threat. The best way to analyze outbound connections is with real-time file logs from the Passive Vulnerability Scanner, or host system logs so you can see what applications were running at the time of connection. Attempt to answer questions about the outbound connection such as: > What other websites was this IP address visiting? PVS web logs as well as proxy logs can help answer this. > Was any potentially hostile content recently downloaded? The PVS web logs and some proxy logs can help identify when PDF files, movie files and other types of potentially hostile content were downloaded. > If system logs are present, were there were any new process event types? Any system errors or any crashed applications could indicate the presence of hostile software. If logs from an intrusion detection system are available, attempt to see if any of the hosts connected to are attempting to attack other Internet or local hosts by looking for scanning events or intrusion events. Finally, keep in mind that events from the ThreatList correlation are also fed into the Never Before Seen and continuous correlations of the LCE as well as the stats engine. The LCE can generate a set of first time threatlist correlations as well as anomalies in these logs. Detecting Statistical Network Deviations The LCE stats daemon will identify statistical network events for each host just like any other event type. The following is a screen capture that shows seven days of statistical network events from a small server farm: Copyright 2002-2012 Tenable Network Security, Inc. 34

Organizations where network usage tends to be different day to day will see changes similar to what is shown above. When analyzing the 25 Large Anomalies, it was evident that a new host was added to the network and the stats daemon was learning what is normal for that host. Firewall rule changes, new types of applications, new hosts, as well as compromised systems that use systems differently than before, will all generate usage patterns different enough for the stats daemon to pick up on. The stats daemon works on a per-event basis. This means that an event anomaly is identified by comparing the previous occurrences of that event. Since the network event type consists of events associated with short network sessions, network sessions based on bandwidth and network sessions based on length, the anomalies are generated along these lines as well. For example, the following is a screen capture that shows logs from a spike in short TCP sessions as well as UDP activity events: It is expected to see stats events when the usage of a network node changes. For example, if a web site added a new flash video and there was spike in people watching this video, there should also be a spike in TNM-TCP_Session_Whole-1-10MB events. WEB SERVER LOGS Background Web server logs from Apache, Microsoft IIS, and NCSA-compliant sources are normalized to the event types of web-access and web-error. These types consider valid requests and invalid requests. Tracking valid requests allows an organization to identify which web servers are the most busy, least busy and which hosted web sites are the most popular. Tracking requests that cause errors allows discovery of misconfigured servers, content that is no longer active as well as many types of network attacks. What You May Be Missing If you do not have your system configured to generate and collect web server logs, you are missing out on the following benefits: > If you have any SSL based web services and have a network IDS that is configured to decrypt your SSL session, gathering web logs with the LCE can help identify attacks and provide a forensic trail if an incident happens. Copyright 2002-2012 Tenable Network Security, Inc. 35

> There are different types of evasion techniques that can be used to send HTTP attacks past a NIDS that end up creating regular web logs. Gathering these with the LCE can help identify these types of attacks. > If you are gathering system logs and have configured an LCE client to tail the actual web access and error logs, you get a more complete correlation of log data. Automating Web Server Probe and Attack Detection The LCE considers the footprint of unique types of web errors generated by an IP address. When three or more unique types of errors are generated by a remote IP address, a Web_Server_Scan log is reported. When a remote IP address generates an error log on three or more different web servers, a Web_Servers_Scanned event is reported. Both events allows for quick identification of scans against one web server as well as sweeps of the network for web services. These events are also sent to the intrusion event type so they can be more easily analyzed with other network IDS and attack detection logs. Following is an example trend of these alerts for the past 24 hours of a virtual e-commerce store web site: Following is a screen capture of a Web_Server_Scan log: Detecting Long Term Web Errors The LCE identifies many different types of errors and intrusion logs that can indicate abuse. One source of normalized events that it subscribes to is web errors. In the screen capture below, we can see that there has been a series of 169 events indicating long term web error activity. This could mean several different things: > The network or application has an automated process that is routinely asking for the same web files that are no longer there. Copyright 2002-2012 Tenable Network Security, Inc. 36

> There is a caching issue of some sort and there has been a repeated erroneous request for the same file that no longer exists. > There is an ongoing web application scan. Hostile web application scans come in two flavors. The first is the simple case where an attacker knows about a certain type of exploit and performs one query to test if their target is vulnerable or not. The second type of scan is much more exhaustive. Typically, a web application scan will attempt to try millions of different combinations to guess forms, application variables, and web pages. It is not uncommon for web application scans to last multiple hours if not days. During this time, there will likely be a continuous set of web error messages generated by the web server that will be alerted on by the LCE. ACTIVITY MONITORING DATABASE ACTIVITY MONITORING Background When it comes to monitoring database servers, the LCE consumes multiple types of events. These include: > Real-time SQL query, insert and delete information sniffed by Tenable s Passive Vulnerability Scanner (PVS) > Logs from the underlying Windows or Unix operating systems running the database > Logs from the actual database application such as MS SQL, MySQL or Oracle > Logs from database transactions The PVS sniffs network traffic in real-time and can create syslog messages for observed SQL transactions as well as SQL logins and login failures. These events are normalized to the database event type. The following is a screen capture of PVS data sniffed from a lightly used database at a major university: The PVS can sniff SQL database protocols used by Oracle, MySQL, and MS SQL. Logs from the actual database application get logged to the following event types: > application any type of database log not associated with an error, login, or logout > error any type of log from a database that indicates a crash, bug, error, or misconfiguration > login/login-failure logs from the database that indicate access by a program or user > startup logs from the database that indicate restarting, rebooting, reloading, reindexing, or otherwise tracking the availability of the database Copyright 2002-2012 Tenable Network Security, Inc. 37

The following is a screen capture of an LCE query for an event type of application and an event name filter of *SQL* : In this case, there were two types of SQL application in use: Microsoft SQL and MySQL. The application event type is generically used for normalization of any application source such as Exchange, Apache or sendmail. Logs from database transactions are not typically normalized by the LCE. However, all logs sent to the LCE can be compressed and made available for analysis with the Raw Logs search tool. Passive SQL Boundary Monitoring Tenable customers who leverage the PVS to perform SQL monitoring are in a unique position to audit all SQL queries that traverse their perimeters. A common task is to look for SQL activity that is inbound, internal, or outbound from your organization. Consider the following dashboard: In this example, we created three trend lines for sniffed SQL sessions that were inbound, internal, and outbound. We would expect to have most of our SQL activity to be from internal systems to other internal systems. However, Tenable has had customers who have had to monitor cloud-based SQL server usage. The PVS can easily detect outbound SQL traffic to databases hosted in the cloud. Similarly, there may be a need to detect cloudbased web applications making direct SQL queries to internal databases. Depending on your specific needs and security models, your boundary could be a virtual private network, an intranet, a partner extranet or a virtual server farm. You may also want to ensure that a development database does not query a production database. Finally, the PVS will report any SQL logins and login failures. The LCE normalizes these logs and places them in the login and login-failure event types accordingly. These types of Copyright 2002-2012 Tenable Network Security, Inc. 38

logs can be very useful for auditing database access by employees and applications for a variety of compliance regulations. Searching Sniffed SQL Statements Sniffed SQL statements read like a typical SQL database statement. Any of the keywords can be used to perform a text search of any log collected by the LCE or to search the output syslog data of a specific event query. For example, let s say that you know there was a table named EmployeeName that was accessed by a web application attack. There are 20,000 PVS Database Select Command events to sift through, most of which do not select the EmployeeName table. To quickly refine this search, select the PVS Database Select Command event, choose the Raw Syslog Events tool, and then in the Search dialog, enter in EmployeeName as shown below: This search will consider the logs from every matching PVS Database Select Command event. If you would like to search all logs you could also use the Raw Logs search tool. Below is an example PVS sniffed SQL log: <36>Mar 04 12:22:49 pvs: 172.30.3.2:0 172.30.3.2:0 6 7019 Database command logging version: 1.22 PVS has observed the following command from a database client to the database server (192.168.2.3): select @@version_comment limit 10!...select @@version_comment limit 1...desc RDLIST...desc RDLIST...LIST from LISTNODE INFO The keywords that would limit a generic raw log search to just sniffed SQL PVS logs would be: > pvs: all real-time PVS logs have this tag > Database command logging all sniffed SQL logs use this tag > select this will differentiate SQL SELECT statements from others This list would also be joined with your specific table name. The following is an example screen capture with the query populated as well as a keyword for the term EmployeeName : Copyright 2002-2012 Tenable Network Security, Inc. 39

Statistical and Never Before Seen Events for Passive SQL Logs Working with output from the LCE s stats daemon and from the Never Before Seen correlation can help find a variety of very interesting events related to database activity monitoring. The Never_Before_Seen-Database_Event is generated by the LCE when it receives a PVS SQL log from a host that has not generated a log of that event before. This event could mean two things: the host is new or this type of log really has not been seen before. If the host is indeed new, then it should be analyzed for acceptability. Does the SQL server really belong where it is on the network? Is it making queries across a boundary or perimeter it shouldn t? If the event is new, then who made this query and why? Perhaps the SQL developer has some debug code or is doing some manual work on the database. Perhaps the application that is making use of the SQL database has been compromised and new and malicious queries are being run. Statistical increases in PVS observed SQL queries will alert in one of the following event types: > Statistics-Database_Minor_Anomaly > Statistics-Database_Anomaly > Statistics-Database_Medium_Anomaly > Statistics-Database_Large_Anomaly If there is a spike in SQL queries, then the next step is to determine if the increased activity is something to be concerned about. During analysis, it is important to take the context of the situation into account. Maybe a database has failed over and the spike is really the result of a normal query load being sent to the secondary database server. Maybe the spike is the result of a denial of service attack on your application or perhaps the application s traffic is unusually high. Monitoring Database Systems in General As noted in the introduction, each database will generate a set of logs that are normalized into the LCE event types of application, error, login/login-failure, and startup. The underlying operating system will also contribute its logs to the LCE event categories of error, login/login-failure, process, startup, and system. Copyright 2002-2012 Tenable Network Security, Inc. 40

There are many approaches to analyzing these events and monitoring them for their impact to compliance, security, and availability. FILE ACCESS AND WEB BROWSING ACTIVITY Background The Passive Vulnerability Scanner (PVS) can log all file sharing activity that occurs over SMTP, HTTP, FTP, NFS and SMB (Windows file sharing) protocols. The file name that is being shared is logged as are the source and destination IP addresses. Following are some example PVS logs from various types of protocols. SMTP file Office 2010 attachment: <36>Mar 05 14:44:26 pvs: 172.129.11.231:0 172.129.11.231:0 6 7042 Email attachment detection The remote email client sent "HR-0905-HW.docx" as an attachment via the SMTP server at (174.26.240.164) INFO SMB Windows share of a calendar file: <36>Feb 11 15:33:39 pvs: 10.242.26.110:0 10.242.26.110:0 4 7021 SMB Client File Download the SMB client was most recently observed downloading '\mrsmith.ical' from the remote SMB file server on 158.27.20.142 HTTP download of bitmap image (BMP): <36>Nov 02 09:17:53 pvs: 172.30.2.42:0 172.30.2.42:0 6 7041 HTTP request detection The following GET/POST request was observed:;dip: 169.17.153.220:80;URI: css/iepngfix.bmp;referer: http://twiyia.com/latest.php?typeid=1;host: twiyia.com;user-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2;.NET CLR 2.0.50727;.NET CLR 3.5.30729;.NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2;.NET4.0C;.NET4.0E);version: 1.5 INFO The ability to passively sniff all files in movement across unencrypted protocols is a very useful asset. Data from this type of passive collection can be leveraged for forensics, employee monitoring, incident response, data leakage detection, virus infection analysis and a variety of regulations. The LCE normalizes these logs to the file-access event type. The following is a screen capture of sniffed SMB file sharing events from a university network of more than 4,000 students: Copyright 2002-2012 Tenable Network Security, Inc. 41

Common file extensions are used to create LCE normalized event names so that activity can be visualized at a glance. If an extension is not recognized, the file share is normalized to catch-all event types such as PVS-SMB-Client_File_Download. What You May Be Missing If you do not have your system configured to generate and collect file sharing activity logs, you are missing out on the following benefits: > Real-time logs of all file sharing can be very useful for employee monitoring, incident response and compliance reporting. > Some protocols, such as HTTP, may be logged by your web proxy, however, the PVS and LCE are optimized to parse HTTP, FTP, NFS, SMB, and SMTP in one spot. This makes searching and understanding data in motion much easier. > The LCE s ability to detect first seen events as well as statistical anomalies in all events means that irregularities in file sharing activity can be readily identified. > If your LCE is configured to leverage user ID-to-IP address tracking, you can use passive file access tracking to report on all files a user may have had access to. > If a system was compromised through hostile content, such as a malicious PDF file, the file name can be searched in general to see if anyone else on the network has accessed the file. Statistical File-Access Anomalies The LCE stats daemon will normalize file-access events just like any other LCE event type. The following is a screen capture of all statistical file sharing events associated with the previous screen capture of all file sharing events: Copyright 2002-2012 Tenable Network Security, Inc. 42

Drilling into the single large anomaly presented us with the following log file: This particular IP address downloaded more than 2,000 files during this time window while normally on average it grabbed 3 files. Using the sanitized IP address, the following set of events for that 24 hour period was observed: Using events from the stats daemon that relate to file sharing events is a great way to identify changes in how files are moving throughout your infrastructure. There are several strategies that can be used to audit, report, and alert on this type of data: > If you have user ID-to-IP address tracking, consider creating daily or weekly reports and dashboards that summarize the users who have had specific types of file sharing anomalies. This is an excellent method to monitor trusted insiders for potential abuse. > Create dashboard and reports that highlight anomalies on a per-asset basis. If you have file sharing resources such as a network share, FTP servers, or email servers, any type of spike in sharing activity could indicate a form of abuse. > When a spike is detected, try to identify why it occurred by considering the asset as well as any type of other logs. Try to determine if the spike was the result in a change in a regular business or IT process, a new user action or a potential compromise or malicious incident. Forensic Investigation Having access to all files that have been downloaded and viewable at one time can decrease the amount of time it takes to understand what a potentially compromised host was doing just before the event. The following screen capture summarizes eight days of file sharing activity for a given IP address and shows what the usage pattern of certain types of file access has been: Copyright 2002-2012 Tenable Network Security, Inc. 43

Some of the queries occurred almost continuously, such as the PVS- Web_File_XML_Request while on other days, different file access attempts stacked up next to each other. This at a glance view lets you visually look for different types of activity and changes in activity. If you have evidence of a host being compromised from another log source, such as a network IDS, correlating the start of behavior such as port scanning with which files were being downloaded can be of tremendous value. Depending on the virus or malware, some Tenable customers have reported logging the download of a PDF file and outbound worm scanning start within just a few minutes. Investigation of types of files and known files can also be of interest. For example, searching file names for words that can indicate classes of potentially unauthorized content such as adult content or gambling can help identify this sort of activity. If you want to find out how often a certain file, such as a corporate spreadsheet, is shared or transmitted on the network, simply searching for that in the logs can identify usage. Files Downloaded from Threatening Addresses The LCE ThreatList performs correlation between network sessions, PVS file download events, and connection events with lists of IP addresses that are known to be participating in botnet command and control. When this sort of correlation occurs, LCE will generate one of the three following events: > Outbound_Threatlist_Communication A generic file was detected being downloaded by the PVS from an IP address considered a threat > Outbound_Threatlist_JS_Download A JavaScript file was detected being downloaded by the PVS from an IP address considered a threat > Outbound_Threatlist_PDF_Download A PDF document was detected being downloaded by the PVS from an IP address considered a threat Detecting New Types of File Access The LCE analyzes file-access events that occur for the first time. In the following screen capture, it can be seen that there has been 224 file access events that have not been seen before in the past 24 hours: Copyright 2002-2012 Tenable Network Security, Inc. 44

Detecting that a host or server has accessed a file type for the first time is very useful for two important reasons: > It identifies when major types of new content are being hosted on purpose or maliciously. > It identifies when a node accesses existing content for the first time. If an attacker modifies a server and inserts new content that was not there before, they may add a new technology (.html,.pdf,.txt, etc.) that was not hosted before. This is not a guarantee. This type of analysis will not detect when a new.html file is added to a web server that was already detected to be hosting.html files. However, when it does occur, the LCE has generated a well-qualified alert about a new type of file being hosted. Similarly, if a virus, insider, or intruder is able to take control of a workstation, it is unlikely they would be able to browse the network in such a way that they would have the same exact footprint of accessed file types as the normal user. Imagine a hypothetical user who accesses PDF, Word and PowerPoint documents, and has his account broken into. The attacker then starts to download these types of files, but also spreadsheets, Access databases and text files. The LCE would generate alerts for these new types of files. Tenable has also worked with customers who were able to detect compromised systems simply by having the PVS record that they have reached out to the Internet to obtain new types of files via HTTP or FTP, which have not been seen before. USER ACTIVITY MONITORING WITH CENTRAL AUTHENTICATION Background The LCE includes the ability to keep track of which IP address a user ID is assigned and then apply this user ID to other events. For example, consider the following login event from an IMAP server: Jul 30 11:31:01 mail1 imaps[19785]: login: cpe-176-73-172-154.socal.res.rr.com [176.73.172.154] joeuser plaintext+tls User logged in The user joeuser is coming from address 176.73.172.154. Now consider this following SSH login failure event: Copyright 2002-2012 Tenable Network Security, Inc. 45

Jul 30 12:55:07 org1 sshd(pam_unix)[10129]: 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=176.73.172.154 user=root The login attempt was for the root user, but the source IP address of 176.73.172.154 is the same IP address that joeuser just logged into the IMAP server with. If you knew this relationship, an LCE user could manually type in the IP address of each user they wanted to keep track of, but this does not scale well. The good news is that the LCE can do this for you automatically across any event. To configure this in the LCE, you only need to do three things: 1. Decide which login events you want to use to be your IP addresses pivot 2. Find the LCE plugin ID for those events and place them into the trusted_plugins.txt file located in /opt/lce/admin 3. Restart the LCE All potential LCE plugin IDs that can be used for user ID tracking are listed at the end of the prm_map.prm file that is updated and stored in the /opt/lce/daemons/plugins directory. Which Authentication Logs? There are many types of authentication logs that your organization may have in use. There could be independent audit trails for VPN users, domain authentication, or email authentication. These resources could all point to the same LDAP authentication place. Regardless of which authentication you have in use, consider the IP addresses of what is involved and make sure there is relevant overlap. Many Tenable customers tend to use email authentication as central tracking log because it catches remote mobile users, users logging in from their home, VPN users, and users working centrally in an office. Other Tenable customers make use of Windows domain logins, which is excellent because it associates a user ID to each node participating in the network. In some cases, log correlation does not make sense. For example, consider a network that has extensive NetFlow and network IDS coverage of their DMZ, but all user access originates from an RFC1918 network through a single firewall using Network Address Translation (NAT). In this case, all outbound network traffic from these users would have the external NAT IP address and this would not be relevant to the internet IP address of the user. Multiple and Migrating IPs per User The LCE will track users as they login from new IP addresses. An event named user-ipchange is generated when a login occurs. The following is an example log from such a transition: Network user IP address change: user joeuser became active at 172.20.101.203 with event IMAP-User_Login2 (172.20.101.203:0 -> 172.20.210.11:0). In this case, 172.20.210.11 was the IP address of the IMAP server. If your users have multiple devices that authenticate, it is likely to have each IP address be associated with the Copyright 2002-2012 Tenable Network Security, Inc. 46

user. In addition, if a local user is migrating through your network, such as moving on a wireless device and getting a new DHCP addresses, you may see many types of these events. Additional PVS User Activity Events In the File Access and Web Browsing Activity section, we focused on the actual transfer of files via HTTP, SMB, NFS, FTP, and SMTP. In addition to these, the PVS will generate several very useful types of alerting including: > Logins to social media sites such as Twitter, Facebook, and LinkedIn > Logins to Gmail, Yahoo, and other email services > Logins to chat services such as AIM, Google Chat, and IRC > Generic logins to IMAP and POP email services > Internet search queries to Google, Bing, Bandu, and Wikipedia The Internet search queries are normalized to the event type of file-access while the other events are normalized to the social-networks event type. Pivoting From Events to Users Once user ID-to-IP address tracking is in place, there are many types of pivots that can be accomplished. A pivot is simply taking an existing LCE query and then re-issuing it with the User Summary tool. Following is a table of some very interesting and useful filters that can be used to track abuse, security issues, and compliance issues by user. Query event = PVS-SMB* type = intrusion event = PVS-Email* Analysis Would summarize all users who have shared files via SMB. Would view all users who have had an IDS event associated with them. Lists which users have sent email attachments. type = login-failure type = error event = *1GB and type = network type = firewall and direction = outbound type = social-networks Would list all users who have had login-failure events. This would let you easily see which users had different patterns of long term login failures and visually see the difference between users. Allows seeing which users had errors associated with their systems. Lists all users who had one or more network sessions transferring 1 GB of data. Lists which users have run into some sort of outbound egress firewall filter. Allows user activity comparisons of events that detect Facebook, Twitter and other types of social networking activities. Copyright 2002-2012 Tenable Network Security, Inc. 47

ip address = corporate IP address of server event = Web_Query_Google_Search type = stats Lists all users who have some sort of log or event that is associated with an IP address or server of interest. Could be used to create a list of users who have logged in to a resource. Compare various user rates of Google search engine usage. Shows an at a glance view of anomalies in users. type = stats and event = *File_Access* Shows relative file access anomalies. When working with just one user, there are two summary reports from various LCEs that are excellent sources for detailed reporting. These are listed below: Event Domain_Summary Daily_Command_Summary Report Lists all unique domains queried for. When filtered on with a specific user ID, this becomes the domains queried for by that user. Lists all unique applications executed on the systems where the user ID was active. Copyright 2002-2012 Tenable Network Security, Inc. 48

ABOUT TENABLE NETWORK SECURITY Tenable Network Security, the leader in Unified Security Monitoring, is the source of the Nessus vulnerability scanner and the creator of enterprise-class, agentless solutions for the continuous monitoring of vulnerabilities, configuration weaknesses, data leakage, log management, and compromise detection to help ensure network security and FDCC, FISMA, SANS CAG, and PCI compliance. Tenable s award-winning products are utilized by many Global 2000 organizations and Government agencies to proactively minimize network risk. For more information, please visit http://www.tenable.com. Tenable Network Security, Inc. 7063 Columbia Gateway Drive Suite 100 Columbia, MD 21046 410.872.0555 www.tenable.com Copyright 2002-2012 Tenable Network Security, Inc. 49