Threat Analytics Platform (TAP)

(1)

Threat Analytics Platform

(TAP)

Deployment Guide

April 28, 2014

(2)

Information provided about third-party products does not imply any recommendation for use of that product. The information is provided as a guidelines only and is not guar-anteed to be accurate.

FireEye is a registered trademark of FireEye, Inc. All other brands, products, or service names are or may be trademarks or service marks of their respective owners. Use of this product and this document are subject to the terms of your license agreement with FireEye, Inc.

(3)

About the Deployment Guide

This deployment guide is designed to assist you in configuring log sources and suc-cessfully transmitting them to your TAP instance. It contains information about the fol-lowing:

l Overview of TAPincluding itsarchitecture l Information aboutlog sourcesfor TAP

l Comm Broker Senderconfiguration instructions

Deployment Checklist

Before deploying TAP, you must first contact FireEye Sales to obtain the proper license for Threat Analytics Platform (TAP). Your data sources will not be fully functional until you obtain this license.

To contact the TAP team, including TAP Sales, e-mail [email protected].

(6)

TAP Overview

The FireEyeThreat Analytics Platform (TAP) is a security incident detection and res-olution tracking platform that identifies cyber threats and improves response by layering enterprise-generated event data with real-time threat intelligence from FireEye.

TAP Overview

TAP is a cloud-based application that:

l Collects and indexes database, security, network, and endpoint events from your

environment

l Compares indicators in your events against FireEye intelligence in real time and

generates alerts on hits

l Applies both FireEye-defined rules and rules that you define to event data to

gen-erate alerts

l Provides an incident workflow for tracking both events associated with alerts and

any events that you deem suspicious from investigation to remediation

l Makes events available for efficient searching and pivoting l Provides visualizations of trending activity

TAP Architecture

(7)

Receiver within TAP in the VPC. The Comm Broker Receiver and all other TAP components within the VPC are managed by the TAP Operations Team.

TAP High-Level Architecture

The data flow is as follows:

l The Comm Broker sender listens receives log data in your environment and sends

it to the Comm Broker Receiver in the VPC. For security purposes, all data in transit, including all metadata, is encrypted with Twofish with a 256-bit key. When data is transmitted over the WAN to the Communication Broker Receiver, it is double-encrypted with two layers of Twofish and 512 bits of key total. The Com-munication Broker Sender/Receiver combination never stores any customer data in clear text.

l Log data is parsed according to the TAP taxonomy and then indexed to make it

available for fast searches and pivoting. Log data that cannot be parsed is still indexed as raw messages.

l Both FireEye-defined and customer defined rules are applied to the events and

alerts generated if applicable.

l FireEye Intelligence is also applied to all events in real-time and alerts generated

(8)

Comm Broker Sender

The Communications Broker (Comm Broker) Sender is an application runs on an Amazon Machine Image. It collects logs from within your Amazon Cloud environment and forwards them to the Communications Broker Receiver within yourTAP

architecture.

Communications Broker Sender Configuration

Before configuring the Comm Broker Sender, be sure that you have available the inform-ation provided by FireEye Product Support.

To configure the Comm Broker Sender to send logs to the Comm Broker Receiver in your TAP VPC and to listen for log data:

1. Load the Amazon Machine Image (AMI) from the Amazon Marketplace. 2. Enter the key provided by FireEye Product Support.

3. Run the configuration script: ./ConfigSender.sh 4. Complete the post-install script as follows:

l Welcome to the Threat Analytics Platform (TAP) Sender setup script. l Enter this Sender's identification number [38351]: (Enter the number

provide by FireEye Support)

l Enter symmetric key

[NDd-jNjExZjhjZDAyY2IxMGU2YmU3MjI2MjUzN2MyMTgwODlj]: (Enter the number provide by FireEye Support)

l Configure Sender listener addresses

l Enter interface IP address that sender will listen on [0.0.0.0]: 0.0.0.0 (Hit

Enter to select the default of 0.0.0.0)

l Enter the protocol: [UDP] (Hit Enter to select the default of

UDP or enter TCP)

l Enter the port: [514] 514 (Hit Enter to select the default of

514)

