Log Correlation Engine 3.6 Architecture Guide

Transcription

1 Log Correlation Engine 3.6 Architecture Guide August 19, 2011 (Revision 5) The newest version of this document is available at the following URL: Copyright Tenable Network Security, Inc. Tenable Network Security, Nessus and ProfessionalFeed are registered trademarks of Tenable Network Security, Inc. Tenable, the Tenable logo, the Nessus logo, and/or other Tenable products referenced herein are trademarks of Tenable Network Security, Inc., and may be registered in certain jurisdictions. All other product names, company names, marks, logos, and symbols may be the trademarks of their respective owners. Tenable Network Security, Inc Columbia Gateway Drive, Suite 100, Columbia, MD

2 Table of Contents Introduction... 3 Standards and Conventions... 3 Architecture... 3 Components of the Log Correlation Engine... 3 Collection and Correlation... 6 Collection Only... 6 Event Collection, Normalization, Storage, Analysis and Response... 7 Event Correlation... 9 Behavior Modeling...11 Event Storage Model...12 Storage of Data in Silos...12 Silo Caching and Indexing...12 Going Forward...13 Prerequisites...13 Supported Operating Systems...13 Supported Log Sources...15 Licenses...17 The LCE Manager...17 SecurityCenter...17 Secure Shell Public Keys...18 For More Information...18 About Tenable Network Security...19 Appendix 1: Non-Tenable License Declarations...20 Related 3 rd Party and Open-Source Licenses...20 Introduction Copyright Tenable Network Security, Inc. 2

3 INTRODUCTION This document describes Tenable Network Security s Log Correlation Engine 3.6 including architecture, installation and configuration in both LCE Manager and SecurityCenter deployments. Please share your comments and suggestions with us by ing them to support@tenable.com. A working knowledge of Secure Shell, regular expressions and SecurityCenter operation and architecture is assumed. Familiarity with system log formats from various operating systems, network devices and applications and a basic understanding of Unix is also assumed. This document is intended to be used with LCE installations using version 3.6 and higher. STANDARDS AND CONVENTIONS Throughout the documentation, filenames, daemons and executables are indicated with a courier bold font such as gunzip, httpd and /etc/passwd. Command line options and keywords are also indicated with the courier bold font. Command line options may or may not include the command line prompt and output text from the results of the command. Often, the command being run will be boldfaced to indicate what the user typed. Below is an example running of the Unix pwd command. # pwd /opt/local/lce # Important notes and considerations are highlighted with this symbol and grey text boxes. Tips, examples and best practices are highlighted with this symbol and white on blue text. ARCHITECTURE COMPONENTS OF THE LOG CORRELATION ENGINE LCE servers can either be managed from the LCE Manager or SecurityCenter. Any documentation references to SecurityCenter pertain to SecurityCenter 4 unless otherwise noted. The LCE can only take advantage of vulnerability data if it is managed by a SecurityCenter. The LCE Manager user interface works only with event data. Copyright Tenable Network Security, Inc. 3

4 The Log Correlation Engine (LCE) is made up of three basic components: the LCE client, the LCE server (lced) and the user interface (SecurityCenter or LCE Manager). The LCE client collects and forwards events on to the LCE server daemon. When received by the LCE daemon, events can be stored as raw logs and normalized and correlated with vulnerabilities (if applicable). The user interface makes both the raw and normalized event data available to the user for event and vulnerability analysis and mitigation. The diagrams below demonstrate a high-level diagram of data flow and illustrate some of the differences between a SecurityCenter-based and LCE Manager-based LCE system: SecurityCenter-Based LCE Architecture Copyright Tenable Network Security, Inc. 4

5 LCE Manager-Based Architecture The Log Correlation Engine enables users to work with data from a wide variety of sources. Each organization can make queries to one or more LCE servers that contain events from a wide variety of devices including firewalls, servers, routers, honeypots, applications and many other sources. The LCE supports many types of agents including: > Windows Event Logs > Windows/Unix system and application logs > Checkpoint OPSEC events > Cisco RDEP events > Cisco SDEE events > Netflow > Splunk > Sniffed TCP and UDP network traffic > Sniffed syslog messages in motion > File monitoring (Unix and Windows) Copyright Tenable Network Security, Inc. 5

