Log Correlation Engine Best Practices

Size: px
Start display at page:

Download "Log Correlation Engine Best Practices"

Transcription

1 Log Correlation Engine Best Practices August 14, 2012 (Revision 3) Copyright 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 Columbia Gateway Drive, Suite 100, Columbia, MD

2 Table of Contents Introduction... 4 Log Types 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 Tenable Network Security, Inc. 2

3 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 Tenable Network Security, Inc. 3

4 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 us at 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 Tenable Network Security, Inc. 4

5 > 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 Tenable Network Security, Inc. 5

6 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 Tenable Network Security, Inc. 6

7 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 Tenable Network Security, Inc. 7

8 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 Tenable Network Security, Inc. 8

9 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 , 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 Tenable Network Security, Inc. 9

10 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 Tenable Network Security, Inc. 10

11 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 and wanted to ignore login failure alerts from it, you could create a special asset list that contained , 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 Tenable Network Security, Inc. 11

12 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 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 Tenable Network Security, Inc. 12

13 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 Tenable Network Security, Inc. 13

14 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 Tenable Network Security, Inc. 14

15 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 and treat 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 , 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 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 Tenable Network Security, Inc. 15

16 Following is a log that indicates that a DNS query has occurred: <134>named[7273]: queries: client #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 Tenable Network Security, Inc. 16

17 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 , 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 Tenable Network Security, Inc. 17

18 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 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 Tenable Network Security, Inc. 18

19 When a node is infected with malware that can be used to attack other computers or send spam , it is very likely that the computer will perform many DNS lookups for websites and 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 s, it is possible that the attempts to connect to the 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 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 message volume, web site popularity and even employee workload. However, a spike could also be associated with activity from comprised servers, malicious 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 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 Tenable Network Security, Inc. 19

20 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 (lap11109.home) and the most recent event was failed-query towards host (Wireless_Broadband_Router.home) at 2/7/ :21:09 We can see that the level of DNS lookups has been continuing for 140 minutes. In this case, 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 gateway performs a lot of DNS lookups that fail while sending 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 Tenable Network Security, Inc. 20

21 > 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 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 Tenable Network Security, Inc. 21

22 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 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 . This could indicate a user not complying with the local policy, a user with a misconfigured client or even one that has been compromised and is attempting to send (e.g., exfiltrating data, unsolicited bulk ). Copyright Tenable Network Security, Inc. 22

23 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 Tenable Network Security, Inc. 23

24 > 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 Tenable Network Security, Inc. 24

25 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 , 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 Tenable Network Security, Inc. 25

26 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 Tenable Network Security, Inc. 26

27 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 Tenable Network Security, Inc. 27

28 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 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 Tenable Network Security, Inc. 28

29 > 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, servers and streaming audio servers: Copyright Tenable Network Security, Inc. 29

30 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 Tenable Network Security, Inc. 30

31 > 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[ ]: :1488 -> :445 [u:0 d: ] 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 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 Tenable Network Security, Inc. 31

32 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 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 /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 Tenable Network Security, Inc. 32

33 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 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 Tenable Network Security, Inc. 33

34 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 Tenable Network Security, Inc. 34

35 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 Tenable Network Security, Inc. 35

36 > 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 Tenable Network Security, Inc. 36

37 > 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 Tenable Network Security, Inc. 37

38 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 Tenable Network Security, Inc. 38

39 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: : : Database command logging version: 1.22 PVS has observed the following command from a database client to the database server ( ): select limit 10!...select 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 Tenable Network Security, Inc. 39

40 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 Tenable Network Security, Inc. 40

41 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: : : attachment detection The remote client sent "HR-0905-HW.docx" as an attachment via the SMTP server at ( ) INFO SMB Windows share of a calendar file: <36>Feb 11 15:33:39 pvs: : : SMB Client File Download the SMB client was most recently observed downloading '\mrsmith.ical' from the remote SMB file server on HTTP download of bitmap image (BMP): <36>Nov 02 09:17:53 pvs: : : HTTP request detection The following GET/POST request was observed:;dip: :80;URI: css/iepngfix.bmp;referer: twiyia.com;user-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2;.NET CLR ;.NET CLR ;.NET CLR ; 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 Tenable Network Security, Inc. 41

42 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 Tenable Network Security, Inc. 42

43 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 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 Tenable Network Security, Inc. 43

44 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 Tenable Network Security, Inc. 44

45 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 socal.res.rr.com [ ] joeuser plaintext+tls User logged in The user joeuser is coming from address Now consider this following SSH login failure event: Copyright Tenable Network Security, Inc. 45

Security Event Management. February 7, 2007 (Revision 5)