l Add another?: [no] (Hit Enter to continue; to add additional

ports, enter yes.)

l Listening configurations: 0.0.0.0\/514\/UDP (Hit Enter to select

the default or modify if needed)

l Configure Receivers' listener address and port

l Enter interface IP address of receiver [ENTER]: (Enter the IP

address provided by FireEye Product Support)

l Enter the port: [443] 443 (Hit Enter to select the default) l Add another receiver?: [no] (Hit Enter to continue if you have

(9)

information from FireEye Support for additional Comm Broker Receivers)

l List of receivers: (Hit Enter to select the default or make

modifications as needed) 5. You should see the following messages:

l Replacing senders in init file l tap-cbs stop/waiting

l tap-cbs start/running, process 1448 l Sender has successfully been initialized

Monitor Comm Broker Sender

To monitor overall health, we recommend you monitor your systems in accordance with your corporate monitoring policy.

Some areas to consider:

l Network t/x and r/x are useful for watching trends in log traffic l CPU / memory / disk space

l Monitor the host system if using virtualization for i/o performance

As an application specific check, yhe following processes should appear with the sender has successfully connected to a receiver.

Remove Comm Broker Sender

You must remove all the tap-cbs files manually in order to reinstall a CB.

l service tap-cbs stop

l yum remove tap-cbs

l rm /etc/init.d/tap-cbs

l rmdir /opt/tap-cbs

Troubleshoot Comm Broker Sender

(10)

Step 2. Verify network connectivity between the Communications Broker and the cus-tomer instance (e.g. netstat –anp | grep sender)

Step 3. Use tcpdump to verify the Communication Broker is receiving syslog traffic from log sources (e.g. tcpdump –ni eth1 –c 50 –s0 –A udp port 514)

Alternatively, you can verify the Communication Broker is listening and receiving log traffic on the configured ports.

Use the Netcat utility to send traffic from another device to the Communication Broker (e.g. echo -n "TEST TEST TEST" | nc -4u -w1 <ip address of sender> 514 )

Look for this traffic on the Communication Broker (e.g., tcpdump –ni eth1 –c 50 –s0 –A udp port 514 )

Comm Broker Senders Traffic Management

To manage large streams of data both to the Comm Broker Sender and between the Comm Broker Sender and Comm Broker Receiver, TAP supports multiple options:

l Multiple Comm Broker Senders l Load Balancers

(11)

TAP supports the use of multiple Comm Brokers Senders and Comm Broker Receivers. One Comm Broker Receiver can receive traffic from multiple Comm Broker Senders. Comm Broker Senders operate independently.

Installing Comm Broker Senders closer to the log source conserves bandwidth. If your environment includes data centers that are regional, you could deploy one or more Comm Broker Senders within each data center.

Comm Broker Senders can be deployed in arrays with load balancers for redundancy and load sharing.

Load balancers can be used to detect when systems are in need of maintenance or repair, share the load across multiple systems, and provide redundancy.

(12)

Data Sources for TAP

TAP’s effectiveness is dependent on the data sources available for analysis. What log data you send into TAP determines TAP’s detection capability (i.e., use cases avail-able). From the perspective of effective use of TAP, there are varyingtypes of log data. The TAP Communication Broker Sender hasspecifications for log dataaccepted anlog data from specific sources that is currently supported. TAP generally accepts logs from

log aggregation systemsand other sources such as network devices, security systems, and operating systems.

Types of Log Data for TAP

The detection capability from various sources including log data can be compared with the “cost” (in terms of dollars as well as resources and effort) to form an efficiency curve Perimeter devices create a bottleneck for network traffic to the internet and are generally easy to configure for syslog. Perimeter devices, such as firewalls, perform translation of inside IPs to outside Ops, and track ports used, providing key information used to identify malware and other activities of known malicious actors. Web proxy events allow detec-tion of beaconing activities and SQL injecdetec-tions.

Event data generated by the following network devices, network services, security devices and applications help detect advanced threats:

l Network devices: Routers, Switches l Network services: DNS, DHCP, NAT

l Security devices: Firewalls with NAT table logs, Web Proxy with user tracking, AV,

IPS, DLP

l Applications: ERP, CRM, web applications