6 LCE has many signature processing libraries to parse logs and can normalize and correlate most network IDS devices, as well as messages from SecurityCenter. The LCE server supports the following IDS sources: Collection and Correlation > Bro > Cisco IDS > Enterasys Dragon > HP TippingPoint > IBM Proventia (SNMP) > Juniper NetScreen IDP > McAfee IntruShield (limited correlation) > Fortinet IDS events > Tenable s Passive Vulnerability Scanner > Snort (and Snort based products) TippingPoint syslog event format must be modified to use a comma delimiter rather than a tab delimiter before it can be processed by the LCE. Collection Only > AirMagnet > Checkpoint (Network Flight Recorder) > Portaledge > Toplayer IPS In SecurityCenter deployments, the LCE receives vulnerability data and IDS signatures from SecurityCenter and performs IDS event correlation of that data for analysis, display and reporting. Correlated events show up in the SecurityCenter event filter as Targeted IDS Events type. The screen capture below shows a type summary of events whose CVE or Nessus ID matches that of the vulnerability, indicating a targeted IDS event: Copyright Tenable Network Security, Inc. 6

7 Typically, LCE data collection is real-time from external log sources; however, batch imports of log data can be processed via the import_logs command available on LCE 3.4 (or greater) systems. Data received by the LCE can be stored in a number of formats including data silo storage (default), flat file ( save-all ) and compressed files ( enablelog-archiving ). EVENT COLLECTION, NORMALIZATION, STORAGE, ANALYSIS AND RESPONSE The LCE server can be configured to receive events directly through syslog messages or multiple agents can be used to securely send events found in flat log files, OPSEC compatible devices and Windows events. The LCE clients make use of a secure API to send events to the LCE through an authenticated encrypted session. When the LCE receives an event, high-speed rules are applied to it such that it can be normalized with a unique event name. Any information in the log containing IP addresses, usernames, ports, protocols and sensors is also extracted. The LCE ships with support for several hundred different log sources. For example, consider the following log message: Jul 5 20:20:23 kong sshd(pam_unix)[32401]: session closed for user root The LCE may have received this message through syslog or through a LCE client. Once it receives this message, it can be configured to normalize the message or ignore it altogether. If it is normalized, the LCE can perform behavioral analysis on the message, such as determining how often this event normally occurs. The LCE can also have more complex correlation rules in use that could be looking for this message in a sequence of complex events, or possibly from specific hostile networks. In addition, the LCE contains a customizable rule set for generation, syslog alerting and command execution based on LCE event content. Content within the log archive can be used as parameters within the desired output. This ability allows for administrator notification, blacklisting, rate limiting and many other useful functions. Copyright Tenable Network Security, Inc. 7

8 LCE data collection allows for targeted log collection based on PRM and TASL scripts. For example, some enterprise organizations require that all firewall connections be logged. In these cases, the LCE can be directed to keep every firewall event sent to it. Other network organizations may only be interested in keeping firewall events that contain information about denied connection attempts. In these cases, the LCE can be configured to keep only the deny information in the firewall logs and throw away the logs that are considered irrelevant. This information is stored on the LCE server in silos, a proprietary database where the oldest data is discarded first. For example, a LCE server can be configured to hold 1 GB of data (4 GB max). When 1 GB is reached, the silos rotate with the oldest silo being overwritten by the newest. Since there are multiple silos and each can be configured with a variable size, care should be taken in silo configuration and sizing. This behavior is indicated in the log file as shown in the example below: May 23, 07 03:48 (silo-manager.sh) rolling from 10 to 11 May 23, 07 03:48 (silo-manager.sh) deleting lce11.db.gz May 23, 07 03:48 (silo-manager.sh) deleting lce11.raw.gz May 23, 07 03:48 (silo-manager.sh) deleting lce11-cache May 23, 07 03:48 (silo-manager.sh) deleting lce11-index It is not the number of events that matter, but the average event size. A LCE server with smaller average log message sizes will be able to store more events than a network with larger average log message sizes. The LCE data is available for analysis and reporting through the SecurityCenter/LCE Manager. When users want to analyze security events, they have two views available under the Analysis tab. The first is the Events selection where events can be analyzed on a daily basis to see if they correlate with known vulnerabilities. The second is the Raw Logs selection that allows users to perform a search of raw LCE logs across multiple LCE servers. This view provides a broader context of LCE data for saved searches and event correlation. When creating SecurityCenter 4 repositories, LCE event source IP ranges must be included along with the vulnerability IP ranges or the event data will not be accessible from the SecurityCenter UI. It is very useful to be able to sort, navigate and drill into a large number and variety of log messages. However, when an intrusion occurs or there is an attack of interest, a SecurityCenter user can simply click to get a list of all logs that are related to the activity. For example, assume there is a new Buffer Overflow IDS event. This event will have a source and destination IP address. When viewing the event under a SecurityCenter that is integrated with the LCE, the user will be able quickly analyze if the attacker has visited prior to the IDS detection, and possibly observe other related firewall, honeypot, operating system logs or any devices that sends logs to the LCE. You can also forward all events received from the LCE via syslog to another server for long-term storage. This helps to minimize the collection effort for log Copyright Tenable Network Security, Inc. 8

