AlienVault Unified Security Management (USM) 4.x-5.x Deployment Planning Guide
USM 4.x-5.x Deployment Planning Guide, rev. 1 Copyright AlienVault, Inc. All rights reserved. The AlienVault Logo, AlienVault, AlienVault Unified Security Management, AlienVault USM, AlienVault Open Threat Exchange, AlienVault OTX, Open Threat Exchange, AlienVault OTX Reputation Monitor, AlienVault OTX Reputation Monitor Alert, AlienVault OSSIM, and OSSIM are trademarks or service marks of AlienVault, Inc. All other registered trademarks, trademarks or service marks are the property of their respective owners. Revision to This Document Date July 1, Revision Description Original document. Updated Table 2 with new URLs added in USM 5.1. USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 2 of 12
Contents Contents Introduction... 4 AlienVault USM Components... 4 USM Sensor... 4 USM Server... 5 USM Logger... 6 USM Deployment Types... 6 USM Deployment Examples... 7 Simple Deployment Example: USM All-in-One... 7 Simple Deployment Example: USM All-in-One and a Remote Sensor... 8 Complex Deployment Example: Individual USM Components... 9 Firewall Permissions... 10 USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 3 of 12
Introduction Introduction This guide is for use by AlienVault Unified Security Management (USM) 4.x and 5.x customers who must decide where to deploy the USM appliances on their network. It describes what the USM components are, how they work, as well as the URLs and port numbers that they need to access. AlienVault USM Components USM provides a single monitoring solution that combines several critical security technologies into a single appliance. Its modular architecture allows components to exist at any level of the network, thereby increasing system visibility and performance. All USM products include these three core components available as hardware or virtual appliances: USM Sensor - Deployed throughout the network to collect logs and monitor network traffic. Provides the five essential USM security capabilities for complete visibility. USM Server - Aggregates and correlates information that the Sensors gather. Provides single pane-of-glass management, reporting, and administration. (See USM Server.) USM Logger - Securely archives raw event log data for forensic research and compliance mandates. (See USM Logger.) Note: USM All-in-One (AIO) combines the Server, Sensor, and Logger components onto a single system. USM Sensor The USM Sensor deploys throughout the network, including any remote sites your organization has. It is referred to as the frontline security module of the USM platform. The USM Sensor combines five essential security capabilities that the AlienVault USM platform provides. This greatly expands situational awareness, creating visibility into deployed assets; vulnerabilities on those assets; attack targets and vectors; and services. USM Sensors specifically perform the following data aggregation tasks: Collects logs from network devices and hosts. Collects data on network traffic from mirrored ports. Performs asset discovery. Conducts vulnerability scanning. Collects intrusion detection data. Generates NetFlows. USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 4 of 12
AlienVault USM Components USM Sensors then translate ( normalize ) all received data into uniform format that they can act on. To normalize the raw data from disparate data sources, the USM Sensor uses individual plugins. Plugins parse the data and convert it into a readable format with multiple fields, which are called events in AlienVault USM. Finally the USM Sensor sends the normalized events to the USM Server where correlation and risk assessment occur. Data Aggregation and Detection Normalization Send to USM Server Figure 1. USM Sensor workflow USM Server The USM Server communicates with every component, and provides a single point for management, reporting, and administration. This management includes the following core functionality: Collects information forwarded by USM Sensors. Evaluates each event against USM default and customer specified policies. Performs risk assessment on every event. Correlates events to identify threat patterns. Generate alarms for evaluation and appropriate response. Stores events in a local database for assessment and reporting. USM Server correlates events by observing patterns based on logical operators such as OR and AND. It also cross-correlates events with existing vulnerability data. After the USM Server correlates events, it performs risk analyses and, if the risk for an event rises above 1, it triggers an alarm. See correlation on the AlienVault Documentation Center. Figure 2 shows the workflow of the USM Server. By default, the USM Sensor sends normalized events to the USM Server correlation engine, where risk assessment occurs. Organizations can configure policies to filter events, so that the USM Server analyzes only those events that are most important to the company. After correlation, the USM Server stores the events in the database for a short period. This allows for more correlation and incident response, if needed. Optionally, it can also forward events and alarms to another USM Server or a USM Logger. Event Collection Policy Evaluation Risk Assessment Correlation SQL Storage Event Forwarding (Optional) Figure 2. USM Server workflow USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 5 of 12
USM Deployment Types USM Logger The USM Logger acts as the secure data archive of the USM solution. It performs simple, but critical tasks: Stores security events and alarms as flat files on the system. Digitally signs and time-stamps it for integrity. Organizations can use this later for log validation an important feature for compliance. Stores events for long-term retention, analysis, and reporting with a 7:1 compression ratio. Indexes on full text in hourly runs, and offers fast log retrieval. (See note.) Users can access Logger data through the USM web interface to run reports, analyze trends, and conduct forensic research. Note: Full-text indexes are based on text-based columns (VAR, CHAR, or TEXT) and help speed up queries and DML operations on data in those columns, omitting defined stop words. Figure 3 shows the workflow of the USM Logger. USM Logger receives normalized events and alarms from USM Server. It then signs and archives them on the disk. Event Collection Log Signature Disk Storage Figure 3. USM Logger workflow USM Deployment Types AlienVault USM can generally be deployed in two ways: Simple Deployment All AlienVault USM components (Sensor, Server, and Logger) are deployed in a single appliance called USM All-in-One. Such deployment is useful for smaller environments as well as testing and demo purposes. Complex/Distributed Deployment AlienVault USM components are deployed onto its own appliance and are separated. In distributed deployment, AlienVault USM comes in two flavors, USM Standard and USM Enterprise, such as USM Standard Server, USM Standard Sensor, USM Enterprise Server, or USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 6 of 12
USM Deployment Examples USM Enterprise Logger. The USM Enterprise deployment is only available on hardware appliances. Enterprise Server ships with two devices, one device is the Enterprise Server and the other is the Enterprise Database. The AlienVault USM Standard and USM Enterprise product lines offer increased scalability and performance by provisioning dedicated systems for each component. Table 1. AlienVault USM Deployment Types USM All-in-One USM Standard USM Enterprise User Type Small organizations Mid-size organizations Large organizations Environment Single-tier deployment Multi-tier deployments & distributed environment Multi-tier deployments & distributed environment Virtual Appliance x x Hardware Appliance x x x See datasheets on alienvault.com for details. USM Deployment Examples You can deploy AlienVault USM appliances in small organizations, where a single USM All-in-One is sufficient; in mid-size organizations, where one or more USM Remote Sensors connect to a USM AIO; or in large organizations, where USM Sensor, USM Server, and USM Logger are separate physically but work as a single unit. Below are some examples with graphical illustrations. Simple Deployment Example: USM All-in-One In this example, a USM AIO is deployed behind the company firewall. The Sensor component on the AIO collects log from the office network, wireless network, DMZ network, as well as the firewalls. It also monitors the network traffic through the connected routers. The routers have port mirroring enabled. USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 7 of 12
USM Deployment Examples Figure 4. Simple deployment example: USM AIO Simple Deployment Example: USM All-in-One and a Remote Sensor This example is very similar to the previous one, but this company has a remote office that s on a different subnet. In this case, the best practice is to deploy a USM Remote Sensor at the remote office, and deploy the USM AIO on the main network. This way the remote sensor can collect logs and monitor traffic specific to the subnet, then send them to the AIO for correlation and risk assessment. USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 8 of 12
USM Deployment Examples Figure 5. Simple deployment example: USM AIO and a remote sensor Complex Deployment Example: Individual USM Components In this complex example, each office subnet has a remote sensor deployed to collect logs and monitor traffic. On the main network, instead of using the USM AIO, each USM component is installed on its own appliance to increase scalability and performance. All USM Sensors connect to the USM Server, where correlation and risk assessment occur. The USM Server forwards the events and alarms to the USM Logger for long-term storage. USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 9 of 12
Firewall Permissions Figure 6. Complex deployment example: individual USM components Firewall Permissions The USM components need to access certain URLs and port numbers to function correctly. If your company operates in a highly secure environment, you will need to change some permissions on your firewall(s) for USM to work. Table 2 summarizes the URLs and port numbers that the USM needs access to, while Table 3 lists the port numbers used by the USM components to communicate with each other. Table 2. URLs and port numbers used by USM Server URL Port Number AlienVault Features in Use USM versions data.alienvault.com 80 AlienVault product and feed update 4.x and 5.x feed.openvas.org, openvas.org 80, 873 Vulnerability Assessment 4.x maps-api-ssl.google.com 443 Asset Location 4.x and 5.x messages.alienvault.com 443 Message Center 5.x USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 10 of 12
Firewall Permissions Server URL Port Number AlienVault Features in Use USM versions otx.alienvault.com 443 Open Threat Exchange 5.1 and above reputation.alienvault.com 443 Open Threat Exchange 4.x and 5.x support.alienvault.com 20, 21 AlienVault Doctor 4.x and 5.x telemetry.alienvault.com 443 Telemetry Data Collection 5.x tractorbeam.alienvault.com 22, 443 Remote Support 5.x www.google.com* 80 AlienVault API 4.x and 5.x *The AlienVault API tries to access www.google.com every 5 minutes to ensure that the system has Internet connection. Table 3. Port numbers used by the USM components for internal communication USM Components Package Name Listening Port Description Server, Sensor alienvault-firewall 22 alienvault-snmpd 161, 162 alienvault-vpn <VPN_PORT> When VPN is enabled, the alienvault-vpn package will add a rule to open the specified port. By default it is 33800. alienvault-ha 873, 694, 3306, 4949, 9390, 3000 When High Availability (HA) is enabled, the alienvault-ha package will add rules to open these ports between the two nodes as well as on the virtual IP. Server alienvault-mysql 3306 ossim-server 40001, 40002, 40004, 40005 alienvault-apache2 80, 443 ossim-framework 40003, 40011, 3128, 555(udp) alienvault-ntop 3000 USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 11 of 12
Firewall Permissions USM Components Package Name Listening Port Description Sensor alienvault-ossec 1514(udp) ossim-agent 514(udp), 4949, 9390 USM 4.x-5.x Deployment Planning Guide, rev. 1 Page 12 of 12