USM Anywhere Environment Settings. AlienVault USM Anywhere

USM Anywhere Environment Settings

The Setup Wizard helps first-time users configure USM Anywhere security capabilities within minutes. 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 tasks you must perform in your network to ensure that USM Anywhere is receiving l

Network firewall allows communication with USM Anywhere.

l

Operating system forwards all relevant logs to USM Anywhere.

USM Anywhere™ Deployment Guide 480

Log Management

Log Management

USM Anywhere collects third-party device data through syslog on port 514 by default. To configure any third-party devices to send data to USM Anywhere, you must give them the IP address of your

USM Anywhere Sensor and the port number.

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 on (SETTINGS > DEPLOYMENT >

Sensor Apps > Syslog Server). However, be aware that if you change this in

USM Anywhere, you also need to configure your third-party device to use the new port number.

Remote Log Data Transfer on a Platform or Third-Party Device l

Log collection from a Linux System —

Collecting Logs from a Linux System .

l

Log collection from a Windows System —

Collecting Logs from a Windows System

.

l

Log collection from AWS —

Enabling AWS Log Collection

.

l

Log collection from other devices using a plugin —

USM Anywhere Plugin Integration and Enablement .

Disabling the Syslog Server App

The Syslog Server app is enabled by default. There is no action needed from the user for enablement. However, if you want to disable it for some reason, follow this procedure.

To disable log data receipt from third-party devices

1. From the USM Anywhere web UI, choose SETTINGS > DEPLOYMENT to open the

Deployment page.

2. Under Sensors, click Syslog Server.

3. On the STATUS tab, select SENSOR:<SENSOR_TYPE> and click DISABLE.

File Integrity Monitoring

File integrity monitoring (FIM) is a mechanism for validating the integrity of operating system and application software files using a verification method between the current file state and a known, good baseline. It is one of the most powerful techniques used to secure IT infrastructures and business data against a wide variety of both known and unknown threats.

481 USM Anywhere™ Deployment Guide

File Integrity Monitoring

FIM for Linux

For Linux systems, you can enable FIM within USM Anywhere by configuring the osquery agent to monitor and track file changes on those systems. The osquery configuration file (typically named osquery.conf

) contains the configuration options and queries that osquery uses when it runs.

AlienVault provides a default configuration file that you can use to enable FIM for Linux systems in your USM Anywhere environment to identify system and software file changes and forward this information to the USM Anywhere Sensor.

For more information about installing and configuring osquery on your Linux systems, see

Collecting

Logs from Linux Using osquery

.

FIM for Windows

For Windows systems, you can use FIM to identify changes in system files, folders, and Microsoft

Windows registries. To use FIM, you configure Windows systems so that USM Anywhere can view

Windows audit object access events. To do so, you need to enable file auditing and update security policy settings. After applying policy changes to include audit object events in Windows security logs,

NXLog will forward those events to the USM Anywhere Sensor.

See

Collecting Logs from a Windows System

 for detailed information about using NXLog to forward these events.

Configuring Policy Settings for Object Access Audit Events

Local Policies determine the security options for a user or service account. Local policies are based on the computer and the rights for the account on that computer. Local Policies can be used to configure an audit policy, which determines which security events will be logged into the Security log on the computer (successful attempts, failed attempts, or both). This Security log is accessible from the Event Viewer.

To define local group policy settings for object access audit events

1. On a selected Windows system, open the Local Group Policy Editor.

2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local

Policies > Audit Policy.

USM Anywhere™ Deployment Guide 482

File Integrity Monitoring

3. Open the Audit object access policy.

4. In the dialog, select the Success and Failure check boxes to enable auditing.

483

5. Click Apply and then OK.

USM Anywhere™ Deployment Guide

File Integrity Monitoring

Configuring Policy for File Auditing in the Active Directory Domain

In order to track file system changes on a Microsoft Active Directory Domain so that USM Anywhere can view Windows audit object access events, first you must set the Windows group policy to keep track of file system changes.

The following example uses the default domain controller policy in order to track changes on a domain controller. Your actual policy might be different, depending on your particular domain configuration.

To audit changes on a domain controller

1. From the Server Manager, open up Group Policy Management, and expand the domain to select 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 settings option to enable it.

This allows the more granular advanced audit policy settings instead of the general categories that 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 to make sure 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.

USM Anywhere™ Deployment Guide 484

File Integrity Monitoring

485

6. Verify that the Group Policy you just edited is enforced, and applied to the domain per your particular 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 you want to monitor. You might 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 you expect 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. Open Windows Explorer and navigate to the file or folder you want to audit.

Note: Because the Windows security log is limited in size and new audit events will be stored there, select the files and folders to be audited carefully. Also, consider the amount of disk space that you want to devote to the security log. The maximum size for the security log 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.

USM Anywhere™ Deployment Guide

File Integrity Monitoring

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 select field, enter the name of the user or group that you want to audit and click OK.

l

To remove auditing for an existing group or user, select the group or user name, click

Remove, and click OK. 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.

USM Anywhere™ Deployment Guide 486

File Integrity Monitoring

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. For