9 aggregation of the entire network for sites that are required to retain all logs for a specific period of time. Beyond standard silo storage, LCE can be configured to store all log events in either plain text or compressed format. For older versions of LCE, use the save-all feature to save all log events in raw plain-text format. Newer versions of LCE (3.2 or greater) enable full raw log archival in a compressed format using the enable-log-archiving option in /opt/lce/daemons/lce.conf. The save-all function is still available in newer versions of LCE, but does not have important features that enable-log-archiving has: > Compressed log format uses less space than the plain text file used by save-all > Works with the Search Raw Logs function in SecurityCenter and above > May be used with multiple LCE sources With enable-log-archiving storage enabled, raw compressed log data is automatically saved on the LCE server and available for retrieval through the LCE host user interface. Raw log search data is viewed through the user interface and then saved in a compressed format for later searches. Below is a screen capture of several raw log searches: More information about raw log searches is available through the SecurityCenter User Guide available on the Tenable Support Portal. EVENT CORRELATION The LCE has the ability to perform in-depth event correlation. The technology is a high performance scripting language named TASL (Tenable Application Scripting Language). TASL scripts can be used to work with any normalized events. They perform a variety of deeper analysis and log parsing tasks not possible with basic normalization rules. Some of the things that can be accomplished with TASL include: > Tracking observed Ethernet addresses on wireless access points and alerting when new ones appear > Aggregating several unique events from one IP address into a global correlated event > Re-writing events based on time, networks involved or ports in use > Threshold alerting when a certain amount of events over time is exceeded, to generate a new alert Copyright Tenable Network Security, Inc. 9

10 Below is a screen capture of correlated event activity from a major enterprise network: Each of these events corresponds to the following types of behavior: > Compromised Event Spike The Log Correlation Engine is running the threatlist.nbin script and has correlated a connection with a host that has been reported to be compromised. > Login From External Network Any successful login event that originates from outside of the network. > Login_Then_Change The Log Correlation Engine is running the events_followed_by_change.tasl script and has detected a system change that was preceded by a valid system login. In addition to process account and configuration auditing, associating logins with change is an excellent way to track authorized changes to systems. > Long Term Intrusion Activity Any time a host is generating intrusion events for more than three hours continuously. > Long Term Network Scanning Any time a host is generating port scans for more than three hours continuously. > Network Login Sweep When multiple login-failure events from multiple targets can be correlated against one source IP address. For example, when aggregating Secure Shell logs from multiple sources, if a single attacker attempts to login to each server but fails, this correlation rule will identify that a login sweep has occurred. Copyright Tenable Network Security, Inc. 10