l E-mail: Server transaction events, filtering, and security events

Web Intrusion Prevention Systems (IPS) and Intrusion Detection System (IDS) are also valuable log sources.

Operating system logs including system events and process tracking from high-value systems like domain controller and logs from DNS, DCHP, and other anti-virus software offer valuable context into potential malicious activity such as lateral movement.

Data logs such a file auditing, DLP or file integrity auditing have less value to security operations compared to other data sources and can be complex to implement effectively. TAP accepts log data from sources such as the following:

l Threat Detection Systems such as FireEye

l Firewalls including web application firewalls, such as Checkpoint, Cisco, F5 l Internet devices including switches, routers, and VPNs such as Cisco, Juniper,

(13)

l Network Access Control such as Forescout NAC

l Web Proxy with user tracking such as BlueCoat, Websense

l Intrusion Detection Systems (IDS) and Intrusion Protection Systems (IPS) such as

Ironport, McAfee, Symantec

l Endpoint security events such as anti-virus, HIPS, and Bit9

l Log aggregators such as Splunk, Q1, Rsyslog, ArcSight, RSA Envision, Estreamer

Log Specifications for TAP

Because of the flexibility of these data source input methods, and how TAP process logs, TAP is compatible with virtually any data source.

Through the Communications Broker Sender, TAP accepts machine-generated mes-sages and logs from hardware devices, operating systems, applications, security appli-ances, network devices and databases via a variety of methods.

The CB looks for events formatted as IETF syslog RFC5424, RFC3164, date-prefixed arbitrary data, and just-plain-arbitrary data, in descending order of preference. On stream-ing inputs (TCP, named pipe) the Comm Broker Sender expects linefeed-separated mes-sages/records.

TAP currently accepts and processes events sent via syslog, flat files, UDP/TCP streams, and queries via JDBC connection.

With the use of an additional java-based utility provided by TAP Support, the Comm Broker Sender will query Microsoft SQL, MySQL, Oracle, and PostgreSQL databases and will accept non-RFC formatted data inputs via HTTP methods.

Log Aggregation System Configuration for TAP

If you have already implemented a log aggregation system such as centralized logging, SIEM, or "Big Data" systems, you will likely be able leverage those systems to send logs into TAP.

Many of these systems support forwarding of messages and/or logs to other systems. You may be able to forward logs directly to TAP, as long as those logs follow thelog spe-cificationsand the following:

l Does not alter the original message

l Preserves the original source IP address (typically this spoofing requires UDP

for-warding, vs. TCP)

l Preserves the original timestamp l Preserves the original program name l Preserves the original message format

(14)

l Syslog-ng l Solarwinds

l Kiwi Enterprise Syslog server l Splunk

l ArcSight l Q1

Log Sources Supported by TAP

The following table shows the devices and applications that TAP currently supports.

TAP Supported Log Sources

Vendor Source Method

Apache httpd,Tomcat syslog, flat file

APC UPS syslog

Barracuda E-mail syslog

Barracuda Web syslog

Bit9 Parity syslog

Bluecoat* Proxy syslog

Bro IDS syslog

Checkpoint* FW-1 syslog

Checkpoint* Secure Platform syslog

Cisco ACE syslog

Cisco ACS syslog

Cisco Aironet syslog

Cisco ASA syslog

Cisco Call Manager syslog

Cisco Catalyst Switch syslog

Cisco FWSM syslog

Cisco IOS syslog

Cisco Ironport E-mail syslog

Cisco ISE syslog

(15)

Cisco PIX syslog

Cisco VPN 3000 Concentrator syslog

Citrix Netscaler syslog

f5 ASM (WAF) syslog

Fidelis XPS syslog

FireEye NX syslog

FireEye EX syslog

Forescout NAC syslog

IBM AIX syslog

IBM AS 400 syslog

IBM zSecure syslog

Ironport E-mail syslog

Ironport Proxy syslog

InfoBlox DNS syslog

InfoBlox DHCP syslog

ISC BIND syslog

Juniper AVT syslog

Juniper VGW syslog

Juniper SA Series VPN syslog

Kiwi Syslog Server syslog

Mandiant MIR syslog

Mandiant MSO syslog