FIM 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 inheriting audit settings, select the Apply these auditing entries to objects and/or containers within this container only option.

9. Click OK.

Testing and Viewing Events

After enabling object access auditing, you can view the security log in the Windows Event Viewer to see that the audit events are now collected. You can test to make sure the events are properly generated in Windows Event viewer by creating a file, editing it, moving it out of the folder, and then moving it back in. This should generate the events in the Event Viewer of a Windows Server, looking like the following example:

487 USM Anywhere™ Deployment Guide

File Integrity Monitoring

When NXLog is set up to forward these events to the USM Anywhere Sensor, these audit events are available in your USM Anywhere environment.

USM Anywhere™ Deployment Guide 488

Collecting Logs from a Linux System

Collecting Logs from a Linux System

The use of syslog is required to send log data from Linux systems to the USM Anywhere Sensor

IP address over UDP on port 514. If you want to gain more visibility and use File Integrity Monitoring

(FIM) in your Linux systems, USM Anywhere also supports osquery by default.

Using syslog to Send Logs From a Linux System

Syslog is an industry standard message logging system that is used on many devices and platforms.

It provides a mechanism for network devices to send event messages to a logging server, also known as a Syslog server. For example, a router might send messages about users logging on to console sessions, while a web server might log access-denied events.

Follow the procedure that corresponds to the Linux distribution you use:

Fedora Linux Distribution

You must have sudo privileges to complete this procedure.

To send logs from Fedora Linux using syslog

1. On your Linux machine, 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

You must have sudo privileges to complete this procedure.

To send logs from Red Hat Enterprise Linux using syslog

1. On your Linux machine, 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:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

3. Restart rsyslog: sudo service syslog stop (only for RHEL-5) sudo service rsyslog restart openSUSE Distributions

You must have sudo privileges to complete this procedure.

489 USM Anywhere™ Deployment Guide

Collecting Logs from a Linux System

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 Linux machine, open

/etc/rsyslog.d/remote.conf

and add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

4. Restart rsyslog: sudo service rsyslog restart

Debian GNU/Linux and Ubuntu Distributions

You must have sudo privileges to complete this procedure.

To send logs from Debian GNU/Linux and Ubuntu Distributions

1. On your Linux machine, open the appropriate configuration file: l

(debian)

/etc/rsyslog.conf

l

(ubuntu) 

/etc/rsyslog.d/50-default.conf

2. Add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

3. Restart rsyslog: sudo service rsyslog restart

SUSE Linux Enterprise 11 SP4 - 12 SP1Server Distribution

You must have sudo privileges to complete this procedure.

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”

USM Anywhere™ Deployment Guide 490

Collecting Logs from a Linux System

RSYSLOGD_COMPAT_VERSION=”4″

3. Save the file and run

SuSEconfig

.

4. On your Linux machine, open rsyslog.d/remote.conf

and add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

5. Restart rsyslog: sudo rcsyslog restart

Solaris Distribution

You must have sudo privileges to complete this procedure.

To send logs from Solaris distributions

1. On your Linux machine, open

/etc/syslog.conf

and add the following line:

*.notice @<USM-Anwhere-Sensor-IP-address>

Important: In the foregoing command, you must tab from auth.notice to

@<USM-Anwhere-

Sensor-IP-address>

; if you type a space the command will fail.

2. Stop, then restart syslog:

Solaris 5.9 and earlier sudo /etc/init.d/syslog stop sudo /etc/init.d/syslog start

Solaris 5.10 and above

#sudo svcadm refresh svc:/system/system-log

FreeBSD Distributions

You must have sudo privileges to complete this procedure.

To send logs from FreeBSD Distributions

1. On your Linux machine, open

/etc/syslog.conf

and add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

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

You must have sudo privileges to complete this procedure.

491 USM Anywhere™ Deployment Guide

Collecting Logs from a Linux System

To send logs from Gentoo Distribution

1. On your Linux machine, open

/etc/rsyslog.conf

and add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

2. Restart rsyslog: sudo /etc/init.d rsyslog restart

Arch Linux Distribution

You must have sudo privileges to complete this procedure.

To send logs from Arch Distribution

1. On your Linux machine, open

/etc/syslog-ng/syslog-ng.conf

and add the following line:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

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 operating system as a high-performance relational database so that SQL queries can explore the operating system data. With osquery, SQL tables represent abstract concepts such as running processes, loaded kernel modules, open network connections, browser plugins, hardware events, or file hashes.

You must have sudo privileges to complete this procedure.

For information about installing osquery with a Log Agent wrapper in an AWS environment, see

Installing 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 operating 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 strings with equals signs (=) 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 own osquery configuration.

4. Start the osquery daemon:

USM Anywhere™ Deployment Guide 492

Collecting Logs from a Linux System osqueryd --daemonize --config_path /etc/osquery/osquery.conf

5. Configure syslog to send data to the USM Anywhere Sensor:

*.* @<USM_ANYWHERE_SENSOR_IP_ADDRESS>:514

6. Restart syslog: sudo service rsyslog restart

7. Verify that you can see osquery events in USM Anywhere.

493 USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

