AlienVault® USM (Unified Security Management) Anywhere ...

USM Anywhere™Deployment Guide

Updated February 12, 2018

Copyright © 2018 AlienVault. All rights reserved.

AlienVault, AlienApp, AlienApps, AlienVault OSSIM, Open Threat Exchange, OTX, Unified SecurityManagement, USM, USMAnywhere, USMAppliance, and USMCentral, are trademarks ofAlienVault and/or its affiliates. Other namesmay be trademarks of their respective owners.

2 USM Anywhere™Deployment Guide

Contents

About USMAnywhere Deployment 6

USMAnywhere Deployment Overview 7

USMAnywhere Architecture 7

USMAnywhere Data Security 8

USMAnywhere Deployment Types and Scalability 10

Deployment Requirements 11

USMAnywhere Deployment Process 13

About USMAnywhere Upgrades 14

USMAnywhere Sensor Deployment on VMware 15

About VMware Sensor Deployment 16

Requirements for VMware Sensor Deployment 17

Importing the VMwareOVF Package 18

USMAnywhere Setup on the VMware Virtual Machine 20

VMware Sensor Connection to USMAnywhere 22

Completing the VMware Sensor Setup 24

USMAnywhere Sensor Deployment onMicrosoft Hyper-V 35

About Hyper-V Sensor Deployment 36

Requirements for Hyper-V Sensor Deployment 36

Creating the Hyper-V Virtual Machine 38

USMAnywhere Setup on the Hyper-V Virtual Machine 44

Hyper-V Sensor Connection to USMAnywhere 46

Completing the Hyper-V Sensor Setup 48

USMAnywhere Sensor Deployment on AWS 60

About AWS Sensor Deployment 61

Requirements for AWS Sensor Deployment 62

Deploying the AWS Sensor 65

USM Anywhere™ Deployment Guide 3

Setting the AWS Sensor Connection to USMAnywhere 68

Completing the AWS Sensor Setup 71

Enabling syslog Connections in an AWS VPC 78

Adding Another Sensor to Other AWS Accounts 79

AWS LogDiscovery and Collection in USMAnywhere 81

Creating a New CloudWatch Collection Job 84

Creating a New AWS S3AccessCollection Job 88

USMAnywhere Sensor Deployment onMicrosoft Azure 93

About Azure Sensor Deployment 94

Requirements for USMAnywhere Sensor Deployment on Azure 96

Deploying the USMAnywhere Sensor from the AzureMarketplace 97

Setting the Azure Sensor Connection to USMAnywhere 103

Completing the Azure Sensor Setup 106

Creating an Application andObtaining Azure Credentials 120

Adding Another Sensor for Other Azure Subscriptions 122

Azure Log Discovery and Collection in USMAnywhere 125

Device Port Mirroring Configuration 136

Configuring VMware ESX Virtual Switches for Port Monitoring 137

Configuring a Hyper-V Virtual Machine for Port Mirroring on aWindowsServer 2012+ 142

Configuring the ADTRAN (AOS) Switch for Port Mirroring 144

Configuring the Check Point Gateway for Port Mirroring 145

Configuring the Cisco ASA 5505 for Port Mirroring 146

Configuring the Cisco Nexus for Port Mirroring 147

Configuring the Cisco SGxxx Series for Port Mirroring 148

Configuring the Dell Networking Force10 Switch for Port Mirroring 151

Configuring the Fortinet-FortiGate Switch for Port Mirroring 152

Configuring SonicWALL Port Mirroring 153

Alarm and Event Notifications 154

Sending USMAnywhere Notifications to Slack 155

Sending USMAnywhere Notifications to Datadog 161

Sending USMAnywhere Notifications to PagerDuty 168

Sending Notifications Through Amazon SNS 175

4 USM Anywhere™ Deployment Guide

Setup and Configuration of Your USMAnywhere Environment 184

LogManagement 185

File IntegrityMonitoring 186

Collecting Linux System Logs 193

CollectingWindowsSystem Logs 198

Enabling AWS LogCollection 217

Installing osquery and CloudWatch Through the Log Agent 218

Configuring Network Interfaces for On-Premises Sensors 222

Getting Ready for Authenticated Scans 225

Granting Access to Active Directory for USMAnywhere 227

Getting Traffic fromYour Physical Network to the Virtual USMAnywhere Network 228

Managing Jobs in the Scheduler 231

CollectingWindowsSystemData with the Forensics and Response Sensor App 235

PluginManagement 239

USMAnywhere Plugin Operations 240

Manual PluginManagement 245

Requesting a New Plugin or an Update to an Existing Plugin 249

Troubleshooting and Remote Sensor Support 251

Checking Connectivity to the Remote Server 252

Creating a Remote Support Session 254

Collecting Debug Information 256


About USMAnywhere Deployment

USMAnywhere is a SaaS securitymonitoring solution that centralizes threat detection, incidentresponse, and compliancemanagement across your on-premises, cloud, or hybrid environments.Data collection, security analysis, and threat detection are centralized in the AlienVault SecureCloud and provide you with a single view into all of your critical infrastructure.

This chapter includes the following topics:

USMAnywhere Deployment Overview 7

USMAnywhere Architecture 7

USMAnywhere Data Security 8

USMAnywhere Deployment Types and Scalability 10

Deployment Requirements 11

USMAnywhere Deployment Process 13

About USMAnywhere Upgrades 14


USM Anywhere Deployment Overview

USMAnywhere consists of amodular, scalable, two-tier architecture tomanage andmonitor everyaspect of cloud security. Software sensors collect and normalize data from all of your on-premisesand cloud environments, while USMAnywhere provides centralized cloud securitymanagement,analysis, correlation, detection, alerting, logmanagement, and reporting.

Purpose-built USMAnywhere Sensors deploy natively into each environment and help you gainvisibility into all of your on-premises and cloud environments. These sensors collect and normalizelogs, monitor networks, and collect information about the environments and assets deployed in yourhybrid environments.

USM Anywhere Architecture

USMAnywhere is amodular and scalable two-tier architecture.

Tier 1 — USM Anywhere Sensors

USMAnywhere Sensors deploy natively into each environment and help you gain visibility into all ofyour on-premises and cloud environments. USMAnywhere Sensors collect and normalize logs,monitor networks and collect information about the environments and assets deployed in your hybridenvironments.

USMAnywhere Sensors are a key component of the USMAnywhere solution. They operate eitheron-premises or in the cloud:

l Discovering your assets.

l Scanning assets for vulnerabilities.

l Monitoring packets on your networks and collecting data.

l Collecting log data and normalizing it before sending it securely to USMAnywhere.

USMAnywhere Deployment Overview


Tier 2 — USM Anywhere Cloud

USMAnywhere receives the previously described data sent to it by the USMAnywhere Sensor anduses it to provide essential security capabilities in a single SaaS platform:

l Centralized system securitymanagement

l Log data analysis and correlation

l Detection

l Alerting

l Logmanagement

l Reporting

USMAnywhere also integrates logmanagement and retains raw logs securely long-term forforensic investigations and compliancemandates.

USM Anywhere Data Security

As a security-first organization, AlienVault makes your data protection and privacy a top priority.USMAnywhere architecture and processes are designed to protect your data in transit and at rest.

Data Collection

All data sent from the USMAnywhere sensor deployed in your on-premises or cloud environment tothe USMAnywhere service in the AlienVault Secure Cloud is encrypted and transferred over asecure SSL /TLS connection. Each USMAnywhere sensor generates a certificate to communicatewith the USMAnywhere service. Thismeans that all communication is uniquely encrypted betweeneach sensor and USMAnywhere.

The collected data in USMAnywhere is secured using AES-256 encryption for both hot (online)storage and cold (long-term) storage.

USMAnywhere Data Security


Single-Tenant Data Store

Unlike other SaaS solutions that use amulti-tenant architecture, AlienVault uses a single-tenantdata store architecture to securely store your data. With USMAnywhere, your data is stored in itsown dedicated data store, which is completely isolated from other customers’ data. Unlikemulti-tenancy, which is prone to data leakage and breakage that can affect multiple customer accounts,single-tenancy ensures that all customers’ data is kept separate and leak-proof.

Cold Storage Data Integrity

USMAnywhere offers secure, long-term log retention, known as cold storage. By default, USMAnywhere enables 12months of cold storage with the ability to extend the long-term storagecapacity as needed.

USMAnywhere uses a write once, readmany (WORM) approach to log storage to prevent log datafrom beingmodified or otherwise tampered with. You can download your raw logs at any time. If youdo not to renew your subscription, AlienVault will keep the raw logs for 90 days after yoursubscription expires, giving you a grace period to restart your service. After 90 days, your data will bedestroyed.

Data Access

Your data in USMAnywhere is treated as highly confidential, and only a select few AlienVault staffmembers have access. This group of employees usesmulti-factor authentication to access theAlienVault Secure Cloud. Strict internal controls and automation enable support for the service whileminimizing administrative access.

AlienVault also has a formal information security program that implements various security controlsto the NIST Cyber Security Framework. Key controls include: Inventory of Devices, Inventory ofSoftware, Secure Configurations, Vulnerability Assessment, and Controlled Use of AdministrativePrivileges. Additionally, AlienVault conducts security self-assessments on an regular basis.

USMAnywhere Data Security


USM Anywhere Deployment Types and Scalability

USMAnywhere scales with your business needs. Using the following deployment types, you canadd or remove sensors, bring on addition cloud services, and scale central logmanagement as yourbusiness needs change.

On-Premises

USMAnywhere provides EXSi VMware andMicrosoft Hyper-V sensors to support an on-premises(private cloud) deployment.

VMware EXSi Microsoft Hyper-V

l EXSi API asset discovery l NIDS packet inspection

l EXSi logmonitoring and alerting l Network asset discovery

l NIDS packet inspection

l Network asset discovery

Cloud and Multi-Cloud

USMAnywhere provides AmazonWeb Services (AWS) andMicrosoft Azure sensors to supportdeployment on a public cloud. If your organization deploys resources into both of these cloudservices, you can use both sensors tomonitor your assets.

Amazon Web Services Microsoft Azure

l AWS API asset discovery l Azure API asset discovery

l CloudTrail monitoring and alerting l Azure RESTMonitor (formerly Insight Logs) monitoringand alerting

l S3 access logmonitoring and alerting l Azure infrastructure assessment

USMAnywhere Deployment Types and Scalability


Amazon Web Services Microsoft Azure

l ELB access logmonitoring and alerting l Azure Security Alerts

l AWS infrastructure assessment l AzureWindows Log Locations

Hybrid Cloud

A hybrid cloud deployment uses a combination of private (VMware and/or Hyper-V) and public cloud(AWS and/or Azure) sensors.

Deployment Requirements

USMAnywhere has the following general deployment requirements.



Sensor Ports and Connectivity

A deployed USMAnywhere Sensor requires that you open egress/outbound ports and protocols inthe firewall for communication with USMAnywhere and AlienVault cloud resources. After the initialsensor setup, you do not need to open any external inbound ports because the USMAnywhereSensor receives no inbound connections from outside the firewall.

Type Ports Endpoints Purpose

TCP 80 license.alienvault.com Communication with AlienVault for initial setup ofthe sensor

Important: Both ingress and egressare required for the initial setup of thesensor. After the sensor is connected,you can close all ingress for this port.

HTTPS /TCP

80 and443

your USM Anywhere subdomain.alienvault.cloud

Ongoing communication with AlienVault andOpen Threat Exchange®

update.alienvault.cloud

license.alienvault.com

HTTPS /TCP

443 reputation.alienvault.com Ongoing communication with Open ThreatExchange®

SSL / TCP 7100 your USM Anywhere subdomain.alienvault.cloud

Ongoing communication with USM Anywhere

Important: A USMAnywhere Sensor deployed in AWS might require outbound access tospecific AWS resources, based on the Sensor App in use. For example, the AmazonWebServices Sensor Appmust have the ability to connect to the AWS API (port 443). However,the actual API endpoint might be different depending on the service (such as S3 orCloudWatch).

USMAnywhere normally gives systems explicit access to the AWS API.

Supported Web Browsers

USMAnywhere works best in the latest version back of the following web browsers:

l Mozilla Firefox

l Google Chrome

Sensor-Specific Requirements

Each USMAnywhere Sensor has unique requirements. See the following topics for detailedinformation about these sensor-specific requirements:



l Requirements for VMware Sensor Deployment

l Requirements for Hyper-V Sensor Deployment

l Requirements for AWS Sensor Deployment

l Requirements for USMAnywhere Sensor Deployment on Azure

USM Anywhere Deployment Process

The deployment process is kicked off with your USMAnywhere registration and activation. Thereare four basic tasks to complete your initial USMAnywhere deployment.

Task 1: Receive USM Anywhere Download Link and Activation Code

After registering for AlienVaultUSMAnywhere online, the system displays a page with the followinginformation:

l A download link for installing the USMAnywhere Sensor template and, depending on your envir-onment, a VHD image and other files

l An authentication code

You also receive an email with the same information in case you want to save deployment to anothertime.

Task 2: Download and Install Sensor

After you download the USMAnywhere Sensor image and template and install the sensor, log intothe USMAnywhere webUI, using the activation code.

After several minutes, the connection with USMAnywhere in the cloud is completed and you receivea systemmessage with a URL and password. Paste this URL into a browser window and enter yourcredentials, including the password you received in themessage box.

When your code is verified, USMAnywhere prompts you to enter a new password. After passwordverification, the USMAnywhere dashboard appears.

Task 3: Configure Your Network

Prior to configuring USMAnywhere, you should configure your network to ensure that USMAnywhere performs optimally. Some tasks are operating system-specific. Others apply regardless ofoperating system. These consist of the following tasks:

l Collecting Linux System Logs

l CollectingWindowsSystem Logs

l Configuring Network Interfaces for On-Premises Sensors

l Getting Ready for Authenticated Scans

l Getting Traffic fromYour Physical Network to the Virtual USMAnywhere Network

l Granting Access to Active Directory for USMAnywhere

USMAnywhere Deployment Process


l Installing osquery and CloudWatch Through the Log Agent

l USMAnywhere Setup on the VMware Virtual Machine

l USMAnywhere Setup on the Hyper-V Virtual Machine

Task 4: Configure USM Anywhere with the Setup Wizard

A setup wizard specific to each portal guides you through the initial configuration of your USMAnywhere Sensor to initiate the following:

l Log collection

l Logmanagement

l Pluginmanagement

l Authenticated scans of single assets, an asset group, or a network range

You can use the setup wizard to configure each sensor you create when you receive a prompt, oryou can postpone it, or configure sensorsmanually.

After you install and set up the USMAnywhere Sensor, it communicateswith USMAnywhere in thecloud about the assets in your network. The USMAnywhere Sensor then transfers any availableraw plugin data to USMAnywhere in the cloud for correlation and event generation, among otherthings.

About USM Anywhere Upgrades

USMAnywhere upgrades occur as new versions become available, automatically, in thebackground. The upgrade is transparent, and requires no action on your part.

The upgrade process beginswhen the USMAnywhere Sensor first tries to connect to USMAnywhere in the AlienVault secure cloud. If there is an upgrade available, the download andinstallation begins.

You do not need to reconfigure a sensor or restart it after an upgrade.

About USMAnywhere Upgrades


USMAnywhere Sensor Deployment on VMware

AlienVault provides a VMware sensor to monitor your virtual and physical on-premisesinfrastructure. When this USMAnywhere Sensor is deployed and configured for your USMAnywhere instance, security-related data is collected and sent to the AlienVault Cloud for securityanalysis, threat correlation, and secure, compliance-ready data storage.

The VMware sensor deployment includes network intrusion detection (NIDS) that monitors thenetworks connected to the listening interfaces. You can also create jobs to collect log data throughVMware, including operating system and database-level logs.


About VMware Sensor Deployment 16

Requirements for VMware Sensor Deployment 17

Importing the VMwareOVF Package 18

USMAnywhere Setup on the VMware Virtual Machine 20

VMware Sensor Connection to USMAnywhere 22

Completing the VMware Sensor Setup 24


About VMware Sensor Deployment

Through VMware, you can deploy a USMAnywhere Sensor in any of the virtual networks that youwant to instrument for network intrusion detection (NIDS), including standard sensor features:

l Log Data Collection

l Authenticated Asset Scans

l Unauthenticated Asset Discovery Scans

AlienVault distributes the VMware sensor as anOpen Virtual Format (OVF) file that can be deployedthrough vCenter or directly to an ESXi Hypervisor version 5.1 and later.

Important: If you are using VMware ESXi 6.5, the VMware vSphere Desktop Client is requiredfor deployment of the USMAnywhere Sensor OVF. You cannot use the VMware vSphereWebClient interface for this deployment.

The USMAnywhere Sensor deployed on VMware provides the ability to monitor the packets onnetworks that you select by attaching one of the sensor network interfaces to a port configured inPromiscuousmode on a Virtual Switch. This also requires that Port Mirroring is enabled on theupstream physical switch to which the ESXi host is connected.

Note: If your organization usesmultiple subnets to allow communication betweenheadquarters and remote offices, you do not need a sensor for each subnet. However, you willneed a deployed VMware sensor for each physical location that you want to monitor.

There is an option for you to enter credentials for either your vCenter or ESXi servers, which willallow the sensor to discover the VMs registered on the ESXi servers through the vSphere API. Thisallows for the discovery of assets and alsomonitors user logins within your vSphere environmentand feeds the information back to USMAnywhere.

Deployment Process Overview

The deployment process for an initial USMAnywhere Sensor on VMware consists of these primarytasks:

1. Review requirements for a VMware sensor deployment

2. Deploy a VMware sensor by executing the USM_sensor-node.ovf file

3. Configure the sensor on the virtual machine

4. Register the new sensor with your Sensor Authentication Code to provision the USMAnywhereinstance and connect the deployed sensor

5. Complete your VMware sensor configuration, including initial asset discovery

About VMware Sensor Deployment


Requirements for VMware Sensor Deployment

Review the following prerequisites to ensure an efficient setup and configuration of the USMAnywhere Sensor on VMware:

l Access to VMware ESXi 5.1 or later

Important: If you are using VMware ESXi 6.5, the VMware vSphere Desktop Client isrequired for deployment of the USMAnywhere Sensor OVF. You cannot use the VMwarevSphereWebClient interface for this deployment.

l Four cores and 12GB of memory dedicated to VMware

l 150GB of disk space

l If DHCP is not available, a configured static IP for themanagement interface and local DNSinformation

Important: AlienVault strongly recommends assigning a static IP to deploy the USMAnywhere Sensor. If DHCP changes the IP address of the sensor, youmust update all theIP addresses on all the devices that are forwarding logs to the Sensor through syslog.

l Internet connectivity to the network where you plan to install the VMware sensor

l Port mirroring setup for networkmonitoring (see Configuring VMware ESX Virtual Switches forPort Monitoring)

l Administrative credentials for devices fromwhich you want to forward logs to the VMware sensor

l Configuration on firewall or other security device to send UDP syslog (if it is capable of exportingsecurity logs through UDP syslog)

l Network topology information to run asset discovery

l Administrative credentials on your devices for authenticated asset scans

l (Optional) Access to a span port to monitor network traffic for IDS

Requirements for VMware Sensor Deployment







HTTPS /TCP

80 and443





HTTPS /TCP




Importing the VMware OVF Package

AlienVault provides anOVF package, which contains the VMware sensor image and anOVFtemplate that you can import and deploy on a VMware ESXi instance.

Note: This procedure references the VMware vSphere client. If you are using a different client,refer to that vendor's documentation and extrapolate from this procedure.

To load the OVF package on a VMware ESXi instance

1. Download the VMwareOVF package.

This package is provided in.zip format from the USMAnywhere Sensor downloads page:https://www.alienvault.com/products/usm-anywhere/sensor-downloads.

Note: This download can take 30minutes or more.

2. When prompted, save the ZIP file.

3. Decompress the usm-sensor-vmware.zip package to your desktop or wherever you normally

Importing the VMwareOVF Package


https://www.alienvault.com/products/usm-anywhere/sensor-downloads

save VMware packages.

It should extract the following files:

l deploy_config.iso

l USM_sensor-node.ovf

l USM-disk1.vmdk

l USM.mf

4. In VMwareManager, choose File > Deploy OVF Template.

VMwareManager displays the DeployOVF Template page.

5. Browse to USM_sensor-node.ovf (one of the files you just extracted) and click Next.

6. Click Next for each of the following pages.

You do not need to change the settings unless you want to change the default sensor name.

l OVF Template Details

l (Optional) Name and Location — Youmay change the name, if desired.

l Disk Format

7. On the Ready to Complete page, select Power on after deployment and click Finish.

Deployment of the virtual image takes several minutes. As the deployment progresses and thencompletes, VMwareManager displays the followingmessages:

Deploying USM Anywhere Sensor Node

Deploying disk 1 of 2 from: (File Location)

Deploying disk 2 of 2 from: (File Location)

Completed Successfully

Note: If you chose a different name for your sensor, that name appears in the firstmessage instead of the default name.

8. Click Close.

9. Connect to the console of the USMAnywhere Virtual Appliance using one of the followingmethods:

l Select the new VMware virtual machine from the inventory list of the VMware Managementpage, choose to open a console, and then power it on.

l In the console toolbar, click the console icon.

The system initialization screen displays the URL that you use to accessUSMAnywhere.

Importing the VMwareOVF Package


USM Anywhere Setup on the VMware Virtual Machine

There is some configuration required within the sensor console on the virtual machine. The sensorconsole also provides tools for troubleshooting the USMAnywhere Sensor. After this initialconfiguration, you complete the sensor configuration in the USMAnywhere webUI.

Perform these initial configuration tasks on the VMware virtual machine, using the USMAnywhereSensor console.

Changing the Keyboard Layout and Administrative Password

To change keyboard layout and the administrative password

1. Log in using the credentials displayed in the console screen.

2. (Optional) Configure the keyboard if you use a keyboard layout other than the U.S. default.

3. Set a new password for the sysadmin user.

Important: During the installation, your system acquires the initial IP address throughDHCP. If DHCP is not enabled, youmust configure it manually.

AlienVault strongly recommends assigning a static IP address to the USMAnywhereSensor as a best practice. This allows for proper log forwarding and network architecture.

l If your system sets an IP address automatically, note the webURL. You will need theURL when you exit from the console and follow the instructions in VMware SensorConnection to USMAnywhere.

USMAnywhere Setup on the VMware Virtual Machine


l If your system does not set an IP address automatically, a message box confirms that thesystemwas unable to acquire an IP address from aDHCP server after you change thesysadmin password.

l In this case, youmust manually set a static IP address so that it remains unchanged infuture.

Configuring a Static IP Address

To configure a static IP address

1. Navigate to Network Configuration > Configure Management Interface > Set a Static Man-agement IP Address.

2. Enter the IP Address, subnet, and gateway information in each input screen.

3. Press Enter (OK).

Configuring DNS

To configure DNS

1. Navigate to the option Network Configuration > Configure DNS.

2. Enter the primary DNS and press Enter (OK).

3. (Optional) Enter the secondary DNS and press Enter (OK).

A text box appears to confirm that you want to apply changes.

4. Press Enter (Yes).

Note: Check your settings through Network Configuration > View Network Configuration.

USMAnywhere Setup on the VMware Virtual Machine


VMware Sensor Connection to USM Anywhere

After obtaining the IP address used to connect to USMAnywhere, youmust provision your USMAnywhere instance within the AlienVault Secure Cloud. This IP address is provided when you setyour management interface settings in the sensor console and it directs you to the sensor connectionweb interface.

Register the Sensor with USM Anywhere

After you complete the deployment of your first USMAnywhere Sensor, youmust register thesensor using the initial Authentication Code (starts with a "C"), which requests a USMAnywhereinstance and defines its attributes (such as how many sensors to allow, how much storage toprovide, and what email address is used to create the initial user account).

Important: USMAnywhere instance provisioning takes place only for the first deployedsensor. If you are deploying an additional sensor in your USMAnywhere environment, you cansimply register the sensor using the generated authentication code (starts with an "S") and usethe SetupWizard to complete the sensor deployment.

To register your sensor and provision the instance

1. Open a web browser and enter the IP address.

This opens theWELCOME TO USM ANYWHERE SENSOR SETUP page, which promptsyou to provide the information for registering the sensor with your USMAnywhere instance.

2. Enter a Sensor Name and Sensor Description.

3. Paste the authentication code sent fromAlienVault into the field with the Key icon ( ).

4. Click Start Setup to start the process of connecting the USMAnywhere Sensor.

The provisioning of your USMAnywhere instance upon registration of your initial sensor takesabout 20minutes. When this instance is provisioned and running, you’ll see a welcomemessagethat provides an access link.

VMware Sensor Connection to USMAnywhere


Use this link to open the secured web console for your USMAnywhere instance. You and theother USMAnywhere users in your organization can access this console from aweb browser onany systemwith internet connectivity.