Security Event Management. February 7, 2007 (Revision 5) Security Event Management February 7, 2007 (Revision 5) Table of Contents TABLE OF CONTENTS... 2 INTRODUCTION... 3 CRITICAL EVENT DETECTION... 3 LOG ANALYSIS, REPORTING AND STORAGE... 7 LOWER TOTAL COST

More information

June 8, 2011. (Revision 1)

June 8, 2011. (Revision 1) Unified Security Monitoring Best Practices June 8, 2011 (Revision 1) Copyright 2011. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of

More information

Unified Security Monitoring Best Practices

Unified Security Monitoring Best Practices Unified Security Monitoring Best Practices This white paper outlines several best practices when deploying and optimizing a USM platform to perform security and compliance monitoring for enterprise networks.

More information

April 11, 2011. (Revision 2)

April 11, 2011. (Revision 2) Passive Vulnerability Scanning Overview April 11, 2011 (Revision 2) Copyright 2011. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of

More information

Comprehensive Malware Detection with SecurityCenter Continuous View and Nessus. February 3, 2015 (Revision 4)

Comprehensive Malware Detection with SecurityCenter Continuous View and Nessus. February 3, 2015 (Revision 4) Comprehensive Malware Detection with SecurityCenter Continuous View and Nessus February 3, 2015 (Revision 4) Table of Contents Overview... 3 Malware, Botnet Detection, and Anti-Virus Auditing... 3 Malware

More information

24/7 Visibility into Advanced Malware on Networks and Endpoints

24/7 Visibility into Advanced Malware on Networks and Endpoints WHITEPAPER DATA SHEET 24/7 Visibility into Advanced Malware on Networks and Endpoints Leveraging threat intelligence to detect malware and exploitable vulnerabilities Oct. 24, 2014 Table of Contents Introduction

More information

Configuring Virtual Switches for Use with PVS. February 7, 2014 (Revision 1)

Configuring Virtual Switches for Use with PVS. February 7, 2014 (Revision 1) Configuring Virtual Switches for Use with PVS February 7, 2014 (Revision 1) Table of Contents Introduction... 3 Basic PVS VM Configuration... 3 Platforms... 3 VMware ESXi 5.5... 3 Configure the ESX Management

More information

May 11, 2011. (Revision 10)

May 11, 2011. (Revision 10) Blended Security Assessments Combining Active, Passive and Host Assessment Techniques May 11, 2011 (Revision 10) Renaud Deraison Director of Research Ron Gula Chief Technology Officer Copyright 2011. Tenable

More information

Protecting Critical Infrastructure

Protecting Critical Infrastructure Protecting Critical Infrastructure SCADA Network Security Monitoring March 20, 2015 Table of Contents Introduction... 4 SCADA Systems... 4 In This Paper... 4 SCADA Security... 4 Assessing the Security

More information

February 22, 2011. (Revision 2)

February 22, 2011. (Revision 2) Real-Time Massachusetts Data Security Law Monitoring Leveraging Asset-Based Configuration and Vulnerability Analysis with Real-Time Event Management February 22, 2011 (Revision 2) Copyright 2011. Tenable

More information

Blended Security Assessments

Blended Security Assessments Blended Security Assessments Combining Active, Passive and Host Assessment Techniques October 12, 2009 (Revision 9) Renaud Deraison Director of Research Ron Gula Chief Technology Officer Table of Contents

More information

3D Tool 2.0 Quick Start Guide

3D Tool 2.0 Quick Start Guide www.tenable.com sales@tenable.com 3D Tool 2.0 Quick Start Guide ABOUT THE 3D TOOL Tenable s 3D Tool is a Windows application that is used to query data from a SecurityCenter 4 server and present it in

More information

Architecture Overview

Architecture Overview Architecture Overview Design Fundamentals The networks discussed in this paper have some common design fundamentals, including segmentation into modules, which enables network traffic to be isolated and

More information

January 4, 2011. (Revision 1) The newest version of this document is available at the following URL: http://cgi.tenable.com/lce_3.6_stats.

January 4, 2011. (Revision 1) The newest version of this document is available at the following URL: http://cgi.tenable.com/lce_3.6_stats. Log Correlation Engine 3.6 Statistics Daemon Guide January 4, 2011 (Revision 1) The newest version of this document is available at the following URL: http://cgi.tenable.com/lce_3.6_stats.pdf Copyright

More information

Concierge SIEM Reporting Overview