Collecting Logs from a Windows System

USM Anywhere leverages NXLog to collect and forward Windows events to a sensor. NXLog is a universal log collection and forwarding agent for basic Windows event logs. But, it's also useful in its own right for suppressing spurious events. NXLog collects this audit log data and forwards it to the

USM Anywhere sensor over the syslog protocol on UDP port 514.

There are two ways you can implement this agent and integrate it with your USM Anywhere sensor to collect and forward events from your Windows systems: l

(Best Method)

Use the Windows Event Collector sensor app

to manage the NXLog subscription used to forward your windows logs directly to a deployed USM Anywhere sensor. When you use this method, the USM Anywhere sensor acts as the collector and the Windows host will forward the logs directly to the sensor using a private IP address, not over the public Internet.

l

(Alternative Method)

Install and configure NXLog CE across your Windows hosts

to use a custom NXLog configurations to capture non-Windows events on your end servers.

NXLog provides an open source version and a paid, enterprise version. The USM Anywhere sensor integration using the Windows Event Collector app is based on the enterprise version. And the

Alternative Method is based on the open source Community Edition.

Using the Windows Event Collector Sensor App

USM Anywhere provides the Windows Event Collector sensor app, which you can use to set up event collection through a deployed sensor. With Windows Event Collector (WEC), you can get events from remote computers and store them in a local event log on a collector computer. This functions through a subscription that receives and stores events on the collector that are forwarded from a remote computer (client). All data in the forwarded event is saved in the collector computer event log (no information is lost) and other forwarding related to the event is also added. The collector communicates with the USM Anywhere sensor over a private, encrypted connection.

To use the Windows Event Collector sensor app, you must have: l

A Windows Server 2008 (or newer) host you can use to setup Windows Event Forwarding to the

Windows Event Collector running on the USM Anywhere sensor l

A USM Anywhere sensor that is deployed in the same network as the Windows Server

Important: This method of Windows event collection is highly recommended over the alternative method of using NXLog CE installed on each Windows host.

Download and Install the Certificate

The Windows Server needs a certificate to establish a trusted connection between the

USM Anywhere sensor (collector) and Windows instances (clients). This certificate is available to download as a USM-NXLog-client.pfx file from the USM Anywhere web UI when you enable the

Windows Event Collector sensor app.

USM Anywhere™ Deployment Guide 494

Collecting Logs from a Windows System

To enable the sensor app and download the certificate

1. Choose SETTINGS > DEPLOYMENT to open the Deployment page.

2. In the Sensor Apps list, select Windows Event Collector.

3. At the top-right of the page, select the sensor that you want to use to enable the sensor app.

Sensor apps operate through a deployed sensor. If you have more than one deployed sensor, choose the sensor that is deployed in the same network as the Windows Server where you plan to configure a subscription to forward events to USM Anywhere.

495 USM Anywhere™ Deployment Guide

4. Below the selected sensor, click Enable.

5. In the Status tab, click the Download NXLog Certificates link.

Collecting Logs from a Windows System

This downloaded certificate must be installed locally on the Windows Server.

To install the certificate

1. Copy the downloaded certificate file to the Windows Server.

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.

USM Anywhere™ Deployment Guide 496

Collecting Logs from a Windows System

4. If the wizard prompts you for a password, leave it blank and click Next.

5. Select the option to automatically store the certificate and click Next to finish.

497

Configure the Certificate

On your Windows Server, use the Microsoft Windows HTTP Services (WinHTTP) Certificate

Configuration Tool (WinHttpCertCfg.exe) to complete the configuration of the client certificate. If you do not already have the WinHttpCertCfg.exe tool on your Windows Server, download and install it .

Important: In order to access the Security event log, the Network Service account must be in the Event Log Readers group.

USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

Give the Network Service account access to the installed certificate: winhttpcertcfg -g -c LOCAL_MACHINE\my -s USM-NXLog-client -a NetworkService

If winhttpcertcfg is not in the path, you might find it in

C:\Program Files (x86)\Windows

Resource Kits\Tools\

.

Set Up Windows Event Forwarding

Windows Event Forwarding (WEF) reads any operational or administrative event log on a device and forwards the events you choose to a Windows Event Collector (WEC) server. On the device that you set up as an Event Log collector, you configure subscriptions that pull the desired logs from any number of source computers. No special configuration is required on the source computers, other than that Windows Remote Management (WinRM) should be enabled, the WinRM Windows

Firewall exceptions be enabled, and the collector’s computer account must have read permission on the logs which you want to subscribe to.

When you configure Windows Event Forwarding on your Windows Server, you set up a security policy using the IP address of your deployed USM Anywhere sensor and the certificate thumbprint.

To get the USM Anywhere sensor IP address

1. From the USM Anywhere web UI, select SETTINGS > DEPLOYMENT.

2. Copy the displayed IP ADDRESS for the sensor.

To get the intermediate certificate thumbprint

1. On the Windows Server, open the Manage computer certificates utility.

2. Select Intermediate Certification Authorities > Certificates and locate the certificate issued by

USM Anywhere™ Deployment Guide 498