11 > Password Guessing This is a correlation that looks for multiple login failures to hundreds of different types of devices, applications and operating systems. > Portscan Spike The Log Correlation Engine is running the portscan_spike.tasl script and has observed more than 10 port scan events in the last minute. > Potential Worm Outbreak This correlation considers port scan events to determine if a server has been scanned by a remote system and then starts to scan other systems. > Successful Password Guess The Log Correlation Engine has detected multiple password login failures. This could indicate brute force password guessing. The LCE is running the brute_force_password_guessing.tasl script that considers login failures for Windows, Unix and many other types of applications. > Suspicious Connection The Log Correlation Engine is running the suspicious_outbound_connections.tasl script and has detected an inbound connection followed by an outbound connection that is indicative of compromised system obtaining a command or exploit payload. > Suspicious Proxy The LCE is looking for long network connections to a server that are also accompanied by connections originating at that server and may indicate leapfrogging. When a hacker compromises a system, they may use it as a base to connect to other servers to obscure their true location. For example, a compromised Windows server could have VNC running on it and a hacker could connect to it on port 5900 and then launch a new VNC connection from that host to a different compromised host. To learn more about how TASL works and writing TASL scripts, please see the TASL Reference Guide. There are also some relevant postings at Tenable s blog located at and at the Tenable Discussion Forums located at There are many types of correlation rules available to LCE users. Many of these rules are modified and added over time as new threats and detection techniques are developed. To learn more, please visit the Tenable Support Portal and also use an RSS reader to subscribe to Tenable s list of LCE PRM and TASL updates. BEHAVIOR MODELING The LCE also includes a self-learning network behavior analysis tool known as the stats daemon. Through the use of basic statistical principals, each host on a protected network is modeled for its client/server activity, its overall connections profile and how often specific types of events occur for it. For example, consider the following alert from the stats daemon: stats: Jun 03 15:00: Statistical_SrcIp_EventCnt_Increase TNM-TCP_Session_Started window Jun 03 14:00:00 15:00:00 average stddev 1.00 nhits 35 stddev_units freq 0.00 This alert says that one of our servers ( , the SrcIp part of the alert) had a series of events that increased over what was expected. The event TNM-TCP-Session- Started is generated by the Tenable Network Monitor agent that sniffs and logs network sessions. The specific window in question is 2:00 PM to 3:00 PM (14:00 to 15:00). Copyright Tenable Network Security, Inc. 11

12 Normally, that hour of the day has an average of 11 hits. However, for the period in question (June 3) there were 35 hits. For an example network, the following graph of statistical events can be seen: In this screen capture, during each hour, the stats daemon has evaluated every event that has ever occurred for each host on the network. If there has been an increase in the event rate, a log is produced. The LCE normalizes these logs into a statistical event that indicates the type of event (such as a spike in logins or a spike in virus activity) and the magnitude such as Minor, Medium and Large. That is a lot of information packed into these events and there are many types of events like this. Tenable recommends that these behavior alerts be used to learn what is normal on the network, and then use tools like TASL scripts to create alerts when things appear abnormal. EVENT STORAGE MODEL Storage of Data in Silos The LCE makes use of an extremely high-speed proprietary data storage mechanism known as silos. There are two silo options available with the LCE: 50 and 255 silos. The smaller 3-silo LCE has been deprecated as of LCE 3.4.2, but is still supported. In the LCE configuration, the number and size of silos define the total amount of storage space for event data. For example, the LCE could be configured to use 50 silos, each 100 MB in size for a total of 5 GB of storage space. Each silo also has an index file that allows for highspeed analysis of the events stored by the LCE. As more and more events arrive, they are written to the current LCE silo. When the last silo is full, the first silo is deleted and new data is added. For the full version of LCE, a maximum of 255 silos can be created. For those using the 50-silo license, a maximum of 50 silos can be created. Silo Caching and Indexing There is always one active silo that is receiving live data. When this silo exceeds its allotted hard drive space, the lced process opens up a new silo. This new silo will then receive the latest data. The process where a silo goes from being current to containing historical data is referred to as rolling over. When a silo roll occurs, the LCE will attempt to index the existing data based on common IP address, network, port, event and other types of queries such that future queries will be extremely fast. In addition, the LCE will consider previous queries and attempt to precache their results. Copyright Tenable Network Security, Inc. 12