Note: You'll also receive an email fromAlienVault that provides the access link to USMAnywhere.

Configure the Initial Login Credentials

When you link to a newly-provisioned USMAnywhere instance, youmust configure the passwordfor the initial user account. This is the default administrator as defined in your subscription.

To configure login credentials

1. Click the link in the welcomemessage.

This displays a prompt to set the password to use for the default administrator of USMAnywhere.

2. Enter the password, and again to confirm.

USMAnywhere requires aminimumpassword length of eight characters, with amaximumlength of 128 characters. The passwordmust combine numerical digits (0-9), uppercase letters(A-Z), and lowercase letters (a-z). Special characters, such as hyphen (-) and underscore (_)are supported, but optional.

Note: USMAnywhere passwords expire after 90 days.When your password expires,USMAnywhere enforces the password change when you next log into the system usingthe current (now expired) password. A new passwordmust be different than the previousfour passwords.

3. Click Save & Continue.

VMware Sensor Connection to USMAnywhere


4. When the login page appears, enter the password you just set, select the acceptance of theterms of service, and click Login.

Completing the VMware Sensor Setup

R o l e Ava i l a bi l i ty R ead-Onl y Ana lys t Manager

After you initialize a new USMAnywhere Sensor, youmust configure it in the SetupWizard. As youcomplete the VMware sensor configuration, USMAnywhere performs specific actions, like runningan asset discovery scan and collecting logs.

Accessing the SetupWizard

The SetupWizard launches under the following circumstances:

l When you first log into the USMAnywhere webUI and see theWELCOME TOUSMANYWHERE page, clickGet Started.

l If you configured a first sensor, but did not complete the setup and then logged out, the Setup wiz-ard launches to remind you to finalize configuration on the remaining sensors when you log inagain.



Configuring the VMware Sensor in the SetupWizard

The first time you log in from theWELCOME TOUSMANYWHERE web page, the SetupWizardprompts you to complete the configuration of the first deployed sensor. Thereafter, you can use theSensors page to configure an additional sensor or to change the configuration options for a deployedsensor.

Note: Youmust have already configured your network interfaces for VMware. For moreinformation, see USMAnywhere Setup on the VMware Virtual Machine.

Within the SetupWizard, complete the configuration on each page.

VMWARE CONFIGURATION

The first page in the SetupWizard for a VMware sensor is the VMWARE CONFIGURATION page.The vCenter/ESXi details that you provide on this page will allow USMAnywhere to discover assetsin your VMware environment and also collect events from that environment.

Note: If you aremodifying the configuration of a sensor that is already connected, thesesettings are not required to proceed. You can click the Next button at the bottom-right to skipthis step.



To complete the VMware configuration step

1. Enter your VCenter or vSphere IP address and user credentials.

2. Click Save Credentials.

3. Click Next.

The wizard displays the next page in the setup process, ASSET DISCOVERY.



ASSET DISCOVERY

When youmove forward to the ASSET DISCOVERY page, a dialog automatically appears andprompts you to allow asset scanning. USMAnywheremust discover your assets to enable securitymonitoring on them.

To complete the asset discovery task

1. Click Yes to start the automatic asset discovery.

Or, if you prefer to add the assetsmanually or scan another network, click No and skip to thenext step.

During the automated scan, the Scan Networks status bar appears and displays the number ofassets detected in your network range.



When the scan stops, you have the option to either scan a different set of assets (click ScanAnother) or continue with asset discovery setup options (click Next).

When the initial asset scan dialog closes, the ASSET DISCOVERY page displays statusinformation for an ongoing scan or any discovered assets for completed scans.



2. (Optional) ADD ASSETS MANUALLY

Enter the name and IP address or FQDN to specify an asset for discovery. The scan option isselected by default. Click Save to add the asset.

You can repeat this for each individual asset you want to add.

3. (Optional) ADD ASSETS BY SCANNING NETWORK RANGE

Click Scan Networks to scan a network range that you specify. This runs an Nmap (NetworkMapper) scan to discover hosts and services running on the specified network range.

4. When all the needed assets are discovered, click Next at the bottom of the page.

The wizard displays the next page in the setup process, ACTIVE DIRECTORY.

NETWORK SECURITY MONITORING

TheNETWORK SECURITY MONITORING page shows the status of the network interfacesmonitored by the sensor (it could take a few moments to load the interfaces). All network adaptersare configured for networkmonitoring by default.

Youmust manually enable port mirroring/spanning and/or promiscuousmode in a virtual switch tosend a copy of the network traffic you want to analyze to these interfaces. This page provides links todocumentation about how to configure your networking to allow for the interfaces to see the networktraffic and performNetwork Intrusion Detection.



Note: Youmust have already configured your network interfaces for VMware. For moreinformation, see USMAnywhere Setup on the VMware Virtual Machine.

Use this page to verify that USMAnywhere is able tomonitor your network traffic for security events.

Note: You will see red X icons next to the interfaces if the port mirroring or promiscuousmodeis not configured. Youmight also see these icons if the network interfaces have not seen anytraffic in the past 30 seconds.

1. To access detailed information about port mirroring set up, click How do I set up portmirroring?.

This opens a dialog that can direct you to specific information about your device.

If you have not yet set up port mirroring, you can also go directly to Configuring VMware ESXVirtual Switches for Port Monitoring.

2. Click Next.

LOG MANAGEMENT

On the LOG MANAGEMENT page, you see the IP addresses of the assets you added during theasset discovery configuration. You also see the port number. (The port is the same for all USMAnywhere Sensors.)

USMAnywhere collects third-party device data through syslog on port 514 by default. To configureany third-party devices to send data to USMAnywhere, youmust give them the IP address of yourUSMAnywhere Sensor and the port number.



Make sure that you've granted the necessary permissions for your operating system to allow USMAnywhere to access its logs. You can also integrate a wide variety of plugins to send log data oversyslog to the USMAnywhere Sensor.

To find out how to configure your operating system and supported third-party devices to forwardsyslog log data, see the following related topics:

l Log collection from a Linux System — Collecting Linux System Logs.

l Log collection from aWindows System — CollectingWindowsSystem Logs.

l Log collection from other devices using a plugin — USMAnywhere Plugin Operations.

Note: Because the log scan can take some time, youmight not see all the automaticallydiscovered log sources immediately after deploying the first sensor.

When you've finished the log collection setup and integrated any needed plugins, verify that the datatransfer is occurring.

Click Next when this step is complete.



THREAT INTELLIGENCE

AlienVault Open Threat Exchange® (OTX™) is an open information-sharing and analysis networkproviding users the ability to collaborate, research, and receive alerts on emerging threats andindicators of compromise (IOC) such as IPs, file hashes, and domains.

Youmust have anOTX account to receive alerts based on threats identified in OTX. This account isseparate from your USMAnywhere account. See the TheWorld’s First Truly Open ThreatIntelligence Community page for signing up for anOTX account.

Note: If you do not already have anOTX account, click the Signup for an OTX account link inthe page. This opens another browser tab or window that displays the OTX signup page. Afteryou confirm your email address, you can log into OTX and retrieve the unique API key for youraccount.