Collecting Logs from a Windows System

AlienVault-NXLog.

The name of this certificate is unique to your USM Anywhere deployment.

3. Double-click the certificate to open the Certificate dialog, and then click the Details tab.

4. Select the Thumbprint item in the list and copy the displayed value.

Important: Make sure that you don't copy any invalid characters. You can check this by pasting the value in a text editor and making sure there are no invalid characters.

499 USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

5. Close the dialog and certificate utility.

To set up event forwarding in the security policy

1. On the Windows Server, open the Local Group Policy Editor.

2. Navigate to Computer Configuration > Administrative Templates > Windows Components

> Event Forwarding and then select Configure target Subscription Manager.

3. Click the Edit policy setting link.

USM Anywhere™ Deployment Guide 500

Collecting Logs from a Windows System

501

4. In the dialog, make sure the subscription is marked as Enabled.

5. Click Show to open the subscription managers.

USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

6. Add the new subscription in the dialog using the following syntax:

Server=HTTPS://PRIVATE_SENSOR_IP:5986/wsman/,Refresh=<REFRESH_INTERVAL_IN_

SECONDS>, IssuerCA=<CERTIFICATE_THUMBPRINT>

In this syntax, use the following values: l

<CERTIFICATE_THUMBPRINT> is the thumbprint you copied in the previous task l

PRIVATE_SENSOR_IP is the IP of your deployed USM Anywhere sensor l

<REFRESH_INTERVAL_IN_SECONDS> is the number of seconds used for the refresh interval

USM Anywhere™ Deployment Guide 502

Collecting Logs from a Windows System

7. Click OK and close the Local Group Policy Editor.

8. Open the terminal and apply the configurations with 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 the Windows Server, open the Event Viewer.

503

2. Navigate to Applications and Services Logs > Microsoft > Windows > Eventlog-

ForwardingPlugin and check for any errors.

USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

You could see warnings if there are any paths that are not configured on your Windows Servers.

If the event log collection configuration is without errors or warnings, you can view the events in the

USM Anywhere Events page.

USM Anywhere™ Deployment Guide 504

Collecting Logs from a Windows System

Configuring NXLog CE on Windows Hosts

If you must collect and forward Windows events that are not supported by the Windows Event

Collector sensor app or other types of non-Windows application events from a Windows host, you can install and configure NXLog Community Edition (CE) and customize your configuration file for these systems. With this method, you must set up Windows Event Forwarding on each Windows host to enable these functions: l

Forward Windows Events to a NXLog CE agent running on a Windows server l

Enable syslog forwarding from the NXLog CE agent to the USM Anywhere sensor

Important: The

Windows Event Collector

sensor app is the preferred method of Windows event collection; however, for situations where you need to deploy the agent on an end server to send non-Windows events (such as flat files for Apache logs), you can use this method as an alternative.

This method of auditing and forwarding Windows event logs is intended for use in these environments: l

On-premises (VMware or Hyper-V sensors) l

AWS, with one of these configurations: l

The Windows hosts, the NXLog agent server, and USM Anywhere sensor are located in the same AWS VPC.

l

The Windows hosts, the NXLog agent server, and USM Anywhere sensor are not located in the same AWS VPC, but you have VPC peering configured to allow the NXLog server to communicate with the sensor using UDP port 514.

l

Azure, where the Windows hosts, the NXLog agent server, and USM Anywhere sensor are located in the same virtual network.

Important: Because it does not require that you set up log forwarding on each host, the easiest and most straightforward method for Windows log collection in an Azure environment is to collect the Windows Security events from the Azure storage table.

However, if you need the additional logs forwarded by NXLog, you can use the following information to configure Windows log collection for this environment.

Complete the following tasks to configure this method of auditing and forwarding Windows event logs and manage the subscriptions:

Install NXLog

The first task to install NXLog CE on each Windows host, including: l

Collecting computer (collector) l

Each computer from which events will be collected (source)

505 USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

To install NXLog CE

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.conf

and give it another name (you can delete it later).

4. Delete the contents in the new copy of nxlog.conf

and replace it with the following: define ROOT C:\Program Files (x86)\nxlog

Moduledir %ROOT%\modules

CacheDir %ROOT%\data

Pidfile %ROOT%\data\nxlog.pid

SpoolDir %ROOT%\data

LogFile %ROOT%\data\nxlog.log

<Extension json>

Module xm_json

</Extension>

<Extension syslog>

Module xm_syslog

</Extension>

<Extension w3c>

Module xm_csv

Fields $date, $time, $s_ip, $cs_method, $cs_uri_stem, $cs_uri_query, $s_ port, $cs_username, $c_ip, $cs_User_Agent, $cs_Referer, $sc_status, $sc_ substatus, $sc_win32_status, $time_taken

FieldTypes string, string, string, string, string, string, integer, string, string, string, string, integer, integer, integer, integer

Delimiter ' '

</Extension>

<Input internal>

Module im_internal

</Input>

<Input eventlog>

Module im_msvistalog

Query <QueryList>\

<Query Id="0">\

<Select Path="Application">*</Select>\

<Select Path="System">*</Select>\