13 GOING FORWARD At its core, the LCE is very simple. > The lced process receives both syslog events and events from remote LCE clients. > The lced process is configured with rules to both normalize events as well as process more complex TASL scripts. > A separate stats daemon watches over the LCE data to identify any behavioral anomalies. > The LCE can be configured to send events to another syslog server or simply write the events to a flat log file that can be on a separate disk or a SAN. It can also be configured to rotate logs after a certain file size is reached. > The LCE can also be configured to send events to a compressed archive log for queries spanning multiple LCE hosts. The sections below focus on deployment requirements and related considerations. Installation and operation of the LCE along with installation of LCE clients, writing normalization rules, writing TASL scripts and configuring the stats daemon are all covered in the LCE Admin/User Guide, LCE Client Guide, Log Normalization Guide, TASL Reference Guide and Statistics Daemon Guide. PREREQUISITES This section describes the environmental requirements to run LCE, depending on organizational needs. SUPPORTED OPERATING SYSTEMS Please refer to the SecurityCenter Installation guide for installation guidance related to the LCE host component (LCE Manager/SecurityCenter). The LCE server component is available for the Red Hat ES (Enterprise Server) 3.x, 4.x and 5.x Operating Systems for 32-bit platforms (4.x and 5.x for 64-bit platforms). Several different clients are available to operate directly on remote operating systems. This chart may not be complete, as newer information may be available at Tenable s download site. Below is a chart of available clients and their supported operating systems: The LCE clients written for 32-bit platforms will run on 64-bit systems as long as the 32-bit libraries are installed. LCE Client Platform 32/64 bit Function LCE Log Agent Red Hat ES 4, ES 5, ES 6 32/64 Monitors specific log files or directories of different operating systems. These clients Copyright Tenable Network Security, Inc. 13

14 FreeBSD 7, 8 32 will tail any number of log files and send the observed data to the LCE server for analysis. AIX Debian 5 32 Fedora 13, 14 32/64 Ubuntu 10.04, Ubuntu /64 Solaris SPARC (8,9,10) 32 Mac OS X 32 Dragon Appliance 32 MS Windows XP Professional, Server The Windows Log Agent also can monitor: > Entries in the Windows event log > USB device inserts and removals > Entries in the event logs of remote Windows servers > Process status (available for Unix systems as well) LCE Log Agents are designed to send log data to the LCE server. Accepted log data is normally in ASCII text format and will not include binary files (with the exception of process accounting data). The LCE Log Agents will check all data before sending, specifically omitting binary files such as.zip,.gz,.tar,.lzh,.bz2, etc. If a binary file is sent to the LCE, it has the potential to corrupt the database. This filtering is automatically performed by the LCE client software. LCE OPSEC Client LCE Splunk Client MS Windows Server 2008, Vista and Windows 7 Ultimate Red Hat ES 4, ES 5, ES 6 Red Hat ES 4, ES 5, ES 6 32/64 32 Based on Checkpoint s API for Linux, it monitors OPSEC compliant devices for new events. 32/64 Accepts Splunk messages for logging to the LCE server. When configuring Splunk to forward data to a non-splunk system, it is necessary to set sendcookeddata=false in outputs.conf. Copyright Tenable Network Security, Inc. 14

15 LCE WMI Monitor Tenable NetFlow Monitor Tenable Network Monitor Red Hat ES 5, ES 6 32/64 Retrieves Windows event logs (e.g., System, Application, Security, All, etc.) from one or more Windows hosts using the Windows Management Instrumentation (WMI) protocol. Red Hat ES 4, ES 5, ES 6 FreeBSD 7, 8 32 Red Hat ES 4, ES 5, ES 6 FreeBSD 7, /64 Receives NetFlow messages for logging to the LCE. Messages can be sent from multiple NetFlow sources to a single TNS_Netflow client. The client supports NetFlow versions 5 and 9. 32/64 Designed to monitor network traffic and send session information to the LCE server. Sniffs network traffic to identify TCP sessions as well as UDP, ICMP and IGMP activity. Tenable RDEP Monitor Tenable SDEE Monitor Red Hat ES 4, ES 5, ES 6 Red Hat ES 4, ES 5, ES 6 It also has a very useful feature of sniffing live syslog traffic in motion and sending it to the LCE as if the traffic were originally destined for it. This makes it very easy to centralize logs and not rely on forwarding of events from a different log server. 32/64 Retrieves messages from one or more Cisco IDS devices using Cisco s Remote Data Exchange Protocol (RDEP) that can send events to the LCE for processing. 32/64 Retrieves messages from one or more Cisco IDS devices using Cisco s Security Device Event Exchange Protocol (SDEE) that can send events to the LCE for processing. Tenable s LCE is available as a SecurityCenter upgrade or as a required component of the LCE Manager. One or more LCE servers can be installed to operate with a single SecurityCenter or LCE Manager. While LCE can run on the same server as SecurityCenter, this configuration is not recommended for performance reasons. Conversely, the LCE server is meant to be installed on the LCE Manager because of the lessened performance impact due to a lack of vulnerability data. SUPPORTED LOG SOURCES There are thousands of normalization rules that support most operating systems, firewalls, network routers, intrusion detection systems, honeypots and other network devices. The list of officially supported log sources is frequently updated on the Tenable web site. An example of some of the supported log sources follows: Log Type Supported Technologies Copyright Tenable Network Security, Inc. 15