Concierge SIEM Reporting Overview Concierge SIEM Reporting Overview Table of Contents Introduction... 2 Inventory View... 3 Internal Traffic View (IP Flow Data)... 4 External Traffic View (HTTP, SSL and DNS)... 5 Risk View (IPS Alerts

More information

Chapter 9 Firewalls and Intrusion Prevention Systems

Chapter 9 Firewalls and Intrusion Prevention Systems Chapter 9 Firewalls and Intrusion Prevention Systems connectivity is essential However it creates a threat Effective means of protecting LANs Inserted between the premises network and the to establish

More information

Using Nessus to Detect Wireless Access Points. March 6, 2015 (Revision 4)

Using Nessus to Detect Wireless Access Points. March 6, 2015 (Revision 4) Using Nessus to Detect Wireless Access Points March 6, 2015 (Revision 4) Table of Contents Introduction... 3 Why Detect Wireless Access Points?... 3 Wireless Scanning for WAPs... 4 Detecting WAPs using

More information

SANS Top 20 Critical Controls for Effective Cyber Defense

SANS Top 20 Critical Controls for Effective Cyber Defense WHITEPAPER SANS Top 20 Critical Controls for Cyber Defense SANS Top 20 Critical Controls for Effective Cyber Defense JANUARY 2014 SANS Top 20 Critical Controls for Effective Cyber Defense Summary In a

More information

Configuration Information

Configuration Information This chapter describes some basic Email Security Gateway configuration settings, some of which can be set in the first-time Configuration Wizard. Other topics covered include Email Security interface navigation,

More information

Speed Up Incident Response with Actionable Forensic Analytics

Speed Up Incident Response with Actionable Forensic Analytics WHITEPAPER DATA SHEET Speed Up Incident Response with Actionable Forensic Analytics Close the Gap between Threat Detection and Effective Response with Continuous Monitoring January 15, 2015 Table of Contents

More information

May 11, 2011. (Revision 4) Ron Gula Chief Technology Officer

May 11, 2011. (Revision 4) Ron Gula Chief Technology Officer Correlating IDS Alerts with Vulnerability Information May 11, 2011 (Revision 4) Ron Gula Chief Technology Officer Copyright 2011. Tenable Network Security, Inc. All rights reserved. Tenable Network Security

More information

WildFire Reporting. WildFire Administrator s Guide 55. Copyright 2007-2015 Palo Alto Networks

WildFire Reporting. WildFire Administrator s Guide 55. Copyright 2007-2015 Palo Alto Networks WildFire Reporting When malware is discovered on your network, it is important to take quick action to prevent spread of the malware to other systems. To ensure immediate alerts to malware discovered on

More information

Automate PCI Compliance Monitoring, Investigation & Reporting

Automate PCI Compliance Monitoring, Investigation & Reporting Automate PCI Compliance Monitoring, Investigation & Reporting Reducing Business Risk Standards and compliance are all about implementing procedures and technologies that reduce business risk and efficiently

More information

Global Partner Management Notice

Global Partner Management Notice Global Partner Management Notice Subject: Critical Vulnerabilities Identified to Alert Payment System Participants of Data Compromise Trends Dated: May 4, 2009 Announcement: To support compliance with

More information

Patch Management Integration

Patch Management Integration Patch Management Integration January 10, 2012 (Revision 5) Copyright 2002-2012 Tenable Network Security, Inc. Tenable Network Security, Nessus and ProfessionalFeed are registered trademarks of Tenable

More information

SecurityCenter 4.2 Administration Guide

SecurityCenter 4.2 Administration Guide SecurityCenter 4.2 Administration Guide January 24, 2012 (Revision 5) The newest version of this document is available at the following URL: http://static.tenable.com/prod_docs/securitycenter_4.2_admin_guide.pdf

More information

Web Application Vulnerability Testing with Nessus

Web Application Vulnerability Testing with Nessus The OWASP Foundation http://www.owasp.org Web Application Vulnerability Testing with Nessus Rïk A. Jones, CISSP rikjones@computer.org Rïk A. Jones Web developer since 1995 (16+ years) Involved with information

More information

SonicWALL Global Management System ViewPoint Guide. Version 2.1

SonicWALL Global Management System ViewPoint Guide. Version 2.1 SonicWALL Global Management System ViewPoint Guide Version 2.1 Copyright Information 2001 SonicWALL, Inc. All rights reserved. Under the copyright laws, this manual or the software described within, may

More information

How I Learned to Stop Worrying and Love Compliance Ron Gula, CEO Tenable Network Security

How I Learned to Stop Worrying and Love Compliance Ron Gula, CEO Tenable Network Security How I Learned to Stop Worrying and Love Compliance Ron Gula, CEO Tenable Network Security PART 1 - COMPLIANCE STANDARDS PART 2 SECURITY IMPACT THEMES BUILD A MODEL THEMES MONITOR FOR FAILURE THEMES DEMONSTRATE

More information

SecurityCenter 5.1 with Nessus Agent Support. October 22, 2015

SecurityCenter 5.1 with Nessus Agent Support. October 22, 2015 SecurityCenter 5.1 with Nessus Agent Support October 22, 2015 Table of Contents Introduction... 3 Adding an Agent Repository... 6 Add Agent Scans and Import Agent Scan Results... 7 Tips and Tricks... 8

More information

SonicWALL PCI 1.1 Implementation Guide

SonicWALL PCI 1.1 Implementation Guide Compliance SonicWALL PCI 1.1 Implementation Guide A PCI Implementation Guide for SonicWALL SonicOS Standard In conjunction with ControlCase, LLC (PCI Council Approved Auditor) SonicWall SonicOS Standard

More information

Nessus Enterprise Cloud User Guide. October 2, 2014 (Revision 9)

Nessus Enterprise Cloud User Guide. October 2, 2014 (Revision 9) Nessus Enterprise Cloud User Guide October 2, 2014 (Revision 9) Table of Contents Introduction... 3 Nessus Enterprise Cloud... 3 Subscription and Activation... 3 Multi Scanner Support... 4 Customer Scanning

More information

Tenable Network Security Support Portal. January 12, 2015 (Revision 14)

Tenable Network Security Support Portal. January 12, 2015 (Revision 14) Tenable Network Security Support Portal January 12, 2015 (Revision 14) Table of Contents Introduction... 3 Activate Tenable Support Portal... 3 Locate Your Customer ID... 6 Manage Your Activation Codes...

More information

AlienVault. Unified Security Management (USM) 5.x Policy Management Fundamentals

AlienVault. Unified Security Management (USM) 5.x Policy Management Fundamentals AlienVault Unified Security Management (USM) 5.x Policy Management Fundamentals USM 5.x Policy Management Fundamentals Copyright 2015 AlienVault, Inc. All rights reserved. The AlienVault Logo, AlienVault,

More information

Nessus and Mobile Device Scanning. November 7, 2014 (Revision 12)

Nessus and Mobile Device Scanning. November 7, 2014 (Revision 12) Nessus and Mobile Device Scanning November 7, 2014 (Revision 12) Table of Contents Introduction... 3 Standards and Conventions... 3 Overview... 3 Scanning for Mobile Devices with Nessus... 4 Creating a

More information

NetFlow Analytics for Splunk

NetFlow Analytics for Splunk NetFlow Analytics for Splunk User Manual Version 3.5.1 September, 2015 Copyright 2012-2015 NetFlow Logic Corporation. All rights reserved. Patents Pending. Contents Introduction... 3 Overview... 3 Installation...

More information

Cyber Essentials. Test Specification

Cyber Essentials. Test Specification Cyber Essentials Test Specification Contents Scope of the Audit...2 Assumptions...3 Success Criteria...3 External systems...4 Required tests...4 Test Details...4 Internal systems...7 Tester pre-requisites...8

More information

SecurityCenter 4.4 Administration Guide

SecurityCenter 4.4 Administration Guide SecurityCenter 4.4 Administration Guide September 18, 2012 (Revision 3) The newest version of this document is available at the following URL: http://static.tenable.com/prod_docs/securitycenter_4.4_admin_guide.pdf

More information

Managed Intrusion, Detection, & Prevention Services (MIDPS) Why E-mail Sorting Solutions? Why ProtectPoint?

Managed Intrusion, Detection, & Prevention Services (MIDPS) Why E-mail Sorting Solutions? Why ProtectPoint? Managed Intrusion, Detection, & Prevention Services (MIDPS) Why E-mail Sorting Solutions? Why ProtectPoint? Why? Focused on Managed Intrusion Security Superior-Architected Hardened Technology Security

More information

GFI White Paper PCI-DSS compliance and GFI Software products

GFI White Paper PCI-DSS compliance and GFI Software products White Paper PCI-DSS compliance and Software products The Payment Card Industry Data Standard () compliance is a set of specific security standards developed by the payment brands* to help promote the adoption

More information

GFI Product Manual. Administration and Configuration Manual

GFI Product Manual. Administration and Configuration Manual GFI Product Manual Administration and Configuration Manual http://www.gfi.com info@gfi.com The information and content in this document is provided for informational purposes only and is provided "as is"

More information

CS 356 Lecture 17 and 18 Intrusion Detection. Spring 2013

CS 356 Lecture 17 and 18 Intrusion Detection. Spring 2013 CS 356 Lecture 17 and 18 Intrusion Detection Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists

More information

Introduction of Intrusion Detection Systems

Introduction of Intrusion Detection Systems Introduction of Intrusion Detection Systems Why IDS? Inspects all inbound and outbound network activity and identifies a network or system attack from someone attempting to compromise a system. Detection:

More information

Log Correlation Engine Log Normalization Guide. December 22, 2014 (Revision 2)

Log Correlation Engine Log Normalization Guide. December 22, 2014 (Revision 2) Log Correlation Engine Log Normalization Guide December 22, 2014 (Revision 2) Table of Contents Introduction... 3 Standards and Conventions... 3 Log Parsing and Normalization... 3 Architecture... 3 Normalization...

More information

Configuration Information

Configuration Information Configuration Information Email Security Gateway Version 7.7 This chapter describes some basic Email Security Gateway configuration settings, some of which can be set in the first-time Configuration Wizard.

More information

STARTER KIT. Infoblox DNS Firewall for FireEye

STARTER KIT. Infoblox DNS Firewall for FireEye STARTER KIT Introduction Infoblox DNS Firewall integration with FireEye Malware Protection System delivers a unique and powerful defense against Advanced Persistent Threats (APT) for business networks.

More information

74% 96 Action Items. Compliance

74% 96 Action Items. Compliance Compliance Report PCI DSS 2.0 Generated by Check Point Compliance Blade, on July 02, 2013 11:12 AM 1 74% Compliance 96 Action Items Upcoming 0 items About PCI DSS 2.0 PCI-DSS is a legal obligation mandated

More information

Guide to DDoS Attacks December 2014 Authored by: Lee Myers, SOC Analyst

Guide to DDoS Attacks December 2014 Authored by: Lee Myers, SOC Analyst INTEGRATED INTELLIGENCE CENTER Technical White Paper William F. Pelgrin, CIS President and CEO Guide to DDoS Attacks December 2014 Authored by: Lee Myers, SOC Analyst This Center for Internet Security

More information

APPLICATION PROGRAMMING INTERFACE

APPLICATION PROGRAMMING INTERFACE DATA SHEET Advanced Threat Protection INTRODUCTION Customers can use Seculert s Application Programming Interface (API) to integrate their existing security devices and applications with Seculert. With

More information

Nessus Enterprise for Amazon Web Services (AWS) Installation and Configuration Guide. July 16, 2014 (Revision 2)

Nessus Enterprise for Amazon Web Services (AWS) Installation and Configuration Guide. July 16, 2014 (Revision 2) Nessus Enterprise for Amazon Web Services (AWS) Installation and Configuration Guide July 16, 2014 (Revision 2) Table of Contents Introduction... 3 Requirements... 3 Standards and Conventions... 3 Nessus

More information

Outcome Based Security Monitoring in a Continuous Monitoring World

Outcome Based Security Monitoring in a Continuous Monitoring World Outcome Based Security Monitoring in a Continuous Monitoring World December 2012 Ron Gula Chief Executive Officer / Chief Technology Officer White Paper Copyright 2002-2012 Tenable Network Security, Inc.

More information

Nessus Perimeter Service User Guide (HTML5 Interface) March 18, 2014 (Revision 9)

Nessus Perimeter Service User Guide (HTML5 Interface) March 18, 2014 (Revision 9) Nessus Perimeter Service User Guide (HTML5 Interface) March 18, 2014 (Revision 9) Table of Contents Introduction... 3 Nessus Perimeter Service... 3 Subscription and Activation... 3 Multi Scanner Support...

More information

Networking for Caribbean Development

Networking for Caribbean Development Networking for Caribbean Development BELIZE NOV 2 NOV 6, 2015 w w w. c a r i b n o g. o r g N E T W O R K I N G F O R C A R I B B E A N D E V E L O P M E N T BELIZE NOV 2 NOV 6, 2015 w w w. c a r i b n

More information

Configuring PA Firewalls for a Layer 3 Deployment

Configuring PA Firewalls for a Layer 3 Deployment Configuring PA Firewalls for a Layer 3 Deployment Configuring PAN Firewalls for a Layer 3 Deployment Configuration Guide January 2009 Introduction The following document provides detailed step-by-step

More information

F-SECURE MESSAGING SECURITY GATEWAY

F-SECURE MESSAGING SECURITY GATEWAY F-SECURE MESSAGING SECURITY GATEWAY DEFAULT SETUP GUIDE This guide describes how to set up and configure the F-Secure Messaging Security Gateway appliance in a basic e-mail server environment. AN EXAMPLE

More information

Security Threat Kill Chain What log data would you need to identify an APT and perform forensic analysis?

Security Threat Kill Chain What log data would you need to identify an APT and perform forensic analysis? Security Threat Kill Chain What log data would you need to identify an APT and perform forensic analysis? This paper presents a scenario in which an attacker attempts to hack into the internal network

More information

HoneyBOT User Guide A Windows based honeypot solution

HoneyBOT User Guide A Windows based honeypot solution HoneyBOT User Guide A Windows based honeypot solution Visit our website at http://www.atomicsoftwaresolutions.com/ Table of Contents What is a Honeypot?...2 How HoneyBOT Works...2 Secure the HoneyBOT Computer...3

More information

CONNECTING TO DEPARTMENT OF COMPUTER SCIENCE SERVERS BOTH FROM ON AND OFF CAMPUS USING TUNNELING, PuTTY, AND VNC Client Utilities

CONNECTING TO DEPARTMENT OF COMPUTER SCIENCE SERVERS BOTH FROM ON AND OFF CAMPUS USING TUNNELING, PuTTY, AND VNC Client Utilities CONNECTING TO DEPARTMENT OF COMPUTER SCIENCE SERVERS BOTH FROM ON AND OFF CAMPUS USING TUNNELING, PuTTY, AND VNC Client Utilities DNS name: turing.cs.montclair.edu -This server is the Departmental Server

More information

JK0 015 CompTIA E2C Security+ (2008 Edition) Exam

JK0 015 CompTIA E2C Security+ (2008 Edition) Exam JK0 015 CompTIA E2C Security+ (2008 Edition) Exam Version 4.1 QUESTION NO: 1 Which of the following devices would be used to gain access to a secure network without affecting network connectivity? A. Router

More information

Decryption. Palo Alto Networks. PAN-OS Administrator s Guide Version 6.0. Copyright 2007-2015 Palo Alto Networks

Decryption. Palo Alto Networks. PAN-OS Administrator s Guide Version 6.0. Copyright 2007-2015 Palo Alto Networks Decryption Palo Alto Networks PAN-OS Administrator s Guide Version 6.0 Contact Information Corporate Headquarters: Palo Alto Networks 4401 Great America Parkway Santa Clara, CA 95054 www.paloaltonetworks.com/company/contact-us

More information

Passive Vulnerability Detection

Passive Vulnerability Detection Page 1 of 5 Passive Vulnerability Detection "Techniques to passively find network security vulnerabilities" Ron Gula rgula@securitywizards.com September 9, 1999 Copyright 1999 Network Security Wizards

More information

Network Security. Tampere Seminar 23rd October 2008. Overview Switch Security Firewalls Conclusion

Network Security. Tampere Seminar 23rd October 2008. Overview Switch Security Firewalls Conclusion Network Security Tampere Seminar 23rd October 2008 1 Copyright 2008 Hirschmann 2008 Hirschmann Automation and and Control GmbH. Contents Overview Switch Security Firewalls Conclusion 2 Copyright 2008 Hirschmann

More information

ANNEXURE-1 TO THE TENDER ENQUIRY NO.: DPS/AMPU/MIC/1896. Network Security Software Nessus- Technical Details

ANNEXURE-1 TO THE TENDER ENQUIRY NO.: DPS/AMPU/MIC/1896. Network Security Software Nessus- Technical Details Sub: Supply, Installation, setup and testing of Tenable Network Security Nessus vulnerability scanner professional version 6 or latest for scanning the LAN, VLAN, VPN and IPs with 3 years License/Subscription

More information

Top 5 Essential Log Reports

Top 5 Essential Log Reports Top 5 Essential Log Reports Version 1.0 Contributors: Chris Brenton - Independent Security Consultant - chris@chrisbrenton.org Tina Bird, Security Architect, PGP Corporation Marcus J Ranum, CSO, Tenable

More information

Computer Security CS 426 Lecture 36. CS426 Fall 2010/Lecture 36 1

Computer Security CS 426 Lecture 36. CS426 Fall 2010/Lecture 36 1 Computer Security CS 426 Lecture 36 Perimeter Defense and Firewalls CS426 Fall 2010/Lecture 36 1 Announcements There will be a quiz on Wed There will be a guest lecture on Friday, by Prof. Chris Clifton

More information

1 You will need the following items to get started:

1 You will need the following items to get started: QUICKSTART GUIDE 1 Getting Started You will need the following items to get started: A desktop or laptop computer Two ethernet cables (one ethernet cable is shipped with the _ Blocker, and you must provide

More information

The SIEM Evaluator s Guide

The SIEM Evaluator s Guide Using SIEM for Compliance, Threat Management, & Incident Response Security information and event management (SIEM) tools are designed to collect, store, analyze, and report on log data for threat detection,

More information

Network Security Platform 7.5

Network Security Platform 7.5 M series Release Notes Network Security Platform 7.5 Revision B Contents About this document New features Resolved issues Known issues Installation instructions Product documentation About this document

More information

Intrusion Detection in AlienVault

Intrusion Detection in AlienVault Complete. Simple. Affordable Copyright 2014 AlienVault. All rights reserved. AlienVault, AlienVault Unified Security Management, AlienVault USM, AlienVault Open Threat Exchange, AlienVault OTX, Open Threat

More information

Log Correlation Engine 3.6 Log Normalization Guide

Log Correlation Engine 3.6 Log Normalization Guide Log Correlation Engine 3.6 Log Normalization Guide May 31, 2011 (Revision 3) The newest version of this document is available at the following URL: http://cgi.tenable.com/lce_3.6_log_analysis.pdf Copyright

More information

FIREWALL POLICY November 2006 TNS POL - 008

FIREWALL POLICY November 2006 TNS POL - 008 FIREWALL POLICY November 2006 TNS POL - 008 Introduction Network Security Services (NSS), a department of Technology and Network Services, operates a firewall to enhance security between the Internet and

More information

Quick Start Guide: Utilizing Nessus to Secure Microsoft Azure

Quick Start Guide: Utilizing Nessus to Secure Microsoft Azure Quick Start Guide: Utilizing Nessus to Secure Microsoft Azure Introduction Tenable Network Security is the first and only solution to offer security visibility, Azure cloud environment auditing, system

More information

QUICK START GUIDE. Cisco C170 Email Security Appliance

QUICK START GUIDE. Cisco C170 Email Security Appliance 1 0 0 1 QUICK START GUIDE Email Security Appliance Cisco C170 303357 Cisco C170 Email Security Appliance 1 Welcome 2 Before You Begin 3 Document Network Settings 4 Plan the Installation 5 Install the Appliance

More information

A Guide to New Features in Propalms OneGate 4.0

A Guide to New Features in Propalms OneGate 4.0 A Guide to New Features in Propalms OneGate 4.0 Propalms Ltd. Published April 2013 Overview This document covers the new features, enhancements and changes introduced in Propalms OneGate 4.0 Server (previously

More information

Cisco IPS Tuning Overview

Cisco IPS Tuning Overview Cisco IPS Tuning Overview Overview Increasingly sophisticated attacks on business networks can impede business productivity, obstruct access to applications and resources, and significantly disrupt communications.

More information

Log Correlation Engine 4.2 Log Normalization Guide. October 3, 2013 (Revision 3)

Log Correlation Engine 4.2 Log Normalization Guide. October 3, 2013 (Revision 3) Log Correlation Engine 4.2 Log Normalization Guide October 3, 2013 (Revision 3) Table of Contents Introduction... 3 Standards and Conventions... 3 Log Parsing and Normalization... 3 Architecture... 3 Normalization...

More information

WHITEPAPER. Nessus Exploit Integration

WHITEPAPER. Nessus Exploit Integration Nessus Exploit Integration v2 Tenable Network Security has committed to providing context around vulnerabilities, and correlating them to other sources, such as available exploits. We currently pull information

More information

March 2012 www.tufin.com

March 2012 www.tufin.com SecureTrack Supporting Compliance with PCI DSS 2.0 March 2012 www.tufin.com Table of Contents Introduction... 3 The Importance of Network Security Operations... 3 Supporting PCI DSS with Automated Solutions...

More information

Log Correlation Engine Backup Strategy

Log Correlation Engine Backup Strategy Log Correlation Engine Backup Strategy August 10, 2012 (Revision 1) Copyright 2002-2012 Tenable Network Security, Inc. Tenable Network Security, Nessus and ProfessionalFeed are registered trademarks of

More information

Running the SANS Top 5 Essential Log Reports with Activeworx Security Center

Running the SANS Top 5 Essential Log Reports with Activeworx Security Center Running the SANS Top 5 Essential Log Reports with Activeworx Security Center Creating valuable information from millions of system events can be an extremely difficult and time consuming task. Particularly

More information

Juniper Secure Analytics Release Notes

Juniper Secure Analytics Release Notes Juniper Secure Analytics Release Notes 2014.5 February 2016 Juniper Networks is pleased to introduce JSA 2014.5. Juniper Secure Analytics (JSA) 2014.5 Release Notes provides new features, known issues

More information

Description of Actual State Sensor Types for the Software Asset Management (SWAM) Capability. 7 Jul 2014

Description of Actual State Sensor Types for the Software Asset Management (SWAM) Capability. 7 Jul 2014 Description of Actual State Sensor Types for the Software Asset Management (SWAM) Capability 7 Jul 2014 1 Purpose This document is intended to provide insight on the types of tools and technologies that

More information

Passive Logging. Intrusion Detection System (IDS): Software that automates this process

Passive Logging. Intrusion Detection System (IDS): Software that automates this process Passive Logging Intrusion Detection: Monitor events, analyze for signs of incidents Look for violations or imminent violations of security policies accepted use policies standard security practices Intrusion

More information

Using the Tenable Solution to Audit and Protect Firewalls, Routers, and Other Network Devices May 14, 2013 (Revision 1)

Using the Tenable Solution to Audit and Protect Firewalls, Routers, and Other Network Devices May 14, 2013 (Revision 1) Network Infrastructure Is Not Immune Using the Tenable Solution to Audit and Protect Firewalls, Routers, and Other Network Devices May 14, 2013 (Revision 1) Table of Contents Executive Summary... 3 Network

More information

Security+ Guide to Network Security Fundamentals, Fourth Edition. Chapter 6 Network Security

Security+ Guide to Network Security Fundamentals, Fourth Edition. Chapter 6 Network Security Security+ Guide to Network Security Fundamentals, Fourth Edition Chapter 6 Network Security Objectives List the different types of network security devices and explain how they can be used Define network

More information

Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs

Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs Why Network Security? Keep the bad guys out. (1) Closed networks

More information

Today s Topics. Protect - Detect - Respond A Security-First Strategy. HCCA Compliance Institute April 27, 2009. Concepts.

Today s Topics. Protect - Detect - Respond A Security-First Strategy. HCCA Compliance Institute April 27, 2009. Concepts. Protect - Detect - Respond A Security-First Strategy HCCA Compliance Institute April 27, 2009 1 Today s Topics Concepts Case Study Sound Security Strategy 2 1 Security = Culture!! Security is a BUSINESS

More information

Recommended Practice Case Study: Cross-Site Scripting. February 2007

Recommended Practice Case Study: Cross-Site Scripting. February 2007 Recommended Practice Case Study: Cross-Site Scripting February 2007 iii ACKNOWLEDGEMENT This document was developed for the U.S. Department of Homeland Security to provide guidance for control system cyber

More information

INCREASE NETWORK VISIBILITY AND REDUCE SECURITY THREATS WITH IMC FLOW ANALYSIS TOOLS

INCREASE NETWORK VISIBILITY AND REDUCE SECURITY THREATS WITH IMC FLOW ANALYSIS TOOLS WHITE PAPER INCREASE NETWORK VISIBILITY AND REDUCE SECURITY THREATS WITH IMC FLOW ANALYSIS TOOLS Network administrators and security teams can gain valuable insight into network health in real-time by

More information

SonicWALL Global Management System Reporting Guide Standard Edition

SonicWALL Global Management System Reporting Guide Standard Edition SonicWALL Global Management System Reporting Guide Standard Edition Version 2.9.4 Copyright Information 2005 SonicWALL, Inc. All rights reserved. Under the copyright laws, this manual or the software described

More information

INTRUSION DETECTION SYSTEMS and Network Security

INTRUSION DETECTION SYSTEMS and Network Security INTRUSION DETECTION SYSTEMS and Network Security Intrusion Detection System IDS A layered network security approach starts with : A well secured system which starts with: Up-to-date application and OS

More information

PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES

PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES PROTECTING INFORMATION SYSTEMS WITH FIREWALLS: REVISED GUIDELINES ON FIREWALL TECHNOLOGIES AND POLICIES Shirley Radack, Editor Computer Security Division Information Technology Laboratory National Institute

More information

Continuous Compliance for Energy and Nuclear Facility Cyber Security Regulations

Continuous Compliance for Energy and Nuclear Facility Cyber Security Regulations Continuous Compliance for Energy and Nuclear Facility Cyber Security Regulations Leveraging Configuration and Vulnerability Analysis for Critical Assets and Infrastructure May 2015 (Revision 2) Table of

More information

Proxy Blocking: Preventing Tunnels Around Your Web Filter. Information Paper August 2009

Proxy Blocking: Preventing Tunnels Around Your Web Filter. Information Paper August 2009 Proxy Blocking: Preventing Tunnels Around Your Web Filter Information Paper August 2009 Table of Contents Introduction... 3 What Are Proxies?... 3 Web Proxies... 3 CGI Proxies... 4 The Lightspeed Proxy

More information

SSL: A False Sense of Security? How the Tenable Solution Restores SSL Effectiveness and Mitigates Related Threats

SSL: A False Sense of Security? How the Tenable Solution Restores SSL Effectiveness and Mitigates Related Threats SSL: A False Sense of Security? How the Tenable Solution Restores SSL Effectiveness and Mitigates Related Threats White Paper Copyright 2002-2012 Tenable Network Security, Inc. Tenable Network Security,

More information

Network and Host-based Vulnerability Assessment

Network and Host-based Vulnerability Assessment Network and Host-based Vulnerability Assessment A guide for information systems and network security professionals 6600 Peachtree-Dunwoody Road 300 Embassy Row Atlanta, GA 30348 Tel: 678.443.6000 Toll-free:

More information

End-user Security Analytics Strengthens Protection with ArcSight

End-user Security Analytics Strengthens Protection with ArcSight Case Study for XY Bank End-user Security Analytics Strengthens Protection with ArcSight INTRODUCTION Detect and respond to advanced persistent threats (APT) in real-time with Nexthink End-user Security

More information

RAVEN, Network Security and Health for the Enterprise

RAVEN, Network Security and Health for the Enterprise RAVEN, Network Security and Health for the Enterprise The Promia RAVEN is a hardened Security Information and Event Management (SIEM) solution further providing network health, and interactive visualizations

More information