<Select Path="Security">*</Select>\

</Query>\

</QueryList>

</Input>

<Input IIS_Logs>

USM Anywhere™ Deployment Guide 506

Collecting Logs from a Windows System

Module im_file

File "C:\\inetpub\\logs\\LogFiles\\W3SVC1\\u_ex*"

SavePos TRUE

Exec if $raw_event =~ /^#/ drop(); \ else \ w3c->parse_csv(); \

$EventTime = parsedate($date + " " + $time); \

$SourceName = "IIS"; \

$raw_event = to_json(); \

}

</Input>

<Output out>

Module om_udp

Host [YOUR_USM_INSTANCE_ADDRESS]

Port 514

Exec $EventTime = strftime($EventTime, '%Y-%m-%d %H:%M:%S, %z');

Exec $Message = to_json(); to_syslog_bsd();

</Output>

<Route 1>

Path eventlog, internal, IIS_Logs => out

</Route>

Important: Make sure USM Anywhere allows inbound requests to UDP port 514 from this host.

5. Replace

[YOUR_USM_INSTANCE_ADDRESS

] with the IP address of the USM Anywhere sensor.

6. Save the file.

7. Open Windows Services and restart the NXLog service.

8. Open USM Anywhere and verify that you are receiving NXLog events.

Note: If you need to debug NXLog, open

C:\Program Files

(x86)\nxlog\data\nxlog.log

.

For related MS Windows IIS NXLog web server plugin information, see  Microsoft Windows IIS

NXLog .

Install Sysmon

System Monitor (Sysmon) is a Windows system service and device driver that remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. Sysmon is a free Windows Sysinternals tool from Sysinternals/Microsoft.

Note: Installing is Sysmon is optional, but recommended.

507 USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System

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.

You can download this file from our Documentation Center:  https://www.alienvault.com/documentation/resources/downloads/sysmon5_config_basic.xml

3. Install Sysmon in the Windows system and execute the following command: sysmon.exe -accepteula -h md5 -n -l -i sysmon_config.xml

Sysmon starts logging the information to the Windows Event 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:

<Input eventlog>

Module im_msvistalog

Query <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 opening Windows Services and restarting NXLog.

7. Open USM Anywhere 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: wecutil qc

USM Anywhere™ Deployment Guide 508

Collecting Logs from a Windows System

3. On each source computer (every computer where you want to run logs), enter the following at 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 local computer.

This allows you to access the Security group channel.

d. Reboot the machine.

Note: If you don't want to reboot, you can read the Security Log without rebooting by entering 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 an

Administration 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 from which 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 events must meet to be collected.

To take full advantage of USM Anywhere detection capabilities, AlienVault recommends the following minimum list of channels:

509 USM Anywhere™ Deployment Guide

Collecting Logs from a Windows System 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 → Windows Defender l

Application and Services Logs → Microsoft → Windows → Windows Firewall with Advanced

Security l

Application and Services Logs → Windows PowerShell

USM Anywhere supports a full list of channels, which allows it to detect a wide array of specific types of attacks on the MS Windows platform.

You can also enable Security Group auditing and Registry auditing on certain sensitive registry keys, such as

HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\

PowerShell\1\ShellIds\Microsoft.PowerShell

.

12. Under Advanced, select Minimize Latency.

13. In the Subscription Properties dialog, click OK.

This adds the subscription to the Subscriptions pane and, if the operation was successful, the status of the subscription becomes Active.

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 the Windows Firewall on the source 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 in application log"

Export Subscription Configurations

If you are replacing a machine in your network, but you want to run both together for some time without having to reset Event Log Subscriptions manually on the new computer, you can export and re-import all the Event Log Subscriptions settings.

USM Anywhere™ Deployment Guide 510

Enabling AWS Log Collection

To export subscription configurations

1. From the command line, list 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 custom QueryList doesn't work.

4. (Optional) To use a custom query list, create a subscription as previously described, or import a subscription 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 custom QueryList.

7. Click OK, then OK again.

Troubleshooting Subscription Configuration Exports

For basic troubleshooting, see http://windowsitpro.com/security/q-what-are-some-simple-tipstesting-and-troubleshooting-windows-event-forwarding-and-collec .

For a more advanced configuration, see https://technet.microsoft.com/en-us/itpro/windows/keepsecure/use-windows-event-forwarding-to-assist-in-instrusion-detection#how-frequently-are-wefevents-delivered .

Testing and Debugging

For testing and debugging, see https://blogs.technet.microsoft.com/kevinholman/2011/08/02/howto-test-fire-any-windows-event-on-any-server-from-any-application/ .

Enabling AWS Log Collection

AWS sensor CloudWatch Logs can be used to aggregate and store application logs. This provides an easy mechanism for transporting log files from your running instances to a place where

USM Anywhere can access them without having to change any network access settings.

The advantage of CloudWatch Logs is the ability to easily configure additional metadata to be processed with the log files. It also simplifies the task of moving log files around EC2. But, if you don't want to use this utility, USM Anywhere also lets you monitor an S3 bucket, and move log files there using the tools of your choice.

After you've