1. Log into OTX and open the API page (https://otx.alienvault.com/api/).

2. In the DirectConnect API Usage panel, click the Copy ( ) icon to copy your uniqueOTX connection key.

3. Return to the Threat Intelligence page of the USMAnywhere Sensor setup wizard and pastethe value in the OTX Key text box.



https://otx.alienvault.com/


https://otx.alienvault.com/api/

4. Click Validate OTX Key.

With a successful validation of the key, the status at the top of the page changes to ValidOTX key.

Click Next when this task is complete.

Note: SeeOpen Threat Exchange® and USMAnywhere for further information.



SETUP COMPLETE

TheCongratulations! page summarizes the status of your configuration.

Click Start Using USM Anywhere, which takes you to the Overview dashboard.

Next...

Now's a great time to run a vulnerability scan. You can learn how to run a vulnerability scan by goingto Vulnerability Assessment in the USMAnywhere User Guide.



USMAnywhere Sensor DeploymentonMicrosoft Hyper-V

Microsoft Hyper-V is a hypervisor that lets you create andmanage a virtualized computingenvironment by using virtualization technology that is built intoWindowsServer. ThroughMicrosoftHyper-V, you can deploy a USMAnywhere sensor in any of the virtual networks that you want toinstrument for threat monitoring.

The Hyper-V sensor deployment includesNIDS that monitors the networks connected to thelistening interfaces.


About Hyper-V Sensor Deployment 36

Requirements for Hyper-V Sensor Deployment 36

Creating the Hyper-V Virtual Machine 38

USMAnywhere Setup on the Hyper-V Virtual Machine 44

Hyper-V Sensor Connection to USMAnywhere 46

Completing the Hyper-V Sensor Setup 48


About Hyper-V Sensor Deployment

AlienVault provides a package containing the following files to deploy a USMAnywhere Sensor onMicrosoft Hyper-V:

l A disk image file: deploy_config

l An XML document: USM_sensor-node

l The hard disk images files: usm-data-disk.vhdx and usm-os-disk.vhd

If your organization usesmultiple subnets to allow communication between headquarters andremote offices, you do not need a sensor for each subnet, but you will need a Hyper-V sensor foreach physical location that you want to monitor.

Note: For further information about Hyper-V, see theMicrosoft TechNet website(https://technet.microsoft.com/en-us/library/mt169373(v=ws.11.aspx).

Deployment Process Overview

The deployment process for an initial USMAnywhere Sensor on Hyper-V consists of these primarytasks:

1. Review requirements for a Hyper-V sensor deployment

2. Create, configure, and start the Hyper-V virtual machine

3. Configure the sensor on the virtual machine

4. Register the new sensor with your Sensor Authentication Code to provision the USMAnywhereinstance and connect the deployed sensor

5. Complete your Hyper-V sensor configuration, including initial asset discovery

Requirements for Hyper-V Sensor Deployment

Review the following prerequisites to ensure an efficient setup and configuration of a USMAnywhere Sensor on Hyper-V:

l Operating systemmust be 2012 R2with either Hyper-V Manager or SystemCenter Virtual Man-ager (SCVMM) 2012

l Four cores and 12GB of memory dedicated to the Hyper-V virtual machine

l 150GB of disk space

l If DHCP is unavailable, a static IP for themanagement interface and local DNS information

About Hyper-V Sensor Deployment


https://technet.microsoft.com/en-us/library/mt169373(v=ws.11).aspx

Important: AlienVault strongly recommends assigning a static IP to deploy the USMAnywhere Sensor. If DHCP changes the IP address of the sensor, youmust update all theIP addresses on all the devices that are forwarding logs to the Sensor through syslog.

l Internet connectivity from the virtual machine

l Network topology information to run asset discovery

l Port mirroring setup for networkmonitoring (see Configuring a Hyper-V Virtual Machine for PortMirroring on aWindowsServer 2012+ for more information)

l Administrative credentials for authenticated asset scans

l Administrative credentials for devices fromwhich you want to forward logs to the Hyper-V sensor

l (Optional) A span port to monitor network traffic for IDS






HTTPS /TCP

80 and443





HTTPS /TCP




Requirements for Hyper-V Sensor Deployment


Hyper-V Machine Deployment

You can deploy a Hyper-V virtual machine using either of the followingmanagement tools:

l Microsoft Hyper-V Manager, which is an administrative tool for managing local and remoteHyper-V servers. For more information, see Creating the VMwith Hyper-V Manager.

l System Center Virtual Machine Manager 2012, which is designed for managing large numbersof virtual servers, based onMicrosoft Virtual Server and Hyper-V. For more information, seeCreating the VMwith SCVMM2012.

Creating the Hyper-V Virtual Machine

Before you deploy the Hyper-V sensor, youmust create, configure, and start the virtual machine(VM) using either the Hyper-V Manager or SystemCenter Virtual Manager (SCVMM) 2012. Beforeyou begin this task, download the Hyper-V sensor package fromAlienVault(http://downloads.alienvault.cloud/usm-anywhere/sensor-images/usm-anywhere-sensor-hyperv.zip), extract the contents, and place the files where they are accessible from your Hyper-Vmanagement tool.

Creating the VM with Hyper-VManager

Follow these procedures to create, configure, and start the virtual machine using Hyper-V Manager.

Creating the Virtual Machine

To create a new virtual machine with Hyper-V Manager

1. Open the Hyper-V Manager and connect to the server.

2. From the Actions panel, go to New > Virtual Machine.

The New Virtual Machine Wizard launches. You can simply click Next in the entry page.

3. In Specify Name and Location, enter a name for the new virtual machine and then click Next.



http://downloads.alienvault.cloud/usm-anywhere/sensor-images/usm-anywhere-sensor-hyperv.zip

http://downloads.alienvault.cloud/usm-anywhere/sensor-images/usm-anywhere-sensor-hyperv.zip

4. In Specify Generation, chooseGeneration 1 for the virtual machine and then click Next.

5. In Assign Memory, change the value of the Startup memory to 12288MB.

Alsomake sure that the Use Dynamic Memory option is not selected. Click Next whencomplete.

6. In Configure Networking, connect the new virtual machine to the desired network and then clickNext.

7. In Connect Virtual Hard Disk, select Use an existing virtual hard disk and then click Browseto locate the usm-os-disk.vhd file that was part of the sensor download.

Note: You will add the data disk later in another step, because the wizard doesn't supportthis.



8. In Complete the New Virtual Machine Wizard, click Next and then Finish.

Configuring the Virtual Machine

To configure a virtual machine using the Hyper-V Manager

1. Select the virtual machine you previously created, and click Settings.

2. In the dialog, select Processor in the left navigation pane and set the Number of Virtual Pro-cessors to four (4).

3. Click Apply.

4. In the left navigation pane, select IDE Controller 0.

5. Select Hard Drive and click Add, then click Browse to locate the usm-data-disk.vhdx filethat was part of the sensor download.

6. At the top-left corner of the dialog, click Add Hardware, then Network Adapter ExternalNetwork > Add to add five network adapters.

Important: The Hyper-V sensor requires all five NICs to be enabled. You should connecteach of the additional NICs to any additional network you want to monitor, or to adead/inactive network. All five NICsmust be associated to some network (active orinactive) to allow successful update of the sensor. Do not configure the additional NICs tothe same SPAN port, because this will cause duplicated events.

For more information about these interfaces, see Configuring Network Interfaces for On-Premises Sensors.



7. ClickOK.

8. Click IDE Controller 1 > DVD Drive.

9. Click Browse to locate the deploy_config.iso image file that was part of the sensordownload, then click Apply.

Starting the Virtual Machine

To connect the virtual machine to USM Anywhere

l Select your virtual machine and, in the right panel, click Connect.

The system initialization screen appears and displays the URL used to accessUSMAnywhereand register the sensor.



Creating the VM with SCVMM 2012

Follow these procedures to create and start the virtual machine using SystemCenter VirtualMachineManager (SCVMM) 2012.

Creating the Virtual Machine

To create a virtual machine with SCVMM 2012

1. Connect to SCVMM2012.

2. Select Library > VM Templates.

3. Select the AlienVault VMTemplate under VM Templates, and click Create Virtual Machine.

4. Enter a name for the virtual machine and then click Next.

5. In the Configure Hardware, click Next.

6. In Select Destination, choose whether to deploy or store the virtual machine and then clickNext.

7. In Select Host, select a destination for the virtual machine and then click Next.

8. In Configure Settings, review the virtual machine settings and then click Next.

9. In Add Properties, change the automatic actions, if needed, and then click Next.



10. In Summary, confirm the settings and then click Next.

The Jobs window appears and shows the virtual machines in the process of creation.

When the process finishes, youmay close the window.

Starting the Virtual Machine

To connect your machine to USM Anywhere

l Right-click the virtual machine and select Connect or View > Connect via Console.

The system initialization screen appears and displays the URL you can use to accessUSMAnywhere and register the sensor.



USM Anywhere Setup on the Hyper-V Virtual Machine

There is some configuration required within the console of the sensor. After this initial configuration,you use the USMAnywhere webUI to further configure the sensor, and all other sensors that youconnect to USMAnywhere.

Perform these initial configuration tasks on the Hyper-V virtual machine, using the USMAnywhereSensor console.

Changing the Keyboard Layout and Administrative Password

To change keyboard layout and the administrative password

1. Log in using the credentials displayed in the console screen.

2. (Optional) Configure the keyboard if you use a keyboard layout other than the U.S. default.

3. Set a new password for the sysadmin user.

Important: During the installation, your system acquires the initial IP address throughDHCP. If DHCP is not enabled, youmust configure it manually.

AlienVault strongly recommends assigning a static IP address to the USMAnywhereSensor as a best practice. This allows for proper log forwarding and network architecture.

l If your system sets an IP address automatically, note the webURL. You will need theURL when you exit from the console and follow the instructions in Hyper-V SensorConnection to USMAnywhere .

USMAnywhere Setup on the Hyper-V Virtual Machine


l If your system does not set an IP address automatically, a message box confirms that thesystemwas unable to acquire an IP address from aDHCP server after you change thesysadmin password.

l In this case, youmust manually set a static IP address so that it remains unchanged infuture.

Configuring a Static IP Address

To configure a static IP address

1. Navigate to Network Configuration > Configure Management Interface > Set a Static Man-agement IP Address.

2. Enter the IP Address, subnet, and gateway information in each input screen.


Configuring DNS

To configure DNS

1. Navigate to the option Network Configuration > Configure DNS.


3. (Optional) Enter the secondary DNS and press Enter (OK).

A text box appears to confirm that you want to apply changes.


Note: Check your settings through Network Configuration > View Network Configuration.

USMAnywhere Setup on the Hyper-V Virtual Machine


Hyper-V Sensor Connection to USM Anywhere

After obtaining the IP address used to connect to USMAnywhere, youmust provision your USMAnywhere instance within the AlienVault Secure Cloud. This IP address is provided when you setyour management interface settings in the sensor console and it directs you to the sensor connectionweb interface.











Hyper-V Sensor Connection to USMAnywhere













Hyper-V Sensor Connection to USMAnywhere



Completing the Hyper-V Sensor Setup


After you initialize a new USMAnywhere Sensor, youmust configure it in the SetupWizard. As youcomplete the Hyper-V sensor configuration, USMAnywhere performs specific actions, like runningan asset discovery scan and collecting logs.







Configuring the Sensor in the SetupWizard


Note: Youmust have already configured your network interfaces for Hyper-V. For moreinformation, see USMAnywhere Setup on the Hyper-V Virtual Machine.

Within the SetupWizard, complete the configuration on each page.



ASSET DISCOVERY

When youmove forward to the ASSET DISCOVERY page, a dialog automatically appears andprompts you to allow asset scanning. USMAnywheremust discover your assets to enable securitymonitoring on them.

To complete the asset discovery task

1. Click Yes to start the automatic asset discovery.

Or, if you prefer to add the assetsmanually or scan another network, click No and skip to thenext step.

During the automated scan, the Scan Networks status bar appears and displays the number ofassets detected in your network range.



When the scan stops, you have the option to either scan a different set of assets (click ScanAnother) or continue with asset discovery setup options (click Next).

When the initial asset scan dialog closes, the ASSET DISCOVERY page displays statusinformation for an ongoing scan or any discovered assets for completed scans.



2. (Optional) ADD ASSETS MANUALLY

Enter the name and IP address or FQDN to specify an asset for discovery. The scan option isselected by default. Click Save to add the asset.

You can repeat this for each individual asset you want to add.

3. (Optional) ADD ASSETS BY SCANNING NETWORK RANGE

Click Scan Networks to scan a network range that you specify. This runs an Nmap (NetworkMapper) scan to discover hosts and services running on the specified network range.

4. When all the needed assets are discovered, click Next at the bottom of the page.


ACTIVE DIRECTORY

The optional ACTIVE DIRECTORY setup page configuresUSMAnywhere to collect informationfrom your Azure Active Directory (AD) account. Tomonitor Windows systems effectively, USMAnywhere needs access to AD (Active Directory) server to collect inventory information.

AlienVault recommends that you create a dedicated AD account with membership in the DomainAdmins group to be used byUSMAnywhere to log in into theWindows systems. You also need toactivateWinRM in the Domain Controller and in all the hosts that you want to scan. You can do thisby using a group policy for all the systems in your Active Directory.



Important: Before this feature is fully functional, youmust allow access to the USMAnywhereSensor in the Active Directory server. For more information see, Granting Access to ActiveDirectory for USMAnywhere.

To complete the AD access configuration

1. Provide the AD credentials for USMAnywhere:

l Active Directory IP Address — Enter the IP address for the AD instance.

l Username — Enter your username as administrator of the account.

l Password — Enter your administrator's password.

l Domain — Enter the domain for the AD instance.

2. Click Scan Active Directory.

After a successful launch of the scan, a confirmation dialog appears.



3. Click Accept.

The scan continues in the background.

Upon completion, another dialog appears and provides information about the number of assetsUSMAnywhere discovered. It also prompts you to decide if you want to scan for hosts andservices running in your environment.

Click CANCEL to opt out of this scan.

4. (Optional) If you want to scan for other hosts and services, clickOK.

5. Click Next after the scan ends.

The wizard displays the next page in the setup process, NETWORK SECURITYMONITORING.

NETWORK SECURITY MONITORING

TheNETWORK SECURITY MONITORING page shows the status of the network interfacesmonitored by the sensor (it could take a few moments to load the interfaces). All network adaptersare configured for networkmonitoring by default.

Youmust manually enable port mirroring/spanning and/or promiscuousmode in a virtual switch tosend a copy of the network traffic you want to analyze to these interfaces. This page provides links todocumentation about how to configure your networking to allow for the interfaces to see the networktraffic and performNetwork Intrusion Detection.

Note: Youmust have already configured your network interfaces for Hyper-V. For moreinformation, see USMAnywhere Setup on the Hyper-V Virtual Machine.



Use this page to verify that USMAnywhere is able tomonitor your network traffic for security events.

Note: You will see red X icons next to the interfaces if the port mirroring or promiscuousmodeis not configured. Youmight also see these icons if the network interfaces have not seen anytraffic in the past 30 seconds.

1. To access detailed information about port mirroring set up, click How do I set up portmirroring?.

This opens a dialog that can direct you to specific information about your device.

If you have not yet set up port mirroring, you can also go directly to Configuring a Hyper-V VirtualMachine for Port Mirroring on aWindowsServer 2012+.

2. Click Next.

LOG MANAGEMENT





CLOUD SERVICES

Use the Cloud Services page to configure USMAnywhere to collect information from any of thesupported cloud services apps. These apps allow you tomonitor and detect threats against yourcloud services accounts, such asG Suite (Google Apps) andO365, directly fromUSMAnywhere.When configured , the AlienApp collects log data from via the cloud service API and analyzes thatdata against our built-in threat intelligence to look for anomalies and intrusions.

To setup cloud services in USM Anywhere

1. Select the AlienApp for each cloud service where you want to monitor activity.

2. Click Next.

USMAnywhere displays a configuration page for each cloud service you selected.

3. Complete the form for its configuration and click Save Credentials.

4. Click Next. when this step is complete.

THREAT INTELLIGENCE












SETUP COMPLETE



Next...




USMAnywhere Sensor Deployment on AWS

TheUSMAnywhere Sensor provides operational visibility into the security of your AmazonWebServices (AWS) environment. Based on the collected log information, USMAnywhere analyzes thedata generated by your AWS environment and provides real-time alerting to identifymaliciousactivity. The sensor is deployed into your AWS environment to provide ultimate control over theinstallation and the data contained within it, and also avoiding any external access to yourenvironment.


About AWS Sensor Deployment 61

Requirements for AWS Sensor Deployment 62

Deploying the AWS Sensor 65

Setting the AWS Sensor Connection to USMAnywhere 68

Completing the AWS Sensor Setup 71

Enabling syslog Connections in an AWS VPC 78

Adding Another Sensor to Other AWS Accounts 79

AWS LogDiscovery and Collection in USMAnywhere 81

Creating a New CloudWatch Collection Job 84

Creating a New AWS S3AccessCollection Job 88


About AWS Sensor Deployment

All USMAnywhere Sensors allow for authenticated scans of assets by leveraging stored credentialsthat you define in USMAnywhere. This allowsUSMAnywhere to detect potential vulnerabilities,installed software packages, and running processes and services. Unlike the other USMAnywhereSensors, the AWS sensor queries AWS directly to discover assets using an AWS API.

Log Collection and Scans

The AWS sensor collects AWS logs and system logs, and generates asset scans and vulnerabilityassessments, consisting of the following:

l AWS CloudTrail Log

l AWS CloudWatch Log

l AWS Classic Load Balancer Log

l AWS Application Load Balancer Log

l S3 Access Logs

l Operational logs for critical software packages deployed, such asHTTP servers and databaseservers

l Asset scans on your VMs to inventory installed software packages, running processes, and ser-vices

l Periodic vulnerability assessments

Log Analysis

USMAnywhere analyzes these logs in these stages:

1. Collects logs from systems and software running in your environment

2. Configures log line processing and generates events

l Includes IP addresses and timestamps culled from extracted log line data

l Adds other data to the event, such as security context and environmental information

3. Analyzes events and stores them

About AWS Sensor Deployment


Deployment Overview

AlienVault distributes the AWS sensor as a CloudFormation Template in two different forms. Theone that you use depends on the type of AWS environment where you want to deploy it (a VirtualPrivate Cloud or the EC2-Classic).

The deployment process for an initial USMAnywhere Sensor in your AWS environment consists ofthese primary tasks:

1. Review requirements for an AWS sensor deployment

2. Deploy the USMAnywhere Sensor within your AWS environment

3. Register the sensor with your Sensor Authentication Code to provision the USMAnywhereinstance and connect the deployed sensor

4. Complete your AWS sensor configuration, including initial asset discovery

Requirements for AWS Sensor Deployment

USMAnywhere runs in either an Amazon Virtual Private Cloud (VPC) or in the classicmode ofAmazon Elastic Compute Cloud (Amazon EC2).

Requirement Description

t2.large / m3.large instance t2. large instance in a virtual private cloud (VPC) oran m3. large in EC2-Classic

12-GB EBS volume Provides short-term storage for your data as it isprocessed. Recommended volume: 12-GB elasticblock store (EBS).

Internet connection to the USM Anywhere securecloud

Important: If you download and deploy the t2 instance, youmust launch it into a virtual privatecloud (VPC); this instance type is not supported on the EC2-Classic platform. You cannotchange the instance type of an existing instance in EC2-Classic to a t2 instance type.



Application Service Dependencies

With the CloudFormation Template provided by AlienVault, you can automatically deploy USMAnywhere as a service into your environment. Review the following lists for information about theoutbound/inbound IP addresses, ports, and services used byUSMAnywhere.






HTTPS /TCP

80 and443





HTTPS /TCP




Important: A USMAnywhere Sensor deployed in AWS might require outbound access tospecific AWS resources, based on the Sensor App in use. For example, the AmazonWebServices Sensor Appmust have the ability to connect to the AWS API (port 443). However,the actual API endpoint might be different depending on the service (such as S3 orCloudWatch).

USMAnywhere normally gives systems explicit access to the AWS API.



https://aws.amazon.com/cloudformation/aws-cloudformation-templates/

AWS Services

USMAnywhere uses the following AWS services:

l AWS CloudWatch

l AWS CloudTrail

l Elastic Load Balancing

l Amazon Simple Storage Service (AWS S3)

l Amazon EC2

l AWS Identity and AccessManagement (IAM)

Note: USMAnywhere uses us-east-1 as a default region in the amazon-aws app. As a result,youmight want to verify whether or not your sensors are communicating with us-east-1, even ifyou have never deployed to that region.

Installation Prerequisites

Before you install the AWS sensor, make sure you have the following prerequisites available:

Prerequisites Description

AWS CloudFormation template, available fromAlienVault

The CloudFormation template automatically creates allrequired AWS resources for deployment, including anIAM Role and instance profile for use by the USMAnywhere instance.

Privileged user account on AWS To deploy the CloudFormation template, you must havea privileged user account in AWS with permissions tocreate Identity and Access Management (IAM)resources.

Multiple Accounts or VPCs

If you havemultiple AWS accounts, youmust deploy the AWS sensor in each AWS account that youwant to monitor.

Amazon VPC enables you to launch AWS resources into a virtual network that you've defined. Asingle sensor canmonitor an entire AWS account, even when it containsmultiple virtual privateclouds (VPCs).

Note: If you intend to use the USMAnywhere vulnerability scanner with the AWS sensor, youmust allow traffic from the sensor and the target instance you are scanning. You can usuallyaccomplish this by using VPC peering.



Deploying the AWS Sensor

After you review the requirements andmake sure that your AWS environment is configured asneeded, you can deploy the AWS sensor. Using the CloudFormation Template provided byAlienVault, you automatically deploy USMAnywhere as a service into your environment.

You will need the following resources to complete this process:

l Link to the USMAnywhere Sensor page where you can download the sensor template. (Ali-enVault also sends an email with this information.)

l Product authentication code

l License key

The following procedure describes how to launch the AWS sensor when provisioning the USMAnywhere service for the first time. In this process, you launch the USMAnywhere product from theAWS console using the AWS CloudFormation template.

Important: If you are deploying the sensor in a VPC, make sure that the target VPC subnethas the Enable auto-assign public IPv4 address option enabled prior to creating theCloudFormation stack. For detailed information, refer to the AWS documentation.

To create a new sensor in the AWS console

1. Under Management Tools, click CloudFormation.

2. Click Create New Stack.

This launches the AWS Create Stackwizard.

3. On the Select Template page, scroll to the Choose a template section and select Specify anAWS S3 template URL.



https://aws.amazon.com/cloudformation/aws-cloudformation-templates/


http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#subnet-public-ip

4. In another browser tab or window, open the sensor download link you received fromAlienVault.

This page provides two AWS sensor templates. Click the template that is correct for yourenvironment and copy the displayed URL:

l VPC

l Non-VPC (EC2Classic)

5. Return to the AWS console and paste the link it in the text box for the selected template option.

6. Click Next.

7. On the Specify Details page, enter a name in the Stack name text box.

The namemust be one word. Use hyphens, if desired. For example, you could call the stack"USM-sensor-1".

8. Set the Parameters.

Note: The volume size should be prefilled. You can leave this setting at the default value.

l In the USM Anywhere Sensor Name text box, enter the same name you used for the stack.

l In the Key Name list, select the PEM file that you normally use for an ssh connection intoAWS.

l Specify the HTTP Access Range and SSH Access Range.

Click Next when the stack details are complete.

9. (VPC templates only) Select the appropriate VPC ID and Subnet ID, then click Next.

10. (Optional) On theOptions page, set tags for the instance and click Next.



11. On the Review page, select the checkbox at the bottom of the page, next to the statement:

I acknowledge that AWS CloudFormation might create IAM resources.

12. Click Create.

13. In the Create stack page, confirm that your newly-created stack status reads:

CREATE_IN_PROGRESS

Stack creation typically takes about 15minutes. When the stack build is complete, you see thefollowing confirmation:

CREATE_COMPLETE

14. After your new stack is complete, click the Outputs tab at the bottom of the Create Stack tableand click the URL link (displayed in blue) at bottom of the page.

This redirects you to the Instances page in the AWS console, where you can access the publicIPv4 address of your deployed sensor.

15. Make note of the IPv4 Public IP address for your deployed sensor instance because you willneed this information to complete the sensor registration in USMAnywhere.



You can refer to the AWS documentation for more information about the public IPv4 address.

Setting the AWS Sensor Connection to USM Anywhere

After obtaining the IP address used to connect to USMAnywhere, youmust provision your USMAnywhere instance within the AlienVault Secure Cloud. This IP address is provided after you createthe USMAnywhere Sensor stack and start the instance in your AWS account.








Setting the AWS Sensor Connection to USMAnywhere


http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#using-instance-addressing-common


Verify That the USM Anywhere Sensor Is Running

It's a good idea to verify that the USMAnywhere Sensor is running. It also gives you the chance towatch the sensor actively working to find all of your assets and to record events from the start.

Note: Make sure to verify that the Sensor is running before performing configuration. You cankeep one web browser tab with theWELCOME TOUSMANYWHERE page in thebackground while you perform the verification on a different tab.

To verify the new USM Anywhere Sensor

1. In USMAnywhere, select SETTINGS > SENSORS.

You should now see your Sensor in the page.

After a few minutes, USMAnywhere locates your assets and starts registering events.

2. You can review the activity in two locations.

l From the primary task bar, select ENVIRONMENT > ASSETS.

l From the primary task bar, select ACTIVITY > EVENTS.

Note: It could take up to sixminutes before events appear. Make sure to refresh yourbrowser from time to time to display the current data.



This example shows the detected assets that USMAnywheremight discover from an assetscan.

For more information about using the Assets and Events pages in USMAnywhere, see theUSMAnywhere User Guide.

Completing the AWS Sensor Setup


After you initialize a new USMAnywhere Sensor, youmust configure it using the SetupWizard. Asyou configure the AWS sensor, USMAnywhere performs specific actions, like running an assetdiscovery scan or collecting security events from a predefined cloud storage location.

About Accessing the SetupWizard






Configuring the Sensor in the SetupWizard


The AMAZON WEB SERVICES CONFIGURATION page provides information about the assetdiscovery that occurs upon the initial deployment of the USMAnywhere Sensor, summarizing thenumber of instances, instance types, and regions in your environment.

Click Next to proceed with the SetupWizard and complete additional configuration on each page.



AWS LOG COLLECTION

USMAnywhere automatically discovers a number of out-of-box logs as long as you have enabledthemwithin your AWS subscription. For more information about these logs and how they functionwithin the AWS environment, see AWS LogDiscovery and Collection in USMAnywhere.

1. Enable the AWS S3 and CloudWatch out-of-box log collection jobs.

Locate the jobs you want to enable and click the disabled icon ( ). This turns the icon

green ( ).

Note: You can also enable CloudTrail, ELB Access, and other security logs. However,make sure you've enabled these first on your AWS account.

2. Click Next.

LOG MANAGEMENT





THREAT INTELLIGENCE












SETUP COMPLETE



Next...




Enabling syslog Connections in an AWS VPC

A USMAnywhere Sensor deployed in AWS to a virtual private cloud (VPC) automatically listens forsyslog packets on UDP port 514, but youmust enable access to it. This allows the other hosts in yournetwork to send data to the sensor. You enable this access by opening this port using the AWSSecurity groups that were created by the CloudFormation template that you used to deploy thesensor.

The AWSSecurity Groups

There are three AWS Security Groups that help control network connectivity between the instances:

l USMConnectionSG — Accepts incoming HTTP, HTTPS, and SSH connections from the CIDRblock you specified when you completed the CloudFormation template parameters.

These connections are only required to enable remote sensor management, and to connect tothe webUI during deployment and setup.

l USMServicesSG — Accepts incoming UDP connections on port 514 from any VM instance inthe USMBaseSG.

l USMBaseSG — Does not have inbound nor outbound rules, nor is it assigned to the sensor.

It exists solely as a convenience, so that you can assign it to VMs for connection to UDP over port514 on the sensor as specified in the USMServicesSG.

UDP Port 514

You can open UDP port 514 to receive syslog packet transmissions from the AWS console usingany one of the followingmethods:

l Assign the USMBaseSG Security Group to the selected VMs by navigating to Networking >Change Security Groups action. (You can also do this through the AWS CLI.)

l Add the default Security Group from your VPC to the USMServicesSG. This allows all the VMsin that Security Group to send to port 514 UDP.

l Put the AWS sensor in the default Security Group from your VPC. This gives all of the VMs in thelocal VPC full access to all ports on the sensor.

Enabling syslog Connections in an AWS VPC


Adding Another Sensor to Other AWS Accounts


After you set up your initial sensor and USMAnywhere service, you can generate the license keyfromwithin USMAnywhere for any new sensor you intend to add for other AWS accounts.

Note: The number of sensors that you can add to your environment depends on your USMAnywhere licensing. You can go to SETTINGS > MY SUBSCRIPTION to view the number oflicensed sensors.

To add an additional USM Anywhere Sensor to AWS


2. Click NEW SENSOR.

The dialog displays an authentication code for the new sensor.

3. Click the Copy icon ( ) to copy the code to your clipboard.

You should paste this code to another location for use later and keep USMAnywhere open inthe background.

4. Create the sensor stack in your AWS account, as described in Deploying the AWS Sensor.

5. Use the URL/public IP to access the USMAnywhere sensor registration, as described in Settingthe AWS Sensor Connection to USMAnywhere.



6. When you get to theWELCOME TO USM ANYWHERE SENSOR SETUP! page, it promptsyou to provide the information for registering the additional sensor with your USMAnywhereinstance.

l Enter a Sensor Name and Sensor Description.

l Paste the sensor authentication code you copied into the field with the Key icon ( ).

l Copy the URL of your existing USMAnywhere instance and paste it into the field with theComputer icon ( ).

For example, if the subdomain with which you registered with AlienVault was "example123,"the URLwould be example123.alienvault.cloud.

l Click Start Setup.

A progress screen displays a statusmessage.



Connecting USM Anywhere Sensor

When the connection is complete, aWelcome page appears.

7. Click the link to open the USMAnywhere webUI.

Upon login, this displays the USMANYWHERE SENSOR CONFIGURATION page with theconnected sensor listed in the page.

8. Click Configure to complete the sensor setup.

If you do not want to complete the sensor setup immediately, you can click Start Using USMAnywhere at the bottom of the page. However, youmust complete the sensor setup before youcan use it.

Note: Although you can wait to configure the new sensor at amore convenient time, westrongly recommend that you do so now.

AWS Log Discovery and Collection in USM Anywhere

With a deployed AWS sensor, USMAnywhere automatically discovers a number of out-of-boxAWS logswhen you have enabled themwithin your AWS subscription.

You can enable or disable log collection for these logs from the AWS sensor SetupWizard (seeAWS LOG COLLECTION) or within the USMAnywhere Scheduler (see Enabling Standard LogCollection and Scan Jobs ).

AWS LogDiscovery and Collection in USMAnywhere


CloudTrail Logs

AWS CloudTrail provides a complete audit log for all actions taken with the Amazon API, eitherthrough the web interface, the CLI, or an SDK. Ongoingmonitoring of this log gives you visibility ofend-user and automated actions in your environment. This helps you quickly detect abuse cases andsecurity incidents, such as a user trying tomake changes inconsistent with their privileges to anAWS account.

USMAnywhere automatically detects AWS CloudTrail, and retrieves your CloudTrail logs across allregions by default. USMAnywhere also provides you the credentials to access your CloudTrail logssecurely.

Note: If you choose not to enable AWS CloudTrail, USMAnywhere processes all stored logsat initial start up.

For information about enabling AWS CloudTrail, see the Amazon documentation.

Elastic Load Balancing Logs

The USMAnywhere Sensor automatically detects AWS Elastic Load Balancing (ELB) logs afteryou've enabled them in AWS.

Unlike other AWS log collection jobs, you never schedule a new ELB job. After USMAnywhereexamines your ELB logs, it creates jobs according to the logging configuration. After you enablethese logs in USMAnywhere, it analyzes them and displays events.

Elastic Load Balancing supports two types of load balancers:

l Application Load Balancer

An Application Load Balancer functions at the application layer, serving as a single point ofcontact for clients. This increases the availability of an application. The Application Load BalancerAccess Logs provide insight into who is accessing your applications. They also help you identifycommon abuse patterns and use of automated hacking tools, such asweb application scanners.

To learn how to enable Application Load Balancer logging in AWS, see the Amazondocumentation.

l Classic Load Balancer

AWS Classic Load Balancer (formerly Elastic Load Balancer) logs provide an easy, yet effectiveway tomonitor HTTP traffic for threats. The AWS Classic Load Balancer Access Logs provideinsight into who is accessing your web resources. They also help you identify common abusepatterns and use of automated hacking tools, such asweb application scanners.

To learn how to enable Classic Load Balancer logging in AWS, see the Amazon documentation.

Important: Youmust enable Classic Load Balancer logs for every ELB that you want tomonitor.



http://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html#enable-access-logging

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-access-logs.html

CloudWatch Logs

AWS CloudWatchmonitors applications, such asCloudTrail, and systems using log data,aggregating and storing application logs. This utility lets you transport log files from your running S3Access Log instances to a place where USMAnywhere can access themwithout your having tochange any network access settings.

CloudWatch Logs are useful, because you can easily configure them to process additionalmetadatawith the log files. They alsomakemoving log files around EC2 easy.

Important: CloudWatch streams should be separated from each other by plugin type.

AWS S3 and CloudWatch locations can automatically generate events based on CloudTrail, S3,ELB Access, and other security logs.

Follow the appropriate procedures for your operating system to configure the CloudWatch LogsAgent to use the EC2Config service:

l MS Windows — http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/send_logs_to_cwl.html

l Linux — http://-docs.aws.amazon.com/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html

Make sure to keep the log types the samewithin a given log group. The scheduled CloudWatch taskin USMAnywhere assumes that all streamswithin a given group should be parsed using the sameplugin:

l IIS-Logs — "IIS Logs" plugin

l Apache-Access-Logs — "Apache" plugin

l Linux-Audit-Logs — "Linux Auditd" plugin

l Linux-Auth-Logs — "Linux SUDO" plugin

l OSQuery-Logs — "Osquery" plugin

l Windows-System-Logs — "AWSWindows" plugin

Important: When setting up CloudWatch, you should configure the system logs to go to anAWS LogGroup calledWindows-System-Logs (shown as boldface in the preceding list).

This is because it already exists as a scheduled task in the AWS LOG COLLECTION page ofthe sensor setup wizard and the USMAnywhere Scheduler. USMAnywhere finds andprocesses the logs automatically with the AWSWindows plugin.



http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/send_logs_to_cwl.html

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/send_logs_to_cwl.html

http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html


https://www.alienvault.com/documentation/Default.htm#cshid=1004

S3 Access Logs

Amazon Simple Storage Service (Amazon S3) is object storage with a simple web service interfacethat you can use to store and retrieve any amount of data from anywhere on the web. Organizationsrunning an AWS environment typically use it as the primary storage for their cloud-nativeapplications, as a bulk repository, as a target for backup and recovery, and as a log-term archivelocation.

Amazon S3 has the ability to provide complete access logs for all actions taken in an S3 bucket.When you enable this capability, it gives you insight into who is accessing the data, and what actionsare being taken.

To learn how to enable S3 Access Logging, see Amazon's documentation.

Note: In AWS, youmust enable S3 Access Logging in every S3 bucket that you want tomonitor.

Moving Logs from an EC2 Instance to an S3 Bucket

In Amazon EC2, it can be difficult to create direct network connections between isolated parts ofyour environment. Amazon S3 provides a convenient way tomove application logs from an EC2instance to an S3 bucket. Buckets are used to store objects, which consist of data andmetadata thatdescribes the data. You then configure the USMAnywhere Sensor to retrieve and process the logfiles.

You'll want to synchronize logs from your instance with an Amazon S3 bucket. There aremultipleways to do this. The easiest method is to use the AWS CLI documented by Amazon. You thencreate a script similar to the following example and configure it to run periodically as a cron job.

aws s3 sync "<path_to_log>" "S3://<bucket_name>/<storage_path>/"

For detailed information about creating S3 Access collection jobs in USMAnywhere, see Creating aNew AWS S3AccessCollection Job.

Creating a New CloudWatch Collection Job

R o l e Ava i l a bi l i ty R ead-Onl y Ana l ys t Manager

TheCloudWatch utility lets you transport log files from your running S3 Access Log instances to aplace where USMAnywhere can access themwithout your having to change any network accesssettings. CloudWatch Logs are useful, because you can easily configure them to process additionalmetadata with the log files. They alsomake it easy tomove log files around EC2.

If you want USMAnywhere to run a log collection job with your own parameters, use this procedureto create a new collection job.

Note: Before you create a new CloudWatch log collection job, youmust have CloudWatchenabled in your AWS environment. For more information, see CloudWatch Logs.



http://docs.aws.amazon.com/AmazonS3/latest/dev/enable-logging-console.html

http://aws.amazon.com/cli/

To create new CloudWatch log collection job

1. Go to SETTINGS > SCHEDULER.

2. In the left navigation list, click Log Collection.

3. Click Create Log Collection Job.

Note: If you recently deployed a new sensor, it can take 10 to 20minutes for USMAnywhere to discover the various log sources. After it discovers the logs, youmustmanually enable the AWS log collection jobs you want before the system collects the logdata.

4. Enter the Name and Description for the job.

The description is optional, but it is a best practice to provide this information so that others caneasily understand what it does.

5. In the Select App option, select Amazon Web Services.

6. In the App Action option, select Monitor CloudWatch.



7. Enter the Region Name, Group Name, and Stream Name information for your AWS account.

8. In Source Format, select either of the following log formats:

l syslog — Standard format for transmitting log data to USMAnywhere

l raw — Not applicable

USMAnywhere transfers CloudWatch log data to an S3 bucket automatically. If you haveraw data that you have collected using another tool, you can either select raw here or use anS3 Log Collection job for this purpose instead.



Note: CloudWatch streams should be separated from each other by plugin type.

9. (Raw source only) From the Plugin Name list, select the plugin that corresponds to the incom-ing data.

10. Set the Schedule to specify when USMAnywhere runs the job.

First, choose the increment asHour, Day,Week, Month, or Year. Next, set the interval optionsfor the increment. The selected increment determines the available options.

For example, on a weekly increment you can select the days of the week to run the job.



Or, on amonthly increment you can specify a date or a day of the week that occurs within themonth.

To finish, set the Start time. This is the time that the job starts at the specified interval. It uses thetime zone configured for your USMAnywhere instance (default is UTC).

11. Click Save.

Creating a New AWS S3 Access Collection Job


Before you can create a new AWS S3Access collection job, youmust have previously enabled S3Access Logging in your AWS environment. For more information about these logs, see S3 AccessLogs.

Note: In AWS, youmust enable S3 Access Logging in every S3 bucket that you want tomonitor.

To create a new S3 Access Collection Job




Creating a New AWS S3AccessCollection Job





5. In the Select App option, select Amazon Web Services.

6. In the App Action option, select Monitor S3 Bucket.



7. Enter the Bucket Name and Path.

The bucket name is simply the name of the S3 bucket as configured in your AWS account, suchas DevBucket.

The path is the path prefix within the S3 Bucket, such as AWSLOGS/3987783. This does notinclude the bucket name.

8. In Source Format, select either of the following log formats:

l syslog — Standard format for transmitting log data to USMAnywhere

l raw — Not applicable



9. (Raw source only) From the Plugin Name list, select the plugin that corresponds to the incom-ing data.








11. Click Save.

12. In the AWS console, restart the AWS sensor instance so that it detects the new configuration.



USMAnywhere Sensor DeploymentonMicrosoft Azure

TheUSMAnywhere Sensor provides operational visibility into the security of your Azureenvironment. Based on the collected log information, USMAnywhere analyzes the data generatedby your Azure environment and provides real-time alerting to identifymalicious activity. The Azuresensor is deployed into your environment to provide ultimate control over the installation and thedata contained within it, and also to avoid any external access to the environment.

This topic discusses the following subtopics:

About Azure Sensor Deployment 94

Requirements for USMAnywhere Sensor Deployment on Azure 96

Deploying the USMAnywhere Sensor from the AzureMarketplace 97

Setting the Azure Sensor Connection to USMAnywhere 103

Completing the Azure Sensor Setup 106

Creating an Application andObtaining Azure Credentials 120

Adding Another Sensor for Other Azure Subscriptions 122

Azure Log Discovery and Collection in USMAnywhere 125


About Azure Sensor Deployment

Through Azure, you can deploy a USMAnywhere Sensor in any of the virtual networks that youwant to instrument for network intrusion detection (NIDS). All USMAnywhere Sensors allow forauthenticated scans of assets by leveraging stored credentials that you define in USMAnywhere.This allowsUSMAnywhere to detect potential vulnerabilities, installed software packages, andrunning processes and services.

In addition to these standard sensor functions, the Azure sensor also provides capabilities thatleverage the Azure environment:

l Automatic discovery of VMs running in your Azure environment

l Optionalmonitoring of Azure Logs

Log Collection and Scans

USMAnywhere automatically discovers your use of the following logswithout the need forenablement on the Azure subscription side, as long as the Azure resource subscription hascontributor-level permissions:

l Azure RESTMonitor (formerly Azure Insight) logs

l Azure Security Alerts

l AzureWeb App logs

l Azure SQL Server logs

Note: USMAnywhere collects SQL Server logs stored as tables only. It does not collectSQL Server logs stored as Binary LargeOBjects (BLOB)s.

Microsoft Azure has recently deprecated table storage and recommends that users selectthe BLOB storage option. However, youmust use the Azure Tables storage option foryour SQL Server logs tomake them available for collection by the USMAnywhereSensor.

l Azure IIS logs

l AzureWindows logs

l Asset scans on your VMs to inventory installed software packages, running processes, and ser-vices



Log Analysis

USMAnywhere analyzes these logs in these stages:

1. Collects logs from systems and software running in your environment

2. Configures log line processing and generates events

l Includes IP addresses and timestamps culled from extracted log line data

l Adds other data to the event, such as security context and environmental information

3. Analyzes events and stores them

Deployment Overview

AlienVault distributes the Azure sensor through the AzureMarketplace as a D2 Standard or DS2PremiumVM template.

Note: If your organization usesmultiple subnets to allow communication betweenheadquarters and remote offices, we recommend that you deploy a sensor to each.Alternatively, you can deploy a USMAnywhere Sensor in a single virtual network. When youdeploy a sensor to a single virtual network in your Azure subscription, you'll see Azure logs forthe entire subscription.

The deployment process for an initial USMAnywhere Sensor in your Azure environment consists ofthese primary tasks:

1. Review requirements for an Azure sensor deployment

2. Deploy the USMAnywhere Sensor within your Azure environment

3. Register the deployed sensor with your Sensor Authentication Code to provision the USMAny-where instance and connect the deployed sensor

4. (Optional) Manually create a new application and credentials in the Azure console

5. Complete your Azure sensor configuration, including initial asset discovery



Requirements for USM Anywhere Sensor Deployment on Azure

To ensure that you can successfully deploy USMAnywhere in your Azure subscription andmonitorall of your Azure resources, make sure you have the following available in your Azure environment:

l An Azure account with privileges in the resource group or subscriptions in which you wantto install the USM Anywhere Sensor

Note: You can deploy a single USMAnywhere Sensor to monitor all of your Azureresource groups. To do this, youmust assign the application you create to the entiresubscription.

l Administrative access to Active Directory within Azure

This allows you to create an application required to install resource groups or a subscription formonitoring.

l A virtual network inside the resource group

l A subnet inside the virtual network

l A storage account






HTTPS /TCP

80 and443





HTTPS /TCP


Requirements for USMAnywhere Sensor Deployment on Azure





Deploying the USM Anywhere Sensor from the Azure Marketplace

After you review the requirements andmake sure that your Azure environment is configured asneeded, you can deploy the Azure sensor. Using the virtual machine (VM) template provided byAlienVault and distributed through the AzureMarketplace, you can automatically deploy the USMAnywhere Sensor within your environment.

To deploy a USM Anywhere Sensor in Azure

1. Go to https://www.alienvault.com/products/usm-anywhere/sensor-downloads and click theSensor Download arrow next to Azure.

This launches theMicrosoft Azure Login page.

2. Provide your Azure account credentials (username and password) and click Sign in.

3. On the USMAnywhere License page, review the details of the license and click Create.

This takes you to the Create Virtual Machine Basics page, which guides you through the stepsfor deploying the USMAnywhere Sensor VM.

Deploying the USMAnywhere Sensor from the AzureMarketplace



4. Specify the Basics for the virtual machine:

l Name — Enter the name you want to use for the USMAnywhere Sensor virtual machine.

l VM disk type — Select the disk type, HDD or SSD.

l User name — Enter the SSH username.

For access to the USMAnywhere CLI or anything that will require root access, thismust besysadmin.

l Authentication type — Set this option to specify an SSH Public key or a password for SSHaccess.

l Subscription — Select the subscription into which USMAnywhere Sensor should beinstalled.

l Resource Group — Indicate whether you want to install the USMAnywhere Sensor into anexisting resource group or into a new resource group. If new, enter a unique name.

l Location — If you are using a new resource group, indicate the region for the USMAnywhereSensor. Otherwise, leave this as the default.



5. ClickOK.

6. In the Choose a Size blade, select the instance size of your virtual machine.

AlienVault recommends the following instance sizes:

l HDD instances — D2 standard

l SSD instances — DS2 standard



7. Click Select.

8. In the Settings blade, define the storage and network preferences:

l Storage Account — Set the storage account that the USMAnywhere Sensor should use.

o If you select HDD as the disk type, this requests a new standard storage account bydefault.

o If you select SSD as the disk type, this requests a new premium storage account bydefault.

l Network — Set the network where the USMAnywhere Sensor VM should be installed.

Important: Make sure you install the USMAnywhere Sensor in the network where theassets that you want to monitor are located.

l Extensions — Leave blank.

l High availability — Leave blank.

l Monitoring — Leave this disabled unless you want to store USMAnywhere Sensor logs formonitoring purposes.



9. ClickOK.

10. On the Summary blade, review your specifications and the cost summary.



11. Click Create.

This starts the deployment of the USMAnywhere Sensor, which can take up to sixminutes.

12. After deployment finishes, locate the Public IP address for the virtual machine by reviewing thevirtual machine overview.

This IP address is required to complete the next task of the Azure sensor deployment.



Setting the Azure Sensor Connection to USM Anywhere

After obtaining the IP address used to connect to USMAnywhere, youmust provision your USMAnywhere instance within the AlienVault Secure Cloud. This IP address is available in the Azureconsole after you create and start the USMAnywhere Sensor virtual machine.

For the first deployed sensor, registration provisions the USMAnywhere instance and gives youaccess to the sensor through the USMAnywhere web interface, where you complete the sensorsetup. You perform this procedure after deploying the USMAnywhere Sensor within your Azuresubscription.










Setting the Azure Sensor Connection to USMAnywhere



Verify That the USM Anywhere Sensor Is Running

It's a good idea to verify that the USMAnywhere Sensor is running. It also gives you the chance towatch the sensor actively working to find all of your assets and to record events from the start.

Note: Make sure to verify that the Sensor is running before performing configuration. You cankeep one web browser tab with theWELCOME TOUSMANYWHERE page in thebackground while you perform the verification on a different tab.

To verify the new USM Anywhere Sensor


You should now see your Sensor in the page.

After a few minutes, USMAnywhere locates your assets and starts registering events.

2. You can review the activity in two locations.

l From the primary task bar, select ENVIRONMENT > ASSETS.

l From the primary task bar, select ACTIVITY > EVENTS.

Note: It could take up to sixminutes before events appear. Make sure to refresh yourbrowser from time to time to display the current data.



This example shows the detected assets that USMAnywheremight discover from an assetscan.

For more information about using the Assets and Events pages in USMAnywhere, see theUSMAnywhere User Guide.

Completing the Azure Sensor Setup


After you initialize a new USMAnywhere Sensor, youmust configure it in the SetupWizard. As partof configuration, you can enable scheduled jobs for sensor apps to perform specific actions, such asrunning an asset discovery scan or collecting security events from a predefined cloud storagelocation.







Configuring the Azure Sensor in the SetupWizard


AZURE CREDENTIALS

To complete the Azure sensor configuration, youmust obtain Azure API credentials for thesubscription that you want USMAnywhere tomonitor. Select the option on theAZURE CREDENTIALS page that matches your current Azure credential creation status:

l If you already generated your Azure credentials, click Yes, I have my Azure credentials andam ready to enter them.

l If you don't yet have your Azure credentials, click No, I don't have my Azure credentials andneed to create them.

l If you're not sure, click I am not sure. Show me how to create my Azure credentials.



If you select No or I am not sure, the page provides options for two creationmethods:

If you select Yes, follow the steps in Configuring the Azure Credentials After Manual CredentialGeneration.

Generating the Azure Credentials for Windows Users

This procedure is for Windows users who want to use the provided Powershell script toautomatically generate their credentials for sensor configuration.

1. Select Create credentials automatically using a Powershell script (Recommended).

The page automatically launches a download of the Powershell script. You can use the browsertools to save the file to the appropriate location on your system.



2. Run the script as administrator on your Windows operating system.

Note: If you havemultiple Azure subscriptions, the script prompts you to identify which oneyou want USMAnywhere tomonitor.

When the script finishes it creates a text file that saves to your Desktop.

3. In USMAnywhere, drop the Azure credentials text file onto the displayed page or click theselect USM_Anywhere_Azure_Credentials.txt from your desktop link to locate, select, andupload the file.



4. Verify that the status at the top of the page displays the followingmessage:

Valid Credentials

Creating the Azure Credentials Manually

1. Select Learn how to create Azure credentials manually.

This opens the Creating an Application andObtaining Azure Credentials page in a new browsertab or window.

2. Follow the instructions for creating the needed credentials.

3. Return to USMAnywhere, then click the Back button to display the first AZURECREDENTIALS page.

Configuring the Azure Credentials After Manual Credential Generation

This procedure is for non-Windows users who generated their Azure credentialsmanually and whoare ready to configure the sensor.

1. Select the Yes option, and in the next page click the Enter previously created Azure cre-dentials manually link at the bottom of the page.

2. Enter the Azure API credentials you generated in the Azure console into the appropriate fields.




4. Verify that the status at the top of the page displays themessage:

Valid Credentials

When the credentials are configured, click Next.

The wizard displays the next page in the setup process, AZURE CONFIGURATION.



AZURE CONFIGURATION

After you've successfully configured the Azure credential, the AZURE CONFIGURATION pageappears. This page summarizes the number of Azure virtual machines (VMs), resource groups, andVM sizes in your environment.

Click Next.

The wizard displays the next page in the setup process, AZURE LOG COLLECTION.

AZURE LOG COLLECTION

The AZURE LOG COLLECTION page displays the following Azure logs that are automaticallydiscovered byUSMAnywhere in your environment:

l Azure RESTMonitor (formerly Azure Insight)

l Azure Security Alerts

l Azure SQL Server logs

l Azure IIS logs

l AzureWindows logs



Important: USMAnywhere collects SQL Server logs stored as tables only. It does not collectSQL Server logs stored as Binary LargeOBjects (BLOB)s.

Microsoft Azure has recently deprecated table storage and recommends that users select theBLOB storage option. However, youmust use the Azure Tables storage option for yourSQL Server logs tomake them available for collection by the USMAnywhere Sensor.

For more information about Azure log discovery and collection, see Azure Log Discovery andCollection in USMAnywhere.

To enable these out-of-box Azure log collection jobs, toggle the gray ENABLE icon so that it turnsinto a green checkmark. When you enable any of these log collection jobs, USMAnywhere startscollecting the log data immediately according to the preconfigured frequency. If you want to addother Azure log collection jobs after the sensor configuration, including jobs for AzureWeb Apps,see Creating a New Azure Log Collection Job.

Note: If you go to ACTIVITY > EVENTS in USMAnywhere post-configuration, you can see allof the events associated with each log type, including its Event ID andmany other usefuldetails. You can also review related log collection jobs in the JOB SCHEDULER (SETTINGS> SCHEDULER).

After you enable each job that you want, click Next.


ACTIVE DIRECTORY

The optional ACTIVE DIRECTORY setup page configuresUSMAnywhere to collect informationfrom your Azure Active Directory (AD) account. Tomonitor Windows systems effectively, USMAnywhere needs access to AD (Active Directory) server to collect inventory information.

AlienVault recommends that you create a dedicated AD account with membership in the DomainAdmins group to be used byUSMAnywhere to log in into theWindows systems. You also need toactivateWinRM in the Domain Controller and in all the hosts that you want to scan. You can do this



by using a group policy for all the systems in your Active Directory.

Important: Before this feature is fully functional, youmust allow access to the USMAnywhereSensor in the Active Directory server. For more information see, Granting Access to ActiveDirectory for USMAnywhere.

To complete the AD access configuration

1. Provide the AD credentials for USMAnywhere:

l Active Directory IP Address — Enter the IP address for the AD instance.

l Username — Enter your username as administrator of the account.

l Password — Enter your administrator's password.

l Domain — Enter the domain for the AD instance.

2. Click Scan Active Directory.

After a successful launch of the scan, a confirmation dialog appears.



3. Click Accept.

The scan continues in the background.

Upon completion, another dialog appears and provides information about the number of assetsUSMAnywhere discovered. It also prompts you to decide if you want to scan for hosts andservices running in your environment.

Click CANCEL to opt out of this scan.

4. (Optional) If you want to scan for other hosts and services, clickOK.

5. Click Next after the scan ends.

The wizard displays the next page in the setup process, LOG MANAGEMENT.

LOG MANAGEMENT





THREAT INTELLIGENCE












SETUP COMPLETE



Next...




Creating an Application and Obtaining Azure Credentials

To enable USMAnywhere tomonitor your Azure subscription, youmust create an application thatgrants permission to USMAnywhere to fetch data using the Azure SDK and Azure REST API. USMAnywhere requires the following credentials:

Azure Credential USM Anywhere Field Name

azure_tenant_id Azure Tenant ID

azure_subscription_id Azure Subscription ID

azure_application_id Azure Application ID

azure_application_key Azure Application Key

If you're a Windows OS user, you can do this in one of two ways:

l Using a Powershell script, which is available through the USMAnywhere Setup wizard.

l Manually, within your Azure subscription.

If you're not a Windows OS user, youmust generate thesemanually from your Azure subscription.

Important: Youmust have global administrator privileges to create an application and obtaincredentials.

Obtaining the Azure Subscription ID

The subscription ID is required when you complete the Azure Credentials step of the sensor setup inUSMAnywhere.

To get the Azure subscription ID

1. Log into theMicrosoft Azure console (https://portal.azure.com).

2. From the Azure Dashboard, select your subscription.

3. From the Subscription page, copy your Subscription ID and save it somewhere that you canaccess later.

Creating the Application

To allow USMAnywhere to access Azure resources, youmust set up an Azure Active Directory

Creating an Application andObtaining Azure Credentials


https://portal.azure.com/

(AD) application and assign the required permissions to it. To create the application and obtain theremaining Azure credentials (tenant ID, application ID, and application key), youmust complete theMicrosoft Azure standard procedure for adding a new application registration.

As you add and configure the new application, copy the tenant ID, application ID, and applicationkey. This information is required when you complete the Azure Credentials step of the sensor setupin USMAnywhere.

Associating the Application with the Entire Subscription

If you want to use USMAnywhere tomonitor all of your Azure resources, you should associate itwith your Microsoft Azure subscription as a whole.

To associate the application with the entire subscription

1. Log into the new Microsoft Azure portal (https://portal.azure.com).

2. Go toMore Services > Subscriptions, locate the subscription, and select it.

3. Select Access control (IAM) in the navigation list.

This reveals a new blade that displays the roles and permissions that exist for the subscription.

Creating an Application andObtaining Azure Credentials


https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal#check-azure-subscription-permissions


4. At the top of the blade, click Add.

5. Select the Contributor role.

This role allows assigned users to fetch new Azure logs.

6. Select the Service principal you created previously to assign the role to the subscription.

7. Click Save andOK.

The system respondswith the followingmessage:

Added user. <User_names> were added as Contributor for <name-of-your-subscription>.

Adding Another Sensor for Other Azure Subscriptions


After you set up your initial USMAnywhere Sensor in your Azure environment, you can generate thelicense key for any new sensor you intend to add for other Azure subscriptions fromwithin the USMAnywhere webUI.

Note: The number of sensors that you can add to your environment depends on your USMAnywhere licensing. You can go to SETTINGS > MY SUBSCRIPTION to view the number oflicensed sensors.



To add an additional USM Anywhere Sensor for Azure


2. Click NEW SENSOR.

The dialog displays an authentication code for the new sensor.

3. Click the Copy icon ( ) to copy the code to your clipboard.

You should paste this code to another location for use later and keep USMAnywhere open inthe background.

4. Create the sensor VM in your Azure subscription, as described in Deploying the USMAnywhereSensor from the AzureMarketplace.

5. Use the URL/public IP to access the USMAnywhere sensor registration, as described in Settingthe Azure Sensor Connection to USMAnywhere.

6. When you get to theWELCOME TO USM ANYWHERE SENSOR SETUP! page, it promptsyou to provide the information for registering the additional sensor with your USMAnywhereinstance.

l Enter a Sensor Name and Sensor Description.

l Paste the sensor authentication code you copied into the field with the Key icon ( ).

l Copy the URL of your existing USMAnywhere instance and paste it into the field with theComputer icon ( ).

For example, if the subdomain with which you registered with AlienVault was "example123,"the URLwould be example123.alienvault.cloud.



l Click Start Setup.

A progress screen displays a statusmessage.

Connecting USM Anywhere Sensor

When the connection is complete, aWelcome page appears.

7. Click the link to open the USMAnywhere webUI.

Upon login, this displays the USMANYWHERE SENSOR CONFIGURATION page with theconnected sensor listed in the page.



8. Click Configure to complete the sensor setup.

If you do not want to complete the sensor setup immediately, you can click Start Using USMAnywhere at the bottom of the page. However, youmust complete the sensor setup before youcan use it.

Note: Although you can wait to configure the new sensor at amore convenient time, westrongly recommend that you do so now.

Azure Log Discovery and Collection in USM Anywhere

When you use Azure Diagnostic logs tomonitor your deployed assets, includingWindows hosts, IIS,and the Azure SQLDatabase service, USMAnywhere automatically discovers and enablescollection of these logs through Azure APIs. A USMAnywhere Sensor deployed in your Azureenvironment is preconfigured to automatically discover Azure Storage Tables and BLOBscontaining these types of diagnostic logs. You can enable or disable the default log collection jobsfrom the Azure sensor SetupWizard (see AZURE LOG COLLECTION) or within the USMAnywhere Scheduler (see Enabling Standard Log Collection and Scan Jobs ).

To supplement the default log collection jobs and to add log collection for AzureWeb Apps, you canalso create custom log collection jobs that operate through the Azure sensor app.

Note: What an Azure log job collects depends on whether you granted contributor permissionsto one of your resources or to your entire Azure subscription for the USMAnywhereapplication. Depending on the Azure Credentials configured for the deployed Azure sensor,the sensor could have access to individual resource groups or the whole subscription. Formore details, see Creating an Application andObtaining Azure Credentials.

Azure Log Discovery and Collection in USMAnywhere


Azure Monitor (Insight)

AzureMonitor (formerly Azure Insights) provides base level infrastructuremetrics and logs for mostservices in Microsoft Azure. It helps you to track user activities within an Azure subscription,including when users log on, deploy, or shut down VMs, andmore. Through the AzureMonitorREST API, USMAnywhere captures those logs and creates events.

You do not need to perform a specific configuration of AzureMonitor in the Azure console for USMAnywhere to collect these logs. USMAnywhere automatically detects these logs and creates a jobfor AzureMonitor logs. When you complete the Log Collection step for your Azure sensor setup, youcan enable this default job, which runs every 20minutes.

You can also enable or disable this default job in the Job Scheduler. When you select the job in thispage, you can review the history for the scheduled job.

Azure Security Alerts

Azure Security Center is an Azure service that continuouslymonitors your Azure environment andapplies analytics to automatically detect a wide range of potentiallymalicious activity. It surfacesthese detections as security alerts. Security Center performs this function by collecting data fromyour virtual machines, which is enabled for all virtual machines in your subscription by default. Youcan also customize this data collection in the Security Center policy.

You do not need to perform a specific configuration of the Azure Security Alerts in the Azure consoleto be able to collect these logs. USMAnywhere automatically detects these logs and creates a jobfor Azure Security Alerts logs. When you complete the Log Collection step for your Azure sensorsetup, you can enable this default job, which runs every 20minutes.

You can also enable or disable this default job in the Job Scheduler. When you select the job in thispage, you can review the history for the scheduled job.



Azure IIS Logs

For individual VMs running IIS with Azure diagnostics enabled, you can designate storage for the IISlogs. USMAnywhere automatically detects these logs through the Azure APIs and Azure SDKs. Foreach Azure Storage Container locationswith Azure IIS Logs that it detects, USMAnywhere createsa default log collection job.When you complete the Log Collection step for your Azure sensor setup,you can enable these default jobs, which run every fiveminutes.

Note: This type of IIS implementation is different than AzureWeb Apps, which is a platformservice and uses a different logging configuration. For information about collecting logs for webapps, see AzureWeb Apps Logs.

You can also enable or disable this default job in the Job Scheduler. When you select the job in thispage, you can review the history for the scheduled job. You could choose to disable this default jobbased on the IIS log locations that USMAnywhere discovers and create a customAzure IIS logcollection job for a location that you specify.



When you configure the new job, set the App Action option to Process Azure IIS Logs. Youmustalso specify the Resource Group, Storage Account, and Blob Container for the custom logcollection job. For more information about scheduling an Azure log collection job, see Creating aNew Azure Log Collection Job.

Azure SQL Server Logs

For individual VMs running SQL Server with Azure diagnostics enabled, you can designate storagefor the IIS logs. Youmust configure this to use Azure Table Storage. To simplify the tracking ofrelated security issues, USMAnywhere treats the SQL service as an asset, andmaps events andother security issues directly with the SQL service. When it detects Azure Storage Table locationswith Azure SQL Server Logs, USMAnywhere creates a default log collection job for each.Whenyou complete the Log Collection step for your Azure sensor setup, you can enable these defaultjobs, which run every fiveminutes.

Important: USMAnywhere collects SQL Server logs stored as tables only. It does not collectSQL Server logs stored as Binary LargeOBjects (BLOB)s.

Microsoft Azure has recently deprecated table storage and recommends that users select theBLOB storage option. However, youmust use the Azure Tables storage option for yourSQL Server logs tomake them available for collection by the USMAnywhere Sensor.



If you want to supplement this automatic Azure log collection in USMAnywhere, you can create anadditional Azure SQL Server log collection job.

When you configure the new job, set the App Action option to Process Azure SQL Server Logs.Youmust also specify the Resource Group, Storage Account, and Table Container for the customlog collection job. For more information about creating a new Azure log collection job, see Creating aNew Azure Log Collection Job.

Azure Web Apps Logs

Azure App ServiceWeb Apps is a fullymanaged compute platform that is optimized for hostingwebsites and web applications. A web app represents the compute resources that Azure providesfor hosting a website or web application and these compute resourcesmay be on shared ordedicated virtual machines (VMs). For each deployed web app in your Azure environment, you canenable diagnostic logging to capture and store the web server and application information.

Unlike the other supported Azure logs, the USMAnywhere Sensor does not perform an automaticdiscovery job for Web Apps to look for the storage location. If you want USMAnywhere to collect thelog data for your Web Apps, youmust create a new log job and specify the storage locationparameters.



When you configure the new job, set the App Action option to Process Azure Web Apps Logs. Youmust also specify the Resource Group, Storage Account, and Blob Container for the custom logcollection job. For more information about creating a new Azure log collection job, see Creating aNew Azure Log Collection Job.

Azure Windows Logs

For individual VMs runningWindowswith Azure diagnostics enabled, Azure stores theWindows Events logs by default. USMAnywhere automatically detects these logs through AzureAPIs and Azure SDKs.When it detects Azure Storage Container locationswith Azure WindowsLogs, USMAnywhere creates a default log collection job for each.When you complete the LogCollection step for your Azure sensor setup, you can enable these default jobs, which run every fiveminutes.

If you want to supplement this automatic Azure log collection in USMAnywhere, you can create anadditional AzureWindows log collection job.



When you configure the new job, set the App Action option to Process Azure Windows Logs. Youmust also specify the Resource Group, Storage Account, and Blob Container for the custom logcollection job. For more information about creating a new Azure log collection job, see Creating aNew Azure Log Collection Job.

Enabling Diagnostics for AzureWeb Apps

If you have AzureWeb Apps running in your Azure environment, you can enable diagnostics loggingfor these web apps in the Azure console and then create log collection jobs in USMAnywhere toretrieve and process the log data.

The Azure App Service web apps provide diagnostic functionality for logging information from boththe web server and the web application. It logically separates this into web server diagnostics andapplication diagnostics. When you enable this feature in Azure, you specify a log data storageaccount and container for each of these. For more information, see theMicrosoft Azuredocumentation at https://docs.microsoft.com/en-us/azure/app-service/web-sites-enable-diagnostic-log.



https://docs.microsoft.com/en-us/azure/app-service/web-sites-enable-diagnostic-log

https://docs.microsoft.com/en-us/azure/app-service/web-sites-enable-diagnostic-log

To enable diagnostics for your Azure web app

1. Log in to your account at https://portal.azure.com/.

2. Go to your AzureWeb App and select Settings > Diagnostics logs.

3. For Application Logging (Blob), clickOn and set the parameters.

l Set the Level for the logging.

l For Storage Settings, click > and select the Storage Account and Container.

This is the Storage Account and Container that Azure will use to store logs for theWeb App.Make note of this information because you will need it to set up a log collection job in USMAnywhere. You can click + Storage Account to create a new storage account or container,or select an existing one.

4. For Web server logging, select Storage.

5. Click Storage Settings and select the same storage account and container that you set for theapplication logging.

6. Click Save.




Creating a NewAzure Log Collection Job


USMAnywhere automatically creates log collection jobs for AzureMonitor and Security logs. It alsocreates jobs for IIS, SQL Server, andWindows if it detects storage locations for these log types.When you complete the Log Collection step for the Azure sensor, you can enable these default jobs.You can review these jobs and their history in the Scheduler, but you cannot modify the parametersof these default jobs.

Note: What an Azure log job collects depends on whether you granted contributor permissionsto one of your resources or to your entire Azure subscription for the USMAnywhereapplication. Depending on the Azure Credentials configured for the deployed Azure sensor,the sensor could have access to individual resource groups or the whole subscription. Formore details, see Creating an Application andObtaining Azure Credentials.

To supplement the automatic Azure log collection in USMAnywhere and to set up log collection forAzureWeb Apps, add new Azure log collection jobs.

To schedule a new job to collect and process Azure logs









5. In the Select App option, select Azure.

6. In the App Action option, select the action for Azure log type that you want to schedule forcollection.

To review details about the Azure log types that USMAnywhere can collect, see Azure LogDiscovery and Collection in USMAnywhere.

7. Depending on the selected app action (log type), specify the Resource Group, StorageAccount, and Container for the logs.

You can obtain this information by logging into the Azure console and reviewing theconfiguration for your diagnostic/storage resources.

Note: For Azure IIS Logs, AzureWeb Apps Logs, and AzureWindows Logs, youmustspecify a BLOB container used for the log storage. For the Azure SQL Server log type, youmust specify the table container used for the log storage.

USMAnywhere collects SQL Server logs stored as tables only. It does not collectSQL Server logs stored as Binary LargeOBjects (BLOB)s.

Microsoft Azure has recently deprecated table storage and recommends that users selectthe BLOB storage option. However, youmust use the Azure Tables storage option foryour SQL Server logs tomake them available for collection by the USMAnywhereSensor.








9. Click Save.



Device Port Mirroring Configuration

USMAnywhere supports use of a number of devices for the purpose of port mirroring.

By configuring amirror port in your device, you can clone all traffic to a single port. To do this, theswitch sends a copy of all network packets seen on one port (or an entire VLAN) to another port.USMAnywhere immediately starts receiving events from the device through the port and startsanalysis on them.

Note: Cisco switches support a feature known as SPAN (short for Switch Port Analyzer)which allows traffic received on an interface or VLAN to be sent to a single physical port.SPAN technically implies that the source and destination ports are local to the same switch. Ifthe traffic destination is on another remote switch, it usesRemote SPAN (RSPAN). If thedestination requires crossing one or more IP networks, some switches can use EncapsulatedRemote SPAN (ERSPAN).

USMAnywhere supports both SPAN and RSPAN. It does not support ERSPAN.

This section provides detailed information about port mirroring on a number of devices.


Configuring VMware ESX Virtual Switches for Port Monitoring

VMware ESX Virtual Switch terminology equates the termSPAN with port mirroring.

l Creating the vSwitch SPAN Port Group

l Granting PromiscuousMode Permissions to the Port Group

l Assigning USMAnywhere Interfaces to the Port Group

Creating the vSwitch SPANPort Group

To create the vSwitch SPAN port group

1. Open ESX vSphere GUI.

2. Click the Configuration tab.

3. Select Networking from the side panel, and then Properties.

4. Add a new Virtual Machines port group to the existing switch.

l Name the port group to indicate its visibility to all traffic (SPAN port)

l VLAN ID 'ALL (4095)' is a special ID in VMware vSwitch that has visibility to all traffic on theswitch



The SPAN port creates. Any VM interface connected to this SPAN port group is able to enterpromiscuousmode and capture traffic from any other VM interface connected to the other portgroups on this vSwitch.



Granting PromiscuousMode Permissions to the Port Group

To grant promiscuous mode permissions to the port group

1. Open ESX vSphere GUI.

2. Click Configuration tab.

3. Select Networking from the side panel, and then Properties.

4. Check the port group has permission for interfaces to enter promiscuousmode.



5. (Optional) If the defaults are to deny promiscuousmode, open the properties sheet (click Edit)for the SPAN port group andmanually assign permission for promiscuousmode.

Assigning USM Anywhere Interfaces to the Port Group

To assign USM Anywhere interfaces to the port group

1. Edit settings of the target virtual appliance.

2. Assign the network adapter to the created port mirroring groups (SPAN port), and use network



adapters 3, 4, 5, and 6 for port mirroring the AlienVault USMAnywhere appliance..

Note: Interfaces are pre-configured in the system.



Configuring a Hyper-V Virtual Machine for Port Mirroring on aWindows Server 2012+

The following procedureswork natively onWindowsServer 2012 R2Hyper-V Hosts. WindowsServer 2012 requires a hotfix.

Configuration for port mirroring consists of two tasks:

l Configuring the Virtual Machine to CaptureMirrored Traffic

l Configuring theMirror Port

Configuring the Virtual Machine to CaptureMirrored Traffic

To configure the virtual machine you want to use to capture mirrored traffic

1. Open the Hyper-V Manager and right-click themachine that you want to use to capturemirroredtraffic.

2. Select Settings.

3. Expand the associated network adapter and select Advanced Features.

4. Under the Port Mirroring section, select themirroringmode, then set it to Destination.

5. Click Apply andOK.

Configuring a Hyper-V Virtual Machine for Port Mirroring on aWindowsServer 2012+


https://support.microsoft.com/en-us/kb/2885541

Configuring theMirror Port

To configure the mirror port

1. Start aWindowsPowerShell console.

2. Enter:

$a = Get-VMSystemSwitchExtensionPortFeature -FeatureId 776e0ba7-94a1-41c8-8f28-951f524251b5

$a.SettingData.MonitorMode = 2

add-VMSwitchExtensionPortFeature -ExternalPort -SwitchName <virtual_switch_name> -VMSwitchExtensionFeature $a

Important: Be aware that, if you enable promiscuousmode in a physical port, it directs all thetraffic received on that port towards the virtual machine destination.

To learnmore about configuring port mirroring on a Hyper-V Virtual Machine, visit this web page.

Configuring a Hyper-V Virtual Machine for Port Mirroring on aWindowsServer 2012+


Configuring the ADTRAN (AOS) Switch for Port Mirroring

This procedure explains how to configure the ADTRAN (AOS) Switch for port mirroring throughboth the switch CLI and the switch webUI.

Configuration Through the CLI

To configure the device through the CLI

1. Open amonitor session.

2. Specify which port to mirror (the source port):

(config)#monitor session 1 source interface ethernet 0/<source_port>

3. Specify which port is going tomirror the traffic (the destination port):

(config)#monitor session 1 destination interface ethernet 0/<destination_port>

Note: There can only be onemonitor session, therefore, the only availablemonitor session is"1."

4. Verify the configuration of themirrored ports:

Switch#show monitor session all

Configuration Through theWebUI

To configure the device in the web UI

1. Navigate to Utilities > Port Mirroring.

2. Choose Destination Port.

3. Select the proper port from thismenu.

4. Select No-Tag option to not to tag VLAN traffic if needed.

5. Select the source port to mirror from the Source Port drop downmenu.

6. Click Add.

Note: If you want to add additional source ports to monitor, select another port from theSource Port drop downmenu and click Add.

7. In the CLI, verify the configuration of themirrored ports.

To learnmore about configuring port mirroring on ADTRAN (AOS) switches, see Configuring PortMirroring on AOS.pdf on https://supportforums.adtran.com/servlet/JiveServlet/previewBody/2291-102-2-8423.

Configuring the ADTRAN (AOS) Switch for Port Mirroring


https://supportforums.adtran.com/servlet/JiveServlet/previewBody/2291-102-2-8423/

https://supportforums.adtran.com/servlet/JiveServlet/previewBody/2291-102-2-8423/

Configuring the Check Point Gateway for Port Mirroring

This procedure explains how to configure a Check Point GatewaySwitch for port mirroring throughits CLI and webUI.

Connecting the Device

To configure the device

1. Open the VMware Security Gateway.

2. Enter the following in the command line:

sysconfig

3. Select Network Connections.

4. Select Configure Connections.

5. Select the interface to configure asmirror-port.

This is the one that you connected.

6. Select Define as connected to a mirror port.

7. Enable the Application Control blade in the SmartDashboard.

You can also enable the IPS blade to see IPS traffic.

Note: If you only want to enable the IPS blade, youmust activate at least one HTTPprotection.

8. Install the Policy.

Verifying the Configuration

To verify the configuration

1. Browse to an internet site, such asGoogle.

2. Open SmartView Tracker.

3. Verify that you see traffic from the blade you enabled.

To learnmore about configuring amirror port on a Check Point gateway, visit the Check Pointwebsite at https://sc1.checkpoint.com/documents/R76/CP_R76_AppControl_WebAdmin/64821.htm.

Configuring the Check Point Gateway for Port Mirroring


https://sc1.checkpoint.com/documents/R76/CP_R76_AppControl_WebAdmin/64821.htm

https://sc1.checkpoint.com/documents/R76/CP_R76_AppControl_WebAdmin/64821.htm

Configuring the Cisco ASA 5505 for Port Mirroring


1. Open amonitoring session.

2. Configure the interface:

#interface <port>

3. Specify the destination port:

#switchport monitor<destination_port>

4. Specify the source port:

#switchport monitor<source_port>

To learnmore about configuring port mirroring in the Cisco ASA 5505 device, visit the vendorwebsite at http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/configuration/guide/conf_gd/int5505.html#wp1067336.

Configuring the Cisco ASA 5505 for Port Mirroring


http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/configuration/guide/conf_gd/int5505.html#wp1067336

http://www.cisco.com/c/en/us/td/docs/security/asa/asa80/configuration/guide/conf_gd/int5505.html#wp1067336

Configuring the Cisco Nexus for Port Mirroring


1. Open amonitor session.

2. Enter global configurationmode:

#configure terminal

3. Enter interface configurationmode for the specified Ethernet interface selected by the port val-ues:

#interface ethernet [port]

4. Set the interface tomonitor mode. Priority flow control is disabled when the port is configured asa SPAN destination:

#switchport monitor

5. Revert the global configurationmode:

#exit

6. Enter monitor configurationmode:

#monitor session [session-number]

7. Configure the Ethernet destination port:

#destination interface ethernet [port]

To learnmore about configuring port mirroring with the Cisco Nexus device, see the vendor websiteathttp://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/Span.htm.

Configuring the Cisco Nexus for Port Mirroring


http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/Span.html

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/Span.html

Configuring the Cisco SGxxx Series for Port Mirroring

Cisco switches support a feature known as SPAN (short for Switch Port Analyzer) which allowstraffic received on an interface or VLAN to be sent to a single physical port. SPAN technically impliesthat the source and destination ports are local to the same switch. If the traffic destination is onanother remote switch, it usesRemote SPAN (RSPAN). If the destination requires crossing one ormore IP networks, some switches can use Encapsulated Remote SPAN (ERSPAN).

Important: USMAnywhere supports both SPAN and RSPAN. It does not support ERSPAN.

To learnmore about configuring port mirroring on the Cisco SGxxx Series devices, visit the vendorwebsite at https://www.cisco.com/assets/sol/sb/SG220_Emulators/SG220_Emulator_v1-0-0-18_20140626/home.html.

To configure port and VLAN mirroring

1. On the device, select Administration > Diagnostics > Port and VLAN Mirroring.

2. If your switch supports RSPAN:

l RSPAN VLAN — Select Enable to enable RSLAN VLAN mirroring.

l RSPAN VLAN ID — Select the VLAN to bemirrored.

Note: When you configure a RSPAN mirroring session, you should select this VLAN asthe RSPAN VLAN.

3. Click Add to add a SPAN or RSPAN mirroring session.

4. Provide the following information:

l Session ID — Select the identifier for themirroring session.

l Session Type — Select one of the following options:

o Local Port Based — Copies Tx, Rx, or both Tx and Rx traffic from each port to the des-tination port.

o Local VLAN Based — Copies traffic from the local VLAN to the destination port.

o RSPAN Source Session — Uses a VLAN to copy traffic from a source port or a sourceVLAN to another device.

o RSPAN Destination Session — Uses a VLAN to copy traffic from a destination port toanother device.



https://www.cisco.com/assets/sol/sb/SG220_Emulators/SG220_Emulator_v1-0-0-18_20140626/home.html

https://www.cisco.com/assets/sol/sb/SG220_Emulators/SG220_Emulator_v1-0-0-18_20140626/home.html

5. If Local Port Based is selected, specify the following:

l Destination Port — Select the analyzer port as the destination for the copied packets.

A network analyzer, such as a PC runningWireshark, is connected to this port.

Note: Any port identified as an analyzer destination remains such until all the entrieshave been removed.

l Allow Ingress Packets — Select Enable to allow the destination port to receive uncopiedingress packets.

l Source Port — Select the source ports for themirrored traffic and the type of traffic to bemirrored to the analyzer port:

o RxOnly — Port mirroring on incoming packets.

o TxOnly — Port mirroring on outgoing packets.

o Tx and Rx — Port mirroring on both incoming and outgoing packets.

o N/A — Traffic from this port is not mirrored.

6. If Local VLAN Based is selected, specify the following information:

l Destination Port — Select the analyzer port to where packets are copied.

l Allow Ingress Packets — Check Enable to allow the destination port to receive ingress pack-ets that are not copied.

l VLAN — Select the source VLAN fromwhere traffic ismirrored.

7. If RSPAN Source Session is selected, type the following information:

l RSPAN VLAN — Select the VLAN to be used to copy traffic to another device.

This VLAN should be same as the VLAN defined in the RSPAN VLAN ID field.

l Reflector Port — Select the port or LAG to be connected to another device.

l Source Type — Select Port or VLAN as the source port or source VLAN.

If Port is selected, select the source ports for themirrored traffic and the type of traffic to bemirrored to the analyzer port:

o RxOnly — Port mirroring on incoming packets.

o TxOnly — Port mirroring on outgoing packets.

o Tx and Rx — Port mirroring on both incoming and outgoing packets.

o N/A — Traffic from this port is not mirrored.

If VLAN is selected, select a source VLAN:

o VLAN — Select a VLAN as the source VLAN.



8. If RSPAN Destination Session is selected, specify the following information:

l RSPAN VLAN — Select the VLAN to be used to copy traffic to another device.

This VLAN should be same as the VLAN defined in the RSPAN VLAN ID field.

l Destination Port — Select the analyzer port as the destination for the copied packets.

l Allow Ingress Packets — Check Enable to allow the destination port to receive ingress pack-ets that are not copied.

9. Click Apply.

This updates the running configuration.



Configuring the Dell Networking Force10 Switch for Port Mirroring


1. Enter configurationmode.

#configure

2. Enter the destination port to use for themonitoring session, and confirm that it has no con-figuration:

#interface te 0/2

3. Remove any IP addresses that may have previously been configured:

#no ip address

4. Enable the port:

#no shutdown

5. Exit the destination port interface:

#exit

6. Set up and identify the session number (range is from 0 - 65535):

#monitor session 0

7. Configure the source, the port you want to monitor, the destination port you want to send themonitored packets to, and the direction (Both/Rx/Tx):

#source te 0/1 destination te 0/2 direction both

8. Verify port monitoring is active:

#show monitor session 0

To learnmore about configuring port mirroring on the Dell Networking Force10 Switch, visit thevendor website at http://www.dell.com/support/article/us/en/04/HOW10532.

Configuring the Dell Networking Force10 Switch for Port Mirroring


http://www.dell.com/support/article/us/en/04/HOW10532

Configuring the Fortinet-FortiGate Switch for Port Mirroring

This procedure explains how to configure Fortinet-FortiGate Switches for port mirroring onmodelswith built-in hardware switches (for example, the FortiGate-100D, 140D, and 200D), using theSwitch Port Analyzer (SPAN) feature.

Configuration Through the CLI

To configure SPAN through the CLI

Enter:

config system virtual-switchedit <port>set span enableset span-source-port <port>set span-dest-port <port>set span-direction {both | Tx | Rx}endend

Configuration Through theWebUI

To configure SPAN through the web UI

1. Go to System > Network > Interfaces.

2. Edit a hardware switch interface.

By default, the systemmay have a hardware switch interface called a LAN. You can also createa new hardware switch interface:

a. Select the SPAN check box, then select a source port fromwhich you want trafficmirrored.

b. Select one of the following:

l Traffic received

l Traffic sent

l Both

To learnmore about configuring port mirroring on Fortinet-FortiGate Switches, visit the vendorwebsite at http://kb.fortinet.com/kb/documentLink.do?externalID=FD36798.

Configuring the Fortinet-FortiGate Switch for Port Mirroring


http://kb.fortinet.com/kb/documentLink.do?externalID=FD36798

Configuring SonicWALL Port Mirroring

You can configure port mirroring on the Dell SonicWALLNSA 2400MX to send a copy of networkpackets seen on one or more switch ports (or on a VLAN) to another switch port, called themirrorport. By connecting to themirror port, you canmonitor the traffic passing through themirrored port(s).

Note: A VLAN trunk port can bemirrored, but cannot act as amirror port itself.

To create a new port mirroring group

1. Navigate to Switching > Port Mirroring.

2. Click New Group.

3. In the Edit Mirror Group dialog box, type a descriptive name for the group into the InterfaceGroup Name field.

4. For the Direction, select one of the following:

l ingress — Monitors traffic arriving on themirrored port(s).

l egress — Monitors traffic being sent from themirrored port(s).

l both — Monitors traffic in both directions on themirrored port(s).

5. In the All Interfaces list, select the port to mirror the traffic to and click the top right-arrow buttontomove it to theMirror Port field. Youmust use an unassigned port as themirror port.

6. In the All Interfaces list, select one or more ports to bemonitored, and click the lower right-arrow button tomove them to theMirrored Ports field. You will be able tomonitor traffic on themirrored port(s) by connecting to themirror port.

7. To enable port mirroring for these ports, select the Enable checkbox.

8. ClickOK.

To learnmore about configuring port mirroring on SonicWall devices, visit the vendor website athttps://support.sonicwall.com/kb/sw12079.

Configuring SonicWALL Port Mirroring


https://support.sonicwall.com/kb/sw12079

Alarm and Event Notifications

USMAnywhere provides support for direct integration with Slack, Datadog, and PagerDuty asnotificationmethods, aswell as integration with Amazon Simple Notification Service (Amazon SNS)to support custom integrationswith other messaging services. With direct integration, you can createan orchestration rule that sends notifications to a Slack channel, Datadog event console, orPagerDuty incident management console. With an Amazon SNS integration, you can create anorchestration rule that publishes notification requests to your Amazon SNS for message delivery.

Edition: Notification integrations are available in the Standard and Enterprise editions of USMAnywhere.

For more information about the feature and data support provided by each of the USMAnywhere editions, go to https://www.alienvault.com/pricing.

Fore details about creating orchestration rules, seeOrchestration Rules in the USMAnywhere UserGuide.

Before you can create a notification orchestration rule in your environment, youmust define one ormore of these integrations in USMAnywhere.


https://www.alienvault.com/pricing

Sending USM Anywhere Notifications to Slack


FromUSMAnywhere, you can send an alarm or event notification to a Slack channel so that teammembers are alerted. This facilitates communication and collaboration within the samemessagingtool that your organization uses for incident response.When you have this integration configured inUSMAnywhere, you can create orchestration rules to automatically send these notificationswhenan event or alarmmatches the rule criteria.



Note: While the direct integration with USMAnywhere is the easiest andmost straightforwardway to sendmessages to your Slack team fromUSMAnywhere, you can use the AmazonSNS messaging service as an alternative.

In this case, you create the webhook in Slack and then set up the integration in the Lambdafunction that you created in AWS to support USMAnywheremessaging (see SendingNotifications Through Amazon SNSand Set Up a Slack Integration through Amazon SNS).

Create the Slack Webhook

Slack provides amechanism to create incoming webhooks as a way to post messages from externalsources into Slack. Theymake use of normal HTTP requests with a JSON payload, which includesthemessage and some additional options. Youmust first create this webhook for your Slack team toconfigure the integration with USMAnywhere.

Important: To add an incoming webhook for the Slack team, youmust be the team owner orbe a teammember where the owner has granted the permission to install apps and customintegrations to all teammembers.

To create the incoming webhook for Slack

1. When you are logged into your Slack team, go to https://api.slack.com/incoming-webhooks.

2. Review the information and click the incoming webhook integration link to open the page for anew configuration.

Sending USMAnywhere Notifications to Slack



https://api.slack.com/incoming-webhooks

3. Choose the channel you want to use for USMAnywhere notifications.

If you do not already have a channel for this purpose, you can click the create a new channellink. You could create a new usmanywhere channel, for example, as either a public or privatechannel and invite the appropriate teammembers.

4. Click Add Incoming WebHooks integration.

5. Copy the displayedWebhookURL.

Configure the Slack Webhook in USM Anywhere

After you have generated and copied the incoming webhook for your Slack team, you can configureSlack connection in USMAnywhere. After this configuration is in place, any orchestration rules setup for Slack notification will send the triggered notification to the Slack team channel.

To configure the connection between USM Anywhere and the Slack channel

1. In the USMAnywhere webUI, go to SETTINGS > NOTIFICATIONS.

2. Click Slack in the left navigation panel.

3. In the Slack Webhook URL field, paste the webhookURL that you copied in the Slack API tool.




Add an Orchestration Rule for Slack Notifications

Create an orchestration rule tomatch new alarms or events and trigger a notification to the Slackchannel. You can use an existing alarm or event with the desired characteristics to easily set thematching conditions for the rule.

To create an orchestration rule to trigger a Slack notification

1. Navigate to ACTIVITY > ALARMS or ACTIVITY > EVENTS.

2. Click the alarm or event to open the details.

3. Click Create Rule and select Create Notification Rule.

4. Enter the Rule Name and set thematching conditions you want for the rule.

The Create Rule dialog displays property values for the selected alarm or event that you can useto specify thematch conditions. For more information, seeOrchestration Rules in the USMAnywhere User Guide.

5. For Notification Method, select the Slack option.



6. Enter the Slack Alert Username.

Thismust be a valid teammember for the Slack channel.

7. At the bottom of the dialog, set the Rule Condition parameters to specify the criteria for amatching alarm or event to trigger the rule.

l If you create the rule from an applied action, this section provides suggested property/valuepairs from the selected alarm or event that you can use as conditions for the rule. Click theDelete ( ) icon for items that you do not want to include in thematching conditions. You can

also add other conditions that are not suggested.

l If you create the rule from the Rules page, youmust use the Add Condition and Add Groupfunctions to define the property/value pairs that you want to use as conditions for the rule.

Click theMore... link at the bottom of the dialog to display the optionalmultiple occurrence andwindow length parameters.



Conditional Expression

Choose an operator and add one or more conditions to form the conditional expression. You caninclude a condition group to evaluate a subset of conditions. The Current Rule box displays theconstructed expression in standard syntax. The box displays a red border if the expression issyntactically invalid as currently specified. A valid expression is required to save the ruledefinition.

Select the operator used to determine thematch for multiple conditions.

l Select AND tomatch all conditions.

l Select OR tomatch any one condition.

l Select AND NOT to exclude itemsmatching all conditions after the first.

l Select OR NOT to include all items that do not match any conditions after the first.

Click Add Condition to add a condition. For each condition, specify the field name, evaluator,and value. If the evaluation returns true for the condition, it is amatch.

Click Add Group to a condition group. A new group includes a condition and its own operatorused tomatch the conditionswithin the group. You can nest condition groups.

Occurrences

Specify the number of event or alarm occurrences that produce amatch on the conditionalexpression to trigger the rule. The default value is 1. You can enter the number of occurrencesor use the arrow to scroll the value up or down.

USMAnywhere uses this in conjunction with the Length option to specify the number ofoccurrenceswithin a time period that will trigger the rule. For example, you can define a rule totrigger for an unauthorized access attempt when a failed SSH login occurs three timeswithin afiveminute window.

Length

Specify the length of the window to identify amatch for multiple occurrences. Enter the numberand choose a time unit value of seconds, minutes, or hours. This time period identifies theamount of time that transpires from the first occurrence to the last occurrence. If the number ofoccurrences is not met within this period, the rule does not trigger.

8. Click Save Rule.

Set Up a Slack Integration through Amazon SNS

If you prefer to use Amazon SNS to forward notifications to your Slack channel, you can add thewebhook that you created to the Lambda function in your AWS account.

Important: For this integration type, you do not add the Slackwebhook in USMAnywhere.When you create the orchestration rule, you select the Amazon SNS notificationmethod.



Before you can complete this integration, youmust have an SNS topic and a Lambda Function forUSM Anywhere notifications set up in your AWS account (see Setting Up an SNS Topic and aLambda Function) and a Slack incoming webhook (see Create the SlackWebhook).

To integrate the Slack webhook with the USM Anywhere through Amazon SNS

1. In the Lambda function code, paste this code and replace [INSERT_WEBHOOK_URL] with theSlackWebhookURL.

2. Use the default Role setting (Create a new role from templates) and specify the Role name aslambda_basic_execution.

3. Expand the Advanced settings and set the Timeout to 10 seconds.

4. Click Next.

5. Click Create function.

To check the integration with Slack

1. Go to your Lambda function, clickMonitoring and check the Invocation Count graph data.

2. Check in your Slack channel for notifications.



https://www.alienvault.com/documentation/resources/downloads/notifications/slack.py

Sending USM Anywhere Notifications to Datadog


FromUSMAnywhere, you can send an alarm or event notification to your Datadog event console sothat teammembers are alerted. This facilitates communication and collaboration within the samemessaging tool that your organization uses for infrastructuremonitoring.When you have thisintegration configured in USMAnywhere, you can create orchestration rules to automatically sendthese notificationswhen an event or alarmmatches the rule criteria.



Note: While direct integration with USMAnywhere is the easiest andmost straightforwardway to sendmessages to your Datadog environment fromUSMAnywhere, you can use theAmazon SNS messaging service as an alternative. In this case, you create the API key inDatadog and then set up the integration in the Lambda function that you created in AWS tosupport USMAnywheremessaging (see Sending Notifications Through Amazon SNS andSet Up a Datadog Events Integration Through Amazon SNS).

Create a Datadog API Key

Datadog provides amechanism to create API keys as a way to post data from external sources intoDatadog events. All requests to the Datadog API must be authenticated. Requests that write datarequire reporting access and require an API key. Youmust first create this API key to configure theintegration with USMAnywhere.

To create the API key for Datadog

1. Log into your Datadog account and go to https://app.datadoghq.com/account/settings#api.

2. For the New API key, enter a name for the key and click Create API key.

Make sure to copy the generated key value and store it in a secured location.

3. (Amazon SNS Only) For the New application key, click Create Application key and copy thegenerated value.

Note: This key is not used for a direct integration with USMAnywhere. However, if youplan to use the Amazon SNS messaging service for a custom integration, any requeststhat read data require full access and an application key.

Sending USMAnywhere Notifications to Datadog



https://app.datadoghq.com/account/settings#api

Configure the Datadog API Key in USM Anywhere

After you have generated and copied the API key for your Datadog environment, you can configureUSMAnywhere for Datadog notifications. After this configuration is in place, any orchestration rulesset up for Datadog notification will send the triggered notification to your Datadog events.

To configure the connection between Datadog events and USM Anywhere


2. Click Datadog in the left navigation panel.

3. In the Datadog API key field, paste the key value that you generated in the Datadog API tool.


Add an Orchestration Rule for Datadog Notifications

Create an orchestration rule tomatch new alarms or events and trigger a notification to Datadogevents. You can use an existing alarm or event with the desired characteristics to easily set thematching conditions for the rule.

To create an orchestration rule to trigger a Datadog notification








5. For Notification Method, select the Datadog option.

6. Set the Datadog Priority.




Occurrences



Length


8. Click Save Rule.

Set Up a Datadog Events Integration Through Amazon SNS

If you prefer to use Amazon SNS to forward notifications to your Datadog Events, you can add theAPI key to the Lambda function in your AWS account.

Important: For this integration type, you do not add the Datadog API key in USMAnywhere.When you create the orchestration rule, you select the Amazon SNS notificationmethod.

Before you can complete this integration, youmust have an SNS topic and a Lambda Function forUSMAnywhere notifications set up in your AWS account (see Setting Up an SNS Topic and aLambda Function) and a Datadog API key (see Create a Datadog API Key).



To integrate USM Anywhere notifications with Datadog Events through Amazon SNS

1. In the Lambda function code, paste this code and replace [INSERT_DATADOG_API_KEY]and [INSERT_DATADOG_APPLICATION_KEY] with your Datadog keys.

You can alsomodify the Datadog fields and adapt them to your environment, similar to thefollowing:

alert_type = "info"default_priority = "normal"default_tags = ["environment:test", "security"]send_payload = True

2. Use the default Role setting (Create a new role from templates) and specify the Role name aslambda_basic_execution.



https://www.alienvault.com/documentation/resources/downloads/notifications/datadog.py

3. Expand the Advanced settings and set the Timeout to 10 seconds.

4. Click Next.

5. Click Create function.

To check the integration with Datadog

1. Go to your Lambda function, clickMonitoring, and check that the Invocation Count graph showssome data.

2. Click View logs in CloudWatch and open the last entry.



You should see entries similar to the following:

3. Navigate to the Datadog event URL and check that you see the USMAnywhere alarm in theDatadog console.

Sending USM Anywhere Notifications to PagerDuty


FromUSMAnywhere, you can send an alarm or event notification to your PagerDuty incidentmanagement console so that teammembers receive alerts. This facilitates communication andcollaboration within the samemessaging tool that your organization uses for incident response.When you have this integration configured in USMAnywhere, you can create orchestration rules toautomatically send these notificationswhen an event or alarmmatches the rule criteria.



Sending USMAnywhere Notifications to PagerDuty



Create the PagerDuty Integration

PagerDuty provides amechanism to create services that include integrations to its Events API as away to post data from external sources into PagerDuty incidents. The service configurationdetermines how PagerDuty handles the incoming incident. Youmust first create the integration keyfor a PagerDuty service before you set up the configuration in USMAnywhere to send thesenotifications.

Note: A PagerDuty service typically represents an application, component, or team foropening incidents. If you already have a defined service and you want to incorporate USMAnywhere notificationswith it, you can simply add a new integration to that service and use theparameters outlined in the following procedure.

To create a PagerDuty service and integration for USM Anywhere

1. Log into your PagerDuty account.

2. In the topmenu, select Configuration > Services.

3. At the top of the page, click Add New Service.

4. In the General Settings, enter a Name for the new service (such as AlienVault).

5. In the Integration Settings, set the type and name for the integration.

l Choose Use our API Directly and select Events API v2.

l Enter an Integration Name, such asUSMAnywhere.



6. Set the Incident Settings and Incident Behavior according to how you want PagerDuty tohandle the incidents (notifications) fromUSMAnywhere.

7. Click Add Service.

8. In the Integrations tab, copy the Integration Key for the new integration.

Make sure to copy the key value to a secured location.



Configure the PagerDuty Integration in USM Anywhere

After you have created the PagerDuty integration and copied the key, you can configure USMAnywhere for PagerDuty notifications. After this configuration is in place, any orchestration rules setup for PagerDuty notification will send the triggered notification to the PagerDuty service for incidenthandling.

To configure the connection between PagerDuty and USM Anywhere


2. Click PagerDuty in the left navigation panel.

3. In the PagerDuty integration key field, paste the key value that you copied from your PagerDutyservice integration.


Add an Orchestration Rule for PagerDuty Notifications

Create an orchestration rule tomatch new alarms or events and trigger a notification to yourPagerDuty service. You can use an existing alarm or event with the desired characteristics to easilyset thematching conditions for the rule.

To create an orchestration rule to trigger a PagerDuty notification








5. For Notification Method, select the PagerDuty option.







Occurrences



Length


7. Click Save Rule.



Review USM Anywhere Notifications in PagerDuty

PagerDuty creates incidents for the service from the notifications that USMAnywhere sends. Youcan review and respond to these incidents from your PagerDuty incidents dashboard.When youexpand the details for the incident, click the CLIENT link to open the event or alarm in USMAnywhere.

Sending Notifications Through Amazon SNS

Amazon Simple Notification Service (SNS) is a flexible messaging andmobile notifications servicefor coordinating the delivery of messages to subscribing endpoints and clients. You can configureSNS using the AWSManagement Console, AWS Command Line Interface, or using the AWSSDK. By subscribing AWS Lambda functions to Amazon SNS topics, you can perform custommessage handling.

USMAnywhere provides an integration point for Amazon SNS to connect to your SNS topic throughthe Amazon SNS APIs. When you have this integration configured in AWS and USMAnywhere,you can create orchestration rules to automatically send these notificationswhen an event or alarmmatches the rule criteria.





Completing the Amazon SNS integration for USMAnywhere notifications includes the followingtasks:

l Setting Up an SNS Topic and a Lambda Function

l Creating an AWS Access Key

l Configuring SNS Notifications in USMAnywhere

Setting Up an SNSTopic and a Lambda Function

When using Amazon SNS, you create a topic and control access to it by defining policies thatdetermine which publishers and subscribers can communicate with the topic. As a publisher, USMAnywhere can then sendmessages (notifications) to topics for which it has the needed credentials(access key).

When an SNS topic has a Lambda function subscribed to it, it invokes the Lambda function with thepayload of a publishedmessage. The Lambda function receives themessage as an input parameterand canmanipulate the information in themessage, publish themessage to other SNS topics,and/or send themessage to other AWS services or endpoints.

To set up a SNS topic and a Lambda Function for USM Anywhere notifications

1. Log in to your AWS Account and go to the Amazon SNS console.

2. Create a new SNS topic in the AWS SNS dashboard page.

l Click Create topic.

l Enter a topic name and a display name.

l Click Create topic.

3. Open the AWS Lambda page and click Create a function.

4. Click Author from scratch.

5. Click the dotted square icon and select SNS in the list.

6. Select the SNS topic you created.

7. Select the Enable trigger option.

8. Click Next.




https://console.aws.amazon.com/sns/v2/home?region=us-east-1

https://console.aws.amazon.com/lambda/home?region=us-east-1#/home

9. Create a hello world lambda function:

l Enter a name and a description.

l Select Python 2.7 in the Runtime field.

l In the Lambda function code, copy and paste the following code:

import jsondef lambda_handler(event, context):

message = json.loads(event['Records'][0]['Sns']['Message'])print("JSON: " + json.dumps(message))return message

l In the Lambda function handler and role select a handler, a role, and an existing role.



l Expand the Advanced settings and set the Timeout to 10 seconds.

l Click Create Function.

Creating an AWSAccess Key

USMAnywhere requires an access key tomake programmatic calls to AWS API operations. Theseaccess keys consist of an access key ID and a secret access key.

To create an AWS Access Key ID

1. Log in to your AWS Account and go to the Amazon SNS console.

2. Create a new user (see the Add User page).

3. Select Programmatic access.

4. Click Next: Permissions.

5. Click Attach existing policies directly.

6. Click Create policy.



https://console.aws.amazon.com/iam/home?region=us-east-1#/users$new?step=details

7. Create a policy with the following code:

{"Version":"2012-10-17","Statement":[{

"Effect":"Allow","Action":"sns:Publish","Resource":"arn:aws:sns:us-east-1:ACCOUNT_ID:USMA"}

]}

8. Replace ACCOUNT_ID and USMA with the ID of your AWS Account and the name of the SNSTopic you created (Setting Up an SNS Topic and a Lambda Function).

9. Attach the new policy you created.

10. Attach also the AmazonSNSReadOnlyAccess policy or manually add permissions to list topics("Resource": "*").

11. Click Next and Create User.

Note: Copy the access key ID and secret access key, which you will need to configure AmazonSNS in USMAnywhere.

Configuring SNS Notifications in USM Anywhere


After you set up the SNS topic and Lambda function and create the access key, you can configureAmazon SNS notifications in USMAnywhere.

To configure Amazon SNS Credentials for notifications

1. Navigate to SETTINGS > NOTIFICATIONS.

2. Click Amazon SNS in the left navigation panel.

3. Select the AWS Region name.

4. Enter the Access key and Secret key.



SeeCreating an AWS Access Key.


To create an orchestration rule for sending a notification request to Amazon SNS







TheCreate Rule dialog displays property values for the selected alarm or event that you can useto specify thematch conditions. For more information, seeOrchestration Rules in the USMAnywhere User Guide.

5. For Notification Method, select the Amazon SNS option.

6. Enter the SNS Topic Name you created in the AWS console.

See Setting Up an SNS Topic and a Lambda Function.

















Occurrences





Length


8. Click Save Rule.

When amatching alarm or event is generated in USMAnywhere, you can go to your AWSconsole and select the Lambda function you created to verify that the function is being called.



Setup and Configuration of Your USMAnywhereEnvironment

The SetupWizard helps first-time users configure USMAnywhere Sensor capabilities withinminutes. Its simple, step-by-step workflow lets you

l Configure sensors

l Manage logs

l Perform authenticated scans on your assets

But, before you can start seeing the results, there are certain configurationswithin your network thatmust be in place to ensure that USMAnywhere is receiving all of your relevant event logs.

l Network firewall allows communication with USMAnywhere

l Operating system forwards all relevant logs to USMAnywhere


Log Management


Important: If you don't allow the use of a privileged port (< 1024) on your production system,you can change the port to a non-privileged number. However, be aware that if you changethis in USMAnywhere, you also need to configure your third-party device to use the new portnumber.

Remote Log Data Transfer on a Platform or Third-Party Device



l Log collection fromAWS — AWS LogDiscovery and Collection in USMAnywhere.

l Log collection fromAzure — Azure Log Discovery and Collection in USMAnywhere


Disabling the Syslog Server App

The Syslog Server app is enabled by default for each deployed USMAnywhere Sensor. If you wantto disable the app for a sensor, follow this procedure.

To disable syslog data receipt from third-party devices

1. In USMAnywhere, choose SETTINGS > LOG COLLECTION.

2. Under Sensor Apps, click Syslog Server.

3. Select the sensor where you want to disable the app.

4. Click Disable.

LogManagement


File Integrity Monitoring

File integritymonitoring (FIM) is amechanism for validating the integrity of operating system andapplication software files using a verificationmethod between the current file state and a known,good baseline. It is one of themost powerful techniques used to secure IT infrastructures andbusiness data against a wide variety of both known and unknown threats.

FIM for Linux

For Linux systems, you can enable FIMwithin USMAnywhere by configuring the osquery agent tomonitor and track file changes on those systems. The osquery configuration file (typically namedosquery.conf) contains the configuration options and queries that osquery useswhen it runs.AlienVault provides a default configuration file that you can use to enable FIM for Linux systems inyour USMAnywhere environment to identify system and software file changes and forward thisinformation to the USMAnywhere Sensor.

For more information about installing and configuring osquery on your Linux systems, see CollectingLogs from LinuxUsing osquery.

FIM forWindows

For Windows systems, you can use FIM to identify changes in system files, folders, andMicrosoftWindows registries. To use FIM, you configureWindows systems so that USMAnywhere can viewWindows audit object access events. To do so, you need to enable file auditing and update securitypolicy settings. After applying policy changes to include audit object events inWindows security logs,NXLog will forward those events to the USMAnywhere Sensor.

See CollectingWindowsSystem Logs for detailed information about using NXLog to forward theseevents.

Configuring Policy Settings for Object Access Audit Events

Local Policies determine the security options for a user or service account. Local policies are basedon the computer and the rights for the account on that computer. Local Policies can be used toconfigure an audit policy, which determineswhich security events will be logged into the Security logon the computer (successful attempts, failed attempts, or both). This Security log is accessible fromthe Event Viewer.

To define local group policy settings for object access audit events

1. On a selectedWindows system, open the Local Group Policy Editor.

2. Navigate to Computer Configuration > Windows Settings > Security Settings > LocalPolicies > Audit Policy.

File IntegrityMonitoring


3. Open the Audit object access policy.

4. In the dialog, select the Success and Failure check boxes to enable auditing.

5. Click Apply and thenOK.



Configuring Policy for File Auditing in the Active Directory Domain

In order to track file system changes on aMicrosoft Active Directory Domain so that USMAnywherecan view Windows audit object access events, first youmust set theWindows group policy to keeptrack of file system changes.

The following example uses the default domain controller policy in order to track changes on adomain controller. Your actual policymight be different, depending on your particular domainconfiguration.

To audit changes on a domain controller

1. From the Server Manager, open upGroup PolicyManagement, and expand the domain toselect the policy you want to edit.

2. Right-click the policy and choose Edit.

3. Select the Security Options and change the Audit: Force audit policy subcategory settingsoption to enable it.

This allows themore granular advanced audit policy settings instead of the general categoriesthat are enabled by default.

4. Locate and expand the Advanced Audit Policy Configuration option.

Note: This procedure is primarily concerned with object auditing, but you will need tomakesure the other policies, such as account lockout, are correct for your organization.Remember, these advanced policies are now taking precedence.

5. For the Audit File System policy, change the configuration to Success and Failure.



6. Verify that the Group Policy you just edited is enforced, and applied to the domain per your par-ticular configuration.

Configuring a Folder for Auditing

In order for the policy to be effective, you need to enable auditing on the files and directories that youwant to monitor. Youmight be tempted to just enable the entire filesystem, and inherit throughout,and you could do that — however, this will be extremely detrimental to the operation of the server,creating hundreds or thousands of events per minute. You should also consider how often youexpect changes to the folders you are auditing because it can get quite noisy.

Note: You can only set up file and folder auditing on NTFS drives.

To apply or modify auditing policy settings

1. OpenWindows Explorer and navigate to the file or folder you want to audit.

Note: Because theWindows security log is limited in size and new audit events will bestored there, select the files and folders to be audited carefully. Also, consider the amountof disk space that you want to devote to the security log. Themaximum size for the securitylog is set in Event Viewer.

2. Right-click the file or folder and select Properties.

3. Select the Security tab and click Advanced.

4. Select the Auditing tab and click Continue if prompted.

This displays the auditing policies for the file or folder.



5. Perform one of the following operations:

l To set up auditing for a new user or group, click Add. In the Enter the object name to selectfield, enter the name of the user or group that you want to audit and clickOK.

l To remove auditing for an existing group or user, select the group or user name, clickRemove, and clickOK. You can skip the remaining steps.

l To view or change auditing for an existing group or user, select the name and click Edit.

6. Set the Applies to option to specify the location that you want to audit.



7. In the permissions box, select the actions that you want to audit.

You can click Show advanced permissions to display additional permissions for selection. ForFIM enablement, Create, Write, Append, and Delete permissions are key.

8. (Optional) If you want to prevent subordinate files and subfolders of the original object from inher-iting audit settings, select the Apply these auditing entries to objects and/or containers withinthis container only option.

9. ClickOK.

Testing and Viewing Events

After enabling object access auditing, you can view the security log in theWindowsEvent Viewer tosee that the audit events are now collected. You can test to make sure the events are properlygenerated inWindowsEvent viewer by creating a file, editing it, moving it out of the folder, and thenmoving it back in. This should generate the events in the Event Viewer of aWindowsServer, lookinglike the following example:



WhenNXLog is set up to forward these events to the USMAnywhere Sensor, these audit eventsare available in your USMAnywhere environment.



Collecting Linux System Logs

The use of syslog is required to send log data from Linux systems to the USMAnywhere SensorIP address over UDP on port 514. If you want to gainmore visibility and use File IntegrityMonitoring(FIM) in your Linux systems, USMAnywhere also supports osquery by default.

Using syslog to Send Logs from a Linux System

Syslog is an industry standardmessage logging system that is used onmany devices and platforms.It provides amechanism for network devices to send event messages to a logging server, alsoknown as a Syslog server. For example, a router might sendmessages about users logging on toconsole sessions, while a web server might log access-denied events.

Follow the procedure that corresponds to the Linux distribution you use:

Fedora Linux Distribution

Youmust have sudo privileges to complete this procedure.

To send logs from Fedora Linux using syslog

1. On your Linuxmachine, open /etc/rsyslog.conf and add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

2. Restart rsyslog:

sudo service rsyslog restart

Red Hat Enterprise Linux Distribution


To send logs from Red Hat Enterprise Linux using syslog

1. On your Linuxmachine, install rsyslog for RHEL-5 (installed by default for RHEL-6 and 7):

sudo yum install rsyslog

2. Open /etc/rsyslog.conf and add the following line to the start of the file:


3. Restart rsyslog:

sudo service syslog stop (only for RHEL-5)sudo service rsyslog restart

openSUSE Distributions




To send logs from openSUSE Distributions

1. Install rsyslogd:

sudo yast -i rsyslog

2. Set rsyslog as syslog server:

a. Open /etc/sysconfig/syslog.

b. Add the following lines:

SYSLOG_DAEMON=”rsyslogd”RSYSLOGD_COMPAT_VERSION=”4″

c. Save it and run SuSEconfig.

3. On your Linuxmachine, open /etc/rsyslog.d/remote.conf and add the following line:


4. Restart rsyslog:


Debian GNU/Linux and Ubuntu Distributions


To send logs from Debian GNU/Linux and Ubuntu Distributions

1. On your Linuxmachine, open the appropriate configuration file:

l (debian) /etc/rsyslog.conf

l (ubuntu) /etc/rsyslog.d/50-default.conf

2. Add the following line:


3. Restart rsyslog:


SUSE Linux Enterprise 11 SP4 - 12 SP1Server Distribution


To send logs from SUSE Linux Enterprise Server Distribution

1. Install the rsyslogd package:

sudo yast -i rsyslog

2. Set rsyslog as syslog server by editing the following parameters in /etc/sysconfig/syslog:

SYSLOG_DAEMON=”rsyslogd”



RSYSLOGD_COMPAT_VERSION=”4″

3. Save the file and run SuSEconfig.

4. On your Linuxmachine, open rsyslog.d/remote.conf and add the following line:


5. Restart rsyslog:

sudo rcsyslog restart

Solaris Distribution


To send logs from Solaris distributions

1. On your Linuxmachine, open /etc/syslog.conf and add the following line:

*.notice @<USM-Anwhere-Sensor-IP-address>

Important: In the foregoing command, youmust tab from auth.notice to @<USM-Anwhere-Sensor-IP-address>; if you type a space the commandwill fail.

2. Stop, then restart syslog:

Solaris 5.9 and earlier

sudo /etc/init.d/syslog stopsudo /etc/init.d/syslog start

Solaris 5.10 and above

#sudo svcadm refresh svc:/system/system-log

FreeBSD Distributions


To send logs from FreeBSD Distributions

1. On your Linuxmachine, open /etc/syslog.conf and add the following line:


Note: Unlike the similar command for Solaris, no tab is required between *.*. and@<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514.

2. Restart rsyslog:

sudo service syslogd restart

Gentoo Distributions




To send logs from Gentoo Distribution

1. On your Linuxmachine, open /etc/rsyslog.conf and add the following line:


2. Restart rsyslog:

sudo /etc/init.d rsyslog restart

Arch Linux Distribution


To send logs from Arch Distribution

1. On your Linuxmachine, open /etc/syslog-ng/syslog-ng.conf and add the following line:


2. Restart rsyslog:

sudo systemctl start rsyslog

Collecting Logs from Linux Using osquery

osquery is an operating system instrumentation framework for Linux that exposes this operatingsystem as a high-performance relational database so that SQL queries can explore the operatingsystem data. With osquery, SQL tables represent abstract concepts such as running processes,loaded kernelmodules, open network connections, browser plugins, hardware events, or filehashes.


For information about installing osquery with a Log Agent wrapper in an AWS environment, seeInstalling osquery and CloudWatch Through the Log Agent.

To collect logs from Linux using osquery

1. If you do not yet have osquery, download it and follow the instructions appropriate for your oper-ating system.

2. Create a text file called osquery.conf and copy-paste the contents of this file into it.

Important: After copy-pasting the text, make sure to edit it so that all stringswith equalssigns (=) in them remain on the same line. Otherwise, this procedure will fail.

3. Save osquery.conf and copy it to /etc/osquery/.

Note: We recommend leaving the queries created by default, but you can create your ownosquery configuration.

4. Start the osquery daemon:



https://osquery.io/downloads

osqueryd --daemonize --config_path /etc/osquery/osquery.conf

5. Configure syslog to send data to the USMAnywhere Sensor:


6. Restart syslog:


7. Verify that you can see osquery events in USMAnywhere.



Collecting Windows System Logs

USMAnywhere leveragesNXLog to collect and forwardWindows events to a sensor. NXLog is auniversal log collection and forwarding agent for basicWindows event logs. But, it's also useful in itsown right for suppressing spurious events. NXLog collects this audit log data and forwards it to theUSMAnywhere Sensor over the syslog protocol on UDP port 514.

There are two ways you can implement this agent and integrate it with your USMAnywhere Sensorto collect and forward events from your Windows systems:

l Install and configure NXLog CE across your Windows hosts to use customNXLog configurationsto capture non-Windows events on your end servers.

l Use theWindowsEvent Collector sensor app tomanage the NXLog subscription used to for-ward your windows logs directly to a deployed USMAnywhere Sensor. When you use thismethod, the sensor acts as the collector and theWindows host will forward the logs directly to thesensor using a private IP address, not over the public Internet.

NXLog provides an open source version and a paid, enterprise version. The USMAnywhere Sensorintegration using theWindowsEvent Collector app is based on the enterprise version. And theAlternativeMethod is based on the open source Community Edition.

Configuring NXLog CE forWindows Hosts

If you want to collect and forwardWindows events that are not supported by theWindowsEventCollector sensor app or other types of non-Windows application events from aWindows host, youcan install and configure NXLog Community Edition (CE) and customize your configuration file forintegration with USMAnywhere. You can choose to set up NXLog on eachWindows host to forwardevents directly to the USMAnywhere Sensor or use a forwarding server as a central collection point.

TheMSWindowsNXLog plugin provided byUSMAnywhere translates the raw log data intonormalized events for analysis. This plugin automatically processes all messages forwarded to theUSMAnywhere Sensor where the syslog tagmatches the value "eventlog”.

Note: For useful information about testing and debugging your Windows events, seehttps://blogs.technet.microsoft.com/kevinholman/2011/08/02/how-to-test-fire-any-windows-event-on-any-server-from-any-application/.

Forwarding NXLog Messages Directly to the Sensor

The simplest implementation is to install NXLog CE on eachWindows host and configure it toforwardmessages to the USMAnywhere Sensor.

CollectingWindowsSystem Logs


https://blogs.technet.microsoft.com/kevinholman/2011/08/02/how-to-test-fire-any-windows-event-on-any-server-from-any-application/

https://blogs.technet.microsoft.com/kevinholman/2011/08/02/how-to-test-fire-any-windows-event-on-any-server-from-any-application/

Install NXLog and configure nxlog.conf on each host

Before you configure the nxlog.conf file, youmust have the IP Address of the USMAnywhereSensor.

To install NXLog CE and configure forwarding

1. Download the newest stable NXLog Community Edition.

2. Follow the instructions to sign up for the trial and to download the file.

3. For security, make a backup copy of C:\Program Files (x86)\nxlog\conf\nxlog.confand give it another name (you can delete it later).

4. Download the NXLog configuration file and save it as your new nxlog.conf file.

https://www.alienvault.com/documentation/resources/downloads/nxlog.conf

5. Open the configuration file for editing and replace usmsensoripherewith the IP address of theUSMAnywhere Sensor.

Important: Make sure USMAnywhere allows inbound requests to UDP port 514 from thishost.

6. Save the file.

7. OpenWindowsServices and restart the NXLog service.

8. Open USMAnywhere and verify that you are receiving NXLog events.

Note: If you need to debug NXLog, open C:\Program Files(x86)\nxlog\data\nxlog.log.

Install Sysmon on each Windows host

SystemMonitor (Sysmon) is aWindows system service and device driver that remains residentacross system reboots tomonitor and log system activity to theWindows event log. It providesdetailed information about process creations, network connections, and changes to file creationtime. Sysmon is a freeWindowsSysinternals tool fromSysinternals/Microsoft.

Note: Installing Sysmon is optional, but recommended.

To install Sysmon

1. Download the Sysmon ZIP file and unzip it in the target system.

2. Download the Sysmon configuration file to a folder and name the file as sysmon_config.xml.

https://www.alienvault.com/documentation/resources/downloads/sysmon6_config_basic.xml

3. Install Sysmon in theWindows system and execute the following command:

sysmon.exe -accepteula -h md5 -n -l -i sysmon_config.xml

Sysmon starts logging the information to theWindowsEvent Log.



https://nxlog.co/products/nxlog-community-edition/download


https://technet.microsoft.com/en-us/sysinternals/dn798348

https://download.sysinternals.com/files/Sysmon.zip


4. Edit the NXLog configuration file under EventLog > Querylist.

Look for the <Input eventlog> tag and add this line:

<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>\

With the line addition, it should look like this example:

<Input eventlog>Module im_msvistalogQuery <QueryList>\<Query Id="0">\<Select Path="Application">*</Select>\<Select Path="System">*</Select>\<Select Path="Security">*</Select>\<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>\</Query>\</QueryList></Input>

5. Save the file.

6. Apply the last configuration by openingWindowsServices and restarting NXLog.

7. Open USMAnywhere and verify that you are receiving Sysmon events.

Using a Windows Server as a Central Collector

You can choose an implementation where you set up eachWindows host to forward its events to asubscribing server. In this scenario, the collector server acts as a central repository for Windows logsfrom other servers in the network. With thismethod, youmust set upWindowsEvent Forwarding oneachWindows host to enable the collection functions.

l ForwardWindowsEvents to a NXLogCE agent running on aWindows server

l Enable syslog forwarding from the NXLogCE agent to the USMAnywhere Sensor

Thismethod of auditing and forwardingWindows event logs is intended for use in these USMAnywhere environments:

l On-premises (VMware or Hyper-V sensors)

l AWS, where theWindows hosts are deployed within one of the following configurations:

l TheWindows hosts, the NXLog agent server, and USMAnywhere Sensor are located in thesame AWS VPC.

l TheWindows hosts, the NXLog agent server, and USMAnywhere Sensor are not located inthe same AWS VPC, but you have VPC peering configured to allow the NXLog server to com-municate with the sensor using UDP port 514.

l Azure, where theWindows hosts, the NXLog agent server, and USMAnywhere Sensor arelocated in the same virtual network.



https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html

Important: Because it does not require that you set up log forwarding on each host, theeasiest andmost straightforwardmethod for Windows log collection in an Azureenvironment is to collect theWindowsSecurity events from the Azure storage table.However, if you need the additional logs forwarded byNXLog, you can use the followinginformation to configureWindows log collection for this environment.

Complete the following tasks to implement thismethod of auditing and forwardingWindows eventlogs andmanage the subscriptions.

Install NXLog on the central (subscribing) server and configure nxlog.conf

The first task to install NXLog CE on the computer where events will be collected.

To install NXLog CE and configure forwarding

1. Download the newest stable NXLog Community Edition.

2. Follow the instructions to sign up for the trial and to download the file.

3. For security, make a backup copy of C:\Program Files (x86)\nxlog\conf\nxlog.confand give it another name (you can delete it later).

4. Download the NXLog configuration file and save it as your new nxlog.conf file.


5. Open the configuration file for editing and replace usmsensoripherewith the IP address of theUSMAnywhere Sensor.

Important: Make sure USMAnywhere allows inbound requests to UDP port 514 from thishost.

6. Save the file.

7. OpenWindowsServices and restart the NXLog service.

8. Open USMAnywhere and verify that you are receiving NXLog events.

Note: If you need to debug NXLog, open C:\Program Files(x86)\nxlog\data\nxlog.log.

Install Sysmon on the central server and Windows hosts

SystemMonitor (Sysmon) is aWindows system service and device driver that remains residentacross system reboots tomonitor and log system activity to theWindows event log. It providesdetailed information about process creations, network connections, and changes to file creationtime. Sysmon is a freeWindowsSysinternals tool fromSysinternals/Microsoft.

Note: Installing Sysmon is optional, but recommended.



https://nxlog.co/products/nxlog-community-edition/download


https://technet.microsoft.com/en-us/sysinternals/dn798348

To install Sysmon

1. Download the Sysmon ZIP file and unzip it in the target system.

2. Download the Sysmon configuration file to a folder and name the file as sysmon_config.xml.


3. Install Sysmon in theWindows system and execute the following command:

sysmon.exe -accepteula -h md5 -n -l -i sysmon_config.xml

Sysmon starts logging the information to theWindowsEvent Log.

4. Edit the NXLog configuration file under EventLog > Querylist.

Look for the <Input eventlog> tag and add this line:

<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>\

With the line addition, it should look like this example:

<Input eventlog>Module im_msvistalogQuery <QueryList>\<Query Id="0">\<Select Path="Application">*</Select>\<Select Path="System">*</Select>\<Select Path="Security">*</Select>\<Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>\</Query>\</QueryList></Input>

5. Save the file.

6. Apply the last configuration by openingWindowsServices and restarting NXLog.

7. Open USMAnywhere and verify that you are receiving Sysmon events.

Perform the initial configuration

Use this procedure to configure the domain computers to collect and forward events.

To configure domain computers to collect and forward events

1. Log onto all collector and source computers.

Note: It is a best practice to use a domain account with administrative privileges.

2. On the collector computer, launch the Administration console and enter the following command:

wecutil qc

3. On each source computer (every computer where you want to run logs), enter the following at



https://download.sysinternals.com/files/Sysmon.zip


an elevated command prompt:

winrm quickconfig

4. Add the collector computer account to the Event Reader Group.

a. Edit the group configuration through Local Users and Group.

b. Add the local computer NETWORK SERVICE account to the Event Log Readers Group.

c. Change the search location for the NETWORK SERVICE account from the domain to localcomputer.

This allows you to access the Security group channel.

d. Reboot themachine.

Note: If you don't want to reboot, you can read the Security Log without rebooting byentering wevtutil sl security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;s-1-5-20) from anAdministration console.

Add the subscription

Set up the event subscription to receive forwarded events on the Collector.

To add the subscription

1. Log in as administrator to the Collector computer.

2. Go to Administrator Tools and run Event Viewer.

3. In the console tree, click Subscriptions.

4. From the Actions menu, click Create Subscription.

5. In the Subscriptions Name field, enter the name of the subscription.

6. (Optional) In the Description field, enter a description of the subscription.

7. In the Destination Log list, select the log file in which you want to store collected events.

By default, collected events are stored in the ForwardedEvents log.

8. Click Add, and select the computers fromwhich to collect events.

9. To test connectivity to the source computer, click Test.

10. Click Select Events.

11. In the Query Filter dialog, use the controls to specify the criteria that eventsmust meet to becollected.

To take full advantage of USMAnywhere detection capabilities, AlienVault recommends thefollowingminimum list of channels.



l Windows Logs→ Application

l Windows Logs→ Security

l Windows Logs→ System

l Windows Logs→ Security

l Application and Services Logs→ Microsoft→ Windows→ AppLocker

l Application and Services Logs→ Microsoft→ Windows→ PowerShell

l Application and Services Logs→ Microsoft→ Windows→ Sysmon

l Application and Services Logs→ Microsoft→ Windows→ WindowsDefender

l Application and Services Logs→ Microsoft→ Windows→ Windows Firewall withAdvanced Security

l Application and Services Logs→ WindowsPowerShell

USMAnywhere supports a full list of channels, which allows it to detect a wide array of specifictypes of attacks on theMSWindows platform.

You can also enable Security Group auditing and Registry auditing on certain sensitive registrykeys, such as HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.

12. Under Advanced, select Minimize Latency.

13. In the Subscription Properties dialog, clickOK.

This adds the subscription to the Subscriptions pane and, if the operation was successful, thestatus of the subscription becomesActive.

14. Right-click the new subscription and select Runtime Status to verify its status.

If you have trouble connecting to the source computer, check that theWindows Firewall on thesource computer allows inbound connections on TCP port 5985 from the collector.

15. To test forwarding, create test events using eventcreate on the source computer.

eventcreate /t error /id 100 /l application /d "Custom event inapplication log"



Export the subscription configurations

If you are replacing amachine in your network, but you want to run both together for some timewithout having to reset Event Log Subscriptionsmanually on the new computer, you can export andre-import all the Event Log Subscriptions settings.

To export subscription configurations

1. From the command line, list the subscriptions.

wecutil es

2. Export the subscriptions.

wecutil gs "<subscriptionname>" /f:xml >>"C:\Temp\<subscriptionname>.xml"

3. Import the subscription.

wecutil cs "<subscriptionname>.xml"

Note: Importing a subscription with a customQueryList doesn't work.

4. (Optional) To use a custom query list, create a subscription as previously described, or import asubscription that uses standard settings.

5. Open the subscription and click Select Events.

6. Click the XML tab, select Edit query manually, and paste it in your customQueryList.

7. ClickOK, thenOK again.

Troubleshooting Subscription Configuration Exports

For basic troubleshooting, see http://windowsitpro.com/security/q-what-are-some-simple-tips-testing-and-troubleshooting-windows-event-forwarding-and-collec.

For amore advanced configuration, see https://technet.microsoft.com/en-us/itpro/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection#how-frequently-are-wef-events-delivered.



http://windowsitpro.com/security/q-what-are-some-simple-tips-testing-and-troubleshooting-windows-event-forwarding-and-collec

http://windowsitpro.com/security/q-what-are-some-simple-tips-testing-and-troubleshooting-windows-event-forwarding-and-collec

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection#how-frequently-are-wef-events-delivered



Using theWindows Event Collector Sensor App


WithWindowsEvent Collector (WEC), you can get events from remote computers and store them ina local event log on a collector computer. For events forwarded from a remote computer (client), thisfunctions through a subscription that receives and stores these events.

USMAnywhere provides theWindowsEvent Collector sensor app, which you can use to set upevent collection through a deployed sensor. You configure theWindowsmachines (clients) toforward the logs to the USMAnywhere Sensor, which works as the collector.

Setup for theWindowsEvent Collector sensor app requires the following

l AWindowsServer 2008 (or newer) host

This is the host that you use to set upWindowsEvent Forwarding to theWindowsEventCollector running on the USMAnywhere Sensor.

l PowerShell 3.0 or newer (required to use the certificate installer script)

l A USMAnywhere Sensor with a private, static IP address, deployed in the same network as theWindowsServer and the client systems that forward logs to the sensor

Download the Certificate

TheWindowsServer needs a certificate to establish a trusted connection between the USMAnywhere Sensor (collector) andWindows instances (clients). This certificate is available todownload as a USM-NXLog-client.pfx file fromUSMAnywhere when you enable theWindowsEvent Collector sensor app.

To download the certificate for the sensor app

1. Navigate to SETTINGS > LOG COLLECTION.

2. In left navigation list, select Windows Event Collector.



3. Select the sensor where you want to use the app.

The app operates through a deployed sensor. If you havemore than one deployed sensor,choose the sensor that is deployed in the same network as theWindowsServer and clientsystemswhere you plan to configure a subscription and log forwarding to USMAnywhere.

4. In the Status tab, click the Download NXLog Certificates link.

Make sure that you save the downloaded certificate to a location where it is available for localinstallation on theWindowsServer.



Install and Configure the NXLog Certificate on the Windows Server

AlienVault provides a PowerShell installer script that you can use to automatically install thecertificates. However, if you prefer to configure thismanually, you can follow themanual procedureto install the certificate on your WindowsServer.

Using the Certificate Installer Script

The NXLogCertificate Installer script is the easiest method for installing the NXLog certificates onyour WindowsServer so that you can configureWindows event forwarding for a USMAnywhereSensor.

To use the installer script

1. In the Status tab, click the Download the NXLog Certificate Installer link.

Make sure that you save the downloaded script to a location where it is available to run locally ontheWindowsServer.

2. On theWindowsServer, execute the script from a PowerShell terminal.

3. At the dialog prompt, select the certificate file.

4. (Optional) Remove previous certificates.

The script automatically asks to remove the previous certificates in the case of an earlier USMAnywhere NXLog installation.

Important: It is highly recommended that you remove the previous certificates to avoidpotential conflicts. The system provides an individual confirmation for each certificate that itwill remove.

When the installation is complete, the terminal window displays a confirmation and providesinformation about next steps to set up event forwarding. This is a summary of the information



provided in Set UpWindowsEvent Forwarding.

Installing the Certificate Manually

If you prefer not to use the provided PowerShell installer script to install and configure the NXLogcertificate on your WindowsServer, you can perform this processmanually. After the initialcertificate installation, use theMicrosoft WindowsHTTP Services (WinHTTP) CertificateConfiguration Tool (WinHttpCertCfg.exe) to complete the configuration of the client certificate.

To install the certificate

1. Copy the downloaded certificate file to theWindowsServer.

2. Double-click the USM-NXLog-client.pfx file.

This launches the Certificate Import Wizard to guide the process.

3. For the Store Location, select the Local Machine.

Note: Windows 2008 does not present the option to import into the LocalMachinecertificate store. For Windows 2008 installations, use the information in the followingMicrosoft document to import the certificate into the LocalMachine certificate store:

https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspx

4. If the wizard prompts you for a password, leave it blank and click Next.



https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspx

5. Select the option to automatically store the certificate and click Next to finish.

To configure the Windows HTTP Services

Important: In order to access the Security event log, the Network Service account must be inthe Event Log Readers group.

1. If you do not already have theWinHttpCertCfg.exe tool on your WindowsServer, download andinstall it.

2. Navigate to the Administrative Tools and open the Computer Management utility.



https://www.microsoft.com/en-us/download/details.aspx?id=19801

https://www.microsoft.com/en-us/download/details.aspx?id=19801

3. Select Local Users and Groups > Groups > Event Log Readers.

4. Right-click the item and choose Add to Group.

5. In the dialog, click Add.

6. Enter NETWORK SERVICE as the object name and click Check Names.



7. ClickOK in the dialogs and then close the Computer Management utility.

8. Give the Network Service account access to the installed certificate:

winhttpcertcfg -g -c LOCAL_MACHINE\my -s USM-NXLog-client -aNetworkService

If winhttpcertcfg is not in the path, youmight find it in C:\Program Files (x86)\WindowsResource Kits\Tools\.

Important: If you add the Network Service account to the Event Log Readers group later,it will require that you grant the account access to the certificate again.

Set Up Windows Event Forwarding

WindowsEvent Forwarding (WEF) reads any operational or administrative event log on a deviceand forwards the events you choose to aWindowsEvent Collector (WEC) server. On the devicethat you set up as an Event Log collector, you configure subscriptions that pull the desired logs fromany number of source computers. No special configuration is required on the source computers,other than thatWindowsRemoteManagement (WinRM) should be enabled, theWinRMWindowsFirewall exceptions be enabled, and the computer account for the collector must have readpermission on the logs that you want to subscribe to.

USMprovides the log forwarding policy that you use to set up theWEF on your WindowsServer.



To get the USM Anywhere log forwarding policy

1. Navigate to SETTINGS > LOG COLLECTION.

2. In the left navigation list, select Windows Event Collector.

3. Select the sensor where you enabled the sensor app.

4. Copy the Log Forwarding Policy that is displayed in the page.

The policy follows this pattern:

Server=HTTPS://PRIVATE_SENSOR_IP:5986/wsman/,Refresh=<REFRESH_INTERVAL_IN_SECONDS>, IssuerCA=<CERTIFICATE_THUMBPRINT>

To configure the policy on your Windows Server

1. On theWindowsServer, navigate to the Control Panel and open the Local Group PolicyEditor.

2. Select Computer Configuration > Administrative Templates > Windows Components> Event Forwarding and then click Configure target Subscription Manager.

3. Click the Edit policy setting link.



4. In the dialog, make sure the subscription ismarked as Enabled.

5. Click Show to open the subscriptionmanagers.



6. Paste the policy that you copied fromUSMAnywhere into the new subscription value field.

7. ClickOK and close the Local Group Policy Editor.

8. Open the terminal and apply the configurationswith the following command:

gpupdate /force



Verify the Event Log Collection

You can verify your event log collection configurations by checking the logs.

To check the event logs

1. On theWindowsServer, open the Event Viewer.

2. Navigate to Applications and Services Logs > Microsoft > Windows > Eventlog-ForwardingPlugin and check for any errors.

You could see warnings if there are any paths that are not configured on your WindowsServers.



If the event log collection configuration is without errors or warnings, you can view the events in theUSMAnywhere Events page.

Enabling AWS Log Collection


AWS sensor CloudWatch Logs can be used to aggregate and store application logs. This providesan easymechanism for transporting log files from your running instances to a place where USMAnywhere can access themwithout having to change any network access settings.

The advantage of CloudWatch Logs is the ability to easily configure additionalmetadata to beprocessed with the log files. It also simplifies the task of moving log files around EC2. But, if you don'twant to use this utility, USMAnywhere also lets youmonitor an S3 bucket, andmove log files thereusing the tools of your choice.

After you've enabled logs, such as S3 and Cloudwatch, USMAnywhere automatically discoversthem and they can start generating events, based on CloudTrail, S3, ELB Access, and other securitylogs.

After deployment, all of the USMAnywhere out-of-box logs you see in the SetupWizard aredisabled by default. To start log collection jobs for the logs of your choice, youmust enable them onthis page.

To enable out-of-box logs in USM Anywhere

1. Choose SETTINGS > SCHEDULER to open the Job Scheduler page.

2. Locate the jobs you want to enable to collect events or asset information and click thedisabled icon ( ).

This turns the icon green ( ). To disable an already enabled job, toggle the icon to its

original status.

Enabling AWS LogCollection


Installing osquery and CloudWatch Through the Log Agent

The Log Agent is a wrapper convenient for installing third-party software with USM-specificconfigurations that collect and transmit system events and logs on Linux systems.

The Log Agent detects your distribution and version of Linux, and decides if it's supported.

Note: If you prefer amoremanual approach to installation, see Collecting Logs from LinuxUsing osquery.

Supported Linux Distributions

TheUSMAnywhere Log Agent installer supporting osquery and an AWS CloudWatch configurationis available for the following Linux distributions and versions.

Distribution Version

Ubuntu 12.04 Precise

14.04 Trusty

16.04 Xenial

RHEL 6.6

6.7

6.8

7.1

7.2

7.3



Distribution Version

CentOS 6.6

6.7

6.8

7.0

7.1

7.2

7.3

About the osquery and CloudWatch Log Agent

osquery

After distribution and version verification, the Log Agent installs osquery for S3 fromAWS.

It creates a custom osquery.conf file that queries the following useful set of events:

l file_events

l users

l listening_ports

l crontab

l kernel_modules

l processes

l yara_events (Currently, we don't install any yara configuration; this is for future development.)l suid_bin

l outbound_connections

Additionally, the Log Agent installs python and pip on Ubuntu 16+, if not already installed.

CloudWatch

The Log Agent assembles a distribution-specific CloudWatch configuration file with the followingLogGroupmappings:

File Log Group Name Caveats

/var/log/osquery/osqueryd.results.log osquery-Logs

/var/log/auth.log Linux-Auth-Logs Ubuntu only

/var/log/secure Linux-Auth-Logs All other Linux distributions

/var/log/apache/access.log Apache-Access-Logs



File Log Group Name Caveats

/var/log/httpd/access_log Apache-Access-Logs All other Linux distributions

/var/log/audit/audit.log Linux-Audit-Logs

All log streamswithin the groups are created using the AWS instance id.

Note: If you have installed your Apache or other web servers to nonstandard locations, the LogAgent won't discover them.

The Log Agent downloads and runs the AWS CloudWatch Logs Agent installer from the AWS S3page for your platform and distribution's directory.

Important: Make sure that the VMwhich you're running the Log Agent installer on hasconnectivity to that download page.

Log Agent Instance Prerequisites

l The instancemust

o Be one of the supported Linux distributions.

o Have an IAMRole with the proper policy to allow it to publish to CloudWatch logs.

o Have at least temporary internet access, so it can get to the Linux distribution repositories:

n osquery repository

n AWS CloudWatch log agent installation endpoint

l The default CloudWatchmonitoring jobs created in the USMAnywhereScheduler should havealready been enabled within the USMAnywhere web interface.

l Youmust have root permissions or be able to perform sudo elevation to run the script. The scriptaccepts no command-line arguments nor does it interact with users.

Installing the Log Agent

To install the Log Agent

1. Download the tarball from the distribution website (http://downloads.alienvault.cloud/usm-anywhere/usma-logagent-linux/usma-logagent-linux-latest.tgz).

2. Upload and extract the tarball in a convenient directory on the target host, and go to the sub-directory created (for example, usma-logagent-0.999/).

3. Run the script as root or perform passwordless sudo elevation, for example:

sudo ./LinuxConfigurationScript.sh




http://downloads.alienvault.cloud/usm-anywhere/usma-logagent-linux/usma-logagent-linux-latest.tgz

http://downloads.alienvault.cloud/usm-anywhere/usma-logagent-linux/usma-logagent-linux-latest.tgz

After the CloudWatch agent starts, it begins publishing logs to the CloudWatch LogGroups,where USMAnywhere's default scheduled jobs detect them. You can expect new events to takefrom 5 to 10minutes to show up in the USMAnywhere webUI.



Configuring Network Interfaces for On-Premises Sensors

A USMAnywhere Sensor deployed on VMware or Hyper-V uses five network interfaces. Thesenetwork interfaces have a predefined role that cannot be changed. The USMAnywhereManagement Interface is required for many essential functions.

l Connection to USMAnywhere

l Updates to the system

l Log collection within themonitored network

l Vulnerability scans

l Asset discovery

This interface needs an IP addresswith permissions to access

l Inbound packets containing syslog data sent from other hosts on that network

l Outbound connectionsmade to perform authenticated scans

The other interfaces passivelymonitor network traffic in promiscuousmode; the system does allowthe configuration of an IP address on them. These interfaces should be plugged into a port in theswitch where port mirroring is configured.

Interface Name Network Configuration Required

Management Interface Internet connectivity and IP address routed to provide the access to USMAnywhere

This IP address also allows connections to assets in a monitored network forlog collection and asset scans.

Network MonitoringInterface 1

Interface connected to a mirrored port in the network switch







Network Interfaces

Important: The VMware sensor and Hyper-V sensor require all five NICs to be enabled.

You should connect each of the additional NICs to any additional network you want to monitor,or to a dead/inactive network. All five NICsmust be associated to some network (active orinactive) to allow successful update of the sensor. Do not configure the additional NICs to thesame SPAN port, because this will cause duplicated events.



https://en.wikipedia.org/wiki/Port_mirroring

Use the functions provided by the sensor console to configure themanagement interface and DNS.

Setting Up the Management Interface

USMAnywhere has, by default, DHCP and Log Collection enabled.

Configuring the Interface Automatically Using DHCP

During the installation, your system sets an IP address assigned by a DHCP Server.

Note: Check your settings on Network Configuration > View Network Configuration.

Configuring the Interface Manually

1. Connect to the USMAnywhere Sensor console.

2. Navigate to the Network Configuration > Configure Management Interface > Set a StaticManagement IP Address option.

3. Type the IP Address.


Defining the DNS Nameservers

The DNS nameserver is part of the Domain NameSystem (DNS) that maintains a directory ofdomain names and translates them to IP addresses.

Important: If you specify two servers for DNS resolution, USMAnywhere determines theirpriority by their order. Configure your local DNS in the first position to have DNS nameresolution in your internal network.

To define the DNS Nameservers

1. Connect to the USMAnywhere Sensor console.

2. Navigate to Network Configuration > Configure DNS.


4. Optionally, you can provide the secondary DNS and press Enter (OK).

A confirmation screen appears to apply changes.




Creating a Firewall Rule for Communication Between Sensor and Cloud Service

USMAnywhere is hosted as a cloud service with an IP address that is not statically assigned andmay change periodically. For this reason, youmust set up a firewall rule that uses the DNS of thecloud service to allow incoming / outgoing traffic between the USMSensor and the cloud service.

In this example, the DNS for the USMAnywhere instance is displayed within the green box.

Checking Your Settings

You can verify your network settings in the USMAnywhere Sensor Setup wizard or through thesensor console.

Sensor Setup Wizard

To verify the network settings in the USM Anywhere Sensor Setup wizard

1. Select SETTINGS > SENSORS and click the sensor name.

2. At the bottom of the sensor page, click the NETWORK IDS tab, where you can view the traffic inyour network over various interfaces.

On this tab, you can also configure a new interface or you can configure port mirroring. SeeDevice Port Mirroring Configuration for more information.

Sensor Console

To verify the network settings in the USM Anywhere Sensor console

1. Connect to the sensor console.

2. Navigate to the option Network Configuration > View Network Configuration.



Getting Ready for Authenticated Scans

Before you can run an authenticated scan, youmust perform a series of preparatory tasks,depending on your operating system.

Configuring MS Windows for Authenticated Scans

Requirements:

l Network connectivity between the USMAnywhere instance and port 5985

l TheWindows host must accept remote connects for theWindowsRM service

To start the Windows RM service

l Open aWindows command prompt and run the command winrm qc; accept the default settings.

This command starts theWindowsRM service and configures a listener for the port 5985.

You're now ready to add a new credential specifically for scans of theMS Windows operatingsystem.

For more information aboutWinRM, see https://msdn.microsoft.com/en-us/library/aa384372(v=vs.85).aspx and https://blogs.technet.microsoft.com/jonjor/2009/01/09/winrm-windows-remote-management-troubleshooting/.

Configuring Linux for Authenticated Scans

Requirements

l OpenSSH server must be installed on your Linux host.

l Network connectivity between the USMAnywhere Sensor and the port SSH is running on theLinux host.

Installing the OpenSSH Server

Refer to the vendor documentation for your Linux distribution for instructions on how to install andconfigure OpenSSH Server.

l Redhat — https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-ssh-configuration.html

l Fedora — https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/ch-OpenSSH.html

l Ubuntu — https://help.ubuntu.com/community/SSH/OpenSSH/Configuring

l Debian — https://wiki.debian.org/SSH

l FreeBSD — https://www.freebsd.org/doc/handbook/openssh.html

Next...



https://msdn.microsoft.com/en-us/library/aa384372(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/aa384372(v=vs.85).aspx

https://blogs.technet.microsoft.com/jonjor/2009/01/09/winrm-windows-remote-management-troubleshooting/

https://blogs.technet.microsoft.com/jonjor/2009/01/09/winrm-windows-remote-management-troubleshooting/

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-ssh-configuration.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-ssh-configuration.html

https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/ch-OpenSSH.html

https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/ch-OpenSSH.html

https://help.ubuntu.com/community/SSH/OpenSSH/Configuring

https://wiki.debian.org/SSH

https://www.freebsd.org/doc/handbook/openssh.html

Before you can conduct a vulnerability scan, youmust first create a credential to identify yourself toUSMAnywhere each time you want to perform a scan. For information about these credentials, seein the USMAnywhere User Guide.



Granting Access to Active Directory for USM Anywhere

If you want to configure scans of the Active Directory byUSMAnywhere, you need to grant it accessto the Active Directory server.

This consists of two tasks:

l Creating a dedicated USMAnywhere account in Active Directory. This is used byUSMAny-where to log into the virtual machines to perform a scan.

l ActivatingWinRM in the Domain Controller and in all the hosts you want to scan.

Creating a Dedicated AD Account

To create a new dedicated account in AD

1. Log into your Domain Controller administrator's account.

2. Open Active Directory Users and Computers.

3. Create a new user called either alienvault_usm or any other name that's easy to associatewith USMAnywhere.

4. Add the user you’ve just created to the Domain Admins group.

ActivatingWinRM to EnableWindows PowerShell Remoting

To activateWinRM, you can use a group policy to combine the Domain Controller and all the hosts inyour Active Directory. (For reference, see Enable and configureWindowsPowerShell Remotingusing Group Policy in the blog powershell.no.)

Alternatively, if you prefer to activateWinRMmanually in each system you want to scan, see theWinRMprocedure in Getting Ready for Authenticated Scans. This activates aWindowsRM listeneron port 5985.

Granting Access to Active Directory for USMAnywhere


Getting Traffic from Your Physical Network to the Virtual USMAnywhere Network

This topic describes how tomove traffic from your on-premises sensor and other physical networkartifacts to the USMAnywhere virtual network.

This procedure assumes that you have already completed the following:

l Allocated a spare NIC on your VMware host to pass the SPAN port traffic from the physical net-work to the virtual network.

l Plugged the spare NIC into a SPAN (mirror) port on your switch.

Important: We recommend that you SPAN all internal and DMZ firewall ports. This includes allswitch ports to which the firewall internal interfaces connect and the port used by the NIC, towhich the VMware host connects.

To configure your virtual network and USM Anywhere

1. Configure a new Standard vSwitch specifically for the SPAN target:

l Select the ESX Host in the vSphere client.

l Select Configuration and click Add Networking, in the upper right-hand corner.

l For the Connection Type, select Virtual Machine.

l Select Create a vSphere standard switch andmake sure that the spare NIC is associatedwith the switch.

l In Port Group Properties, create a new Network Label called "SPAN Target."

Important: It is important to create a new vSwitch dedicated to the SPAN target.Adding a promiscuous port group to an existing vSwitchmay cause instability in thehypervisor.

2. Configure the vSwitch to allow promiscuousmode:

l Click Properties, located next to the new vSwitch.

l Select the vSwitch and click Edit.

l Set PromiscuousMode to Acceptand clickOK.

l Select the SPAN Target port group andmake sure that the default security policy permitspromiscuousmode there aswell.

Getting Traffic fromYour Physical Network to the Virtual USMAnywhere Network


3. Select the Network Adapters tab; make sure that your spare NIC is associated with thevSwitch.



4. Click Close from the vSwitch properties dialog.

5. Edit the USMAnywhere Sensor virtual machine and add a new Ethernet adapter.

6. Associate the adapter with the SPAN Target network and save your changes.

7. Log in to the USMAnywhere Sensor console and select Restart from the systemmenu.




Managing Jobs in the Scheduler


The Job Scheduler page provides a list of all jobs that are defined in your USMAnywhere instance.Many jobs are predefined (out-of-the-box) items for log collection and asset scans, and some ofthese require enablement in order to run according to the defined schedule. You can also defineyour own jobs to schedule automatic log collection, asset scans, and asset group scans, aswell asjobs to performSensor App and AlienApp functionality. For more information about schedulingsome of these job types, see the following topics:

l Configuring the AlienApp for McAfee ePO in the USMAnywhere AlienAppsGuide

l Scheduling a Forensics and Response Job

For a deployed AWS sensor or Azure sensor, USMAnywhere automatically discovers a number ofout-of-box logs as long as you have enabled themwithin your AWS or Azure subscription. For morespecific information about these log types and default jobs, see AWS LogDiscovery and Collectionin USMAnywhere and Azure Log Discovery and Collection in USMAnywhere.

Enabling Standard Log Collection and Scan Jobs

Whenmost logs in your account are enabled, USMAnywhere automatically discovers them andthey can start generating events, based on CloudTrail, S3, ELB Access, Azure Security Event logs,and others.

But, because all of the USMAnywhere out-of-box log and asset scan jobs deploy disabled initially,youmust decide which jobs you want to activate and enabling them.

To enable scheduled jobs in USM Anywhere


2. Locate the jobs you want to enable to collect events or asset information and click the disabledicon ( ).

This turns the icon green ( ). To disable an already enabled job, toggle the icon to its

original status.



Adding a New Job to the Scheduler

USMAnywhere includes defined jobs to performmany of the standard log collection and scanningactions that you will need tomonitor your networks. These jobs are predefined to run using arecurrence according to industry best practices. However, if you need to define a scheduled job toperform log collection, asset scans, or asset group scans, you can add a new job directly on the JobScheduler page.

To create a new job


2. At the top-right of the page, click New Job.

l If Log Collection is selected on the left, this button is labeled Create Log Collection Job.This limits the options in the dialog to those that define a log collection job.

l If Asset Scans or Asset Group Scans is selected, this button is labeled Create Scan Job.This limits the options in the dialog to those that define an asset scan or asset group scan job.



4. Use the Select App option to select the app used to run the job.

5. Use the AppAction option to select the job to run.

The selected app determines the actions that are available.





7. Click Save.



Collecting Windows System Data with the Forensics andResponse Sensor App


The Forensics and Response sensor app lets you collect system data on a remoteMicrosoftWindowsmachine to provide forensic information during the incident response process.

You can also use the Forensics and Response app to launch actions on a remoteWindows systemtomitigate an incident or contain a threat, such asmalware. You can automatically trigger theseactions using orchestration rules, and themost common ones are exposed as actionswhen you usethe app. (For information about creating orchestration rules, seeOrchestration Rules in the USMAnywhere User Guide.)

Edition: The Forensics and Response sensor app is available in the Standard and Enterpriseeditions of USMAnywhere.


Requirements

l Most actions require Powershell, v 3 or above, to function properly.

l Any asset that you want to querymust have credentials in USMAnywhere.

Scheduling a Forensics and Response Job

You schedule a Forensics and Response job in the sameway you do any other type of job.

To schedule a Forensics and Response app job

1. In USMAnywhere, go to SETTINGS > LOG COLLECTION and select Forensics andResponse App under Sensor Apps.

Note: You can also start a job from the SCHEDULER. For more information about addingandmodifying jobs in the Scheduler, seeManaging Jobs in the Scheduler.

2. Select the Sensor you want to use to run the query .

CollectingWindowsSystemData with the Forensics and Response Sensor App



3. Select the ACTIONS tab.

4. On the right side of the page, click Schedule Job.

This opens the Schedule New Job dialog with many of the options already defined for theForensics and Response app job.



6. Click the App Action list and select the command you want to run.



7. In the Asset field, start typing the name of the asset that you want to run the query against.

The dialog preforms amatch of the character string to fill in the value for the asset name. If youare unsure of the asset name, you can click the Select from list link to expose a list of assets andmake your selection.








9. Click Save.



PluginManagement

USMAnywhere plugins are software components that provide logic specific to extracting data fromraw logs produced by external devices, operating systems, and applications. A plugin enriches thecollected data with security-specificmetadata to produce an event managed byUSMAnywhere.

Within the USMAnywhere environment, a plugin has a specific scope of functionality:

l Performs a singular function to translate raw log data into normalized events for analysis byUSMAnywhere

l Does not collect log data or perform threat analysis

l Serves only as the translationmechanism for the data after collection by the USMAnywhereSensor

Note: Plugins are different fromAlienApps™. Plugins have a singular function to translate rawlog data into normalized events for analysis byUSMAnywhere, but AlienApps domuchmore,including collecting and enriching log data, performing threat analysis, and providing workflowthat coordinates response actionswith the infrastructure and third-party applications to providesecurity orchestration.

USMAnywhere Plugin Operations 240

Manual PluginManagement 245

Requesting a New Plugin or an Update to an Existing Plugin 249


USM Anywhere Plugin Operations

A USMAnywhere plugin is a software component that provides logic specific to producingnormalized event data from the raw data received from an external data source. The plugin parsesthe raw data and converts it into common event fields, such as user, date and time, and source ordestination IP address, so that USMAnywhere canmanage the information as a security event.With a normalized event, USMAnywhere can display information uniformly and correlate eventsfrom various individual systems to generate alarms.

USMAnywhere provides numerous plugins that translate log data from common devices, operatingsystems, and applications.WhenUSMAnywhere receives the raw log data, it must identify a pluginto use for normalization. Many data sources produce syslogmessages that contain information thatcan be used to identify the device or application that produced themessage. Others data sourcesproduce log data that requiresmore guidance to identify amatch for the data.

Auto-discovered Plugins

In USMAnywhere, many plugins can be identified andmatched to the log data automaticallybecause of hints — unique information within a syslogmessage that identifies the data sourcesending the logs. These hints allow the syslogmessage to be read and the plugin type to beidentified when the hintsmatch the criteria set for each plugin type. Therefore, if a plugin acceptshints, USMAnywhere can automatically identify it as amatch for a syslogmessage.

When you review plugin details in USMAnywhere, these plugins are designated withAutodiscovered = YES.

Manual Plugins

Not all plugins accept hints, because some syslogmessages contain only generic data. For hints towork, syslogmessagesmust contain unique information. For this reason, USMAnywhere canneither automatically identify those plugins nor ready their syslog data. These plugins require adefinedmatch in USMAnywhere by associating the asset with the plugin or by associating the pluginwith an asset.

When you review plugin details in USMAnywhere, these plugins are designated withAutodiscovered = NO.

With one or moremanual plugin associations for an asset, it is possible for the wrong plugin to beinvoked for parsing and normalizing a logmessage. This typically happens if the needed plugin is notincluded in the list of manually associated plugins.

Important: If you create amanual plugin association for an asset and that asset producesmultiple log types that require processing bymore than one plugin, youmust create amanualassociation for each plugin, including auto-discovered plugins. Any specified plugin associationfor an asset disables the use of hints and only specified plugins are considered for parsing andnormalizing a logmessage.

USMAnywhere Plugin Operations


For detailed instructions about how to associate these plugins with an asset or asset group, seeManual PluginManagement.

The Generic (Fuzzy) Plugin

Occasionally, a log line does not match either amanually enabled or an auto-discovered plugin. Thisis typically caused by devices that generate non-standard syslogmessages. Because they put non-standard date formats or other information in the syslog HEADER, the USMAnywhere syslog parsingcode is unable to properly extract the tag header. In some cases, you canmodify the loggingconfiguration on the device to produce a better result.

In these caseswhere amatching plugin is not available, USMAnywhere parses it using the fuzzyplugin. The fuzzy plugin is a generic plugin that can be used to parse the log line using RegularExpressions and advanced text searches, including the following keywords:

l get

l device

l to

l src

l srcip

l source

l client

l loc_ip

l rem_ip

l from

l dst

l dstip

l destination

l Remote-Address

l netsession

l session

l zone

l interface

l unique_id

l log_id

l device_id

l id

l message



l msg

l proto

l reason

l tag

l action

l sport

l src_port

l srcport

l spt

l loc_port

l rem_port

l dpt

l dport

l file

l virus

l user

l Username

l to

l from

l name

l initf

l outif

l srcmac

l dstmac

l get

l device

l to

l src

l srcip

l source

l client

l loc_ip

l rem_ip

l from



l dst

l dstip

l destination

l Remote-Address

l netsession

l session

l zone

l interface

l unique_id

l log_id

l device_id

l id

l message

l msg

l proto

l reason

l tag

l action

l sport

l src_port

l srcport

l spt

l loc_port

l rem_port

l dpt

l dport

l file

l virus

l user

l Username

l to

l from

l name



l initf

l outif

l srcmac

l dstmac

After it scans for key phrases, it starts looking for patternswithin the log. It typically looks for thesepatterns:

l <zone>sep<IP>sep<port>

l <IP>sep<port>sep<zone>

l <IP>sep<port>

Where separators can be one of the following:

: = , ; [ ] / \n

If USMAnywhere uses this best-effort plugin to parse a log line, it adds a Was Fuzzied = Truefield to the event within the Events (ACTIVITY > EVENTS) page. For more information aboutfiltering the page to display these events, see About the 'Was Fuzzied' Filter in the USMAnywhereUser Guide.



Manual Plugin Management


If USMAnywhere receives syslog log data from an external data source (device, application, oroperation system) and that data is not automaticallymatched with a plugin through hints (see Auto-discovered Plugins), youmust manually associate the required plugin with the asset in USMAnywhere. There are twomethods for creating these associations:

l Manage the plugin by adding one or more assets that require that plugin for parsing and nor-malizing log data.

l Manage an asset by adding one or more plugins that are needed for parsing and normalizing logdata.

You can use a combination of thesemethods to ensure that USMAnywhere can identify the correctplugin(s) for the log data it receives from an asset.

Important: If you create amanual plugin association for an asset and that asset producesmultiple log types that require processing bymore than one plugin, youmust create amanualassociation for each plugin, including auto-discovered plugins. Any specified plugin associationfor an asset disables the use of hints and only specified plugins are considered for parsing andnormalizing a logmessage.

Manual PluginManagement


Adding Assets to a Plugin

Adding assets to a plugin requires that you know the data sources that are the best match for theplugin and which assets produce the log data that is received by the USMAnywhere Sensor.Identifying the best match could take some experimentation with the plugin to determine how itparses and normalizes data and if it producesmeaningful events for your needs.

In theManage Plugins page, you can review the plugins and determine which plugins are currentlyin use for your USMAnywhere environment.

To add an asset to a plugin

1. In USMAnywhere, choose SETTINGS > LOG COLLECTION.

2. On the left side of the page, clickManage Plugins.

3. Locate the plugin you want to associate with an asset and click theWrench icon ( ) in the

plugin row.

You can enter text in the search box and click theMagnifying Glass icon ( ) to filter the plugin

list.

4. In the Add Assets dialog, select the asset to assign to the plugin.



The dialog displays any assets that are already assigned to the plugin.

Enter part of the asset name in the SET A NEW ASSET field and select the asset from thedisplayed list.

The system displays a confirmation of the add function.

Plugin added successfully

5. (Optional) Repeat the previous step to add another asset.

6. Click the Close icon ( ) in the dialog.

Adding Plugins to an Asset

Adding a plugin to an asset requires that you know what log data that the USMAnywhere Sensorreceives from the asset and which plugin(s) are the best match for parsing and normalizing that datato producemeaningful events for your needs.

For more information about managing discovered assets in USMAnywhere, see AssetManagement in the USMAnywhere User Guide.

To add a plugin to an asset

1. Select ENVIRONMENT > ASSETS.

2. (Optional) Use the Search & Filters options to filter the list and help you to locate the asset youwant.

3. Click the icon ( ) next to the asset name and select Full Details.



This displays the Asset Details.

4. At the bottom of the page, select the Plugins tab and click Add Plugin.

5. In the dialog, select the plugin to use for log data from the asset.

Enter part of the plugin name in the SET A NEW PLUGIN field and select the plugin from thedisplayed list.



The system displays a confirmation of the add function.

Plugin added successfully.

6. (Optional) Repeat the previous step to add another plugin for the asset.

7. Click the Close icon ( ) in the dialog.

In the Asset Details you can now see that the asset has an associated plugin.

Requesting a New Plugin or an Update to an Existing Plugin

AlienVault builds or updates plugins at the request of customers for products and devices availableto the general public. To take advantage of this, customersmust have an active AlienVault SupportandMaintenance contract.

This policy does not apply to plugins for custom software or devices.

For information on the plugins we deliver out of the boxwith USMAnywhere, see this list of plugins.

Before Submitting Your Request

Themore information we receive from you, the faster we can build the plugin and themore accurateit will be.

A complete plugin request includes:

l Product’s vendor, model, and version.

l A description of the formatting of the product's logs. For more universal plugin application,choosing a standard event format such as the Common Event Format (CEF) is preferable, if it isavailable and suitable to your needs.

Youmay also want to consider using the product's default log settings in defining which fields tolog. However, if a product has a particular logging configuration that you want the plugin tosupport, you should include that in your request.

l A description of how you use the product, including which events and which data inside thoseevents provide themost relevance to your business.



https://www.alienvault.com/docs/data-sheets/usm-anywhere-plugins-list.pdf

https://community.saas.hpe.com/t5/ArcSight-Connectors/ArcSight-Common-Event-Format-CEF-Guide/ta-p/1589306

l Specific log samples or database dumps of relevant device events. For best results, exclude anyextraneous noise from the log samples, while still retaining all the data needed to differentiate thevarious events you want to capture with a plugin.

l If you need information other than the date, source, destination, username, and protocol extrac-ted from the logs, specify this in your request, and provide an example. This helps us test the plu-gin tomake sure it can successfully extract that data.

l Use case for the new plugin and the business value of the application or device to your organ-ization. This information helps us assign a priority to your request.

After you have collected the information, click here to submit your request.



https://www.alienvault.com/documentation/usm-anywhere/deployment-guide/plugin-management/request-plugin.htm

Troubleshooting and Remote Sensor Support

UseRemote Support to allow the AlienVault Technical Support team to access and diagnose thecomponents identified in a support ticket. USMAnywhere offers remote technical support throughthe USMAnywhere Sensor console. All data exchanged with AlienVault Support is encrypted forsecurity. The information exchanged is only available to AlienVault Support and Engineering teams.

Typically, you open a ticket with AlienVault Support first and only establish a remote supportconnection upon their request. You can establishmultiple sessions using the same ticket number fordifferent sensors. But a support engineer could ask you to open a new ticket if it is an unrelatedissue. During the remote support session you can communicate with the AlienVault TechnicalSupport team by phone or email at any time.


Checking Connectivity to the Remote Server


Before you can connect with AlienVault Technical Support remotely, you need to verify yourconnection to the Remote Support server from the sensor. The USMAnywhere Sensor uses port 22for SSH communicationswith the USMAnywhere Remote Support server. If there is an issue withyour connectivity, make sure that port 22 is open to prod-usm-saas-tractorbeam.alienvault.cloud for the sensor. If the ports are open and you still have noconnectivity, check for any other physical problem on your side. If none are found, contact AlienVaultTechnical Support to find out if their server is temporarily down.

To check the network connectivity for the sensor

1. While logged in to USMAnywhere, check your networking status by going to SETTINGS > Sys-tem.

2. If you havemore than one deployed sensor, select the sensor that you want to verify.

If the page reports that this endpoint is unreachable, youmay have a problem.

To verify remote support connectivity directly on the USM Anywhere Sensor

1. Use SSH to log into the USMAnywhere Sensor console.

2. From the USMAnywhere Sensor console System Menu, select Maintenance and press Enter(<OK>).



3. From theMaintenancemenu, select Remote Support and press Enter (<OK>).

4. From the Remote Support menu, select Show Remote Support Status, press the arrow-down(↓) key, and then Enter (<OK>).

The system displays an alert message that the check is in progress.

When the check is complete with a connection, you see a success alert.

If there's no connection, the system displays an alert message that the remote server isunreachable.



Note: If the system doesmake a connection, you see a success prompt.

5. Press Enter (<OK>).

Creating a Remote Support Session

After you confirm that you have a connection to AlienVault Technical Support, you're ready to start asession.When AlienVault Technical Support Representatives complete their work on an issue, theycommunicate the results to you by email and update your ticket.

To enable remote sensor support

1. Start an SSH session to the USMAnywhere Sensor that you want AlienVault Technical Sup-port to diagnose.


3. From theMaintenancemenu, select Remote Support and press Enter (<OK>).



4. From the Remote Support menu, select Enable Remote Support and press Enter (<OK>).

5. On the Enable Remote Support screen, enter the eight-digit ticket number and press Enter(<OK>).

Important: Be careful not to enter any spaces before or after the number or the operationwill fail.

A progress bar appears and your request begins processing, whichmay take several seconds.

When the connection is established with the Support server, the system displays a connectionmessage.

Connected to AlienVault Support. Press Enter to continue.

6. Press Enter.



TheUSMAnywhere Sensor console returns you to the to the Remote Support screen.

7. To disconnect after your session is done, select Disable Remote Support and press Enter(<OK>).

TheManage Connectivity information screen appears and prompts you to confirm.

Are you sure you want to disconnect from AlienVault Remote Support?

8. Select Yes.

The screen goes black and, after several seconds, you receive a notification that the secureconnection is now disconnected. You can then back out of the previousmenus and close thesensor console.

Collecting Debug Information

When you open a ticket with AlienVault Support, you can include collected debug information toassist the support engineer with diagnosing your issue. The USMAnywhere Sensor consoleprovides a function that you can use to collect this information.

To collect debug information for the sensor

1. Start an SSH session to the USMAnywhere Sensor that you want AlienVault Technical Sup-port to diagnose.


3. From theMaintenancemenu, select Collect Debug Information and press Enter (<OK>).



4. In the confirmation screen, select Yes and press Enter (<OK>).

When the collection process is complete, you see an alert message. This provides the URL forthe file and the password.

5. Press Enter (<OK>).

6. Download the debug file and attach it to your support case.

Make sure to update the support case information to include the file password.



AlienVault® USM (Unified Security Management) Anywhere ...

Documents

Transcript of AlienVault® USM (Unified Security Management) Anywhere ...