McAfee Nitro syslog

Microsoft OS Events syslog

Microsoft DHCP syslog

Microsoft DNS syslog, flat file

Microsoft Exchange syslog

Microsoft IIS syslog, flat file

Microsoft SCOM ACS syslog

(16)

Postfix E-mail sylog

Riverbed Steelhead syslog

RSA Authentication Manager syslog

SourceFire Defense Center syslog

SourceFire IDS/IPS syslog

Symantec Brightmail syslog

Symantec Endpoint Protection syslog

Tipping Point IPS syslog

Tomcat application syslog

Trend Micro Control Manager syslog

Trend Micro Deep Discovery IPS syslog

VMWare ESX, ESXi syslog

Websense Web Proxy syslog

*For more information:

l BlueCoat: https://kb.bluecoat.com/index?page=content&id=KB4294 l Checkpoint FW-1:

http://www.mail-archive.com/[email protected]/msg26440.html

l Checkpoint Secure Platform:

https://qos.kayako.- com/Knowledgebase/Article/View/14/1/how-to-configure-syslog-server-with-check-point-device

l Kiwi Syslog Server:

http://www.kiwisyslog.com/help/syslog/index.html?action_for-ward_to_another_host.htm

Cisco PIX and ASA Firewall Configuration

To send logs from Cisco Pix or ASA firewall's, you must configure logging on the device, capture the activity on the NAT table, and forward it to the Communications Broker via syslog as follows:

#Config t

(config)#Logging on

(config)#Logging host (IP ADDRESS OF COMM BROKER) (config)#Logging trap 6

(17)

l Each line in the access control lists (ACLs) should end with the keyword “log”. l Each ACL should end with a default statement to deny all traffic, and log:

#Deny IP any any LOG

More Cisco logging information is available from the Cisco website:

http://www.cisco.com/en/US/docs/security/asa/syslog-guide/asa-syslog.pdf

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_ example09186a00805a2e04.shtml

Juniper Secure Access Configuration

To configure Juniper Secure Access (SA) logging to syslog: 1. Select System then Log/Monitoring

2. Click the Settings tab 3. Input the following:

l Server name/IP (IP generally more fault tolerant) l Facility: Generally Local0

l Type: UDP

l Client Certificate: Not Supported yet l Filter: Standard

4. Save the configuration.

For more information, see http://www.juniper.net/techpubs/en_US/uac/top-ics/task/configuration/security-access-syslog-configuring.html

Linux Configuration

Linux systems can utilize a number of different syslog tools to send logs to the Com-munications Broker.

Rsyslog Configuration

When configuring Rsyslog for Centros and RedHat 5 and 6, be sure the fully qualified domain name (FQDN) of the Communications Broker is registered in domain naming server (DNS) and the server can resolve the name correctly.

To edit the Ryslog configuration: 1. Open /etc/rsyslog.conf

2. Add the following lines to the body of the file (note that in this script @ infers UDP is used, @@ will use TCP):

“# ### begin forwarding rule ###”

(18)

Authpriv.info @CommBroker.company.com:514 Cron.* @CommBroker.company.com:514

Daemon.crit @CommBroker.company.com:514 Kern.crit @CommBroker.company.com:514

Uncomment the following lines to cache logs on hard disk: $WorkDirectory /var/lib/rsyslog $ActionQueueFileName fwdRule1 $ActionQueueMaxDiskSpace 1g $ActionQueueuSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1

*.* @CommBroker.company.com:514 #this final line specifies the forwarding location

To ensure rsyslog runs at boot: Chkconfig rsyslog on To restart the service:

Service rsyslog restart

Syslog-ng Configuration

Edit the Syslog-ng Configuration for Ubuntu LTS: 1. Open /etc/syslog-ng/syslog-ng.conf

2. Define a new destination: destination d_commbroker {syslog ("10.1.1.1"transport("udp")port(514));};

3. Replace "10.1.1.1" with theIP address of the communication broker 4. Add this destination to the appropriate log definition:

log {

source(s_network); #example existing log source source(s_bro_conn); # example existing log source destination(d_commbroker);

}

To restart the service:

service syslog-ng restart

McAfee Nitro Configuration

(19)