enabled logs, such as S3 and Cloudwatch,

USM Anywhere automatically discovers them and they can start generating events, based on CloudTrail, S3, ELB Access, and other security logs.

511 USM Anywhere™ Deployment Guide

Installing osquery and CloudWatch Through the Log Agent

After deployment, all of the USM Anywhere out-of-box logs you see in the Setup Wizard are disabled by default. To start log collection jobs for the logs of your choice, you must enable them on this 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 the disabled icon (  ).

This turns the icon green (  original status.

). To disable an already enabled job, toggle the icon to its

Installing osquery and CloudWatch Through the Log Agent

The Log Agent is a wrapper convenient for installing third-party software with USM-specific configurations 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 a more manual approach to installation, see

Collecting Logs from a Linux

System .

USM Anywhere™ Deployment Guide 512

Installing osquery and CloudWatch Through the Log Agent

Supported Linux Distributions

The USM Anywhere Log Agent installer supporting osquery and an AWS CloudWatch configuration is available for the following Linux distributions and versions.

Distribution

Ubuntu

RHEL

CentOS

Version

12.04 Precise

7.0

7.1

7.2

7.3

7.3

6.6

6.7

6.8

6.7

6.8

7.1

7.2

14.04 Trusty

16.04 Xenial

6.6

About the osquery and CloudWatch Log Agent

osquery

After distribution and version verification, the Log Agent installs osquery for S3 from AWS.

It creates a custom osquery.conf

file that queries the following useful set of events: l file_events l users l listening_ports

513 USM Anywhere™ Deployment Guide

Installing osquery and CloudWatch Through the Log Agent 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 following

Log Group mappings:

File

/var/log/osquery/osqueryd.results.log

/var/log/auth.log

/var/log/secure

/var/log/apache/access.log

/var/log/httpd/access_log

/var/log/audit/audit.log

Log Group Name osquery-Logs

Linux-Auth-Logs

Linux-Auth-Logs

Apache-Access-Logs

Apache-Access-Logs

Linux-Audit-Logs

Caveats

Ubuntu only

All other Linux distributions

All other Linux distributions

All log streams within the groups are created using the AWS instance id

.

Note: It does not discover if you have installed Apache or other web servers to non-standard locations.

The Log Agent downloads and runs the AWS CloudWatch Logs Agent installer from the AWS S3 page for your platform and distribution's directory.

Important: Make sure that the VM on which you're running the Log Agent installer on has connectivity to that download page.

USM Anywhere™ Deployment Guide 514

Installing osquery and CloudWatch Through the Log Agent

Log Agent Instance Prerequisites

l

The instance must o

Be one of the

supported Linux distributions

.

o

Have an IAM Role 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 CloudWatch monitoring jobs created in the USM AnywhereScheduler should have already been enabled within the USM Anywhere web interface.

l

You must have root permissions or be able to perform sudo elevation to run the script. The script accepts 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/usmanywhere/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 subdirectory created (for example, usma-logagent-0.999/

).

3. Run the script as root or perform passwordless sudo elevation, for example: sudo ./LinuxConfigurationScript.sh

After the CloudWatch agent starts, it begins publishing logs to the CloudWatch Log Groups, where USM Anywhere's default scheduled jobs detect them. You can expect new events to take from 5 to 10 minutes to show up in the USM Anywhere web interface.

515 USM Anywhere™ Deployment Guide

Configuring the Network

Configuring the Network

USM Anywhere can have up to five network interfaces, depending on your environment. These network interfaces have a predefined role that cannot be changed.

The USM Anywhere Management Interface is used for system management, collecting logs, and running scans. This interface also has the following capabilities: l

Connection to USM Anywhere l

Updates to the system l

Log collection within the monitored network l

Vulnerability scans l

Asset discovery

This interface needs an IP address with permissions to access l

Inbound packets containing syslog data sent from other hosts on that network.

l

Outbound connections made to perform authenticated scans.

The other interfaces passively monitor network traffic in promiscuous mode; the system does allow the configuration of an IP address on them. These interfaces should be plugged into a port in the switch where port mirroring is configured.

Network Interfaces

Interface Name

Management

Interface

Network Configuration Required

IP address routed to provide the administrators access to the USM Anywhere web interface

This IP address also allows connections to assets in a monitored network for log collection and asset scans.

Interface connected to a mirrored port in the network switch Network Monitoring

Interface 1

Network Monitoring

Interface 2

Network Monitoring

Interface 3

Interface connected to a mirrored port in the network switch

Interface connected to a mirrored port in the network switch

Network Monitoring

Interface 4

Interface connected to a mirrored port in the network switch

Setting Up the Management Interface

USM Anywhere has, by default, DHCP and Log Collection enabled.

USM Anywhere™ Deployment Guide 516

Configuring the Network

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 USM Anywhere Sensor console.

2. Navigate to the Network Configuration > Configure Management Interface > Set a Static

Management IP Address option.

3. Type the IP Address.

4. Press Enter (OK).

Defining the DNS Nameservers

Important: If you specify two servers for DNS resolution, USM Anywhere determines their priority by their order. Configure your local DNS in the first position to have DNS name resolution in your internal network.