16 Anomaly Detection Audit Trails Authentication Arbor, Tenable Log Correlation Engine anomalies, Stealthwatch Support for auditing of all system and user commands for Windows, Linux, FreeBSD, OS X and Solaris is supported by all LCE clients. BlueSocket, Cisco ACS, Microsoft ISA, Steel Belted Radius Applications Databases DNS File Integrity Firewalls & IPS Honey Pots Intrusion Detection/Prevention Network Devices Network Monitors Operating Systems Spam arpwatch, Citrix, Exim, IMAP, IRCd, ncftp, Nessus, OpenSSH, POP, Postfix, proftp, Pure FTP, Qpopper, Sendmail, all Tenable Products, UPS, wu-ftp, wu-imap Microsoft SQL, MySQL, Oracle, Postgres, sniffed SQL transactions observed by the Passive Vulnerability Scanner Bind, all supported web proxies, sniffed DNS lookups observed by the Passive Vulnerability Scanner Tenable Windows and Unix Log Correlation Engine Agents, Tripwire Adtran, Arkoon, Astaro, Checkpoint, Cisco ASA, Cisco PIX, CyberGuard, D-Link, Fortinet, F5 Big IP Application Firewall, Gauntlet, ipchains, ipfilter, iptables, Juniper, Microsoft ISA, Kerio, NetGear, OpenBSD's pf, Palo Alto, PortSentry, SideWinder, SonicWall, Stonegate, Sygate, Symantec, Windows XP, ZoneAlarm ForeScout, Honeyd, La Brea, Multipot, Nepenthes, Symantec Decoy Server AirMagnet, Bro, Cisco Security Agent, Dragon, IntruSheild, Juniper, Checkpoint (Network Flight Recorder), Portaledge, Proventia, Snort, Sourcefire, TippingPoint, Toplayer IPS 3Com, Apple Airport, Buffalo, Cisco 3000 VPN Concentrator, Cisco ACE, Cisco Aironet, Cisco IOS, Citrix Access Gateway, DHCP leases, D-Link, Enterasys, Extreme, Foundry, Juniper Reconnex, RNA, Tenable NetFlow Monitor (v5 and v9), Tenable Network Monitor, forensic logging from the Passive Vulnerability Scanner AIX, AS400 (via PowerTech), FreeBSD, Linux (Red Hat, Fedora, CentOS, SuSE), Mac OS X, Solaris, Windows NT/2000/XP/2003/Vista/2008/7 Amavis, Barracuda, MailScanner Virus Web Servers ClamAV, etrust, McAfee, Symantec, Trend Micro, Windows Defender Apache 1.x/2.x, Microsoft IIS, PHP Suhosin extensions Copyright Tenable Network Security, Inc. 16

17 Web Proxies BlueCoat, Squid, WC3/NCSA compatible log formats, sniffed web browsing sessions observed by the Passive Vulnerability Scanner LICENSES LCE servers are licensed to the specific hostname of the system they are to be installed on. There is no limit to the number of events or IPs that the LCE can be configured to monitor except that which is imposed by the SecurityCenter/LCE Manager license. There are two different licenses available for the LCE. The first license lets you create up to 255 data silos (see Storage of Data in Silos for more information). The second license limits the number of data silos that can be created to 50. There is no difference in the software that is installed, just the number of silos that can be created. Data silos are always limited to a maximum size of 4 GB per silo. THE LCE MANAGER Starting with SecurityCenter (LCE 3.6 and greater), Tenable has provided a standalone management interface for LCE so that it does not need to be managed from SecurityCenter. This is useful for configurations where event, but not vulnerability management is required. One LCE Manager can be configured to work with multiple LCE servers. Each LCE Manager supports a single repository/organization. For deployments where vulnerability/event data integration is required, a SecurityCenter must be installed to manage the LCE servers. The LCE Manager interface is very similar to that of SecurityCenter, without vulnerability data integration. LCE Manager installation, administration and usage are described in detail in the corresponding LCE Manager documents. SECURITYCENTER If you want to correlate LCE data with vulnerability data, it is recommended that LCE servers be managed by Tenable s SecurityCenter. LCE and greater is required for SecurityCenter 4. One SecurityCenter can be configured to work with multiple LCE servers. Each SecurityCenter organization can be configured to use one or more LCE servers. Multiple SecurityCenter organizations can also reference the same LCE server. On SecurityCenter, organizations are discrete groupings of users based on IP ranges, assets, repositories or other items. Organizations can also share these objects depending on your enterprise needs. For example, let us assume SC4 organization #1 can access LCE #1, organization #2 can access LCE #2 and organization #3 can actually access LCE #1 and LCE #2. Copyright Tenable Network Security, Inc. 17

