This topic provides details about configuring Windows collection so that NetWitness can collect logs from Microsoft Windows machines. In this document, the word "Collector" refers to either the NetWitness Log Collector or the NetWitness Virtual Log Collector. The word “Channel” refers to a Windows Event Log, for example, a Security Application, System, Forwarded Event, or DNS.
Windows Eventing Collection is the collection of events from Windows systems using the Windows Remote Management (WinRM) protocol, and is a Microsoft implementation of the WS-Management protocol, which runs as a service on most Windows desktops and servers. This service uses HTTP or HTTPS as its transport mechanism. The request / responses are wrapped in a SOAP envelope (a simple XML wrapper) to give them structure.
The WinRM service is not set up to run by default on all Windows operating systems, nor is it configured to listen for requests by default, which means that in order to use WinRM, you must configure it on the systems you are using. The Microsoft WinRM Configuration guide describes how to configure the WinRM service and its sub layers, either manually or by using group policies, to allow the Collector to collect Windows event logs. The Test and Troubleshoot Microsoft WinRM guide provides detailed information about resolving WinRM configuration issues. These documents are available as a PDF Portfolio on RSA Link here: Microsoft WinRM Configuration and Troubleshooting.
In its simplest form, the WinRM protocol is used by the Collector to send a subscribe request that contains filters, such as channels (event log names) and exclusions (or inclusions), for certain Windows event types. Bookmarks, which are also included in subscribe requests, are numbers that correspond to record IDs in Windows event logs. NetWitness stores these numbers so that if the Collector is restarted, it can restart where it left off from where it was collecting from previously. They are actual event record IDs which you can view in the corresponding Windows event log by highlighting an event and clicking Properties. When a subscribe request is successful, it is followed by successions of pull commands to retrieve events from a target system, and finally, an unsubscribe request is sent to end the poll cycle. To authenticate to the Windows system, NetWitness allows you to select Basic or Negotiate (Kerberos) authentication types in the event category section of an event source to provide credentials to the target system while establishing a connection.
When the event category of an event source is configured for the Negotiate authentication type (Kerberos is the default protocol), the Collector requires access to a domain controller via port 88 UDP. The Collector needs to retrieve a TGT for the log collection user account, and an ST for each of the Windows event sources being collected from in order to provide credentials for access to the WinRM service on each system. If a firewall exists between the Collector and the domain controllers, the firewall must allow at least UDP traffic on port 88 inbound to the domain controllers.
In order to send requests to Windows systems, a listener must be available on each system, that is, logic in the WinRM service that opens a TCP port to listen for incoming requests. In deciding whether to use HTTP or HTTPS as the type of protocol, consider the following information:
- If you use Basic authentication type in the NetWitness event source configuration, using HTTP as the WinRM transport protocol (when creating the listener) is not advisable. Since HTTP is not encrypted, and Basic authentication merely adds Base64-encoded credentials to the header of the request to Windows systems, this is not secure, hence the caution below.
- If you use Negotiate authentication type in the NetWitness event source configuration with HTTP, the credentials are already passed in the form of an encrypted Windows token, so no leakage of credentials will occur. However, the event log payload from the systems is in the clear – it is not encrypted.
- The HTTPS transport with either Basic or Negotiate authentication type encrypts both credentials and payload at the expense of being more difficult to configure across a large number of Windows systems.
When a collector poll cycle begins, a TCP connection to the WinRM listener port on the target system is established. The default port for this connection is 5985 for HTTP, and 5986 for HTTPS, but these can be overridden by using manual commands to create the listener, or via GPO. If a firewall exists between the Collector and the target systems, you must configure a rule to allow at least inbound TCP connections to those systems on the WinRM ports.
There are two areas that complicate WinRM deployment, especially if you are using Windows Group Policy Object (GPO):
- Using HTTPS transport instead of HTTP (see explanation of each above)
- Using a non-Administrative account as the Log Collection user account (which is highly recommended). A non-Administrative account on either domain-based, standalone or workgroup systems must have certain permissions to successfully connect and to read events.
The steps to create these permissions can be performed manually on each target system or by a combination of using GPO and scripting. (Currently, there is no way to enable WMI read rights with GPO, which affects SID enumeration by the Collector, or a reliable way to enable an HTTPS listener via GPO.)
You can use an RSA supplied script to accomplish these tasks. See the Microsoft WinRM Configuration guide for details on how to configure an HTTP or HTTPS listener on a system and to set permissions for a non-administrative account to collect from that system. The same script can be pushed as a logon script via GPO to apply the same configuration across a broad number of systems. RSA recommends that you perform a test run of the script on a lab system in a lab to observe what it does, before pushing it out in a large scale manner via GPO. See the Microsoft WinRM Configuration guide for a full list of script features.
The following user permissions must be enabled on each system from which events are collected for a non-Administrative Log Collection user account:
- Windows Management Instrumentation (WMI ) Remote Enabled permission
- WMI Read permission (cannot be enabled with GPO)
- Membership in the built-in Event Log Readers group to physically access the event logs (cannot be enabled with GPO, but for domain systems only, you can add the Log Collection user account to the domain-level Event Log Readers group).
Finally, apart from the listener and non-administrator user complications, because the WinRM service on Windows systems runs with Network Service account privileges by default, the Windows Security Event Log requires an Access Control List (ACL) to allow the Network Service account to read from it. This step can be easily accomplished either manually or with GPO.
In summary, while enabling WinRM in your environment, there are some choices that should be made up front. These are:
- What type of Log Collection user account do I use (administrator vs. non-admininstrator)? Non-administrator is highly recommended to limit exposure to administrator credentials. Even though administrator credentials are stored in Security Analytics in an encrypted lockbox, RSA still recommends not using an administrator account.
Should I use HTTP or HTTPS?
- HTTP should not be used with Basic authentication, since it exposes the credentials in the header of the request to the system being collected from.
- When you use Negotiate authentication with HTTP, the credentials (in this case, a Windows Service Ticket) are encrypted, but the event log data payload is not.
- There are two ways to use HTTPS; with, or without mutual authentication. In either case, the payload is encrypted and systems from which event data is being collected must have valid certificates that have at least client and server authentication enabled in the Enhanced Key Usage (EKU) bits. Using full mutual authentication requires the extra step of installing each system's certificate on the Collector using the Security Analytics user interface, which provides the means for the Collector to verify the host from which it is collecting the logs. Full mutual authentication requires that the Collector can also reverse look-up the IP address of the system to verify the hostname in the certificate's domain name. If this level of verification is not required, setting up HTTPS is a little simpler, since installing a certificate from each system can be cumbersome.
Do I enable settings manually or by using GPO?
- In most production environments, using a GPO is the preferred method of enabling WinRM. This offers good flexibility for the machines that are targeted (for example, IP, subnet, or a machine list from Active Directory). One drawback is that if you are using HTTPS or a non-administrator user, there are steps that cannot be done directly with GPO. These steps must be performed either manually or with a login script, as described in the Microsoft WinRM Configuration guide.
- Using a GPO is a good way to push certificates to systems if HTTPS is required, rather than manually creating one per system (however, this can be done by auto-enrollment).
- The decision can come down to the numbers of systems involved: If there are only a relatively small number of systems, the manual method may be much faster than testing, getting approval, and finally pushing a GPO out.
The first step is to create the non-Administrative collection user account (if none already exists) as described in the next section.
Create a User Account for RSA Security Analytics
RSA recommends that the user account that RSA Security Analytics uses to authenticate to the event source has only enough privileges to allow event collection.
If your event source is a part of a Windows domain, you must have your domain administrator create a user account on the domain controller with a password that is sufficiently complicated as per your company policies. If this password is set to expire, remember that collection will stop when this occurs. Hence the password must be maintained (refreshed) outside of Security Analytics, and the event sources in Security Analytics updated when the password is changed in the future. If the event sources are not part of any domain (for example, standalone or workgroup systems), you must create this user account on each of the individual systems being collected from (event sources).
For standalone systems, create a local non-administrator user account:
- On the event source, click Start > Administrative Tools > Server Manager to open the Server Manager console.
Use Server Manager to create a new user account with the following parameters:
User name: Enter a user name for the account.
- Full name: Enter a full name for the user account.
Description: Enter a description of the user account.
Account for remote collection of events in RSA Security Analytics Log Collector.
- Password: Enter a strong password, and select User cannot change password and Password never expires.
After you create users, you must verify the WinRM listener and the assignment of privileges to the non-Administrative user. This procedure varies depending on whether you are using the GPO or manual mode for configuration. Please follow the steps in the Microsoft WinRM Configuration guide.