Question & Answer
What is the 'Microsoft Security Event Log over MSRPC' protocol?
The Microsoft Security Event Log over MSRPC protocol is a new offering for QRadar to collect Windows events without the need of a local agent on the Windows host. The protocol leverages Microsoft's implementation of DCE/RPC, which is commonly referred to as MSRPC. The MSRPC protocols offers agentless, encrypted event collecting that provides higher event rates than the default 'Microsoft Windows Security Event Log' protocol, which uses WMI/DCOM for event collection.
Where do I download the 'Microsoft Security Event Log over MSRPC' protocol?
For most administrators or users, the Microsoft Security Event Log over MSRPC protocol is provided automatically to the QRadar appliance via automatic updates. This can be verified through the log sources user interface or by verifying that the Windows Event RPC protocol rpm file is installed.To verify through the user interface, administrators can click the Admin tab > Log Sources > Add > Microsoft Windows Security Event Log to see if the MSRPC option is available.
To verify from the command line, administrator can log in to the Console and confirm that the required rpm files are installed. These are the rpm files required to collect and parse events using the MSRPC protocol.
- PROTOCOL-WindowsEventRPC-<version>.noarch.rpm (interface and protocol connection code)
- DSM-MicrosoftWindows-<version>.noarch.rpm (parsing and QID map for all Windows-based events)
- DSM-DSMCommon-<version>.noarch.rpm (framework and support files for parsing some operating system events)
- Using SSH, log in to the QRadar Console as the root user.
- To verify the protocol is installed, type: yum info *EventRPC*
- Examine the list and verify that PROTOCOL-WindowsEventRPC-<version>.noarch.rpm is installed. If the file is listed, but does not display in the user interface, the administrator can restart the web server. Note: Restarting the web server will log out all users, stop event exports, and stop reports that are in the middle of generating.
- Click the Admin tab > Advanced > Restart Web Server.
- Log back in to the QRadar Console.
- Verify that the Microsoft Security Event Log over MSRPC is displayed in the log source user interface.
What event log types are supported by the MSRPC protocol?
The Microsoft Security Event Log over MSRPC only supports standard Windows event logs for workstations and servers. This allows MSRPC to collect Security, System, Application, DNS Server, File Replication, and Directory Service event.MSRPC is not capable of retrieving or parsing non-Standard windows logs, such as Microsoft IIS, Microsoft SQL, Microsoft DHCP, Juniper Steel-Belted Radius, Microsoft IAS/NPS, Microsoft ISA, or NetApp Data ONTAP. If you require events from any of these systems, administrators can the install the WinCollect agent software.
What is the intended application for the 'Microsoft Security Event Log over MSRPC' protocol?
The MSRPC protocol is best used to poll Windows endpoints (workstations) and mid-to-low EPS rate Windows servers due to the 100 EPS maximum of the protocol. The MSRPC protocol is only capable of polling for Windows events from the default event logs on the Windows host. For example, IIS, DHCP, or IAS event logs are not supported.
As compared to WMI, MSRPC supports twice the event rate capabilities.
|Name||Protocol type||Maximum event rate|
|Microsoft Security Event Log||WMI/DCOM||50 EPS / Windows host|
|Microsoft Security Event Log over MSRPC||MSRPC||
Does MSRPC provide security for my event payloads?
MSRPC traffic is encrypted. Packet/session information is encrypted cannot be disabled in the user interface by administrators. MSRPC uses NTLMv2 with packet/session security and does not support Kerberos. If event payload security is required, then administrators should leverage MSRPC for Windows event collection.
What are the features of the 'Microsoft Security Event Log over MSRPC' protocol?
The MSRPC protocol provides agentless, encrypted event collection from Windows hosts. Each 'Microsoft Windows Security Event Log over MSRPC' log source is capable of collecting from Windows hosts that generate up to 100 EPS. The MSRPC protocol is capable of supporting up to 8,500 overall EPS per each QRadar 16xx Event Processor or 18xx Event/Flow Processor. QRadar supports bulk adding of a maximum of 500 'Microsoft Security Event Log over MSRPC' log sources. If more than 500 MSRPC log sources are required, the administrator should configure these log sources on a separate QRadar appliance. The use of the MSRPC protocol is recommended for administrators who need to collect Windows events from low-mid EPS rate systems when the corporate policies that restrict the use of agents.
|Features||Supported by the 'Microsoft Security Event Log over MSRPC' protocol?|
|Maximum EPS rate||100 EPS / Windows host|
|Maximum overall EPS rate||8500 EPS / QRadar appliance (15xx, 16xx, 18xx, 31xx)|
|Maximum log sources||500 log sources / QRadar|
|Bulk log source support||Yes|
|Encryption||Yes, using the MS-EVEN6 protocol.|
|Protocol type||The protocol type used for event collection is dependant on your Windows operating system version. Select one of the following options from the Protocol Type list:
MS-EVEN6 (default for new log sources)
The default protocol type for new log sources. The protocol type that is used by QRadar to communicate with Windows Vista and Windows Server 2008 and later.
MS-EVEN (for Windows XP/2003)
The protocol type that is used by QRadar to communicate with Windows XP and Windows Server 2003.
Windows XP and Windows Server 2003 are not supported by Microsoft. The use of this option might not be successful.
Auto-detect (for legacy configurations)
Existing MSRPC log sources are assigned Auto-detect as the protocol type when the latest protocol is installed in the QRadar deployment.
|Supported Windows Operating Systems||
NOTE: MSRPC is not supported on versions of Windows that have been moved to End Of Life by Microsoft, such as Windows 2003 and Windows XP.
|Required permissions||The log source user must be a member of the Event Log Readers group. If this group is not configured, then domain admin privileges are required in most cases to poll a Windows event log across a domain. In some cases, the Backup Operators group can be used depending on how Microsoft Group Policy Objects are configured.
** Windows 2003 operating systems users require read access to the following registry keys:
** Windows 2003 does work with MSRPC, however, QRadar support does not take questions or assist with Windows 2003 integrations. This is due to Microsoft declaring this operating system as end of life.
|Windows Service Requirements||For Windows Vista and later:
** For Windows 2003:
|Port Requirements||For Windows Vista and later:
** For Windows 2003:
|Tuning support||No, MSRPC is limited to 100 EPS / Windows host and no further performance tuning is available. For higher event rate systems (>100 EPS), see WinCollect.|
|Event filtering support||No, MSRPC does not support event filtering. See WinCollect for this feature.|
|Connection test tool||Yes, MSRPC has a downloadable test tool administrators can use to connect from the QRadar appliance to a Windows host. For more information, see http://www.ibm.com/support/docview.wss?uid=swg21959348|
What QRadar versions are required?
The 'Microsoft Security Event Log over MSRPC' protocol is supported on QRadar 7.1.x and QRadar 7.2.x software installations, but is not supported on any version of QRadar 7.0.x.
I currently collect events over WMI using the 'Microsoft Security Event Log' protocol. Can I still continue to use the WMI protocol?
Yes, administrators who have log sources configured that use the 'Microsoft Security Event Log' are not affected when the MSRPC protocol is added to QRadar. Administrators are not required to update or convert any existing log source, unless they choose to make this change themselves.For more information on WMI configurations please refer to these links.
- Configuring DCOM and WMI to Remotely Retrieve Windows 2008 Server Events
- Configuring DCOM and WMI to Remotely Retrieve Windows 7 Events
Event collection scenario: 500 Windows hosts with 5 domain controllers
An administrator has 500 Windows hosts and 5 domain controllers in the network and they are tasked with collecting events from these systems. The collection method the administrator selects should be determined by EPS rate of the remote Windows hosts.
After an investigation in to these Windows systems, it is determined that the EPS rates across these systems are as follows:
- Best option (MSRPC) - A single QRadar appliance using 'Microsoft Security Event Log over MSRPC' can collect these events. This is the best option due to the ease of configuration and centralized management of the log sources.
- 2nd best option (WinCollect) - A two WinCollect agents could remotely poll for these events. Two WinCollect agents are required because the remote polling maximum EPS is 2500 per agent. This is the 2nd ranked option because WinCollect is easy for administrators configure and is not as difficult to configure as WMI, which requires registry changes.
- 3rd best option (WMI) - Multiple QRadar appliances using the 'Microsoft Security Event Log' protocol can be used to collect these events. Administrators need to enable WMI/DCOM on their Windows hosts to be able to poll for events. In this scenario, 3 or 4 QRadar appliances would likely be required to collect these events. The connection to the remote systems must be on a low latency network.
How does an administrator choose what protocol to use for Windows event collection?
New deployments or administrators adding Windows event collection to their QRadar deployment should use MSRPC. WMI is considered a legacy protocol for Windows event collection. The performance improvements of MSRPC and ease of configuration benefits by not having to enable WMI/DCOM make using the MSRPC protocol beneficial. The only reason to use WMI over the MSRPC protocol is for legacy log sources, such as Windows XP where agentless or encrypted events are required.
Internal Use Only
|June 3, 2016||Added TCP port 445 as a requirement for Windows Vista operating systems and later.|
31 July 2019