To define the DNS Nameservers

1. Connect to the USM Anywhere Sensor console.

2. Navigate to Network Configuration > Configure DNS.

3. Type the primary DNS and press Enter (OK).

4. Optionally, type the secondary DNS and press Enter (OK).

A confirmation screen appears to apply changes.

5. Press Enter (Yes).

Creating a Firewall Rule for Communication Between Sensor and Cloud Service

USM Anywhere is hosted as a cloud service and is accessed by an IP address that is not statically assigned and may change periodically. For this reason, you must set up a firewall rule that uses the

DNS of the cloud service, which allows incoming / outgoing traffic between the sensor and the cloud service .

517 USM Anywhere™ Deployment Guide

Configuring the Network

The DNS is shown within the green box in this example.

Checking Your Settings

You can verify your network settings through the USM Anywhere web interface in the Setup wizard, or through the sensor console.

Setup Wizard

To verify the network settings in the USM Anywhere Setup wizard

1. Launch the wizard by going to SETTINGS > DEPLOYMENT, then hover over the Configuration icon to expose the Configure option and select it.

2. Progress through the Setup wizard until you come to the NETWORK SECURITY

MONITORING page, where you can view the traffic in your network over various interfaces.

From this page, you can configure a new interface or you can configure port mirroring. For information about port mirroring, see

Device Port Mirroring Configuration

.

USM Anywhere Sensor Console

To verify the network settings in the USM Anywhere Sensor console

1. Connect to the console.

2. Navigate to the option Network Configuration > View Network Configuration.

USM Anywhere™ Deployment Guide 518

Getting Ready for Authenticated Scans

Getting Ready for Authenticated Scans

Before you can run an authenticated scan, you must perform a series of preparatory tasks, depending on your operating system.

Configuring MS Windows for Authenticated Scans

Requirements: l

Network connectivity between the USM Anywhere instance and port 5985 l

The Windows host must accept remote connects for the Windows RM service

To start the Windows RM service l

Open a Windows command prompt and run the command winrm qc

; accept the default settings.

This command starts the Windows RM service and configures a listener for the port 5985.

You're now ready to add a new credential specifically for scans of the MS Windows operating system.

For more information about WinRM, see https://msdn.microsoft.com/en-us/library/aa384372

(v=vs.85).aspx

and https://blogs.technet.microsoft.com/jonjor/2009/01/09/winrm-windowsremote-management-troubleshooting/ .

Configuring Linux for Authenticated Scans

Requirements l

OpenSSH server must be installed on your Linux host.

l

Network connectivity between the USM Anywhere Sensor and the port SSH is running on the

Linux host.

Installing the OpenSSH Server

Refer to the vendor documentation for your Linux distribution for instructions on how to install and configure 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...

519 USM Anywhere™ Deployment Guide

Getting Ready for Authenticated Scans

Before you can conduct a vulnerability scan, you must first create a credential to identify yourself to

USM Anywhere each time you want to perform a scan. For information about these credentials, see in the

USM Anywhere User Guide.

USM Anywhere™ Deployment Guide 520

Granting Access to Active Directory for USM Anywhere

Granting Access to Active Directory for USM Anywhere

If you want to configure scans of the Active Directory by USM Anywhere, you need to grant it access to the Active Directory server.

This consists of two tasks: l

Creating a dedicated USM Anywhere account in Active Directory. This is used by

USM Anywhere to log into the virtual machines to perform a scan.

l

Activating WinRM 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 associate with USM Anywhere.

4. Add the user you’ve just created to the Domain Admins group.

Activating WinRM to Enable Windows PowerShell Remoting

To activate WinRM, you can use a group policy to combine the Domain Controller and all the hosts in your Active Directory. (For reference, see Enable and configure Windows PowerShell Remoting using Group Policy in the blog powershell.no

.)

Alternatively, if you prefer to activate WinRM manually in each system you want to scan, see the

WinRM procedure in

Getting Ready for Authenticated Scans

. This activates a Windows RM listener on port 5985.

521 USM Anywhere™ Deployment Guide

Getting Traffic from Your Physical Network to the Virtual USM Anywhere Network

Getting Traffic from Your Physical Network to the Virtual

USM Anywhere Network

This topic describes how to move traffic from your on-premises sensor and other physical network artifacts to the USM Anywhere 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 network 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 all switch ports to which the firewall internal interfaces connect and the port used by the NIC, to which 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 and make sure that the spare NIC is associated with 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 vSwitch may cause instability in the hypervisor.

2. Configure the vSwitch to allow promiscuous mode: l

Click Properties, located next to the new vSwitch.

l

Select the vSwitch and click Edit.

l

Set Promiscuous Mode to Acceptand click OK.

l

Select the SPAN Target port group and make sure that the default security policy permits promiscuous mode there as well.

USM Anywhere™ Deployment Guide 522

Getting Traffic from Your Physical Network to the Virtual USM Anywhere Network

523

3. Select the Network Adapters tab; make sure that your spare NIC is associated with the vSwitch.

USM Anywhere™ Deployment Guide