section of the Data Archival Settings screen. Enter the following information to configure the device:

l Forwarding IP Address. IP Address of the Comm Broker Sender to which the

data stream should be forwarded.

l Forwarding Port. Port of the Comm Broker Sender to which the data stream

should be forwarded.

RSA Authentication Manager Configuration

To configure RSA Authentication Manager 7.1 (running on a Linux server) to send the syslog, you must enable the Send system to send messages to the OS system log, as fol-lows:

1. Log in to the security console, select the appropriate instance configuration, select the Logging tab, and then select the Send system messages to OS

Sys-tem Log checkbox.

2. Log in to the Linux terminal as root and use cd to change to the following dir-ectory:

/us-r/local/RSASecurity/RSAAuthenticationManager/utils/resources 3. Use vi to edit the ims.properties file. Change the values of the three *syslog.host

fields to the IP address of your Comm Broker Sender.

4. Change the *.use_os_logger field values to true to enable the remote logging. 5. Restart the syslog daemon using the following command: kill -1 <pid> <pid> is the specific process ID of syslogd. The ID can be found by running the following command: ps auxf | syslog

Splunk Configuration

There are three types of Splunk Fowarders: Universal, Heavy, and Light; the only one that supports SYSLOG is a Heavy Forwarder.

The following links provide data on forwarding data from Splunk:

l http://docs.splunk.com/Documentation/Splunk/5.0.4/Deploy/Deployaforwarder l

http://docs.splunk.com/Documentation/Splunk/latest/Deploy/Forwarddatatothird-partysystemsd#Forward_syslog_data

Validate that logs were being forwarded to the Comm Broker Sender by running this tcp-dump command: tcptcp-dump port 514 host <IP address of Splunk Server-/Fowarder) –A

The Splunk GUI may flash a message saying that forwarding has stopped due to a spike in event volume. The message also may say there is a lack of open files or memory. In the event Splunk stops forwarding data and starts dropping events, do the following:

1. Modify the memory setting on the Splunk server in

(20)

(RedHat) by adding these parameters to the file and then reboot the server: soft nproc 10240

hard nproc 10240 soft nofile 65536 hard nofile 65536 2. Clear all the stale queries.

3. Add the following to the splunk output.conf file: Send cookeddata=false After each step, restart Splunk.

Symantec Endpoint Protection Configuration

To configure System Endpoint Protection Logging to send logs to the Comm Broker Sender:

1. In the Symantec console, click Admin. 2. Click Servers.

3. Select the local or remote site for which you want to configure external logging. 4. Under Tasks, click Configure External Logging.

5. On the General tab, select how often you want log data to be sent.

6. Select the Master Logging server that you want to handle external logging. If you use Microsoft SQL with more than one management server connecting to the data-base, only one server needs to be a Master Logging Server.

7. Check Enable Transmission of Logs to a Syslog Server.

8. In the Syslog Server box, type the IP address or hostname of the Communications Broker Sender. The Destination Port information should be UDP and 514 (default). 9. Click OK.

Default settings on the Log Filter tab are set to send all logs. If you run into performance issues, you can scale this back to send only relevant events.

Tomcat Configuration via Syslog

Tomcat does not send logs using syslog natively, In order to send syslog to the Comm Broker Sender, you must use log4j.

To configure log4j logging of Tomcat to syslog:

1. Edit or create the following file:

<TOMCAT_HOME>/-common/classes/log4j.properties (usually in /var/lib/tom-cat*)

2. Add the following making sure to put your syslog destination hostname or IP in the highlighted space(s):

(21)

log4j.logger.org.apache.catalina=INFO, SYSLOG1, SYSLOG2 log4j.appender.SYSLOG1=org.apache.log4j.net.SyslogAppender log4j.appender.SYSLOG1.syslogHost=syslog1.example.com log4j.ap-pender.SYSLOG1.layout=org.apache.log4j.PatternLayout log4j.appender.SYSLOG1.layout.ConversionPattern=%p: %m log4j.appender.SYSLOG1.Facility=LOCAL1 log4j.appender.SYSLOG1.threshold=WARN log4j.appender.SYSLOG2=org.apache.log4j.net.SyslogAppender log4j.appender.SYSLOG2.syslogHost=syslog2.example.com log4j.ap-pender.SYSLOG2.layout=org.apache.log4j.PatternLayout log4j.appender.SYSLOG2.layout.ConversionPattern=%p: %m log4j.appender.SYSLOG2.Facility=LOCAL1 log4j.appender.SYSLOG2.threshold=WARN 3. Restart Tomcat.

