Log Correlation Engine 4.2
Architecture Guide
October 3, 2013 (Revision 2)
Table of Contents
Introduction ... 3
Standards and Conventions ... 3
Architecture ... 3
Components of the Log Correlation Engine ... 3
Collection and Correlation ... 5
Collection Only ... 5
Event Collection, Normalization, Storage, Analysis and Response ... 6
Event Correlation ... 8
Behavior Modeling ... 9
Event Storage Model ... 11
Storage of Data in Silos ... 11
Silo Rollover ... 11
Silo Indexing ... 11
Silo Archiving ... 11
Vulnerability Correlation for Continuous Monitoring ... 11
LCE Workflow ... 12
Prerequisites ... 13
Supported Operating Systems ... 13
Supported Log Sources ... 13
Licenses ... 16
SecurityCenter ... 16
Secure Shell (SSH) Public Keys ... 17
For More Information ... 17
Introduction
This document describes Tenable Network Security’s Log Correlation Engine 4.2 including architecture, installation, and configuration in SecurityCenter. Please share your comments and suggestions with us by emailing them to
A working knowledge of Secure Shell (SSH), 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 Linux and Unix is also assumed.
This document is intended to be used with LCE installations using version 4.2 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 Linux 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 be managed from SecurityCenter. Any documentation references to SecurityCenter pertain to SecurityCenter 4.6.2.2 and higher unless otherwise noted.
The Log Correlation Engine (LCE) is made up of three basic components: the LCE client, the LCE server (lced) and the user interface. 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, normalized (classified as a type and event), and then searched 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.
SecurityCenter-based LCE 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. LCE supports many types of agents including:
Windows Event Logs
Windows, Linux, OSX, and other Unix system and application logs Check Point OPSEC events
Cisco RDEP events Cisco SDEE events NetFlow
Splunk
Sniffed ICMP, TCP, and UDP network traffic
Sniffed syslog (UDP and TCP) messages in motion File integrity monitoring (Windows, Linux, OSX, and Unix)
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 Network Security Monitor Cisco IDS/IPS Enterasys Intrusion Prevention System (formerly Dragon) HP TippingPoint
IBM Proventia (formerly ISS/RealSecure) Juniper / NetScreen
McAfee Network Security Platform (formerly IntruShield) Suricata
Snort / Sourcefire
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 Check Point IPS (formerly NFR Security Sentivist) Portaledge
Corero Intrusion Prevention System (formerly Top Layer)
In SecurityCenter deployments, 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 date summary of events whose type is intrusion and indicates a targeted IDS event:
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. 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 (“enable-log-archiving”).
The “save-all” function can consume a large amount of disk space, and is recommended to be used for debugging purposes only.
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
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. 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, LCE contains a customizable rule set for email 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 email notification, blacklisting, rate limiting, and many other useful functions. 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, an LCE silo can be configured to hold 1 GB of data (10 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 20, 13 09:00 (LCE Daemon) Rolling from silo 14 to silo 0
May 20, 13 09:00 (LCE Daemon) WARNING: MD5 data silo checksums are not being forwarded.
May 20, 13 09:00 (LCE Daemon) WARNING: All silo archiving options are disabled. May 20, 13 09:00 (LCE Daemon) (silo rollover) removing /opt/lce/db//lce0-db_index May 20, 13 09:01 (LCE Daemon) (silo rollover) deleting /opt/lce/db//lce0.ndb
May 20, 13 09:01 (LCE Daemon) (silo rollover) removing /opt/lce/db//lce0-log_store
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 SecurityCenter. When users want to analyze security events, they can view the available data under the “Analysis” tab followed by selecting “Events”. After selecting “Events”, there is a list of tools available from the drop-down menu that can be used to analyze the event data in many ways. A list of possible tools can be viewed below:
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 send logs to the LCE.
You can also forward all events received from LCE via syslog to another server for long-term storage. This helps to minimize the collection effort for log aggregation of the entire network for sites that are required to retain all logs for a specific period of time.
All events that are sent to LCE are either correlated into Event categories, or if the events are not correlated, they are categorized as “unnormalized” events as shown below:
Event Correlation
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 Below is a screen capture of some “Long Term” correlated event activity from a major enterprise network:
Each of these events correspond to actions that have shown a pattern of recurrence. There are many such correlations that LCE performs, providing a unique insight into possible attacks and insider threats. Below is a short list of interesting alerts:
Threatlist Outbound/Inbound Connection – The LCE has correlated a connection between a host in a network and an external host that has been reported to be compromised. This could indicate botnet or malware activity. Crowd Surge – The LCE has detected an unusual number of hosts in a network connecting to the same external
resource. This could indicate botnet, spyware, or malware activity.
VPN Login From Unusual Source – The LCE has learned the normal source IP address for a VPN user that
recently successfully logged in to a VPN from a source IP address in a different class B network. This could indicate a compromised user account.
Long Term Intrusion Activity – The LCE has detected a host that has been generating intrusion events for more
than three hours continuously.
Long Term Network Scanning – The LCE has detected a host that has been generating scanning events for
more than three hours continuously.
Network Login Sweep – The LCE has correlated multiple login-failure events toward multiple targets from one
source IP address, indicating that an attacker is attempting brute force logins across network resources. Password Guessing – This could indicate brute force password guessing. The LCE considers login failures for
Windows, Linux, Unix, and many types of applications, and tracks them by source over time.
Successful Password Guess – The LCE has detected multiple password login failures followed by a successful login event. This could indicate that brute force password guessing has led to a successful intrusion.
Potential Worm Outbreak – This indicates that a server has been scanned by a remote system, and then started
to scan other systems.
Suspicious SSH/VNC/RDP Proxy – The LCE has detected an inbound connection followed by an outbound connection, which is indicative of compromised system obtaining a command or exploit payload.
Suspicious Proxy – This indicates that LCE has detected long network connections to a server that were 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 http://www.tenable.com/blog and at the Tenable Discussion Forums located at https://discussions.nessus.org/community/lce.
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 principles, 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:01 - 10.10.10.2 0.0.0.0 Statistical_SrcIp_EventCnt_Increase TNM-TCP_Session_Started window Jun 03 14:00:00 15:00:00 average 11.00 stddev 1.00 nhits 35 stddev_units 24.00 freq 0.00
This alert says that one of our servers (10.10.10.2, 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). 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 events appear to be abnormal.
Event Storage Model
Storage of Data in Silos
LCE makes use of an extremely high-speed proprietary data storage mechanism known as “silos”. There are three sizing options available with LCE: 1 TB, 5 TB and 10 TB. The number and size of silos define the total amount of storage space for raw event data. For example, LCE could be configured to use 200 silos, each 10 GB in size for a total of 2 TB of storage space.
Each silo consists of a silo file and two silo directories - a directory for the raw log storage and a directory for the high-speed index. Events are compressed and indexed as they are written to the active silo on disk, so the silo file and silo directories will be smaller on disk than the configured silo size when it is considered to be full by LCE.
Silo Rollover
When the “active” silo is full, the LCE will open the next numerical silo file, which will become active. When the last silo is full, the first silo is deleted and new data is added. The process where a silo goes from being current to containing historical data is referred to as “rolling over”.
Silo Indexing
Events are indexed by common properties (IP address, port, event, type, etc.) as they are written to disk so that queries with filters on these properties will execute significantly faster. Events are also tokenized by their raw content so they may be searched with text strings.
Silo Archiving
LCE is able to archive silos when the maximum number of silos has been reached. If this feature is not configured, LCE will overwrite the oldest silo first. The silo archiving feature allows you to save some (the database, the index, the raw data) or all of your data beyond the licensed “active” silo storage capacity of 1 TB, 5 TB, or 10 TB. Silo archiving is explained in more detail in the LCE 4.2 User and Administration guide.
Vulnerability Correlation for Continuous Monitoring
Log Correlation Engine 4.2 has added the ability to detect systems, applications, and vulnerabilities through log analysis. This enables Tenable vulnerability correlation and continuous monitoring to quickly determine the number of systems on a network, as well as which systems are undergoing vulnerability scanning, network monitoring, and log analysis. This capability is only available in conjunction with SecurityCenter 4.6.2.2 and higher.
Below is an example SecurityCenter dashboard that summarizes the vulnerabilities found from Nessus scans, sniffed vulnerabilities via the Passive Vulnerability Scanner, and logged vulnerabilities via Log Correlation Engine.
The dashboard also counts and trends the unique number of systems on the network found through log analysis, scanning, and network traffic monitoring. Finally, it charts today’s percentages of system coverage by vulnerability detection types.
LCE Workflow
At its core, LCE is very simple:
The lced process receives both syslog events and events from remote LCE clients.
The lced process is pre-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.
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. 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 4.2 Administration and User Guide, LCE 4.0 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 its requirements.
The LCE server component is available for Red Hat Enterprise Linux / CentOS 5.x and 6.x operating systems for 32-bit and 64-bit platforms.
Several different clients are available to operate directly on remote operating systems. For the complete list of LCE clients, review the “Log Correlation Engine Client Guide”, which is available on the Tenable Support Portal.
The LCE clients written for 32-bit platforms will run on 64-bit systems as long as the appropriate 32-bit libraries are installed.
Tenable’s LCE is available as a SecurityCenter add-on. One or more LCE servers can be installed to operate with a single SecurityCenter. While LCE can run on the same server as SecurityCenter, this configuration is not recommended for performance reasons.
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
Anomaly Detection Arbor
Tenable Log Correlation Engine anomalies Stealthwatch
Audit Trails Support for auditing of all system and user commands for Windows Linux, FreeBSD, OS X, AIX, and Solaris are supported by all LCE clients.
Authentication BlueSocket
Cisco ACS and NAC Entrust IdentityGuard ForeScout CounterACT Microsoft ISA
Steel Belted Radius
Applications arpwatch Citrix Dovecot Exim IMAP IRCd Microsoft Exchange ncFTP
Nessus(and all other Tenable products) OpenSSH
POP Postfix proFTP Pure FTP Qpopper Sendmail UPS wu-FTP wu-IMAP
Xpient credit card transaction processing
Databases Microsoft SQL
MySQL
Oracle Audit Logs PostgreSQL
sniffed SQL transactions observed by the Passive Vulnerability Scanner
DNS BIND
all supported web proxies
sniffed DNS lookups observed by the Passive Vulnerability Scanner
File Integrity Tenable Log Correlation Engine Clients for Windows, Linux and Unix Tripwire
Firewalls & IPS Adtran Arkoon Astaro Check Point Cisco ASA and PIX CyberGuard D-Link Fortigate Fortinet
F5 Big IPApplication Firewall Gauntlet ipchains ipfilter iptables Juniper Microsoft ISA Kerio Netgear OpenBSD's pf Palo Alto PortSentry SideWinder SonicWall Stonegate Sygate Symantec
Windows XP, Vista, 7, etc. ZoneAlarm
Honey Pots ForeScout Honeyd La Brea Multipot Nepenthes
Symantec Decoy Server WebLabyrinth
Intrusion
Detection/Prevention
Bro Network Security Monitor Cisco IDS/IPS
Enterasys Intrusion Prevention System (formerly Dragon) HP TippingPoint
IBM Proventia (formerly ISS/RealSecure) Juniper / NetScreen
McAfee Network Security Platform (formerly IntruShield) Suricata
Snort / Sourcefire AirMagnet
Check Point IPS (formerly NFR Security Sentivist) Portaledge
Corero Intrusion Prevention System (formerly Top Layer)
Network Devices 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
Network Monitors McAfee DLP
RNA
Tenable NetFlow Monitor (v5 and v9) Tenable Network Monitor
forensic logging from the Passive Vulnerability Scanner
Operating Systems AIX
AS400 (via PowerTech) FreeBSD
IBM z/OS (via Type80 SMA_RT syslogs) Linux (Red Hat, Fedora, CentOS, SuSE) Mac OS X
Solaris
Spam Amavis Barracuda MailScanner
Virus / Malware ClamAV
eTrust FireEye McAfee Microsoft ForeFront Symantec Trend Micro Windows Defender
Web Servers Apache 1.x/2.x
Microsoft IIS
Oracle HTTP Server PHP Suhosin extensions
Web Proxies BlueCoat
McAfee Web Gateway 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 on which they are to be installed. There is no limit to the number of events or IP addresses that the LCE can be configured to monitor.
There are three different licenses available for LCE: 1 TB, 5 TB, and 10 TB. This is based on the total amount of data stored on a single LCE system.
SecurityCenter
If you want to correlate LCE data with vulnerability data a SecurityCenter will need to manage your LCE servers. 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 enterprise needs.
For example, let us assume SC4 Organization #1 can access LCE #1, Organization #2 can access LCE #2 and Organization #3 can access LCE #1 and LCE #2.
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 10.0.0.0/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.
SecurityCenter can also be configured to accept multiple Log Correlation Engine’s configured for high availability, load balancing, or both. For environments that have more than 25,000 events per second(EPS), or that require fault tolerance review the “Log Correlation Engine 4.2 High Availability Large Scale Deployment Guide”.
Secure Shell (SSH) Public Keys
LCE analysis is provided to a SecurityCenter host through the use of command execution across a Secure Shell (SSH) network session. When the host needs to query a LCE server, it invokes a SSH session to the configured LCE server. All execution and analysis of LCE data occurs on the LCE server.
SSH 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 Engine Administrator and User Guide – describes installation, configuration, and operation of the
LCE.
Log Correlation Engine Quick Start Guide – provides basic instructions to quickly install and configure an LCE
server. A more detailed description of configuration and management of an LCE server is provided in the “LCE Administration and User Guide” document.
Log Correlation Engine Client Guide – how to configure, operate, and manage the various Linux, Unix, Windows,
NetFlow, OPSEC, and other clients.
LCE High Availability Large Scale Deployment Guide – details various configuration methods, architecture
examples, and hardware specifications for performance and high availability of large scale deployments of Tenable's Log Correlation Engine (LCE).
LCE Best Practices – Learn how to best leverage the Log Correlation Engine in your enterprise.
Tenable Event Correlation – outlines various methods of event correlation provided by Tenable products and
describes the type of information leveraged by the correlation, and how this can be used to monitor security and compliance on enterprise networks.
Tenable Products Plugin Families – provides a description and summary of the plugin families for Nessus, Log
Correlation Engine, and the Passive Vulnerability Scanner.
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 Large Disk Array Install Guide – configuration, operation, and theory for using the LCE in
large disk array environments.
Example Custom LCE Log Parsing - Minecraft Server Logs – describes how to create a custom log parser using
Minecraft as an example.
Documentation is also available for Nessus, the Passive Vulnerability Scanner, and SecurityCenter through the Tenable Support Portal located at https://support.tenable.com/.
There are also some relevant postings at Tenable’s blog located at http://blog.tenable.com/ and at the Tenable Discussion Forums located at https://discussions.nessus.org/community/lce.
For further information, please contact Tenable at [email protected], [email protected], or visit our web site at
Appendix 1: Non-Tenable License Declarations
Below you will find the command that will list all the third-party software packages that Tenable provides for use with the Log Correlation Engine.
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 CSIS, and PCI compliance. Tenable’s award-winning products are utilized by many Global 2000 organizations and Government agencies to proactively minimize network risk. For more information, please visit
http://www.tenable.com/.
GLOBAL HEADQUARTERS
Tenable Network Security
7021 Columbia Gateway Drive Suite 500
Columbia, MD 21046 410.872.0555