Getting Traffic from Your Physical Network to the Virtual USM Anywhere Network

4. Click Close from the vSwitch properties dialog.

5. Edit the USM Anywhere 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 USM Anywhere Sensor console and select Restart from the system menu.

8. Press Enter (OK).

USM Anywhere™ Deployment Guide 524

Managing Jobs in the Scheduler

Managing Jobs in the Scheduler

The Job Scheduler page provides a list of all jobs that are defined in your USM Anywhere instance.

Many jobs are predefined (out-of-the-box) items for log collection and asset scans, and some of these require enablement in order to run according to the defined schedule. You can also define your own jobs to schedule automatic log collection, asset scans, and asset group scans, as well as jobs to perform Sensor App and AlienApp functionality. For more information about scheduling some of these job types, see the following topics: l

Configuring the AlienApp for McAfee EPO

l

Scheduling a Forensics and Response Job

For a deployed AWS sensor, USM Anywhere automatically discovers a number of out-of-box logs as long as you have enabled them within your AWS subscription. For more specific information about these jobs, see

AWS Log Discovery in USM Anywhere .

For a deployed Azure sensor, USM Anywhere automatically discovers Azure logs and displays these items in the Job Scheduler. For more specific information about Azure job creation, see

Creating a New Azure Collection Job

.

Enabling Standard Log Collection and Scan Jobs

When most logs in your account are enabled, USM Anywhere automatically discovers them and they can start generating events, based on CloudTrail, S3, ELB Access, Azure Security Event logs, and others.

But, because all of USM Anywhere's out-of-box log and asset scan jobs deploy disabled initially, you must decide which jobs you want to activate and enabling them.

To enable scheduled jobs 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 the disabled icon (  ).

This turns the icon green (  original status.

). To disable an already enabled job, toggle the icon to its

525 USM Anywhere™ Deployment Guide

Managing Jobs in the Scheduler

Adding a New Job to the Scheduler

USM Anywhere includes defined jobs to perform many of the standard log collection and scanning actions that you will need to monitor your networks. These jobs are predefined to run using a recurrence according to industry best practices. However, if you need to define a scheduled job to perform log collection, asset scans, or asset group scans, you can add a new job directly on the Job

Scheduler page.

To create a new job

1. Choose SETTINGS > SCHEDULER to open the Job Scheduler page.

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.

3. 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 can easily understand what it does.

4. Use the Select Sensor option to select the deployed sensor.

5. Use the Select App option to select the app used to run the job.

The available apps will depend on the selected sensor.

6. Use the AppAction option to select the job to run.

The selected sensor and app combination determines the actions that are available.

USM Anywhere™ Deployment Guide 526

Managing Jobs in the Scheduler

527

7. Set the Schedule to specify when USM Anywhere runs the job.

First, choose the increment as Hour, Day, Week, Month, or Year. Next, set the interval options for 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.

USM Anywhere™ Deployment Guide

Managing Jobs in the Scheduler

Or, on a monthly increment you can specify a specific date or a day of the week that occurs within in the month.

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

8. Click Save.

USM Anywhere™ Deployment Guide 528

Collecting Windows System Data with the Forensics and Response Sensor App

Collecting Windows System Data with the Forensics and

Response Sensor App

The Forensics and Response sensor app lets you collect system data on a remote Microsoft

Windows machine to provide forensic information during the incident response process.

You can also use the Forensics and Response app to launch actions on a remote Windows system to mitigate an incident or contain a threat, such as malware.

All these actions can be used on orchestration rules, and the most common ones are exposed as actions when you use the app. (For information about creating orchestration rules, see the

USM Anywhere User Guide.)

Requirements l

Most actions require Powershell, v 3 or above, to function properly.

l

Any asset that you want to query must have credentials in USM Anywhere.

Scheduling a Forensics and Response Job

You schedule a Forensics and Response job in the same way you do any other type of job.

To schedule a Forensics and Response app job

1. In USM Anywhere, go to SETTINGS > DEPLOYMENT and select Forensics and Response

App under Sensor Apps.

Note: You can also start a job from the SCHEDULER rather than DEPLOYMENT.

2. Click the link for the app.

3. Select the USM Anywhere Sensor you want to run the query for by clicking the SENSOR:

<SENSOR_TYPE> list to expand it.

4. Select the ACTIONS tab.

5. Click Schedule Job.

The Schedule New Job dialog box displays.

529 USM Anywhere™ Deployment Guide

Collecting Windows System Data with the Forensics and Response Sensor App

Note: In the Schedule New Job dialog box, you see that the sensor you selected appears by default in the Select Sensor field. Likewise, Forensics and Response is preselected in the Select App field.

6. Type a meaningful name for the job in the Name field and, if desired, add clarifying information in the Description field.

7. Click the App Action list to select the command you want to run.

8. In the Asset field, start typing the name of the asset that you want to run the query against. The application fills in the rest.

Or, you can click the

Select from list link to expose a list of assets to choose from.

9. Under Schedule, indicate the frequency with which you want to run this job.

10. Click Save.

USM Anywhere™ Deployment Guide 530