18 As long as organization #1 has the correct IP address filtering, it will be able to see all logs in LCE #1. For example, if organization #1 was configured to look at the /8 network, the authorized users assigned there would be able to see any logs that had events with either their source or destination IP addresses from that class A network. SECURE SHELL PUBLIC KEYS LCE analysis is provided to SecurityCenter/LCE Manager host through the use of command execution across a Secure Shell network session. When the host needs to query a LCE server, it invokes a Secure Shell session to the configured LCE server. All execution and analysis of LCE data occurs on the LCE server. Secure Shell public keys are configured such that the host can invoke commands on the LCE server. Non system-administrator accounts are used to perform these queries. The trust relationship is only needed from the host to the LCE server. FOR MORE INFORMATION Tenable has produced a variety of additional documents detailing the LCE s deployment, configuration, user operation and overall testing. These documents are listed here: > Log Correlation Administrator and User Guide describes installation, configuration and operation of the LCE > Log Correlation Engine Client Guide how to configure, operate and manage the various Unix, Windows, netflow, OPSEC and other clients > Log Correlation Engine Log Normalization Guide explanation of the LCE s log parsing syntax with extensive examples of log parsing and manipulating the LCE s.prm libraries > TASL Reference Guide explanation of the Tenable Application Scripting Language with extensive examples of a variety of correlation rules > Log Correlation Engine Statistics Daemon Guide configuration, operation and theory of the LCE s statistic daemon used to discover behavioral anomalies > Log Correlation Engine SAN-DAS Guide configuration, operation and theory for using the LCE in large disk array environments Documentation is also available for Nessus, the Passive Vulnerability Scanner and SecurityCenter through the Tenable Support Portal located at There are also some relevant postings at Tenable s blog located at and at the Tenable Discussion Forums located at For further information, please contact Tenable at support@tenable.com, sales@tenable.com or visit our web site at Copyright Tenable Network Security, Inc. 18

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

20 Appendix 1: Non-Tenable License Declarations Below you will find 3 rd party software packages that Tenable provides for use with the Log Correlation Engine. Section 1 (b) (ii) of the Log Correlation Engine License Agreement reads: (ii) The Software may include code or other intellectual property provided to Tenable by third parties (collectively, Third Party Components ). Any Third Party Component that is not marked as copyrighted by Tenable is subject to other license terms that are specified in the Documentation. By using the Software, you hereby agree to be bound by such other license terms as specified in the Documentation. The Log Correlation Engine s Software License Agreement can be found on the machine in the top-level directory for the LCE application, /opt/lce. RELATED 3 RD PARTY AND OPEN-SOURCE LICENSES blowfish.h This product includes cryptographic software written by Eric Young (eay@mincom.oz.au). This product includes software written by Tim Hudson (tjh@mincom.oz.au). crypto/bf/blowfish.h Copyright (C) Eric Young (eay@mincom.oz.au) All rights reserved. This package is an SSL implementation written by Eric Young (eay@mincom.oz.au). The implementation was written so as to conform with Netscapes SSL. This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@mincom.oz.au). Copyright remains Eric Young s, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes cryptographic software written by Eric Young (eay@mincom.oz.au) The word cryptographic can be left out if the rouines from the library being used are not cryptographic related :-). Copyright Tenable Network Security, Inc. 20

21 4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: This product includes software written by Tim Hudson (tjh@mincom.oz.au) THIS SOFTWARE IS PROVIDED BY ERIC YOUNG AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.] libcurl Portions Copyright (c) , Daniel Stenberg, <daniel@haxx.se>. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. OpenSSL Portions (C) The OpenSSL Project. All rights reserved THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Full license: zlib Copyright Tenable Network Security, Inc. 21