Trend Micro Control Manager Configuration

To configure Trend Micro Control Manager to send logs to the Comm Broker Sender: 1. Open Control Manager, click on Administration and select Settings then select

Event Center Settings.

2. In the syslog settings area configure the following:

l Server IP Address: Enter the IP of the Communications Broker Sender l Server Port: Set to 514

(22)

Appendix A. Windows Logging with NXLog

Collecting events logs from Windows systems is a complex problem. Windows doesn’t syslog natively, and important data is spread between the Windows event logs and flat files. Additionally, without tuning, the logs are not verbose enough to find evil.

NXLog has the ability to pull Windows events, and read from flat files forDNS,DHCP,

Netlogon,IIS, and any other log file on Windows. You must firstinstall and configure NXLogthen configure each log type.

NXLog Installation and Configuration

The following instructions contain sample entries; we encourage you to read the full doc-umentation found athttp://nxlog.org/resources.

To install and configure NXLog:

1. Obtain the latest MSI install file from http://sourceforge.net/projects/nxlog-ce/files/ 2. Run the NXLog installer using the MSI package, accept the license agreement and

click finish.

3. Start the service and set to start automatically

4. Using a text editor, open the nxlog configuration file which is C:\Program

Files\nxlog\confor C:\Program Files (x86)\nxlog\conf on 64-bit architectures.

5. Update important entries to get the following log types such as:

a. Windows Event Logging (select which version by uncommenting)

#Windows Event Logging of Security,System and Applic-ation Logs

#Uncomment im_msvistalog for Windows Vista/2008 and later

#Module im_msvistalog

#Uncomment im_mseventlog for Windows XP/2000/2003 #Module im_mseventlog

Exec $Message = to_syslog_bsd(); </Input>

b. DNS Logs

(23)

###Path to DNS Logs, make sure the is a double back-slash File "C:\\path_to_logs\\dns.log" SavePos True Exec to_syslog_bsd(); </Input>

c. DHCP Logs (Note: Logs cannot be in their default location of C:\Win-dows\System32\dhcp and must be placed elsewhere.)

# Sample DHCP <Input DHCP> Module im_file

###Path to DHCP Logs, make sure the is a double back-slash File "C:\\path_to_logs\\dhcp.log" SavePos True Exec to_syslog_bsd(); </Input> d. IIS Logs

# Configure your IIS server as per the FireEye recom-mended settings.

# Sample IIS

# Add the extention for w3c format. <Extension w3c>

Module xm_csv

Fields $date, $time, sitename, computername, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $cs-version, $cs(User-Agent), $cs (Cookie), $cs(Referer), $cs-host, $sc-status, $sc-sub-status, $sc-win32-$sc-sub-status, $sc-bytes, $cs-bytes, $time-taken

FieldTypes string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string

(24)

# Add the configuration for reading and forwarding IIS logs for W3SVC1 (a new stanza should be made if you have multiple sites).

<Input IIS_Logs> Module im_file File "C:\\inetpub\\logs\\LogFiles\\W3SVC1\\u_ex*" SavePos TRUE Exec to_syslog_bsd(); </Input>

# Add IIS_Logs to the output section e. Output

#Output to syslog Destination <Output out>

Module om_tcp

###Insert IP of syslog destination below Host X.X.X.X

Port 514 </Output>

# Add a route to complete the configuration <Route 1>

Path internal, eventlog, DNS, DHCP, IIS_Logs => out </Route>

2. Restart the nxlog service to pick up the changes made to your nxlog.conf file. a. net stop nxlog

b. net start nxlog

Example nxlog.conf File

The following is an example nxlog.conf for Windows Server 2008 Events, DNS, DHCP and IIS logs:

## This is a sample configuration file. See the nxlog ref-erence manual about the

## configuration options. It should be installed locally and is also available

(25)

## Please set the ROOT to the folder your nxlog was installed into,

## otherwise it will not start. #define ROOT C:\Program Files\nxlog

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 syslog> Module xm_syslog </Extension> <Extension json> Module xm_json </Extension> <Extension w3c> Module xm_csv

Fields $date, $time, sitename, computername, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $cs-version, $cs(User-Agent), $cs (Cookie), $cs(Referer), $cs-host, $sc-status, $sc-sub-status, $sc-win32-$sc-sub-status, $sc-bytes, $cs-bytes, $time-taken

FieldTypes string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string

Delimiter ' ' </Extension>

(26)

Module im_msvistalog Exec to_syslog_bsd();

(27)

Port 514 </Output> <Route 1>

Path internal, eventlog, DNS, DHCP, IIS_Logs => out </Route>

NXLog Troubleshooting

Always check the nxlog.log file for errors. This is file is found in C:\<Install_ Path>\data. If it shows anything other than theexample, there is a problem with the configuration file that must be resolved.

Verify that INFO nxlog-ce-2.7.1191 started.

You can also run a Wireshark to look at packet captures leaving the system as follows:

Operating System Events

Newer versions of Windows have granular control over what is audited by the operating system. We recommend you carefully plan out your policy in order to collect logs for the events that matter. The Microsoft Security Compliance Manager has templates that can guide you through creating a robust baseline policy for all Microsoft operating systems. Seehttp://technet.microsoft.com/en-us/library/cc677002.aspxfor additional information.

DNS Query Logs

(28)

logging, and send those logs to TAP using NXLog. To configure DNS logs:

1. Find the DNS server in the Server Manager console.

2. Expand DNS and right click the server, and choose properties. 3. Under the Debug Logging tab, click or confirm that:

l Outgoing and Incoming are both checked. l UDP and TCP are both checked.

l Queries is checked. l Details is not clicked

DHCP Logs

DHCP logs help connect the dots from perimeter activity (such as a firewall event show-ing a connection to a C2 server) to the inside host. As hosts are dynamically assigned IPs via DHCP, or roaming between wireless access points, tracking who is where becomes difficult without DHCP logs.

We recommend enabling DHCP audit logging, and sending those logs to TAP using NXLog. An important note to remember, you must change the logging path from the default in order to forward with NXLog.

To enable logging:

1. Find the DHCP server in the Server Manager console.

2. Expand DHCP and right click the server, and choose IPv4 Properties. 3. Under the General tab, click Enable DHCP audit logging.

4. Verify the path to the log files (note the path has been changed from c:\Win-dows\system32\dhcp) for the Audit log file path option under the Advanced tab.

Netlogin Debug Logs

Enabling Netlogon debug logging provides detailed activity about authentication beyond what is normally contained in security event logs. These logs can also be shipped using NXLog. Seehttp://support.microsoft.com/kb/109626for more information.

IIS Logs

Internet Information Server (IIS) logs do not provide much information by default, but they have the ability to be very verbose. We recommend you enable logging to capture import-ant informationfor detecting malicious activity, such as the method, bytes transferred, and other critical data. IIS logs can be sent to TAP using NXLog.

The system requirements are:

l IIS 6, 7 or 8

(29)

To configure IIS log settings:

1. Open the Internet Information Services (IIS) Manager and select the IIS server that is to be configured. Then select Logging.

2. Configure the log settings to reflect the following configuration:

l For the One log file per option: Site l For the Format option: W3C

l For Select Fields, check all field options

l For Log Event Destination, select Log file only or Both log file and ETW

event

l For Schedule under Log File Rollover, select Daily

3. Apply the changes to the logging configuration

Process Creation Auditing

We highly recommend tracking process creation activity, which is not enabled by default. Windows 7, Server 2008 and later operating systems support process creation auditing, and Server 2012 has auditing of command line activity. For more information, see http://-technet.microsoft.com/en-us/library/dd941613(v=ws.10).aspxor

http://-technet.microsoft.com/en-us/library/dn535776.aspx.

SQL Events

SQL events can be written to the Windows event logs, making it easy to collect database activity logs. For more information, see

Threat Analytics Platform (TAP)