QRadar DSM Configuration Guide

IBM Security QRadar
DSM Configuration Guide
April 2018
IBM
Note
Before using this information and the product that it supports, read the information in “Notices” on page 1009.
Product information
This document applies to IBM QRadar Security Intelligence Platform V7.2.1 and subsequent releases unless
superseded by an updated version of this document.
© Copyright IBM Corporation 2005, 2018.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this DSM Configuration Guide
xix
Part 1. QRadar DSM installation and
log source management . . . . . . 1
1 Event collection from third-party
devices . . . . . . . . . . . . . . . 3
Adding
Adding
Adding
Adding
a DSM . . . .
a log source . . .
bulk log sources .
a log source parsing
. .
. .
. .
order
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
6
6
Part 2. Log sources . . . . . . . . . 7
2 Introduction to log source
management. . . . . . . . . . . . . 9
3 Adding a log source . . . . . . . . 11
Blue Coat Web Security Service REST API protocol
configuration options . . . . . . . . . . .
Centrify Redrock REST API protocol configuration
options . . . . . . . . . . . . . . . .
Cisco Firepower eStreamer protocol configuration
options . . . . . . . . . . . . . . . .
Cisco NSEL protocol configuration options . . . .
EMC VMware protocol configuration options . . .
Forwarded protocol configuration options . . . .
HTTP Receiver protocol configuration options . . .
IBM BigFix SOAP protocol configuration options . .
JDBC protocol configuration options . . . . . .
JDBC SiteProtector configuration options . . . .
Juniper Networks NSM protocol configuration
options . . . . . . . . . . . . . . . .
Juniper Security Binary Log Collector protocol
configuration options . . . . . . . . . . .
Log File protocol configuration options . . . . .
Microsoft Azure Event Hubs protocol configuration
options . . . . . . . . . . . . . . . .
Microsoft DHCP protocol configuration options . .
Microsoft Exchange protocol configuration options
Microsoft IIS protocol configuration options . . .
Microsoft Security Event Log protocol configuration
options . . . . . . . . . . . . . . . .
Microsoft Security Event Log over MSRPC
Protocol . . . . . . . . . . . . . .
MQ protocol configuration options . . . . . .
Okta REST API protocol configuration options. . .
OPSEC/LEA protocol configuration options . . .
Oracle Database Listener protocol configuration
options . . . . . . . . . . . . . . . .
PCAP Syslog Combination protocol configuration
options . . . . . . . . . . . . . . . .
SDEE protocol configuration options . . . . . .
© Copyright IBM Corp. 2005, 2018
SMB Tail protocol configuration options . . . . .
SNMPv2 protocol configuration options . . . . .
SNMPv3 protocol configuration options . . . . .
Seculert Protection REST API protocol configuration
options . . . . . . . . . . . . . . . .
Sophos Enterprise Console JDBC protocol
configuration options . . . . . . . . . . .
Sourcefire Defense Center eStreamer protocol
options . . . . . . . . . . . . . . . .
Syslog Redirect protocol overview . . . . . . .
TCP multiline syslog protocol configuration options
TLS syslog protocol configuration options . . . .
Configuring multiple log sources over TLS syslog
UDP multiline syslog protocol configuration options
Configuring UDP multiline syslog for Cisco ACS
appliances . . . . . . . . . . . . . .
VMware vCloud Director protocol configuration
options . . . . . . . . . . . . . . . .
39
40
40
40
41
43
43
44
48
49
50
52
53
4 Adding bulk log sources . . . . . . 55
12
5 Adding a log source parsing order
13
6 Log source extensions . . . . . . . 59
14
14
15
16
16
16
17
20
21
22
22
23
25
26
27
29
30
32
33
34
57
Examples of log source extensions on QRadar forum
Patterns in log source extension documents. . . .
Defining custom property by using a Regex or JSON
expression . . . . . . . . . . . . . . .
Match groups. . . . . . . . . . . . . .
Matcher (matcher) . . . . . . . . . . .
JSON matcher (json-matcher) . . . . . . .
Multi-event modifier (event-match-multiple) . .
Single-event modifier (event-match-single) . .
Extension document template . . . . . . . .
Creating a log source extensions document to get
data into QRadar . . . . . . . . . . . .
Building a Universal DSM . . . . . . . .
Exporting the logs . . . . . . . . . . .
Common regular expressions . . . . . . .
Building regular expression patterns . . . . .
Uploading extension documents to QRadar. . .
Mapping unknown events . . . . . . . .
Parsing issues and examples. . . . . . . . .
Parsing a CSV log format. . . . . . . . .
Log Source Type IDs . . . . . . . . . . .
7 Log source extension management
Adding a log source extension .
.
.
.
.
.
59
60
60
61
62
65
68
69
70
72
73
73
75
76
77
78
79
81
82
93
.
. 93
Part 3. DSMs . . . . . . . . . . . 95
35
8 3Com Switch 8800 . . . . . . . . . 97
36
38
Configuring your 3COM Switch 8800 .
.
.
.
.
. 97
iii
9 AhnLab Policy Center . . . . . . . 99
10 Akamai Kona . . . . . . . . . . 101
11 Amazon AWS CloudTrail . . . . . 103
Enabling communication between IBM Security
QRadar and AWS CloudTrail . . . . . . .
Verifying that Amazon AWS CloudTrail events are
received . . . . . . . . . . . . . .
Troubleshooting Amazon AWS log source
integrations . . . . . . . . . . . . .
Configuring Amazon AWS CloudTrail to
communicate with QRadar . . . . . . . .
. 106
. 107
. 107
. 109
12 Ambiron TrustWave ipAngel . . . . 111
13 APC UPS . . . . . . . . . . . . 113
Configuring your APC UPS to forward syslog
events . . . . . . . . . . . . . .
.
. 114
14 Apache HTTP Server . . . . . . . 115
Configuring Apache HTTP Server with syslog . . 115
Configuring a Log Source in IBM Security QRadar 116
Configuring Apache HTTP Server with syslog-ng
116
Configuring a log source . . . . . . . . . 117
15 Apple Mac OS X . . . . . . . . . 119
Configuring a Mac OS X log source . . . .
Configuring syslog on your Apple Mac OS X.
.
.
. 119
. 119
16 Application Security DbProtect . . 121
Installing the DbProtect LEEF Relay Module .
Configuring the DbProtect LEEF Relay . . .
Configuring DbProtect alerts . . . . . .
.
.
.
. 122
. 122
. 123
17 Arbor Networks . . . . . . . . . 125
Arbor Networks Peakflow SP . . . . . . . .
Supported event types for Arbor Networks
Peakflow SP . . . . . . . . . . . . .
Configuring a remote syslog in Arbor Networks
Peakflow SP . . . . . . . . . . . . .
Configuring global notifications settings for
alerts in Arbor Networks Peakflow SP . . . .
Configuring alert notification rules in Arbor
Networks Peakflow SP . . . . . . . . .
Configuring an Arbor Networks Peakflow SP
log source . . . . . . . . . . . . .
Arbor Networks Pravail . . . . . . . . . .
Configuring your Arbor Networks Pravail
system to send events to IBM Security QRadar .
125
126
126
126
127
127
129
129
18 Arpeggio SIFT-IT. . . . . . . . . 131
Configuring a SIFT-IT agent . . . . .
Configuring a Arpeggio SIFT-IT log source
Additional information . . . . . . .
.
.
.
.
.
.
. 131
. 132
. 133
19 Array Networks SSL VPN . . . . . 135
Configuring a log source
iv
.
.
.
QRadar DSM Configuration Guide
.
.
.
.
.
. 135
20 Aruba Networks . . . . . . . . . 137
Aruba ClearPass Policy Manager . . . . . . .
Configuring Aruba ClearPass Policy Manager to
communicate with QRadar . . . . . . . .
Aruba Introspect . . . . . . . . . . . .
Configuring Aruba Introspect to communicate
with QRadar . . . . . . . . . . . .
Aruba Mobility Controllers . . . . . . . . .
Configuring your Aruba Mobility Controller . .
Configuring a log source . . . . . . . .
137
138
138
140
141
141
141
21 Avaya VPN Gateway . . . . . . . 143
Avaya VPN Gateway DSM integration process . . 143
Configuring your Avaya VPN Gateway system for
communication with IBM Security QRadar . . . 143
Configuring an Avaya VPN Gateway log source in
IBM Security QRadar . . . . . . . . . . . 144
22 BalaBit IT Security . . . . . . . . 145
BalaBit IT Security for Microsoft Windows Events
Configuring the Syslog-ng Agent event source
Configuring a syslog destination . . . . .
Restarting the Syslog-ng Agent service . . .
Configuring a log source . . . . . . .
BalaBit IT Security for Microsoft ISA or TMG
Events. . . . . . . . . . . . . . .
Configure the BalaBit Syslog-ng Agent . . .
Configuring the BalaBit Syslog-ng Agent file
source . . . . . . . . . . . . . .
Configuring a BalaBit Syslog-ng Agent syslog
destination . . . . . . . . . . . .
Filtering the log file for comment lines . . .
Configuring a BalaBit Syslog-ng PE Relay . .
Configuring a log source . . . . . . .
145
145
. 146
. 147
. 147
. 147
. 148
. 148
.
.
.
.
149
149
150
151
23 Barracuda . . . . . . . . . . . 153
Barracuda Spam & Virus Firewall . . .
Configuring syslog event forwarding .
Configuring a log source . . . . .
Barracuda Web Application Firewall. . .
Configuring Barracuda Web Application
Firewall to send syslog events to QRadar
Configuring Barracuda Web Application
Firewall to send syslog events to QRadar
devices that do not support LEEF . .
Barracuda Web Filter . . . . . . . .
Configuring syslog event forwarding .
Configuring a log source . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 155
for
. .
. .
. .
. .
.
.
.
.
153
153
153
154
155
156
157
157
24 BeyondTrust PowerBroker . . . . 159
Configuring BeyondTrust PowerBroker to
communicate with QRadar . . . . . . .
BeyondTrust PowerBroker DSM specifications
Sample event messages . . . . . . . .
.
.
.
. 160
. 161
. 162
25 BlueCat Networks Adonis . . . . . 163
Supported event types . . .
Event type format . . . . .
Configuring BlueCat Adonis .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 163
. 163
. 164
Configuring a log source in IBM Security QRadar
164
26 Blue Coat. . . . . . . . . . . . 165
Blue Coat SG . . . . . . . . . . . .
Creating a custom event format . . . . .
Creating a log facility. . . . . . . . .
Enabling access logging . . . . . . . .
Configuring Blue Coat SG for FTP uploads .
Configuring a Blue Coat SG Log Source . .
Configuring Blue Coat SG for syslog . . .
Creating extra custom format key-value pairs
Blue Coat Web Security Service . . . . . .
Configuring Blue Coat Web Security Service to
communicate with QRadar . . . . . . .
.
.
.
.
.
.
.
165
166
167
167
168
168
171
171
. 172
32 Centrify
. . . . . . . . . . . . 209
Centrify Identity Platform . . . . . . . .
Centrify Identity Platform DSM specifications
Configuring Centrify Identity Platform to
communicate with QRadar . . . . . . .
Sample event message . . . . . . . .
Centrify Infrastructure Services . . . . . .
Configuring WinCollect agent to collect event
logs from Centrify Infrastructure Services . .
Configuring Centrify Infrastructure Services on
a UNIX or Linux device to communicate with
QRadar . . . . . . . . . . . . .
Sample event messages . . . . . . . .
. 209
210
. 211
. 212
. 212
. 213
. 215
. 216
. 173
33 Check Point. . . . . . . . . . . 217
27 Box . . . . . . . . . . . . . . 175
Configuring Box to communicate with QRadar .
198
Check Point . . . . . . . . . . . . . .
Integration of Check Point by using OPSEC . .
Adding a Check Point Host . . . . . . .
Creating an OPSEC Application Object . . . .
Locating the log source SIC. . . . . . . .
Configuring an OPSEC/LEA log source in IBM
Security QRadar . . . . . . . . . . .
Edit your OPSEC communications configuration
Updating your Check Point OPSEC log source
Changing the default port for OPSEC LEA
communication . . . . . . . . . . . .
Configuring OPSEC LEA for unencrypted
communications . . . . . . . . . . .
Configuring IBM Security QRadar to receive
events from a Check Point device . . . .
Integrate Check Point by using syslog . . .
Configuring a log source . . . . . . .
Integration of Check Point Firewall events from
external syslog forwarders . . . . . . . .
Configuring a log source for Check Point
forwarded events . . . . . . . . . .
Check Point Multi-Domain Management
(Provider-1) . . . . . . . . . . . . . .
Integrating syslog for Check Point
Multi-Domain Management (Provider-1) . . .
Configuring a log source . . . . . . . .
Configuring OPSEC for Check Point
Multi-Domain Management (Provider-1) . . .
Configuring an OPSEC log source . . . . .
198
34 Cilasoft QJRN/400 . . . . . . . . 233
. 176
28 Bridgewater. . . . . . . . . . . 179
Configuring Syslog for your Bridgewater Systems
Device. . . . . . . . . . . . . . . . 179
Configuring a log source . . . . . . . . . 179
29 Brocade Fabric OS. . . . . . . . 181
Configuring syslog for Brocade Fabric OS
appliances . . . . . . . . . . .
30 CA Technologies
.
.
. 181
. . . . . . . . 183
CA ACF2 . . . . . . . . . . . . . . .
Create a log source for near real-time event feed
Creating a log source for Log File protocol . .
Integrate CA ACF2 with IBM Security QRadar
by using audit scripts . . . . . . . . .
Configuring CA ACF2 that uses audit scripts to
integrate with IBM Security QRadar . . . . .
CA SiteMinder . . . . . . . . . . . . .
Configuring a log source . . . . . . . .
Configuring Syslog-ng for CA SiteMinder . . .
CA Top Secret . . . . . . . . . . . . .
Creating a log source for Log File protocol . .
Create a log source for near real-time event feed
Integrate CA Top Secret with IBM Security
QRadar by using audit scripts . . . . . . .
Configuring CA Top Secret that uses audit
scripts to integrate with IBM Security QRadar .
183
184
184
187
188
191
191
192
193
194
197
31 Carbon Black . . . . . . . . . . 203
Carbon Black . . . . . . . . . . . . . 203
Configuring Carbon Black to communicate with
QRadar . . . . . . . . . . . . . . 204
Carbon Black Protection . . . . . . . . . . 205
Configuring Carbon Black Protection to
communicate with QRadar . . . . . . . . 206
Bit9 Parity . . . . . . . . . . . . . . 206
Configure a log source . . . . . . . . . 207
Bit9 Security Platform . . . . . . . . . . 207
Configuring Bit9 Security Platform to
communicate with QRadar . . . . . . . . 208
Configuring Cilasoft QJRN/400 . . . . .
Configuring a Cilasoft QJRN/400 log source .
.
.
217
217
218
218
219
219
221
221
222
222
223
224
225
226
226
228
228
229
229
230
. 233
. 234
35 Cisco . . . . . . . . . . . . . 237
Cisco ACE Firewall . . . . . . . .
Configuring Cisco ACE Firewall . . .
Configuring a log source . . . . .
Cisco Aironet . . . . . . . . . .
Configuring a log source . . . . .
Cisco ACS . . . . . . . . . . .
Configuring Syslog for Cisco ACS v5.x .
Creating a Remote Log Target . . . .
Configuring global logging categories .
Configuring a log source . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
237
237
237
238
239
240
240
240
241
241
Contents
v
Configuring Syslog for Cisco ACS v4.x . . . .
Configuring syslog forwarding for Cisco ACS
v4.x . . . . . . . . . . . . . . .
Configuring a log source for Cisco ACS v4.x
Configuring UDP multiline syslog for Cisco
ACS appliances. . . . . . . . . . . .
Cisco ASA . . . . . . . . . . . . . .
Integrate Cisco ASA Using Syslog . . . . .
Configuring syslog forwarding . . . . . .
Configuring a log source . . . . . . . .
Integrate Cisco ASA for NetFlow by using NSEL
Configuring NetFlow Using NSEL . . . . .
Configuring a log source . . . . . . . .
Cisco CallManager . . . . . . . . . . .
Configuring syslog forwarding . . . . . .
Configuring a log source . . . . . . . .
Cisco CatOS for Catalyst Switches . . . . . .
Configuring syslog . . . . . . . . . .
Configuring a log source . . . . . . . .
Cisco Cloud Web Security . . . . . . . . .
Configuring Cloud Web Security to
communicate with QRadar . . . . . . . .
Cisco CSA . . . . . . . . . . . . . .
Configuring syslog for Cisco CSA . . . . .
Configuring a log source . . . . . . . .
Cisco FireSIGHT Management Center . . . . .
Creating Cisco FireSIGHT Management Center
5.x and 6.x certificates . . . . . . . . .
Importing a Cisco FireSIGHT Management
Center certificate in QRadar . . . . . . .
Configuring a log source for Cisco FireSIGHT
Management Center events. . . . . . . .
Cisco FWSM . . . . . . . . . . . . .
Configuring Cisco FWSM to forward syslog
events . . . . . . . . . . . . . . .
Configuring a log source . . . . . . . .
Cisco IDS/IPS . . . . . . . . . . . . .
Cisco IronPort . . . . . . . . . . . . .
Cisco IronPort DSM specifications . . . . .
Configuring Cisco IronPort appliances to
communicate with QRadar . . . . . . . .
Configuring a Cisco IronPort and Cisco ESA log
source by using the log file protocol . . . . .
Configuring a Cisco IronPort and Cisco WSA
log source by using the Syslog protocol . . .
Sample event messages . . . . . . . . .
Cisco IOS. . . . . . . . . . . . . . .
Configuring Cisco IOS to forward events . . .
Configuring a log source . . . . . . . .
Cisco Identity Services Engine . . . . . . . .
Configuring a remote logging target in Cisco
ISE . . . . . . . . . . . . . . . .
Configuring logging categories in Cisco ISE . .
Cisco NAC . . . . . . . . . . . . . .
Configuring Cisco NAC to forward events . .
Configuring a log source . . . . . . . .
Cisco Nexus . . . . . . . . . . . . . .
Configuring Cisco Nexus to forward events . .
Configuring a log source . . . . . . . .
Cisco Pix . . . . . . . . . . . . . . .
Configuring Cisco Pix to forward events . . .
vi
QRadar DSM Configuration Guide
242
242
243
243
244
244
244
245
246
246
247
248
248
249
249
249
250
251
253
254
254
254
255
257
259
260
261
261
262
262
264
265
265
Configuring a log source . . . . . . . .
Cisco Stealthwatch . . . . . . . . . . .
Configuring Cisco Stealthwatch to communicate
with QRadar . . . . . . . . . . . .
Cisco Umbrella . . . . . . . . . . . . .
Configure Cisco Umbrella to communicate with
QRadar . . . . . . . . . . . . . .
Cisco Umbrella DSM specifications . . . . .
Sample event messages . . . . . . . . .
Cisco VPN 3000 Concentrator . . . . . . . .
Configuring a log source . . . . . . . .
Cisco Wireless Services Module . . . . . . .
Configuring Cisco WiSM to forward events . .
Configuring a log source . . . . . . . .
Cisco Wireless LAN Controllers . . . . . . .
Configuring syslog for Cisco Wireless LAN
Controller . . . . . . . . . . . . .
Configuring a syslog log source in IBM Security
QRadar . . . . . . . . . . . . . .
Configuring SNMPv2 for Cisco Wireless LAN
Controller . . . . . . . . . . . . .
Configuring a trap receiver for Cisco Wireless
LAN Controller . . . . . . . . . . .
Configuring a log source for the Cisco Wireless
LAN Controller that uses SNMPv2 . . . . .
278
279
280
281
283
284
284
284
285
286
286
288
288
289
289
290
291
291
36 Citrix. . . . . . . . . . . . . . 293
Citrix NetScaler . . . . . . . . . . . .
Configuring a Citrix NetScaler log source . . .
Citrix Access Gateway . . . . . . . . . .
Configuring a Citrix Access Gateway log source
293
294
294
295
37 Cloudera Navigator . . . . . . . 297
Configuring Cloudera Navigator to communicate
with QRadar . . . . . . . . . . . . . 298
38 CloudPassage Halo . . . . . . . 299
Configuring CloudPassage Halo for
communication with QRadar . . . . . . .
Configuring a CloudPassage Halo log source in
QRadar . . . . . . . . . . . . . .
. 301
39 CloudLock Cloud Security Fabric
303
Configuring CloudLock Cloud Security Fabric to
communicate with QRadar . . . . . . . .
. 304
. 299
265
268
269
269
270
270
271
274
274
275
275
275
276
276
277
277
277
40 Correlog Agent for IBM z/OS . . . 305
Configuring your CorreLog Agent system for
communication with QRadar . . . . . .
.
. 306
41 CrowdStrike Falcon Host . . . . . 307
Configuring CrowdStrike Falcon Host to
communicate with QRadar . . . . . .
.
.
. 308
42 CRYPTOCard CRYPTO-Shield . . . 311
Configuring a log source . . . .
Configuring syslog for CRYPTOCard
CRYPTO-Shield. . . . . . . .
.
.
.
.
. 311
.
.
.
.
. 311
43 CyberArk . . . . . . . . . . . . 313
45 Damballa Failsafe . . . . . . . . 319
Extreme HiGuard Wireless IPS . . . . . .
Configuring Enterasys HiGuard . . . . .
Configuring a log source . . . . . . .
Extreme HiPath Wireless Controller . . . . .
Configuring your HiPath Wireless Controller
Configuring a log source . . . . . . .
Extreme Matrix Router . . . . . . . . .
Extreme Matrix K/N/S Series Switch . . . .
Extreme NetSight Automatic Security Manager .
Extreme NAC . . . . . . . . . . . .
Configuring a log source . . . . . . .
Extreme stackable and stand-alone switches . .
Extreme Networks ExtremeWare . . . . . .
Configuring a log source . . . . . . .
Extreme XSR Security Router . . . . . . .
Configuring syslog for Damballa Failsafe .
Configuring a log source . . . . . .
53 F5 Networks . . . . . . . . . . 351
CyberArk Privileged Threat Analytics . . . .
Configuring CyberArk Privileged Threat
Analytics to communicate with QRadar . .
CyberArk Vault . . . . . . . . . . .
Configuring syslog for CyberArk Vault . . .
Configuring a log source for CyberArk Vault
. 313
. 314
. 314
. 314
315
44 CyberGuard Firewall/VPN
Appliance . . . . . . . . . . . . . 317
Configuring syslog events .
Configuring a log source .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 317
. 317
. 319
. 319
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51 Exabeam . . . . . . . . . . . . 335
F5 Networks BIG-IP AFM . . . . . . . .
Configuring a logging pool . . . . . . .
Creating a high-speed log destination . . .
Creating a formatted log destination. . . .
Creating a log publisher . . . . . . . .
Creating a logging profile . . . . . . .
Associating the profile to a virtual server . .
Configuring a log source . . . . . . .
F5 Networks BIG-IP APM . . . . . . . .
Configuring Remote Syslog for F5 BIG-IP APM
11.x. . . . . . . . . . . . . . .
Configuring a Remote Syslog for F5 BIG-IP
APM 10.x . . . . . . . . . . . .
Configuring a log source . . . . . . .
Configuring F5 Networks BIG-IP ASM . . . .
Configuring a log source . . . . . . .
F5 Networks BIG-IP LTM . . . . . . . .
Configuring a log source . . . . . . .
Configuring syslog forwarding in BIG-IP LTM
Configuring Remote Syslog for F5 BIG-IP LTM
11.x. . . . . . . . . . . . . . .
Configuring Remote Syslog for F5 BIG-IP LTM
10.x . . . . . . . . . . . . . .
Configuring Remote Syslog for F5 BIG-IP LTM
9.4.2 to 9.4.8 . . . . . . . . . . . .
F5 Networks FirePass . . . . . . . . .
Configuring syslog forwarding for F5 FirePass
Configuring a log source . . . . . . .
Configuring Exabeam to communicate with
QRadar . . . . . . . . . . . . .
54 Fair Warning . . . . . . . . . . 363
46 DG Technology MEAS . . . . . . 321
Configuring your DG Technology MEAS system
for communication with QRadar . . . . . .
. 321
47 Digital China Networks (DCN) . . . 323
Configuring a log source . . . . . . . .
Configuring a DCN DCS/DCRS Series Switch .
. 323
. 324
48 Enterprise-IT-Security.com
SF-Sherlock . . . . . . . . . . . . 325
Configuring Enterprise-IT-Security.com SF-Sherlock
to communicate with QRadar . . . . . . . . 326
49 Epic SIEM . . . . . . . . . . . 327
Configuring
QRadar .
Configuring
QRadar .
Configuring
QRadar .
Epic
. .
Epic
. .
Epic
. .
SIEM
. .
SIEM
. .
SIEM
. .
2014
. .
2015
. .
2017
. .
to communicate with
. . . . . . . . 328
to communicate with
. . . . . . . . 328
to communicate with
. . . . . . . . 330
50 ESET Remote Administrator. . . . 333
Configuring ESET Remote Administrator to
communicate with QRadar . . . . . . .
.
.
. 334
. 335
52 Extreme . . . . . . . . . . . . 337
Extreme 800-Series Switch . . . . . . . .
Configuring your Extreme 800-Series Switch .
Configuring a log source . . . . . . .
Extreme Dragon . . . . . . . . . . .
Creating a Policy for Syslog . . . . . .
Configuring a log source . . . . . . .
Configure the EMS to forward syslog messages
Configuring syslog-ng Using Extreme Dragon
EMS V7.4.0 and later . . . . . . . . .
Configuring syslogd Using Extreme Dragon
EMS V7.4.0 and earlier . . . . . . . .
Configuring a log source
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
341
342
342
343
343
343
344
345
346
347
347
347
349
349
349
351
351
352
352
352
353
353
354
354
. 354
.
.
.
.
.
.
355
355
356
357
357
357
358
. 358
. 359
. 359
. 359
360
. 360
. 363
337
337
337
338
338
340
340
55 Fasoo Enterprise DRM . . . . . . 365
. 340
57 FireEye. . . . . . . . . . . . . 371
. 341
Configuring your FireEye system for
communication with QRadar . . .
.
.
.
.
.
.
Configuring Fasoo Enterprise DRM to
communicate with QRadar . . . . .
.
.
.
. 367
56 Fidelis XPS . . . . . . . . . . . 369
Configuring Fidelis XPS .
Configuring a log source
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
. 369
. 370
. 372
vii
Configuring your FireEye HX system for
communication with QRadar . . . . .
.
.
. 373
58 FORCEPOINT . . . . . . . . . . 375
FORCEPOINT Stonesoft Management Center. . .
Configuring FORCEPOINT Stonesoft
Management Center to communicate with
QRadar . . . . . . . . . . . . . .
Configuring a syslog traffic rule for
FORCEPOINT Stonesoft Management Center. .
Forcepoint TRITON . . . . . . . . . . .
Configuring syslog for Forcepoint TRITON . .
Configuring a log source for Forcepoint
TRITON . . . . . . . . . . . . . .
Forcepoint V-Series Data Security Suite . . . . .
Configuring syslog for Forcepoint V-Series Data
Security Suite . . . . . . . . . . . .
Configuring a log source for Forcepoint V-Series
Data Security Suite . . . . . . . . . .
Forcepoint V-Series Content Gateway . . . . .
Configure syslog for Forcepoint V-Series
Content Gateway . . . . . . . . . . .
Configuring the Management Console for
Forcepoint V-Series Content Gateway . . . .
Enabling Event Logging for Forcepoint V-Series
Content Gateway . . . . . . . . . . .
Configuring a log source for Forcepoint V-Series
Content Gateway . . . . . . . . . . .
Log file protocol for Forcepoint V-Series Content
Gateway . . . . . . . . . . . . . .
Configuring the Content Management
Console for Forcepoint V-Series Content
Gateway . . . . . . . . . . . . .
Configuring a log file protocol log source for
Forcepoint V-Series Content Gateway . . .
375
376
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
397
397
397
399
64 genua genugate . . . . . . . . . 401
Configuring genua genugate to send events to
QRadar . . . . . . . . . . . . . .
. 402
65 Great Bay Beacon . . . . . . . . 403
379
380
66 HBGary Active Defense. . . . . . 405
380
381
381
381
382
382
383
383
384
384
. 385
385
. 386
60 Fortinet FortiGate Security
Gateway . . . . . . . . . . . . . 389
Configuring a syslog destination on your
FortiGate Security Gateway device . .
Configuring a syslog destination on your
FortiAnalyzer device . . . . . . .
.
.
.
.
377
378
379
59 ForeScout CounterACT . . . . . . 385
Configuring a log source . . . . . . . .
Configuring the ForeScout CounterACT Plug-in
Configuring ForeScout CounterACT Policies . .
Configuring a log source .
Generic Firewall . . . . .
Configuring event properties
Configuring a log source .
Fortinet
. . . . 390
Fortinet
. . . . 390
Configuring syslog for Great Bay Beacon .
Configuring a log source . . . . . .
Configuring HBGary Active Defense
Configuring a log source . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. 403
. 403
. 405
. 405
67 H3C Technologies . . . . . . . . 407
H3C Comware Platform . . . . . . .
Configuring H3C Comware Platform to
communicate with QRadar . . . . .
.
.
. 407
.
.
. 408
68 Honeycomb Lexicon File Integrity
Monitor (FIM) . . . . . . . . . . . 409
Supported Honeycomb FIM event types logged by
QRadar . . . . . . . . . . . . . . . 409
Configuring the Lexicon mesh service . . . . . 409
Configuring a Honeycomb Lexicon FIM log source
in QRadar . . . . . . . . . . . . . . 410
69 Hewlett Packard (HP). . . . . . . 413
HP Network Automation . . . .
Configuring HP Network Automation
communicate with QRadar . . . .
HP ProCurve . . . . . . . .
Configuring a log source . . .
HP Tandem . . . . . . . . .
Hewlett Packard UNIX (HP-UX) . .
Configure a log source . . . .
. . .
Software
. . .
. . .
. . .
. . .
. . .
. . .
.
to
.
.
.
.
.
.
. 413
.
.
.
.
.
.
414
415
415
416
417
417
70 Huawei . . . . . . . . . . . . . 419
Huawei AR Series Router . . . . . . .
Configuring a log source . . . . . .
Configuring Your Huawei AR Series Router
Huawei S Series Switch . . . . . . . .
Configuring a log source . . . . . .
Configuring Your Huawei S Series Switch .
.
.
.
.
.
.
.
.
.
.
.
.
419
419
420
420
421
421
61 Foundry FastIron . . . . . . . . 391
Configuring syslog for Foundry FastIron .
Configuring a log source . . . . . .
62 FreeRADIUS
. 391
. 391
71 HyTrust CloudControl . . . . . . 423
Configuring HyTrust CloudControl to
communicate with QRadar . . . . .
.
.
.
. 424
72 IBM . . . . . . . . . . . . . . 425
.
.
. 393
. . . . . . . . . . . . 395
Generic Authorization Server . .
Configuring event properties .
viii
.
.
. . . . . . . . . . 393
Configuring your FreeRADIUS device to
communicate with QRadar . . . . . .
63 Generic
.
.
.
.
QRadar DSM Configuration Guide
.
.
.
.
.
.
.
.
. 395
. 395
IBM AIX . . . . . . . . . . . . . .
IBM AIX Server DSM overview . . . . .
Configuring your IBM AIX Server device to
send syslog events to QRadar . . . . .
IBM AIX Audit DSM overview . . . . .
. 425
. 425
. 426
. 426
Configuring IBM AIX Audit DSM to send
syslog events to QRadar . . . . . . . .
Configuring IBM AIX Audit DSM to send log
file protocol events to QRadar . . . . . .
IBM i . . . . . . . . . . . . . . . .
Configuring IBM i to integrate with IBM
Security QRadar . . . . . . . . . . .
Manually extracting journal entries for IBM i
Pulling Data Using Log File Protocol . . . .
Configuring Townsend Security Alliance
LogAgent to integrate with QRadar . . . . .
IBM BigFix . . . . . . . . . . . . . .
IBM BigFix Detect . . . . . . . . . . . .
Configuring IBM BigFix Detect to communicate
with QRadar . . . . . . . . . . . .
IBM Bluemix Platform . . . . . . . . . .
Configuring Bluemix Platform to communicate
with QRadar . . . . . . . . . . . .
Integrating Bluemix Platform with QRadar
Configuring a Bluemix log source to use
Syslog . . . . . . . . . . . . . .
Configuring a Bluemix log source with TLS
Syslog . . . . . . . . . . . . . .
IBM CICS . . . . . . . . . . . . . .
Create a log source for near real-time event feed
Creating a log source for Log File protocol . .
IBM DataPower . . . . . . . . . . . .
Configuring IBM DataPower to communicate
with QRadar . . . . . . . . . . . .
IBM DB2 . . . . . . . . . . . . . . .
Create a log source for near real-time event feed
Creating a log source for Log File protocol . .
Integrating IBM DB2 Audit Events . . . . .
Extracting audit data for DB2 v8.x to v9.4 . . .
Extracting audit data for DB2 v9.5 . . . . .
IBM Federated Directory Server . . . . . . .
Configuring IBM Federated Directory Server to
monitor security events . . . . . . . . .
IBM Fiberlink MaaS360 . . . . . . . . . .
Configuring an IBM Fiberlink MaaS360 log
source in QRadar . . . . . . . . . . .
IBM Guardium . . . . . . . . . . . . .
Creating a syslog destination for events . . .
Configuring policies to generate syslog events
Installing an IBM Guardium Policy . . . . .
Configuring a log source . . . . . . . .
Creating an event map for IBM Guardium
events . . . . . . . . . . . . . . .
Modifying the event map . . . . . . . .
IBM IMS . . . . . . . . . . . . . . .
Configuring IBM IMS . . . . . . . . .
Configuring a log source . . . . . . . .
IBM Informix Audit . . . . . . . . . . .
IBM Lotus Domino . . . . . . . . . . .
Setting Up SNMP Services . . . . . . . .
Setting up SNMP in AIX . . . . . . . .
Starting the Domino Server Add-in Tasks . . .
Configuring SNMP Services . . . . . . .
Configuring your IBM Lotus Domino device to
communicate with QRadar . . . . . . . .
IBM Privileged Session Recorder . . . . . . .
428
429
430
431
433
434
435
435
437
438
440
440
441
441
441
442
443
444
447
447
448
449
450
453
453
454
455
456
456
457
458
459
459
460
460
461
462
462
463
465
467
468
468
468
469
469
470
471
Configuring IBM Privileged Session Recorder to
communicate with QRadar . . . . . . . .
Configuring a log source for IBM Privileged
Session Recorder . . . . . . . . . . .
IBM Proventia . . . . . . . . . . . . .
IBM Proventia Management SiteProtector . . .
Configuring a log source . . . . . . .
IBM ISS Proventia . . . . . . . . . . .
IBM QRadar Packet Capture . . . . . . . .
Configuring IBM QRadar Packet Capture to
communicate with QRadar . . . . . . . .
Configuring IBM QRadar Network Packet
Capture to communicate with QRadar . . . .
IBM RACF . . . . . . . . . . . . . .
Creating a log source for Log File protocol . .
Create a log source for near real-time event feed
Integrate IBM RACF with IBM Security QRadar
by using audit scripts . . . . . . . . .
Configuring IBM RACF that uses audit scripts
to integrate with IBM Security QRadar . . . .
IBM SAN Volume Controller . . . . . . . .
Configuring IBM SAN Volume Controller to
communicate with QRadar . . . . . . . .
IBM Security Access Manager for Enterprise Single
Sign-On . . . . . . . . . . . . . . .
Configuring a log server type . . . . . . .
Configuring syslog forwarding . . . . . .
Configuring a log source in IBM Security
QRadar . . . . . . . . . . . . . .
IBM Security Access Manager for Mobile . . . .
Configuring IBM Security Access Manager for
Mobile to communicate with QRadar . . . .
Configuring IBM IDaaS Platform to
communicate with QRadar . . . . . . . .
Configuring an IBM IDaaS console to
communicate with QRadar . . . . . . . .
IBM Security Directory Server . . . . . . . .
IBM Security Directory Server integration
process . . . . . . . . . . . . . .
Configuring an IBM Security Directory
Server log source in IBM Security QRadar . .
IBM Security Identity Governance . . . . . .
Configuring QRadar to communicate with your
IBM Security Identity Governance database . .
IBM Security Identity Manager . . . . . . .
IBM Security Network IPS (GX) . . . . . . .
Configuring your IBM Security Network IPS
(GX) appliance for communication with QRadar.
Configuring an IBM Security Network IPS (GX)
log source in QRadar . . . . . . . . . .
IBM QRadar Network Security XGS . . . . . .
Configuring IBM QRadar Network Security XGS
Alerts . . . . . . . . . . . . . . .
Configuring a Log Source in IBM Security
QRadar . . . . . . . . . . . . . .
IBM Security Privileged Identity Manager . . . .
Configuring IBM Security Privileged Identity
Manager . . . . . . . . . . . . . .
IBM Security Trusteer Apex Advanced Malware
Protection . . . . . . . . . . . . . .
Contents
472
472
473
473
474
476
476
478
479
479
480
483
484
484
486
488
488
489
489
489
490
492
493
493
494
494
494
495
496
497
500
501
501
502
502
503
504
505
506
ix
Configuring IBM Security Trusteer Apex
Advanced Malware Protection to send syslog
events to QRadar . . . . . . . . . . .
Configuring IBM Security Trusteer Apex
Advanced Malware Protection to send TLS
Syslog events to QRadar. . . . . . . . .
Creating a TLS/SSL server certificate and
private key . . . . . . . . . . . .
Creating Client Authentication certificates
and keys for Apex Local Manager . . . .
Configuring the Apex Local Manager . . .
Configuring the ALM instance . . . . .
Configuring a Flat File Feed service . . . . .
IBM Security Trusteer Apex Local Event
Aggregator . . . . . . . . . . . . . .
Configuring syslog for Trusteer Apex Local
Event Aggregator . . . . . . . . . . .
IBM Sense . . . . . . . . . . . . . .
Configuring IBM Sense to communicate with
QRadar . . . . . . . . . . . . . .
IBM SmartCloud Orchestrator . . . . . . . .
Installing IBM SmartCloud Orchestrator . . .
Configuring an IBM SmartCloud Orchestrator
log source in QRadar . . . . . . . . . .
IBM Tivoli Access Manager for e-business . . . .
Configure Tivoli Access Manager for e-business
Configuring a log source . . . . . . . .
IBM Tivoli Endpoint Manager . . . . . . . .
IBM WebSphere Application Server . . . . . .
Configuring IBM WebSphere . . . . . . .
Customizing the Logging Option . . . . . .
Creating a log source . . . . . . . . . .
IBM WebSphere DataPower . . . . . . . .
IBM z/OS . . . . . . . . . . . . . .
Create a log source for near real-time event feed
Creating a log source for Log File protocol . .
IBM zSecure Alert . . . . . . . . . . . .
77 Infoblox NIOS . . . . . . . . . . 547
510
.
.
.
.
.
.
.
510
510
511
511
512
512
513
513
514
515
515
516
516
517
517
518
519
519
519
519
520
523
523
524
524
527
.
. 530
74 Illumio Adaptive Security Platform
533
Configuring Illumio Adaptive Security Platform to
communicate with QRadar . . . . . . . . . 534
Configuring Exporting Events to Syslog for
Illumio PCE . . . . . . . . . . . . . 534
Configuring Syslog Forwarding for Illumio PCE 535
75 Imperva Incapsula . . . . . . . . 537
Configuring Imperva Incapsula to communicate
with QRadar . . . . . . . . . . . .
. 538
76 Imperva SecureSphere . . . . . . 541
Configuring an alert action for Imperva
SecureSphere . . . . . . . . . . . . . 542
Configuring a system event action for Imperva
SecureSphere . . . . . . . . . . . . . 543
Configuring Imperva SecureSphere V11.0 to send
database audit records to QRadar . . . . . . 545
x
QRadar DSM Configuration Guide
.
.
.
.
.
.
.
.
. 547
78 iT-CUBE agileSI . . . . . . . . . 549
73 ISC Bind . . . . . . . . . . . . 529
Configuring a log source
Configuring a log source
Configuring agileSI to forward events .
Configuring an agileSI log source . .
.
.
.
.
.
.
. 549
. 550
79 Itron Smart Meter . . . . . . . . 553
80 Juniper Networks . . . . . . . . 555
Juniper Networks AVT . . . . . . . . . .
Configuring IBM Security QRadar to receive
events from a Juniper Networks AVT device . .
Juniper Networks DDoS Secure . . . . . . .
Juniper Networks DX Application Acceleration
Platform . . . . . . . . . . . . . . .
Configuring IBM Security QRadar to receive
events from a Juniper DX Application
Acceleration Platform . . . . . . . . .
Juniper Networks EX Series Ethernet Switch . . .
Configuring IBM Security QRadar to receive
events from a Juniper EX Series Ethernet Switch
Juniper Networks IDP . . . . . . . . . .
Configure a log source . . . . . . . . .
Juniper Networks Infranet Controller . . . . .
Juniper Networks Firewall and VPN . . . . .
Configuring IBM Security QRadar to receive
events . . . . . . . . . . . . . . .
Juniper Networks Junos OS . . . . . . . .
Configuring QRadar to receive events from a
Juniper Junos OS Platform device . . . . .
Configure the PCAP Protocol . . . . . . .
Configuring a New Juniper Networks SRX Log
Source with PCAP. . . . . . . . . . .
Juniper Networks Network and Security Manager
Configuring Juniper Networks NSM to export
logs to syslog . . . . . . . . . . . .
Configuring a log source for Juniper Networks
NSM . . . . . . . . . . . . . . .
Juniper Networks Secure Access . . . . . . .
Juniper Networks Security Binary Log Collector
Configuring the Juniper Networks Binary Log
Format . . . . . . . . . . . . . .
Configuring a log source . . . . . . . .
Juniper Networks Steel-Belted Radius . . . . .
Configuring Juniper Steel-Belted Radius for
syslog . . . . . . . . . . . . . . .
Juniper Networks vGW Virtual Gateway . . . .
Juniper Networks Junos WebApp Secure . . . .
Configuring syslog forwarding . . . . . .
Configuring event logging . . . . . . . .
Configuring a log source . . . . . . . .
Juniper Networks WLC Series Wireless LAN
Controller . . . . . . . . . . . . . .
Configuring a syslog server from the Juniper
WLC user interface . . . . . . . . . .
Configuring a syslog server with the
command-line interface for Juniper WLC . . .
555
555
557
557
558
558
559
559
560
561
561
561
562
564
564
565
566
566
566
567
567
567
568
569
570
570
571
572
572
573
574
574
575
81 Kaspersky . . . . . . . . . . . 577
Kaspersky Security Center . . . . . . . .
Creating a Database View for Kaspersky
Security Center . . . . . . . . . . .
Exporting syslog to QRadar from Kaspersky
Security Center . . . . . . . . . . .
Kaspersky Threat Feed Service . . . . . .
Configuring Kaspersky Threat Feed Service to
communicate with QRadar . . . . . . .
Configuring QRadar to forward events to the
Kaspersky Threat Feed Service . . . . .
. 577
. 580
. 581
. 582
. 583
. 584
82 Kisco Information Systems
SafeNet/i . . . . . . . . . . . . . 587
Configuring Kisco Information Systems SafeNet/i
to communicate with QRadar . . . . . . . . 588
83 Lastline Enterprise. . . . . . . . 591
Configuring Lastline Enterprise to communicate
with QRadar . . . . . . . . . . . .
. 592
84 Lieberman Random Password
Manager . . . . . . . . . . . . . 593
85 LightCyber Magna . . . . . . . . 595
Configuring LightCyber Magna to communicate
with QRadar . . . . . . . . . . . .
86 Linux
. 596
. . . . . . . . . . . . . 597
Linux DHCP
Configuring
Linux IPtables
Configuring
Configuring
Linux OS . .
Configuring
Configuring
Configuring
. . . . . . . . . .
a log source . . . . .
. . . . . . . . . .
IPtables . . . . . . .
a log source . . . . .
. . . . . . . . . .
syslog on Linux OS . . .
syslog-ng on Linux OS . .
Linux OS to send audit logs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
597
597
597
598
599
599
600
600
601
87 LOGbinder . . . . . . . . . . . 603
LOGbinder EX event collection from Microsoft
Exchange Server . . . . . . . . . . . .
Configuring your LOGbinder EX system to send
Microsoft Exchange event logs to QRadar . . .
LOGbinder SP event collection from Microsoft
SharePoint . . . . . . . . . . . . . .
Configuring your LOGbinder SP system to send
Microsoft SharePoint event logs to QRadar . .
LOGbinder SQL event collection from Microsoft
SQL Server . . . . . . . . . . . . . .
Configuring your LOGbinder SQL system to
send Microsoft SQL Server event logs to QRadar
603
604
604
605
606
607
88 McAfee . . . . . . . . . . . . . 609
McAfee Application / Change Control .
McAfee ePolicy Orchestrator . . . .
Adding a registered server to McAfee
Ochestrator . . . . . . . . .
. . .
. . .
ePolicy
. . .
. 609
. 611
Configuring SNMP notifications on McAfee
ePolicy Orchestrator . . . . . . . . . .
Installing the Java Cryptography Extension on
McAfee ePolicy Orchestrator . . . . . . .
Installing the Java Cryptography Extension on
QRadar . . . . . . . . . . . . . .
McAfee Firewall Enterprise. . . . . . . . .
Configuring McAfee Firewall Enterprise to
communicate with QRadar . . . . . . . .
McAfee Intrushield . . . . . . . . . . .
Configuring alert events for McAfee Intrushield
V2.x - V5.x . . . . . . . . . . . . .
Configuring alert events for McAfee Intrushield
V6.x and V7.x . . . . . . . . . . . .
Configuring fault notification events for McAfee
Intrushield V6.x and V7.x . . . . . . . .
McAfee Web Gateway . . . . . . . . . .
McAfee Web Gateway DSM integration process
Configuring McAfee Web Gateway to
communicate with QRadar (syslog) . . . . .
Importing the Syslog Log Handler . . . . .
Configuring McAfee Web Gateway to
communicate with IBM Security QRadar (log
file protocol). . . . . . . . . . . . .
Pulling data by using the log file protocol . . .
Creation of an event map for McAfee Web
Gateway events . . . . . . . . . . .
Discovering unknown events . . . . . . .
Modifying the event map . . . . . . . .
617
619
619
620
620
621
621
622
623
625
625
626
626
627
628
628
628
629
89 MetaInfo MetaIP . . . . . . . . . 631
90 Microsoft . . . . . . . . . . . . 633
Microsoft Azure . . . . . . . . . . .
Configuring Microsoft Azure Log Integration
service to communicate with QRadar . . .
Configuring Microsoft Azure Event Hubs to
communicate with QRadar . . . . . . .
Configuring a log source to collect events from
Microsoft Azure Event Hubs . . . . . .
Microsoft Azure DSM specifications . . . .
Sample event messages . . . . . . . .
Microsoft DHCP Server . . . . . . . . .
Microsoft DNS Debug . . . . . . . . .
Enabling DNS debugging on Windows Server
Microsoft Endpoint Protection . . . . . . .
Configuring an Endpoint Protection log source
for predefined database queries . . . . .
Microsoft Exchange Server . . . . . . . .
Configuring Microsoft Exchange Server to
communicate with QRadar . . . . . . .
Configuring OWA logs on your Microsoft
Exchange Server . . . . . . . . .
Enabling SMTP logs on your Microsoft
Exchange Server 2003, 2007, and 2010 . .
Enabling SMTP logs on your Microsoft
Exchange Server 2013, and 2016 . . . .
Configuring MSGTRK logs for Microsoft
Exchange 2003, 2007, and 2010 . . . .
. 633
. 634
. 634
.
.
.
.
.
635
637
638
640
641
642
. 643
. 643
. 645
. 646
. 647
. 647
. 648
. 648
. 617
Contents
xi
Configuring MSGTRK logs for Exchange
2013 and 2016 . . . . . . . . . . .
Configuring a log source for Microsoft Exchange
Microsoft Hyper-V . . . . . . . . . . .
Microsoft Hyper-V DSM integration process . .
Configuring a Microsoft Hyper-V log source in
QRadar . . . . . . . . . . . . . .
Microsoft IAS Server . . . . . . . . . . .
Microsoft IIS Server . . . . . . . . . . .
Configuring Microsoft IIS by using the IIS
Protocol . . . . . . . . . . . . . .
Configuring the Microsoft IIS Protocol in IBM
Security QRadar . . . . . . . . . . .
Configuring a Microsoft IIS log source . . . .
Microsoft ISA . . . . . . . . . . . . .
Microsoft Office 365 . . . . . . . . . . .
Configuring Microsoft Office 365 to
communicate with QRadar . . . . . . . .
Configuring Microsoft Office 365 to
communicate with QRadar using the Classic
Azure Management interface . . . . . . .
Microsoft Operations Manager . . . . . . .
Microsoft SharePoint . . . . . . . . . . .
Configuring a database view to collect audit
events . . . . . . . . . . . . . . .
Configuring Microsoft SharePoint audit events
Creating a database view for Microsoft
SharePoint . . . . . . . . . . . . .
Creating read-only permissions for Microsoft
SharePoint database users . . . . . . . .
Configuring a SharePoint log source for a
database view . . . . . . . . . . . .
Configuring a SharePoint log source for
predefined database queries . . . . . . .
Microsoft SQL Server . . . . . . . . . . .
Microsoft SQL Server preparation for
communication with QRadar . . . . . . .
Creating a Microsoft SQL Server auditing
object . . . . . . . . . . . . . .
Creating a Microsoft SQL Server audit
specification . . . . . . . . . . . .
Creating a Microsoft SQL Server database
view . . . . . . . . . . . . . .
Configuring a Microsoft SQL Server log source
Microsoft System Center Operations Manager . .
Microsoft Windows Security Event Log. . . . .
Verifying MSRPC Protocol . . . . . . . .
Verifying MSRPC protocol from the QRadar
Console . . . . . . . . . . . . .
Verifying MSRPC protocol from QRadar user
interface . . . . . . . . . . . . .
Restarting the Web Server . . . . . . .
Installing the MSRPC protocol on the QRadar
Console . . . . . . . . . . . . . .
Enabling MSRPC on Windows hosts. . . . .
Diagnosing connection issues with the MSRPC
test tool . . . . . . . . . . . . . .
Enabling WMI on Windows hosts . . . . .
Configure syslog events for Motorola Symbol AP
649
649
651
651
652
652
653
xii
.
.
.
.
QRadar DSM Configuration Guide
.
.
.
.
92 Name Value Pair . . . . . . . . . 691
93 NCC Group DDoS Secure . . . . . 695
Configuring NCC Group DDoS Secure to
communicate with QRadar . . . . . .
.
.
. 696
94 NetApp Data ONTAP . . . . . . . 697
653
95 Netskope Active . . . . . . . . . 699
654
655
656
656
659
Configuring QRadar to collect events from your
Netskope Active system . . . . . . . . .
. 700
96 Niksun . . . . . . . . . . . . . 701
Configuring a log source
.
.
.
.
.
.
.
.
. 701
97 Nokia Firewall . . . . . . . . . . 703
665
Integration with a Nokia Firewall by using syslog
Configuring IPtables . . . . . . . . . .
Configuring syslog . . . . . . . . . .
Configuring the logged events custom script
Configuring a log source . . . . . . . .
Integration with a Nokia Firewall by using OPSEC
Configuring a Nokia Firewall for OPSEC . . .
Configuring an OPSEC log source . . . . .
666
98 Nominum Vantio . . . . . . . . . 709
666
Configure the Vantio LEEF Adapter .
Configuring a log source . . . .
660
661
664
664
664
669
671
672
672
672
673
673
676
678
679
679
679
679
680
680
683
684
91 Motorola Symbol AP . . . . . . . 689
Configuring a log source
689
. 689
.
.
.
.
.
.
.
.
703
703
704
704
704
705
705
706
. 709
. 709
99 Nortel Networks . . . . . . . . . 711
Nortel Multiprotocol Router . . . . . . .
Nortel Application Switch . . . . . . . .
Nortel Contivity . . . . . . . . . . .
Nortel Ethernet Routing Switch 2500/4500/5500
Nortel Ethernet Routing Switch 8300/8600 . .
Nortel Secure Router . . . . . . . . . .
Nortel Secure Network Access Switch . . . .
Nortel Switched Firewall 5100 . . . . . . .
Integrating Nortel Switched Firewall by using
syslog . . . . . . . . . . . . . .
Integrate Nortel Switched Firewall by using
OPSEC . . . . . . . . . . . . .
Configuring a log source . . . . . . .
Nortel Switched Firewall 6000 . . . . . . .
Configuring syslog for Nortel Switched
Firewalls . . . . . . . . . . . . .
Configuring OPSEC for Nortel Switched
Firewalls . . . . . . . . . . . . .
Reconfiguring the Check Point SmartCenter
Server . . . . . . . . . . . . . .
Nortel Threat Protection System (TPS) . . . .
Nortel VPN Gateway . . . . . . . . . .
. 711
. 713
. 714
714
. 715
. 716
. 717
. 718
. 718
. 719
. 719
. 719
. 720
. 720
. 721
. 721
. 722
100 Novell eDirectory . . . . . . . . 725
Configure XDASv2 to forward events . . . . . 725
Load the XDASv2 Module . . . . . . . . . 726
Loading the XDASv2 on a Linux Operating System 726
Loading the XDASv2 on a Windows Operating
System . . . . . . . . . . . . . .
Configure event auditing using Novell iManager
Configure a log source . . . . . . . . .
. 727
727
. 728
101 Observe IT JDBC . . . . . . . . 729
102 Okta . . . . . . . . . . . . . 733
103 Onapsis Security Platform . . . . 737
Configuring Onapsis Security Platform to
communicate with QRadar . . . . . .
.
.
. 738
104 OpenBSD . . . . . . . . . . . 739
Configuring a log source . . .
Configuring syslog for OpenBSD .
.
.
.
.
.
.
.
.
.
.
. 739
. 739
105 Open LDAP . . . . . . . . . . 741
Configuring
Configuring
events . .
Configuring
a log source . . . . . . . .
IPtables for UDP Multiline Syslog
. . . . . . . . . . . . .
event forwarding for Open LDAP .
. 741
. 742
. 744
106 Open Source SNORT . . . . . . 745
Configuring Open Source SNORT
Configuring a log source . . .
.
.
.
.
.
.
.
.
.
.
. 745
. 746
Configuring the Oracle Database Listener within
QRadar. . . . . . . . . . . . . . .
Oracle Directory Server overview. . . . . . .
Oracle Enterprise Manager . . . . . . . . .
Oracle Fine Grained Auditing . . . . . . . .
Configuring a log source . . . . . . . .
Oracle OS Audit . . . . . . . . . . . .
Configuring the log sources within QRadar for
Oracle OS Audit . . . . . . . . . . .
769
770
770
771
772
774
776
109 OSSEC . . . . . . . . . . . . 777
Configuring OSSEC . .
Configuring a log source
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 777
. 777
110 Palo Alto Networks . . . . . . . 779
Palo Alto Endpoint Security Manager . . . . .
Configuring Palo Alto Endpoint Security
Manager to communicate with QRadar . . . .
Palo Alto Networks PA Series . . . . . . . .
Creating a syslog destination on your Palo Alto
PA Series device . . . . . . . . . . .
Creating a forwarding policy on your Palo Alto
PA Series device . . . . . . . . . . .
Creating ArcSight CEF formatted Syslog events
on your Palo Alto PA Series Networks Firewall
device . . . . . . . . . . . . . . .
779
780
781
782
786
786
111 Pirean Access: One . . . . . . . 789
107 OpenStack. . . . . . . . . . . 747
Configuring a log source
Configuring OpenStack to communicate with
QRadar . . . . . . . . . . . . .
112 PostFix Mail Transfer Agent . . . 793
.
. 748
108 Oracle. . . . . . . . . . . . . 751
Oracle Acme Packet Session Border Controller . .
Supported Oracle Acme Packet event types that
are logged by IBM Security QRadar . . . . .
Configuring an Oracle Acme Packet SBC log
source . . . . . . . . . . . . . . .
Configuring SNMP to syslog conversion on
Oracle Acme Packet SBC . . . . . . . .
Enabling syslog settings on the media manager
object . . . . . . . . . . . . . . .
Oracle Audit Vault . . . . . . . . . . .
Configuring Oracle Audit Vault to communicate
with QRadar . . . . . . . . . . . .
Oracle BEA WebLogic . . . . . . . . . .
Enabling event logs . . . . . . . . . .
Configuring domain logging . . . . . . .
Configuring application logging . . . . . .
Configuring an audit provider. . . . . . .
Configuring a log source . . . . . . . .
Oracle DB Audit . . . . . . . . . . . .
Enabling Unified Auditing in Oracle 12c . . .
Configuring an Oracle database server to send
syslog audit logs to QRadar . . . . . . .
Oracle DB Listener . . . . . . . . . . .
Collecting events by using the Oracle Database
Listener Protocol . . . . . . . . . . .
Collecting Oracle database events by using Perl
751
Configuring
Configuring
Configuring
events . .
.
.
.
.
.
.
.
.
. 789
syslog for PostFix Mail Transfer Agent 793
a PostFix MTA log source . . . . . 793
IPtables for multiline UDP syslog
. . . . . . . . . . . . . . 794
751
113 ProFTPd . . . . . . . . . . . . 797
751
752
753
753
756
756
757
757
757
758
758
760
764
764
766
Configuring ProFTPd. .
Configuring a log source
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 797
. 797
114 Proofpoint Enterprise Protection
and Enterprise Privacy . . . . . . . 799
Configuring Proofpoint Enterprise Protection and
Enterprise Privacy DSM to communicate with IBM
Security QRadar . . . . . . . . . . . . 800
Configuring a Proofpoint Enterprise Protection and
Enterprise Privacy log source . . . . . . . . 800
115 Pulse Secure Pulse Connect
Secure . . . . . . . . . . . . . . 805
Configuring a Pulse Secure Pulse Connect Secure
device to send WebTrends Enhanced Log File
(WELF) events to IBM Security QRadar . . . . 806
Configuring a Pulse Secure Pulse Connect Secure
device to send syslog events to QRadar . . . . 807
Sample event message . . . . . . . . . . 808
766
768
Contents
xiii
116 Radware . . . . . . . . . . . . 809
124 Samhain Labs . . . . . . . . . 837
Radware AppWall . . . . . . . . . . . .
Configuring Radware AppWall to communicate
with QRadar . . . . . . . . . . . .
Increasing the maximum TCP Syslog payload
length for Radware AppWall . . . . . . .
Radware DefensePro . . . . . . . . . . .
Configuring a log source . . . . . . . .
Configuring syslog to collect Samhain events .
Configuring JDBC to collect Samhain events .
809
118 Redback ASE
810
811
812
. 813
. 815
. . . . . . . . . 817
Configuring Redback ASE .
Configuring a log source .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 817
. 817
119 Resolution1 CyberSecurity . . . . 819
Configuring your Resolution1 CyberSecurity device
to communicate with QRadar . . . . . . . . 820
Resolution1 CyberSecurity log source on your
QRadar Console . . . . . . . . . . . . 820
120 Riverbed
. . . . . . . . . . . 821
Riverbed SteelCentral NetProfiler (Cascade
Profiler) Audit . . . . . . . . . . .
Creating a Riverbed SteelCentral NetProfiler
report template and generating an audit file
Riverbed SteelCentral NetProfiler (Cascade
Profiler) Alert . . . . . . . . . . .
Configuring your Riverbed SteelCentral
NetProfiler system to enable communication
with QRadar . . . . . . . . . .
.
. 821
.
. 822
.
. 823
.
. 824
121 RSA Authentication Manager . . . 825
Configuration of syslog for RSA Authentication
Manager 6.x, 7.x and 8.x. . . . . . . .
Configuring Linux. . . . . . . . . .
Configuring Windows . . . . . . . .
Configuring the log file protocol for RSA
Authentication Manager 6.x and 7.x . . . .
Configuring RSA Authentication Manager 6.x
Configuring RSA Authentication Manager 7.x
.
.
.
. 825
. 825
. 826
.
.
.
. 826
. 827
. 827
122 SafeNet DataSecure . . . . . . . 829
Configuring SafeNet DataSecure to communicate
with QRadar . . . . . . . . . . . . . 829
123 Salesforce . . . . . . . . . . . 831
Salesforce Security Auditing . . . . . . .
Downloading the Salesforce audit trail file. .
Configuring a Salesforce Security Auditing log
source in QRadar . . . . . . . . . .
Salesforce Security Monitoring. . . . . . .
Configuring the Salesforce Security Monitoring
server to communicate with QRadar. . . .
Configuring a Salesforce Security Monitoring
log source in QRadar . . . . . . . . .
xiv
QRadar DSM Configuration Guide
. 837
. 838
810
117 Raz-Lee iSecurity . . . . . . . . 813
Configuring Raz-Lee iSecurity to communicate
with QRadar . . . . . . . . . . . .
Configuring a log source for Raz-Lee iSecurity .
.
.
. 831
. 831
. 832
. 832
. 833
. 834
125 Seculert . . . . . . . . . . . . 841
Obtaining an API key
.
.
.
.
.
.
.
.
.
. 842
126 Sentrigo Hedgehog . . . . . . . 843
127 Skyhigh Networks Cloud Security
Platform . . . . . . . . . . . . . 845
Configuring Skyhigh Networks Cloud Security
Platform to communicate with QRadar . . . .
. 846
128 SolarWinds Orion. . . . . . . . 847
Configuring SolarWinds Orion to communicate
with QRadar . . . . . . . . . . . .
Configuring a SolarWinds Orion log source by
using the SNMP protocol . . . . . . . .
Installing the Java Cryptography Extension on
QRadar . . . . . . . . . . . . . .
. 848
. 850
. 852
129 SonicWALL . . . . . . . . . . 853
Configuring SonicWALL to forward syslog events 853
Configuring a log source . . . . . . . . . 853
130 Sophos . . . . . . . . . . . . 855
Sophos Enterprise Console . . . . . . . .
Configuring QRadar using the Sophos
Enterprise Console Protocol . . . . . .
Configure IBM Security QRadar by using the
JDBC protocol . . . . . . . . . . .
Configuring the database view . . . . .
Configuring a JDBC log source in QRadar . .
Sophos PureMessage . . . . . . . . . .
Integrating QRadar with Sophos PureMessage
for Microsoft Exchange . . . . . . . .
Configure a JDBC log source for Sophos
PureMessage . . . . . . . . . . .
Integrating QRadar with Sophos PureMessage
for Linux . . . . . . . . . . . . .
Configuring a log source for Sophos
PureMessage for Microsoft Exchange . . .
Sophos Astaro Security Gateway . . . . . .
Sophos Web Security Appliance . . . . . .
. 855
. 855
.
.
.
.
857
858
858
860
. 861
. 861
. 863
. 864
. 866
. 867
131 Splunk . . . . . . . . . . . . 869
Collect Windows events that are forwarded from
Splunk appliances . . . . . . . . . . . . 869
Configuring a log source for Splunk forwarded
events . . . . . . . . . . . . . . . . 869
132 Squid Web Proxy . . . . . . . . 873
Configuring syslog forwarding
Create a log source . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. 873
. 874
133 SSH CryptoAuditor . . . . . . . 875
Configuring an SSH CryptoAuditor appliance to
communicate with QRadar . . . . . . . .
. 876
134 Starent Networks . . . . . . . . 877
135 STEALTHbits. . . . . . . . . . 881
STEALTHbits StealthINTERCEPT. . . . . . .
Configuring a STEALTHbits StealthINTERCEPT
log source in IBM Security QRadar . . . . .
Configuring your STEALTHbits
StealthINTERCEPT to communicate with
QRadar . . . . . . . . . . . . . .
Configuring your STEALTHbits File Activity
Monitor to communicate with QRadar . . . .
Configuring a log source for STEALTHbits File
Activity Monitor in QRadar . . . . . . .
STEALTHbits StealthINTERCEPT Alerts . . . .
Collecting alerts logs from STEALTHbits
StealthINTERCEPT . . . . . . . . . .
STEALTHbits StealthINTERCEPT Analytics . . .
Collecting analytics logs from STEALTHbits
StealthINTERCEPT . . . . . . . . . .
881
881
881
882
882
884
885
886
Configuring syslog for PGP Universal Server
Configuring a log source . . . . . . .
Symantec SGS . . . . . . . . . . . .
Symantec System Center . . . . . . . .
Configuring a database view for Symantec
System Center . . . . . . . . . . .
Configuring a log source . . . . . . .
912
. 912
. 913
. 913
. 914
. 914
139 Sourcefire Intrusion Sensor . . . 917
Configuring Sourcefire Intrusion Sensor . .
Configuring a log source for Cisco FireSIGHT
Management Center events. . . . . . .
.
. 917
.
. 917
140 ThreatGRID Malware Threat
Intelligence Platform . . . . . . . . 919
Supported event collection protocols for
ThreatGRID Malware Threat Intelligence . . . . 919
ThreatGRID Malware Threat Intelligence
configuration overview . . . . . . . . . . 919
Configuring a ThreatGRID syslog log source
919
Configuring a ThreatGRID log file protocol log
source . . . . . . . . . . . . . . . 920
887
141 TippingPoint . . . . . . . . . . 925
136 Sun . . . . . . . . . . . . . . 889
Sun ONE LDAP . . . . . . . . . . .
Enabling the event log for Sun ONE Directory
Server . . . . . . . . . . . . . .
Configuring a log source for Sun ONE LDAP
Configuring a UDP Multiline Syslog log source
Sun Solaris DHCP . . . . . . . . . . .
Configuring Sun Solaris DHCP . . . . .
Configuring Sun Solaris . . . . . . . .
Sun Solaris Sendmail . . . . . . . . . .
Configuring a Sun Solaris Sendmail log source
Sun Solaris Basic Security Mode (BSM) . . . .
Enabling Basic Security Mode in Solaris 10 .
Enabling Basic Security Mode in Solaris 11 .
Converting Sun Solaris BSM audit logs . . .
Creating a cron job . . . . . . . . .
Configuring a log source for Sun Solaris BSM
. 889
. 889
890
893
. 894
. 894
. 895
. 895
896
. 897
. 897
. 897
. 898
. 899
899
137 Sybase ASE . . . . . . . . . . 903
Configuring IBM Security QRadar SIEM to receive
events from a Sybase ASE device . . . . . . . 904
138 Symantec . . . . . . . . . . . 905
Symantec Critical System Protection . . . . .
Symantec Data Loss Prevention (DLP) . . . .
Creating an SMTP response rule . . . . .
Creating a None Of SMTP response rule . .
Configuring a log source . . . . . . .
Event map creation for Symantec DLP events
Discovering unknown events . . . . . .
Modifying the event map . . . . . . .
Symantec Endpoint Protection . . . . . . .
Configuring Symantec Endpoint Protection to
Communicate with QRadar. . . . . . .
Symantec PGP Universal Server . . . . . .
.
.
.
.
.
905
906
906
907
908
908
. 908
. 909
. 910
. 911
. 912
Tipping Point Intrusion Prevention System
Configure remote syslog for SMS . . .
Configuring notification contacts for LSM
Configuring an Action Set for LSM . .
Tipping Point X505/X506 Device . . . .
Configuring syslog . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
925
925
926
926
927
927
142 Top Layer IPS . . . . . . . . . 929
143 Townsend Security LogAgent . . 931
Configuring Raz-Lee iSecurity .
Configuring a log source . .
.
.
.
.
.
.
.
.
.
.
.
.
. 931
. 931
144 Trend Micro . . . . . . . . . . 933
Trend Micro Control Manager . . . . . . . .
Configuring a log source . . . . . . . .
Configuring SNMP traps . . . . . . . .
Trend Micro Deep Discovery Analyzer . . . . .
Configuring your Trend Micro Deep Discovery
Analyzer instance for communication with
QRadar . . . . . . . . . . . . . .
Trend Micro Deep Discovery Email Inspector. . .
Configuring Trend Micro Deep Discovery Email
Inspector to communicate with QRadar . . .
Trend Micro Deep Discovery Inspector . . . . .
Configuring Trend Micro Deep Discovery
Inspector V3.0 to send events to QRadar . . .
Configuring Trend Micro Deep Discovery
Inspector V3.8 to send Events to QRadar . . .
Trend Micro Deep Security . . . . . . . . .
Configuring Trend Micro Deep Security to
communicate with QRadar . . . . . . . .
Trend Micro InterScan VirusWall . . . . . . .
Trend Micro Office Scan . . . . . . . . . .
Integrating with Trend Micro Office Scan 8.x
Contents
933
933
934
934
935
936
937
938
939
939
940
941
942
942
942
xv
Integrating with Trend Micro Office Scan 10.x
Configuring General Settings . . . . .
Configure Standard Notifications . . . .
Configuring Outbreak Criteria and Alert
Notifications. . . . . . . . . . .
Integrating with Trend Micro OfficeScan XG .
Configuring General Settings in OfficeScan
XG . . . . . . . . . . . . . .
Configuring Administrator Notifications in
OfficeScan XG . . . . . . . . . .
Configuring Outbreak Notifications in
OfficeScan XG . . . . . . . . . .
943
. 943
. 944
. 944
. 945
. 945
. 945
. 946
145 Tripwire . . . . . . . . . . . . 947
146 Tropos Control . . . . . . . . . 949
147 Universal . . . . . . . . . . . 951
Universal CEF . . . . . . . . . . . .
Configuring event mapping for Universal CEF
events . . . . . . . . . . . . . .
Universal LEEF. . . . . . . . . . . .
Configuring a Universal LEEF log source . .
Configuring the log file protocol to collect
Universal LEEF events . . . . . . .
Forwarding events to IBM Security QRadar .
Universal LEEF event map creation . . . .
Discovering unknown events . . . . .
Modifying an event map . . . . . .
. 951
. 952
. 953
. 953
.
.
.
.
.
954
956
957
957
957
148 Vectra Networks Vectra . . . . . 959
Configuring Vectra Networks Vectra to
communicate with QRadar . . . . .
.
.
.
. 960
149 Venustech Venusense . . . . . . 961
Venusense configuration overview . .
Configuring a Venusense syslog server .
Configuring Venusense event filtering .
Configuring a Venusense log source . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
961
961
961
962
150 Verdasys Digital Guardian . . . . 963
Configuring IPtables . . .
Configuring a data export .
Configuring a log source .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 963
. 964
. 965
151 Vericept Content 360 DSM . . . . 967
152 VMWare . . . . . . . . . . . . 969
VMware ESX and ESXi . . . . . . . . . .
Configuring syslog on VMware ESX and ESXi
servers . . . . . . . . . . . . . .
Enabling syslog firewall settings on vSphere
Clients . . . . . . . . . . . . . .
Enabling syslog firewall settings on vSphere
Clients by using the esxcli command . . .
Configuring a syslog log source for VMware
ESX or ESXi . . . . . . . . . . . . .
Configuring the EMC VMWare protocol for ESX
or ESXi servers . . . . . . . . . . . .
xvi
QRadar DSM Configuration Guide
969
Creating an account for QRadar in ESX. . . .
Configuring read-only account permissions . .
Configuring a log source for the EMC VMWare
protocol . . . . . . . . . . . . . .
VMware vCenter . . . . . . . . . . . .
Configuring a log source for the VMware
vCenter . . . . . . . . . . . . . .
VMware vCloud Director . . . . . . . . .
Configuring the vCloud REST API public
address . . . . . . . . . . . . . .
Supported VMware vCloud Director event types
logged by IBM Security QRadar . . . . . .
Configuring a VMware vCloud Director log
source in IBM Security QRadar . . . . . .
VMware vShield . . . . . . . . . . . .
VMware vShield DSM integration process . . .
Configuring your VMware vShield system for
communication with IBM Security QRadar . .
Configuring a VMware vShield log source in
IBM Security QRadar . . . . . . . . . .
971
972
972
973
973
973
974
974
975
976
976
977
977
153 Vormetric Data Security . . . . . 979
Vormetric Data Security DSM integration process
Configuring your Vormetric Data Security systems
for communication with IBM Security QRadar . .
Configuring Vormetric Data Firewall FS Agents to
bypass Vormetric Data Security Manager . . . .
Configuring a Vormetric Data Security log source
in IBM Security QRadar . . . . . . . . . .
979
980
980
981
154 WatchGuard Fireware OS . . . . 983
Configuring your WatchGuard Fireware OS
appliance in Policy Manager for communication
with QRadar . . . . . . . . . . . . . 983
Configuring your WatchGuard Fireware OS
appliance in Fireware XTM for communication
with QRadar . . . . . . . . . . . . . 984
Configuring a WatchGuard Fireware OS log source
in QRadar . . . . . . . . . . . . . . 985
155 Websense . . . . . . . . . . . 987
156 Zscaler Nanolog Streaming
Service . . . . . . . . . . . . . . 989
Configuring a syslog feed in Zscaler NSS .
Configuring a Zscaler NSS log source . .
157 QRadar supported DSMs
.
.
.
.
. 989
. 990
. . . . 993
Part 4. Appendixes . . . . . . . 1007
969
Notices . . . . . . . . . . . . . 1009
970
970
970
971
Trademarks . . . . . . .
Terms and conditions for product
IBM Online Privacy Statement .
Privacy policy considerations. .
. . . . . . 1010
documentation 1011
. . . . . . 1011
. . . . . . 1012
Glossary . . . . . . . . . . . . . 1013
A
B
C
D
E
F
G
H
I
K
L
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1013
1013
1013
1014
1014
1014
1015
1015
1015
1015
1015
M.
N .
O .
P .
Q .
R .
S .
T .
V .
W.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1016
1016
1016
1017
1017
1017
1018
1018
1018
1019
Index . . . . . . . . . . . . . . 1021
Contents
xvii
xviii
QRadar DSM Configuration Guide
About this DSM Configuration Guide
The DSM Configuration guide provides instructions about how to collect data from your third-party
devices, also known as log sources.
You can configure IBM® Security QRadar® to accept event logs from log sources that are on your
network. A log source is a data source that creates an event log.
Note: This guide describes the Device Support Modules (DSMs) that are produced by IBM. Third-party
DSMs are available on the IBM App Exchange, but are not documented here.
Intended audience
System administrators must have QRadar access, knowledge of the corporate network security concepts
and device configurations.
Technical documentation
To find IBM Security QRadar product documentation on the web, including all translated documentation,
access the IBM Knowledge Center (http://www.ibm.com/support/knowledgecenter/SS42VS/welcome).
For information about how to access more technical documentation in the QRadar products library, see
Accessing IBM Security Documentation Technical Note (www.ibm.com/support/docview.wss?rs=0
&uid=swg21614644).
Contacting customer support
For information about contacting customer support, see the Support and Download Technical Note
(http://www.ibm.com/support/docview.wss?uid=swg21616144).
Statement of good security practices
IT system security involves protecting systems and information through prevention, detection and
response to improper access from within and outside your enterprise. Improper access can result in
information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of
your systems, including for use in attacks on others. No IT system or product should be considered
completely secure and no single product, service or security measure can be completely effective in
preventing improper use or access. IBM systems, products and services are designed to be part of a
lawful comprehensive security approach, which will necessarily involve additional operational
procedures, and may require other systems, products or services to be most effective. IBM DOES NOT
WARRANT THAT ANY SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE
YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.
Please Note:
Use of this Program may implicate various laws or regulations, including those related to privacy, data
protection, employment, and electronic communications and storage. IBM Security QRadar may be used
only for lawful purposes and in a lawful manner. Customer agrees to use this Program pursuant to, and
assumes all responsibility for complying with, applicable laws, regulations and policies. Licensee
represents that it will obtain or has obtained any consents, permissions, or licenses required to enable its
lawful use of IBM Security QRadar.
© Copyright IBM Corp. 2005, 2018
xix
xx
QRadar DSM Configuration Guide
Part 1. QRadar DSM installation and log source management
© Copyright IBM Corp. 2005, 2018
1
2
QRadar DSM Configuration Guide
1 Event collection from third-party devices
To configure event collection from third-party devices, you need to complete configuration tasks on the
third-party device, and your QRadar Console, Event Collector, or Event Processor. The key components
that work together to collect events from third-party devices are log sources, DSMs, and automatic
updates.
Log sources
A log source is any external device, system, or cloud service that is configured to either send events to
your IBM Security QRadar system or be collected by your QRadar system. QRadar shows events from
log sources in the Log Activity tab.
To receive raw events from log sources, QRadar supports several protocols, including syslog from OS,
applications, firewalls, IPS/IDS, SNMP, SOAP, JDBC for data from database tables and views. QRadar
also supports proprietary vendor-specific protocols such as OPSEC/LEA from Checkpoint.
DSMs
A Device Support Module (DSM) is a code module that parses received events from multiple log sources
and converts them to a standard taxonomy format that can be displayed as output. Each type of log
source has a corresponding DSM. For example, the IBM Fiberlink MaaS360 DSM parses and normalizes
events from an IBM Fiberlink MaaS360 log source.
Automatic Updates
QRadar provides daily and weekly automatic updates on a recurring schedule. The weekly automatic
update includes new DSM releases, corrections to parsing issues, and protocol updates. For more
information about automatic updates, see the IBM Security QRadar Administration Guide.
Third-party device installation process
To collect events from third-party device, you must complete installation and configuration steps on both
the log source device and your QRadar system. For some third-party devices, extra configuration steps
are needed, such as configuring a certificate to enable communication between that device and QRadar.
The following steps represent a typical installation process:
1. Read the specific instructions for how to integrate your third-party device.
2. Download and install the RPM for your third-party device. RPMs are available for download from the
IBM support website (http://www.ibm.com/support).
Tip: If your QRadar system is configured to accept automatic updates, this step might not be
required.
3. Configure the third-party device to send events to QRadar.
After some events are received, QRadar automatically detects some third-party devices and creates a
log source configuration. The log source is listed on the Log Sources list and contains default
information. You can customize the information.
4. If QRadar does not automatically detect the log source, manually add a log source. The list of
supported DSMs and the device-specific topics indicate which third-party devices are not
automatically detected.
5. Deploy the configuration changes and restart your web services.
© Copyright IBM Corp. 2005, 2018
3
Universal DSMs for unsupported third-party log sources
After the events are collected and before the correlation can begin, individual events from your devices
must be properly normalized. Normalization means to map information to common field names, such as
event name, IP addresses, protocol, and ports. If an enterprise network has one or more network or
security devices that QRadar does not provide a corresponding DSM, you can use the Universal DSM.
QRadar can integrate with most devices and any common protocol sources by using the Universal DSM.
To configure the Universal DSM, you must use device extensions to associate a Universal DSM to
devices. Before you define device extension information in the Log Sources window in the Admin tab,
you must create an extensions document for the log source.
For more information about Universal DSMs, see the IBM support website (http://www.ibm.com/
support).
Adding a DSM
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
Restriction: Uninstalling a Device Support Module (DSM) is not supported in QRadar.
Before you begin
Note: The rpm -Uvh <rpm_filename> command line to install was replaced with the yum -y install
<rpm_filename> command.
Procedure
1. Download the DSM RPM file from the IBM support website (http://www.ibm.com/support).
2. Copy the RPM file to your QRadar Console.
3. Using SSH, log in to the QRadar host as the root user.
4. Navigate to the directory that includes the downloaded file.
5. Type the following command:
yum -y install <rpm_filename>
6. Log in to the QRadar user interface.
7. On the Admin tab, click Deploy Changes.
Related concepts:
8, “3Com Switch 8800,” on page 97
The IBM Security QRadar DSM for 3Com Switch 8800 receives events by using syslog.
10, “Akamai Kona,” on page 101
The IBM Security QRadar DSM for Akamai KONA collects event logs from your Akamai KONA servers.
Adding a log source
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
4
QRadar DSM Configuration Guide
About this task
The following table describes the common log source parameters for all log source types:
Table 1. Log source parameters
Parameter
Description
Log Source Identifier
The IPv4 address or host name that identifies the log
source.
If your network contains multiple devices that are
attached to a single management console, specify the IP
address of the individual device that created the event. A
unique identifier for each, such as an IP address,
prevents event searches from identifying the
management console as the source for all of the events.
Enabled
When this option is not enabled, the log source does not
collect events and the log source is not counted in the
license limit.
Credibility
Credibility is a representation of the integrity or validity
of events that are created by a log source. The credibility
value that is assigned to a log source can increase or
decrease based on incoming events or adjusted as a
response to user-created event rules. The credibility of
events from log sources contributes to the calculation of
the offense magnitude and can increase or decrease the
magnitude value of an offense.
Target Event Collector
Specifies the QRadar Event Collector that polls the
remote log source.
Use this parameter in a distributed deployment to
improve Console system performance by moving the
polling task to an Event Collector.
Coalescing Events
Increases the event count when the same event occurs
multiple times within a short time interval. Coalesced
events provide a way to view and determine the
frequency with which a single event type occurs on the
Log Activity tab.
When this check box is clear, events are viewed
individually and events are not bundled.
New and automatically discovered log sources inherit
the value of this check box from the System Settings
configuration on the Admin tab. You can use this check
box to override the default behavior of the system
settings for an individual log source.
Procedure
1. Click the Admin tab.
2. Click the Log Sources icon.
3. Click Add.
4. Configure the common parameters for your log source.
5. Configure the protocol-specific parameters for your log source.
6. Click Save.
7. On the Admin tab, click Deploy Changes.
1 Event collection from third-party devices
5
Related concepts:
8, “3Com Switch 8800,” on page 97
The IBM Security QRadar DSM for 3Com Switch 8800 receives events by using syslog.
10, “Akamai Kona,” on page 101
The IBM Security QRadar DSM for Akamai KONA collects event logs from your Akamai KONA servers.
Adding bulk log sources
You can add up to 500 Microsoft Windows or Universal DSM log sources at one time. When you add
multiple log sources at one time, you add a bulk log source in QRadar. Bulk log sources must share a
common configuration.
Procedure
1. Click the Admin tab.
2. Click the Log Sources icon.
3. From the Bulk Actions list, select Bulk Add.
4. Configure the parameters for the bulk log source.
v File Upload - Upload a text file that has one host name or IP per line
v Manual - Enter the host name or IP of the host that you wish to add
5. Click Save.
6. Click Continue to add the log sources.
7. On the Admin tab, click Deploy Changes.
Adding a log source parsing order
You can assign a priority order for when the events are parsed by the target event collector.
About this task
You can order the importance of the log sources by defining the parsing order for log sources that share a
common IP address or host name. Defining the parsing order for log sources ensures that certain log
sources are parsed in a specific order, regardless of changes to the log source configuration. The parsing
order ensures that system performance is not affected by changes to log source configuration by
preventing unnecessary parsing. The parsing order ensures that low-level event sources are not parsed
for events before more important log source.
Procedure
1. Click the Admin tab.
2. Click the Log Source Parsing Ordering icon.
3. Select a log source.
4. Optional: From the Selected Event Collector list, select the Event Collector to define the log source
parsing order.
5. Optional: From the Log Source Host list, select a log source.
6. Prioritize the log source parsing order.
7. Click Save.
6
QRadar DSM Configuration Guide
Part 2. Log sources
© Copyright IBM Corp. 2005, 2018
7
8
QRadar DSM Configuration Guide
2 Introduction to log source management
You can configure IBM Security QRadar to accept event logs from log sources that are on your network.
A log source is a data source that creates an event log.
For example, a firewall or intrusion protection system (IPS) logs security-based events, and switches or
routers logs network-based events.
To receive raw events from log sources, QRadar supports many protocols. Passive protocols listen for
events on specific ports. Active protocols use APIs or other communication methods to connect to external
systems that poll and retrieve events.
Depending on your license limits, QRadar can read and interpret events from more than 300 log sources.
To configure a log source for QRadar, you must do the following tasks:
1. Download and install a device support module (DSM) that supports the log source. A DSM is
software application that contains the event patterns that are required to identify and parse events
from the original format of the event log to the format that QRadar can use.
2. If automatic discovery is supported for the DSM, wait for QRadar to automatically add the log source
to your list of configured log sources.
3. If automatic discover is not supported for the DSM, manually create the log source configuration.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Adding bulk log sources” on page 6
You can add up to 500 Microsoft Windows or Universal DSM log sources at one time. When you add
multiple log sources at one time, you add a bulk log source in QRadar. Bulk log sources must share a
common configuration.
“Adding a log source parsing order” on page 6
You can assign a priority order for when the events are parsed by the target event collector.
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
© Copyright IBM Corp. 2005, 2018
9
10
QRadar DSM Configuration Guide
3 Adding a log source
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
About this task
The following table describes the common log source parameters for all log source types:
Table 2. Log source parameters
Parameter
Description
Log Source Identifier
The IPv4 address or host name that identifies the log
source.
If your network contains multiple devices that are
attached to a single management console, specify the IP
address of the individual device that created the event. A
unique identifier for each, such as an IP address,
prevents event searches from identifying the
management console as the source for all of the events.
Enabled
When this option is not enabled, the log source does not
collect events and the log source is not counted in the
license limit.
Credibility
Credibility is a representation of the integrity or validity
of events that are created by a log source. The credibility
value that is assigned to a log source can increase or
decrease based on incoming events or adjusted as a
response to user-created event rules. The credibility of
events from log sources contributes to the calculation of
the offense magnitude and can increase or decrease the
magnitude value of an offense.
Target Event Collector
Specifies the QRadar Event Collector that polls the
remote log source.
Use this parameter in a distributed deployment to
improve Console system performance by moving the
polling task to an Event Collector.
Coalescing Events
Increases the event count when the same event occurs
multiple times within a short time interval. Coalesced
events provide a way to view and determine the
frequency with which a single event type occurs on the
Log Activity tab.
When this check box is clear, events are viewed
individually and events are not bundled.
New and automatically discovered log sources inherit
the value of this check box from the System Settings
configuration on the Admin tab. You can use this check
box to override the default behavior of the system
settings for an individual log source.
© Copyright IBM Corp. 2005, 2018
11
Procedure
1. Click the Admin tab.
2. Click the Log Sources icon.
3. Click Add.
4. Configure the common parameters for your log source.
5. Configure the protocol-specific parameters for your log source.
6. Click Save.
7. On the Admin tab, click Deploy Changes.
Related concepts:
8, “3Com Switch 8800,” on page 97
The IBM Security QRadar DSM for 3Com Switch 8800 receives events by using syslog.
10, “Akamai Kona,” on page 101
The IBM Security QRadar DSM for Akamai KONA collects event logs from your Akamai KONA servers.
Blue Coat Web Security Service REST API protocol configuration
options
To receive events from Blue Coat Web Security Service, configure a log source to use the Blue Coat Web
Security Service REST API protocol.
The Blue Coat Web Security Service REST API protocol queries the Blue Coat Web Security Service Sync
API and retrieves recently hardened log data from the cloud.
The following table describes the protocol-specific parameters for the Blue Coat Web Security Service
REST API protocol:
Table 3. Blue Coat Web Security Service REST API protocol parameters
Parameter
Description
API Username
The API user name that is used for authenticating with the Blue Coat Web
Security Service. The API user name is configured through the Blue Coat
Threat Pulse Portal.
Password
The password that is used for authenticating with the Blue Coat Web
Security Service.
Confirm Password
Confirmation of the Password field.
Use Proxy
When you configure a proxy, all traffic for the log source travels through
the proxy for QRadar to access the Blue Coat Web Security Service.
Configure the Proxy IP or Hostname, Proxy Port, Proxy Username, and
Proxy Password fields. If the proxy does not require authentication, you can
leave the Proxy Username and Proxy Password fields blank.
Automatically Acquire Server
Certificate(s)
If you select Yes from the list, QRadar downloads the certificate and begins
trusting the target server.
Recurrence
You can specify when the log collects data. The format is M/H/D for
Months/Hours/Days. The default is 5 M.
EPS Throttle
The upper limit for the maximum number of events per second (EPS). The
default is 5000.
12
QRadar DSM Configuration Guide
Centrify Redrock REST API protocol configuration options
The Centrify Redrock REST API protocol for IBM Security QRadar collects events from Centrify Identity
Platform.
The following parameters require specific values to collect events from Centrify Identity Platform:
Table 4. Centrify Redrock REST API protocol log source parameters
Parameter
Value
Log Source type
Centrify Identity Platform
Protocol Configuration
Centrify Redrock REST API
Log Source Identifier
Type a unique name for the log source.
The Log Source Identifier can be any valid value and
does not need to reference a specific server. The Log
Source Identifier can be the same value as the Log
Source Name. If you have more than one Centrify
Identity Platform log source that is configured, you
might want to identify the first log source as centrify1,
the second log source as centrify2, and the third log
source as centrify3.
Tenant ID
The Centrify assigned unique customer or tenant ID.
Username
The user name that is associated with the Cloud service
for Centrify Identity Platform.
Password
The password that is associated with the Centrify
Identity Platform user name.
Event Logging Filter
Select the logging level of the events that you want to
retrieve. Info, Warning and Error are selectable. At least
one filter must be selected.
Use Proxy
When a proxy is configured, all traffic from the Centrify
Redrock REST API travels through the proxy.
Configure the Proxy Server, Proxy Port, Proxy
Username, and Proxy Password fields. If the proxy does
not require authentication, you can leave the Proxy
Username and Proxy Password fields blank.
Automatically Acquire Server Certificate(s)
Select Yes for QRadar to automatically download the
server certificate and begin trusting the target server.
EPS Throttle
The maximum number of events per second.
The default is 5000.
Recurrence
The time interval can be in hours (H), minutes (M) or
days (D).
The default is 5 minutes (5M).
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
3 Adding a log source
13
Cisco Firepower eStreamer protocol configuration options
To collect events in IBM Security QRadar from a Cisco Firepower eStreamer (Event Streamer) service,
configure a log source to use the Cisco Firepower eStreamer protocol.
Cisco Firepower eStreamer protocol is formerly known as Sourcefire Defense Center eStreamer protocol.
Events are streamed to QRadar to be processed after the Cisco FireSIGHT Management Center DSM is
configured.
The following table describes the protocol-specific parameters for the Cisco Firepower eStreamer protocol:
Table 5. Cisco Firepower eStreamer protocol parameters
Parameter
Description
Protocol Configuration
Cisco Firepower eStreamer
Server Port
The port number that the Firepower eStreamer services is configured to
accept connection requests on.
The default port that QRadar uses for Cisco Firepower eStreamer is 8302.
Keystore Filename
The directory path and file name for the keystore private key and associated
certificate. By default, the import script creates the keystore file in the
following directory: /opt/qradar/conf/estreamer.keystore
Truststore Filename
The truststore file contains the certificates that are trusted by the client. By
default, the import script creates the truststore file in the following
directory: /opt/qradar/conf/estreamer.truststore
Request Extra Data
Select this option to request intrusion event extra data from FireSIGHT
Management Center eStreamer, for example, extra data includes the original
IP address of an event.
Domain
The domain where the events are streamed from.
The value in the Domain field must be a fully qualified domain. This means
that all ancestors of the desired domain must be listed starting with the
top-level domain and ending with the leaf domain that you want to request
events from.
Example:
Global is the top level domain, B is a second level domain that is a
subdomain of Global, and C is a third-level domain and a leaf domain that
is a subdomain of B. To request events from C, type the following value for
the Domain parameter:
Global \ B \ C
Cisco NSEL protocol configuration options
To monitor NetFlow packet flows from a Cisco Adaptive Security Appliance (ASA), configure the Cisco
Network Security Event Logging (NSEL) protocol source.
To integrate Cisco NSEL with QRadar, you must manually create a log source to receive NetFlow events.
QRadar does not automatically discover or create log sources for syslog events from Cisco NSEL.
The following table describes the protocol-specific parameters for the Cisco NSEL protocol:
14
QRadar DSM Configuration Guide
Table 6. Cisco NSEL protocol parameters
Parameter
Description
Protocol Configuration
Cisco NSEL
Log Source Identifier
If the network contains devices that are attached to a management console,
you can specify the IP address of the individual device that created the
event. A unique identifier for each, such as an IP address, prevents event
searches from identifying the management console as the source for all of
the events.
Collector Port
The UDP port number that Cisco ASA uses to forward NSEL events.
QRadar uses port 2055 for flow data on QRadar QFlow Collectors. You must
assign a different UDP port on the Cisco Adaptive Security Appliance for
NetFlow.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
EMC VMware protocol configuration options
To receive event data from the VMWare web service for virtual environments, configure a log source to
use the EMC VMware protocol.
IBM Security QRadar supports the following event types for the EMC VMware protocol:
v Account Information
v Notice
v Warning
v Error
v System Informational
v System Configuration
v System Error
v User Login
v Misc Suspicious Event
v Access Denied
v Information
v Authentication
v Session Tracking
The following table describes the protocol-specific parameters for the EMC VMware protocol:
Table 7. EMC VMware protocol parameters
Parameter
Description
Protocol Configuration
EMC VMware
Log Source Identifier
The value for this parameter must match the VMware IP parameter.
VMware IP
The IP address of the VMWare ESXi server. The VMware protocol appends
the IP address of your VMware ESXi server with HTTPS before the protocol
requests event data.
3 Adding a log source
15
Forwarded protocol configuration options
To receive events from another Console in your deployment, configure a log source to use the Forwarded
protocol.
The Forwarded protocol is typically used to forward events to another QRadar Console. For example,
Console A has Console B configured as an off-site target. Data from automatically discovered log sources
is forwarded to Console B. Manually created log sources on Console A must also be added as a log
source to Console B with the forwarded protocol.
HTTP Receiver protocol configuration options
To collect events from devices that forward HTTP or HTTPS requests, configure a log source to use the
HTTP Receiver protocol
The HTTP Receiver acts as an HTTP server on the configured listening port and converts the request
body of any received POST requests into events. It supports both HTTPS and HTTP requests.
The following table describes the protocol-specific parameters for the HTTP Receiver protocol:
Table 8. HTTP Receiver protocol parameters
Parameter
Description
Protocol Configuration
From the list, select HTTP Receiver.
Log Source Identifier
The IP address, host name, or any name to identify the device.
Must be unique for the log source type.
Communication Type
Select HTTP, or HTTPs, or HTTPs and Client Authentication.
Client Certificate Path
If you select HTTPs and Client Authentication as the communication type,
you must set the absolute path to the client certificate. You must copy the
client certificate to the QRadar Console or the Event Collector for the log
source.
Listen Port
The port that is used by QRadar to accept incoming HTTP Receiver events.
The default port is 12469.
Message Pattern
Denotes the start of each event.
EPS Throttle
The maximum number of events per second (EPS) that you do not want this
protocol to exceed. The default is 5000.
IBM BigFix SOAP protocol configuration options
To receive Log Extended Event Format (LEEF) formatted events from IBM BigFix® appliances, configure a
log source that uses the IBM BigFix SOAP protocol.
This protocol requires IBM BigFix versions 8.2.x to 9.5.2, and the Web Reports application for IBM BigFix.
The IBM BigFix SOAP protocol retrieves events in 30-second intervals over HTTP or HTTPS. As events
are retrieved, the IBM BigFix DSM parses and categorizes the events.
The following table describes the protocol-specific parameters for the IBM BigFix SOAP protocol:
Table 9. IBM BigFix SOAP protocol parameters
Parameter
Description
Protocol Configuration
IBM BigFix SOAP
16
QRadar DSM Configuration Guide
Table 9. IBM BigFix SOAP protocol parameters (continued)
Parameter
Description
Use HTTPS
If a certificate is required to connect with HTTPS, copy the required
certificates to the following directory: /opt/qradar/conf/
trusted_certificates. Certificates that have following file extensions: .crt,
.cert, or .der are supported. Copy the certificates to the trusted certificates
directory before the log source is saved and deployed.
SOAP Port
By default, port 80 is the port number for communicating with IBM BigFix.
Most configurations use port 443 for HTTPS communications.
JDBC protocol configuration options
QRadar uses the JDBC protocol to collect information from tables or views that contain event data from
several database types.
The following table describes the protocol-specific parameters for the JDBC protocol:
Table 10. JDBC protocol parameters
Parameter
Description
Log Source Name
Type a unique name for the log source.
Log Source Description
Type a description for the log source.
Log Source Type
Select your Device Support Module (DSM) that uses the JDBC protocol from
the Log Source Type list.
Protocol Configuration
JDBC
Log Source Identifier
The Log Source Identifier value must follow the <database name>@<ip or
hostname> format. The <database name> must match the Database Name
parameter value and <ip or hostname> must match the IP or Hostname
parameter value.
Note: If you have more than one JDBC log source of the same log source
type that connects to the same database on the same host, the Log Source
Identifier value must follow the <table name>|<database name>@<ip or
hostname> format. The <table name> must match the Table Name parameter
value.
Database Type
Select the type of database that contains the events.
Database Name
The database name must match the database name that is specified in the
Log Source Identifier field.
IP or Hostname
The IP address or host name of the database server.
3 Adding a log source
17
Table 10. JDBC protocol parameters (continued)
Parameter
Description
Port
Enter the JDBC port. The JDBC port must match the listener port that is
configured on the remote database. The database must permit incoming
TCP connections. The valid range is 1 - 65535.
The defaults are:
v MSDE - 1433
v Postgres - 5432
v MySQL - 3306
v Sybase - 1521
v Oracle - 1521
v Informix® - 9088
v DB2® - 50000
If a database instance is used with the MSDE database type, you must leave
the Port field blank.
Username
A user account for QRadar in the database.
Password
The password that is required to connect to the database.
Confirm Password
The password that is required to connect to the database.
Authentication Domain (MSDE only) The domain for MSDE databases that are a Windows domain. If your
network does not use a domain, leave this field blank.
Database Instance (MSDE or
Informix only)
The database instance, if required. MSDE databases can include multiple
SQL server instances on one server.
When a non-standard port is used for the database or access is blocked to
port 1434 for SQL database resolution, the Database Instance parameter
must be blank in the log source configuration.
Predefined Query
Select a predefined database query for the log source. If a predefined query
is not available for the log source type, administrators can select the none
option.
Table Name
The name of the table or view that includes the event records. The table
name can include the following special characters: dollar sign ($), number
sign (#), underscore (_), en dash (-), and period (.).
Select List
The list of fields to include when the table is polled for events. You can use
a comma-separated list or type an asterisk (*) to select all fields from the
table or view. If a comma-separated list is defined, the list must contain the
field that is defined in the Compare Field.
Compare Field
A numeric value or time stamp field from the table or view that identifies
new events that are added to the table between queries. Enables the
protocol to identify events that were previously polled by the protocol to
ensure that duplicate events are not created.
Use Prepared Statements
Prepared statements enable the JDBC protocol source to set up the SQL
statement, and then run the SQL statement numerous times with different
parameters. For security and performance reasons, most JDBC protocol
configurations can use prepared statements.
Start Date and Time
Type the start date and time for database polling in the following format:
yyyy-MM-dd HH:mm with HH specified by using a 24-hour clock. If the
start date or time is clear, polling begins immediately and repeats at the
specified polling interval.
18
QRadar DSM Configuration Guide
Table 10. JDBC protocol parameters (continued)
Parameter
Description
Polling Interval
Enter the amount of time between queries to the event table. To define a
longer polling interval, append H for hours or M for minutes to the numeric
value
The maximum polling interval is one week.
EPS Throttle
The number of Events Per Second (EPS) that you do not want this protocol
to exceed. The valid range is 100 - 20,000.
Use Named Pipe Communication
(MSDE only)
MSDE databases require the user name and password field to use a
Windows authentication user name and password and not the database user
name and password. The log source configuration must use the default that
is named pipe on the MSDE database.
Database Cluster Name (MSDE only) This field appears if the Use Named Pipe Communication box is selected. If
you are running your SQL server in a cluster environment, define the
cluster name to ensure named pipe communication functions properly.
Use NTLMv2 (MSDE only)
Select this option if you want MSDE connections to use the NTLMv2
protocol when they are communicating with SQL servers that require
NTLMv2 authentication. This option does not interrupt communications for
MSDE connections that do not require NTLMv2 authentication.
Does not interrupt communications for MSDE connections that do not
require NTLMv2 authentication.
Use SSL (MSDE only)
Select this option if your connection supports SSL. This option appears only
for MSDE.
Use Oracle Encryption
Oracle Encryption and Data Integrity settings is also known as Oracle Advanced
Security.
If selected, Oracle JDBC connections require the server to support similar
Oracle Data Encryption settings as the client.
Database Locale (Informix only)
For multilingual installations, use this field to specify the language to use.
Code-Set (Informix only)
This field appears after you choose a language for multilingual installations.
Use this field to specify the character set to use.
Enabled
Select this check box to enable the log source. By default, the check box is
selected.
Credibility
From the list, select the Credibility of the log source. The range is 0 - 10.
The credibility indicates the integrity of an event or offense as determined
by the credibility rating from the source devices. Credibility increases if
multiple sources report the same event. The default is 5.
Target Event Collector
Select the Target Event Collector to use as the target for the log source.
Coalescing Events
Select the Coalescing Events check box to enable the log source to coalesce
(bundle) events.
By default, automatically discovered log sources inherit the value of the
Coalescing Events list from the System Settings in QRadar. When you create
a log source or edit an existing configuration, you can override the default
value by configuring this option for each log source.
Store Event Payload
Select the Store Event Payload check box to enable the log source to store
event payload information.
By default, automatically discovered log sources inherit the value of the
Store Event Payload list from the System Settings in QRadar. When you
create a log source or edit an existing configuration, you can override the
default value by configuring this option for each log source.
3 Adding a log source
19
Related information:
Configuring JDBC Over SSL with a Self-signed Certificate
Configuring JDBC Over SSL with an Externally-signed Certificate
JDBC SiteProtector configuration options
You can configure log sources to use the Java™ Database Connectivity (JDBC) SiteProtector™ protocol to
remotely poll IBM Proventia® Management SiteProtector® databases for events.
The JDBC - SiteProtector protocol combines information from the SensorData1 and SensorDataAVP1
tables in the creation of the log source payload. The SensorData1 and SensorDataAVP1 tables are in the
IBM Proventia® Management SiteProtector® database. The maximum number of rows that the JDBC SiteProtector protocol can poll in a single query is 30,000 rows.
The following table describes the protocol-specific parameters for the JDBC - SiteProtector protocol:
Table 11. JDBC - SiteProtector protocol parameters
Parameter
Description
Protocol Configuration
JDBC - SiteProtector
Database Type
From the list, select MSDE as the type of database to use for the event
source.
Database Name
Type RealSecureDB the name of the database to which the protocol can
connect.
IP or Hostname
The IP address or host name of the database server.
Port
The port number that is used by the database server. The JDBC SiteProtector
configuration port must match the listener port of the database. The
database must have incoming TCP connections enabled. If you define a
Database Instance when with MSDE as the database type, you must leave
the Port parameter blank in your log source configuration.
Username
If you want to track access to a database by the JDBC protocol, you can
create a specific user for your QRadar system.
Authentication Domain
If you select MSDE and the database is configured for Windows, you must
define a Windows domain.
If your network does not use a domain, leave this field blank.
Database Instance
If you select MSDE and you have multiple SQL server instances on one
server, define the instance to which you want to connect. If you use a
non-standard port in your database configuration, or access is blocked to
port 1434 for SQL database resolution, you must leave the Database
Instance parameter blank in your configuration.
Predefined Query
The predefined database query for your log source. Predefined database
queries are only available for special log source connections.
Table Name
SensorData1
AVP View Name
SensorDataAVP
Response View Name
SensorDataResponse
Select List
Type * to include all fields from the table or view.
Compare Field
SensorDataRowID
20
QRadar DSM Configuration Guide
Table 11. JDBC - SiteProtector protocol parameters (continued)
Parameter
Description
Use Prepared Statements
Prepared statements allow the JDBC protocol source to set up the SQL
statement, and then execute the SQL statement numerous times with
different parameters. For security and performance reasons, use prepared
statements. You can clear this check box to use an alternative method of
querying that does not use pre-compiled statements.
Include Audit Events
Specifies to collect audit events from IBM SiteProtector®.
Start Date and Time
Optional. A start date and time for when the protocol can start to poll the
database.
Polling Interval
The amount of time between queries to the event table. You can define a
longer polling interval by appending H for hours or M for minutes to the
numeric value. Numeric values without an H or M designator poll in
seconds.
EPS Throttle
The number of Events Per Second (EPS) that you do not want this protocol
to exceed.
Database Locale
For multilingual installations, use the Database Locale field to specify the
language to use.
Database Codeset
For multilingual installations, use the Codeset field to specify the character
set to use.
Use Named Pipe Communication
If you are using Windows authentication, enable this parameter to allow
authentication to the AD server. If you are using SQL authentication, disable
Named Pipe Communication.
Database Cluster Name
The cluster name to ensure that named pipe communications function
properly.
Use NTLMv2
Forces MSDE connections to use the NTLMv2 protocol with SQL servers
that require NTLMv2 authentication. The Use NTLMv2 check box does not
interrupt communications for MSDE connections that do not require
NTLMv2 authentication.
Use SSL
Enables SSL encryption for the JDBC protocol.
Log Source Language
Select the language of the events that are generated by the log source. The
log source language helps the system parse events from external appliances
or operating systems that can create events in multiple languages.
Juniper Networks NSM protocol configuration options
To receive Juniper Networks NSM and Juniper Networks Secure Service Gateway (SSG) logs events,
configure a log source to use the Juniper Networks NSM protocol.
The following table describes the protocol-specific parameters for the Juniper Networks Network and
Security Manager protocol:
Table 12. Juniper Networks NSM protocol parameters
Parameter
Description
Log Source Type
Juniper Networks Network and Security Manager
Protocol Configuration
Juniper NSM
3 Adding a log source
21
Juniper Security Binary Log Collector protocol configuration options
You can configure a log source to use the Security Binary Log Collector protocol. With this protocol,
Juniper appliances can send audit, system, firewall, and intrusion prevention system (IPS) events in
binary format to QRadar.
The binary log format from Juniper SRX or J Series appliances are streamed by using the UDP protocol.
You must specify a unique port for streaming binary formatted events. The standard syslog port 514
cannot be used for binary formatted events. The default port that is assigned to receive streaming binary
events from Juniper appliances is port 40798.
The following table describes the protocol-specific parameters for the Juniper Security Binary Log
Collector protocol:
Table 13. Juniper Security Binary Log Collector protocol parameters
Parameter
Description
Protocol Configuration
Security Binary Log Collector
XML Template File Location
The path to the XML file used to decode the binary stream from your
Juniper SRX or Juniper J Series appliance. By default, the device support
module (DSM) includes an XML file for decoding the binary stream.
The XML file is in the following directory: /opt/qradar/conf/
security_log.xml.
Log File protocol configuration options
To receive events from remote hosts, configure a log source to use the Log File protocol.
The Log File protocol is intended for systems that write daily event logs. It is not appropriate to use the
Log File protocol for devices that append information to their event files.
Log files are retrieved one at a time. The Log File protocol can manage plain text, compressed files, or file
archives. Archives must contain plain-text files that can be processed one line at a time. When the Log
File protocol downloads an event file, the information that is received in the file updates the Log Activity
tab. If more information is written to the file after the download is complete, the appended information is
not processed.
The following table describes the protocol-specific parameters for the Log File protocol:
Table 14. Log File protocol parameters
Parameter
Description
Protocol Configuration
Log File
Remote Port
If the remote host uses a non-standard port number, you must adjust the
port value to retrieve events.
SSH Key File
The path to the SSH key, if the system is configured to use key
authentication. When an SSH key file is used, the Remote Password field is
ignored.
Remote Directory
For FTP, if the log files are in the remote user’s home directory, you can
leave the remote directory blank. A blank remote directory field supports
systems where a change in the working directory (CWD) command is
restricted.
22
QRadar DSM Configuration Guide
Table 14. Log File protocol parameters (continued)
Parameter
Description
Recursive
Enable this check box to allow FTP or SFTP connections to recursively
search sub folders of the remote directory for event data. Data that is
collected from sub folders depends on matches to the regular expression in
the FTP File Pattern. The Recursive option is not available for SCP
connections.
FTP File Pattern
The regular expression (regex) required to identify the files to download
from the remote host.
FTP Transfer Mode
For ASCII transfers over FTP, you must select NONE in the Processor field
and LINEBYLINE in the Event Generator field.
Recurrence
The time interval to determine how frequently the remote directory is
scanned for new event log files. The time interval can include values in
hours (H), minutes (M), or days (D). For example, a recurrence of 2H scans
the remote directory every 2 hours.
Run On Save
Starts the log file import immediately after you save the log source
configuration. When selected, this check box clears the list of previously
downloaded and processed files. After the first file import, the Log File
protocol follows the start time and recurrence schedule that is defined by
the administrator.
EPS Throttle
The number of Events Per Second (EPS) that the protocol cannot exceed.
Change Local Directory?
Changes the local directory on the Target Event Collector to store event
logs before they are processed.
Local Directory
The local directory on the Target Event Collector. The directory must exist
before the Log File protocol attempts to retrieve events.
File Encoding
The character encoding that is used by the events in your log file.
Folder Separator
The character that is used to separate folders for your operating system.
Most configurations can use the default value in Folder Separator field.
This field is intended for operating systems that use a different character to
define separate folders. For example, periods that separate folders on
mainframe systems.
Microsoft Azure Event Hubs protocol configuration options
The Microsoft Azure Event Hubs protocol for IBM Security QRadar collects events from Microsoft Azure
Event Hubs.
The following parameters require specific values to collect events from Microsoft Azure Event Hubs
appliances:
Table 15. Microsoft Azure Event Hubs log source parameters
Parameter
Value
Log Source type
Microsoft Azure
Protocol Configuration
Microsoft Azure Event Hubs
Log Source Identifier
The Log Source Identifier can be any valid value,
including the same value as the Log Source Name
parameter, and doesn't need to reference a specific server.
If you configured multiple Microsoft Azure Event Hub
log sources, you might want to identify the first log
source as EventHub-1, the second log source as
EventHub-2, and the third log source as EventHub-3.
3 Adding a log source
23
Table 15. Microsoft Azure Event Hubs log source parameters (continued)
Parameter
Value
Use as a Gateway Log Source
Enable this check box to send all events through the
QRadar Traffic Analysis Engine and automatically detect
one or more appropriate log sources.
Use Event Hub Connection String
Enable this check box to use an Event Hub Connection
String. Clear this check box to manually enter the values
for the Event Hub Namespace Name, Event Hub Name, SAS
Key Name, and SAS Key parameters.
Event Hub Connection String
The Event Hub Connection String contains the
Namespace Name, the path to the Event Hub within the
namespace, and the Shared Access Signature (SAS)
Authentication information.
Namespace Name
The Namespace Name value is the name of the top-level
directory that contains the Event Hub entities in the
Microsoft Azure Event Hubs user interface.
Event Hub Name
The Event Hub Name is the identifier for the Event Hub
that you want to access. The Event Hub Name should
match one of the Event Hub entities within the
namespace.
SAS Key Name
The Shared Access Signature (SAS) Name identifies the
event publisher.
SAS Key
The Shared Access Signature (SAS) Key authenticates the
event publisher.
Consumer Group
A Consumer Group specifies the view that is used during
the connection. Each Consumer Group maintains its own
session tracking. Any connection that shares consumer
groups and connection information shares session
tracking information.
Use Storage Account Connection String
Enable this check box to use a Storage Account
Connection String. Clear this check box to manually
enter the Storage Account Name and Storage Account
Key.
Storage Account Connection String
A Storage Account Connection String includes
authentication for the Storage Account Name and
Storage Account Key that is used to access the data in
the Azure Storage Account.
Storage Account Name
The Storage Account Name is part of the authentication
process that is required to access data in the Azure
Storage Account.
Storage Account Key
The Storage Account Key is part of the authentication
process that is required to access data in the Azure
Storage Account.
Automatically Acquire Server Certificate(s)
Select Yes for QRadar to automatically download the
server certificate and begin trusting the target server.
EPS Throttle
The maximum number of events per second (EPS). The
default is 5000.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
24
QRadar DSM Configuration Guide
Microsoft DHCP protocol configuration options
To receive events from Microsoft DHCP servers, configure a log source to use the Microsoft DHCP
protocol.
To read the log files, folder paths that contain an administrative share (C$), require NetBIOS privileges on
the administrative share (C$). Local or domain administrators have sufficient privileges to access log files
on administrative shares.
Fields for the Microsoft DHCP protocol that support file paths allow administrators to define a drive
letter with the path information. For example, the field can contain the c$/LogFiles/ directory for an
administrative share, or the LogFiles/directory for a public share folder path, but cannot contain the
c:/LogFiles directory.
Restriction: The Microsoft authentication protocol NTLMv2 is not supported by the Microsoft DHCP
protocol.
The following table describes the protocol-specific parameters for the Microsoft DHCP protocol:
Table 16. Microsoft DHCP protocol parameters
Parameter
Description
Protocol Configuration
Microsoft DHCP
Log Source Identifier
Type a unique hostname or other identifier unique to the log source.
Server Address
The IP address or host name of your Microsoft DHCP server.
Domain
Type the domain for your Microsoft DHCP server.
This parameter is optional if your server is not in a domain.
Username
Type the user name that is required to access the DHCP server.
Password
Type the password that is required to access the DHCP server.
Confirm Password
Confirm the password that is required to access the server.
Folder Path
The directory path to the DHCP log files. The default is
c$/WINDOWS/system32/dhcp/
File Pattern
The regular expression (regex) that identifies event logs. The log files must
contain a three-character abbreviation for a day of the week. Use one of the
following file patterns:
English:
v IPv4 file pattern: DhcpSrvLog-(?:Sun|Mon|Tue|Wed|Thu|Fri|Sat)\.log.
v IPv6 file pattern: DhcpV6SrvLog-(?:Sun|Mon|Tue|Wed|Thu|Fri|Sat)\.log.
v Mixed IPv4 and IPv6 file pattern: Dhcp.*SrvLog(?:Sun|Mon|Tue|Wed|Thu|Fri|Sat)\.log.
Recursive
Select this option if you want the file pattern to search the sub folders.
3 Adding a log source
25
Table 16. Microsoft DHCP protocol parameters (continued)
Parameter
Description
SMB Version
The version of SMB to use:
AUTO Auto-detects to the highest version that the client and server agree
to use.
SMB1
Forces the use of SMB1.
SMB2
Forces the use of SMB2.
Polling Interval (in seconds)
The number of seconds between queries to the log files to check for new
data. The minimum polling interval is 10 seconds. The maximum polling
interval is 3,600 seconds.
Throttle events/sec
The maximum number of events the DHCP protocol can forward per
second. The minimum value is 100 EPS. The maximum value is 20,000 EPS.
File Encoding
The character encoding that is used by the events in your log file.
Enabled
When this option is not enabled, the log source does not collect events and
the log source is not counted in the license limit.
Credibility
Credibility is a representation of the integrity or validity of events that are
created by a log source. The credibility value that is assigned to a log source
can increase or decrease based on incoming events or adjusted as a response
to user-created event rules. The credibility of events from log sources
contributes to the calculation of the offense magnitude and can increase or
decrease the magnitude value of an offense.
Target Event Collector
Specifies the QRadar Event Collector that polls the remote log source.
Use this parameter in a distributed deployment to improve Console system
performance by moving the polling task to an Event Collector.
Coalescing Events
Increases the event count when the same event occurs multiple times within
a short time interval. Coalesced events provide a way to view and
determine the frequency with which a single event type occurs on the Log
Activity tab.
When this check box is clear, events are viewed individually and events are
not bundled.
New and automatically discovered log sources inherit the value of this
check box from the System Settings configuration on the Admin tab. You
can use this check box to override the default behavior of the system
settings for an individual log source.
Microsoft Exchange protocol configuration options
To receive events from SMTP, OWA, and Microsoft Exchange 2007 and 2010 servers, configure a log
source to use the Microsoft Windows Exchange protocol to support.
To read the log files, folder paths that contain an administrative share (C$), require NetBIOS privileges on
the administrative share (C$). Local or domain administrators have sufficient privileges to access log files
on administrative shares.
Fields for the Microsoft Exchange protocol that support file paths allow administrators to define a drive
letter with the path information. For example, the field can contain the c$/LogFiles/ directory for an
administrative share, or the LogFiles/directory for a public share folder path, but cannot contain the
c:/LogFiles directory.
26
QRadar DSM Configuration Guide
Important: The Microsoft Exchange protocol does not support Microsoft Exchange 2003 or Microsoft
authentication protocol NTLMv2 Session.
The following table describes the protocol-specific parameters for the Microsoft Exchange protocol:
Table 17. Microsoft Exchange protocol parameters
Parameter
Description
Protocol Configuration
Microsoft Exchange
Log Source Identifier
Type the IP address, host name, or name to identify your log source.
Server Address
The IP address or host name of your Microsoft Exchange server.
Domain
Type the domain for your Microsoft Exchange server.
This parameter is optional if your server is not in a domain.
Username
Type the user name that is required to access your server.
Password
Type the password that is required to access your server.
Confirm Password
Confirm the password that is required to access the server.
SMTP Log Folder Path
When the folder path is clear, SMTP event collection is disabled.
OWA Log Folder Path
When the folder path is clear, OWA event collection is disabled.
MSGTRK Log Folder Path
Message tracking is available on Microsoft Exchange 2007 or 2010 servers
assigned the Hub Transport, Mailbox, or Edge Transport server role.
File Pattern
The regular expression (regex) that identifies the event logs. The default is
.*\.(?:log|LOG).
Force File Read
If the check box is cleared, the log file is read only when QRadar detects a
change in the modified time or file size.
Recursive
If you want the file pattern to search sub folders, use this option. By default,
the check box is selected.
SMB Version
The version of SMB to use:
AUTO Auto-detects to the highest version that the client and server agree
to use.
SMB1
Forces the use of SMB1.
SMB2
Forces the use of SMB2.
Polling Interval (In seconds)
Type the polling interval, which is the number of seconds between queries
to the log files to check for new data. The default is 10 seconds.
Throttle Events/Second
The maximum number of events the Exchange protocol can forward per
second.
File Encoding
The character encoding that is used by the events in your log file.
Microsoft IIS protocol configuration options
You can configure a log source to use the Microsoft IIS protocol. This protocol supports a single point of
collection for W3C format log files that are located on a Microsoft IIS web server.
To read the log files, folder paths that contain an administrative share (C$), require NetBIOS privileges on
the administrative share (C$). Local or domain administrators have sufficient privileges to access log files
on administrative shares.
3 Adding a log source
27
Fields for the Microsoft IIS protocol that support file paths allow administrators to define a drive letter
with the path information. For example, the field can contain the c$/LogFiles/ directory for an
administrative share, or the LogFiles/directory for a public share folder path, but cannot contain the
c:/LogFiles directory.
Restriction: The Microsoft authentication protocol NTLMv2 is not supported by the Microsoft IIS
protocol.
The following table describes the protocol-specific parameters for the Microsoft IIS protocol:
Table 18. Microsoft IIS protocol parameters
Parameter
Description
Protocol Configuration
Microsoft IIS
Log Source Identifier
Type the IP address, host name, or name to identify your log source.
Server Address
The IP address or host name of your Microsoft IIS server.
Domain
Type the domain for your Microsoft IIS server.
This parameter is optional if your server is not in a domain.
Username
Type the user name that is required to access your server.
Password
Type the password that is required to access your server.
Confirm Password
Confirm the password that is required to access the server.
Log Folder Path
The directory path to access the log files. For example, administrators can
use the c$/LogFiles/ directory for an administrative share, or the LogFiles/
directory for a public share folder path. However, the c:/LogFiles directory
is not a supported log folder path.
If a log folder path contains an administrative share (C$), users with
NetBIOS access on the administrative share (C$) have the privileges that are
required to read the log files.
Local system or domain administrator privileges are also sufficient to access
a log files that are on an administrative share.
File Pattern
The regular expression (regex) that identifies the event logs.
Recursive
If you want the file pattern to search sub folders, use this option. By default,
the check box is selected.
SMB Version
The version of SMB to use:
AUTO Auto-detects to the highest version that the client and server agree
to use.
SMB1
Forces the use of SMB1.
SMB2
Forces the use of SMB2.
Polling Interval (In seconds)
Type the polling interval, which is the number of seconds between queries
to the log files to check for new data. The default is 10 seconds.
Throttle Events/Second
The maximum number of events the IIS protocol can forward per second.
File Encoding
The character encoding that is used by the events in your log file.
Note: If you use Advanced IIS Logging, you need to create a new log definition. In the Log Definition
window, ensure that the following fields are selected in the Selected Fields section:
v Date-UTC
v Time-UTC
v URI-Stem
28
QRadar DSM Configuration Guide
v URI-Querystring
v ContentPath
v Status
v Server Name
v Referer
v Win325Status
v Bytes Sent
Microsoft Security Event Log protocol configuration options
You can configure a log source to use the Microsoft Security Event Log protocol. You can use Microsoft
Windows Management Instrumentation (WMI) to collect customized event logs or agent less Windows
Event Logs.
The WMI API requires that firewall configurations accept incoming external communications on port 135
and on any dynamic ports that are required for DCOM. The following list describes the log source
limitations that you use the Microsoft Security Event Log Protocol:
v Systems that exceed 50 events per second (eps) might exceed the capabilities of this protocol. Use
WinCollect for systems that exceed 50 eps.
v A QRadar all-in-one installation can support up to 250 log sources with the Microsoft Security Event
Log protocol.
v Dedicated Event Collectors can support up to 500 log sources by using the Microsoft Security Event
Log protocol.
The Microsoft Security Event Log protocol is not suggested for remote servers that are accessed over
network links, for example, systems that have high round-trip delay times, such as satellite or slow WAN
networks. You can confirm round-trip delays by examining requests and response time that is between a
server ping. Network delays that are created by slow connections decrease the EPS throughput available
to those remote servers. Also, event collection from busy servers or domain controllers rely on low
round-trip delay times to keep up with incoming events. If you cannot decrease your network round-trip
delay time, you can use WinCollect to process Windows events.
The Microsoft Security Event Log supports the following software versions with the Microsoft Windows
Management Instrumentation (WMI) API:
v Microsoft Windows 2000
v Microsoft Windows Server 2003
v Microsoft Windows Server 2008
v Microsoft Windows Server 2008R3
v Microsoft Windows XP
v Microsoft Windows Vista
v Microsoft Windows 7
The following table describes the protocol-specific parameters for the Microsoft Security Event Log
protocol:
Table 19. Microsoft Security Event Log protocol parameters
Parameter
Description
Protocol Configuration
Windows Security Event Log
3 Adding a log source
29
Microsoft Security Event Log over MSRPC Protocol
The Microsoft Security Event Log over MSRPC protocol (MSRPC) collects Windows events without
installing an agent on the Windows host.
The MSRPC protocol uses the Microsoft Distributed Computing Environment/Remote Procedure Call
(DCE/RPC) specification to provide agentless, encrypted event collection. The MSRPC protocol provides
higher event rates than the default Microsoft Windows Security Event Log protocol, which uses
WMI/DCOM for event collection.
The following table lists the supported features of the MSRPC protocol.
Table 20. Supported features of the MSRPC protocol
Features
Microsoft Security Event Log over MSRPC protocol
Manufacturer
Microsoft
Connection test tool
The MSRPC test tool checks the connectivity between the
QRadar appliance and a Windows host. The MSRPC test
tool is part of the MSRPC protocol RPM and can be
found in /opt/qradar/jars after you install the protocol.
For more information, see MSRPC test tool
(http://www.ibm.com/support/
docview.wss?uid=swg21959348)
Protocol type
The operating system dependent type of the remote
procedure protocol for collection of events.
Select one of the following options from the Protocol
Type list:
MS-EVEN6
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)
Previous log source configurations for the
Microsoft Windows Security Event Log DSM
use the auto-detect (for legacy configurations)
protocol type.
Upgrade to the MS_EVEN6 or the MS-EVEN
(for Windows XP/2003) protocol type.
Maximum EPS rate
100 EPS / Windows host
Maximum overall EPS rate of MSRPC
8500 EPS / IBM Security QRadar 16xx or 18xx appliance
Maximum number of supported log sources
500 log sources / QRadar 16xx or 18xx appliance
Bulk log source support
Yes
Encryption
Yes
30
QRadar DSM Configuration Guide
Table 20. Supported features of the MSRPC protocol (continued)
Features
Microsoft Security Event Log over MSRPC protocol
Supported event types
Application
System
Security
DNS Server
File Replication
Directory Service logs
Supported Windows Operating Systems
Windows Server 2012 (most recent)
Windows Server 2008 (most recent)
Windows 8.1
Windows 8
Windows 7
Windows Vista
MSRPC is not supported on versions of Microsoft
Windows with end of life status 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 XP and 2003 operating system users require
read access to the following registry keys:
v HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
services\eventlog
v HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\Nls\Language
v HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
Windows\CurrentVersion
QRadar provides no support for Windows 2003
integrations because this operating system as reached its
end of life.
Required RPM files
PROTOCOL-WindowsEventRPC-QRadar_releaseBuild_number.noarch.rpm
DSM-MicrosoftWindows-QRadar_releaseBuild_number.noarch.rpm
DSM-DSMCommon-QRadar_release-Build_number.noarch.rpm
3 Adding a log source
31
Table 20. Supported features of the MSRPC protocol (continued)
Features
Microsoft Security Event Log over MSRPC protocol
Windows service requirements
For Windows Vista and later
Remote Procedure Call (RPC)
RPC Endpoint Mapper
For Windows 2003
Remote Registry
Server
Windows port requirements
For Windows Vista and later
TCP port 135
TCP port 445
TCP port that is dynamically allocated for RPC,
above 49152
For Windows 2003
TCP port 445
TCP port 139
Special features
Supports encrypted events by default.
Automatically discovered?
No
Includes identity?
Yes
Includes custom properties?
A security content pack with Windows custom event
properties is available on IBM Fix Central.
Intended application
Agentless event collection for Windows operating
systems that can support 100 EPS per log source.
Tuning support
MSRPC is limited to 100 EPS / Windows host. For
higher event rate systems, see the IBM Security QRadar
WinCollect User Guide.
Event filtering support
MSRPC does not support event filtering. See the IBM
Security QRadar WinCollect User Guide for this feature.
More information
Microsoft support (http://support.microsoft.com/)
In contrast to WMI/DCOM, the MSRPC protocol provides twice the EPS. The event rates are shown in
the following table.
Table 21. Contrast between MSRPC and WMI/DCOM event rates
Name
Protocol type
Maximum event rate
Microsoft Security Event Log
WMI/DCOM
50EPS / Windows host
Microsoft Security Event Log over
MSRPC
MSRPC
100EPS / Windows host
MQ protocol configuration options
To receive messages from a message queue (MQ) service, configure a log source to use the MQ protocol.
The protocol name appears in IBM Security QRadar as MQ JMS.
IBM MQ is supported.
The MQ protocol can monitor multiple message queues, up to a maximum of 50 per log source.
32
QRadar DSM Configuration Guide
The following table describes the protocol-specific parameters for the MQ protocol:
Table 22. MQ protocol parameters
Parameter
Description
Protocol Name
MQ JMS
IP or Hostname
The IP address or host name of the primary queue manager.
Port
The default port that is used for communicating with the primary queue
manager is 1414.
Standby IP or Hostname
The IP address or host name of the standby queue manager.
Standby Port
The port that is used to communicate with the standby queue manager.
Queue Manager
The name of the queue manager.
Channel
The channel through which the queue manager sends messages. The default
channel is SYSTEM.DEF.SVRCONN.
Queue
The queue or list of queues to monitor. A list of queues is specified with a
comma-separated list.
Username
The user name that is used for authenticating with the MQ service.
Password
Optional: The password that is used to authenticate with the MQ service.
Incoming Message Encoding
The character encoding that is used by incoming messages.
Process Computational Fields
Select this option if the retrieved messages contain computational data. The
binary data in the messages will be processed according to the field
definition found in the specified CopyBook file.
CopyBook File Name
The name of the CopyBook file to use for processing data. The CopyBook
file must be placed in /store/ec/mqjms/*
Event Formatter
Select the event formatting to be applied for any events that are generated
from processing data containing computational fields. By default, No
Formatting is used.
Include JMS Message Header
Select this option to include a header in each generated event containing
JMS message fields such as the JMSMessageID and JMSTimestamp.
EPS Throttle
The upper limit for the maximum number of events per second (EPS).
Related concepts:
“Creating a log source extensions document to get data into QRadar” on page 72
You create log source extensions (LSX) when log sources don't have a supported DSM, or to repair an
event that has missing or incorrect information, or to parse an event when the associated DSM fails to
produce a result.
Related tasks:
“Building a Universal DSM” on page 73
The first step in building a Universal DSM is to create the log source in IBM Security QRadar. When you
create the log source, it prevents the logs from being automatically classified and you can export the logs
for review.
Okta REST API protocol configuration options
To receive events from Okta, configure a log source to use the Okta REST API protocol.
The Okta REST API protocol queries the Okta Events and Users API endpoints to retrieve information
about actions that are completed by users in an organization.
The following table describes the protocol-specific parameters for the Okta REST API protocol:
3 Adding a log source
33
Table 23. Okta REST API protocol parameters
Parameter
Description
IP or Hostname
oktaprise.okta.com
Authentication Token
A single authentication token that is generated by the Okta console and
must be used for all API transactions.
Use Proxy
When a proxy is configured, all traffic for the log source travels through the
proxy for QRadar to access Okta.
Configure the Proxy IP or Hostname, Proxy Port, Proxy Username, and
Proxy Password fields. If the proxy does not require authentication, you can
leave the Proxy Username and Proxy Password fields blank.
Automatically Acquire Server
Certificate(s)
If you select Yes from the list, QRadar downloads the certificate and begins
trusting the target server.
Recurrence
You can specify when the log source collects data. The format is M/H/D
for Months/Hours/Days. The default is 1 M.
EPS Throttle
The maximum limit for the number of events per second.
OPSEC/LEA protocol configuration options
To receive events on port 18184, configure a log source to use the OPSEC/LEA protocol.
The following table describes the protocol-specific parameters for the OPSEC/LEA protocol:
Table 24. OPSEC/LEA protocol parameters
Parameter
Description
Protocol Configuration
OPSEC/LEA
Log Source Identifier
The IP address, host name, or any name to identify the device.
Must be unique for the log source type.
Server IP
Type the IP address of the server.
Server Port
The port number that is used for OPSEC communication. The valid range is
0 - 65,536 and the default is 18184.
Use Server IP for Log Source
Select the Use Server IP for Log Source check box if you want to use the
LEA server IP address instead of the managed device IP address for a log
source. By default, the check box is selected.
Statistics Report Interval
The interval, in seconds, during which the number of syslog events are
recorded in the qradar.log file. The valid range is 4 - 2,147,483,648 and the
default interval is 600.
Authentication Type
From the list, select the Authentication Type that you want to use for this
LEA configuration. The options are sslca (default), sslca_clear, or clear.
This value must match the authentication method that is used by the server.
OPSEC Application Object SIC
Attribute (SIC Name)
The Secure Internal Communications (SIC) name is the distinguished name
(DN) of the application; for example: CN=LEA, o=fwconsole..7psasx.
Log Source SIC Attribute (Entity SIC The SIC name of the server, for example: cn=cp_mgmt,o=fwconsole..7psasx.
Name)
Specify Certificate
34
QRadar DSM Configuration Guide
Select this check box if you want to define a certificate for this LEA
configuration. QRadar attempts to retrieve the certificate by using these
parameters when the certificate is needed.
Table 24. OPSEC/LEA protocol parameters (continued)
Parameter
Description
Certificate Filename
This option appears only if Specify Certificate is selected. Type the file
name of the certificate that you want to use for this configuration. The
certificate file must be located in the /opt/qradar/conf/
trusted_certificates/lea directory.
Certificate Authority IP
Type the Check Point Manager Server IP address.
Pull Certificate Password
Type the activation key password.
OPSEC Application
The name of the application that makes the certificate request.
Enabled
Select this check box to enable the log source. By default, the check box is
selected.
Credibility
From the list, select the Credibility of the log source. The range is 0 - 10.
The credibility indicates the integrity of an event or offense as determined
by the credibility rating from the source devices. Credibility increases if
multiple sources report the same event. The default is 5.
Target Event Collector
From the list, select the Target Event Collector to use as the target for the
log source.
Coalescing Events
Select the Coalescing Events check box to enable the log source to coalesce
(bundle) events.
By default, automatically discovered log sources inherit the value of the
Coalescing Events list from the System Settings in QRadar. When you create
a log source or edit an existing configuration, you can override the default
value by configuring this option for each log source.
Store Event Payload
Select the Store Event Payload check box to enable the log source to store
event payload information.
By default, automatically discovered log sources inherit the value of the
Store Event Payload list from the System Settings in QRadar. When you
create a log source or edit an existing configuration, you can override the
default value by configuring this option for each log source.
Important: If you receive the error message Unable to pull SSL certificate after an upgrade, follow these
steps:
1. Clear the Specify Certificate check box.
2. Reenter the password for Pull Certificate Password.
Oracle Database Listener protocol configuration options
To remotely collect log files that are generated from an Oracle database server, configure a log source to
use the Oracle Database Listener protocol source.
Before you configure the Oracle Database Listener protocol to monitor log files for processing, you must
obtain the directory path to the Oracle database log files.
The following table describes the protocol-specific parameters for the Oracle Database Listener protocol:
Table 25. Oracle Database Listener protocol parameters
Parameter
Description
Protocol Configuration
Oracle Database Listener
Log Source Identifier
Type the IP address, host name, or name to identify your log source.
3 Adding a log source
35
Table 25. Oracle Database Listener protocol parameters (continued)
Parameter
Description
Server Address
The IP address or host name of your Oracle Database Listener server.
Domain
Type the domain for your Oracle Database Learner server.
This parameter is optional if your server is not in a domain.
Username
Type the user name that is required to access your server.
Password
Type the password that is required to access your server.
Confirm Password
Confirm the password that is required to access the server.
Log Folder Path
Type the directory path to access the Oracle Database Listener log files.
File Pattern
The regular expression (regex) that identifies the event logs.
Force File Read
Select this check box to force the protocol to read the log file when the
timing of the polling interval specifies.
When the check box is selected, the log file source is always examined when
the polling interval specifies, regardless of the last modified time or file size
attribute.
When the check box is not selected, the log file source is examined at the
polling interval if the last modified time or file size attributes changed.
Recursive
If you want the file pattern to search sub folders, use this option. By default,
the check box is selected.
SMB Version
The version of SMB to use:
AUTO Auto-detects to the highest version that the client and server agree
to use.
SMB1
Forces the use of SMB1.
SMB2
Forces the use of SMB2.
Polling Interval (in seconds)
Type the polling interval, which is the number of seconds between queries
to the log files to check for new data. The default is 10 seconds.
Throttle events/sec
The maximum number of events the Oracle Database Listener protocol
forwards per second.
File Encoding
The character encoding that is used by the events in your log file.
PCAP Syslog Combination protocol configuration options
To collect events from Juniper SRX Series Services Gateway or Juniper Junos OS Platform that forward
packet capture (PCAP) data, configure a log source to use the PCAP Syslog Combination protocol.
Before you configure a log source that uses the PCAP Syslog Combination protocol, determine the
outgoing PCAP port that is configured on the Juniper SRX Series Services Gateway or Juniper Junos OS
Platform. PCAP data cannot be forwarded to port 514.
Note:
QRadar supports receiving PCAP data only from Juniper SRX Series Services Gateway or Juniper Junos
OS Platform for each event collector.
The following table describes the protocol-specific parameters for the PCAP Syslog Combination protocol:
36
QRadar DSM Configuration Guide
Table 26. PCAP Syslog Combination protocol parameters
Parameter
Description
Log Source Name
Type a unique name of the log source.
Log Source Description
Optional. Type a description for the log source.
Log Source Type
From the list, you can select either Juniper SRX Series Services Gateway or
Juniper Junos OS Platform.
Protocol Configuration
From the list, select PCAP Syslog Combination.
Log Source Identifier
Type an IP address, host name, or name to identify the Juniper SRX Series
Services Gateway or Juniper Junos OS Platform appliance.
The log source identifier must be unique for the log source type.
Incoming PCAP Port
If the outgoing PCAP port is edited on the Juniper SRX Series Services
Gateway or Juniper Junos OS Platform appliance, you must edit the log
source to update the incoming PCAP Port.
To edit the Incoming PCAP Port number, complete the following steps:
1. Type the new port number for receiving PCAP data
2. Click Save.
The port update is complete and event collection starts on the new port
number.
Enabled
Select this check box to enable the log source.
When this check box is clear, the log source does not collect events and the
log source is not counted in the license limit.
Credibility
Select the credibility of the log source. The range is 0 (lowest) - 10 (highest).
The default credibility is 5.
Credibility is a representation of the integrity or validity of events that are
created by a log source. The credibility value that is assigned to a log source
can increase or decrease based on incoming events or adjusted as a response
to user created event rules. The credibility of events from log sources
contributes to the calculation of the offense magnitude and can increase or
decrease the magnitude value of an offense.
Target Event Collector
Select the target for the log source. When a log source actively collects
events from a remote source, this field defines which appliance polls for the
events.
This option enables administrators to poll and process events on the target
event collector, instead of the Console appliance. This can improve
performance in distributed deployments.
Coalescing Events
Select this check box to enable the log source to coalesce (bundle) events.
Coalescing events increase the event count when the same event occurs
multiple times within a short time interval. Coalesced events provide
administrators a way to view and determine the frequency with which a
single event type occurs on the Log Activity tab.
When this check box is clear, the events are displayed individually and the
information is not bundled.
New and automatically discovered log sources inherit the value of this
check box from the System Settings configuration on the Admin tab.
Administrators can use this check box to override the default behavior of
the system settings for an individual log source.
3 Adding a log source
37
Table 26. PCAP Syslog Combination protocol parameters (continued)
Parameter
Description
Store Event Payload
Select this check box to enable the log source to store the payload
information from an event.
New and automatically discovered log sources inherit the value of this
check box from the System Settings configuration on the Admin tab.
Administrators can use this check box to override the default behavior of
the system settings for an individual log source.
Log Source Extension
Optional. Select the name of the extension to apply to the log source.
This parameter is available after a log source extension is uploaded. Log
source extensions are XML files that contain regular expressions, which can
override or repair the event parsing patterns that are defined by a device
support module (DSM).
Extension Use Condition
From the list box, select the use condition for the log source extension. The
options include:
v Parsing enhancement - Select this option when most fields parse correctly
for your log source.
v Parsing override - Select this option when the log source is unable to
correctly parse events.
Groups
Select one or more groups for the log source.
SDEE protocol configuration options
You can configure a log source to use the Security Device Event Exchange (SDEE) protocol. QRadar uses
the protocol to collect events from appliances that use SDEE servers.
The following table describes the protocol-specific parameters for the SDEE protocol:
Table 27. SDEE protocol parameters
Parameter
Description
Protocol Configuration
SDEE
URL
The HTTP or HTTPS URL that is required to access the log source, for
example, https://www.example.com/cgi-bin/sdee-server.
For SDEE/CIDEE (Cisco IDS v5.x and later), the URL must end with
/cgi-bin/sdee-server. Administrators with RDEP (Cisco IDS v4.x), the URL
must end with /cgi-bin/event-server.
Force Subscription
When the check box is selected, the protocol forces the server to drop the
least active connection and accept a new SDEE subscription connection for
the log source.
Maximum Wait To Block For Events
When a collection request is made and no new events are available, the
protocol enables an event block. The block prevents another event request
from being made to a remote device that did not have any new events. This
timeout is intended to conserve system resources.
38
QRadar DSM Configuration Guide
SMB Tail protocol configuration options
You can configure a log source to use the SMB Tail protocol. Use this protocol to watch events on a
remote Samba share and receive events from the Samba share when new lines are added to the event log.
The following table describes the protocol-specific parameters for the SMB Tail protocol:
Table 28. SMB Tail protocol parameters
Parameter
Description
Protocol Configuration
SMB Tail
Server Address
The IP address or host name of your SMB Tail server.
Domain
Type the domain for your SMB Tail server.
This parameter is optional if your server is not in a domain.
Username
Type the user name that is required to access your server.
Password
Type the password that is required to access your server.
Confirm Password
Confirm the password that is required to access the server.
Log Folder Path
The directory path to access the log files. For example, administrators can
use the c$/LogFiles/ directory for an administrative share, or the LogFiles/
directory for a public share folder path. However, the c:/LogFiles directory
is not a supported log folder path.
If a log folder path contains an administrative share (C$), users with
NetBIOS access on the administrative share (C$) have the privileges that are
required to read the log files.
Local system or domain administrator privileges are also sufficient to access
a log files that are on an administrative share.
File Pattern
The regular expression (regex) that identifies the event logs.
SMB Version
The version of SMB to use:
AUTO Auto-detects to the highest version that the client and server agree
to use.
SMB1
Forces the use of SMB1.
SMB2
Forces the use of SMB2.
Force File Read
If the check box is cleared, the log file is read only when QRadar detects a
change in the modified time or file size.
Recursive
If you want the file pattern to search sub folders, use this option. By default,
the check box is selected.
Polling Interval (In seconds)
Type the polling interval, which is the number of seconds between queries
to the log files to check for new data. The default is 10 seconds.
Throttle Events/Second
The maximum number of events the SMB Tail protocol forwards per second.
File Encoding
The character encoding that is used by the events in your log file.
3 Adding a log source
39
SNMPv2 protocol configuration options
You can configure a log source to use the SNMPv2 protocol to receive SNMPv2 events.
The following table describes the protocol-specific parameters for the SNMPv2 protocol:
Table 29. SNMPv2 protocol parameters
Parameter
Description
Protocol Configuration
SNMPv2
Community
The SNMP community name that is required to access the system that
contains SNMP events.
Include OIDs in Event Payload
Specifies that the SNMP event payload is constructed by using name-value
pairs instead of the event payload format.
When you select specific log sources from the Log Source Types list, OIDs
in the event payload are required for processing SNMPv2 or SNMPv3
events.
SNMPv3 protocol configuration options
You can configure a log source to use the SNMPv3 protocol to receive SNMPv3 events.
The following table describes the protocol-specific parameters for the SNMPv3 protocol:
Table 30. SNMPv3 protocol parameters
Parameter
Description
Protocol Configuration
SNMPv3
Authentication Protocol
The algorithms to use to authenticate SNMP traps:
Include OIDs in Event Payload
Specifies that the SNMP event payload is constructed by using name-value
pairs instead of the standard event payload format. When you select specific
log sources from the Log Source Types list, OIDs in the event payload are
required for processing SNMPv2 or SNMPv3 events.
Seculert Protection REST API protocol configuration options
To receive events from Seculert, configure a log source to use the Seculert Protection REST API protocol.
Seculert Protection provides alerts on confirmed incidents of malware that are actively communicating or
exfiltrating information.
Before you can configure a log source for Seculert, you must obtain your API key from the Seculert web
portal.
1. Log in to the Seculert web portal.
2. On the dashboard, click the API tab.
3. Copy the value for Your API Key.
The following table describes the protocol-specific parameters for the Seculert Protection REST API
protocol:
Table 31. Seculert Protection REST API protocol parameters
Parameter
Description
Log Source Type
Seculert
40
QRadar DSM Configuration Guide
Table 31. Seculert Protection REST API protocol parameters (continued)
Parameter
Description
Protocol Configuration
Seculert Protection REST API
Log Source Identifier
Type the IP address or host name for the log source as an identifier for
events from Seculert.
Each additional log source that you create when you have multiple
installations ideally includes a unique identifier, such as an IP address or
host name.
API Key
The API key that is used for authenticating with the Seculert Protection
REST API. The API key value is obtained from the Seculert web portal.
Use Proxy
When you configure a proxy, all traffic for the log source travels through
the proxy for QRadar to access the Seculert Protection REST API.
Configure the Proxy IP or Hostname, Proxy Port, Proxy Username, and
Proxy Password fields. If the proxy does not require authentication, you can
leave the Proxy Username and Proxy Password fields blank.
Automatically Acquire Server
Certificate(s)
If you select Yes form the list, QRadar downloads the certificate and begins
trusting the target server.
Recurrence
Specify when the log collects data. The format is M/H/D for
Months/Hours/Days. The default is 1 M.
EPS Throttle
The upper limit for the maximum number of events per second (eps) for
events that are received from the API.
Enabled
Select this check box to enable the log source. By default, the check box is
selected.
Credibility
Select the Credibility of the log source. The range is 0 - 10.
The credibility indicates the integrity of an event or offense as determined
by the credibility rating from the source devices. Credibility increases if
multiple sources report the same event. The default is 5.
Target Event Collector
Select the Target Event Collector to use as the target for the log source.
Coalescing Events
Select this check box to enable the log source to coalesce (bundle) events.
By default, automatically discovered log sources inherit the value of the
Coalescing Events list from the System Settings in QRadar. When you
create a log source or edit an existing configuration, you can override the
default value by configuring this option for each log source.
Store Event Payload
Select this check box to enable the log source to store event payload
information.
By default, automatically discovered log sources inherit the value of the
Store Event Payload list from the System Settings in QRadar. When you
create a log source or edit an existing configuration, you can override the
default value by configuring this option for each log source.
Sophos Enterprise Console JDBC protocol configuration options
To receive events from Sophos Enterprise Consoles, configure a log source to use the Sophos Enterprise
Console JDBC protocol.
The Sophos Enterprise Console JDBC protocol combines payload information from application control
logs, device control logs, data control logs, tamper protection logs, and firewall logs in the
vEventsCommonData table. If the Sophos Enterprise Console does not have the Sophos Reporting
Interface, you can use the standard JDBC protocol to collect antivirus events.
3 Adding a log source
41
The following table describes the parameters for the Sophos Enterprise Console JDBC protocol:
Table 32. Sophos Enterprise Console JDBC protocol parameters
Parameter
Description
Protocol Configuration
Sophos Enterprise Console JDBC
Database Type
MSDE
Database Name
The database name must match the database name that is specified in the
Log Source Identifier field.
Port
The default port for MSDE in Sophos Enterprise Console is 1168. The JDBC
configuration port must match the listener port of the Sophos database to
communicate with QRadar. The Sophos database must have incoming TCP
connections enabled.
If a Database Instance is used with the MSDE database type, you must
leave the Port parameter blank.
Authentication Domain
If your network does not use a domain, leave this field blank.
Database Instance
The database instance, if required. MSDE databases can include multiple
SQL server instances on one server.
When a non-standard port is used for the database or administrators block
access to port 1434 for SQL database resolution, the Database Instance
parameter must be blank.
Table Name
vEventsCommonData
Select List
*
Compare Field
InsertedAt
Use Prepared Statements
Prepared statements enable the protocol source to set up the SQL statement,
and then run the SQL statement numerous times with different parameters.
For security and performance reasons, most configurations can use
prepared statements. Clear this check box to use an alternative method of
querying that do not use pre-compiled statements.
Start Date and Time
Optional. A start date and time for when the protocol can start to poll the
database. If a start time is not defined, the protocol attempts to poll for
events after the log source configuration is saved and deployed.
Polling Interval
The polling interval, which is the amount of time between queries to the
database. You can define a longer polling interval by appending H for
hours or M for minutes to the numeric value. The maximum polling
interval is 1 week in any time format. Numeric values without an H or M
designator poll in seconds.
EPS Throttle
The number of Events Per Second (EPS) that you do not want this protocol
to exceed.
Use Named Pipe Communication
If MSDE is configured as the database type, administrators can select this
check box to use an alternative method to a TCP/IP port connection.
Named pipe connections for MSDE databases require the user name and
password field to use a Windows authentication username and password
and not the database user name and password. The log source
configuration must use the default named pipe on the MSDE database.
Database Cluster Name
42
QRadar DSM Configuration Guide
If you use your SQL server in a cluster environment, define the cluster
name to ensure that named pipe communications function properly.
Table 32. Sophos Enterprise Console JDBC protocol parameters (continued)
Parameter
Description
Use NTLMv2
Forces MSDE connections to use the NTLMv2 protocol with SQL servers
that require NTLMv2 authentication. The default value of the check box is
selected.
The Use NTLMv2 check box does not interrupt communications for MSDE
connections that do not require NTLMv2 authentication.
Sourcefire Defense Center eStreamer protocol options
Sourcefire Defense Center eStreamer protocol is now known as Cisco Firepower eStreamer protocol.
Syslog Redirect protocol overview
The Syslog Redirect protocol is used as an alternative to the Syslog protocol. Use this protocol to override
how QRadar determines the source of a syslog event.
The standard syslog protocol listener on port 514 automatically parses the host name or IP from a
standard syslog header and recognizes it as the source value of the event. If an event does not have a
standard header, the source IP of the packet it arrived on is used as the source value.
If events are sent to QRadar through an intermediary system, such as a syslog forwarder, aggregator, load
balancer, third-party log management, or SIEM system, the packet IP is that of the intermediary. Syslog
Redirect addresses this issue by determining the source value from elsewhere in the event payload.
The following table describes the protocol-specific parameters for the Syslog Redirect protocol:
Table 33. Syslog Redirect protocol parameters
Parameter
Description
Protocol Configuration
Syslog Redirect
Log Source Identifier Regex
Enter a regex (regular expression) to capture one or more values from event
payloads that are handled by this protocol. These values are used with the
Log Source Identifier Regex Format String to set a source or origin value
for each event. This source value is used to route the event to a log source
with a matching Log Source Identifier value.
Log Source Identifier Regex Format
String
You can use a combination of one or more of the following inputs to form a
source value for event payloads that are processed by this protocol:
v One or more capture groups from the Log Source Identifier Regex. To
refer to a capture group, use \xnotation where x is the index of a capture
group from the Log Source Identifier Regex.
v The IP address from which the event data originated. To refer to the
packet IP, use the token $PIP$.
v Literal text characters. The entire Log Source Identifier Regex Format
String can be user-provided text.
For example, if the Log Source Identifier Regex is 'hostname=(.*?) ' and
you want to append hostname.com to the capture group 1 value, set the Log
Source Identifier Regex Format String to \1.hostname.com. If an event is
processed that containshostname=ibm, then the event payload's source value
is set to ibm.hostname.com, and QRadar routes the event to a log source
with that Log Source Identifier.
3 Adding a log source
43
Table 33. Syslog Redirect protocol parameters (continued)
Parameter
Description
Perform DNS Lookup On Regex
Match
Select this check box to allow the protocol to perform DNS lookups on
source values (as set by the Log Source Identifier Regex and Log Source
Identifier Format String parameters) to convert host names into IP
addresses. If left clear, the source value remains as-is.
By default, the check box is not selected.
Note: If you enable the Perform DNS Lookup on Regex Match option, it
might slow the performance of the Syslog Redirect protocol.
Listen Port
517 is the default part. Any port can be used for listening, other than port
514 as it is used by the standard Syslog listener.
Protocol
You can select either UDP or TCP.
TCP multiline syslog protocol configuration options
You can configure a log source that uses the TCP multiline syslog protocol. This protocol uses regular
expressions to identify the start and end pattern of multiline events.
The following example is a multiline event:
06/13/2012 08:15:15 PM
LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=5156
EventType=0
TaskCategory=Filtering Platform Connection
Keywords=Audit Success
Message=The Windows Filtering Platform permitted a connection.
Process ID: 4
Application Name: System
Direction: Inbound
Source Address: <IP_address>
Source Port: 80
Destination Address: <IP_address>
Destination Port:444
The following table describes the protocol-specific parameters for the TCP multiline syslog protocol:
Table 34. TCP multiline syslog protocol parameters
Parameter
Description
Protocol Configuration
TCP Multiline Syslog
Log Source Identifier
Type an IP address or host name to identify the log source. To use a name
instead, select Use Custom Source Name and fill in the Source Name
Regex and Source Name Formatting String parameters.
Note: These parameters are only available if Show Advanced Options is set
to Yes.
Listen Port
The default port is 12468.
Aggregation Method
The default is Start/End Matching. Use ID-Linked if you want to combine
multiline events that are joined by a common identifier.
44
QRadar DSM Configuration Guide
Table 34. TCP multiline syslog protocol parameters (continued)
Parameter
Description
Event Start Pattern
This parameter is available when you set the Aggregation Method
parameter to Start/End Matching.
The regular expression (regex) that is required to identify the start of a TCP
multiline event payload. Syslog headers typically begin with a date or time
stamp. The protocol can create a single-line event that is based on solely on
an event start pattern, such as a time stamp. When only a start pattern is
available, the protocol captures all the information between each start value
to create a valid event.
Event End Pattern
This parameter is available when you set the Aggregation Method
parameter to Start/End Matching.
This regular expression (regex) that is required to identify the end of a TCP
multiline event payload. If the syslog event ends with the same value, you
can use a regular expression to determine the end of an event. The protocol
can capture events that are based on solely on an event end pattern. When
only an end pattern is available, the protocol captures all the information
between each end value to create a valid event.
Message ID Pattern
This parameter is available when you set the Aggregation Method
parameter to ID-Linked.
This regular expression (regex) required to filter the event payload
messages. The TCP multiline event messages must contain a common
identifying value that repeats on each line of the event message.
Event Formatter
Use the Windows Multiline option for multiline events that are formatted
specifically for Windows.
Show Advanced Options
The default is No. Select Yes if you want to customize the event data.
Use Custom Source Name
This parameter is available when you set Show Advanced Options to Yes.
Select the check box if you want to customize the source name with regex.
Source Name Regex
This parameter is available when you check Use Custom Source Name.
The regular expression (regex) that captures one or more values from event
payloads that are handled by this protocol. These values are used along
with the Source Name Formatting String parameter to set a source or
origin value for each event. This source value is used to route the event to a
log source with a matching Log Source Identifier value.
Source Name Formatting String
This parameter is available when you check Use Custom Source Name.
You can use a combination of one or more of the following inputs to form a
source value for event payloads that are processed by this protocol:
v One or more capture groups from the Source Name Regex. To refer to a
capture group, use \x notation where x is the index of a capture group
from the Source Name Regex.
v The IP address where the event data originated from. To refer to the
packet IP, use the token $PIP$.
v Literal text characters. The entire Source Name Formatting String can be
user-provided text. For example, if the Source Name Regex is
’hostname=(.*?)’ and you want to append hostname.com to the capture
group 1 value, set the Source Name Formatting String
to\1.hostname.com. If an event is processed that contains hostname=ibm,
then the event payload's source value is set to ibm.hostname.com, and
QRadar routes the event to a log source with that Log Source Identifier.
3 Adding a log source
45
Table 34. TCP multiline syslog protocol parameters (continued)
Parameter
Description
Use as a Gateway Log Source
This parameter is available when you set Show Advanced Options to Yes.
When selected, events that flow through the log source can be routed to
other log sources, based on the source name tagged on the events.
When this option is not selected and Use Custom Source Name is not
checked, incoming events are tagged with a source name that corresponds
to the Log Source Identifier parameter.
Flatten Multiline Events into Single
Line
This parameter is available when you set Show Advanced Options to Yes.
Retain Entire Lines during Event
Aggregation
This parameter is available when you set Show Advanced Options to Yes.
Shows an event in one single line or multiple lines.
If you set the Aggregation Method parameter to ID-Linked, you can enable
Retain Entire Lines during Event Aggregation to either discard or keep the
part of the events that comes before Message ID Pattern when
concatenating events with the same ID pattern together.
TCP Multiline Syslog protocol configuration use cases
To set the TCP Multiline Syslog listener log source to collect all events that are sent from the same
system, follow these steps:
1. Leave Use As A Gateway Log Source and Use Custom Source Name cleared.
2. Enter the IP address of the system that is sending events in the Log Source Identifier parameter.
Figure 1. A QRadar log source collects events sent from a single system to a TCP Multiline Syslog Listener
If multiple systems are sending events to the TCP Multiline Syslog listener, or if one intermediary system
is forwarding events from multiple systems and you want the events to be routed to separate log sources
based on their syslog header or IP address, check the Use As A Gateway Log Source check box.
Note: QRadar checks each event for an RFC3164 or RFC5424-compliant syslog header, and if present,
uses the IP/hostname from that header as the source value for the event. The event is routed to a log
source with that same IP or host name as its Log Source Identifier. If no such header is present, QRadar
uses the source IP value from the network packet that the event arrived on as the source value for the
event.
46
QRadar DSM Configuration Guide
Figure 2. Separate QRadar log sources collect events sent from multiple systems to a TCP Multiline Listener, by using
the syslog header.
Figure 3. Separate QRadar log sources collect events sent from multiple systems and forwarded via an intermediate
system to a TCP Multiline Listener, by using the syslog header.
To route events to separate log sources based on a value other than the IP or host name in their syslog
header, follow these steps:
1. Check the Use Custom Source Name check box.
2. Configure a Source Name Regex and Source Name Formatting String to customize how QRadar sets
a source name value for routing the received events to log sources.
Figure 4. Separate QRadar log sources collect events sent from multiple systems and forwarded via an intermediate
system to a TCP Multiline Listener, by using the Source Name Regex and Source Name Formatting String.
3 Adding a log source
47
TLS syslog protocol configuration options
Configure a TLS Syslog protocol log source to receive encrypted syslog events from up to 1000 network
devices that support TLS Syslog event forwarding.
The log source creates a listen port for incoming TLS Syslog events and generates a certificate file for the
network devices. Up to 50 network appliances can forward events to the listen port that is created for the
log source. If you create additional log sources with unique listen ports, you can configure up to 1000
network appliances.
The following table describes the protocol-specific parameters for the TLS Syslog protocol:
Table 35. TLS syslog protocol parameters
Parameter
Description
Protocol Configuration
TLS Syslog
TLS Listen Port
The default TLS listen port is 6514.
Authentication Mode
The mode by which your TLS connection is authenticated. If you select the
TLS and Client Authentication option, you must configure the certificate
parameters.
Client Certificate Path
The absolute path to the client-certificate on disk. The certificate must be
stored on the Console or Event Collector for this log source.
Certificate Type
The type of certificate to use for authentication. If you select the Provide
Certificate option, you must configure the file paths for the server certificate
and the private key.
Provided Server Certificate Path
The absolute path to the server certificate.
Provided Private Key Path
The absolute path to the private key.
Note: The corresponding private key must be a DER-encoded PKCS8 key.
The configuration fails with any other key format.
Maximum Connections
The Maximum Connections parameter controls how many simultaneous
connections the TLS Syslog protocol can accept for each Event Collector.
There is a limit of 1000 connections across all TLS syslog log source
configurations for each Event Collector. The default for each device
connection is 50.
Note: Automatically discovered log sources that share a listener with
another log source, such as if you use the same port on the same event
collector, count only one time towards the limit.
After the log source is saved, a syslog-tls certificate is created for the log source. The certificate must be
copied to any device on your network that is configured to forward encrypted syslog. Other network
devices that have a syslog-tls certificate file and the TLS listen port number can be automatically
discovered as a TLS syslog log source.
TLS syslog use cases
The following use cases represent possible configurations that you can create:
Client Authentication
You can supply a client-certificate that enables the protocol to engage in client-authentication. If
you select this option and provide the certificate, incoming connections are validated against the
client-certificate.
User-provided Server Certificates
You can configure your own server certificate and corresponding private key. The configured TLS
48
QRadar DSM Configuration Guide
Syslog provider uses the certificate and key. Incoming connections are presented with the
user-supplied certificate, rather than the automatically generated TLS Syslog certificate.
Default authentication
To use the default authentication method, use the default values for the Authentication Mode
and Certificate Type parameters. After the log source is saved, a syslog-tls certificate is created
for log source device. The certificate must be copied to any device on your network that forwards
encrypted syslog data.
Configuring multiple log sources over TLS syslog
You can configure multiple devices in your network to send encrypted Syslog events to a single TLS
Syslog listen port. The TLS Syslog listener acts as a gateway, decrypts the event data, and feeds it within
QRadar to extra log sources configured with the Syslog protocol.
Before you begin
Ensure that the TLS Syslog log source is configured.
Note: You can use any placeholder for the Log Source Identifier and Log Source Type to identify the
TLS Syslog log source. The TLS Syslog log source is configured to host the TLS Syslog listener and acts as
a gateway.
About this task
Multiple devices within your network that support TLS-encrypted Syslog can send encrypted events via a
TCP connection to the TLS Syslog listen port. These encrypted events are decrypted by the TLS Syslog
(gateway) and are fired into the event pipeline. The decrypted events get routed to the appropriate
receiver log sources or to the traffic analysis engine for autodiscovery.
Events are routed within QRadar to log sources with a Log Source Identifier value that matches the
source value of an event. For Syslog events with an RFC3164- or RFC5424-compliant Syslog header, the
source value is the IP address or the host name from the header. For events that do not have a compliant
header, the source value is the IP address of the device that sent the Syslog event.
On QRadar, you can configure multiple log sources with the Syslog protocol to receive encrypted events
that are sent to a single TLS Syslog listen port from multiple devices.
Note: Most TLS-enabled clients require the target server or listener's public certificate to authenticate the
server's connection. By default, a TLS Syslog log source generates a certificate that is named
syslog-tls.cert in /opt/qradar/conf/trusted_certificates/ on the target Event Collector that the log
source is assigned to. This certificate file must be copied to all clients that are making a TLS connection.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click Log Sources > Add.
4. From the Protocol Configuration list, select TLS Syslog.
5. Configure the log source device to use the TLS Syslog port to send events to QRadar.
6. Repeat steps 3-5 for each log source that receives events through the gateway TLS listener.
Note: You can also add multiple receiver log sources in bulk by clicking Bulk Actions > Bulk Add
from the Log Sources window.
Related concepts:
3 Adding a log source
49
“TLS syslog protocol configuration options” on page 48
Configure a TLS Syslog protocol log source to receive encrypted syslog events from up to 1000 network
devices that support TLS Syslog event forwarding.
UDP multiline syslog protocol configuration options
To create a single-line syslog event from a multiline event, configure a log source to use the UDP
multiline protocol. The UDP multiline syslog protocol uses a regular expression to identify and
reassemble the multiline syslog messages into single event payload.
The original multiline event must contain a value that repeats on each line in order for a regular
expression to capture that value and identify and reassemble the individual syslog messages that make
up the multiline event. For example, this multiline event contains a repeated value, 2467222, in the conn
field. This field value is captured so that all syslog messages that contain conn=2467222 are combined into
a single event.
15:08:56
15:08:56
15:08:56
15:08:56
<IP_address>
<IP_address>
<IP_address>
<IP_address>
slapd[517]:
slapd[517]:
slapd[517]:
slapd[517]:
conn=2467222
conn=2467222
conn=2467222
conn=2467222
op=2
op=2
op=2
op=1
SEARCH RESULT tag=101
SRCH base="dc=xxx"
SRCH attr=gidNumber
SRCH base="dc=xxx"
The following table describes the protocol-specific parameters for the UDP multiline syslog protocol:
Table 36. UDP multiline syslog protocol parameters
Parameter
Description
Protocol Configuration
UDP Multiline Syslog
Listen Port
The default port number that is used by QRadar to accept incoming UDP
Multiline Syslog events is 517. You can use a different port in the range 1 65535.
To edit a saved configuration to use a new port number, complete the
following steps:
1.
In the Listen Port field, type the new port number for receiving UDP
Multiline Syslog events.
2. Click Save.
3. Click Deploy Changes to make this change effective.
The port update is complete and event collection starts on the new port
number.
Message ID Pattern
The regular expression (regex) required to filter the event payload messages.
The UDP multiline event messages must contain a common identifying
value that repeats on each line of the event message.
Event Formatter
The event formatter that formats incoming payloads that are detected by the
listener. Select No Formatting to leave the payload untouched. Select Cisco
ACS Multiline to format the payload into a single-line event.
In ACS syslog header, there are total_seg and seg_num fields. These two
fields are used to rearrange ACS multiline events into a single-line event
with correct order when you select the Cisco ACS Multiline option.
Show Advanced Options
The default is No. Select Yes if you want to configure advanced options.
Use Custom Source Name
Select the check box if you want to customize the source name with regex.
50
QRadar DSM Configuration Guide
Table 36. UDP multiline syslog protocol parameters (continued)
Parameter
Description
Source Name Regex
Use the Source Name Regex and Source Name Formatting String
parameters if you want to customize how QRadar determines the source of
the events that are processed by this UDP Multiline Syslog configuration.
For Source Name Regex, enter a regex to capture one or more identifying
values from event payloads that are handled by this protocol. These values
are used with the Source Name Formatting String to set a source or origin
value for each event. This source value is used to route the event to a log
source with a matching Log Source Identifier value when the Use As A
Gateway Log Source option is enabled.
Source Name Formatting String
You can use a combination of one or more of the following inputs to form a
source value for event payloads that are processed by this protocol:
v One or more capture groups from the Source Name Regex. To refer to a
capture group, use \x notation where x is the index of a capture group
from the Source Name Regex.
v The IP address from which the event data originated. To refer to the
packet IP, use the token $PIP$.
v Literal text characters. The entire Source Name Formatting String can be
user-provided text.
For example, CiscoACS\1\2$PIP$, where \1\2 means first and second capture
groups from the Source Name Regex value, and $PIP$ is the packet IP.
Use As A Gateway Log Source
If this check box is clear, incoming events are sent to the log source with the
Log Source Identifier matching the IP that they originated from.
When checked, this log source serves as a single entry point or gateway for
multiline events from many sources to enter QRadar and be processed in
the same way, without the need to configure a UDP Multiline Syslog log
source for each source. Events with an RFC3164- or RFC5424-compliant
syslog header are identified as originating from the IP or host name in their
header, unless the Source Name Formatting String parameter is in use, in
which case that format string is evaluated for each event. Any such events
are routed through QRadar based on this captured value.
If one or more log sources exist with a corresponding Log Source Identifier,
they are given the event based on configured Parsing Order. If they do not
accept the event, or if no log sources exist with a matching Log Source
Identifier, the events are analyzed for autodetection.
Flatten Multiline Events Into Single
Line
Shows an event in one single line or multiple lines. If this check box is
selected, all newline and carriage return characters are removed from the
event.
Retain Entire Lines During Event
Aggregation
Choose this option to either discard or keep the part of the events that
comes before Message ID Pattern when the protocol concatenates events
with same ID pattern together.
Enabled
Select this check box to enable the log source.
Credibility
Select the credibility of the log source. The range is 0 - 10.
The credibility indicates the integrity of an event or offense as determined
by the credibility rating from the source devices. Credibility increases if
multiple sources report the same event. The default is 5.
Target Event Collector
Select the Event Collector in your deployment that should host the UDP
Multiline Syslog listener.
3 Adding a log source
51
Table 36. UDP multiline syslog protocol parameters (continued)
Parameter
Description
Coalescing Events
Select this check box to enable the log source to coalesce (bundle) events.
By default, automatically discovered log sources inherit the value of the
Coalescing Events list from the System Settings in QRadar. When you create
a log source or edit an existing configuration, you can override the default
value by configuring this option for each log source.
Store Event Payload
Select this check box to enable the log source to store event payload
information.
By default, automatically discovered log sources inherit the value of the
Store Event Payload list from the System Settings in QRadar. When you
create a log source or edit an existing configuration, you can override the
default value by configuring this option for each log source.
Configuring UDP multiline syslog for Cisco ACS appliances
The Cisco ACS DSM for IBM Security QRadar accepts syslog events from Cisco ACS appliances with log
sources that are configured to use the UDP Multiline Syslog protocol.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the Data Sources section, click the Log Sources icon, and then click Add.
4. In the Log Source Name field, type a name for your log source.
5. From the Log Source Type list, select Cisco ACS.
6. From the Protocol Configuration list, select UDP Multiline Syslog.
7. Configure the parameters:
The following parameters require specific values to collect events from Cisco ACS appliances:
Table 37. Cisco ACS log source parameters
Parameter
Value
Log Source Identifier
Type the IP address, host name, or name to identify your
Cisco ACS appliance.
Listen Port
The default port number that is used by QRadar to
accept incoming UDP Multiline Syslog events is 517. You
can use a different port. The valid port range is 1 - 65535.
To edit a saved configuration to use a new port number,
complete the following steps.
1. In the Listen Port field, type the new port number
for receiving UDP Multiline Syslog events.
2. Click Save.
The port update is complete and event collection starts
on the new port number.
Message ID Pattern
\s(\d{10})\s
Event Formatter
Select Cisco ACS Multiline from the list.
Related concepts:
52
QRadar DSM Configuration Guide
“UDP multiline syslog protocol configuration options” on page 50
To create a single-line syslog event from a multiline event, configure a log source to use the UDP
multiline protocol. The UDP multiline syslog protocol uses a regular expression to identify and
reassemble the multiline syslog messages into single event payload.
VMware vCloud Director protocol configuration options
To collect events from the VMware vCloud Director virtual environments, you can create a log source
that uses the VMware vCloud Director protocol.
The following table describes the protocol-specific parameters for the VMware vCloud Director protocol:
Table 38. VMware vCloud Director protocol parameters
Parameter
Description
Protocol Configuration
VMware vCloud Director
vCloud URL
The URL that is configured on the VMware vCloud appliance to access the
REST API. The URL must match the address that is configured as the VCD
public REST API base URL on the vCloud Server, for example,
https://192.0.2.1.
User Name
The user name that is required to remotely access the vCloud Server, for
example, console/user@organization. To configure a read-only account to
use with the vCloud Director protocol, a user must have Console Access
Only permission.
3 Adding a log source
53
54
QRadar DSM Configuration Guide
4 Adding bulk log sources
You can add up to 500 Microsoft Windows or Universal DSM log sources at one time. When you add
multiple log sources at one time, you add a bulk log source in QRadar. Bulk log sources must share a
common configuration.
Procedure
1. Click the Admin tab.
2. Click the Log Sources icon.
3. From the Bulk Actions list, select Bulk Add.
4. Configure the parameters for the bulk log source.
v File Upload - Upload a text file that has one host name or IP per line
v Manual - Enter the host name or IP of the host that you wish to add
5. Click Save.
6. Click Continue to add the log sources.
7. On the Admin tab, click Deploy Changes.
© Copyright IBM Corp. 2005, 2018
55
56
QRadar DSM Configuration Guide
5 Adding a log source parsing order
You can assign a priority order for when the events are parsed by the target event collector.
About this task
You can order the importance of the log sources by defining the parsing order for log sources that share a
common IP address or host name. Defining the parsing order for log sources ensures that certain log
sources are parsed in a specific order, regardless of changes to the log source configuration. The parsing
order ensures that system performance is not affected by changes to log source configuration by
preventing unnecessary parsing. The parsing order ensures that low-level event sources are not parsed
for events before more important log source.
Procedure
1. Click the Admin tab.
2. Click the Log Source Parsing Ordering icon.
3. Select a log source.
4. Optional: From the Selected Event Collector list, select the Event Collector to define the log source
parsing order.
5. Optional: From the Log Source Host list, select a log source.
6. Prioritize the log source parsing order.
7. Click Save.
© Copyright IBM Corp. 2005, 2018
57
58
QRadar DSM Configuration Guide
6 Log source extensions
An extension document can extend or modify how the elements of a particular log source are parsed. You
can use the extension document to correct a parsing issue or override the default parsing for an event
from an existing DSM.
An extension document can also provide event support when a DSM does not exist to parse events for an
appliance or security device in your network.
An extension document is an Extensible Markup Language (XML) formatted document that you can
create or edit one by using any common text, code or markup editor. You can create multiple extension
documents but a log source can have only one applied to it.
The XML format requires that all regular expression (regex) patterns be contained in character data
(CDATA) sections to prevent the special characters that are required by regular expressions from
interfering with the markup format. For example, the following code shows the regex for finding
protocols:
<pattern id="ProtocolPattern" case-insensitive="true" xmlns="">
<![CDATA[(TCP|UDP|ICMP|GRE)]]></pattern>
(TCP|UDP|ICMP|GRE) is the regular expression pattern.
The log sources extension configuration consists of the following sections:
Pattern
Regular expressions patterns that you associate with a particular field name. Patterns are
referenced multiple times within the log source extension file.
Match groups
An entity within a match group that is parsed, for example, EventName, and is paired with the
appropriate pattern and group for parsing. Any number of match groups can appear in the
extension document.
Examples of log source extensions on QRadar forum
You can create log source extensions (LSX) for log sources that don't have a supported DSM. To help you
create your own log source extensions (also known as DSM extensions), you modify existing ones that
were created.
You can access log source extension examples (https://www.ibm.com/developerworks/community/
forums/html/topic?id=d15cac8d-b0fa-4461-bb1e-dc1b291de440&ps=25) on the Discussion about DSM
Extensions, Custom Properties and other REGEX related topics forum (https://www.ibm.com/
developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000003046&ps=25).
The IBM Security QRadar forums is an online discussion site where users and subject matter experts
collaborate and share information.
Related concepts:
“Creating a log source extensions document to get data into QRadar” on page 72
You create log source extensions (LSX) when log sources don't have a supported DSM, or to repair an
event that has missing or incorrect information, or to parse an event when the associated DSM fails to
produce a result.
© Copyright IBM Corp. 2005, 2018
59
Patterns in log source extension documents
Rather than associating a regular expression directly with a particular field name, patterns (patterns) are
declared separately at the top of the extension document. These regex patterns can be then referenced
multiple times within the log source extension file.
All characters between the start tag <pattern> and end tag </pattern> are considered part of the pattern.
Do not use extra spaces or hard returns inside or around your pattern or <CDATA> expression. Extra
characters or spaces can prevent the DSM extension from matching your intended pattern.
Table 39. Description of pattern parameters
Pattern
Type
Description
id (Required)
String
A regular string that is unique within
the extension document.
case-insensitive (Optional)
Boolean
If true, the character case is ignored.
For example, abc is the same as ABC.
If not specified, this parameter
defaults to false.
trim-whitespace (Optional)
Boolean
If true, whitespace and carriage
returns are ignored. If the CDATA
sections are split onto different lines,
any extra spaces and carriage returns
are not interpreted as part of the
pattern.
If not specified, this parameter
defaults to false.
use-default-pattern (Optional)
Boolean
If true, the system uses Java Patterns
for the Log Source Extension, instead
of the more effective Adaptive
Patterns. Set this option to true if
Adaptive Patterns are providing
inconsistent matching.
If not specified, this parameter
defaults to false.
Defining custom property by using a Regex or JSON expression
You can define a custom property for an event payload by using a Regex or JSON expression.
About this task
Support for the JSON format was added in V7.3.1.
Procedure
1. Log in to QRadar and click the Admin tab.
2. From the Data Sources section, click Custom Event Properties > Add.
3. In the Property Type Selection section, select Extraction Based.
4. In the Test Field, enter the event payload that you want to use to test your custom property.
5. In the Property Definition section, complete the following steps:
a. If you're adding an expression to an existing property, select Existing Property and select a
property from the list.
60
QRadar DSM Configuration Guide
b. If you're defining a new property, select New Property and enter the name of the property.
c. To use the property for rules, reports and searches, select the Parse in advance for rules, reports,
and searches check box.
d. Select a Field Type for the property.
e. Enter a description for the property in the Description field.
6. In the Property Expression Definition section, complete the following steps:
a. Select the Enabled check box to enable or clear the check box to disable the property.
b. From the Log Source Type list, select a log source type for the property.
c. If the expression is only evaluated against events for a specific log source, select a log source from
the Log Source list. Otherwise, select All.
d. If the expression is only evaluated against events with a specific event name or QID, click the
Event Name and browse for a QID to associate the expression with.
e. If the expression is evaluated against any event with a specific low-level category, select Category,
and select the High Level Category and Low Level Category for the event.
Note: If the expression is evaluated for all events of the selected log source type and log source,
ensure that you set the Low Level Category and High Level Category to Any.
f. From the Extraction using field, select the extraction method that is used for the property.
g. If the extraction method is Regex, enter the regex in the Regex field, and enter the capture group
number in the Capture Group field.
h. If the extraction method is JsonKeypath, enter the JSON expression in the JsonKeypath field.
Note: A valid JSON expression is in the form /"<name of top-level field>".
For an event data in a nested JSON format, a valid JSON expression is in the form /"<name of
top-level field>"/"<name of sub-level field_1>".../"<name of sub-level field_n>".
The following two examples show how to extract data from a JSON record:
v Simple case of an event for a flat JSON record: {"action": "login", "user": "John Doe"}
To extract the 'user' field, use this expression: /"user".
v Complex case of an event for a JSON record with nested objects: { "action": "login", "user":
{ "first_name": "John", "last_name": "Doe" } }
To extract just the 'last_name' value from the 'user' subobject, use this expression:
/"user"/"last_name".
i. If you chose the Numeric Field Type in the Property Definition section, select a number format in
the Extracted Number Format field in the Format section to define any digit group separators for
the locale of the custom property.
j. If you chose the Date/Time Field Type in the Property Definition section, enter a format in the
Extracted Date/Time Format and Locale fields in the Format section to define the date and time for
the locale of the custom property.
k. Click Test to test the property expression definition.
7. Click Save.
Match groups
A match group (match-group) is a set of patterns that are used for parsing or modifying one or more types
of events.
A matcher is an entity within a match group that is parsed, for example, EventName, and is paired with
the appropriate pattern and group for parsing. Any number of match groups can appear in the extension
document.
6 Log source extensions
61
Table 40. Description of match group parameters
Parameter
Description
order (Required)
An integer greater than zero that defines the order in
which the match groups are executed. It must be unique
within the extension document.
description (Optional)
A description for the match group, which can be any
string. This information can appear in the logs.
If not specified, this parameter defaults to empty.
device-type-id-override (Optional)
Define a different device ID to override the QID. Allows
the particular match group to search in the specified
device for the event type. It must be a valid log source
type ID, represented as an integer. A list of log source
type IDs is presented in Table 49 on page 82.
If not specified, this parameter defaults to the log source
type of the log source to which the extension is attached.
Match groups can have these entities:
v “Matcher (matcher)”
v “Single-event modifier (event-match-single)” on page 69
v “Multi-event modifier (event-match-multiple)” on page 68
Matcher (matcher)
A matcher entity is a field that is parsed, for example, EventName, and is paired with the appropriate
pattern and group for parsing.
Matchers have an associated order. If multiple matchers are specified for the same field name, the
matchers are run in the order that is presented until a successful parse is found or a failure occurs.
Table 41. Description of matcher parameters
Parameter
Description
field (Required)
The field to which you want the pattern to apply, for example,
EventName, or SourceIp. You can use any of the field names
that are listed in the List of valid matcher field names table.
pattern-id (Required)
The pattern that you want to use when the field is parsed from
the payload. This value must match (including case) the ID
parameter of the pattern that is previously defined in a pattern
ID parameter (Table 39 on page 60).
order (Required)
The order that you want this pattern to attempt among matchers
that are assigned to the same field. If two matchers are assigned
to the EventName field, the one with the lowest order is
attempted first.
62
QRadar DSM Configuration Guide
Table 41. Description of matcher parameters (continued)
Parameter
Description
capture-group (Optional)
Referenced in the regular expression inside parenthesis ( ). These
captures are indexed starting at one and processed from left to
right in the pattern. The capture-group field must be a positive
integer less than or equal to the number of capture groups that
are contained in the pattern. The default value is zero, which is
the entire match.
For example, you can define a single pattern for a source IP
address and port; where the SourceIp matcher can use a capture
group of 1, and the SourcePort matcher can use a capture group
of 2, but only one pattern needs to be defined.
This field has a dual purpose when combined with the
enable-substitutions parameter.
To see an example, review the extension document example.
enable-substitutions (Optional)
Boolean
When you set to true, a field cannot be adequately represented
with a straight group capture. You can combine multiple groups
with extra text to form a value.
This parameter changes the meaning of the capture-group
parameter. The capture-group parameter creates the new value,
and group substitutions are specified by using \x where x is a
group number, 1 - 9. You can use groups multiple times, and
any free-form text can also be inserted into the value. For
example, to form a value out of group 1, followed by an
underscore, followed by group 2, an @, and then group 1 again,
the appropriate capture-group syntax is shown in the following
code:
capture-group=”\1_\2@\1”
In another example, a MAC address is separated by colons, but
in QRadar, MAC addresses are usually hyphen-separated. The
syntax to parse and capture the individual portions is shown in
the following example:
capture-group=”\1:\2:\3:\4:\5:\6”
If no groups are specified in the capture-group when
substitutions are enabled, a direct text replacement occurs.
Default is false.
ext-data (Optional)
An extra-data parameter that defines any extra field information
or formatting that a matcher field can provide in the extension.
The only field that uses this parameter is DeviceTime.
For example, you might have a device that sends events by
using a unique time stamp, but you want the event to be
reformatted to a standard device time. Use the ext-data
parameter included with the DeviceTime field to reformat the
date and time stamp of the event. For more information, see the
List of valid matcher field names.
6 Log source extensions
63
The following table lists valid matcher field names.
Table 42. List of valid matcher field names
Field name
EventName (Required)
EventCategory
Description
The event name to be retrieved from the QID to identify
the event.
Note: This parameter doesn't appear as a field in the
Log Activity tab.
An event category for any event with a category not
handled by an event-match-single entity or an
event-match-multiple entity.
Combined with EventName, EventCategory is used to
search for the event in the QID. The fields that are used
for QIDmap lookups require an override flag to be set
when the devices are already known to QRadar, for
example,
<event-match-single event-name=
"Successfully logged in"
force-qidmap-lookup-on-fixup="true"
device-event-category="CiscoNAC"
severity="4" send-identity=
"OverrideAndNeverSend" />
The force-qidmap-lookup-on-fixup="true" is the flag
override.
Note: This parameter doesn't appear as a field in the
Log Activity tab.
SourceIp
The source IP address for the message.
SourcePort
The source port for the message.
SourceIpPreNAT
The source IP address for the message before Network
Address Translation (NAT) occurs.
SourceIpPostNAT
The source IP address for the message after NAT occurs.
SourceMAC
The source MAC address for the message.
SourcePortPreNAT
The source port for the message before NAT occurs.
SourcePortPostNAT
The source port for the message after NAT occurs.
DestinationIp
The destination IP address for the message.
DestinationPort
The destination port for the message.
DestinationIpPreNAT
The destination IP address for the message before NAT
occurs.
DestinationIpPostNAT
The destination IP address for the message after NAT
occurs.
DestinationPortPreNAT
The destination port for the message before NAT occurs.
DestinationPortPostNAT
The destination port for the message after NAT occurs.
DestinationMAC
The destination MAC address for the message.
64
QRadar DSM Configuration Guide
Table 42. List of valid matcher field names (continued)
Field name
Description
DeviceTime
The time and format that is used by the device. This date
and time stamp represent the time that the event was
sent, according to the device. This parameter doesn't
represent the time that the event arrived. The DeviceTime
field supports the ability to use a custom date and time
stamp for the event by using the ext-data Matcher
attribute.
The following list contains examples of date and time
stamp formats that you can use in the DeviceTime field:
v ext-data="dd/MMM/YYYY:hh:mm:ss"
11/Mar/2015:05:26:00
v ext-data="MMM dd YYYY / hh:mm:ss"
Mar 11 2015 / 05:26:00
v ext-data="hh:mm:ss:dd/MMM/YYYY"
05:26:00:11/Mar/2015
For more information about the possible values for the
data and time stamp format, see the Joda-Time web page
(http://www.joda.org/joda-time/key_format.html).
DeviceTime is the only event field that uses the ext-data
optional parameter.
Protocol
The protocol for the message; for example, TCP, UDP, or
ICMP.
UserName
The user name for the message.
HostName
The host name for the message. Typically, this field is
associated with identity events.
GroupName
The group name for the message. Typically, this field is
associated with identity events.
IdentityIp
The identity IP address for the message.
IdentityMac
The identity MAC address for the message.
IdentityIpv6
The IPv6 identity IP address for the message.
NetBIOSName
The NetBIOS name for the message. Typically, this field
is associated with identity events.
ExtraIdentityData
Any user-specific data for the message. Typically, this
field is associated with identity events.
SourceIpv6
The IPv6 source IP address for the message.
DestinationIpv6
The IPv6 destination IP address for the message.
JSON matcher (json-matcher)
A JSON-matcher (json-matcher) entity is a field that is parsed and is paired with the appropriate pattern
and group for parsing. This entity is new in IBM Security QRadar V7.3.1.
If multiple matchers are specified for the same field name, the matchers are run in the order that is
presented until a successful parse is found.
6 Log source extensions
65
Table 43. Description of JSON matcher parameters
Parameter
Description
field (Required)
The field to which you want the pattern to apply; for example,
EventName or SourceIp. You can use any of the field names that
are listed in the List of valid matcher field names table.
pattern-id (Required)
The pattern that you want to use when the field is parsed from
the payload. This value must match (including case) the ID
parameter of an already defined pattern. (Table 39 on page 60)
order (Required)
The order that you want this pattern to attempt among matchers
that are assigned to the same field. If two matchers are assigned
to the EventName field, the one with the lowest order is
attempted first.
The regular regex matchers and JSON matchers are combined
into one list. The different types of matchers are attempted based
on their orders, and the process stops when one of the matchers
is able to parse out data from the payload.
enable-substitutions (Optional)
Boolean
When set to true, a field cannot be adequately represented with
a straight group capture. You can combine multiple groups with
extra text to form a value.
Wherever the pattern is in the form of a multi-keypath, set the
enable-subtitutions value to '=true' so that each keypath in the
pattern and expression is replaced with the value that is found
by the payload. For example, if the JSON payload contains the
first_name and last_name fields, but no full_name field, you can
define an expression that contains multiple keypaths, such as
{/"last_name"}, {/"first_name"}. The captured value for this
expression is smith, john.
Default is false.
ext-data (Optional)
An extra-data parameter that defines any extra field information
or formatting that a matcher field can provide in the extension.
The only field that uses this parameter is DeviceTime.
For example, you might have a device that sends events by
using a unique time stamp, but you want the event to be
reformatted to a standard device time. Use the ext-data
parameter included with the DeviceTime field to reformat the
date and time stamp of the event. For more information, see the
List of valid JSON matcher field names.
The following table lists valid JSON matcher field names.
Table 44. List of valid JSON matcher field names
Field name
Description
EventName (Required)
The event name to be retrieved from the QID to identify
the event.
Note: This parameter doesn't appear as a field in the
Log Activity tab.
66
QRadar DSM Configuration Guide
Table 44. List of valid JSON matcher field names (continued)
Field name
Description
EventCategory
An event category for any event with a category that is
not handled by an event-match-single entity or an
event-match-multiple entity.
Combined with EventName, EventCategory is used to
search for the event in the QID. The fields that are used
for QIDmap lookups require an override flag to be set
when the devices are already known to the QRadar
system, for example:
<event-match-single event-name=
"Successfully logged in"
force-qidmap-lookup-on-fixup="true"
device-event-category="CiscoNAC"
severity="4" send-identity=
"OverrideAndNeverSend" />
The force-qidmap-lookup-on-fixup="true" is the flag
override.
Note: This parameter doesn't appear as a field in the
Log Activity tab.
SourceIp
The source IP address for the message.
SourcePort
The source port for the message.
SourceIpPreNAT
The source IP address for the message before Network
Address Translation (NAT) occurs.
SourceIpPostNAT
The source IP address for the message after NAT occurs.
SourceMAC
The source MAC address for the message.
SourcePortPreNAT
The source port for the message before NAT occurs.
SourcePortPostNAT
The source port for the message after NAT occurs.
DestinationIp
The destination IP address for the message.
DestinationPort
The destination port for the message.
DestinationIpPreNAT
The destination IP address for the message before NAT
occurs.
DestinationIpPostNAT
The destination IP address for the message after NAT
occurs.
DestinationPortPreNAT
The destination port for the message before NAT occurs.
DestinationPortPostNAT
The destination port for the message after NAT occurs.
DestinationMAC
The destination MAC address for the message.
6 Log source extensions
67
Table 44. List of valid JSON matcher field names (continued)
Field name
Description
DeviceTime
The time and format that is used by the device. This date
and time stamp represent the time that the event was
sent, according to the device. This parameter doesn't
represent the time that the event arrived. The DeviceTime
field supports the ability to use a custom date and time
stamp for the event by using the ext-data Matcher
attribute.
The following list contains examples of date and time
stamp formats that you can use in the DeviceTime field:
v ext-data="dd/MMM/YYYY:hh:mm:ss"
11/Mar/2015:05:26:00
v ext-data="MMM dd YYYY / hh:mm:ss"
Mar 11 2015 / 05:26:00
v ext-data="hh:mm:ss:dd/MMM/YYYY"
05:26:00:11/Mar/2015
For more information about the possible values for the
data and time stamp format, see the Java
SimpleDateFormat web page (https://docs.oracle.com/
javase/8/docs/api/java/text/SimpleDateFormat.html).
DeviceTime is the only event field that uses the ext-data
parameter.
Protocol
The protocol for the message; for example, TCP, UDP, or
ICMP.
UserName
The user name for the message.
HostName
The host name for the message. Typically, this field is
associated with identity events.
GroupName
The group name for the message. Typically, this field is
associated with identity events.
IdentityIp
The identity IP address for the message.
IdentityMac
The identity MAC address for the message.
IdentityIpv6
The IPv6 identity IP address for the message.
NetBIOSName
The NetBIOS name for the message. Typically, this field
is associated with identity events.
ExtraIdentityData
Any user-specific data for the message. Typically, this
field is associated with identity events.
SourceIpv6
The IPv6 source IP address for the message.
DestinationIpv6
The IPv6 destination IP address for the message.
Multi-event modifier (event-match-multiple)
The multi-event modifier (event-match-multiple) matches a range of event types and then modifies them
as specified by the pattern-id parameter and the capture-group-index parameter.
This match is not done against the payload, but is done against the results of the EventName matcher
previously parsed out of the payload.
68
QRadar DSM Configuration Guide
This entity allows mutation of successful events by changing the device event category, severity, or the
method the event uses to send identity events. The capture-group-index must be an integer value
(substitutions are not supported) and pattern-ID must reference an existing pattern entity. All other
properties are identical to their counterparts in the single-event modifier.
Single-event modifier (event-match-single)
Single-event modifier (event-match-single) matches and then modifies exactly one type of event, as
specified by the required, case-sensitive EventName parameter.
This entity allows mutation of successful events by changing the device event category, severity, or the
method for sending identity events.
When events that match this event name are parsed, the device category, severity, and identity properties
are imposed upon the resulting event.
You must set an event-name attribute and this attribute value matches the value of the EventName field.
In addition, an event-match-single entity consists of these optional properties:
Table 45. Description of single-event parameters
Parameter
Description
device-event-category
A new category for searching for a QID for the event.
This parameter is an optimizing parameter because some
devices have the same category for all events.
severity
The severity of the event. This parameter must be an
integer value 1 - 10.
If a severity of less than 1 or greater than 10 is specified,
the system defaults to 5.
If not specified, the default is whatever is found in the
QID.
send-identity
Specifies the sending of identity change information from
the event. Choose one of the following options:
v UseDSMResults If the DSM returns an identity event,
the event is passed on. If the DSM does not return an
identity event, the extension does not create or modify
the identity information.
This option is the default value if no value is specified.
v SendIfAbsent If the DSM creates identity information,
the identity event is passed through unaffected. If no
identity event is produced by the DSM, but there is
enough information in the event to create an identity
event, an event is generated with all the relevant fields
set.
v OverrideAndAlwaysSend Ignores any identity event that
is returned by the DSM and creates a new identity
event, if there is enough information.
v OverrideAndNeverSend Suppress any identity
information that is returned by the DSM. Suggested
option unless you are processing events that you want
to go into asset updates.
6 Log source extensions
69
Extension document template
The example of an extension document provides information about how to parse one particular type of
Cisco FWSM so that events are not sent with an incorrect event name.
For example, if you want to resolve the word session, which is embedded in the middle of the event
name:
Nov 17 09:28:26 192.0.2.1 %FWSM-session-0-302015:
Built UDP connection for faddr <IP_address1>/80
gaddr <IP_address2>/31696 laddr <IP_address3>/2157
duration 0:00:00 bytes 57498 (TCP FINs)
This condition causes the DSM to not recognize any events and all the events are unparsed and
associated with the generic logger.
Although only a portion of the text string (302015) is used for the QID search, the entire text string
(%FWSM-session-0-302015) identifies the event as coming from a Cisco FWSM. Since the entire text string
is not valid, the DSM assumes that the event is not valid.
Extension document example for parsing one event type
An FWSM device has many event types and many with unique formats. The following extension
document example indicates how to parse one event type.
Note: The pattern IDs do not have to match the field names that they are parsing. Although the
following example duplicates the pattern, the SourceIp field and the SourceIpPreNAT field cab use the
exact same pattern in this case. This situation might not be true in all FWSM events.
<?xml version="1.0" encoding="UTF-8"?>
<device-extension xmlns="event_parsing/device_extension">
<pattern id="EventNameFWSM_Pattern" xmlns=""><![CDATA[%FWSM[a-zA-Z\-]*\d-(\d{1,6})]]></pattern>
<pattern id="SourceIp_Pattern" xmlns=""><![CDATA[gaddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="SourceIpPreNAT_Pattern" xmlns=""><![CDATA[gaddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="SourceIpPostNAT_Pattern" xmlns=""><![CDATA[laddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="DestinationIp_Pattern" xmlns=""><![CDATA[faddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="Protocol_Pattern" case-insensitive="true" xmlns=""><![CDATA[(tcp|udp|icmp|gre)]]></pattern>
<pattern id="Protocol_6_Pattern" case-insensitive="true" xmlns=""><![CDATA[protocol=6]]></pattern>
<pattern id="EventNameId_Pattern" xmlns=""><![CDATA[(\d{1,6})]]></pattern>
<match-group order="1" description="FWSM Test" device-type-id-override="6" xmlns="">
<matcher field="EventName" order="1" pattern-id="EventNameFWSM_Pattern" capture-group="1"/>
<matcher field="SourceIp" order="1" pattern-id="SourceIp_Pattern" capture-group="1" />
<matcher field="SourcePort" order="1" pattern-id="SourcePort_Pattern" capture-group="2"/>
<matcher field="SourceIpPreNAT" order="1" pattern-id="SourceIpPreNAT_Pattern" capture-group="1" />
<matcher field="SourceIpPostNAT" order="1" pattern-id="SourceIpPostNAT_Pattern" capture-group="1" />
<matcher field="SourcePortPreNAT" order="1" pattern-id="SourcePortPreNAT_Pattern" capture-group="2" />
<matcher field="SourcePortPostNAT" order="1" pattern-id="SourcePortPostNAT_Pattern" capture-group="2" />
<matcher field="DestinationIp" order="1" pattern-id="DestinationIp_Pattern" capture-group="1" />
<matcher field="DestinationPort" order="1" pattern-id="DestinationIp_Pattern" capture-group="2" />
<matcher field="Protocol" order="1" pattern-id="Protocol_Pattern" capture-group="1" />
<matcher field="Protocol" order="2" pattern-id="Protocol_6_Pattern" capture-group="TCP" enable-substitutions=true/>
<event-match-multiple pattern-id="EventNameId" capture-group-index="1" device-event-category="Cisco Firewall"/>
</match-group>
</device-extension>
<?xml version="1.0" encoding="UTF-8"?>
<device-extension xmlns="event_parsing/device_extension">
<!-- Do not remove the "allEventNames" value -->
<pattern id="EventName-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="SourceIp-Fakeware_Pattern" xmlns=""><![CDATA[]]</pattern>
<pattern id="SourcePort-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="SourceMAC-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="DestinationIp-Fakeware_Pattern" xmlns=""><![CDATA[]]></pattern>
<pattern id="DestinationPort-Fakeware_Pattern" case-insensitive="true" xmlns=""><![CDATA[]]></pattern>
<pattern id="Protocol-Fakeware_Pattern" case-insensitive="true" xmlns=""><![CDATA[]]></pattern>
<match-group order="1" description="FWSM Test" device-type-id-override="6" xmlns="">
<matcher field="EventName" order="1" pattern-id="EventName-Fakeware_Pattern" capture-group="1"/>
<matcher field="SourceIp" order="1" pattern-id="SourceIp-Fakeware_Pattern" capture-group="1" />
<matcher field="SourcePort" order="1" pattern-id="SourcePort-Fakeware_Pattern" capture-group="1"/>
<matcher field="SourceMAC" order="1" pattern-id="SourceMAC-Fakeware_Pattern" capture-group="1" />
<matcher field="DestinationIp" order="1" pattern-id="DestinationIp-Fakeware_Pattern" capture-group="1" />
<matcher field="DestinationPort" order="1" pattern-id="SDestinationPort-Fakeware_Pattern" capture-group="1" />
70
QRadar DSM Configuration Guide
<matcher field="Protocol" order="1" pattern-id="Protocol-Fakeware_Pattern" capture-group="1" />
<event-match-multiple pattern-id="EventNameId" capture-group-index="1" device-event-category="Cisco Firewall"/>
</match-group>
</device-extension>
Parsing basics
The preceding extension document example demonstrates some of the basic aspects of parsing:
v IP addresses
v Ports
v Protocol
v Multiple fields that use the same pattern with different groups
This example parses all FWSM events that follow the specified pattern. The fields that are parsed might
not be present in those events when the events include different content.
The information that was necessary to create this configuration that was not available from the event:
v The event name is only the last 6 digits (302015) of the %FWSM-session-0-302015 portion of the event.
v The FWSM has a hardcoded device event category of Cisco Firewall.
v The FWSM DSM uses the Cisco Pix QIDmap and therefore includes the device-type-id-override="6"
parameter in the match group. The Pix firewall log source type ID is 6. For more informaton, see “Log
Source Type IDs” on page 82).
Note: If the QID information is not specified or is unavailable, you can modify the event mapping. For
more information, see the Modifying Event Mapping section in the IBM Security QRadar User Guide.
Event name and device event category
An event name and a device event category are required when the QIDmap is searched. This device
event category is a grouping parameter within the database that helps define like events within a device.
The event-match-multiple at the end of the match group includes hardcoding of the category. The
event-match-multiple uses the EventNameId pattern on the parsed event name to match up to 6 digits.
This pattern is not run against the full payload, just that portion parsed as the EventName field.
The EventName pattern references the %FWSM portion of the events; all Cisco FWSM events contain the
%FWSM portion. The pattern in the example matches %FWSM followed by any number (zero or more) of
letters and dashes. This pattern match resolves the word session that is embedded in the middle of the
event name that needs to be removed. The event severity (according to Cisco), followed by a dash and
then the true event name as expected by QRadar. The (\d{6}) string is the only string within the
EventNameFWSM pattern that has a capture group.
The IP addresses and ports for the event all follow the same basic pattern: an IP address followed by a
colon followed by the port number. This pattern parses two pieces of data (the IP address and the port),
and specifies different capture groups in the matcher section.
<device-extension>
<pattern id="EventName1">(logger):</pattern>
<pattern id="DeviceTime1">time=\[(\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2})\] </pattern>
<pattern id="Username">(TLSv1)</pattern>
<match-group order="1" description="Full Test">
<matcher field="EventName" order="1" pattern-id="EventName1" capture-group="1"/>
<matcher field="DeviceTime" order="1" pattern-id="DeviceTime1"
capture-group="1" ext-data="dd/MMM/YYYY:hh:mm:ss"/>
<matcher field="UserName" order="1" pattern-id="Username" capture-group="1"/>
</match-group>
</device-extension>
6 Log source extensions
71
IP address and port patterns
The IP address and port patterns are four sets of one to three digits, separated by periods followed by a
colon and the port number. The IP address section is in a group, as is the port number, but not the colon.
The matcher sections for these fields reference the same pattern name, but a different capture group (the
IP address is group 1 and the port is group 2).
The protocol is a common pattern that searches the payload for the first instance of TCP, UDP, ICMP, or
GRE. The pattern is marked with the case-insensitive parameter so that any occurrence matches.
Although a second protocol pattern does not occur in the event that is used in the example, there is a
second protocol pattern that is defined with an order of two. If the lowest-ordered protocol pattern does
not match, the next one is attempted, and so on. The second protocol pattern also demonstrates direct
substitution; there are no match groups in the pattern, but with the enable-substitutions parameter
enabled, the text TCP can be used in place of protocol=6.
Creating a log source extensions document to get data into QRadar
You create log source extensions (LSX) when log sources don't have a supported DSM, or to repair an
event that has missing or incorrect information, or to parse an event when the associated DSM fails to
produce a result.
When to create a log source extension
For log sources that don't have an official DSM, use a Universal DSM (uDSM) to integrate log sources. A
log source extension (also known as a device extension) is then applied to the uDSM to provide the logic
for parsing the logs. The LSX is based on Java regular expressions and can be used against any protocol
type, such as syslog, JDBC, and Log File. Values can be extracted from the logs and mapped to all
common fields within IBM Security QRadar.
When you use log source extensions to repair missing or incorrect content, any new events that are
produced by the log source extensions are associated to the log source that failed to parse the original
payload. Creating an extension prevents unknown or uncategorized events from being stored as
unknown in QRadar.
Using the DSM Editor to quickly create a log source extension
For IBM Security QRadar V7.2.8 and later, you can use the DSM Editor to create log source extensions.
The DSM Editor provides real-time feedback so that you know whether the log source extension that you
are creating has problems. You use the DSM Editor to extract fields, define custom properties, categorize
events, and define new QID definitions. You can use the DSM Editor to define your own Log Source
Type, which eliminates the need to use a Universal DSM. For more information about the DSM Editor,
see the IBM Security QRadar Administration Guide.
Process for manually creating a log source extension
Alternatively, to manually create a log source extension, complete the following steps:
1. Ensure that a log source is created in QRadar.
Use Universal DSM for the log source type to collect events from a source when the log source type
not listed as a QRadar supported DSM.
For IBM Security QRadar V7.2.8 and later, you don't need to use the Universal DSM to create a new
log source type. If you want, you can use the DSM Editor only to create the new log source type, and
then you manually create the log source. You can attach an LSX to a supported log source type, such
as Windows, Bluecoat, Cisco, and others that are listed as QRadar supported DSMs.
2. To determine what fields are available, use the Log Activity tab to export the logs for evaluation.
72
QRadar DSM Configuration Guide
3. Use the extension document example template to determine the fields that you can use.
It is not necessary to use all of the fields in the template. Determine the values in the log source that
can be mapped to the fields in extension document template.
4. Remove any unused fields and their corresponding Pattern IDs from the log source extension
document.
5. Upload the extension document and apply the extension to the log source.
6. Map the events to their equivalents in the QIDmap.
This manual action on the Log Activity tab is used to map unknown log source events to known
QRadar events so that they can be categorized and processed.
Related concepts:
“Extension document template” on page 70
The example of an extension document provides information about how to parse one particular type of
Cisco FWSM so that events are not sent with an incorrect event name.
“Examples of log source extensions on QRadar forum” on page 59
You can create log source extensions (LSX) for log sources that don't have a supported DSM. To help you
create your own log source extensions (also known as DSM extensions), you modify existing ones that
were created.
Related reference:
157, “QRadar supported DSMs,” on page 993
IBM Security QRadar can collect events from your security products by using a plugin file that is called a
Device Support Module (DSM).
Building a Universal DSM
The first step in building a Universal DSM is to create the log source in IBM Security QRadar. When you
create the log source, it prevents the logs from being automatically classified and you can export the logs
for review.
Procedure
1. On the Admin tab, click the Log Sources icon.
2. Click Add.
3. Specify the name in the Log Source Name field.
4. From the Log Source Type list, select Universal DSM.
You might not see the Log Source Extension unless you already applied a log source extension to the
QRadar Console
5. From the Protocol Configuration list, specify the protocol that you want to use.
This method is used by QRadar to get the logs from the unsupported log source.
6. For the Log Source Identifier, enter either the IP address or host name of the unsupported log source.
7. Click Save to save the new log source and close the window.
8. From the Admin tab, click Deploy Changes.
What to do next
“Exporting the logs”
Exporting the logs
Export the logs that are created after you build a Universal DSM.
6 Log source extensions
73
About this task
Typically you want a significant number of logs for review. Depending on the EPS rate of the
unsupported log source, it might take several hours to obtain a comprehensive log sample.
When QRadar can't detect the log source type, events are collected, but are not parsed. You can filter on
these unparsed events and then review the last system notification that you received. After you reviewed
the system notification, you can create a search that is based on that time frame.
Procedure
1.
To look at only the events that are not parsed, filter the logs.
a. Click the Log Activity tab.
b. Click Add Filter.
c. Select Event is Unparsed.
Tip: Type inside the Parameter text box to see the Event is Unparsed item.
d. Select a time frame.
e. If you see Information events from system notifications, right-click to filter them out.
f. Review the Source IP column to determine what device is sending the events.
You can view the raw event payloads. Typically, manufacturers put identifiable product names in
the headers, so you can set your search to Display: Raw Events to show the payloads without
having to manually open each event. Sorting by network can also help you find a specific device
where the event originated from.
2. Create a search for exporting the logs.
a. From the Log Activity tab, select Search > Edit Search.
b. For the Time Range, specify as enough time, for example 6 hours, from when the log source was
created.
c. Under Search Parameters, from the Parameter list, select Log Source (Indexed), from the Operator
list, select Equals, and from the Log Source Group list, select Other, specify the log source that
was created when you built the Universal DSM.
Note: Depending on your settings, you might see Log Source in the Parameter list instead of Log
Source (Indexed).
d. Click Search to view the results.
3. Review the results in the console to check the payload.
4. Optionally, you can export the results by clicking select Actions > Export to XML > Full Export (All
Columns).
Don't select Export to CSV because the payload might be split across multiple columns, therefore
making it difficult to find the payload. XML is the preferred format for event reviews.
74
QRadar DSM Configuration Guide
a. You are prompted to download a compressed file. Open the compressed file and then open the
resulting file.
b. Review the logs.
Event payloads are between the following tags:
<payloadAsUTF>
...
</payloadAsUTF>
The following code shows an example payload:
<payloadAsUTF>ecs-ep (pid 4162 4163 4164) is running... </payloadAsUTF>
A critical step in creating a Universal DSM is reviewing the logs for usability. At a minimum, the
logs must have a value that can be mapped to an event name. The event name must be a unique
value that can distinguish the various log types.
The following code shows an example of usable logs:
May 20 17:16:14 <server>[22331]: bad password attempt for ’root’
from <IP_address>:3364
May 20 17:16:26 <server>[22331]: password auth succeeded for
’root’ from <IP_address>:3364
May 20 16:42:19 kernel: DROP IN=vlan2 OUT=
MAC=<MAC_address> SRC=<IP_address>
DST=<IP_address> PROTO=UDP SPT=67 DPT=68
The following codes shows an example of slightly less usable logs:
Oct 26 08:12:08
no map for prod
Oct 26 16:35:00
Nov 24 01:30:00
(rc=-1, opening
No such file or
loopback 1256559128 autotrace[215824]: W: trace:
49420003, idf 010029a2, lal 00af0008
<server> last message repeated 7 times
<server> /usr/local/monitor-rrd/<server>/.rrd
’/usr/local/monitor-rrd/<server>/.rrd’:
directory)
Common regular expressions
Use regular expressions to match patterns of text in the log source file. You can scan messages for
patterns of letters, numbers, or a combination of both. For example, you can create regular expressions
that match source and destination IP addresses, ports, MAC addresses, and more.
The following codes show several common regular expressions:
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} \d{1,5}
(?:[0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2} (TCP|UDP|ICMP|GRE)
\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}
\s \t .*?
The escape character, or "\", is used to denote a literal character. For example, "." character means "any
single character" and matches A, B, 1, X, and so on. To match the "." characters, a literal match, you must
use "\."
Table 46. Common regex expressions
Type
Expression
IP Address
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
MAC Address
(?:[0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2}
Port Number
\d{1,5}
Protocol
(TCP|UDP|ICMP|GRE)
Device Time
\w{3}\s\d{2}\s\d{2}:\d{2}:\d{2}
Whitespace
\s
Tab
\t
Match Anything
.*?
6 Log source extensions
75
Tip: To ensure that you don't accidentally match another characters, escape any non-digit or non-alpha
character.
Building regular expression patterns
To create a Universal DSM, you use regular expressions (regex) to match strings of text from the
unsupported log source.
About this task
The following example shows a log entry that is referenced in the steps.
May 20 17:24:59 kernel: DROP MAC=<MAC_address>
SRC=<Source_IP_address> DST=<Destination_IP_address> LEN=351 TOS=0x00 PREC=0x00 TTL=64 ID=9582
PROTO=UDP SPT=67 DPT=68 LEN=331
May 20 17:24:59 kernel: PASS MAC=<MAC_address>
SRC=<Source_IP_address> DST=<Destination_IP_address> LEN=351 TOS=0x00 PREC=0x00 TTL=64
ID=9583 PROTO=TCP SPT=1057 DPT=80 LEN=331
May 20 17:24:59 kernel: REJECT
MAC=<MAC_address> SRC=<Source_IP_address> DST=<Destination_IP_address> LEN=351
TOS=0x00 PREC=0x00 TTL=64 ID=9584 PROTO=TCP SPT=25212 DPT=6881 LEN=331
Procedure
1. Visually analyze the unsupported log source to identify unique patterns.
These patterns are later translated into regular expressions.
2. Find the text strings to match.
Tip: To provide basic error checking, include characters before and after the values to prevent similar
values from being unintentionally matched. You can later isolate the actual value from the extra
characters.
3. Develop pseudo-code for matching patterns and include the space character to denote the beginning
and end of a pattern.
You can ignore the quotes. In the example log entry, the event names are DROP, PASS, and REJECT.
The following list shows the usable event fields.
v EventName: " kernel: VALUE "
v SourceMAC: " MAC=VALUE "
v SourceIp: " SRC=VALUE "
v DestinationIp: " DST=VALUE "
v Protocol: " PROTO=VALUE "
v SourcePort: " SPT=VALUE "
v DestinationPort: " DPT=VALUE "
4. Substitute a space with the \s regular expression.
You must use an escape character for non-digit or non-alpha characters. For example, = becomes \=
and : becomes \:.
5. Translate the pseudo-code to a regular expression.
Table 47. Translating pseudo-code to regular expressions
Field
Pseudo-code
Regular expression
EventName
" kernel: VALUE
\skernel\:\s.*?\s
"
SourceMAC
76
QRadar DSM Configuration Guide
" MAC=VALUE "
\sMAC\=(?:[0-9a-fA-F]{2}\:){5}[0-9a-fAF]{2}\s
Table 47. Translating pseudo-code to regular expressions (continued)
Field
Pseudo-code
Regular expression
SourceIP
" SRC=VALUE "
\sSRC\=\d{1,3}\.\d{1,3}\.\d{1,3}\.\
d{1,3}\s
DestinationIp
" DST=VALUE "
\sDST\=\d{1,3}\.\d{1,3}\.\d{1,3}\.\
d{1,3}\s
Protocol
" PROTO=VALUE "
\sPROTO\=(TCP|UDP|ICMP|GRE)\s
SourcePort
" SPT=VALUE "
\sSPT\=\d{1,5}\s
DestinationPort
" DPT=VALUE "
\sDPT\=\d{1,5}\s
6. Specify capture groups.
A capture group isolates a certain value in the regular expression.
For example, in the SourcePort pattern in the previous example, you can't pass the entire value since
it includes spaces and SRC=<code>. Instead, you specify only the port number by using a capture
group. The value in the capture group is what is passed to the relevant field in IBM Security QRadar.
Insert parenthesis around the values you that you want capture:
Table 48. Mapping regular expressions to capture groups for event fields
Field
Regular expression
Capture group
EventName
\skernel\:\s.*?\s
\skernel\:\s(.*?)\s
SourceMAC
\sMAC\=(?:[0-9a-fAF]{2}\:){5}[0-9a-fA-F]{2}\s
\sMAC\=((?:[0-9a-fAF]{2}\:){5}[0-9a-fA-F]{2})\s
SourceIP
\sSRC\=\d{1,3}\.\d{1,3}\.\d{1,3}\.\
d{1,3}\s
\sSRC\=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\
d{1,3})\s
Destination IP
\sDST\=\d{1,3}\.\d{1,3}\.\d{1,3}\.\
d{1,3}\s
\sDST\=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\
d{1,3})\s
Protocol
\sPROTO\=(TCP|UDP|ICMP|GRE)\s
\sPROTO\=((TCP|UDP|ICMP|GRE))\s
SourcePort
\sSPT\=\d{1,5}\s
\sSPT\=(\d{1,5})\s
DestinationPort
\sDPT\=\d{1,5}\s
\sDPT\=(\d{1,5})\s
7. Migrate the patterns and capture groups into the log source extensions document.
The following code snippet shows part of the document that you use.
<device-extension xmlns="event_parsing/device_extension">
<pattern id="EventNameFWSM_Pattern" xmlns=""><![CDATA[%FWSM[a-zA-Z\-]*\d-(\d{1,6})]]></pattern>
<pattern id="SourceIp_Pattern" xmlns=""><![CDATA[gaddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="SourceIpPreNAT_Pattern" xmlns=""><![CDATA[gaddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="SourceIpPostNAT_Pattern" xmlns=""><![CDATA[laddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="DestinationIp_Pattern" xmlns=""><![CDATA[faddr (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/([\d]{1,5})]]></pattern>
<pattern id="Protocol_Pattern" case-insensitive="true" xmlns=""><![CDATA[(TCP|UDP|ICMP|GRE)]]></pattern>
<pattern id="Protocol_6_Pattern" case-insensitive="true" xmlns=""><![CDATA[protocol=6]]></pattern>
<pattern id="EventNameId_Pattern" xmlns=""><![CDATA[(\d{1,6})]]></pattern>
Uploading extension documents to QRadar
You can create multiple extension documents and then upload them and associated them to various log
source types. The logic from the log source extension (LSX) is then used to parse the logs from the
unsupported log source.
Extension documents can be stored anywhere before you upload to IBM Security QRadar.
Procedure
1. On the Admin tab, click Log Source Extensions.
2. Click Add.
3. Assign a name.
4. If you are using the Universal DSM, don't select the extension document as the default for a Log
Source Type.
6 Log source extensions
77
By selecting the Universal DSM as the default, it affects all associated log sources. A Universal DSM
can be used to define the parsing logic for multiple custom and unsupported event sources.
5. Optional: If you want to apply this log source extension to more than one instance of a log source
type, select the log source type from the available Log Source Type list and click the add arrow to set
it as the default.
Setting the default log source type applies the log source extension to all events of a log source type,
including those log sources that are automatically discovered.
Ensure that you test the extension for the log source type first to ensure that the events are parsed
correctly.
6. Click Browse to locate the LSX that you saved and then click Upload.
QRadar validates the document against the internal XSD and verifies the validity of the document
before the extension document is uploaded to the system.
7. Click Save and close the window.
8. Associate the log source extension to a log source.
a. From the Admin tab, click Data Sources > Log Sources.
b. Double-click the log source type that you created the extension document for.
c. From the Log Source Extension list, select the document that you created.
d. Click Save and close the window.
Mapping unknown events
Initially, all of the events from the Universal DSM appear as unknown in the Log Activity tab in QRadar.
You must manually map all unknown events to their equivalents in the QID map.
Although the event names, such as DROP, DENY, and ACCEPT, might be understandable values when
you see them in the log files, QRadar doesn't understand what these values represent. To QRadar, these
values are strings of text that are not mapped to any known values. The values appear as expected and
are treated as normalized events until you manually map them.
In some instances, such as an intrusion detection system (IDS) or an intrusion detection and prevention
system (IDP) thousands of events exist and require mapping. In these situations, you can map a category
as the event name instead of the itself. For example, in the following example, to reduce the number of
mappings, instead of using the name field for the Event Name, use the category field instead. You can
use a custom property to display the event name (Code Red v412):
date: "Feb 25 2010 00:43:26"; name: "SQL Slammer v312"; category: "Worm
Activity"; source ip: "<IP_address>";⌂date:
"Feb 25 2015 00:43:26"; name: "Code Red v412"; category: "Worm Activity";
source ip: "<IP_address>"; date: "Feb 25 2015 00:43:26"; name:
"Annoying Toolbar"; category: "Malware"; source ip: "<IP_address>";
Instead of using the name field for the Event Name, use the category field instead. The actual event
name, for example Code Red v412, can be displayed using a custom property.
Before you begin
Ensure that you uploaded the log source extension document and applied it to the Universal DSM. For
more information, see “Uploading extension documents to QRadar” on page 77.
Procedure
1. From the Log Activity tab, click Search > Edit Search
2. From the Time Range options, choose enough time, such as 15 minutes, from when the log source
extension was applied to the Universal DSM.
78
QRadar DSM Configuration Guide
3. Under Search Parameters, select Log Source [Index] from the Parameter list, Equals from the
Operator list and then select the log source that you created from the Log Source Group and the Log
Source lists.
4. Click Search to view the results.
All of the events appear as unknown.
5. Double-click an unknown entry to view the event details.
6. Click Map Event from the toolbar.
The value Log Source Event ID displays an EventName value, for example, DROP, DENY, or
ACCEPT, from the log source extension. The value can't be blank. A blank value indicates that there is
an error in the log source extension document.
7. Map the value that is displayed as the Log Source Event ID to the appropriate QID.
Use the Browse By Category, or QID Search, or both to find a value that best matches the Log
Source Event ID value. For example, the value DROP can be mapped to the QID Firewall Deny Event CRE.
Use the QID with the Event CRE in the name. Most events are specific to a particular log source type.
For example, when you map to a random firewall, Deny QID is similar to mapping the Universal
DSM to events from another log source type. The QID entries that contain the name Event CRE are
generic and are not tied to a particular log source type.
8. Repeat these steps until all unknown events are mapped successfully.
From this point, any further events from the Universal DSM that contain that particular Log Source
Event ID appear as the specified QID. Events that arrived before the QID mapping remain unknown.
There is no supported method for mapping previous events to a current QID. This process must be
repeated until all of the unknown event types are successfully mapped to a QID.
Parsing issues and examples
When you create a log source extension, you might encounter some parsing issues. Use these XML
examples to resolving specific parsing issues.
Converting a protocol
The following example shows a typical protocol conversion that searches for TCP, UDP, ICMP, or GRE
anywhere in the payload. The search pattern is surrounded by any word boundary, for example, tab,
space, end of line. Also, the character case is ignored:
<pattern id="Protocol" case-insensitive="true" xmlns="">
<![CDATA[\b(TCP|UDP|ICMP|GRE)\b]]>
</pattern>
<matcher field="Protocol" order="1" pattern-id="Protocol" capture-group="1" />
Making a single substitution
The following example shows a substitution that parses the source IP address, and then overrides the
result and sets the IP address to 192.0.2.1, ignoring the IP address in the payload.
This example assumes that the source IP address matches something similar to SrcAddress=203.0.113.1
followed by a comma:
<pattern id="SourceIp_AuthenOK" xmlns="">
<![CDATA[SrcAddress=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}),]]>
</pattern>
<matcher field="SourceIp" order="1" pattern-id="SourceIp_AuthenOK"
capture-group="192.0.2.1" enable-substitutions="true"/>
6 Log source extensions
79
Generating a colon-separated MAC address
QRadar detects MAC addresses in a colon-separated form. Because all devices might not use this form,
the following example shows how to correct that situation:
<pattern id="SourceMACWithDashes" xmlns="">
<![CDATA[SourceMAC=([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-([0-9a-fA-F]{2})([0-9a-fA-F]{2})-([0-9a-fA-F]{2})-([0-9a-fA-F]{2})]]>
</pattern>
<matcher field="SourceMAC" order="1" pattern-id="
SourceMACWithDashes" capture-group="\1:\2:\3:\4:\5:\6" />
In the preceding example, SourceMAC=12-34-56-78-90-AB is converted to a MAC address of
12:34:56:78:90:AB.
If the dashes are removed from the pattern, the pattern converts a MAC address and has no separators. If
spaces are inserted, the pattern converts a space-separated MAC address.
Combining IP address and port
Typically an IP address and port are combined into one field, which is separated by a colon.
The following example uses multiple capture groups with one pattern:
pattern id="SourceIPColonPort" xmlns="">
<! [CDATA[Source=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):([\d]{1,5})]]>
</pattern>
<matcher field="SourceIp" order="1" pattern-id="SourceIPColonPort" capture-group="1" />
<matcher field="SourcePort" order="1" pattern-id="SourceIPColonPort" capture-group="2" />
Modifying an Event Category
A device event category can be hardcoded, or the severity can be adjusted.
The following example adjusts the severity for a single event type:
<event-match-single event-name="TheEvent" device-event-category="Actual Category" severity="6"
send-identity="UseDSMResults" />
Suppressing identity change events
A DSM might unnecessarily send identity change events.
The following examples show how to suppress identity change events from being sent from a single
event type and a group of events.
// Never send identity for the event with an EventName of Authen OK
<event-match-single event-name="Authen OK" device-event-category="ACS"
severity="6" send-identity="OverrideAndNeverSend" />
// Never send any identity for an event with an event name starting with 7,
followed by one to five other digits:
<pattern id="EventNameId" xmlns=""><![CDATA[(7\d{1,5})]]>
</pattern>
<event-match-multiple pattern-id="EventNameId" capture-group-index="1"
device-event-category="Cisco Firewall" severity="7"
send-identity="OverrideAndNeverSend"/>
80
QRadar DSM Configuration Guide
Formatting event dates and time stamps
A log source extension can detect several different date and time stamp formats on events.
Because device manufacturers do not conform to a standard date and time stamp format, the ext-data
optional parameter is included in the log source extension to allow the DeviceTime to be reformatted. The
following example shows how an event can be reformatted to correct the date and time stamp
formatting:
<device-extension>
<pattern id="EventName1">(logger):</pattern>
<pattern id="DeviceTime1">time=\[(\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2})\]</pattern>
<pattern id="Username">(TLSv1)</pattern>
<match-group order="1" description="Full Test">
<matcher field="EventName" order="1" pattern-id="EventName1_Pattern" capture-group="1"/>
<matcher field="DeviceTime" order="1" pattern-id="DeviceTime1_Pattern"
capture-group="1" ext-data="dd/MMM/YYYY:hh:mm:ss"/>
<matcher field="UserName" order="1" pattern-id="Username_Pattern" capture-group="1"/>
</match-group>
</device-extension>
Multiple Log Formats in a Single Log Source
Occasionally, multiple log formats are included in a single log source.
May 20 17:15:50 kernel: DROP IN=vlan2 OUT= MAC= SRC=<Source_IP_address>
DST=<Destination_IP_address> PROTO=UDP SPT=1900 DPT=1900
May 20 17:16:26 <server>[22331]: password auth succeeded for ’root’ from <IP_address>
May 20 17:16:28 <server>[22331]: exit after auth (root): Exited normally </br>
May 20 17:16:14 <server>[22331]: bad password attempt for ’root’ from <IP_address>:3364
For example, there are 2 log formats: one for firewall events, and one for authentication events. You must
write multiple patterns for parsing the events. You can specify the order to be parsed. Typically, the more
frequent events are parsed first, followed by the less frequent events. You can have as many patterns as
required to parse all of the events. The order variable determines what order the patterns are matched in.
The following example shows multiple formats for the following fields EventName and UserName
Separate patterns are written to parse each unique log type. Both of the patterns are referenced when you
assign the value to the normalized fields.
<pattern id="EventName-DDWRT-FW_Pattern" xmlns=""><![CDATA[kernel\:\s(.*?)\s]]></pattern>
<pattern id="EventName-DDWRT-Auth_Pattern" xmlns=""><![CDATA[sdrophear\[\d{1,5}\]|:\s(.*?\s.*?)\s]]>
</pattern>
<pattern id="UserName_DDWRT-Auth1__Pattern" xmlns=""><![CDATA[\sfor\s\’(.*?)\’s]]></pattern>
<pattern id="UserName_DDWRT-Auth2__Pattern" xmlns=""><![CDATA[\safter\sauth\s\((.*?)\)\:]]></pattern>
<match-group order="1" description="DD-WRT Device Extensions xmlns="">
<matcher field="EventName" order="1" pattern-id="EventName-DDWRT-FW_Pattern" capture-group="1"/>
<matcher field="EventName" order="2" pattern-id="EventName-DDWRT-Auth_Pattern" capture-group="1"/>
<matcher field="UserName" order="1" pattern-id="UserName-DDWRT-Auth1_Pattern" capture-group="1"/>
<matcher field="UserName" order="2" pattern-id="UserName-DDWRT-Auth2_Pattern" capture-group="1"/>
Parsing a CSV log format
A CSV-formatted log file can use a single parser that has multiple capture groups. It is not always
necessary to create multiple Pattern IDs when you parse this log type.
6 Log source extensions
81
About this task
The following log sample is used:
Event,User,Source IP,Source Port,Destination IP,Destination Port
Failed Login,<Username>,<Source_IP_address>,1024,<Destination_IP_address>,22
Successful Login,<Username>,<Source_IP_address>,1743,<Destination_IP_address>,110
Privilege Escalation,<Username>,<Source_IP_address>,1028,<Destination_IP_address>,23
Procedure
1. Create a parser that matches all relevant values by using the previous patterns.
.*?\,.*?\,\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
\,\d{1,5}\,\d{1,3}\.\d{1,3} \.\d{1,3}\.\d{1,3}\,\d{1,5}
2. Place the capture groups around each value:
(.*?)\,(.*?)\,(\d{1,3}\.\d{1,3}\.\d{1,3}\.
\d{1,3})\,(\d{1,5})\,(\d{1,3} \.\d{1,3}\.\d{1,3}\.\d{1,3})\,(\d{1,5})
3. Map the field that each capture group is mapped to, incrementing the value as you move.
1 = Event, 2 = User, 3 = Source IP,
4 = Source Port, 5 = Destination IP, 6 = Destination Port
4. Include the values in the log source extension by mapping the capture group to the relevant event.
The following code shows a partial example of mapping the capture group to the relevant event.
<pattern id="CSV-Parser_Pattern" xmlns=""><![CDATA 9.*?)\,(.*?)\,(\d{1,3}\.\{1,3}\.{1,3}]]></pattern>
<match-group order="1" description="Log Source Extension xmlns="">
<matcher field="EventName" order="1" pattern-id="CSV-Parser_Pattern" capture-group="1"/>
<matcher field="SourceIP" order="1" pattern-id="CSV-Parser_Pattern" capture-group="3"/>
<matcher field="SourcePort" order="1" pattern-id="CSV-Parser_Pattern" capture-group="4"/>
<matcher field="DestinationIP" order="1" pattern-id="CSV-Parser_Pattern" capture-group="5"/>
<matcher field="DestinationPort" order="1" pattern-id="CSV-Parser_Pattern" capture-group="6"/>
<matcher field="UserName" order="1" pattern-id="CSV-Parser_Pattern" capture-group="2"/>
5. Upload the log source extension.
6. Map the events.
Related tasks:
“Mapping unknown events” on page 78
Initially, all of the events from the Universal DSM appear as unknown in the Log Activity tab in QRadar.
You must manually map all unknown events to their equivalents in the QID map.
Log Source Type IDs
IBM Security QRadar supports a number of log sources and each log source has an identifier. Use the
Log Source Type IDs in a match-group statement:
The following table lists the supported log source type and their IDs.
Table 49. Log Source Type ID
ID
Log Source Type
2
Snort Open Source IDS
3
Check Point (formerly Firewall-1)
4
Configurable Firewall Filter
5
Juniper Networks Firewall and VPN
6
Cisco PIX Firewall
7
Configurable Authentication message filter
9
Extreme Dragon Network IPS
10
Apache HTTP Server
82
QRadar DSM Configuration Guide
Table 49. Log Source Type ID (continued)
ID
Log Source Type
11
Linux OS
12
Microsoft Windows Security Event Log
13
Microsoft IIS
14
Linux iptables Firewall
15
IBM Proventia Network Intrusion Prevention System
(IPS)
17
Juniper Networks Intrusion Detection and Prevention
(IDP)
19
TippingPoint Intrusion Prevention System (IPS)
20
Cisco IOS
22
Nortel Multiprotocol Router
23
Cisco VPN 3000 Series Concentrator
24
Solaris Operating System Authentication Messages
25
McAfee IntruShield Network IPS Appliance
26
Cisco CSA
28
Extreme Matrix E1 Switch
29
Solaris Operating System Sendmail Logs
30
Cisco Intrusion Prevention System (IPS)
31
Cisco Firewall Services Module (FWSM)
33
IBM Proventia Management SiteProtector
35
CyberGuard TSP Firewall/VPN
36
Juniper Networks Secure Access (SA) SSL VPN
37
Nortel Contivity VPN Switch
38
Top Layer (IPS)
39
Universal DSM
40
Tripwire Enterprise
41
Cisco Adaptive Security Appliance (ASA)
42
Niksun 2005 v3.5
45
Juniper Networks Network and Security Manager
46
Squid Web Proxy
47
Ambiron TrustWave ipAngel Intrusion Prevention
System (IPS)
48
Oracle RDBMS Audit Record
49
F5 Networks BIG-IP LTM
50
Solaris Operating System DHCP Logs
55
Array Networks SSL VPN Access Gateways
56
Cisco CatOS for Catalyst Switches
57
ProFTPD Server
58
Linux DHCP Server
59
Juniper Networks Infranet Controller
64
Juniper Junos OS Platform
6 Log source extensions
83
Table 49. Log Source Type ID (continued)
ID
Log Source Type
68
Extreme Matrix K/N/S Series Switch
70
Extreme Networks ExtremeWare Operating System (OS)
71
McAfee Firewall Enterprise
73
Fortinet FortiGate Security Gateway
78
SonicWALL SonicOS
79
Vericept Content 360
82
Symantec Gateway Security (SGS) Appliance
83
Juniper Steel-Belted Radius
85
IBM AIX Server
86
Metainfo MetaIP
87
Symantec System Center
90
Cisco ACS
91
Enterasys Sentinel DSM
92
ForeScout CounterACT
93
McAfee ePolicy Orchestrator
95
Cisco NAC Appliance
96
TippingPoint X Series Appliances
97
Microsoft DHCP Server
98
Microsoft IAS Server
99
Microsoft Exchange Server
100
Trend InterScan VirusWall
101
Microsoft SQL Server
102
MAC OS X
103
Blue Coat SG Appliance
104
Nortel Switched Firewall 6000
105
SIM Audit
106
3Com 8800 Series Switch
107
Nortel VPN Gateway
108
Nortel Threat Protection System (TPS) Intrusion Sensor
110
Nortel Application Switch
111
Juniper DX Application Acceleration Platform
112
SNARE Reflector Server
113
Cisco 12000 Series Routers
114
Cisco 6500 Series Switches
115
Cisco 7600 Series Routers
116
Cisco Carrier Routing System
117
Cisco Integrated Services Router
118
Juniper M Series Multiservice Edge Routing
120
Nortel Switched Firewall 5100
122
Juniper MX Series Ethernet Services Router
84
QRadar DSM Configuration Guide
Table 49. Log Source Type ID (continued)
ID
Log Source Type
123
Juniper T Series Core Platform
134
Nortel Ethernet Routing Switch 8300/8600
135
Nortel Ethernet Routing Switch 2500/4500/5500
136
Nortel Secure Router
138
OpenBSD OS
139
Juniper Ex Series Ethernet Switch
140
Symark Power Broker
141
Oracle Database Listener
142
Samhain HIDS
143
Bridgewater Systems AAA Service Controller
144
Name Value Pair
145
Nortel Secure Network Access Switch (SNAS)
146
Starent Networks Home Agent (HA)
148
IBM AS/400 iSeries
149
Foundry Fastiron
150
Juniper SRX Series Services Gateway
153
CRYPTOCard CRYPTOShield
154
Imperva SecureSphere
155
Aruba Mobility Controller
156
Extreme NetsightASM
157
Extreme HiGuard
158
Motorola SymbolAP
159
Extreme HiPath
160
Symantec Endpoint Protection
161
IBM Resource Access Control Facility (RACF)
163
RSA Authentication Manager
164
Redback ASE
165
Trend Micro Office Scan
166
Extreme XSR Security Routers
167
Extreme Stackable and Standalone Switches
168
Juniper Networks AVT
170
Extreme A2-Series
171
Extreme B2-Series
172
Extreme B3-Series
173
Extreme C2-Series
174
Extreme C3-Series
175
Extreme D2-Series
176
Extreme G3-Series
177
Extreme I3-Series
178
Trend Micro Control Manager
6 Log source extensions
85
Table 49. Log Source Type ID (continued)
ID
Log Source Type
179
Cisco IronPort
180
Hewlett Packard UniX
182
Cisco Aironet
183
Cisco Wireless Services Module (WiSM)
185
ISC BIND
186
IBM Lotus Domino
187
HP Tandem
188
Sentrigo Hedgehog
189
Sybase ASE
191
Microsoft ISA
192
Juniper SRC
193
Radware DefensePro
194
Cisco ACE Firewall
195
IBM DB2
196
Oracle Audit Vault
197
Cicso FireSIGHT Management Center
198
Forcepoint V Series
199
Oracle RDBMS OS Audit Record
200
Risk Manager Default Question
206
Palo Alto PA Series
208
HP ProCurve
209
Microsoft Operations Manager
210
EMC VMWare
211
IBM WebSphere Application Server
212
Universal LEEF
213
F5 Networks BIG-IP ASM
214
FireEye
215
Fair Warning
216
IBM Informix Audit
217
CA Top Secret
218
Extreme NAC
219
Microsoft SCOM
220
McAfee Web Gateway
221
CA ACF2
222
McAfee Application / Change Control
223
Lieberman Random Password Manager
224
Sophos Enterprise Console
225
NetApp Data ONTAP
226
Sophos PureMessage
227
Cyber-Ark Vault
86
QRadar DSM Configuration Guide
Table 49. Log Source Type ID (continued)
ID
Log Source Type
228
Itron Smart Meter
230
Bit9 Security Platform
231
IBM IMS
232
F5 Networks FirePass
233
Citrix NetScaler
234
F5 Networks BIG-IP APM
235
Juniper vGW
236
Symantec DLP
237
Oracle Alert Logs
238
Solaris BSM
239
Oracle BEA WebLogic
240
Sophos Web Security Appliance
241
Sophos Astaro Security Gateway
242
Microsoft SQL Server Trace Log
243
Infoblox NIOS
244
Tropos Control
245
Novell eDirectory
247
VMware vShield
248
Cisco Wireless NCS
249
IBM Guardium
250
Cisco Nexus
251
Stonesoft Management Center
252
SolarWinds Orion
253
Microsoft Endpoint Protection
254
Great Bay Beacon
255
Damballa Failsafe
256
SecWorld X/G/F series
258
CA SiteMinder
259
IBM z/OS
260
Microsoft SharePoint
261
iT-CUBE agileSI
262
CRE Event Response
263
DCN DCS/DCS Series
264
Juniper Security Binary Log Collector
265
Trend Micro Deep Discovery Inspector
266
IBM Tivoli Access Manager for e-business
268
Verdasys Digital Guardian
269
Hauwei S Series Switch
270
Citrix Access Gateway
271
HBGary Active Defense
6 Log source extensions
87
Table 49. Log Source Type ID (continued)
ID
Log Source Type
272
APC UPS
273
Cisco Wireless LAN Controllers
274
Cisco Call Manager
275
CRE System
276
IBM Customer Information Control System (CICS)
278
Barracuda Spam & Virus Firewall
279
Open LDAP Software
280
Application Security DbProtect
281
Barracuda Web Application Firewall
282
OSSEC
283
Huawei AR Series Router
284
Sun ONE LDAP
285
BlueCat Networks Adonis
286
IBM AIX Audit
287
Symantec PGP Universal Server
288
Kaspersky Security Center
289
IBM BigFix
290
Juniper Junos WebApp Secure
291
Nominum Vantio
292
Extreme 800-Series Switch
293
IBM zSecure Alert
294
IBM Security Network Protection (XGS)
295
IBM Security Identity Manager
296
F5 Networks BIG-IP Advanced Firewall Manager (AFM)
297
IBM Security Network IPS (GX)
298
Fidelis XPS
299
Arpeggio SIFT-IT
300
Barracuda Web Filter
302
Brocade FabricOS
303
ThreatGRID Malware Threat Intelligence Platform
304
IBM Security Access Manager for Enterprise Single
Sign-On
305
VmWare vCloud Director
306
Venustech Venusense Unified Threat Management
307
Venustech Venusense Firewall
308
Venustech Venusense Network Intrusion Prevention
System
309
ObserveIT
311
Pirean Access: One
312
Venustech Venusense Security Platform
88
QRadar DSM Configuration Guide
Table 49. Log Source Type ID (continued)
ID
Log Source Type
313
PostFix MailTransferAgent
314
Oracle Fine Grained Auditing
315
VMware vCenter
316
Cisco Identity Services Engine
317
Microsoft System Center Configuration Manager
318
Honeycomb Lexicon File Integrity Monitor
319
Oracle Acme Packet Session Border Controller (SBC)
320
Juniper WirelessLAN
321
Akamai KONA
330
Arbor Networks Peakflow SP
331
Zscaler Nss
332
Proofpoint Enterprise Protection/Enterprise Privacy
333
H3C Comware Platform
334
H3C Switches
335
H3C Routers
336
H3C Wireless LAN Devices
337
H3C IP Security Devices
338
Microsoft Hyper-V
339
Cilasoft QJRN/400
340
Vormetric Data Security
341
SafeNet DataSecure/KeySecure
342
OpenStack Ceilometer
343
STEALTHbits StealthINTERCEPT
344
Juniper DDoS Secure
345
Arbor Networks Pravail
346
IBM Security Trusteer Apex Advanced Walware
Protection
347
Amazon AWS CloudTrail
348
IBM Security Directory Server
349
Extreme A4-Series
350
Extreme B5-Series
351
Extreme C5-Series
352
Salesforce Security Monitoring
353
Ahnlab Policy Center APC
354
Avaya VPN Gateway 3070
356
DG Technology MEAS
357
Salesforce Security Auditing
358
CloudPassage Halo
359
CorreLog Agent for IBM zOS
360
WatchGuard Fireware OS
6 Log source extensions
89
Table 49. Log Source Type ID (continued)
ID
Log Source Type
361
IBM Fiberlink MaaS360
362
Trend Micro Deep Discovery Analyzer
363
Resolution 1 CyberSecurity
364
IBM Privileged Session Recorder
365
Bluemix Platform
366
IBM SmartCloud Orchestrator
367
Universal CEF
369
FreeRADIUS
370
Riverbed SteelCentral NetProfiler
371
Riverbed SteelCentral NetProfiler Audit
372
SSH CryptoAuditor
373
IBM WebSphere DataPower
374
Symantec Critical System Protection
375
Kisco Information Systems SafeNet/i
376
IBM Federated Directory Server
377
HyTrust CloudControl
378
Lastline Enterprise
379
genua genugate
380
IBM Security Privileged Identity Manager
381
Netskope Active
382
Okta Identity Management
383
Oracle Enterprise Manager
384
Microsoft DNS Debug
385
STEALTHbits StealthINTERCEPT Analytics
386
STEALTHbits StealthINTERCEPT Alerts
387
Universal SaaS
388
Cloudera Navigator
389
IBM Security Access Manager for Mobile
390
Skyhigh Networks Cloud Security Platlform
391
Aruba ClearPass Policy Manager
392
IBM Security Identity Governance
393
Seculert Seculert
394
Trend Micro Deep Security
395
Epic SIEM
396
Enterprise-IT-Security.com SF-Sherlock
397
Microsoft Office 365
398
Exabeam
399
Blue Coat Web Security Service
400
Carbon Black
401
Trend Micro Deep Discovery Email Inspector
90
QRadar DSM Configuration Guide
Table 49. Log Source Type ID (continued)
ID
Log Source Type
402
Onapsis Inc. Onapsis Security Platform
403
CyberArk Privileged Threat Analytics
404
Palo Alto Networks Endpoint Security Manager
405
Box
406
Radware AppWall
407
CrowdStrike Falcon Host
408
IBM Sense
409
CloudLock Cloud Security Fabric
410
Vectra Networks Vectra
411
HP Network Automation
412
IBM QRadar Packet Capture
413
Microsoft Azure
414
Kaspersky Threat Feed Service
415
ESET Remote Administrator
416
Illumio Adaptive Security Platform
417
SecureAuth IdP
418
Aruba Introspect
419
Cisco Cloud Web Security
421
IBM SAN Volume Controller
422
LightCyber Magna
423
Fasoo Enterprise DRM
425
Imperva Incapsula
426
IBM BigFix EDR
427
Centrify Server Suite (DSM not released yet)
428
Carbon Black Protection
429
Cisco Stealthwatch
430
Amazon Virtual Private Cloud Flow Logs
6 Log source extensions
91
92
QRadar DSM Configuration Guide
7 Log source extension management
You can create log source extensions to extend or modify the parsing routines of specific devices.
A log source extension is an XML file that includes all of the regular expression patterns that are required
to identify and categorize events from the event payload. Extension files can be used to parse events
when you must correct a parsing issue or you must override the default parsing for an event from a
DSM. When a DSM does not exist to parse events for an appliance or security device in your network, an
extension can provide event support. The Log Activity tab identifies log source events in these basic
types:
v Log sources that properly parse the event. Properly parsed events are assigned to the correct log source
type and category. In this case, no intervention or extension is required.
v Log sources that parse events, but have a value Unknown in the Log Source parameter. Unknown
events are log source events where the log source type is identified, but the payload information
cannot be understood by the DSM. The system cannot determine an event identifier from the available
information to properly categorize the event. In this case, the event can be mapped to a category or a
log source extension can be written to repair the event parsing for unknown events.
v Log sources that cannot identify the log source type and have a value of Stored event in the Log
Source parameter. Stored events require you to update your DSM files or write a log source extension
to properly parse the event. After the event parses, you can then map the events.
Before you can add a log source extension, you must create the extension document. The extension
document is an XML document that you can create with any common word processing or text editing
application. Multiple extension documents can be created, uploaded, and associated with various log
source types. The format of the extension document must conform to a standard XML schema document
(XSD). To develop an extension document, knowledge of and experience with XML coding is required.
Adding a log source extension
You can add a log source extension to extend or modify the parsing routines of specific devices.
Procedure
1. Click the Admin tab.
2. Click the Log Source Extensions icon.
3. Click Add.
4. From the Log Source Types list, select one of the following options:
Option
Description
Available
Select this option when the device support module
(DSM) correctly parses most fields for the log source. The
incorrectly parsed field values are enhanced with the
new XML values.
Set to default for
Select log sources to add or remove from the extension
parsing. You can add or remove extensions from a log
source.
When a log source extension is Set to default for a log
source, new log sources of the same Log Source Type
use the assigned log source extension.
5. Click Browse to locate your log source extension XML document.
© Copyright IBM Corp. 2005, 2018
93
6. Click Upload. The contents of the log source extension is displayed to ensure that the proper
extension file is uploaded. The extension file is evaluated against the XSD for errors when the file is
uploaded.
7. Click Save.
Results
If the extension file does not contain any errors, the new log source extension is created and enabled. It is
possible to upload a log source extension without applying the extension to a log source. Any change to
the status of an extension is applied immediately and managed hosts or Consoles enforce the new event
parsing parameters in the log source extension.
What to do next
On the Log Activity tab, verify that the parsing patterns for events is applied correctly. If the log source
categorizes events as Stored, the parsing pattern in the log source extension requires adjustment. You can
review the extension file against log source events to locate any event parsing issues.
94
QRadar DSM Configuration Guide
Part 3. DSMs
© Copyright IBM Corp. 2005, 2018
95
96
QRadar DSM Configuration Guide
8 3Com Switch 8800
The IBM Security QRadar DSM for 3Com Switch 8800 receives events by using syslog.
The following table identifies the specifications for the 3Com Switch 8800 DSM:
Specification
Value
Manufacturer
3Com
DSM name
Switch 8800 Series
RPM file name
DSM-3ComSwitch_qradar-version_buildnumber.noarch.rpm
Supported versions
v3.01.30
Protocol
Syslog
QRadar recorded events
Status and network condition events
Automatically discovered?
Yes
Includes identity?
No
Includes custom event properties?
No
More information
3Com website (http://www.3com.com)
To send 3COM Switch 8800 events to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent 3COM Switch 8800 RPM
on your QRadar Console.
2. Configure each 3COM Switch 8800 instance to communicate with QRadar.
3. If QRadar does not automatically discover the DSM, create a log source on the QRadar Console for
each 3COM Switch 8800 instance. Configure all the required parameters, and use the following table
for specific values:
Parameter
Description
Log Source Type
3COM Switch 8800
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring your 3COM Switch 8800”
Configure your 3COM Switch 8800 to forward syslog events to IBM Security QRadar.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring your 3COM Switch 8800
Configure your 3COM Switch 8800 to forward syslog events to IBM Security QRadar.
© Copyright IBM Corp. 2005, 2018
97
Procedure
1. Log in to 3COM Switch 8800.
2. To enable the information center, type the following command:
info-center enable
3. To configure the log host, type the following command:
info-center loghost QRadar_ip_address facility informational language english
4. To configure the ARP and IP information modules, type the following commands.
info-center source arp channel loghost log level informational
info-center source ip channel loghost log level informational
98
QRadar DSM Configuration Guide
9 AhnLab Policy Center
The IBM Security QRadar DSM for AhnLab Policy Center retrieves events from the DB2 database that
AhnLab Policy Center uses to store their log.
The following table identifies the specifications for the AhnLab Policy Center DSM:
Table 50. AhnLab Policy Center DSM specifications
Specification
Value
Manufacturer
AhnLab
DSM
AhnLab Policy Center
RPM file names
DSM-AhnLabPolicyCenter-QRadar-Release_BuildNumber.noarch.rpm
Supported versions
4.0
Protocol
AhnLabPolicyCenterJdbc
QRadar recorded events
Spyware detection, Virus detection, Audit
Automatically discovered?
No
Includes identity
Yes
More information
Ahnlab website (https://global.ahnlab.com/)
To integrate AhnLab Policy Center DSM with QRadar, complete the following steps:
1. Download and install the most recent versions of the following RPMs on your QRadar Console:
v JDBC protocol RPM
v AhnLabPolicyCenterJdbc protocol RPM
v AhnLab Policy Center RPM
Tip: For more information, see your DB2 documentation.
2. Ensure that your AhnLab Policy Center system meets the following criteria:
v The DB2 Database allows connections from QRadar.
v The port for AhnLabPolicyCenterJdbc Protocol matches the listener port of the DB2 Database.
v Incoming TCP connections on the DB2 Database are enabled to communicate with QRadar.
3. For each AhnLab Policy Center server you want to integrate, create a log source on the QRadar
Console. The following table identifies Ahnlab-specific protocol values:
Parameter
Value
Log Source Type
AhnLab Policy Center APC
Protocol Configuration
AhnLabPolicyCenterJdbc
Access credentials
Use the access credentials of the DB2 server.
Log Source Language
If you use QRadar v7.2 or later, you must select a log
source language.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
© Copyright IBM Corp. 2005, 2018
99
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
100
QRadar DSM Configuration Guide
10 Akamai Kona
The IBM Security QRadar DSM for Akamai KONA collects event logs from your Akamai KONA servers.
The following table identifies the specifications for the Akamai KONA DSM:
Table 51. Akamai KONA DSM specifications
Specification
Value
Manufacturer
Akamai
Product
Kona
DSM RPM name
DSM-AkamaiKona-QRadar_VersionBuild_Number.noarch.rpm
Protocol
HTTP Receiver
QRadar recorded events
Warn Rule Events
Deny Rule Events
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Akamai website (http://www.akamai.com/)
To send Akamai KONA events to QRadar, complete the following steps:
Restriction: This integration requires you to open a non-standard port in your firewall for incoming
Akamai connections. Use an internal proxy to route the incoming Akamai connections. Do not point the
Akamai data stream directly to the QRadar Console. For more information about opening a non-standard
port in your firewall, consult your network security professionals.
1. If automatic updates are not enabled, download and install the most recent versions of the following
RPMs on your QRadar Console:
v DSMCommon RPM
v HTTPReceiver Protocol RPM
v Akamai KONA RPM
2. For each instance of Akamai KONA, configure your Akamai KONA system to communicate with
QRadar. For more information, contact Akamai.
3. If you plan to configure the log source to use the HTTPs and Client Authentication options, copy the
Akamai KONA certificate to the target QRadar Event Collector.
4. For each Akamai KONA server that you want to integrate, create a log source on the QRadar Console.
Configure all the required parameters. Use this table to configure Akamai Kona specific parameters:
© Copyright IBM Corp. 2005, 2018
101
Table 52. Akamai KONA log source parameters
Parameter
Description
Client Certificate Path
The absolute file path to the client certificate on the
target QRadar Event Collector.
Ensure that the Akamai KONA certificate is already
copied to the Event Collector.
If you select the HTTPs and Client Authentication
option from the Communication Type list, the Client
Certificate Path parameter is required .
Listen Port
The destination port that is configured on the Akamai
KONA system
Message Pattern
The Message Pattern '\{"type' is for JSON format
events
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
102
QRadar DSM Configuration Guide
11 Amazon AWS CloudTrail
The IBM Security QRadar DSM for Amazon AWS CloudTrail collects audit events from your Amazon
AWS CloudTrail S3 bucket.
The following table lists the specifications for the Amazon AWS CloudTrail DSM:
Table 53. Amazon AWS CloudTrail DSM specifications
Specification
Value
Manufacturer
Amazon
DSM
Amazon AWS CloudTrail
RPM name
DSM-AmazonAWSCloudTrail-QRadar_versionBuild_number.noarch.rpm
Supported versions
N/A
Protocol
Amazon AWS S3 REST API
QRadar recorded events
All version 1.0, 1.02, 1.03, and 1.04 events.
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Amazon website (http://docs.aws.amazon.com/
awscloudtrail/latest/userguide/
whatisawscloudtrail.html)
To integrate Amazon AWS CloudTrail with QRadar, complete the following steps:
1. Create an Amazon AWS Identity and Access Management (IAM) user and then apply the
AmazonS3ReadOnlyAccess policy.
2. Install the most recent version of the following RPMs on your QRadar Console.
v Protocol Common
v Amazon AWS REST API Protocol RPM
v Amazon AWS CloudTrail DSM RPM
3. Click the Admin tab.
4. Click the Log Sources icon.
5. From the navigation menu, click Add.
6. Configure the Amazon AWS CloudTrail log source in QRadar.
Restriction:
A log source can retrieve data from only one region. Use a different log source for each region.
Include the region folder name in the file path for the Directory Prefix value when you configure
the log source.
The following table describes the parameters that require specific values to collect audit events from
Amazon AWS CloudTrail:
© Copyright IBM Corp. 2005, 2018
103
Table 54. Amazon AWS CloudTrail log source parameters
Parameter
Description
Log Source Type
Amazon AWS CloudTrail
Protocol Configuration
Amazon AWS S3 REST API
Log Source Identifier
Type a unique name for the log source.
The Log Source Identifier can be any valid value and
does not need to reference a specific server. The Log
Source Identifier can be the same value as the Log
Source Name. If you have more than one Amazon AWS
CloudTrail log source that is configured, you might want
to identify the first log source as awscloudtrail1, the
second log source as awscloudtrail2, and the third log
source as awscloudtrail3.
Signature Version
Select AWSSIGNATUREV2 or AWSSIGNATURE4.
AWSSIGNATUREV2 does not support all Amazon AWS
regions. If you are using a region that supports only
AWSSIGNATUREV4, you must choose
AWSSIGNATUREV4 from the list.
Region Name (Signature V4 only)
The region that is associated with the Amazon S3 bucket.
Bucket Name
The name of the AWS S3 bucket where the log files are
stored.
Endpoint URL
https://s3.amazonaws.com
Authentication Method
Access Key ID / Secret Key
Standard authentication that can be used from
anywhere.
EC2 Instance IAM Role
If your QRadar managed host is running in an
AWS EC2 instance, choosing this option will use
the IAM Role from the instance metadata
assigned to the instance for authentication and
no keys are required. This method will ONLY
work for managed hosts running within an
AWS EC2 container.
Public Key
The public access key that is required to access the AWS
S3 bucket.
Note: This parameter is called Access Key ID in Amazon
AWS Cloudtrail.
Access Key
The private access key that is required to access the AWS
S3 bucket.
Note: This parameter is called Secret Access Key in
Amazon AWS Cloudtrail.
Directory Prefix
The root directory location on the AWS S3 bucket from
which the CloudTrail logs are retrieved, for example,
AWSLogs/<AccountNumber>/CloudTrail/<RegionName>/
File Pattern
The regular expression (regex) used to select files to
process.
The default is .*?\.json\.gz
104
QRadar DSM Configuration Guide
Table 54. Amazon AWS CloudTrail log source parameters (continued)
Parameter
Description
Event Format
Choose the format of the events contained within the
files.
AWS Cloud Trail JSON
Files contain JSON formatted events for Amazon
Cloudtrail (.gz files only).
W3C
For use with Cisco Cloud Web Services DSM
(.gz files only).
LINEBYLINE
Files are raw log files that contain 1 record per
line. Compression with gzip (.gz or .gzip) and
zip (.zip) is supported and autodetected with
the appropriate file extension.
Use Proxy
When a proxy is configured, all traffic for the log source
travels through the proxy for QRadar to access the
Amazon AWS S3 buckets.
Configure the Proxy Server, Proxy Port, Proxy
Username, and Proxy Password fields. If the proxy does
not require authentication, you can leave the Proxy
Username and Proxy Password fields blank.
Automatically Acquire Server Certificate(s)
If you select Yes, QRadar automatically downloads the
server certificate and begins trusting the target server.
This can be used to initialize a newly created log source
and obtain certificates initially, or to replace expired
certificates.
Recurrence
How often the Amazon AWS S3 REST API Protocol
connects to the Amazon cloud API, checks for new files,
and retrieves them if they exist. Every access to an AWS
S3 bucket incurs a cost to the account that owns the
bucket. Therefore, a smaller recurrence value increases
the cost.
Type a time interval to determine how frequently the
remote directory is scanned for new event log files. The
minimum value is 1 minute. The time interval can
include values in hours (H), minutes (M), or days (D).
For example: 2H = 2 hours, 15M = 15 minutes.
7. To verify that QRadar is configured correctly, review the following table to see an example of a parsed
event message.
The following table provides a sample event message for the Amazon AWS CloudTrail DSM:
11 Amazon AWS CloudTrail
105
Table 55. Amazon AWS CloudTrail sample message supported by Amazon AWS CloudTrail.
Event name
Console Login
Low-level
category
General Audit
Event
Sample log message
{"eventVersion":"1.02",
"userIdentity":{"type":"IAMUser",
"principalId":"XXXXXXXXXXXXXXXXXXXXX",
"arn":"arn:aws:iam::<Account_number>:user/
xx.xxccountId":"<Account_number>","userName":
"<Username>"},"eventTime":
"2016-05-04T14:10:58Z","eventSource":
"f.amazonaws.com","eventName":
"ConsoleLogin","awsRegion":
"us-east-1","sourceIPAddress":
"<Source_IP_address> Agent":"Mozilla/5.0
(Windows NT 6.1; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/50.0.1.1 Safari/537.36",
"requestParameters":null,
"responseElements":
{"ConsoleLogin":"Success"},
"additionalEventData":
{"LoginTo":"www.webpage.com",
"MobileVersion":"No","MFAUsed":"No"},
"eventID":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"eventType":"AwsConsoleSignIn",
"recipientAccountId":"<Account_ID>"}
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Enabling communication between IBM Security QRadar and AWS CloudTrail”
A certificate is required for the HTTP connection between QRadar and Amazon AWS CloudTrail.
“Configuring Amazon AWS CloudTrail to communicate with QRadar” on page 109
An Amazon administrator must create a user and then apply the AmazonS3ReadOnlyAccess policy in
the Amazon AWS user interface. The QRadar user can then create a log source in QRadar.
Enabling communication between IBM Security QRadar and AWS
CloudTrail
A certificate is required for the HTTP connection between QRadar and Amazon AWS CloudTrail.
Before you begin
The Automatic Certificate download option is available for the Amazon AWS CloudTrail log source. To
download the certificate automatically, select Yes for the Automatically Acquire Server Certificate(s)
option when you configure the log source.
If you want to download the certificate manually, complete the following steps.
Procedure
1. Access your Amazon AWS CloudTrail S3 bucket.
106
QRadar DSM Configuration Guide
2. Export the certificate as a DER-encoded binary certificate to your desktop system. The file extension
must be .DER.
3. Copy the certificate to the /opt/QRadar/conf/trusted_certificates directory on the QRadar host on
which you plan to configure the log source.
Verifying that Amazon AWS CloudTrail events are received
You can verify that you are collecting event data from the Amazon AWS CloudTrail S3 bucket.
Procedure
1. Log in to QRadar as an administrator.
2. Click the Log Activity tab.
3. Click Add Filter.
4. Select Log Source [Indexed] > Equals and browse for the name of your Amazon AWS CloudTrail log
source.
5. Click Add Filter.
6. From the View menu, select Last 15 minutes or Last Interval.
Results
If the log source parameters are correct, the Amazon AWS CloudTrail should display events retrieved
from the Amazon AWS ecosystem.
Related information:
Amazon AWS CloudTrail documentation (www.amazon.com)
QRadar: Unable to integrate with Amazon AWS CloudTrail (www.ibm.com/support)
QRadar: Troubleshooting Amazon AWS CloudTrail.
Troubleshooting Amazon AWS log source integrations
You configured a log source in QRadar to collect Amazon AWS logs, but the log source status is Warn
and events are not generated as expected.
Symptom:
Error that is shown in /var/log/qradar.error:
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider2
9154] com.q1labs.semsources.sources.amazonawsrest.utils.web.SimpleRESTFileLister:
[ERROR] [NOT:0000003000]
[x.x.x.x/- -] [-/- -]IOException encountered when trying to list files
from remote Amazon S3 bucket.
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider2
9154] javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
Server certificate not recognized
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider2
9154] at com.ibm.jsse2.j.a(j.java:15)
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider2
9154] at com.ibm.jsse2.qc.a(qc.java:728)
Cause:
11 Amazon AWS CloudTrail
107
This error was probably caused by exporting the Amazon SSL certificate from the incorrect URL.
Environment:
All QRadar versions.
Diagnosing the problem:
Verify that the certificate that is on the whitelist does not intersect with the server certificate that is
provided by the connection. The server certificate that is sent by Amazon covers the *.s3.amazonaws.com
domain. The customer must export the certificate for the following URL:
https://<bucketname>.s3.amazonaws.com
The stack trace in QRadar indicates the issue with the Amazon AWS S3 REST API Protocol. In the
following example, QRadar is rejecting an unrecognized certificate. The most common cause is that the
certificate is not in the correct format or is not placed on the proper QRadar appliance and in the proper
directory.
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -]
Rejecting SSL/TLS connection because server presented unrecognized certificate.
The chain sent by the server is
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -] Subject =
CN=*.s3.amazonaws.com, O=Amazon.com Inc., L=Seattle, ST=Washington, C=US
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -] Subject =
CN=q1.us.ibm.com, OU=IBM, O=IBM, L=John, ST=Doe, C=IN, EMAILADDRESS=jdoe@us.ibm.com
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -]The current certificate white list is:
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -]
Subject = EMAILADDRESS=q1sales@us.ibm.com,
O=IBM Corp, L=Waltham, ST=Massachusetts, C=US
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -] Subject = O=SyslogTLS_Server, CN=*
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -]
Subject = CN=s3-console-us-standard.console.aws.amazon.com,
O="Amazon.com, Inc.", L=Seattle, ST=Washington, C=US
[ecs-ec] [Amazon AWS S3 REST API Protocol Provider Thread: class
com.q1labs.semsources.sources.amazonawsrest.AmazonAWSRESTProvider29154]
com.q1labs.frameworks.crypto.Q1X509TrustManager: [WARN]
[NOT:0000004000][x.x.x.x/- -] [-/- -] To establish trust in this server certificate,
place a copy in /opt/qradar/conf/trusted_certificates
Resolving the problem:
108
QRadar DSM Configuration Guide
If you downloaded the certificate automatically when you created the log source, verify the following
steps:
1. You configured the correct Amazon S3 endpoint URL and the correct bucket name.
2. You selected the Yes option for Automatically Acquire server Certificate(s).
3. You saved the log source.
Note: The log source automatically downloads the .DER certificate file to the /opt/qradar/conf/
trusted_certificates directory. To verify that the correct certificate is downloaded and working,
complete the following steps:
1. From the Navigation menu, click Enable/Disable to disable.
2. Enable the Amazon AWS CloudTrail log source.
If you downloaded the certificate manually, you must move the .DER certificate file to the correctQRadar
appliance. The correct QRadar appliance is assigned in the Target Event Collector field in the Amazon
AWS CouldTrail log source.
Note:
The certificate must have a .DER extension. The .DER extension is case-sensitive and must be in uppercase.
If the certificate is exported in lowercase, then the log source might experience event collection issues.
1. Access your AWS CloudTrail S3 bucket at https://<bucketname>.s3.amazonaws.com
2. Use Firefox to export the SSL certificate from AWS as a DER certificate file. Firefox can create the
required certificate with the .DER extension.
3. Copy the DER certificate file to the /opt/qradar/conf/trusted_certificates directory on the QRadar
appliance that manages the Amazon AWS CloudTrail log source.
Note: The QRadar appliance that manages the log source is identified by the Target Event Collect
field in the Amazon AWS CloudTrail log source. The QRadar appliance that manages the Amazon
AWS CloudTrail log source has a copy of the DER certificate file in the /opt/qradar/conf/
trusted_certificates folder.
4. Log in to QRadar as an administrator.
5. Click the Admin tab.
6. Click the Log Sources icon.
7. Select the Amazon AWS CloudTrail log source.
8. From the navigation menu, click Enable/Disable to disable, then re-enable the Amazon AWS
CloudTrail log source.
Note: Forcing the log source from disabled to enabled connects the protocol to the Amazon AWS
bucket as defined in the log source. A certificate check takes place as part of the first communication.
9. If you continue to have issues, verify that the Amazon AWS bucket name in the Log Source Identifier
field is correct. Ensure that the Remote Directory path is correct in the log source configuration.
Configuring Amazon AWS CloudTrail to communicate with QRadar
An Amazon administrator must create a user and then apply the AmazonS3ReadOnlyAccess policy in
the Amazon AWS user interface. The QRadar user can then create a log source in QRadar.
Note: Alternatively, instead of using the AmazonS3ReadOnlyAccess permission you can assign more
granular permissions to the bucket. The minimum required permissions are s3:listBucket and
s3:getObject.
11 Amazon AWS CloudTrail
109
For more information about permissions related to bucket operations, go to the AWS documentation
website (https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html#using-with-s3actions-related-to-buckets).
Procedure
1. Create a user:
a. Log in to the Amazon AWS user interface as administrator.
b. Create an Amazon AWS IAM user and then apply the AmazonS3ReadOnlyAccess policy.
2. Find the S3 bucket name and directory prefix that you use to configure a log source in QRadar:
a. Click Services.
b. From the list, select CloudTrail.
c. From the Trails page, click the name of the trail.
d. Note the name of the S3 bucket that is displayed in the S3 bucket field.
e. Click the pencil icon on the right side of the window.
f. Click Advanced >>.
g. Note the location path for the S3 bucket that is displayed below the Log file prefix field.
What to do next
The QRadar user is ready to configure the log source in QRadar. The S3 bucket name is the value for the
Bucket name field. The location path for the S3 bucket is the value for Directory prefix field.
110
QRadar DSM Configuration Guide
12 Ambiron TrustWave ipAngel
The IBM Security QRadar DSM for Ambiron TrustWave ipAngel receives Snort-based events from the
ipAngel console.
The following table identifies the specifications for the Ambiron TrustWave ipAngel DSM:
Table 56. Ambiron TrustWave ipAngel DSM specifications
Specification
Value
Manufacturer
Ambiron
DSM name
Ambiron TrustWave ipAngel
RPM file name
DSM-AmbironTrustwaveIpAngel-QRadar_versionbuild_number.noarch.rpm
Supported versions
V4.0
Protocol
Syslog
Recorded event types
Snort-based events
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Ambiron website (http://www.apache.org)
To send Ambiron TrustWave ipAngel events to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the Ambiron
TrustWave ipAngel DSM RPM on your QRadar Console.
2. Configure your Ambiron TrustWave ipAngel device to forward your cache and access logs to QRadar.
For information on forwarding device logs to QRadar, see your vendor documentation.
3. Add an Ambiron TrustWave ipAngel log source on the QRadar Console. The following table describes
the parameters that require specific values that are required for Ambiron TrustWave ipAngel event
collection:
Table 57. Ambiron TrustWave ipAngel log source parameters
Parameter
Value
Log Source type
Ambiron TrustWave ipAngel Intrusion Prevention
System (IPS)
Protocol Configuration
Syslog
© Copyright IBM Corp. 2005, 2018
111
112
QRadar DSM Configuration Guide
13 APC UPS
The IBM Security QRadar DSM for APC UPS accepts syslog events from the APC Smart-Uninterruptible
Power Supply (UPS) family of products.
Restriction: Events from RC-Series Smart-UPS are not supported.
The following table identifies the specifications for the APC UPS DSM:
Table 58. APC UPS DSM specifications
Specification
Value
Manufacturer
APC
DSM name
APC UPS
RPM file name
DSM-APCUPS-Qradar_version-build_number.noarch.rpm
Protocol
Syslog
Recorded event types
UPS events
Battery events
Bypass events
Communication events
Input power events
Low battery condition events
SmartBoost events
SmartTrim events
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
APC website (http://www.apc.com)
To send APC UPS events to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the APC UPS
DSM RPM on your QRadar Console.
2. Create an APC UPS log source on the QRadar Console. Configure all the required parameters, and
use the following table to configure the specific values that are requiredto collect APC UPS events:
Table 59. APC UPS log source parameters
Parameter
Value
Log Source type
APC UPS
Protocol Configuration
Syslog
3. Configure your APC UPS device to forward syslog events to QRadar.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
© Copyright IBM Corp. 2005, 2018
113
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Configuring your APC UPS to forward syslog events”
To collect events from your APC UPS, you must configure the device to forward syslog events to IBM
Security QRadar.
Configuring your APC UPS to forward syslog events
To collect events from your APC UPS, you must configure the device to forward syslog events to IBM
Security QRadar.
Procedure
1. Log in to the APC Smart-UPS web interface.
2. In the navigation menu, click Network > Syslog.
3. From the Syslog list, select Enable.
4. From the Facility list, select a facility level for your syslog messages.
5. In the Syslog Server field, type the IP address of your QRadar Console or Event Collector.
6. From the Severity list, select Informational.
7. Click Apply.
114
QRadar DSM Configuration Guide
14 Apache HTTP Server
The Apache HTTP Server DSM for IBM Security QRadar accepts Apache events by using syslog or
syslog-ng.
QRadar records all relevant HTTP status events. The following procedure applies to Apache DSMs
operating on UNIX/Linux operating systems only.
Do not run both syslog and syslog-ng at the same time.
Select one of the following configuration methods:
v “Configuring Apache HTTP Server with syslog”
v “Configuring Apache HTTP Server with syslog-ng” on page 116
Configuring Apache HTTP Server with syslog
You can configure your Apache HTTP Server to forward events with the syslog protocol.
Procedure
1. Log in to the server that hosts Apache, as the root user.
2. Edit the Apache configuration file httpd.conf.
3. Add the following information in the Apache configuration file to specify the custom log format:
LogFormat "%h %A %l %u %t \"%r\" %>s %p %b" <log format name>
Where <log format name> is a variable name you provide to define the log format.
4. Add the following information in the Apache configuration file to specify a custom path for the
syslog events:
CustomLog "|/usr/bin/logger -t httpd -p <facility>.<priority>" <log format name>
Where:
v <facility> is a syslog facility, for example, local0.
v <priority> is a syslog priority, for example, info or notice.
v <log format name> is a variable name that you provide to define the custom log format. The log
format name must match the log format that is defined in “Configuring Apache HTTP Server with
syslog.”
For example,
CustomLog "|/usr/bin/logger -t httpd -p local1.info" MyApacheLogs
5. Type the following command to disable hostname lookup:
HostnameLookups off
6. Save the Apache configuration file.
7. Edit the syslog configuration file.
/etc/syslog.conf
8. Add the following information to your syslog configuration file:
<facility>.<priority> <TAB><TAB>@<host>
Where:
v <facility> is the syslog facility, for example, local0. This value must match the value that you typed
in “Configuring Apache HTTP Server with syslog”.
© Copyright IBM Corp. 2005, 2018
115
v <priority> is the syslog priority, for example, info or notice. This value must match the value that
you typed in “Configuring Apache HTTP Server with syslog” on page 115.
v <TAB> indicates you must press the Tab key.
v <host> is the IP address of the QRadar Console or Event Collector.
9. Save the syslog configuration file.
10. Type the following command to restart the syslog service:
/etc/init.d/syslog restart
11. Restart Apache to complete the syslog configuration.
The configuration is complete. The log source is added to QRadar as syslog events from Apache
HTTP Servers are automatically discovered. Events that are forwarded to QRadar by Apache HTTP
Servers are displayed on the Log Activity tab of QRadar.
Configuring a Log Source in IBM Security QRadar
You can configure a log source manually for Apache HTTP Server events in IBM Security QRadar.
About this task
QRadar automatically discovers and creates a log source for syslog events from Apache HTTP Server.
However, you can manually create a log source for QRadar to receive syslog events. These configuration
steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Apache HTTP Server.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 60. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Apache installations.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete. For more information about Apache, see http://www.apache.org/.
Configuring Apache HTTP Server with syslog-ng
You can configure your Apache HTTP Server to forward events with the syslog-ng protocol.
Procedure
1. Log in to the server that hosts Apache, as the root user.
2. Edit the Apache configuration file.
116
QRadar DSM Configuration Guide
/etc/httpd/conf/httpd.conf
3. Add the following information to the Apache configuration file to specify the LogLevel:
LogLevel info
The LogLevel might already be configured to the info level; it depends on your Apache installation.
4. Add the following to the Apache configuration file to specify the custom log format:
LogFormat "%h %A %l %u %t \"%r\" %>s %p %b" <log format name>
Where <log format name> is a variable name you provide to define the custom log format.
5. Add the following information to the Apache configuration file to specify a custom path for the
syslog events:
CustomLog "|/usr/bin/logger -t ’httpd’ -u /var/log/httpd/apache_log.socket" <log format
name>
The log format name must match the log format that is defined in “Configuring Apache HTTP
Server with syslog-ng” on page 116.
6. Save the Apache configuration file.
7. Edit the syslog-ng configuration file.
/etc/syslog-ng/syslog-ng.conf
8. Add the following information to specify the destination in the syslog-ng configuration file:
source s_apache {
unix-stream("/var/log/httpd/apache_log.socket"
max-connections(512)
keep-alive(yes));
};
destination auth_destination { <udp|tcp> ("<IP address>" port(514)); };
log{
source(s_apache);
destination(auth_destination);
};
Where:
<IP address> is the IP address of the QRadar Console or Event Collector.
<udp|tcp> is the protocol that you select to forward the syslog event.
9. Save the syslog-ng configuration file.
10. Type the following command to restart syslog-ng:
service syslog-ng restart
11. You can now configure the log source in QRadar.
The configuration is complete. The log source is added to QRadar as syslog events from Apache
HTTP Servers are automatically discovered. Events that are forwarded to QRadar by Apache HTTP
Servers are displayed on the Log Activity tab of QRadar.
Configuring a log source
You can configure a log source manually for Apache HTTP Server events in IBM Security QRadar.
About this task
QRadar automatically discovers and creates a log source for syslog-ng events from Apache HTTP Server.
However, you can manually create a log source for QRadar to receive syslog events. These configuration
steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
14 Apache HTTP Server
117
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Apache HTTP Server.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 61. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Apache installations.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete. For more information about Apache, see http://www.apache.org/.
118
QRadar DSM Configuration Guide
15 Apple Mac OS X
The IBM Security QRadar DSM for Apple Mac OS X accepts events by using syslog.
QRadar records all relevant firewall, web server access, web server error, privilege escalation, and
informational events.
To integrate Mac OS X events with QRadar, you must manually create a log source to receive syslog
events.
To complete this integration, you must configure a log source, then configure your Mac OS X to forward
syslog events. Syslog events that are forwarded from Mac OS X devices are not automatically discovered.
Syslog events from Mac OS X can be forwarded to QRadar on TCP port 514 or UDP port 514.
Configuring a Mac OS X log source
IBM Security QRadar does not automatically discover or create log sources for syslog events from Apple
Mac OS X.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Mac OS X.
9. From the Protocol Configuration list, select Syslog.
10. In the Log Source Identifier field, type the IP address or host name for the log source as an
identifier for events from your Apple Mac OS X device.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. You are now ready to configure your Apple Mac OS X device to
forward syslog events to QRadar.
Configuring syslog on your Apple Mac OS X
You can configure syslog on systems that run Mac OS X operating systems.
Procedure
1. Using SSH, log in to your Mac OS X device as a root user.
2. Open the /etc/syslog.conf file.
3. Add the following line to the top of the file. Make sure that all other lines remain intact:
*.* @QRadar_IP_address
4. Save and exit the file.
5. Send a hang-up signal to the syslog daemon to make sure that all changes are enforced:
sudo killall - HUP syslogd
© Copyright IBM Corp. 2005, 2018
119
The syslog configuration is complete. Events that are forwarded to IBM Security QRadar by your
Apple Mac OS X are displayed on the Log Activity tab.
For more information about Mac OS X configurations, see your Mac OS X vendor documentation.
120
QRadar DSM Configuration Guide
16 Application Security DbProtect
The IBM Security QRadar DSM for Application Security DbProtect collects event from DbProtect devices
that are installed with the Log Enhanced Event Format (LEEF) Service.
The following table identifies the specifications for the Application Security DbProtect DSM:
Table 62. Application Security DbProtect DSM specifications
Specification
Value
Manufacturer
Application Security, Inc
DSM name
DbProtect
RPM file name
DSM-AppSecDbProtect-QRadar_versionbuild_number.noarch.rpm
Supported versions
v6.2
v6.3
v6.3sp1
v6.3.1
v6.4
Protocol
LEEF
Recorded event types
All events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Application Security website (http://
www.appsecinc.com/)
To send Application Security DbProtect events to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the Application
Security DbProtect DSM RPM on your QRadar Console:
2. Configure your Application Security DbProtect device to communicate with QRadar. Complete the
following steps:
a. Install the DbProtect LEEF Relay Module.
b. Configure the DbProtect LEEF Relay
c. Configure DbProtect alerts.
3. If QRadar does not automatically detect the log source, add an Application Security DbProtect log
source on the QRadar Console. Configure all required parameters, and use the following table for
DbProtect-specific values:
Table 63. Application Security DbProtect log source parameters
Parameter
Value
Log Source type
Application Security DbProtect
Protocol Configuration
Syslog
© Copyright IBM Corp. 2005, 2018
121
Installing the DbProtect LEEF Relay Module
To enable DbProtect to communicate with IBM Security QRadar, install the DbProtect LEEF Relay module
on the same server as the DbProtect console.
Before you begin
Before you install the DbProtect LEEF Relay module on a Windows 2003 host, you must install Windows
Imaging Components. The wic_x86.exe file contains the Windows Imaging Components and is on the
Windows Server Installation CD. For more information, see your Windows 2003 Operating System
documentation.
About this task
The LEEF Relay module for DbProtect translates the default events messages to Log Enhanced Event
Format (LEEF) messages for QRadar. Before you can receive events in QRadar, you must install and
configure the LEEF Service for your DbProtect device to forward syslog events. The DbProtect LEEF
Relay requires that you install the .NET 4.0 Framework, which is bundled with the LEEF Relay
installation.
Procedure
1. Download the DbProtect LEEF Relay module for DbProtect from the Application Security, Inc.
customer portal (http://www.appsecinc.com).
2. Save the setup file to the same host as your DbProtect console.
3. Click Accept to agree with the Microsoft .NET Framework 4 End-User License Agreement.
In the DbProtect LEEF Relay module installation Wizard, click Next.
4.
5. To select the default installation path, click Next.
If you change the default installation directory, make note of the file location.
6. On the Confirm Installation window, click Next.
7. Click Close.
What to do next
“Configuring the DbProtect LEEF Relay”
Configuring the DbProtect LEEF Relay
After you install the DbProtect LEEF Relay module, configure the service to forward events to IBM
Security QRadar.
Before you begin
Stop the DbProtect LEEF Relay service before you edit any configuration values.
Procedure
1. Log in to the DbProtect LEEF Relay server.
2. Access the C:\Program Files (x86)\AppSecInc\AppSecLEEFConverter directory.
3. Edit the AppSecLEEFConverter.exe.config file. Configure the following values:
Parameter
Description
SyslogListenerPort
The port number that the DbProtect LEEF Relay uses to listen for syslog
messages from the DbProtect console.
122
QRadar DSM Configuration Guide
Parameter
Description
SyslogDestinationHost
The IP address of your QRadar Console or Event Collector.
SyslogDestinationPort
514
LogFileName
A file name for the DbProtect LEEF Relay to write debug and log messages.
The LocalSystem user account that runs the DbProtect LEEF Relay service
must have write privileges to the file path that you specify.
4. Save the configuration changes to the file.
5. On the desktop of the DbProtect console, select Start > Run.
6. Type the following command:
services.msc
7. Click OK.
8. In the details pane of the Services window, verify the DbProtect LEEF Relay is started and set to
automatic startup.
9. To change a service property, right-click the service name, and then click Properties.
10. Using the Startup type list, select Automatic.
11. If the DbProtect LEEF Relay is not started, click Start.
What to do next
“Configuring DbProtect alerts”
Configuring DbProtect alerts
Configure sensors on your DbProtect console to generate alerts.
Procedure
1. Log in to the DbProtect console.
2. Click the Activity Monitoring tab.
3. Click the Sensors tab.
4. Select a sensor and click Reconfigure.
5. Select a database instance and click Reconfigure.
6. Click Next until the Sensor Manager Policy window is displayed.
7. Select the Syslog check box and click Next.
8. In the Send Alerts to the following Syslog console field, type the IP address of your DbProtect
console.
9. In the Port field, type the port number that you configured in the SyslogListenerPort field of the
DbProtect LEEF Relay.
Tip: By default, 514 is the default Syslog listen port for the DbProtect LEEF Relay.
10. Click Add.
11. Click Next until you reach the Deploy to Sensor window.
12. Click Deploy to Sensor.
16 Application Security DbProtect
123
124
QRadar DSM Configuration Guide
17 Arbor Networks
Several Arbor Networks DSMs can be integrated with IBM Security QRadar.
This section provides information on the following DSMs:
v “Arbor Networks Peakflow SP”
v “Arbor Networks Pravail” on page 129
Arbor Networks Peakflow SP
IBM Security QRadar can collect and categorize syslog and TLS syslog events from Arbor Networks
Peakflow SP appliances that are in your network.
Arbor Networks Peakflow SP appliances store the syslog events locally.
To collect local syslog events, you must configure your Peakflow SP appliance to forward the syslog
events to a remote host. QRadar automatically discovers and creates log sources for syslog events that are
forwarded from Arbor Networks Peakflow SP appliances. QRadar supports syslog events that are
forwarded from Peakflow V5.8 to V8.1.2.
To configure Arbor Networks Peakflow SP, complete the following steps:
1. On your Peakflow SP appliance, create a notification group for QRadar.
2. On your Peakflow SP appliance, configure the global notification settings.
3. On your Peakflow SP appliance, configure your alert notification rules.
4. If automatic updates are not enabled for QRadar, RPMs are available for download from the IBM
support website (http://www.ibm.com/support). Download and install the most recent version of the
following RPMs on your QRadar Console.
v DSMCommon RPM
v Arbor Networks Peakflow SP DSM RPM
5. Configure your Arbor Networks Peakflow SP appliance to send syslog or TLS syslog events to
QRadar.
6. If QRadar does not automatically detect the log source, add an Arbor Networks Peakflow SP log
source on the QRadar Console. The following tables describe the parameters that require specific
values to collect events from Arbor Networks Peakflow SP:
Table 64. Arbor Networks Peakflow SP log source parameters
Parameter
Value
Log Source type
Arbor Networks Peakflow SP
Protocol Configuration
Select Syslog or TLS Syslog
Log Source Identifier
Type a unique name for the log source.
Related concepts:
“TLS syslog protocol configuration options” on page 48
Configure a TLS Syslog protocol log source to receive encrypted syslog events from up to 1000 network
devices that support TLS Syslog event forwarding.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
© Copyright IBM Corp. 2005, 2018
125
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Supported event types for Arbor Networks Peakflow SP
The Arbor Networks Peakflow DSM for IBM Security QRadar collects events from several categories.
Each event category contains low-level events that describe the action that is taken within the event
category. For example, authentication events can have low-level categories of login successful or login
failure.
The following list defines the event categories that are collected by QRadar from Peakflow SP appliances:
v Denial of Service (DoS) events
v Authentication events
v Exploit events
v Suspicious activity events
v System events
Configuring a remote syslog in Arbor Networks Peakflow SP
To collect events, you must configure a new notification group or edit existing groups to add IBM
Security QRadar as a remote syslog destination.
Procedure
1. Log in to your Peakflow SP configuration interface as an administrator.
2. In the navigation menu, select Administration > Notification > Groups.
3. Click Add Notification Group.
4. In the Destinations field, type the IP address of your QRadar system.
5. In the Port field, type 514 as the port for your syslog destination.
6. From the Facility list, select a syslog facility.
7. From the Severity list, select info.
The informational severity collects all event messages at the informational event level and higher
severity.
8. Click Save.
9. Click Configuration Commit.
Configuring global notifications settings for alerts in Arbor Networks
Peakflow SP
Global notifications in Arbor Networks Peakflow SP provide system notifications that are not associated
with rules.
About this task
This procedure defines how to add IBM Security QRadar as the default notification group and enable
system notifications.
Procedure
1. Log in to the configuration interface for your Arbor Networks Peakflow SP appliance as an
administrator.
2. In the navigation menu, select Administration > Notification > Global Settings .
126
QRadar DSM Configuration Guide
3. In the Default Notification Group field, select the notification group that you created for QRadar
syslog events.
4. Click Save.
5. Click Configuration Commit to apply the configuration changes.
6. Log in to the Arbor Networks Peakflow SP command-line interface as an administrator.
7. Type the following command to list the current alert configuration:
services sp alerts system_errors show
8. Optional: Type the following command to list the fields names that can be configured:
services sp alerts system_errors ?
9. Type the following command to enable a notification for a system alert:
services sp alerts system_errors <name> notifications enable
Where <name> is the field name of the notification.
10. Type the following command to commit the configuration changes:
config write
Configuring alert notification rules in Arbor Networks Peakflow SP
To generate events, you must edit or add rules to use the notification group that IBM Security QRadar
uses as a remote syslog destination.
Procedure
1. Log in to your Arbor Networks Peakflow SP configuration interface as an administrator.
2. In the navigation menu, select Administration > Notification > Rules.
3. Select one of the following options:
v Click a current rule to edit the rule.
v Click Add Rule to create a new notification rule.
4. Configure the following values:
Table 65. Arbor Networks Peakflow SP notification rule parameters
Parameter
Description
Name
Type the IP address or host name as an identifier for
events from your Peakflow SP installation.
The log source identifier must be a unique value.
Resource
Type a CIDR address or select a managed object from the
list of Peakflow resources.
Importance
Select the Importance of the rule.
Notification Group
Select the Notification Group that you assigned to
forward syslog events to QRadar.
5. Repeat these steps to configure any other rules that you want to create.
6. Click Save.
7. Click Configuration Commit to apply the configuration changes.
QRadar automatically discovers and creates a log source for Arbor Networks Peakflow SP appliances.
Events that are forwarded to QRadar are displayed on the Log Activity tab.
Configuring an Arbor Networks Peakflow SP log source
IBM Security QRadar automatically discovers and creates a log source for syslog events that are
forwarded from Arbor Networks Peakflow SP. The following configuration steps to manually add the log
source are optional.
17 Arbor Networks
127
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. Optional: In the Log Source Description field, type a description for your log source.
8. From the Log Source Type list, select Arbor Networks Peakflow.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 66. System parameters
Parameter
Description
Log Source Identifier
The IP address or host name is used as an identifier for
events from your Peakflow SP installation.
The log source identifier must be a unique value.
Credibility
The credibility of the log source. The credibility indicates
the integrity of an event or offense as determined by the
credibility rating from the source devices. Credibility
increases if multiple sources report the same event.
Target Event Collector
The event collector to use as the target for the log source.
Coalescing Events
Enables the log source to coalesce (bundle) events. By
default, automatically discovered log sources inherit the
value of the Coalescing Events list from the System
Settings in QRadar. When you create a log source or edit
an existing configuration, you can override the default
value by configuring this option for each log source.
Incoming Event Payload
The incoming payload encoder for parsing and storing
the logs.
Store Event Payload
Enables the log source to store event payload
information.
By default, automatically discovered log sources inherit
the value of the Store Event Payload list from the
System Settings in QRadar. When you create a log source
or edit an existing configuration, you can override the
default value by configuring this option for each log
source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
128
QRadar DSM Configuration Guide
Arbor Networks Pravail
The IBM Security QRadar DSM for Arbor Networks Pravail receives event logs from your Arbor
Networks Pravail servers.
The following table identifies the specifications for the Arbor Networks Pravail DSM:
Table 67. Arbor Networks Pravail DSM specifications
Specification
Value
Manufacturer
Arbor Networks
DSM
Arbor Networks Pravail
RPM file name
DSM-ArborNetworksPravail-build_number.noarch.rpm
Protocol
Syslog
Recorded events
All relevant events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Arbor Networks website (www.arbornetworks.com)
To send Arbor Networks Pravail events to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent Arbor Networks Pravail
RPM on your QRadar Console.
2. Configure each Arbor Networks Pravail system to send events to QRadar.
3. If QRadar does not automatically discover the Arbor Pravail system, create a log source on the
QRadar Console. Configure the required parameters, and use the following table for the Arbor Pravail
specific parameters:
Table 68. Arbor Pravail parameters
Parameter
Value
Log Source Type
Arbor Networks Pravail
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring your Arbor Networks Pravail system to send events to IBM Security QRadar”
To collect all audit logs and system events from Arbor Networks Pravail, you must add a destination that
specifies QRadar as the syslog server.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring your Arbor Networks Pravail system to send events to
IBM Security QRadar
To collect all audit logs and system events from Arbor Networks Pravail, you must add a destination that
specifies QRadar as the syslog server.
17 Arbor Networks
129
Procedure
1. Log in to your Arbor Networks Pravail server.
2. Click Settings & Reports.
3. Click Administration > Notifications.
4. On the Configure Notifications page, click Add Destinations.
5. Select Syslog.
6. Configure the following parameters:
Table 69. Syslog parameters
Parameter
Description
Host
The IP address of the QRadar Console
Port
514
Severity
Info
Alert Types
The alert types that you want to send to the QRadar
Console
7. Click Save.
130
QRadar DSM Configuration Guide
18 Arpeggio SIFT-IT
The IBM Security QRadar SIFT-IT DSM accepts syslog events from Arpeggio SIFT-IT running on IBM i
that are formatted as Log Event Extended Format (LEEF).
QRadar supports events from Arpeggio SIFT-IT 3.1 and later installed on IBM i version 5 revision 3
(V5R3) and later.
Arpeggio SIFT-IT supports syslog events from the journal QAUDJRN in LEEF format.
Example:
Jan 29 01:33:34 <Server> LEEF:1.0|Arpeggio|SIFT-IT|3.1|PW_U|sev=3 usrName=<Username>
src=<Source_IP_address> srcPort=543 jJobNam=QBASE jJobUsr=<Username> jJobNum=1664
jrmtIP=<SourceIP_address> jrmtPort=543 jSeqNo=4755 jPgm=QWTMCMNL jPgmLib=QSYS jMsgId=PWU0000
jType=U jUser=ROOT jDev=QPADEV000F jMsgTxt=Invalid user id <Username>. Device <Device_ID>.
Events that SIFT-IT sends to QRadar are determined with a configuration rule set file. SIFT-IT includes a
default configuration rule set file that you can edit to meet your security or auditing requirements. For
more information about configuring rule set files, see your SIFT-IT User Guide.
Configuring a SIFT-IT agent
Arpeggio SIFT-IT can forward syslog events in LEEF format with SIFT-IT agents.
About this task
A SIFT-IT agent configuration defines the location of your IBM Security QRadar installation, the protocol
and formatting of the event message, and the configuration rule set.
Procedure
1. Log in to your IBM i.
2. Type the following command and press Enter to add SIFT-IT to your library list:
ADDLIBLE SIFTITLIB0
3. Type the following command and press Enter to access the SIFT-IT main menu:
GO SIFTIT
4. From the main menu, select 1. Work with SIFT-IT Agent Definitions.
5. Type 1 to add an agent definition for QRadar and press Enter.
6. In the SIFT-IT Agent Name field, type a name.
For example, QRadar.
7. In the Description field, type a description for the agent.
For example, Arpeggio agent for QRadar.
8. In the Server host name or IP address field, type the location of your QRadar Console or Event
Collector.
9. In the Connection type field, type either *TCP, *UDP, or *SECURE.
The *SECURE option requires the TLS protocol.
10. In the Remote port number field, type 514.
By default, QRadar supports both TCP and UDP syslog messages on port 514.
© Copyright IBM Corp. 2005, 2018
131
11. In the Message format options field, type *QRadar.
12. Optional: Configure any additional parameters for attributes that are not QRadar specific.
The additional operational parameters are described in the SIFT-IT User Guide.
13. Press F3 to exit to the Work with SIFT-IT Agents Description menu.
14. Type 9 and press Enter to load a configuration rule set for QRadar.
15. In the Configuration file field, type the path to your QRadar configuration rule set file.
Example: /sifitit/Qradarconfig.txt
16. Press F3 to exit to the Work with SIFT-IT Agents Description menu.
17. Type 11 to start the QRadar agent.
What to do next
Syslog events that are forwarded by Arpeggio SIFT-IT in LEEF format are automatically discovered by
QRadar. In most cases, the log source is automatically created in QRadar after a few events are detected.
If the event rate is low, you might be required to manually create a log source for Arpeggio SIFT-IT in
QRadar.
Until the log source is automatically discovered and identified, the event type displays as Unknown on
the Log Activity tab of QRadar. Automatically discovered log sources can be viewed on the Admin tab of
QRadar by clicking the Log Sources icon.
Related concepts:
“TLS syslog protocol configuration options” on page 48
Configure a TLS Syslog protocol log source to receive encrypted syslog events from up to 1000 network
devices that support TLS Syslog event forwarding.
Configuring a Arpeggio SIFT-IT log source
IBM Security QRadar automatically discovers and creates a log source for system authentication events
forwarded from Arpeggio SIFT-IT.
About this task
This procedure is optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Arpeggio SIFT-IT.
9. From the Protocol Configuration list, select Syslog.
10. In the Log Source Identifier field, type the IP address or host name for the log source as an
identifier for events from your Arpeggio SIFT-IT installation.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
132
QRadar DSM Configuration Guide
Additional information
After you create your IBM Security QRadar agent definition, you can use your Arpeggio SIFT-IT software
and QRadar integration to customize your security and auditing requirements.
You can customize the following security and auditing requirements:
v Create custom configurations in Arpeggio SIFT-IT with granular filtering on event attributes.
For example, filtering on job name, user, file or object name, system objects, or ports. All events that
are forwarded from SIFT-IT and the contents of the event payload in QRadar are easily searched.
v Configure rules in QRadar to generate alerts or offenses for your security team to identify potential
security threats, data loss, or breaches in real time.
v Configuring processes in Arpeggio SIFT-IT to trigger real-time remediation of issues on your IBM i.
v Creating offenses for your security team from Arpeggio SIFT-IT events in QRadar with the Offenses
tab or configuring email job logs in SIFT-IT for your IBM i administrators.
v Creating multiple configuration rule sets for multiple agents that run simultaneously to handle specific
security or audit events.
For example, you can configure one QRadar agent with a specific rule set for forwarding all IBM i events,
then develop multiple configuration rule sets for specific compliance purposes. You can easily manage
configuration rule sets for compliance regulations, such as FISMA, PCI. HIPPA, SOX, or ISO 27001. All of
the events that are forwarded by SIFT-IT QRadar agents are contained in a single log source and
categorized to be easily searched.
18 Arpeggio SIFT-IT
133
134
QRadar DSM Configuration Guide
19 Array Networks SSL VPN
The Array Networks SSL VPN DSM for IBM Security QRadar collects events from an ArrayVPN
appliance by using syslog.
QRadar records all relevant SSL VPN events that are forwarded by using syslog on TCP port 514 or UDP
port 514.
Configuring a log source
To send Array Networks SSL VPN events to IBM Security QRadar, you must manually create a log
source.
About this task
QRadar does not automatically discover or create log sources for syslog events from Array Networks SSL
VPN.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Array Networks SSL VPN Access Gateways.
9. From the Protocol Configuration list, select Syslog.
10. In the Log Source Identifier field, type the IP address or host name for the log source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
What to do next
You are now ready to configure your Array Networks SSL VPN appliance to forward remote syslog
events to QRadar. For more information on configuring Array Networks SSL VPN appliances, see your
Array Networks documentation.
© Copyright IBM Corp. 2005, 2018
135
136
QRadar DSM Configuration Guide
20 Aruba Networks
Several Aruba DSMs can be integrated with IBM Security QRadar.
This section provides information on the following DSMs:
v “Aruba ClearPass Policy Manager”
v “Aruba Mobility Controllers” on page 141
Aruba ClearPass Policy Manager
The IBM Security QRadar DSM for Aruba ClearPass Policy Manager can collect event logs from your
Aruba ClearPass Policy Manager servers.
The following table identifies the specifications for the Aruba ClearPass Policy Manager DSM:
Table 70. Aruba ClearPass Policy Manager DSM specifications
Specification
Value
Manufacturer
Aruba Networks
DSM name
ClearPass
RPM file name
DSM-ArubaClearPass-Qradar_versionbuild_number.noarch.rpm
Supported versions
6.5.0.71095 and later
Event format
LEEF
Recorded event types
Session
Audit
System
Insight
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
Aruba Networks website (http://
www.arubanetworks.com/products/security/)
To integrate Aruba ClearPass Policy Manager with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Aruba ClearPass DSM RPM
v DSMCommon RPM
2. Configure your Aruba ClearPass Policy Manager device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add an Aruba ClearPass log source on the
QRadar Console. The following table describes the parameters that require specific values for Aruba
ClearPass Policy Manager event collection:
© Copyright IBM Corp. 2005, 2018
137
Table 71. Aruba ClearPass Policy Manager log source parameters
Parameter
Value
Log Source type
Aruba ClearPass Policy Manager
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Aruba ClearPass Policy Manager to communicate with
QRadar
To collect syslog events from Aruba ClearPass Policy Manager, you must add an external syslog server
for the QRadar host. You will then need to create one or more syslog filters for your syslog server.
Before you begin
For Session and Insight events, full event parsing works only for the default fields that are provided by
Aruba ClearPass Policy Manager. Session and Insight events that are created by a user, and have different
combinations of fields, might appear as Unknown Session Log, or Unknown Insight Log.
Procedure
1. Log in to your Aruba ClearPass Policy Manager server.
2. Start the Administration Console.
3. Click External Servers > Syslog Targets.
4. Click Add, and then configure the details for the QRadar host.
5. On the Administration Console, click External Servers > Syslog Export Filters
6. Click Add.
7. Select LEEF for the Export Event Format Type, and then select the Syslog Server that you added.
8. Click Save.
Aruba Introspect
The IBM Security QRadar DSM for Aruba Introspect collects events from an Aruba Introspect device.
The following table describes the specifications for the Aruba Introspect DSM:
Table 72. Aruba Introspect DSM specifications
Specification
Value
Manufacturer
Aruba
DSM name
Aruba Introspect
RPM file name
DSM-ArubaIntrospect-QRadar_versionbuild_number.noarch.rpm
Supported versions
1.6
Protocol
Syslog
Event format
Name-value pair (NVP)
138
QRadar DSM Configuration Guide
Table 72. Aruba Introspect DSM specifications (continued)
Specification
Value
Recorded event types
Security
System
Internal Activity
Exfiltration
Infection
Command & Control
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Aruba website (https://www.arubanetworks.com)
To integrate Aruba Introspect with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs, in the order that they are listed, on your QRadar Console:
v DSMCommon RPM
v ArubaIntrospect DSM RPM
2. Configure your Aruba Introspect device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add an Aruba Introspect log source on the
QRadar Console. The following table describes the parameters that require specific values for Aruba
Introspect event collection:
Table 73. Aruba Introspect log source parameters
Parameter
Value
Log Source type
Aruba Introspect
Protocol Configuration
Syslog
Log Source Identifier
A unique identifier for the log source.
4. To verify that QRadar is configured correctly, review the following table to see an example of a parsed
event message.
The following table shows a sample event message for Aruba Introspect
20 Aruba Networks
139
Table 74. Aruba Introspect sample event message
Event name
Low level category
Sample log message
Cloud Exfiltration
Suspicious Activity
May 6 20:04:38 <Server>
May 7 03:04:38 lab-an-node
msg_type=alert detection_time=
"2016-05-06 20:04:23 -07:00"
alert_name="Large DropBox
Upload" alert_type="Cloud
Exfiltration" alert_category=
"Network Access" alert_severity=60
alert_confidence=20 attack_stage
=Exfiltration user_name=<Username>
src_host_name=example.com
src_ip=<Source_IP_address>
dest_ip=Destination_IP_address1>,
<Destination_IP_address2>,...
description="User <Username>
on host example.com uploaded
324.678654 MB to Dropbox on
May 05, 2016; compared with
users in the whole Enterprise
who uploaded an average of
22.851 KB during the same day"
alert_id=xxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxx_xxxxxxxx
xxxxxxxx_Large_DropBox_Upload
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Aruba Introspect to communicate with QRadar
Before IBM Security QRadar can collect events from Aruba Introspect, you must configure Aruba
Introspect to send events to QRadar.
Procedure
1. Log in to the Aruba Introspect Analyzer.
2. Configure forwarding.
a. Click System Configuration > Syslog Destinations.
b. Configure the following forwarding parameters:
Table 75. Aruba Introspect Analyzer forwarding parameters
Parameter
Value
Syslog Destination
IP or host name of the QRadar Event Collector.
Protocol
TCP or UDP
Port
514
3. Configure notification.
a. Click System Configuration > Security Alerts / Emails > Add New.
b. Configure the following notification parameters:
140
QRadar DSM Configuration Guide
Table 76. Aruba Introspect Analyzer notification parameters
Parameter
Value
Enable Alert Syslog Forwarding
Enable the Enable Alert Syslog Forwarding check box.
Sending Notification
As Alerts are produced.
You can customize this setting to send in batches instead
of a live stream.
TimeZone
Your local time zone.
Note: Leave Query, Severity, and Confidence values as default to send all Alerts. These values
can be customized to filter out and send only a subset of Alerts to QRadar.
What to do next
To help you troubleshoot, you can look at the forwarding logs in the /var/log/notifier.log file.
When a new notification is created, as described in Step 3, alerts for the last week that match the Query,
Severity, and Confidence fields are sent.
Aruba Mobility Controllers
The Aruba Mobility Controllers DSM for IBM Security QRadar accepts events by using syslog.
QRadar records all relevant events that are forwarded by using syslog on TCP port 514 or UDP port 514.
Configuring your Aruba Mobility Controller
You can configure the Aruba Wireless Networks (Mobility Controller) device to forward syslog events to
IBM Security QRadar.
Procedure
1. Log in to Aruba Mobility Controller.
2. From the top menu, select Configuration.
3. From the Switch menu, select Management.
4. Click the Logging tab.
5. From the Logging Servers menu, select Add.
6. Type the IP address of the QRadar server that you want to collect logs.
7. Click Add.
8. Optional: Change the logging level for a module:
a. Select the check box next to the name of the logging module.
b. Choose the logging level that you want to change from the list that is displayed at the bottom of
the window.
9. Click Done.
10. Click Apply.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Aruba
Mobility Controllers.
20 Aruba Networks
141
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Aruba Mobility Controller.
9. From the Protocol Configuration list, select Syslog.
10. In the Log Source Identifier field, type the IP address or host name for the log source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
142
QRadar DSM Configuration Guide
21 Avaya VPN Gateway
The IBM Security QRadar DSM for Avaya VPN Gateway can collect event logs from your Avaya VPN
Gateway servers.
The following table identifies the specifications for the Avaya VPN Gateway DSM.
Table 77. Avaya VPN Gateway DSM specifications
Specification
Value
Manufacturer
Avaya Inc.
DSM
Avaya VPN Gateway
RPM file name
DSM-AvayaVPNGateway-7.1-799033.noarch.rpm
DSM-AvayaVPNGateway-7.2-799036.noarch.rpm
Supported versions
9.0.7.2
Protocol
syslog
QRadar recorded events
OS, System Control Process, Traffic Processing, Startup, Configuration Reload, AAA
Subsystem, IPsec Subsystem
Automatically discovered
Yes
Includes identity
Yes
More information
http://www.avaya.com
Avaya VPN Gateway DSM integration process
You can integrate Avaya VPN Gateway DSM with IBM Security QRadar.
About this task
To integrate Avaya VPN Gateway DSM with QRadar, use the following procedure:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Syslog protocol RPM
v DSMCommon RPM
v Avaya VPN Gateway RPM
2. For each instance of Avaya VPN Gateway, configure your Avaya VPN Gateway system to enable
communication with QRadar.
3. If QRadar automatically discovers the log source, for each Avaya VPN Gateway server you want to
integrate, create a log source on the QRadar Console.
Configuring your Avaya VPN Gateway system for communication with
IBM Security QRadar
To collect all audit logs and system events from Avaya VPN Gateway, you must specify QRadar as the
syslog server and configure the message format.
© Copyright IBM Corp. 2005, 2018
143
Procedure
1. Log in to your Avaya VPN Gateway command-line interface (CLI).
2. Type the following command:
/cfg/sys/syslog/add
3. At the prompt, type the IP address of your QRadar system.
4. To apply the configuration, type the following command:
apply
5. To verify that the IP address of your QRadar system is listed, type the following command:
/cfg/sys/syslog/list
Configuring an Avaya VPN Gateway log source in IBM Security QRadar
To collect Avaya VPN Gateway events, configure a log source in QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. From the Log Source Type list, select Avaya VPN Gateway.
7. From the Protocol Configuration list, select Syslog.
8. Configure the remaining parameters.
9. Click Save.
10. On the Admin tab, click Deploy Changes.
144
QRadar DSM Configuration Guide
22 BalaBit IT Security
The BalaBit Syslog-ng Agent application can collect and forward syslog events for the Microsoft Security
Event Log DSM and the Microsoft ISA DSM in IBM Security QRadar.
BalaBit IT Security for Microsoft Windows Events
The Microsoft Windows Security Event Log DSM in IBM Security QRadar can accept Log Extended Event
Format (LEEF) events from BalaBit's Syslog-ng Agent.
The BalaBit Syslog-ng Agent forwards the following Windows events to QRadar by using syslog:
v Windows security
v Application
v System
v DNS
v DHCP
v Custom container event logs
Before you can receive events from BalaBit IT Security Syslog-ng Agents, you must install and configure
the agent to forward events.
Before you begin
Review the following configuration steps before you configure the BalaBit Syslog-ng Agent:
1. Install the BalaBit Syslog-ng Agent on your Windows host. For more information, see your BalaBit
Syslog-ng Agent documentation.
2. Configure Syslog-ng Agent Events.
3. Configure QRadar as a destination for the Syslog-ng Agent.
4. Restart the Syslog-ng Agent service.
5. Optional. Configure the log source in QRadar.
Configuring the Syslog-ng Agent event source
Before you can forward events to IBM Security QRadar, you must specify what Windows-based events
the Syslog-ng Agent collects.
Procedure
1. From the Start menu, select All Programs > syslog-ng Agent for Windows > Configure syslog-ng
Agent for Windows.
The Syslog-ng Agent window is displayed.
2. Expand the Syslog-ng Agent Settings pane, and select Eventlog Sources.
3. Double-click Event Containers.
The Event Containers Properties window is displayed.
4. From the Event Containers pane, select the Enable radio button.
5. Select a check box for each event type you want to collect:
v Application - Select this check box if you want the device to monitor the Windows application
event log.
v Security - Select this check box if you want the device to monitor the Windows security event log.
© Copyright IBM Corp. 2005, 2018
145
v System - Select this check box if you want the device to monitor the Windows system event log.
Note: BalaBit's Syslog-ng Agent supports other event types, such as DNS or DHCP events by using
custom containers. For more information, see your BalaBit Syslog-ng Agent documentation.
6. Click Apply, and then click OK.
The event configuration for your BalaBit Syslog-ng Agent is complete. You are now ready to configure
QRadar as a destination for Syslog-ng Agent events.
Configuring a syslog destination
The Syslog-ng Agent enables you to configure multiple destinations for your Windows based events.
About this task
To configure IBM Security QRadar as a destination, you must specify the IP address for QRadar, and then
configure a message template for the LEEF format.
Procedure
1. From the Start menu, select All Programs > Syslog-ng Agent for Windows > Configure syslog-ng
Agent for Windows.
The Syslog-ng Agent window is displayed.
2. Expand the Syslog-ng Agent Settings pane, and click Destinations.
3. Double-click Add new server.
The Server Property window is displayed.
4. Click the Server tab, and then click Set Primary Server.
5. Configure the following parameters:
v Server Name - Type the IP address of your QRadar Console or Event Collector.
v Server Port - Type 514 as the TCP port number for events to be forwarded to QRadar.
6. Click the Messages tab.
7. From the Protocol list, select Legacy BSD Syslog Protocol.
8. In the Template field, define a custom template message for the protocol by typing:
<${PRI}>${BSDDATE} ${HOST} LEEF:${MSG}
The information that is typed in this field is space delimited.
9. In the Event Message Format pane, in the Message Template field, type or copy and paste the
following text to define the format for the LEEF events:
Note: It is suggested that you do not change the text.
1.0|Microsoft|Windows|2k8r2|${EVENT_ID}|devTime=${R_YEAR}-${R_MONTH}${R_DAY}T${R_HOUR}:${R_MIN}:${R_SEC}GMT${TZOFFSET} devTimeFormat=yyyy-MM-dd'T'HH:mm:ssz
cat=${EVENT_TYPE} sev=${EVENT_LEVEL} resource=${HOST} usrName=${EVENT_USERNAME}
application=${EVENT_SOURCE} message=${EVENT_MSG}
Note: The LEEF format uses tab as a delimiter to separate event attributes from each other.
However, the delimiter does not start until after the last pipe character for {Event_ID}. The following
fields must include a tab before the event name: devTime, devTimeFormat, cat, sev, resource, usrName,
application, and message.
You might need to use a text editor to copy and paste the LEEF message format into the Message
Template field.
10. Click OK.
The destination configuration is complete. You are now ready to restart the Syslog-ng Agent service.
146
QRadar DSM Configuration Guide
Restarting the Syslog-ng Agent service
Before the Syslog-ng Agent can forward LEEF formatted events, you must restart the Syslog-ng Agent
service on the Windows host.
Procedure
1. From the Start menu, select Run.
The Run window is displayed.
2. Type the following text:
services.msc
3. Click OK.
The Services window is displayed.
4. In the Name column, right-click on Syslog-ng Agent for Windows, and select Restart.
After the Syslog-ng Agent for Windows service restarts, the configuration is complete. Syslog events
from the BalaBit Syslog-ng Agent are automatically discovered by IBM Security QRadar. The
Windows events that are automatically discovered are displayed as Microsoft Windows Security Event
Logs on the Log Activity tab.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from LEEF
formatted messages.
About this task
These configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your BalaBit Syslog-ng Agent log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Microsoft Windows Security Event Log.
9. Using the Protocol Configuration list, select Syslog.
10. Configure one of the following parameters from the table:
Table 78. Syslog Parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
the BalaBit Syslog-ng Agent.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
BalaBit IT Security for Microsoft ISA or TMG Events
You can integrate the BalaBit Syslog-ng Agent application to forward syslog events to IBM Security
QRadar.
22 BalaBit IT Security
147
The BalaBit Syslog-ng Agent reads Microsoft ISA or Microsoft TMG event logs, and forwards syslog
events by using the Log Extended Event Format (LEEF).
The events that are forwarded by BalaBit IT Security are parsed and categorized by the Microsoft Internet
and Acceleration (ISA) DSM for QRadar. The DSM accepts both Microsoft ISA and Microsoft Threat
Management Gateway (TMG) events.
Before you begin
Before you can receive events from BalaBit IT Security Syslog-ng Agents you must install and configure
the agent to forward events.
Note: This integration uses BalaBit's Syslog-ng Agent for Windows and BalaBit's Syslog-ng PE to parse
and forward events to QRadar for the DSM to interpret.
Review the following configuration steps before you attempt to configure the BalaBit Syslog-ng Agent:
To configure the BalaBit Syslog-ng Agent, you must take the following steps:
1. Install the BalaBit Syslog-ng Agent on your Windows host. For more information, see your BalaBit
Syslog-ng Agent vendor documentation.
2. Configure the BalaBit Syslog-ng Agent.
3. Install a BalaBit Syslog-ng PE for Linux or Unix in relay mode to parse and forward events to
QRadar. For more information, see your BalaBit Syslog-ng PE vendor documentation.
4. Configure syslog for BalaBit Syslog-ng PE.
5. Optional. Configure the log source in QRadar.
Configure the BalaBit Syslog-ng Agent
Before you can forward events to IBM Security QRadar, you must specify the file source for Microsoft
ISA or Microsoft TMG events in the Syslog-ng Agent collects.
If your Microsoft ISA or Microsoft TMG appliance is generating event files for the Web Proxy Server and
the Firewall Service, both files can be added.
Configuring the BalaBit Syslog-ng Agent file source
Use the BalaBit Syslog-ng Agent file source to define the base log directory and files that are to be
monitored by the Syslog-ng Agent.
Procedure
1. From the Start menu, select All Programs > syslog-ng Agent for Windows > Configure syslog-ng
Agent for Windows.
The Syslog-ng Agent window is displayed.
2. Expand the Syslog-ng Agent Settings pane, and select File Sources.
3. Select the Enable radio button.
4. Click Add to add your Microsoft ISA and TMG event files.
5. From the Base Directory field, click Browse and select the folder for your Microsoft ISA or Microsoft
TMG log files.
6. From the File Name Filter field, click Browse and select a log file that contains your Microsoft ISA
or Microsoft TMG events.
Note: The File Name Filter field supports the wild card (*) and question mark (?) characters, which
help you to find log files that are replaced, when they reach a specific file size or date.
7. In the Application Name field, type a name to identify the application.
148
QRadar DSM Configuration Guide
8. From the Log Facility list, select Use Global Settings.
9. Click OK.
To add additional file sources, repeat steps 4 to 9.
10. Click Apply, and then click OK.
The event configuration is complete. You are now ready to configure a syslog destinations and
formatting for your Microsoft TMG and ISA events.
Web Proxy Service events and Firewall Service events are stored in individual files by Microsoft ISA
and TMG.
Configuring a BalaBit Syslog-ng Agent syslog destination
The event logs captured by Microsoft ISA or TMG cannot be parsed by the BalaBit Syslog-ng Agent for
Windows, so you must forward your logs to a BalaBit Syslog-ng Premium Edition (PE) for Linux or
UNIX.
About this task
To forward your TMG and ISA event logs, you must specify the IP address for your PE relay and
configure a message template for the LEEF format. The BalaBit Syslog-ng PE acts as an intermediate
syslog server to parse the events and to forward the information to IBM Security QRadar.
Procedure
1. From the Start menu, select All Programs > syslog-ng Agent for Windows > Configure syslog-ng
Agent for Windows.
The Syslog-ng Agent window is displayed.
2. Expand the Syslog-ng Agent Settings pane, and click Destinations.
3. Double-click Add new Server.
4. On the Server tab, click Set Primary Server.
5. Configure the following parameters:
v For the Server Name type the IP address of your BalaBit Syslog-ng PE relay.
v For the Server Port type 514 as the TCP port number for events that are forwarded to your BalaBit
Syslog-ng PE relay.
6. Click the Messages tab.
7. From the Protocol list, select Legacy BSD Syslog Protocol.
8. From the File Message Format pane, in the Message Template field, type the following code:
${FILE_MESSAGE}${TZOFFSET}
9. Click Apply, and then click OK.
The destination configuration is complete. You are now ready to filter comment lines from the event
log.
Filtering the log file for comment lines
The event log file for Microsoft ISA or Microsoft TMG might contain comment markers. Comments must
be filtered from the event message.
Procedure
1. From the Start menu, select All Programs > Syslog-ng Agent for Windows > Configure syslog-ng
Agent for Windows.
The Syslog-ng Agent window is displayed.
2. Expand the Syslog-ng Agent Settings pane, and select Destinations.
3. Right-click on your IBM Security QRadar Syslog destination and select Event Filters > Properties.
22 BalaBit IT Security
149
The Global event filters Properties window is displayed.
4. Configure the following values:
v From the Global file filters pane, select Enable.
v From the Filter Type pane, select Black List Filtering.
5. Click OK.
6. From the Filter List menu, double-click Message Contents.
The Message Contents Properties window is displayed.
7. From the Message Contents pane, select Enable.
8. In the Regular Expression field, type the following regular expression:
^#
9. Click Add.
10. Click Apply, and then click OK.
The event messages with comments are no longer forwarded.
Note: You might need to restart Syslog-ng Agent for Windows service to begin syslog forwarding.
For more information, see your BalaBit Syslog-ng Agent documentation.
Configuring a BalaBit Syslog-ng PE Relay
The BalaBit Syslog-ng Agent for Windows sends Microsoft TMG and ISA event logs to a Balabit
Syslog-ng PE installation, which is configured in relay mode.
About this task
The relay mode installation is responsible for receiving the event log from the BalaBit Syslog-ng Agent for
Windows, parsing the event logs in to the LEEF format, then forwarding the events to IBM Security
QRadar by using syslog.
To configure your BalaBit Syslog-ng PE Relay, you must:
1. Install BalaBit Syslog-ng PE for Linux or Unix in relay mode. For more information, see your BalaBit
Syslog-ne PE vendor documentation.
2. Configure syslog on your Syslog-ng PE relay.
The BalaBit Syslog-ng PE formats the TMG and ISA events in the LEEF format based on the configuration
of your syslog.conf file. The syslog.conf file is responsible for parsing the event logs and forwarding
the events to QRadar.
Procedure
1. Using SSH, log in to your BalaBit Syslog-ng PE relay command-line interface (CLI).
2. Edit the following file:
/etc/syslog-ng/etc/syslog.conf
3. From the destinations section, add an IP address and port number for each relay destination.
For example, ###### # destinations destination d_messages { file("/var/log/messages"); };
destination d_remote_tmgfw { tcp("QRadar_IP" port(QRadar_PORT) log_disk_fifo_size(10000000)
template(t_tmgfw)); }; destination d_remote_tmgweb { tcp("QRadar_IP" port(QRadar_PORT)
log_disk_fifo_size(10000000) template(t_tmgweb)); };
Where: QRadar_IP is the IP address of your QRadar Console or Event Collector.
QRadar_Port is the port number that is required for QRadar to receive syslog events. By default,
QRadar receives syslog events on port 514.
4. Save the syslog configuration changes.
5. Restart Syslog-ng PE to force the configuration file to be read.
150
QRadar DSM Configuration Guide
The BalaBit Syslog-ng PE configuration is complete. Syslog events that are forwarded from the BalaBit
Syslog-ng relay are automatically discovered by QRadar as Microsoft Windows Security Event Logs
on the Log Activity tab. For more information, see the IBM Security QRadar Users Guide.
Note: When you are using multiple syslog destinations, messages are considered to be delivered
when they successfully arrive at the primary syslog destination.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from LEEF
formatted messages that are provided by your BalaBit Syslog-ng relay.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for the log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Microsoft ISA.
9. From the Protocol Configuration list, select Syslog.
The Syslog Protocol Configuration is displayed.
10. Configure one of the following parameters from the table:
Table 79. Syslog Parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for Microsoft
ISA or Microsoft Threat Management Gateway events from the BalaBit Syslog-ng
Agent.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The BalaBit IT Security configuration for Microsoft ISA and Microsoft TMG events is complete.
22 BalaBit IT Security
151
152
QRadar DSM Configuration Guide
23 Barracuda
IBM Security QRadar supports a range of Barracuda devices.
The devices QRadar supports are:
v “Barracuda Spam & Virus Firewall”
v “Barracuda Web Application Firewall” on page 154
v “Barracuda Web Filter” on page 156
Barracuda Spam & Virus Firewall
You can integrate Barracuda Spam & Virus Firewall with IBM Security QRadar.
The Barracuda Spam & Virus Firewall DSM for QRadar accepts both mail syslog events and web syslog
events from Barracuda Spam & Virus Firewall appliances.
Mail syslog events contain the event and action that is taken when the firewall processes email. Web
syslog events record information on user activity, and configuration changes that occur on your
Barracuda Spam & Virus Firewall appliance.
Before you begin
Syslog messages are sent to QRadar from Barracuda Spam & Virus Firewall by using UDP port 514. You
must verify that any firewalls between QRadar and your Barracuda Spam & Virus Firewall appliance
allow UDP traffic on port 514.
Configuring syslog event forwarding
You can configure syslog forwarding for Barracuda Spam & Virus Firewall.
Procedure
1. Log in to the Barracuda Spam & Virus Firewall web interface.
2. Click the Advanced tab.
3. From the Advanced menu, select Advanced Networking.
4. In the Mail Syslog field, type the IP address of your QRadar Console or Event Collector.
5. Click Add.
6. In the Web Interface Syslog field, type the IP address of your QRadar Console or Event Collector.
7. Click Add.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Barracuda
Spam & Virus Firewall appliances.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
© Copyright IBM Corp. 2005, 2018
153
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for your log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select Barracuda Spam & Virus Firewall.
8. From the Protocol Configuration list, select Syslog.
9. In the Log Source Identifier field, type the IP address or host name for the log source.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
Barracuda Web Application Firewall
The IBM Security QRadar DSM for Barracuda Web Application Firewall collects syslog LEEF and custom
events from Barracuda Web Application Firewall devices.
The following table identifies the specifications for the Barracuda Web Application Firewall DSM:
Table 80. Barracuda Web Application Firewall DSM specifications
Specification
Value
Manufacturer
Barracuda
DSM name
Web Application Firewall
RPM file name
DSM-BarracudaWebApplicationFirewall-QRadar_versionbuild_number.noarch.rpm
Supported versions
V7.0.x and later
Protocol type
QRadar recorded event types
Syslog
System
Web
Access
Audit
Automatically discovered?
If LEEF-formatted payloads, the log source is
automatically discovered.
If custom-formatted payloads, the log source is not
automatically discovered.
Included identity?
Yes
More information
Barracuda Networks website (https://
www.barracudanetworks.com)
To collect syslog events from Barracuda Web Application Firewall, use the following steps:
1. If automatic updates are not enabled, download the most recent version of the following RPMs on
your QRadar Console:
v Barracuda Web Application Firewall DSM RPM
v DSMCommon RPM
2. Configure your Barracuda Web Application Firewall device to send syslog events to QRadar.
154
QRadar DSM Configuration Guide
3. Add a Barracuda Web Application Firewall log source on the QRadar Console. The following table
describes the parameters that require specific values that are required for Barracuda Web Application
Firewall event collection:
Table 81. Barracuda Web Application Firewall log source parameters
Parameter
Value
Log Source type
Barracuda Web Application Firewall
Protocol Configuration
Syslog
Configuring Barracuda Web Application Firewall to send syslog events
to QRadar
Configure your Barracuda Web Application Firewall appliance to send syslog events to IBM Security
QRadar.
Before you begin
Verify that firewalls between the Barracuda appliance and QRadar allow UDP traffic on port 514.
Procedure
1. Log in to the Barracuda Web Application Firewall web interface.
2. Click the Advanced tab.
3. From the Advanced menu, select Export Logs.
4. Click Add Syslog Server.
5. Configure the parameters:
Option
Description
Name
The name of the QRadar Console or Event Collector
Syslog Server
The IP address of your QRadar Console or Event
Collector.
Port
The port that is associated with the IP address of your
QRadar Console or Event Collector.
If syslog messages are sent by UDP, use the default port,
514.
Connection Type
The connection type that transmits the logs from the
Barracuda Web Application Firewall to the QRadar
Console or Event Collector. UDP is the default protocol
for syslog communication.
Validate Server Certificate
No
6. In the Log Formats pane, select a format from the list box for each log type.
v If you are using newer versions of Barracuda Web Application Firewall, select LEEF 1.0 (QRadar).
v If you are using older versions of Barracuda Web Application Firewall, select Custom Format.
7. Click Save Changes.
Configuring Barracuda Web Application Firewall to send syslog events
to QRadar for devices that do not support LEEF
If your device does not support LEEF, you can configure syslog forwarding for Barracuda Web
Application Firewall.
23 Barracuda
155
Procedure
1. Log in to the Barracuda Web Application Firewall web interface.
2. Click the Advanced tab.
3. From the Advanced menu, select Export logs.
4. Click Syslog Settings.
5. Configure a syslog facility value for the following options:
Option
Description
Web Firewall Logs Facility
Select a syslog facility between Local0 and Local7.
Access Logs Facility
Select a syslog facility between Local0 and Local7.
Audit Logs Facility
Select a syslog facility between Local0 and Local7.
System Logs Facility
Select a syslog facility between Local0 and Local7.
Setting a syslog unique facility for each log type allows the Barracuda Web Application Firewall to
divide the logs in to different files.
6. Click Save Changes.
7. In the Name field, type the name of the syslog server.
8. In the Syslog field, type the IP address of your QRadar Console or Event Collector.
9. From the Log Time Stamp option, select Yes.
10. From the Log Unit Name option, select Yes.
11. Click Add.
12. From the Web Firewall Logs Format list box, select Custom Format.
13. In the Web Firewall Logs Format field, type the following custom event format:
t=%t|ad=%ad|ci=%ci|cp=%cp|au=%au
14. From the Access Logs Format list box, select Custom Format.
15. In the Access Logs Format field, type the following custom event format: t=%t|p=%p|s=%s|id=
%id|ai=%ai|ap=%ap|ci=%ci|cp=%cp|si=%si|sp=%sp|cu=%cu
16. From the Access Logs Format list box, select Custom Format.
17. In the Access Logs Format field, type the following custom event format: t=%t|trt=%trt|an=%an|li=
%li|lp=%lp
18. Click Save Changes.
19. From the navigation menu, select Basic > Administration
20. From the System/Reload/Shutdown pane, click Restart.
Results
The syslog configuration is complete after your Barracuda Web Application Firewall restarts. Events that
are forwarded to QRadar by Barracuda Web Application Firewall are displayed on the Log Activity tab.
Barracuda Web Filter
You can integrate Barracuda Web Filter appliance events with IBM Security QRadar.
The Barracuda Web Filter DSM for IBM Security QRadar accepts web traffic and web interface events in
syslog format that are forwarded by Barracuda Web Filter appliances.
Web traffic events contain the events, and any actions that are taken when the appliance processes web
traffic. Web interface events contain user login activity and configuration changes to the Web Filter
appliance.
156
QRadar DSM Configuration Guide
Before you begin
Syslog messages are forward to QRadar by using UDP port 514. You must verify that any firewalls
between QRadar and your Barracuda Web Filter appliance allow UDP traffic on port 514.
Configuring syslog event forwarding
Configure syslog forwarding for Barracuda Web Filter.
Procedure
1. Log in to the Barracuda Web Filter web interface.
2. Click the Advanced tab.
3. From the Advanced menu, select Syslog.
4. From the Web Traffic Syslog field, type the IP address of your QRadar Console or Event Collector.
5. Click Add.
6. From the Web Interface Syslog field, type the IP address of your QRadar Console or Event Collector.
7. Click Add.
The syslog configuration is complete.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Barracuda
Web Filter appliances.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Barracuda Web Filter.
9. Using the Protocol Configuration list, select Syslog.
10. Configure one of the following parameters:
Table 82. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Barracuda Web Filter appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are forwarded by Barracuda Web Filter are displayed
on the Log Activity tab of QRadar.
23 Barracuda
157
158
QRadar DSM Configuration Guide
24 BeyondTrust PowerBroker
The IBM Security QRadar DSM for BeyondTrust PowerBroker logs all events to a multi-line format in a
single event log that is viewed by using Beyond Trust's pblog utility.
To integrate BeyondTrust PowerBroker with QRadar, complete the following steps:
1. If automatic updates are not enabled, RPMs are available for download from the IBM support website
(http://www.ibm.com/support). Download and install the most recent version of the BeyondTrust
PowerBroker DSM RPM on your QRadar Console.
2. Configure BeyondTrust PowerBroker to communicate with QRadar. See Configuring BeyondTrust
PowerBroker to communicate with QRadar.
3. If QRadar does not automatically detect the log source, add a BeyondTrust PowerBroker log source on
the QRadar Console. The following tables describe the parameters that require specific values for
BeyondTrust PowerBroker event collection:
Table 83. Syslog log source parameters
Parameter
Description
Log Source Type
BeyondTrust PowerBroker
Protocol Configuration
Syslog
Log Source Identifier
Type a unique IP address or host name.
Store Event Payload
Select this check box to enable or disable QRadar from storing the event payload.
Automatically discovered log sources use the default value from the Store Event
Payload list in the System Settings window, which is accessible on the Admin tab.
However, when you create a new log source or update the configuration for an
automatically discovered log source, you can override the default value by
configuring this check box for each log source.
For more information about Syslog log source parameters, see Adding a log source.
Table 84. TLS syslog log source parameters
Parameter
Value
Log Source type
BeyondTrust PowerBroker
Protocol Configuration
TLS Syslog
Log Source Identifier
Type a unique IP address or host name.
For more information about TLS syslog log source parameters, see TLS syslog protocol configuration
options.
Related concepts:
“TLS syslog protocol configuration options” on page 48
Configure a TLS Syslog protocol log source to receive encrypted syslog events from up to 1000 network
devices that support TLS Syslog event forwarding.
“BeyondTrust PowerBroker DSM specifications” on page 161
The following table describes the specifications for the BeyondTrust PowerBroker DSM.
“Sample event messages” on page 162
Use these sample event messages as a way of verifying a successful integration with QRadar.
Related tasks:
© Copyright IBM Corp. 2005, 2018
159
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Configuring BeyondTrust PowerBroker to communicate with QRadar”
BeyondTrust pblogs must be reformatted by using a script and then forwarded to IBM Security QRadar.
You need to download and configure a script for your BeyondTrust PowerBroker appliance before you
can forward events to QRadar.
Configuring BeyondTrust PowerBroker to communicate with QRadar
BeyondTrust pblogs must be reformatted by using a script and then forwarded to IBM Security QRadar.
You need to download and configure a script for your BeyondTrust PowerBroker appliance before you
can forward events to QRadar.
Procedure
1. Download the following file from the IBM support website (http://www.ibm.com/support):
pbforwarder.pl.gz
2. Copy the file to the device that hosts BeyondTrust PowerBroker.
Note: Perl 5.8 must be installed on the device that hosts BeyondTrust PowerBroker.
3. Type the following command to extract the file:
gzip -d pbforwarder.pl.gz
4. Type the following command to set the script file permissions:
chmod +x pbforwarder.pl
5. Use SSH to log in to the device that hosts BeyondTrust PowerBroker.
The credentials that are used need to have read, write, and execute permissions for the log file.
6. Type the appropriate command parameters:
Table 85. Command parameters
Parameters
Description
-h
The -h parameter defines the syslog host that receives the events from BeyondTrust
PowerBroker. This is the IP address of your QRadar Console or QRadar Event
Collector.
-t
The -t parameter defines that the command-line is used to tail the log file and
monitor for new output from the listener.
For PowerBroker, this command must be specified as "pblog -l -t".
-p
The -p parameter defines the TCP port to be used when forwarding events.
If nothing is specified, the default is port 514.
-H
The -H parameter defines the host name or IP address for the syslog header of all sent
events. This should be the IP address of the BeyondTrust PowerBroker.
-r
The -r parameter defines the directory name where you want to create the process ID
(.pid) file. The default is /var/run.
This parameter is ignored if -D is specified.
-l
The -I parameter defines the directory name where you want to create the lock file.
The default is /var/lock.
This parameter is ignored if -D is specified.
160
QRadar DSM Configuration Guide
Table 85. Command parameters (continued)
Parameters
Description
-D
The -D parameter defines that the script runs in the foreground.
The default setting is to run as a daemon and log all internal messages to the local
syslog server.
The -f parameter defines the syslog facility and optionally, the severity for messages
that are sent to the Event Collector.
-f
If no value is specified, user.info is used.
The -a parameter enables an AIX® compatible ps method.
-a
This command is only needed when you run BeyondTrust PowerBroker on AIX
systems.
-d
The -d parameter enables debug logging.
-v
The -v parameter displays the script version information.
7. Type the following command to start the pbforwarder.pl script.
pbforwarder.pl -h <IP address> -t "pblog -l -t"
Where <IP address> is the IP address of your QRadar or Event Collector.
8. Type the following command to stop the pbforwarder.pl script:
kill -QUIT `cat /var/run/pbforwarder.pl.pid`
9. Type the following command to reconnect the pbforwarder.pl script:
kill -HUP `cat /var/run/pbforwarder.pl.pid`
QRadar automatically detects and creates a log source from the syslog events that are forwarded from
a BeyondTrust PowerBroker.
BeyondTrust PowerBroker DSM specifications
The following table describes the specifications for the BeyondTrust PowerBroker DSM.
Table 86. BeyondTrust PowerBroker DSM specifications
Specification
Value
Manufacturer
BeyondTrust
DSM name
BeyondTrust PowerBroker
RPM file name
DSM-BeyondTrustPowerBroker-QRadar_versionbuild_number.noarch.rpm
Supported versions
4.0
Protocol
Syslog, TLS syslog
Event format
System, Application
Recorded event types
All events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
BeyondTrust web page (https://www.beyondtrust.com/
products/powerbroker/)
24 BeyondTrust PowerBroker
161
Sample event messages
Use these sample event messages as a way of verifying a successful integration with QRadar.
The following tables provide sample event messages for the BeyondTrust PowerBroker DSM:
Table 87. BeyondTrust PowerBroker sample syslog message
Event name
Low level category
Sample log message
Finish pbrun terminated
Information
<14>Feb 15 13:23:09 qradar4292
pbforwarder.pl: DEVICETYPE = PowerBroker
EVENTID = PB EVENTCAT = unknown
DDATE = USER = SRC =
DST = EVENT_HEADER = ac15208e4eaddff
b1BB002 Finish pbrun terminated: signal 1
(Hangup) unknown signal code event =
"Finish" exitdate = "2011/10/30"
exitstatus = "pbrun terminated: signal 1
(Hangup) unknown signal code" exittime
= "21:01:49" i18n_exitdate = "10/30/11
" i18n_exittime = "21:01:49"
logpid = 22085786 uniqueid =
"ac15208e4eaddffb1BB002"
162
QRadar DSM Configuration Guide
25 BlueCat Networks Adonis
The BlueCat Networks Adonis DSM for IBM Security QRadar accepts events that are forwarded in Log
Enhanced Event Protocol (LEEF) by using syslog from BlueCat Adonis appliances that are managed with
BlueCat Proteus.
QRadar supports BlueCat Networks Adonis appliances by using version 6.7.1-P2 and later.
You might be required to include a patch on your BlueCat Networks Adonis to integrate DNS and DHCP
events with QRadar. For more information, see KB-4670 and your BlueCat Networks documentation.
Supported event types
IBM Security QRadar is capable of collecting all relevant events related to DNS and DHCP queries.
This includes the following events:
v DNS IPv4 and IPv6 query events
v DNS name server query events
v DNS mail exchange query events
v DNS text record query events
v DNS record update events
v DHCP discover events
v DHCP request events
v DHCP release events
Event type format
The LEEF format consists of a pipe ( | ) delimited syslog header and a space delimited event payload.
For example:
Aug 10 14:55:30 <Server> LEEF:1.0|BCN|Adonis|6.7.1|DNS_Query|cat=A_record
src=<Source_IP_address> url=test.example.com
If the syslog events forwarded from your BlueCat Adonis appliances are not formatted similarly to the
sample above, you must examine your device configuration. Properly formatted LEEF event messages are
automatically discovered by the BlueCat Networks Adonis DSM and added as a log source to IBM
Security QRadar.
Before you begin
BlueCat Adonis must be configured to generate events in Log Enhanced Event Protocol (LEEF) and to
redirect the event output to QRadar using syslog.
BlueCat Networks provides a script on their appliances to assist you with configuring syslog. To
complete the syslog redirection, you must have administrative or root access to the command line
interface of the BlueCat Adonis or your BlueCat Proteus appliance. If the syslog configuration script is
not present on your appliance, contact your BlueCat Networks representative.
© Copyright IBM Corp. 2005, 2018
163
Configuring BlueCat Adonis
You can configure your BlueCat Adonis appliance to forward DNS and DHCP events to IBM Security
QRadar SIEM.
Procedure
1. Using SSH, log in to your BlueCat Adonis appliance.
2. On the command-line interface type the following command to start the syslog configuration script:
/usr/local/bluecat/QRadar/setup-QRadar.sh
3. Type the IP address of your QRadar Console or Event Collector.
4. Type yes or no to confirm the IP address.
The configuration is complete when a success message is displayed.
The log source is added to QRadar as BlueCat Networks Adonis syslog events are automatically
discovered. Events that are forwarded to QRadar are displayed on the Log Activity tab. If the events
are not automatically discovered, you can manually configure a log source.
Configuring a log source in IBM Security QRadar
IBM Security QRadar automatically discovers and creates a log source for syslog events from BlueCat
Networks Adonis. However, you can manually create a log source for QRadar to receive syslog events.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select BlueCat Networks Adonis.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 88. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your BlueCat Networks Adonis appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
164
QRadar DSM Configuration Guide
26 Blue Coat
IBM Security QRadar supports a range of Blue Coat products.
Blue Coat SG
The IBM Security QRadar DSM for Blue Coat SG collects events from Blue Coat SG appliances.
The following table lists the specifications for the Blue Coat SG DSM:
Table 89. Blue Coat SG DSM specifications
Specification
Value
Manufacturer
Blue Coat
DSM name
Blue Coat SG Appliance
RPM file name
DSM-BlueCoatProxySG-Qradar_versionbuild_number.noarch.rpm
Supported versions
SG v4.x and later
Protocol
Syslog
Log File Protocol
Recorded event types
All events
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
Yes
More information
Blue Coat website (http://www.bluecoat.com)
To send events from Blue Coat SG to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the Blue Coat
SG DSM RPM on your QRadar Console.
2. Configure your Blue Coat SG device to communicate with QRadar. Complete the following steps:
v Create a custom event format.
v Create a log facility.
v Enable access logging.
v Configure Blue Coat SG for either Log File protocol or syslog uploads.
3. Add an Blue Coat SG log source on the QRadar Console. Configure all the required parameters, but
use the following table to configure the Blue Coat SG specific parameters:
Table 90. Blue Coat SG log source parameters
Parameter
Value
Log Source type
Blue Coat SG Appliance
Protocol Configuration
Select either Log File or Syslog
The instructions provided describe how to configure Blue Coat SG using a custom name-value pair
format. However, QRadar supports the following formats:
v Custom Format
© Copyright IBM Corp. 2005, 2018
165
v SQUID
v NCSA
v main
v IM
v Streaming
v smartreporter
v bcereportermain_v1
v bcreporterssl_v1
v p2p
v SSL
v bcreportercifs_v1
v CIFS
v MAPI
Related concepts:
“Creating extra custom format key-value pairs” on page 171
Related tasks:
“Creating a log facility” on page 167
To use the custom log format that you created for IBM Security QRadar, you must associate the custom
log format to a facility.
“Enabling access logging” on page 167
You must enable access logging on your Blue Coat SG device.
“Configuring a Blue Coat SG Log Source” on page 168
You can manually configure a Blue Coat SG log source in QRadar.
“Configuring Blue Coat SG for FTP uploads” on page 168
To collect Blue Coat SG events using FTP, configure the Blue Coat SC to upload events to a FTP server
using the Blue Coat upload client.
“Configuring Blue Coat SG for syslog” on page 171
To allow syslog event collection, you must configure your Blue Coat SG appliance to forward syslog
events to IBM Security QRadar.
Creating a custom event format
To collect events from Blue Coat SG, create a custom event format.
Procedure
1. Log in to the Blue Coat Management Console.
2. Select Configuration > Access Logging > Formats.
3. Select New.
4. Type a format name for the custom format.
5. Select Custom format string.
6. Type the following custom format:
Attention: The line breaks in these examples will cause this configuration to fail. Copy the code
blocks into a text editor, remove the line breaks, and paste as a single line in the Custom Format
column.
Bluecoat|src=$(c-ip)|srcport=$(c-port)|dst=$(cs-uri-address)
|dstport=$(cs-uri-port)|username=$(cs-username)|devicetime=$(gmttime)
|s-action=$(s-action)|sc-status=$(sc-status)|cs-method=$(cs-method)
|time-taken=$(time-taken)|sc-bytes=$(sc-bytes)|cs-bytes=$(cs-bytes)
|cs-uri-scheme=$(cs-uri-scheme)|cs-host=$(cs-host)|cs-uri-path=$(cs-uri-path)
|cs-uri-query=$(cs-uri-query)|cs-uri-extension=$(cs-uri-extension)
166
QRadar DSM Configuration Guide
|cs-auth-group=$(cs-auth-group)|rs(Content-Type)=$(rs(Content-Type))
|cs(User-Agent)=$(cs(User-Agent))|cs(Referer)=$(cs(Referer))
|sc-filter-result=$(sc-filter-result)|filter-category=$(sc-filter-category)
|cs-uri=$(cs-uri)
7. Select Log Last Header from the list.
8. Click OK.
9. Click Apply.
Note: The custom format for QRadar supports more key-value pairs by using the Blue Coat ELFF
format. For more information, see “Creating extra custom format key-value pairs” on page 171.
What to do next
You are ready to create a log facility on your Blue Coat device.
Related tasks:
“Creating a log facility”
To use the custom log format that you created for IBM Security QRadar, you must associate the custom
log format to a facility.
Creating a log facility
To use the custom log format that you created for IBM Security QRadar, you must associate the custom
log format to a facility.
Procedure
1. Select Configuration > Access Logging > Logs.
2. Click New.
3. Configure the following parameters:
Parameter
Description
Log Name
A name for the log facility.
Log Format
The custom format you that created.
Description
A description for the log facility.
4. Click OK.
5. Click Apply.
Related tasks:
“Enabling access logging”
You must enable access logging on your Blue Coat SG device.
Enabling access logging
You must enable access logging on your Blue Coat SG device.
Procedure
1. Select Configuration > Access Logging > General.
2. Select the Enable Access Logging check box.
3. Optional: If you use Blue Coat SGOS 6.2.11.2 Proxy Edition, complete the following steps:
a. Select Config > Policy > Visual Policy Manager.
b. In the Policy section, add Web Access Layer for Logging.
c. Select Action > Edit and enable logging to the log facility.
4. Click Apply.
26 Blue Coat
167
Related concepts:
“Creating extra custom format key-value pairs” on page 171
Configuring Blue Coat SG for FTP uploads
To collect Blue Coat SG events using FTP, configure the Blue Coat SC to upload events to a FTP server
using the Blue Coat upload client.
Procedure
1. Select Configuration > Access Logging > Logs > Upload Client.
2. From the Log list, select the log that contains your custom format.
3. From the Client type list, select FTP Client.
4. Select the text file option.
5. Click Settings.
6. From the Settings For list, select Primary FTP Server.
7. Configure the following values:
Parameter
Description
Host
The IP address of the FTP server that you want to
forward the Blue Coat events.
Port
The FTP port number.
Path
The directory path for the log files.
Username
The user name to access the FTP server.
8. Click OK.
9. Select the Upload Schedule tab.
10. From the Upload the access log option, select Periodically.
11. Configure the Wait time between connect attempts option.
12. Select to upload the log file to the FTP daily or on an interval.
13. Click Apply.
Configuring a Blue Coat SG Log Source
You can manually configure a Blue Coat SG log source in QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. From the Log Source Type list, select the Blue Coat SG Appliance option.
8. From the Protocol Configuration list, select the Log File option.
9. Configure the following values:
168
QRadar DSM Configuration Guide
Table 91. Blue Coat SG log file protocol parameters
Parameter
Description
Log Source Identifier
Type an IP address, host name, or name to identify the event source. IP addresses
or host names are recommended as they allow QRadar to identify a log file to a
unique event source.
Service Type
From the list, select the protocol that you want to use when retrieving log files from
a remote server. The default is SFTP.
The underlying protocol that is used to retrieve log files for the SCP and SFTP
service type requires that the server specified in the Remote IP or Hostname field
has the SFTP subsystem enabled.
Remote IP or Hostname
Type the IP address or host name of the device that stores your event log files.
Remote Port
Type the TCP port on the remote host that is running the selected Service Type. The
valid range is 1 - 65535.
The options include:
v FTP - TCP Port 21
v SFTP - TCP Port 22
v SCP - TCP Port 22
If the host for your event files is using a non-standard port number for FTP, SFTP,
or SCP, you must adjust the port value.
Remote User
Type the user name necessary to log in to the host that contains your event files.
The user name can be up to 255 characters in length.
Remote Password
Type the password necessary to log in to the host.
Confirm Password
Confirm the password necessary to log in to the host.
SSH Key File
If you select SCP or SFTP as the Service Type, this parameter gives you the option
to define an SSH private key file. When you provide an SSH Key File, the Remote
Password field is ignored.
Remote Directory
Type the directory location on the remote host from which the files are retrieved,
relative to the user account you are using to log in.
For FTP only. If your log files are in the remote user's home directory, you can leave
the remote directory blank. This is to support operating systems where a change in
the working directory (CWD) command is restricted.
Recursive
Select this check box if you want the file pattern to search sub folders in the remote
directory. By default, the check box is clear.
The Recursive option is ignored if you configure SCP as the Service Type.
FTP File Pattern
If you select SFTP or FTP as the Service Type, this option gives you the option to
configure the regular expression (regex) required to filter the list of files that are
specified in the Remote Directory. All matching files are included in the processing.
The FTP file pattern that you specify must match the name you assigned to your
event files. For example, to collect files that end with .log, type the following:
.*\.log
Use of this parameter requires knowledge of regular expressions (regex). For more
information, see the following website: http://download.oracle.com/javase/
tutorial/essential/regex/
26 Blue Coat
169
Table 91. Blue Coat SG log file protocol parameters (continued)
Parameter
Description
FTP Transfer Mode
This option appears only if you select FTP as the Service Type. The FTP Transfer
Mode parameter gives you the option to define the file transfer mode when you
retrieve log files over FTP.
From the list, select the transfer mode that you want to apply to this log source:
You must select NONE for the Processor parameter and LINEBYLINE the Event
Generator parameter when you use ASCII as the FTP Transfer Mode.
SCP Remote File
If you select SCP as the Service Type you must type the file name of the remote file.
Start Time
Type the time of day you want the processing to begin. For example, type 00:00 to
schedule the Log File protocol to collect event files at midnight.
This parameter functions with the Recurrence value to establish when and how
often the Remote Directory is scanned for files. Type the start time, based on a 24
hour clock, in the following format: HH:MM.
Recurrence
Type the frequency, beginning at the Start Time, that you want the remote directory
to be scanned. Type this value in hours (H), minutes (M), or days (D).
For example, type 2H if you want the remote directory to be scanned every 2 hours
from the start time. The default is 1H.
Run On Save
Select this check box if you want the log file protocol to run immediately after you
click Save.
After the Run On Save completes, the log file protocol follows your configured
start time and recurrence schedule.
Selecting Run On Save clears the list of previously processed files for the Ignore
Previously Processed File parameter.
EPS Throttle
Type the number of Events Per Second (EPS) that you do not want this protocol to
exceed. The valid range is 100 to 5000.
Processor
If the files located on the remote host are stored in a zip, gzip, tar, or tar+gzip
archive format, select the processor that allows the archives to be expanded and
contents processed.
Ignore Previously Processed
File(s)
Select this check box to track and ignore files that have already been processed by
the log file protocol.
QRadar examines the log files in the remote directory to determine if a file has been
previously processed by the log file protocol. If a previously processed file is
detected, the log file protocol does not download the file for processing. All files
that have not been previously processed are downloaded.
This option only applies to FTP and SFTP Service Types.
Change Local Directory?
Select this check box to define a local directory on your QRadar system for storing
downloaded files during processing.
We recommend that you leave this check box clear. When this check box is selected,
the Local Directory field is displayed, which allows you to configure the local
directory to use for storing files.
Event Generator
From the Event Generator list, select LineByLine.
The Event Generator applies additional processing to the retrieved event files. Each
line of the file is a single event. For example, if a file has 10 lines of text, 10 separate
events are created.
10. Click Save.
170
QRadar DSM Configuration Guide
11. On the Admin tab, click Deploy Changes.
Configuring Blue Coat SG for syslog
To allow syslog event collection, you must configure your Blue Coat SG appliance to forward syslog
events to IBM Security QRadar.
Before you begin
Note: When you send syslog events to multiple syslog destinations, a disruption in availability in one
syslog destination might interrupt the stream of events to other syslog destinations from your Blue Coat
SG appliance.
Procedure
1. Select Configuration > Access Logging > Logs > Upload Client.
2. From the Log list, select the log that contains your custom format.
3. From the Client type list, select Custom Client.
4. Click Settings.
5. From the Settings For list, select Primary Custom Server.
6. In the Host field, type the IP address for your QRadar system.
7. In the Port field, type 514.
8. Click OK.
9. Select the Upload Schedule tab.
10. From the Upload the access log list, select Continuously.
11. Click Apply.
Creating extra custom format key-value pairs
Use the Extended Log File Format (ELFF) custom format to forward specific Blue Coat data or events to
IBM Security QRadar.
The custom format is a series of pipe-delimited fields that start with the Bluecoat| field and contains the
$(Blue Coat ELFF) parameter.
For example:
Bluecoat|src=$(c-ip)|srcport=$(c-port)|dst=$(cs-uri-address)|dstport=$(cs-uriport)|username=$(cs-username)|devicetime=$(gmttime)|s-action=$(s-action)|sc-status=$(scstatus)|cs-method=$(cs-method)
Table 92. Custom Format examples
Blue Coat ELFF Parameter
QRadar Custom Format Example
sc-bytes
$(sc-bytes)
rs(Content-type)
$(rs(Content-Type))
For more information about available Blue Coat ELFF parameters, see your Blue Coat appliance
documentation.
26 Blue Coat
171
Blue Coat Web Security Service
The IBM Security QRadar DSM for Blue Coat Web Security Service collects events from the Blue Coat
Web Security Service.
The following table describes the specifications for the Blue Coat Web Security Service DSM:
Table 93. Blue Coat Web Security Service DSM specifications
Specification
Value
Manufacturer
Blue Coat
DSM name
Blue Coat Web Security Service
RPM file name
DSM-BlueCoatWebSecurityService-Qradar_versionbuild_number.noarch.rpm
Event format
Blue Coat ELFF
Recorded event types
Access
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Blue Coat website (https://www.bluecoat.com)
To integrate Blue Coat Web Security Service with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Protocol Common RPM
v Blue Coat Web Security Service REST API Protocol RPM
v Blue Coat Web Security Service DSM RPM
2. Configure Blue Coat Web Security Service to allow QRadar access to the Sync API.
3. Add a Blue Coat Web Security Service log source on the QRadar Console. The following table
describes the parameters that require specific values for Blue Coat Web Security Service event
collection:
Table 94. Blue Coat Web Security Service log source parameters
Parameter
Value
Protocol Configuration
The protocol that is used to receive events from the Blue
Coat Web Security Service. You can specify the following
protocol configuration options:
Blue Coat Web Security Service REST API
(recommended)
Forwarded
API Username
The API user name that is used for authenticating with
the Blue Coat Web Security Service. The API user name
is configured through the Blue Coat Threat Pulse Portal.
Password
The password that is used for authenticating with the
Blue Coat Web Security Service.
Confirm Password
The password that is used for authenticating with the
Blue Coat Web Security Service.
172
QRadar DSM Configuration Guide
Table 94. Blue Coat Web Security Service log source parameters (continued)
Parameter
Value
Use Proxy
When you configure a proxy, all traffic for the log source
travels through the proxy for QRadar to access the Blue
Coat Web Security Service.
Configure the Proxy IP or Hostname, Proxy Port, Proxy
Username, and Proxy Password fields. If the proxy does
not require authentication, you can leave the Proxy
Username and Proxy Password fields blank.
Automatically Acquire Server Certificate(s)
Select Yes for QRadar to automatically download the
server certificate and begin trusting the target server.
Recurrence
You can specify the frequency of data collection. The
format is M/H/D for Minutes/Hours/Days. The default
is 5 M.
EPS Throttle
The upper limit for the maximum number of events per
second (EPS). The default is 5000.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
Configuring Blue Coat Web Security Service to communicate with
QRadar
To collect events from Blue Coat Web Security Service, you must create an API key for IBM Security
QRadar. If an API key exists, Blue Coat Web Security Service is already configured.
Procedure
1. Log in to the Blue Coat Threat Pulse portal.
2. Switch to Service mode.
3. Click Account Maintenance > MDM, API Keys.
4. Click Add API key, type a user name and password for the API key, and then click Add.
You need the user name and password when you configure the log source for the API.
26 Blue Coat
173
174
QRadar DSM Configuration Guide
27 Box
The IBM Security QRadar DSM for Box collects enterprise events from a Box enterprise account.
The following table describes the specifications for the Box DSM:
Table 95. Box DSM specifications
Specification
Value
Manufacturer
Box
DSM name
Box
RPM file name
DSM-BoxBox-Qradar_version-build_number.noarch.rpm
Supported versions
N/A
Protocol
Box REST API
Event format
JSON
Recorded event types
Administrator and enterprise events
Automatically discovered?
No
Includes identity?
Yes
Includes custom properties?
No
More information
Box website (https://www.box.com/)
To integrate Box with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console in the order that they are listed:
v Protocol Common RPM
v Box REST API Protocol RPM
v Box DSM RPM
2. Configure your Box enterprise account for API access.
3. The following table describes the parameters that require specific values for Box event collection:
Table 96. Box log source parameters
Parameter
Value
Log Source type
Box
Protocol Configuration
Box REST API
Client ID
Generated in the OAuth2 parameters pane of the Box
administrator configuration.
Client Secret
Generated in the OAuth2 parameters pane of the Box
administrator configuration.
Key ID
Generated in the Public Key Management pane after you
submit the public key.
Enterprise ID
Used for access token request.
Private Key File Name
The private key file name in the /opt/qradar/conf/
trusted_certificates/box/ directory in QRadar.
© Copyright IBM Corp. 2005, 2018
175
Table 96. Box log source parameters (continued)
Parameter
Value
Use Proxy
If QRadar accesses the Box API, by using a proxy, select
the Use Proxy check box.
If the proxy requires authentication, configure the Proxy
Server, Proxy Port, Proxy Username, and Proxy
Password fields.
If the proxy does not require authentication, configure
the Proxy Server and Proxy Port fields.
Automatically Acquire Server Certificate(s)
Select Yes for QRadar to automatically download the
server certificate and begin trusting the target server.
EPS Throttle
The maximum number of events per second.
The default is 5000.
Recurrence
The time interval between log source queries to the Box
API for new events. The time interval can be in hours
(H), minutes (M), or days (D).
The default is 10 minutes.
The following table shows a sample event message for Box:
Table 97. Box enterprise sample event message
Event name
Low level category
Sample log message
LOGIN
User Login Success
{"source":{"type":"user","id":
"<UserID>","name":"UserName",
"login":"username@example.com"},
"created_by":{"type":"user",
"id":"<UserID>","name":
"UserName","login":
"username@example.com"},
"created_at":"2016-01-07T10
:54:30-08:00","event_id":
"363714450","event_type":"LOGIN",
"ip_address":"<IP_address>","type"
:"event","session_id":null,
"additional_details":null}
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Box to communicate with QRadar
To retrieve administrator logs from your Box enterprise account, you must configure Box and your IBM
Security QRadar Console.
176
QRadar DSM Configuration Guide
Before you begin
You must have a developer account.
Generate a private/public RSAkey pair for the JSON Web Token (JWT) assertion.
1. Open an SSH session to the QRadar Console.
v For a private key, type the following command:
openssl genrsa -out box_private_key.pem 2048
v For a public key, type the following command:
openssl rsa -pubout -in box_private_key.pem -out box_public_key.pem
Note:
Save a copy of the public key. You are required to paste the contents of the public key into the Add
Public Key text box when you configure Box for API access.
v Convert the private key to DER by typing the following command on one line:
openssl pkcs8 -topk8 -inform PEM -outform DER
-in box_private_key.pem -out box_private_key.der -nocrypt
2. Store the private key in QRadar.
a. Create a directory that is named box in the opt/qradar/conf/trusted_certificates/ directory in
QRadar.
b. Copy the private key .DER file to the opt/qradar/conf/trusted_certificates/box directory that
you created. Do not store the private key in any other location.
c. Configure the log source by using only the file name of the private key file in the
opt/qradar/conf/trusted_certificates/box directory. Ensure that you type the file name correctly
in the Private Key File Name field when you configure the log source.
Important: Copy the private key to the opt/qradar/conf/trusted_certificates/box directory before you
configure the log source. If you configure the log source before you store the private key, an error
message is displayed.
Procedure
1. Log in to Box Developers portal (http://developers.box.com/). You will now have access to the
Admin and Box Consoles.
a. Create an application for your QRadar appliance by clicking Create a Box Application.
b. Record the client ID, and the client secret in the OAuth2 parameters pane. The log source is
configured by using the client ID and the client secret.
c. Select Server Authentication (OAuth2.0 with JWT), and then select All Users.
d. Record the API key that is in the Backend parameters pane. The API key is required to authorize
the new App.
e. In the OAuth2 parameters pane, from the User Access Settings list, select All Users, and then
configure the following parameters.
Table 98. User Access Settings parameters
Parameter
Value
Authentication Type:
Server Authentication (OAuth2.0 with JWT)
User Access:
All Users
27 Box
177
Table 98. User Access Settings parameters (continued)
Parameter
Scopes:
Value
Content
Read and write all files and folders stored in
Box
Enterprise
Manage an enterprise's properties. Allows the
application to view and edit enterprise
attributes and reports; edit and delete device
pinners.
Important: If you do not select the correct scopes, Box
API displays an error message.
2. Submit the public key, and then generate the key ID.
a. In the Public Key Management pane, click Add Public Key.
b. Open the public key file that you copied from QRadar, and then paste the contents of the public
key file in the Add Public Key text box.
c. Click Verify.
d. Click Save, and then record the key ID for the log source configuration.
e. To ensure that the properties are stored on the server, scroll to the bottom of the page and then
click Save.
3. Record your Box Enterprise ID.
a. Log in to the Admin Console, and then click Settings.
b. To locate your Enterprise ID, click the Account Info tab.
4. Authorize your application.
a. Log in to the Box Console, and then click Settings.
b. Click the Apps tab.
c. In the Custom Applications pane, click Authorize New App.
d. In the App Authorization window, type the API key, and then click Next. Verify that the access
level is All Users.
e. Click Authorize.
For more information about configuring Box to communicate with QRadar, see the Box website
https://docs.box.com/docs/configuring-box-platform).
What to do next
Verify that QRadar is configured to receive events from your Box DSM. If QRadar is configured correctly,
no error messages appear in the Edit a log source window.
178
QRadar DSM Configuration Guide
28 Bridgewater
The Bridgewater Systems DSM for IBM Security QRadar accepts events by using syslog.
QRadar records all relevant events that are forwarded from Bridgewater AAA Service Controller devices
by using syslog.
Configuring Syslog for your Bridgewater Systems Device
You must configure your Bridgewater Systems appliance to send syslog events to IBM Security QRadar.
Procedure
1. Log in to your Bridgewater Systems device command-line interface (CLI).
2. To log operational messages to the RADIUS and Diameter servers, open the following file:
/etc/syslog.conf
3. To log all operational messages, uncomment the following line:
local1.info /WideSpan/logs/oplog
4. To log error messages only, change the local1.info /WideSpan/logs/oplog line to the following line:
local1.err /WideSpan/logs/oplog
Note: RADIUS and Diameter system messages are stored in the /var/adm/messages file.
5. Add the following line:
local1.*@<IP address>
Where <IP address> is the IP address your QRadar Console.
6. The RADIUS and Diameter server system messages are stored in the /var/adm/messages file. Add the
following line for the system messages:
<facility>*@<IP address>
Where:
<facility> is the facility that is used for logging to the /var/adm/messages file.
<IP address> is the IP address of your QRadar Console.
7. Save and exit the file.
8. Send a hang-up signal to the syslog daemon to make sure that all changes are enforced:
kill -HUP `cat /var/run/syslog.pid`
The configuration is complete. The log source is added to QRadar as Bridgewater Systems appliance
events are automatically discovered. Events that are forwarded to QRadar by your Bridgewater
Systems appliance are displayed on the Log Activity tab.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from a
Bridgewater Systems appliance.
About this task
The following configuration steps are optional.
© Copyright IBM Corp. 2005, 2018
179
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Bridgewater Systems AAA Service Controller.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 99. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Bridgewater Systems appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
180
QRadar DSM Configuration Guide
29 Brocade Fabric OS
IBM Security QRadar can collect and categorize syslog system and audit events from Brocade switches
and appliances that use Fabric OS V7.x.
To collect syslog events, you must configure your switch to forward syslog events. Each switch or
appliance must be configured to forward events.
Events that you forward from Brocade switches are automatically discovered. A log source is configured
for each switch or appliance that forwards events to QRadar.
Configuring syslog for Brocade Fabric OS appliances
To collect events, you must configure syslog on your Brocade appliance to forward events to IBM
Security QRadar.
Procedure
1. Log in to your appliance as an admin user.
2. To configure an address to forward syslog events, type the following command:
syslogdipadd <IP address>
Where <IP address> is the IP address of the QRadar Console, Event Processor, Event Collector, or
all-in-one system.
3. To verify the address, type the following command:
syslogdipshow
Results
As the Brocade switch generates events the switch forwards events to the syslog destination you
specified. The log source is automatically discovered after enough events are forwarded by the Brocade
appliance. It typically takes a minimum of 25 events to automatically discover a log source.
What to do next
Administrators can log in to the QRadar Console and verify that the log source is created on the QRadar
Console and that the Log Activity tab displays events from the Brocade appliance.
© Copyright IBM Corp. 2005, 2018
181
182
QRadar DSM Configuration Guide
30 CA Technologies
IBM Security QRadar supports a number of CA Technologies DSMs.
CA ACF2
The CA Access Control Facility (ACF2) DSM collects events from a CA Technologies ACF2 image on an
IBM z/OS mainframe by using IBM Security zSecure™.
When you use a zSecure process, events from the System Management Facilities (SMF) can be
transformed into Log Event Extended Format (LEEF) events. These events can be sent near real-time by
using UNIX Syslog protocol or IBM Security QRadar can retrieve the LEEF event log files by using the
Log File protocol and then process the events. When you use the Log File protocol, you can schedule
QRadar to retrieve events on a polling interval, which enables QRadar to retrieve the events on the
schedule that you define.
To collect CA ACF2 events, complete the following steps:
1. Verify that your installation meets any prerequisite installation requirements. For more information
about prerequisite requirements, see the IBM Security zSecure Suite 2.2.1 Prerequisites
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/prereqs_qradar.html) .
2. Configure your IBM z/OS image to write events in LEEF format. For more information, see the IBM
Security zSecure Suite: CARLa-Driven Components Installation and Deployment Guide
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/setup_data_prep_qradar.html).
3. Create a log source in QRadar for CA ACF2.
4. If you want to create a custom event property for CA ACF2 in QRadar, for more information, see the
IBM Security Custom Event Properties for IBM z/OS technical note (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf).
Before you begin
Before you can configure the data collection process, you must complete the basic zSecure installation
process and complete the post-installation activities to create and modify the configuration.
The following prerequisites are required:
v
You must ensure parmlib member IFAPRDxx is enabled for IBM Security zSecure Audit on your
z/OS® image.
v The SCKRLOAD library must be APF-authorized.
v If you are using the direct SMF INMEM real-time interface, you must have the necessary software
installed (APAR OA49263) and set up the SMFPRMxx member to include the INMEM keyword and
parameters. If you decide to use the CDP interface, you must also have CDP installed and running. For
more information, see the IBM Security zSecure Suite 2.2.1: Procedure for near real-time
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/smf_proc_real_time_qradar.html)
v You must configure a process to periodically refresh your CKFREEZE and UNLOAD data sets.
v If you are using the Log File protocol method, you must configure a SFTP, FTP, or SCP server on your
z/OS image for QRadar to download your LEEF event files.
© Copyright IBM Corp. 2005, 2018
183
v If you are using the Log File protocol method, you must allow SFTP, FTP, or SCP traffic on firewalls
that are located between QRadar and your z/OS image.
For instructions on installing and configuring zSecure, see the IBM Security zSecure Suite: CARLa-Driven
Components Installation and Deployment Guide (http://www-01.ibm.com/support/
docview.wss?uid=pub1sc27277200).
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Create a log source for near real-time event feed
The Syslog protocol enables IBM Security QRadar to receive System Management Facilities (SMF) events
in near real-time from a remote host.
The following DSMs are supported:
v IBM z/OS
v IBM CICS®
v IBM RACF®
v IBM DB2
v CA Top Secret
v CA ACF2
If QRadar does not automatically detect the log source, add a log source for your DSM on the QRadar
console.
The following table describes the parameters that require specific values for event collection for your
DSM:
Table 100. Log source parameters
Parameter
Value
Log Source type
Select your DSM name from the list.
Protocol Configuration
Syslog
Log Source Identifier
Type a unique identifier for the log source.
Creating a log source for Log File protocol
The Log File protocol enables IBM Security QRadar to retrieve archived log files from a remote host for
the IBM z/OS, IBM CICS, IBM RACF, IBM DB2, CA Top Secret, and CA ACF2 DSM's.
About this task
Log files are transferred, one at a time, to QRadar for processing. The Log File protocol can manage plain
text event logs, compressed files, or archives. Archives must contain plain-text files that can be processed
one line at a time. Multi-line event logs are not supported by the Log File protocol. IBM z/OS with
zSecure writes log files to a specified directory as gzip archives. QRadar extracts the archive and
processes the events, which are written as one event per line in the file.
To retrieve these events, you must create a log source that uses the Log File protocol. QRadar requires
credentials to log in to the system that hosts your LEEF formatted event files and a polling interval.
184
QRadar DSM Configuration Guide
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for the log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select your DSM name.
8. From the Protocol Configuration list, select Log File.
9. Configure the Log File protocol parameters.
The following table describes the parameters that require specific values for the DSM event
collection:
Table 101. Log File protocol parameters
Parameter
Value
Log Source Identifier
Type an IP address, host name, or name to identify the event source. IP addresses
or host names are suggested as they allow QRadar to identify a log file to a unique
event source.
For example, if your network contains multiple devices, such as multiple z/OS
images or a file repository that contains all of your event logs, you must specify a
name, IP address, or host name for the image or location that uniquely identifies
events for the DSM log source. This specification enables events to be identified at
the image or location level in your network that your users can identify.
Service Type
From the Service Type list, select the protocol that you want to use when retrieving
log files from a remote server. The default is SFTP.
v SFTP - SSH File Transfer Protocol
v FTP - File Transfer Protocol
v SCP - Secure Copy
The underlying protocol that is used to retrieve log files for the SCP and SFTP
service type requires that the server that is specified in the Remote IP or Hostname
field has the SFTP subsystem enabled.
Remote IP or Hostname
Type the IP address or host name of the device that stores your event log files.
Remote Port
Type the TCP port on the remote host that is running the selected Service Type.
The valid range is 1 - 65535.
The options include ports:
v FTP - TCP Port 21
v SFTP - TCP Port 22
v SCP - TCP Port 22
If the host for your event files is using a non-standard port number for FTP, SFTP,
or SCP, you must adjust the port value.
Remote User
Type the user name or user ID necessary to log in to the system that contains your
event files.
v If your log files are on your IBM z/OS image, type the user ID necessary to log
in to your IBM z/OS. The user ID can be up to 8 characters in length.
v If your log files are on a file repository, type the user name necessary to log in to
the file repository. The user name can be up to 255 characters in length.
Remote Password
Type the password necessary to log in to the host.
Confirm Password
Confirm the password necessary to log in to the host.
30 CA Technologies
185
Table 101. Log File protocol parameters (continued)
Parameter
Value
SSH Key File
If you select SCP or SFTP as the Service Type, this parameter gives you the option
to define an SSH private key file. When you provide an SSH Key File, the Remote
Password field is ignored.
Remote Directory
Type the directory location on the remote host from which the files are retrieved,
relative to the user account you are using to log in.
Recursive
If you want the file pattern to search sub folders in the remote directory, select this
check box. By default, the check box is clear.
If you configure SCP as the Service Type, the Recursive option is ignored.
FTP File Pattern
If you select SFTP or FTP as the Service Type, you can configure the regular
expression (regex) needed to filter the list of files that are specified in the Remote
Directory. All matching files are included in the processing.
The IBM z/OS mainframe that uses IBM Security zSecure Audit writes event files
by using the pattern: <product_name>.<timestamp>.gz
The FTP file pattern that you specify must match the name that you assigned to
your event files. For example, to collect files that start with zOS and end with .gz,
type the following code:
zOS.*\.gz
Use of this parameter requires knowledge of regular expressions (regex). For more
information about regex, see Lesson: Regular Expressions. (http://
download.oracle.com/javase/tutorial/essential/regex/)
FTP Transfer Mode
This option displays only if you select FTP as the Service Type. From the list, select
Binary.
The binary transfer mode is needed for event files that are stored in a binary or
compressed format, such as zip, gzip, tar, or tar+gzip archive files.
SCP Remote File
If you select SCP as the Service Type you must type the file name of the remote
file.
Start Time
Type the time of day you want the processing to begin. For example, type 00:00 to
schedule the Log File protocol to collect event files at midnight.
This parameter functions with the Recurrence value to establish when and how
often the Remote Directory is scanned for files. Type the start time, based on a
24-hour clock, in the following format: HH: MM.
Recurrence
Type the frequency, beginning at the Start Time, that you want the remote directory
to be scanned. Type this value in hours (H), minutes (M), or days (D).
For example, type 2H if you want the remote directory to be scanned every 2 hours
from the start time. The default is 1H.
Run On Save
If you want the Log File protocol to run immediately after you click Save, select
this check box.
After the Run On Save completes, the Log File protocol follows your configured
start time and recurrence schedule.
Selecting Run On Save clears the list of previously processed files for the Ignore
Previously Processed File parameter.
EPS Throttle
186
Type the number of Events Per Second (EPS) that you do not want this protocol to
exceed. The valid range is 100 - 5000.
QRadar DSM Configuration Guide
Table 101. Log File protocol parameters (continued)
Parameter
Value
Processor
From the list, select gzip.
Processors enable event file archives to be expanded and contents are processed for
events. Files are processed after they are downloaded to QRadar. QRadar can
process files in zip, gzip, tar, or tar+gzip archive format.
Ignore Previously Processed
File(s)
Select this check box to track and ignore files that are already processed by the Log
File protocol.
QRadar examines the log files in the remote directory to determine whether a file is
previously processed by the Log File protocol. If a previously processed file is
detected, the Log File protocol does not download the file for processing. All files
that are not previously processed are downloaded.
This option applies only to FTP and SFTP service types.
Change Local Directory?
Select this check box to define a local directory on your QRadar for storing
downloaded files during processing.
It is suggested that you leave this check box clear. When this check box is selected,
the Local Directory field is displayed, which gives you the option to configure the
local directory to use for storing files.
Event Generator
From the Event Generator list, select LineByLine.
The Event Generator applies more processing to the retrieved event files. Each line
is a single event. For example, if a file has 10 lines of text, 10 separate events are
created.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
The DSM configuration is complete. If your DSM requires custom event properties, see the IBM
Security Custom Event Properties for IBM z/OS technical note. (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf)
Integrate CA ACF2 with IBM Security QRadar by using audit scripts
The CA Access Control Facility (ACF2) DSM collects events and audit transactions on the IBM mainframe
with the Log File protocol.
QexACF2.load.trs is a TERSED file that contains a PDS loadlib with the QEXACF2 program. A TERSED
file is similar to a zip file and requires you to use the TRSMAIN program to decompress the contents.
The TRSMAIN program is available from IBM Support (www.ibm.com/support).
To upload a TRS file from a workstation, you must preallocate a file with the following DCB attributes:
DSORG=PS, RECFM=FB, LRECL= 1024, BLKSIZE=6144. The file transfer type must be BINARY APPEND.
If the transfer type is TEXT or TEXT APPEND, then the file cannot decompress properly.
After you upload the file to the mainframe into the allocated dataset, the TERSED file can be
UNPACKED with the TRSMAIN utility by using the sample JCL also included in the tar package. A
return code of 0008 from the TRSMAIN utility indicates that the dataset is not recognized as a valid
TERSED file. This code (0008) error might be the result of the file not being uploaded to the mainframe
with the correct DCB attributes, or because the transfer was not performed with the BINARY APPEND
transfer mechanism.
After you have successfully UNPACKED the loadlib file, you can run the QEXACF2 program with the
sample JCL file. The sample JCL file is contained in the tar collection. To run the QEXACF2 program, you
30 CA Technologies
187
must modify the JCL to your local naming conventions and JOB card requirements. You might also need
to use the STEPLIB DD if the program is not placed in a LINKLISTED library.
To integrate CA ACF2 events into IBM Security QRadar:
1. The IBM mainframe records all security events as Service Management Framework (SMF) records in a
live repository.
2. The CA ACF2 data is extracted from the live repository with the SMF dump utility. The SMF file
contains all of the events and fields from the previous day in raw SMF format.
3. The QexACF2.load.trs program pulls data from the SMF formatted file. The QexACF2.load.trs
program pulls only the relevant events and fields for QRadar and writes that information in a
compressed format for compatibility. The information is saved in a location accessible by QRadar.
4. QRadar uses the Log File protocol source to retrieve the output file information on a scheduled basis.
QRadar then imports and processes this file.
Configuring CA ACF2 that uses audit scripts to integrate with IBM
Security QRadar
IBM Security QRadar uses scripts to audit events from CA ACF2 installations, which are collected by
using the log file protocol.
Procedure
1. From the IBM support website (http://www.ibm.com/support), download the following compressed
file:
qexacf2_bundled.tar.gz
2. On a Linux operating system, extract the file:
tar -zxvf qexacf2_bundled.tar.gz The following files are contained in the archive:
v QexACF2.JCL.txt - Job Control Language file
v QexACF2.load.trs - Compressed program library (requires IBM TRSMAIN)
v trsmain sample JCL.txt - Job Control Language for TRSMAIN to decompress the .trs file
3. Load the files onto the IBM mainframe by using the following methods:
Upload the sample QexACF2_trsmain_JCL.txt and QexACF2.JCL.txt files by using the TEXT protocol.
4. Upload the QexACF2.load.trs file by using a BINARY mode transfer and append to a preallocated
data set. The QexACF2.load.trs file is a tersed file that contains the executable file (the mainframe
program QexACF2). When you upload the .trs file from a workstation, preallocate a file on the
mainframe with the following DCB attributes: DSORG=PS, RECFM=FB, LRECL=1024,
BLKSIZE=6144. The file transfer type must be binary mode and not text.
Note: QexACF2 is a small C mainframe program that reads the output of the TSSUTIL (EARLOUT
data) line by line. QexACF2 adds a header to each record that contains event information, for example,
record descriptor, the date, and time. The program places each field into the output record,
suppresses trailing blank characters, and delimits each field with the pipe character. This output file
is formatted for QRadar and the blank suppression reduces network traffic to QRadar. This program
does not consume CPU or I/O disk resources.
5. Customize the trsmain sample_JCL.txt file according to your installation-specific parameters.
Example: Jobcard, data set naming conventions, output destinations, retention periods, and space
requirements.
The trsmain sample_JCL.txt file uses the IBM utility TRSMAIN to extract the program that is stored
in the QexACF2.load.trs file.
An example of the QexACF2_trsmain_JCL.txt file includes the following information:
188
QRadar DSM Configuration Guide
//TRSMAIN JOB (yourvalidjobcard),Q1labs,
// MSGCLASS=V
//DEL EXEC PGM=IEFBR14
//D1 DD DISP=(MOD,DELETE),DSN=<yourhlq>.QEXACF2.LOAD.TRS
// UNIT=SYSDA,
// SPACE=(CYL,(10,10))
//TRSMAIN EXEC PGM=TRSMAIN,PARM=’UNPACK’
//SYSPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=12901,RECFM=FBA)
//INFILE DD DISP=SHR,DSN=<yourhlq>.QEXACF2.LOAD.TRS
//OUTFILE DD DISP=(NEW,CATLG,DELETE),
// DSN=<yourhlq>.LOAD,
// SPACE=(CYL,(10,10,5),RLSE),UNIT=SYSDA
//
The .trs input file is an IBM TERSE formatted library and is extracted by running the JCL, which
calls the TRSMAIN. This tersed file, when extracted, creates a PDS linklib with the QexACF2 program
as a member.
6. You can STEPLIB to this library or choose to move the program to one of the LINKLIBs that are in
LINKLST. The program does not require authorization.
7. After you upload, copy the program to an existing link listed library or add a STEPLIB DD
statement with the correct data set name of the library that will contain the program.
8. The QexACF2_jcl.txt file is a text file that contains a sample JCL. You must configure the job card to
meet your configuration.
The QexACF2_jcl.txt sample file includes:
//QEXACF2 JOB (T,JXPO,JKSD0093),DEV,NOTIFY=Q1JACK,
// MSGCLASS=P,
// REGION=0M
//*
//*QEXACF2 JCL VERSION 1.0 OCTOBER, 2010
//*
//************************************************************
//* Change below dataset names to sites specific datasets names*
//QEXACF2 JOB (T,JXPO,JKSD0093),DEV,NOTIFY=Q1JACK,
// MSGCLASS=P,
// REGION=0M
//*
//*QEXACF2 JCL VERSION 1.0 OCTOBER, 2010
//*
//************************************************************
//* Change below dataset names to sites specific datasets names*
//************************************************************
//SET1 SET SMFIN=’MVS1.SMF.RECORDS(0)’,
// QEXOUT=’Q1JACK.QEXACF2.OUTPUT’,
// SMFOUT=’Q1JACK.ACF2.DATA’
//************************************************************
//* Delete old datasets *
//************************************************************
//DEL EXEC PGM=IEFBR14
//DD1 DD DISP=(MOD,DELETE),DSN=&SMFOUT,
// UNIT=SYSDA,
// SPACE=(CYL,(10,10)),
// DCB=(RECFM=FB,LRECL=80)
//DD2 DD DISP=(MOD,DELETE),DSN=&QEXOUT,
// UNIT=SYSDA,
// SPACE=(CYL,(10,10)),
// DCB=(RECFM=FB,LRECL=80)
//*************************************************************
//* Allocate new dataset *
//*************************************************************
//ALLOC EXEC PGM=IEFBR14
//DD1 DD DISP=(NEW,CATLG),DSN=&QEXOUT,
// SPACE=(CYL,(100,100)),
// DCB=(RECFM=VB,LRECL=1028,BLKSIZE=6144)
//*************************************************************
30 CA Technologies
189
//* Execute ACFRPTPP (Report Preprocessor GRO) to extract ACF2*
//* SMF records *
//*************************************************************
//PRESCAN EXEC PGM=ACFRPTPP
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//RECMAN1 DD DISP=SHR,DSN=&SMFIN
//SMFFLT DD DSN=&SMFOUT,SPACE=(CYL,(100,100)),DISP=(,CATLG),
// DCB=(RECFM=FB,LRECL=8192,BLKSIZE=40960),
// UNIT=SYSALLDA
//************************************************************
//* execute QEXACF2 *
//************************************************************
//EXTRACT EXEC PGM=QEXACF2,DYNAMNBR=10,
// TIME=1440
//STEPLIB DD DISP=SHR,DSN=Q1JACK.C.LOAD
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//CFG DD DUMMY
//ACFIN DD DISP=SHR,DSN=&SMFOUT
//ACFOUT DD DISP=SHR,DSN=&QEXOUT
//************************************************************
//FTP EXEC PGM=FTP,REGION=3800K
//INPUT DD *
<IPADDR>
<USER>
<PASSWORD>
PUT ’<ACFOUT>’ EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<ACFOUT>
QUIT
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//*
9. After the output file is created, schedule a job to a transfer the output file to an interim FTP server.
The output file is forwarded to an interim FTP server.
You must configure the following parameters in the sample JCL to successfully forward the output
to an interim FTP server:
Example:
//FTP EXEC PGM=FTP,REGION=3800K
//INPUT DD *
<IPADDR>
<USER>
<PASSWORD>
PUT ’<ACFOUT’ EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<ACFOUT>
QUIT
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
Where:
<IPADDR> is the IP address or host name of the interim FTP server to receive the output file.
<USER> is the user name that is needed to access the interim FTP server.
<PASSWORD> is the password that is needed to access the interim FTP server.
<THEIPOFTHEMAINFRAMEDEVICE> is the destination of the mainframe or interim FTP server that
receives the output.
Example:
PUT ’xxxxxx.xxxxxxx.OUTPUT.C320’ /<IP_address>/ACF2/QEXACF2.OUTPUT.C320
<QEXOUTDSN> is the name of the output file that is saved to the interim FTP server.
You are now ready to configure the Log File protocol.
10. Schedule QRadar to retrieve the output file from CA ACF2.
190
QRadar DSM Configuration Guide
If the zOS platform is configured to serve files through FTP, SFTP, or allow SCP, then no interim FTP
server is needed and QRadar can pull the output file directly from the mainframe. The following text
must be commented out using //* or deleted from the QexACF2_jcl.txt file:
//FTP EXEC PGM=FTP,REGION=3800K
//INPUT DD *
<IPADDR>
<USER>
<PASSWORD>
PUT ’<ACFOUT>’ EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<ACFOUT>
QUIT
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
What to do next
You are now ready to configure the log source in QRadar.
CA SiteMinder
The CA SiteMinder DSM collects and categorizes authorization events from CA SiteMinder appliances
with syslog-ng.
The CA SiteMinder DSM accepts access and authorization events that are logged in smaccess.log and
forwards the events to IBM Security QRadar by using syslog-ng.
Configuring a log source
CA SiteMinder with IBM Security QRadar does not automatically discover authorization events that are
forwarded with syslog-ng from CA SiteMinder appliances.
About this task
To manually create a CA SiteMinder log source:
Procedure
1. Click the Admin tab.
2. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
3. Click the Log Sources icon.
The Log Sources window is displayed.
4. In the Log Source Name field, type a name for your CA SiteMinder log source.
5. In the Log Source Description field, type a description for the log source.
6. From the Log Source Type list, select CA SiteMinder.
7. From the Protocol Configuration list, select Syslog.
The syslog protocol parameters are displayed.
Note: The log file protocol is displayed in the Protocol Configuration list, however, polling for log
files is not a suitable configuration.
8. Configure the following values:
Table 102. Adding a syslog log source
Parameter
Description
Log Source Identifier
Type the IP address or host name for your CA
SiteMinder appliance.
30 CA Technologies
191
Table 102. Adding a syslog log source (continued)
Parameter
Description
Enabled
Select this check box to enable the log source. By default,
this check box is selected.
Credibility
From the list, type the credibility value of the log source.
The range is 0 - 10.
The credibility indicates the integrity of an event or
offense as determined by the credibility rating from the
source device. Credibility increases if multiple sources
report the same event. The default is 5.
Target Event Collector
From the list, select the Target Event Collector to use as
the target for the log source.
Coalescing Events
Select this check box to enable the log source to coalesce
(bundle) events.
Automatically discovered log sources use the default
value that is configured in the Coalescing Events list in
the System Settings window, which is accessible on the
Admin tab. However, when you create a new log source
or update the configuration for an automatically
discovered log source that you can override the default
value by configuring this check box for each log source.
For more information, see theIBM Security QRadar
Administration Guide.
Store Event Payload
Select this check box to enable or disable QRadar from
storing the event payload.
Automatically discovered log sources use the default
value from the Store Event Payload list in the System
Settings window, which is accessible on the Admin tab.
When you create a new log source or update the
configuration for an automatically discovered log source
that you can override the default value by configuring
this check box for each log source. For more information,
see the IBM Security QRadar Administration Guide.
9. Click Save.
The Admin tab toolbar detects log source changes and displays a message to indicate when you
need to deploy a change.
10. On the Admin tab, click Deploy Changes.
What to do next
You are now ready to configure syslog-ng on your CA SiteMinder appliance to forward events to QRadar.
Configuring Syslog-ng for CA SiteMinder
You must configure your CA SiteMinder appliance to forward syslog-ng events to your QRadar Console
or Event Collector.
About this task
IBM Security QRadar can collect syslog-ng events from TCP or UDP syslog sources on port 514.
To configure syslog-ng for CA SiteMinder:
192
QRadar DSM Configuration Guide
Procedure
1. Using SSH, log in to your CA SiteMinder appliance as a root user.
2. Edit the syslog-ng configuration file.
/etc/syslog-ng.conf
3. Add the following information to specify the access log as the event file for syslog-ng:
source s_siteminder_access
{ file("/opt/apps/siteminder/sm66/siteminder/log/smaccess.log"); };
4. Add the following information to specify the destination and message template:
destination d_remote_q1_siteminder {
udp("<QRadar IP>" port(514) template ("$PROGRAM $MSG\n"));
};
Where <QRadar IP> is the IP address of the QRadar Console or Event Collector.
5. Add the following log entry information:
log {
source(s_siteminder_access);
destination(d_remote_q1_siteminder);
};
6. Save the syslog-ng.conf file.
7. Type the following command to restart syslog-ng:
service syslog-ng restart
After the syslog-ng service restarts, the CA SiteMinder configuration is complete. Events that are
forwarded to QRadar by CA SiteMinder are displayed on the Log Activity tab.
CA Top Secret
The CA Top Secret DSM collects events from a CA Technologies Top Secret image on an IBM z/OS
mainframe by using IBM Security zSecure.
When you use a zSecure process, events from the System Management Facilities (SMF) can be
transformed into Log Event Extended Format (LEEF) events. These events can be sent near real-time by
using UNIX Syslog protocol or IBM Security QRadar can retrieve the LEEF event log files by using the
Log File protocol and then process the events. When you use the Log File protocol, you can schedule
QRadar to retrieve events on a polling interval, which enables QRadar to retrieve the events on the
schedule that you define.
To collect CA Top Secret events, complete the following steps:
1. Verify that your installation meets any prerequisite installation requirements. For more information
about prerequisite requirements, see the IBM Security zSecure Suite 2.2.1 Prerequisites
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/prereqs_qradar.html) .
2. Configure your IBM z/OS image to write events in LEEF format. For more information, see the IBM
Security zSecure Suite: CARLa-Driven Components Installation and Deployment Guide
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/setup_data_prep_qradar.html).
3. Create a log source in QRadar for CA Top Secret.
4. If you want to create a custom event property for CA Top Secret in QRadar, for more information, see
the IBM Security Custom Event Properties for IBM z/OS technical note (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf).
30 CA Technologies
193
Before you begin
Before you can configure the data collection process, you must complete the basic zSecure installation
process and complete the post-installation activities to create and modify the configuration.
The following prerequisites are required:
You must ensure parmlib member IFAPRDxx is enabled for IBM Security zSecure Audit on your z/OS
image.
v The SCKRLOAD library must be APF-authorized.
v
v If you are using the direct SMF INMEM real-time interface, you must have the necessary software
installed (APAR OA49263) and set up the SMFPRMxx member to include the INMEM keyword and
parameters. If you decide to use the CDP interface, you must also have CDP installed and running. For
more information, see the IBM Security zSecure Suite 2.2.1: Procedure for near real-time
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/smf_proc_real_time_qradar.html)
v You must configure a process to periodically refresh your CKFREEZE and UNLOAD data sets.
v If you are using the Log File protocol method, you must configure a SFTP, FTP, or SCP server on your
z/OS image for QRadar to download your LEEF event files.
v If you are using the Log File protocol method, you must allow SFTP, FTP, or SCP traffic on firewalls
that are located between QRadar and your z/OS image.
For instructions on installing and configuring zSecure, see the IBM Security zSecure Suite: CARLa-Driven
Components Installation and Deployment Guide (http://www-01.ibm.com/support/
docview.wss?uid=pub1sc27277200).
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Creating a log source for Log File protocol
The Log File protocol enables IBM Security QRadar to retrieve archived log files from a remote host for
the IBM z/OS, IBM CICS, IBM RACF, IBM DB2, CA Top Secret, and CA ACF2 DSM's.
About this task
Log files are transferred, one at a time, to QRadar for processing. The Log File protocol can manage plain
text event logs, compressed files, or archives. Archives must contain plain-text files that can be processed
one line at a time. Multi-line event logs are not supported by the Log File protocol. IBM z/OS with
zSecure writes log files to a specified directory as gzip archives. QRadar extracts the archive and
processes the events, which are written as one event per line in the file.
To retrieve these events, you must create a log source that uses the Log File protocol. QRadar requires
credentials to log in to the system that hosts your LEEF formatted event files and a polling interval.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for the log source.
194
QRadar DSM Configuration Guide
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select your DSM name.
8. From the Protocol Configuration list, select Log File.
9. Configure the Log File protocol parameters.
The following table describes the parameters that require specific values for the DSM event
collection:
Table 103. Log File protocol parameters
Parameter
Value
Log Source Identifier
Type an IP address, host name, or name to identify the event source. IP addresses
or host names are suggested as they allow QRadar to identify a log file to a unique
event source.
For example, if your network contains multiple devices, such as multiple z/OS
images or a file repository that contains all of your event logs, you must specify a
name, IP address, or host name for the image or location that uniquely identifies
events for the DSM log source. This specification enables events to be identified at
the image or location level in your network that your users can identify.
Service Type
From the Service Type list, select the protocol that you want to use when retrieving
log files from a remote server. The default is SFTP.
v SFTP - SSH File Transfer Protocol
v FTP - File Transfer Protocol
v SCP - Secure Copy
The underlying protocol that is used to retrieve log files for the SCP and SFTP
service type requires that the server that is specified in the Remote IP or Hostname
field has the SFTP subsystem enabled.
Remote IP or Hostname
Type the IP address or host name of the device that stores your event log files.
Remote Port
Type the TCP port on the remote host that is running the selected Service Type.
The valid range is 1 - 65535.
The options include ports:
v FTP - TCP Port 21
v SFTP - TCP Port 22
v SCP - TCP Port 22
If the host for your event files is using a non-standard port number for FTP, SFTP,
or SCP, you must adjust the port value.
Remote User
Type the user name or user ID necessary to log in to the system that contains your
event files.
v If your log files are on your IBM z/OS image, type the user ID necessary to log
in to your IBM z/OS. The user ID can be up to 8 characters in length.
v If your log files are on a file repository, type the user name necessary to log in to
the file repository. The user name can be up to 255 characters in length.
Remote Password
Type the password necessary to log in to the host.
Confirm Password
Confirm the password necessary to log in to the host.
SSH Key File
If you select SCP or SFTP as the Service Type, this parameter gives you the option
to define an SSH private key file. When you provide an SSH Key File, the Remote
Password field is ignored.
Remote Directory
Type the directory location on the remote host from which the files are retrieved,
relative to the user account you are using to log in.
30 CA Technologies
195
Table 103. Log File protocol parameters (continued)
Parameter
Value
Recursive
If you want the file pattern to search sub folders in the remote directory, select this
check box. By default, the check box is clear.
If you configure SCP as the Service Type, the Recursive option is ignored.
FTP File Pattern
If you select SFTP or FTP as the Service Type, you can configure the regular
expression (regex) needed to filter the list of files that are specified in the Remote
Directory. All matching files are included in the processing.
The IBM z/OS mainframe that uses IBM Security zSecure Audit writes event files
by using the pattern: <product_name>.<timestamp>.gz
The FTP file pattern that you specify must match the name that you assigned to
your event files. For example, to collect files that start with zOS and end with .gz,
type the following code:
zOS.*\.gz
Use of this parameter requires knowledge of regular expressions (regex). For more
information about regex, see Lesson: Regular Expressions. (http://
download.oracle.com/javase/tutorial/essential/regex/)
FTP Transfer Mode
This option displays only if you select FTP as the Service Type. From the list, select
Binary.
The binary transfer mode is needed for event files that are stored in a binary or
compressed format, such as zip, gzip, tar, or tar+gzip archive files.
SCP Remote File
If you select SCP as the Service Type you must type the file name of the remote
file.
Start Time
Type the time of day you want the processing to begin. For example, type 00:00 to
schedule the Log File protocol to collect event files at midnight.
This parameter functions with the Recurrence value to establish when and how
often the Remote Directory is scanned for files. Type the start time, based on a
24-hour clock, in the following format: HH: MM.
Recurrence
Type the frequency, beginning at the Start Time, that you want the remote directory
to be scanned. Type this value in hours (H), minutes (M), or days (D).
For example, type 2H if you want the remote directory to be scanned every 2 hours
from the start time. The default is 1H.
Run On Save
If you want the Log File protocol to run immediately after you click Save, select
this check box.
After the Run On Save completes, the Log File protocol follows your configured
start time and recurrence schedule.
Selecting Run On Save clears the list of previously processed files for the Ignore
Previously Processed File parameter.
EPS Throttle
Type the number of Events Per Second (EPS) that you do not want this protocol to
exceed. The valid range is 100 - 5000.
Processor
From the list, select gzip.
Processors enable event file archives to be expanded and contents are processed for
events. Files are processed after they are downloaded to QRadar. QRadar can
process files in zip, gzip, tar, or tar+gzip archive format.
196
QRadar DSM Configuration Guide
Table 103. Log File protocol parameters (continued)
Parameter
Value
Ignore Previously Processed
File(s)
Select this check box to track and ignore files that are already processed by the Log
File protocol.
QRadar examines the log files in the remote directory to determine whether a file is
previously processed by the Log File protocol. If a previously processed file is
detected, the Log File protocol does not download the file for processing. All files
that are not previously processed are downloaded.
This option applies only to FTP and SFTP service types.
Change Local Directory?
Select this check box to define a local directory on your QRadar for storing
downloaded files during processing.
It is suggested that you leave this check box clear. When this check box is selected,
the Local Directory field is displayed, which gives you the option to configure the
local directory to use for storing files.
Event Generator
From the Event Generator list, select LineByLine.
The Event Generator applies more processing to the retrieved event files. Each line
is a single event. For example, if a file has 10 lines of text, 10 separate events are
created.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
The DSM configuration is complete. If your DSM requires custom event properties, see the IBM
Security Custom Event Properties for IBM z/OS technical note. (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf)
Create a log source for near real-time event feed
The Syslog protocol enables IBM Security QRadar to receive System Management Facilities (SMF) events
in near real-time from a remote host.
The following DSMs are supported:
v IBM z/OS
v IBM CICS
v IBM RACF
v IBM DB2
v CA Top Secret
v CA ACF2
If QRadar does not automatically detect the log source, add a log source for your DSM on the QRadar
console.
The following table describes the parameters that require specific values for event collection for your
DSM:
Table 104. Log source parameters
Parameter
Value
Log Source type
Select your DSM name from the list.
Protocol Configuration
Syslog
Log Source Identifier
Type a unique identifier for the log source.
30 CA Technologies
197
Integrate CA Top Secret with IBM Security QRadar by using audit
scripts
The CA Top Secret DSM collects events and audit transactions on the IBM mainframe with the Log File
protocol.
IBM Security QRadar records all relevant and available information from the event.
To integrate CA Top Secret events into QRadar:
1. The IBM mainframe records all security events as Service Management Framework (SMF) records in a
live repository.
2. At midnight, the CA Top Secret data is extracted from the live repository by using the SMF dump
utility. The SMF file contains all of the events and fields from the previous day in raw SMF format.
3. The qextopsloadlib program pulls data from the SMF formatted file. The qextopsloadlib program
only pulls the relevant events and fields for QRadar and writes that information in a condensed
format for compatibility. The information is saved in a location accessible by QRadar.
4. QRadar uses the Log File protocol source to retrieve the output file information on a scheduled basis.
QRadar then imports and processes this file.
Configuring CA Top Secret that uses audit scripts to integrate with
IBM Security QRadar
The CA Top Secret DSM collects events and audit transactions on the IBM mainframe by using the Log
File protocol.
Procedure
1. From the IBM support website (http://www.ibm.com/support), download the following compressed
file:
qextops_bundled.tar.gz
2. On a Linux operating system, extract the file:
tar -zxvf qextops_bundled.tar.gz
The following files are contained in the archive:
v qextops_jcl.txt
v qextopsloadlib.trs
v qextops_trsmain_JCL.txt
3. Load the files onto the IBM mainframe by using any terminal emulator file transfer method.
Upload the sample qextops_trsmain_JCL.txt and qextops_jcl.txt files by using the TEXT protocol.
4. Upload the qextopsloadlib.trs file by using a BINARY mode transfer. The qextopsloadlib.trs file
is a tersed file that contains the executable (the mainframe program qextops). When you upload the
.trs file from a workstation, preallocate a file on the mainframe with the following DCB attributes:
DSORG=PS, RECFM=FB, LRECL=1024, BLKSIZE=6144. The file transfer type must be binary mode
and not text.
Note: Qextops is a small C mainframe program that reads the output of the TSSUTIL (EARLOUT
data) line by line. Qextops adds a header to each record that contains event information, for example,
record descriptor, the date, and time. The program places each field into the output record,
suppresses trailing blank characters, and delimits each field with the pipe character. This output file
is formatted for QRadar and the blank suppression reduces network traffic to QRadar. This program
does not consume CPU or I/O disk resources.
5. Customize the qextops_trsmain_JCL.txt file according to your installation-specific requirements.
198
QRadar DSM Configuration Guide
The qextops_trsmain_JCL.txt file uses the IBM utility TRSMAIN to extract the program that is
stored in the qextopsloadlib.trs file.
An example of the qextops_trsmain_JCL.txt file includes:
//TRSMAIN JOB (yourvalidjobcard),Q1labs,
// MSGCLASS=V
//DEL EXEC PGM=IEFBR14
//D1 DD DISP=(MOD,DELETE),DSN=<yourhlq>.QEXTOPS.TRS
// UNIT=SYSDA,
// SPACE=(CYL,(10,10))
//TRSMAIN EXEC PGM=TRSMAIN,PARM=’UNPACK’
//SYSPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=12901,RECFM=FBA)
//INFILE DD DISP=SHR,DSN=<yourhlq>.QEXTOPS.TRS
//OUTFILE DD DISP=(NEW,CATLG,DELETE),
// DSN=<yourhlq>.LOAD,
// SPACE=(CYL,(10,10,5),RLSE),UNIT=SYSDA
//
You must update the file with your installation specific information for parameters, such as, jobcard,
data set naming conventions, output destinations, retention periods, and space requirements.
The .trs input file is an IBM TERSE formatted library and is extracted by running the JCL, which
calls the TRSMAIN. This tersed file, when extracted, creates a PDS linklib with the qextops program
as a member.
6. You can STEPLIB to this library or choose to move the program to one of the LINKLIBs that are in
the LINKLST. The program does not require authorization.
7. Following the upload, copy the program to an existing link listed library or add a STEPLIB DD
statement with the correct data set name of the library that contains the program.
8. The qextops_jcl.txt file is a text file that contains a sample JCL. You must configure the job card to
meet your configuration.
The qextops_jcl.txt sample file includes:
//QEXTOPS JOB (T,JXPO,JKSD0093),DEV,NOTIFY=Q1JACK,
// MSGCLASS=P,
// REGION=0M
//*
//*QEXTOPS JCL version 1.0 September, 2010
//*
//*************************************************************
//* Change below dataset names to sites specific datasets names*
//************************************************************
//SET1 SET TSSOUT=’Q1JACK.EARLOUT.ALL’,
// EARLOUT=’Q1JACK.QEXTOPS.PROGRAM.OUTPUT’
//************************************************************
//* Delete old datasets *
//************************************************************//
DEL EXEC PGM=IEFBR14
//DD1 DD DISP=(MOD,DELETE),DSN=&TSSOUT,
// UNIT=SYSDA,
// SPACE=(CYL,(10,10)),
// DCB=(RECFM=FB,LRECL=80)
//DD2 DD DISP=(MOD,DELETE),DSN=&EARLOUT,
// UNIT=SYSDA,
// SPACE=(CYL,(10,10)),
// DCB=(RECFM=FB,LRECL=80)
//************************************************************
//* Allocate new dataset *
//************************************************************
//ALLOC EXEC PGM=IEFBR14
//DD1 DD DISP=(NEW,CATLG),DSN=&EARLOUT,
// SPACE=(CYL,(100,100)),
// DCB=(RECFM=VB,LRECL=1028,BLKSIZE=6144)
//************************************************************
//* Execute Top Secret TSSUTIL utility to extract smf records*
//************************************************************
30 CA Technologies
199
//REPORT EXEC PGM=TSSUTIL
//SMFIN DD DISP=SHR,DSN=&SMFIN1
//SMFIN1 DD DISP=SHR,DSN=&SMFIN2
//UTILOUT DD DSN=&UTILOUT,
// DISP=(,CATLG),UNIT=SYSDA,SPACE=(CYL,(50,10),RLSE),
// DCB=(RECFM=FB,LRECL=133,BLKSIZE=0)
//EARLOUT DD DSN=&TSSOUT,
// DISP=(NEW,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(200,100),RLSE),
// DCB=(RECFM=VB,LRECL=456,BLKSIZE=27816)
//UTILIN DD *
NOLEGEND
REPORT EVENT(ALL) END
/*
//************************************************************
//EXTRACT EXEC PGM=QEXTOPS,DYNAMNBR=10,
// TIME=1440
//STEPLIB DD DISP=SHR,DSN=Q1JACK.C.LOAD
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//CFG DD DUMMY
//EARLIN DD DISP=SHR,DSN=&TSSOUT
//EARLOUT DD DISP=SHR,DSN=&EARLOUT
//************************************************************
//FTP EXEC PGM=FTP,REGION=3800K
//INPUT DD *
<IPADDR>
<USER>
<PASSWORD>
PUT ’<EARLOUT>’ EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<QUIT
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
9. After the output file is created, schedule a job to a transfer the output file to an interim FTP server.
The output file is forwarded to an interim FTP server.
You must configure the following parameters in the sample JCL to successfully forward the output
to an interim FTP server:
Example:
//FTP EXEC PGM=FTP,REGION=3800K
//INPUT DD *
<IPADDR>
<USER>
<PASSWORD>
PUT ’<EARLOUT>’ EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<EARLOUT>
QUIT
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
Where:
<IPADDR> is the IP address or host name of the interim FTP server to receive the output file.
<USER> is the user name that is needed to access the interim FTP server.
<PASSWORD> is the password that is needed to access the interim FTP server.
<THEIPOFTHEMAINFRAMEDEVICE> is the destination of the mainframe or interim FTP server that
receives the output.
Example:
PUT ’xxxxxx.xxxxxxx.OUTPUT.C320’ /<IP_address>/CA/QEXTOPS.OUTPUT.C320
<QEXOUTDSN> is the name of the output file that is saved to the interim FTP server.
You are now ready to configure the Log File protocol.
10. Schedule QRadar to collect the output file from CA Top Secret.
200
QRadar DSM Configuration Guide
If the zOS platform is configured to serve files through FTP, SFTP, or allow SCP, then no interim FTP
server is needed and QRadar can pull the output file directly from the mainframe. The following text
must be commented out using //* or deleted from the qextops_jcl.txt file:
//FTP EXEC PGM=FTP,REGION=3800K
//INPUT DD *
<IPADDR>
<USER>
<PASSWORD>
PUT ’<EARLOUT>’ EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<EARLOUT>
QUIT
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
What to do next
You are now ready to configure the log source in QRadar.
30 CA Technologies
201
202
QRadar DSM Configuration Guide
31 Carbon Black
Several Carbon Black DSMs can be integrated with IBM Security QRadar
Carbon Black
The IBM Security QRadar DSM for Carbon Black collects endpoint protection events from a Carbon Black
server.
The following table describes the specifications for the Carbon Black DSM:
Table 105. Carbon Black DSM specifications
Specification
Value
Manufacturer
Carbon Black
DSM name
Carbon Black
RPM file name
DSM-CarbonBlackCarbonBlack-Qradar_versionbuild_number.noarch.rpm
Supported versions
5.1 and later
Protocol
Syslog
Recorded event types
Watchlist hits
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Carbon Black website (https://www.carbonblack.com/
products/cb-response/)
To integrate Carbon Black with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Carbon Black DSM RPM
v DSMCommon RPM
2. Configure your Carbon Black device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a Carbon Black log source on the QRadar
Console. The following table describes the parameters that require specific values for Carbon Black
event collection:
Table 106. Carbon Black log source parameters
Parameter
Value
Log Source type
Carbon Black
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
© Copyright IBM Corp. 2005, 2018
203
your network devices or appliances.
Configuring Carbon Black to communicate with QRadar
To collect events from Carbon Black, you must install and configure cb-event-forwarder to send Carbon
Black events to IBM Security QRadar.
Before you begin
Install the Carbon Black Enterprise RPM and ensure that it is running. You can install the
cb-event-forwarder on any 64-bit Linux computer that is running CentOS 6.x. It can be installed on the
same computer as the Carbon Black server, or on another computer. If you are forwarding many events,
for example, all file modifications, registry modifications, or both, to QRadar, install cb-event-forwarder
on a separate server. If you are not forwarding many events to QRadar, you can install the
cb-event-forwarder on the Carbon Black server.
If you are installing the cb-event-forwarder on a computer other than the Carbon Black server, you must
configure the Carbon Black server:
1. Ensure that TCP port 5004 is open through the iptables firewall on the Carbon Black server. The
event-forwarder connects to TCP port 5004 on the Carbon Black server to connect to the Cb message
bus.
2. Get the RabbitMQ user name and password from the /etc/cb/cb.conf file on the Carbon Black
server. Search for the RabbitMQUser and RabbitMQPassword variables and note their values.
About this task
You can find the following instructions, source code, and quick start guide on the GitHub website
(https://github.com/carbonblack/cb-event-forwarder/).
Procedure
1. If it is not already installed, install the CbOpenSource repository:
cd /etc/yum.repos.d
curl -O https://opensource.carbonblack.com/release/x86_64/CbOpenSource.repo
2. Install the RPM for cb-event-forwarder:
yum install cb-event-forwarder
3. Modify the /etc/cb/integrations/event-forwarder/cb-event-forwarder.conf file to include
udpout=<QRadar_IP_address>:514, and then specify LEEF as the output format: output_format=leef.
4. If you are installing on a computer other than the Carbon Black server, copy the RabbitMQ user name
and password into the rabbit_mq_username and rabbit_mq_password variables in the
/etc/cb/integrations/event-forwarder/cb-event-forwarder.conf file. In the cb_server_hostname
variable, enter the host name or IP address of the Carbon Black server.
5. Ensure that the configuration is valid by running the cb-event-forwarder in check mode:
/usr/share/cb/integrations/event-forwarder/cb-event-forwarder -check.
If valid, the message Initialized output displays. If there are errors, the errors are printed to your
screen.
6. Choose the type of event that you want to capture.
By default, Carbon Black publishes the all feed and watchlist events over the bus. If you want to
capture raw sensor events or all binaryinfo notifications, you must enable those features in the
/etc/cb/cb.conf file.
v To capture raw sensor events, edit the DatastoreBroadcastEventTypes option in the
/etc/cb/cb.conf file to enable broadcast of the raw sensor events that you want to export.
v To capture binary observed events, edit the EnableSolrBinaryInfoNotifications option in the
/etc/cb/cb.conf file and set it to True.
204
QRadar DSM Configuration Guide
7. If any variables were changed in /etc/cb/cb.conf, restart the Carbon Black server: "service
cb-enterprise restart".
8. Start the cb-event-forwarder service by using the initctl command: initctl start
cb-event-forwarder.
Note: You can stop the cb-event-forwarder service by using the initctl command: initctl stop
cb-event-forwarder.
Carbon Black Protection
The IBM Security QRadar DSM for Carbon Black Protection receives logs from a Carbon Black Protection
device.
The following table identifies the specifications for the Carbon Black Protection DSM:
Table 107. Carbon Black Protection DSM Specifications
Specification
Value
Manufacturer
Carbon Black
DSM name
Carbon Black Protection
RPM filename
DSM-CarbonBlackProtection-QRadar_versionbuild_number.noarch.rpm
Supported versions
8.0.0, 8.1.0
Protocol
Syslog
Event format
LEEF
Recorded event types
Computer Management, Server Management, Session
Management, Policy Management, Policy Enforcement,
Internal Events, General Management, Discovery
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
https://www.carbonblack.com/products/carbon-blackenterprise-protection/
1. If automatic updates are not configured, download the most recent version of the following RPMs on
your QRadar Console
v DSMCommon RPM
v Carbon Black Protection DSM RPM
2. Enable the Carbon Black Protection console to communicate with QRadar.
3. If QRadar does not automatically detect the log source, add a Carbon Black Protection log source on
the QRadar Console. The following table describes the parameters that require specific values for
Carbon Black Protection event collection:
Table 108. Carbon Black Protection log source parameters
Parameter
Value
Log source type
Carbon Black Protection
Log source identifier
IP address or host name for the log source
Protocol configuration
Syslog
4. Verify that Carbon Black Protection is configured correctly.
The following table provides a sample event message for the Carbon Black Protection DSM:
31 Carbon Black
205
Table 109. Carbon Black Protection sample message supported by the Carbon Black Protection device
Event name
Low level category
Sample log message
Console user login
User login success
LEEF:1.0|
Carbon_Black|Protection|
8.0.0.2141|
Console_user_login|
cat=Session Management
sev=4
devTime=Mar 09 2017
18:32:14.360
UTC msg=User
’<Username>’ logged in from
<IP_address>.
externalId=12345
src=<Source_IP_address>
usrName=<Username>
dstHostName=hostname
receivedTime=Mar 09 2017
18:32:14.360 UTC
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Carbon Black Protection to communicate with QRadar
Enable the Carbon Black Protection console to communicate with QRadar.
Procedure
1. Access the Carbon Black Protection console by entering the Carbon Black Protection server URL in
your browser.
2. On the login screen, enter your username and password. You must use a Carbon Black Protection
account with Administrator or Power User privileges.
3. From the top console menu, select System Configuration in the Administration section.
4. On the System Configuration page, click on the Events tab.
5. On the External Events Logging section, click Edit. Enter the QRadar Event Collector IP address in the
Syslog address field and enter 514 for the Syslog port field.
6. Change the Syslog format to LEEF (Q1Labs).
7. Check Syslog Enabled for Syslog output.
8. Click Update to confirm the changes.
Bit9 Parity
To collect events, you must configure your Bit9 Parity device to forward syslog events in Log Event
Extended Format (LEEF).
Procedure
1. Log in to the Bit9 Parity console with Administrator or PowerUser privileges.
2. From the navigation menu on the left side of the console, select Administration > System
Configuration.
The System Configuration window is displayed.
3. Click Server Status.
206
QRadar DSM Configuration Guide
The Server Status window is displayed.
4. Click Edit.
5. In the Syslog address field, type the IP address of your QRadar Console or Event Collector.
6. From the Syslog format list, select LEEF (Q1Labs).
7. Select the Syslog enabled check box.
8. Click Update.
The configuration is complete. The log source is added to IBM Security QRadar as Bit9 Parity events
are automatically discovered. Events that are forwarded to QRadar by Bit9 Parity are displayed on the
Log Activity tab of QRadar.
Configure a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Bit9 Parity.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Bit9 Security Platform.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 110. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Bit9 Parity device.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Bit9 Security Platform
Use the IBM Security QRadar SIEM DSM for Bit9 Security Platform to collect events from Bit9 Parity
devices.
The following table identifies the specifications for the Bit9 Security Platform DSM:
Table 111. DSM specifications for Bit9 Security Platform
Specification
Value
Manufacturer
Carbon Black
DSM name
Bit9 Security Platform
31 Carbon Black
207
Table 111. DSM specifications for Bit9 Security Platform (continued)
Specification
Value
RPM file name
DSM-Bit9Parity-build_number.noarch.rpm
Supported versions
V6.0.2 and up
Event format
Syslog
Supported event types
All events
Automatically discovered?
Yes
Included identity?
Yes
More information
Bit9 website (http://www.bit9.com)
To integrate Bit9 Security Platform with QRadar, complete the following steps:
1. If automatic updates are not enabled, download the most recent version of the Bit9 Security Platform
DSM RPM.
2. Configure your Bit9 Security Platform device to enable communication with QRadar. You must create
a syslog destination and forwarding policy on the Bit9 Security Platform device.
3. If QRadar does not automatically detect Bit9 Security Platform as a log source, create a Bit9 Security
Platform log source on the QRadar Console. Use the following Bit9 Security Platform values to
configure the log source parameters:
Log Source Identifier
The IP address or host name of the Bit9 Security
Platform device
Log Source Type
Bit9 Security Platform
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Bit9 Security Platform to communicate with QRadar
Configure your Bit9 Security Platform device to forward events to IBM Security QRadar in LEEF format.
Procedure
1. Log in to the Bit9 Security Platform console with Administrator or PowerUser privileges.
2. From the navigation menu, select Administration > System Configuration.
3. Click Server Status and click Edit.
4. In the Syslog address field, type the IP address of your QRadar Console or Event Collector.
5. From the Syslog format list, select LEEF (Q1Labs).
6. Select the Syslog enabled check box and click Update.
208
QRadar DSM Configuration Guide
32 Centrify
IBM Security QRadar supports a range of Centrify devices.
Centrify Identity Platform
The IBM Security QRadar DSM for Centrify Identity Platform collects logs from a Centrify Identity
Platform.
To integrate Centrify Identity Platform with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Protocol Common RPM
v Centrify Redrock REST API Protocol RPM
v DSMCommon RPM
v Centrify Identity Platform DSM RPM
2. Configure your Centrify Identity Platform to communicate with QRadar.
3. Add a Centrify Identity Platform log source on the QRadar Console. The following table describes the
Centrify Redrock REST API protocol parameters that require specific values to collect events from
Centrify Identity Platform:
Table 112. Centrify Redrock REST API protocol log source parameters
Parameter
Value
Log Source type
Centrify Identity Platform
Protocol Configuration
Centrify Redrock REST API
Log Source Identifier
Type a unique name for the log source.
The Log Source Identifier can be any valid value and
does not need to reference a specific server. The Log
Source Identifier can be the same value as the Log
Source Name. If you have more than one Centrify
Identity Platform log source that is configured, you
might want to identify the first log source as centrify1,
the second log source as centrify2, and the third log
source as centrify3.
Tenant ID
The Centrify assigned unique customer or tenant ID.
Username
The user name that is associated with the Cloud service
for Centrify Identity Platform.
Password
The password that is associated with the Centrify
Identity Platform user name.
Event Logging Filter
Select the logging level of the events that you want to
retrieve. Info, Warning and Error are selectable. At least
one filter must be selected.
Use Proxy
When a proxy is configured, all traffic from the Centrify
Redrock REST API travels through the proxy.
Configure the Proxy Server, Proxy Port, Proxy
Username, and Proxy Password fields. If the proxy does
not require authentication, you can leave the Proxy
Username and Proxy Password fields blank.
© Copyright IBM Corp. 2005, 2018
209
Table 112. Centrify Redrock REST API protocol log source parameters (continued)
Parameter
Value
Automatically Acquire Server Certificate(s)
Select Yes for QRadar to automatically download the
server certificate and begin trusting the target server.
EPS Throttle
The maximum number of events per second.
The default is 5000.
Recurrence
The time interval can be in hours (H), minutes (M) or
days (D).
The default is 5 minutes (5M).
Related concepts:
“Centrify Identity Platform DSM specifications”
The following table describes the specifications for the Centrify Identity Platform DSM.
“Sample event message” on page 212
Use this sample event message as a way of verifying a successful integration with QRadar.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Configuring Centrify Identity Platform to communicate with QRadar” on page 211
To send events to QRadar from your Centrify Identity Platform, create a user role and configure a user
policy on your Centrify Identity Platform. The QRadar user can then create a log source in QRadar.
Centrify Identity Platform DSM specifications
The following table describes the specifications for the Centrify Identity Platform DSM.
Table 113. Centrify Identity Platform DSM specifications
Specification
Value
Manufacturer
Centrify
DSM name
Centrify Identity Platform
RPM file name
DSM-CentrifyIdentityPlatform-QRadar_versionbuild_number.noarch.rpm
Supported versions
N/A
Protocol
Centrify Redrock REST API
Event format
JSON
Recorded event types
SaaS
Core
Internal
Mobile
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
210
QRadar DSM Configuration Guide
Table 113. Centrify Identity Platform DSM specifications (continued)
Specification
Value
More information
Centrify website (https://www.centrify.com/whycentrify/centrify-identity-platform)
Configuring Centrify Identity Platform to communicate with QRadar
To send events to QRadar from your Centrify Identity Platform, create a user role and configure a user
policy on your Centrify Identity Platform. The QRadar user can then create a log source in QRadar.
Before you begin
Ensure that you have the Tenant ID and admin login details that are supplied by Centrify. Ensure that
you have the correct user permissions for the Centrify admin portal to complete the following steps:
Procedure
1. Log in to your Centrify Identity Platform admin portal.
2. Create a Centrify Identity Platform user role:
a. From the navigation pane, click Roles > Add Role.
b. In the Name field, type the name for the role.
c. Select Members, and then click Add.
d. In the Add Members window, search for the user name to assign to the role, and then select the
member.
e. Click Add.
f. Select Administrative Rights, and then click Add.
g. From the Description list, select Read Only System Administrator.
h. Click Save.
3. Create an authentication profile:
a. From the navigation pane, click Settings > Authentication.
b. From the Platform menu, click Authentication Profiles.
c. Click Add Profile, and then type a name for the profile in the Profile Name field.
d. From the Challenge 1 pane in the Authentication Mechanisms window, select Password.
e. From the Challenge Pass-Through Duration list, select 30 minutes, and then click OK. The
default is 30 minutes.
Important: Do not select any options from the Challenge 2 pane in the Authentication
Mechanisms window. Select options only from the Challenge 1 pane.
4. Configure a user policy:
a. From the navigation pane, click Policies > Add Policy Set.
b. From the Policy Setting pane, type a name for the policy in the Name field.
c. From the Policy Assignment pane, click Specified Roles.
d. Click Add.
e. From the Select Role window, select the role that you created in Step 2 from the Role list, and then
click Add.
f. From the Policy Settings menu, select Login Policies > Centrify Portal.
g. From the Enable authentication policy controls window, select Yes.
h. From the Default Profile pane, select the authentication profile that you created in Step 3 from the
Default Profile list.
32 Centrify
211
i. Click Save.
Note: If you have difficulty when configuring your Centrify Identity Platform to communicate with
QRadar, contact your Centrify administrator or your Centrify contact.
Sample event message
Use this sample event message as a way of verifying a successful integration with QRadar.
The following table provides a sample event message when using the Centrify Identity Platform REST
API protocol for the Centrify Identity Platform DSM:
Table 114. Centrify Identity Platform sample message supported by Centrify Identity Platform.
Event name
Low level category
Sample log message
Cloud.Core.Login.
MultiFactorChallenge
User Login Attempt
{"RequestIsMobileDevice": false,
"AuthMethod": "MultiAuth","Level":
"Error","UserGuid": "c2c7bcc6-9560
-44e0-8dff-5be221cd37ee","Mechanism"
: "EMail","Tenant": "AAM0428",
"FromIPAddress": "<IP_address>","ID"
: "772c2e1908a4f11b.W03.c5ab.a93685
2233b2232d","RequestDeviceOS":
"Windows","EventType": "Cloud.Core.
Login.MultiFactorChallenge","Request
HostName": "192.0.2.1","ThreadType":
"RestCall","UserName": "username
@example.com","NormalizedUser":
"username@example.com","WhenLogged":
"/Date(1472679431199)/","When
Occurred": "/Date(1472679431199)/"
,"Target": "username@example.com"}
Centrify Infrastructure Services
The IBM Security QRadar DSM for Centrify Infrastructure Services collects events from Centrify
Infrastructure Services standard logs.
The following table describes the specifications for the Centrify Infrastructure Services DSM:
Table 115. Centrify Infrastructure Services DSM specifications
Specification
Value
Manufacturer
Centrify
DSM name
Centrify Infrastructure Services
RPM file name
DSM-CentrifyInfrastructureServicesQRadar_version-build_number.noarch.rpm
Supported versions
Centrify Infrastructure Services 2017
Protocol
Syslog, TLS Syslog and WinCollect
Event format
name-value pair (NVP)
Recorded event types
Audit Events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Centrify website (https://www.centrify.com/support/
documentation/server-suite/)
212
QRadar DSM Configuration Guide
To integrate Centrify Infrastructure Services with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of Centrify
Infrastructure Services DSM RPM on your QRadar Console.
Note: If you use the WinCollect protocol configuration option, install the latest WinCollect agent
bundle (.sfs file) on your QRadar Console.
2. To send syslog or Windows events to QRadar, configure your UNIX, Linux, or Windows device
where the Centrify Infrastructure Services standard logs are available.
3. If QRadar does not automatically detect the log source, add a Centrify Infrastructure Services log
source on the QRadar Console.
The following table describes the parameters that require specific values to collect events from
Centrify Infrastructure Services:
Table 116. Centrify Infrastructure Services log source parameters
Parameter
Value
Log Source type
Centrify Infrastructure Services
Protocol Configuration
Syslog
Log Source Identifier
The IP address or host name of the UNIX, Linux, or
Windows device that sends Centrify Infrastructure
Services events to QRadar.
4. Optional: To add a Centrify Infrastructure Services log source to receive Syslog events from network
devices that support TLS Syslog event forwarding, configure the log source on the QRadar Console to
use the TLS Syslog protocol.
Table 117. Centrify Infrastructure Services TLS Syslog log source parameters
Parameter
Value
Log Source type
Centrify Infrastructure Services
Protocol Configuration
TLS Syslog
Log Source Identifier
Type a unique identifier for the log source.
TLS Protocols
Select the version of TLS that is installed on the client.
Note: To receive encrypted Syslog events from up to 50 network devices that support TLS Syslog
event forwarding, configure a log source to use the TLS Syslog protocol.
Related concepts:
“TLS syslog protocol configuration options” on page 48
Configure a TLS Syslog protocol log source to receive encrypted syslog events from up to 1000 network
devices that support TLS Syslog event forwarding.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring WinCollect agent to collect event logs from Centrify
Infrastructure Services
You can forward Windows events to IBM Security QRadar by using WinCollect.
32 Centrify
213
To forward Windows events by using WinCollect, install WinCollect agent on a Windows host. Download
the WinCollect agent setup file from the IBM Support website (https://www.ibm.com/support). Add a
Centrify Infrastructure Services log source and assign it to the WinCollect agent.
The following table describes the values that are required for the WinCollect log source parameters.
Table 118. WinCollect log source parameters
Parameter
Value
Log Source type
Centrify Infrastructure Services
Protocol Configuration
WinCollect
Log Source Identifier
The IP address or host name of the Windows machine
from which you want to collect Windows events. The log
source identifier must be unique for the log source type.
Local System
Select the Local System check box to disable the remote
collection of events for the log source. The log source
uses local system credentials to collect and forward logs
to QRadar.
You need to configure the Domain, Username, and
Password parameters if remote collection is required.
Event Rate Tuning Profile
For the default polling interval of 3000 ms, the
approximate Events per second (EPS) rates attainable are
as follows:
v Default (Endpoint): 33-50 EPS
v Typical Server: 166-250 EPS
v High Event Rate Server: 416-625 EPS
For a polling interval of 1000 ms, the approximate EPS
rates are as follows:
v Default (Endpoint): 100-150 EPS
v Typical Server: 500-750 EPS
v High Event Rate Server: 1250-1875 EPS
For more information about tuning WinCollect, go to the
IBM Support website (http://www.ibm.com/support/
docview.wss?uid=swg21672193).
Polling Interval (ms)
The interval, in milliseconds, between times when
WinCollect polls for new events.
Application or Service Log Type
Select None for the Application or Service Log Type.
Standard Log Types
Do not enable the check box for any of the log types.
Select No Filtering as the log filter type for the following
log types: Security, System, Application, DNS Server,
File Replication Service, and Directory Service.
Event Types
214
QRadar DSM Configuration Guide
You must select at least one event type.
Table 118. WinCollect log source parameters (continued)
Parameter
Value
XPath Query
To forward only Centrify Audit events, you must specify
the XPath filter. The query is in XML format and can be
created by using Custom View Properties of Microsoft
Event Viewer.
For more information about creating an XPath query, go
to the Creating a custom view documentation on the
IBM Support website (https://www.ibm.com/support/
knowledgecenter/SS42VS_7.3.0/com.ibm.wincollect.doc/
t_ug_wincollect_creating_customview.html).
Important: When you create the custom view, ensure
that the By Source option is selected. From the Event
sources list, select the application name of the Centrify
Audit Events.
Example XPath query:
<QueryList>
<Query Id="0" Path="Application">
<SelectPath="Application">*[System
[Provider[@Name=’Centrify AuditTrail
V2’]]]</Select>
</Query>
</QueryList>
Enable Active Directory Lookups
Do not select the check box.
WinCollectAgent
Select your WinCollect agent from the list.
Target Internal Destination
Use any managed host with an event processor
component as an internal destination.
For more information about WinCollect log source parameters, go to the Common WinCollect log source
parameters documentation on the IBM Support website (https://www.ibm.com/support/
knowledgecenter/SS42VS_7.2.6/com.ibm.wincollect.doc/r_ug_wincollect_comon_parameters.html).
Configuring Centrify Infrastructure Services on a UNIX or Linux device
to communicate with QRadar
You can configure your UNIX or Linux device to send audit events to IBM Security QRadar. The audit
events are available locally in the syslog event logs where the Centrify Infrastructure Services is installed
and configured.
Procedure
1. Log in to your Centrify Infrastructure Services device.
2. Ensure that syslog or rsyslog is installed:
v To verify that syslog is installed, type service syslog status.
v To verify that rsyslog is installed, type service rsyslog status.
3. If syslog or rsyslog is not installed, install them by using your preferred method based on your UNIX
or Linux device. For example, you can type the following command to install rsyslog on a Linux
device:
yum install rsyslog
4. To forward events to your QRadar Event Collector, open the rsyslog.conf file or the syslog.conf file
that is located in /etc/ directory, and then add the following line:
:msg, contains, "AUDIT_TRAIL" @@<QRadar Event Collector IP>:514
32 Centrify
215
Example: :msg, contains, "AUDIT_TRAIL" @@127.0.0.1:514
5. Restart the syslog or rsyslog service:
v If you are using syslog, type service syslog restart.
v If you are using rsyslog, type service rsyslog restart.
Note: The Centrify Linux agent might forward some Linux system messages with the Audit Trail
logs. If no specific category is found, the Linux OS log source type in QRadar discovers the Linux
messages and normalizes them as stored.
Sample event messages
Use these sample event messages as a way of verifying a successful integration with QRadar.
The following table shows sample event messages from Centrify Infrastructure Services:
Table 119. Centrify Infrastructure Services sample message
Event name
Low-level category
Sample log message
Remote login success
Remote Access Login Succeeded
<13>May 09 20:58:48
127.1.1.1 AgentDevice=WindowsLog
AgentLogFile=Application Plugin
Version=7.2.6.39 Source=Centrify
AuditTrail V2 Computer=Centrify
WindowsAgent.Centrify.lab
OriginatingComputer=127.1.1.1
User=user Domain
=CENTRIFY EventID=1234 EventID
Code=1234 EventType=4 Event
Category=4 RecordNumber=1565
TimeGenerated=1494374321
TimeWritten=1494374321
Level=Informational Keywords=
ClassicTask=None Opcode=Info
Message=Product: Centrify
Suite Category: Direct
Authorize - Windows Event name:
Remote login success Message:
User successfully logged on
remotely using role ’Windows
Login/CentrifyTest’. May 09
16:58:41 centrifywindowsagent.
centrify.lab dzagent[2008]:
INFO AUDIT_TRAIL|Centrify Suite
|DirectAuthorize - Windows|
1.0|3|Remote login success|5
|user=username userSid=domain
\username sessionId=6 centrify
EventID=6003 DAInst=N/A DASess
ID=N/A role=Windows Login/
CentrifyTest desktopguid=7678b3
5e-00d0-4ddf-88f5-6626b8b1ec4b
The user logged in to the
system successfully
User Login Success
<38>May 4 23:45:19
hostname adclient[1472]: INFO AUDIT
_TRAIL|Centrify Suite|Centrify
Commands|1.0|200|The user login
to the system successfully|5|user
=user pid=1234 utc=1493952319951
centrifyEventID=18200 DASessID=
c6b7551c-31ea-8743-b870cdef47393d07 DAInst=Default
Installation status=SUCCESS service
=sshd tty=/dev/pts/2
216
QRadar DSM Configuration Guide
33 Check Point
Several Check Point products can be integrated with IBM Security QRadar.
The following products are supported:
v Firewall
v SmartDefense
v IPS
v Anti Malware
v Anti-Bot
v Antivirus
v Mobile Access
v DDoS Protector
v Security Gateway/Management
v Threat Emulation
v URL Filtering
v DLP
v Application Control
v Identity Logging
v VPN
v Endpoint Security
Check Point
You can configure IBM Security QRadar to integrate with a Check Point device by employing one of
several methods.
Employ one of the following methods:
v “Integration of Check Point by using OPSEC”
v “Integrate Check Point by using syslog” on page 224
v “Integration of Check Point Firewall events from external syslog forwarders” on page 226
Note: Depending on your Operating System, the procedures for the Check Point device might vary. The
following procedures are based on the Check Point SecurePlatform Operating system.
Integration of Check Point by using OPSEC
This section describes how to ensure that IBM Security QRadar accepts Check Point events using Open
Platform for Security (OPSEC/LEA).
To integrate Check Point OPSEC/LEA with QRadar, you must create two Secure Internal Communication
(SIC) files and enter the information in to QRadar as a Check Point log source.
Check Point configuration overview
To integrate Check Point with QRadar, you must complete the following procedures in sequence:
1. Add QRadar as a host for Check Point.
2. Add an OPSEC application to Check Point.
© Copyright IBM Corp. 2005, 2018
217
3. Locate the Log Source Secure Internal Communications DN.
4. In QRadar, configure the OPSEC LEA protocol.
5. Verify the OPSEC/LEA communications configuration.
Adding a Check Point Host
You can add IBM Security QRadar as a host in Check Point SmartCenter:
Procedure
1. Log in to the Check Point SmartCenter user interface.
2. Select Objects > New Host.
3. Enter the information for your Check Point host:
v Object Name: QRadar
v IP address: IP address of QRadar
4. Click OK.
What to do next
You are now ready to create an OPSEC Application Object for Check Point.
Creating an OPSEC Application Object
After you add IBM Security QRadar as a host in Check Point SmartCenter, you can create the OPSEC
Application Object.
Procedure
1. Open the Check Point SmartConsole user interface.
2. Select Objects > More Object Types > Server > OPSEC Application > New Application.
3. Configure your OPSEC Application:
a. Configure the following OPSEC Application Properties parameters.
Table 120. OPSEC Application Properties
Parameter
Value
Name
QRadar-OPSEC
Host
QRadar
Client Entities
LEA
b. Click Communication.
c. In the One-time password field, type the password that you want to use.
d. In the Confirm one-time password field, type the password that you used for One-time
password.
e. Click Initialize.
f. Click Close.
4. Select Menu > Install Policy
5. Click Publish & Install.
6. Click Install.
7. Select Menu > Install Database.
8. Click Install.
218
QRadar DSM Configuration Guide
Note: The SIC value is required for the OPSEC Application Object SIC attribute parameter when you
configure the Check Point log source in QRadar. The value can be found by viewing the OPSEC
Application Object after it is created.
The OPSEC Application Object resembles the following example:
CN=QRadar=OPSEC,0=cpmodule..tdfaaz
Results
If you have issues after you install the database policy, contact your system administrator to restart Check
Point services on the central SmartCenter server that hosts the policy files. After services restart, the
updated policies are pushed to all Check Point appliances.
Locating the log source SIC
After you create the OPSEC Application Object, you can locate the Log Source SIC from the Check Point
SmartConsole.
Procedure
1. Select Objects > Object Explorer.
2. In the Categories tree, select Gateways and Servers under Networks Objects.
3. Select your Check Point Log Host object.
4. Copy the Secure Internal Communication (SIC).
Important: Depending on your Check Point version, the Communication button displays the SIC
attribute. You can locate the SIC attribute from the Check Point Management Server command-line
interface. You must use the cpca_client lscert command from the command-line interface of the
Management Server to display all certificates.
Important: The Log Source SIC Attribute resembles the following example:
cn=cp_mgmt,o=cpmodule...tdfaaz. For more information, see your Check Point Command Line Interface
Guide.
You must now install the Security Policy from the Check Point SmartConsole user interface.
What to do next
You are now ready to configure the OPSEC LEA protocol.
Configuring an OPSEC/LEA log source in IBM Security QRadar
After you locate the Log Source SIC, you configure the OPSEC LEA protocol:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for your log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select Check Point.
8. Using the Protocol Configuration list, select OPSEC/LEA.
9. Configure the following values:
33 Check Point
219
Table 121. OPSEC/LEA protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address for the log source. This value must
match the value that is configured in the Server IP
parameter.
The log source identifier must be unique for the log
source type.
Server IP
Type the IP address of the Check Point host or Check
Point Management Server IP.
Server Port
Type the port number that is used for OPSEC
communication.
Administrators must ensure that the existing firewall
policy allows the LEA/OPSEC connection from your
QRadar.
Use Server IP for Log Source
Select the check box to use the LEA server's IP address
instead of the managed device's IP address for a log
source. All events that are received by QRadar are
funneled into a single log source. Clear the check box to
have all events that are forwarded by Check Point
Management Server to go into their individual log
sources. By default, this parameter is enabled.
Statistics Report Interval
Type the interval, in seconds, during which the number
of syslog events are recorded in the QRadar.log file.
The valid range is 4 - 2,147,483,648 and the default is
600.
Authentication Type
From the list, select the Authentication Type that you
want for this LEA configuration.
The options are as follows:
v sslca (default)
v sslca_clear
v clear
This value must match the authentication method that is
configured on the Check Point Firewall or Check Point
custom log management server.
OPSEC Application Object SIC Attribute (SIC Name)
Type the Secure Internal Communications (SIC) name of
the OPSEC Application Object.
The SIC name is the distinguished name (DN) of the
application, for example: CN=LEA, o=fwconsole..7psasx.
Log Source SIC Attribute (Entity SIC Name)
Type the SIC name for the server that generates log
sources.
Example: cn=cp_mgmt,o=fwconsole..7psasx.
Specify Certificate
Select the Specify Certificate check box to define a
certificate for this LEA configuration.
Certificate Filename
Type the file name of the certificate that you want to use
for this configuration. The certificate file must be located
in the /opt/qradar/conf/trusted_certificates/lea
directory.
Certificate Authority IP
Type the IP address of the SmartCenter server from
which you want to pull your certificate.
220
QRadar DSM Configuration Guide
Table 121. OPSEC/LEA protocol parameters (continued)
Parameter
Description
Pull Certificate Password
Type the password that you want to use when you
request a certificate.
OPSEC Application
Type the name of the application you want to use when
you request a certificate. This value can be up to 255
characters in length.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
What to do next
You are now ready to verify your OPSEC/LEA communications for Check Point.
Edit your OPSEC communications configuration
This section describes how to modify your Check Point configuration to allow OPSEC communications
on non-standard ports.
It also explains how to configure communications in a clear text, unauthenticated stream, and verify the
configuration in IBM Security QRadar.
Change your Check Point Custom Log Manager (CLM) IP address
If your Check Point configuration includes a Check Point Custom Log Manager (CLM), you might
eventually need to change the IP address for the CLM, which impacts any of the automatically
discovered Check Point log sources from that CLM in QRadar. When you manually add the log source
for the CLM by using the OPSEC/LEA protocol, all Check Point firewalls that forward logs to the CLM
are automatically discovered by QRadar. These automatically discovered log sources cannot be edited. If
the CLM IP address changes, you must edit the original Check Point CLM log source that contains the
OPSEC/LEA protocol configuration and update the server IP address and log source identifier.
After you update the log source for the new Check Point CLM IP address, then any new events reported
from the automatically discovered Check Point log sources are updated.
Important: Do not delete and re-create your Check Point CLM or automatically discovered log sources in
QRadar. Deleting a log source does not delete event data, but can make finding previously recorded
events more difficult.
Updating your Check Point OPSEC log source
You can update your Check Point OPSEC log source.
Procedure
1. Log in to IBM Security QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Select the original Check Point CLM log source that contains the OPSEC/LEA protocol configuration
and click Edit.
6. In the Log Source Identifier field, type a new identifying name of your Check Point CLM.
7. In the Server IP field, type the new IP address of your Check Point CLM.
8. Click Save.
33 Check Point
221
The IP address update for your Check Point CLM in IBM Security QRadar is complete.
Changing the default port for OPSEC LEA communication
Change the default port (18184) on which OPSEC LEA communicates.
Procedure
1. At the command-line prompt of your Check Point SmartCenter Server, type the following command
to stop the firewall services:
cpstop
2. Depending on your Check Point SmartCenter Server operating system, open the following file:
v Linux - $FWDIR\conf\fwopsec.conf
v Windows - %FWDIR%\conf\fwopsec.conf
The default contents of this file are as follows:
#
#
#
#
#
#
The VPN-1 default settings are:
# sam_server auth_port 0 # sam_server port 18183
# lea_server auth_port 18184 # lea_server port 0
# ela_server auth_port 18187 # ela_server port 0
# cpmi_server auth_port 18190
# uaa_server auth_port 19191 # uaa_server port 0 #
3. Change the default lea_server auth_port from 18184 to another port number.
4. Remove the hash (#) mark from that line.
Example:
lea_server auth_port 18888 # lea_server port 0
5. Save and close the file.
6. Type the following command to start the firewall services:
cpstart
Configuring OPSEC LEA for unencrypted communications
You can configure the OPSEC LEA protocol for unencrypted communications:
Procedure
1. At the command-line prompt of your Check Point SmartCenter Server, stop the firewall services by
typing the following command:
cpstop
2. Depending on your Check Point SmartCenter Server operating system, open the following file:
v Linux - $FWDIR\conf\fwopsec.conf
v Windows - %FWDIR%\conf\fwopsec.conf
3. Change the default lea_server auth_port from 18184 to 0.
4. Change the default lea_server port from 0 to 18184.
5. Remove the hash (#) marks from both lines.
Example:
lea_server auth_port 0 lea_server port 18184
6. Save and close the file.
7. Type the following command to start the firewall services:
cpstart
222
QRadar DSM Configuration Guide
Configuring IBM Security QRadar to receive events from a Check Point device
Configure IBM Security QRadar to receive events from a Check Point device.
Procedure
1.
2.
3.
4.
Login to QRadar.
Click the Admin tab.
On the navigation menu, click Data Sources.
Click the Log Sources icon.
5. Click Add.
6. From the Log Source Type list, select Check Point.
7. Using the Protocol Configuration list, select OPSEC/LEA.
8. Configure the following parameters:
Table 122. OPSEC/LEA protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address for the log source. This value must match the value that is
configured in the Server IP parameter.
The log source identifier must be unique for the log source type.
Server IP
Type the IP address of the server.
Server Port
Type the port number that is used for OPSEC communication. The valid range is
0 - 65,536 and the default port used by QRadar is 18184.
Use Server IP for Log Source
Select the Use Server IP for Log Source check box if you want to use the LEA
server IP address instead of the managed device IP address for a log source. By
default, the check box is selected.
Statistics Report Interval
Type the interval, in seconds, during which the number of syslog events are
recorded in the QRadar .log file. The valid range is 4 - 2,147,483,648 and the
default is 600.
33 Check Point
223
Table 122. OPSEC/LEA protocol parameters (continued)
Parameter
Description
Authentication Type
From the list, select the Authentication Type that you want to use for this LEA
configuration. The options are sslca (default), sslca_clear, or clear. This value
must match the authentication method that is used by the server. The following
parameters appear if sslca or sslca_clear is selected as the authentication type:
v OPSEC Application Object SIC Attribute (SIC Name) - Type the Secure
Internal Communications (SIC) name of the OPSEC Application Object. The SIC
name is the distinguished name (DN) of the application, for example: CN=LEA,
o=fwconsole..7psasx. The name can be up to 255 characters in length and is
case-sensitive.
v Log Source SIC Attribute (Entity SIC Name) - Type the SIC name of the
server, for example: cn=cp_mgmt,o=fwconsole..7psasx. The name can be up to
255 characters in length and is case-sensitive.
v Specify Certificate - Select this check box if you want to define a certificate for
this LEA configuration. QRadar attempts to retrieve the certificate by using
these parameters when the certificate is needed.
If you select the Specify Certificate check box, the Certificate Filename parameter
is displayed:
v Certificate Filename - This option appears only if Specify Certificate is
selected. Type the file name of the certificate that you want to use for this
configuration. The certificate file must be located in the /opt/qradar/conf/
trusted_certificates/lea directory.
If you clear the Specify Certificate check box, the following parameters appear:
v Certificate Authority IP - Type the IP address of the SmartCenter server from
which you want to pull your certificate.
v Pull Certificate Password - Type the password that you want to use when you
request a certificate. The password can be up to 255 characters in length.
v OPSEC Application - Type the name of the application you want to use when
you request a certificate. This value can be up to 255 characters in length.
Important: Access to port 18210 is required for certificate pulls.
9. Click Save.
10. On the Admin tab, click Deploy Changes.
Integrate Check Point by using syslog
This section describes how to ensure that the IBM Security QRadar Check Point DSMs accept Check Point
events with syslog.
Before you configure IBM Security QRadar to integrate with a Check Point device, you must take the
following steps:
Important: If Check Point SmartCenter is installed on Microsoft Windows, you must integrate Check
Point with QRadar by using OPSEC.
1. Type the following command to access the Check Point console as an expert user:
expert
A password prompt appears.
2. Type your expert console password. Press the Enter key.
3. Open the following file:
/etc/rc.d/rc3.d/S99local
4. Add the following lines:
224
QRadar DSM Configuration Guide
$FWDIR/bin/fw log -ftn | /usr/bin/logger -p <facility>.<priority> /dev/null 2>&1 &
Where:
v <facility> is a syslog facility, for example, local3.
v <priority> is a syslog priority, for example, info.
For example:
$FWDIR/bin/fw log -ftn | /usr/bin/logger -p local3.info > /dev/null 2>&1 &
5. Save and close the file.
6. Open the syslog.conf file.
7. Add the following line:
<facility>.<priority> <TAB><TAB>@<host>
Where:
v <facility> is the syslog facility, for example, local3. This value must match the value that you typed
in Step 4.
v <priority> is the syslog priority, for example, info or notice. This value must match the value that
you typed in Step 4.
<TAB> indicates you must press the Tab key.
<host> indicates the QRadar Console or managed host.
8. Save and close the file.
9. Enter the following command to restart syslog:
v In Linux: service syslog restart
v In Solaris: /etc/init.d/syslog start
10. Enter the following command:
nohup $FWDIR/bin/fw log -ftn | /usr/bin/logger -p <facility>.<priority> > /dev/null 2>&1 &
Where:
v <facility> is a Syslog facility, for example, local3. This value must match the value that you typed
in Step 4.
v <priority> is a Syslog priority, for example, info. This value must match the value that you typed
in Step 4.
The configuration is complete. The log source is added to QRadar as Check Point syslog events are
automatically discovered. Events that are forwarded to QRadar are displayed on the Log Activity tab.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Check
Point. The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Check Point.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
33 Check Point
225
Table 123. Syslog parameters
Parameter
Value
Log Source Identifier
The IP address or host name for the log source, which is
used as an identifier for the events that are forwarded
from your Check Point appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
Integration of Check Point Firewall events from external syslog
forwarders
Check Point Firewall events can be forwarded from external sources, such as Splunk Forwarders, or other
third-party syslog forwarders that send events to IBM Security QRadar.
When Check Point Firewall events are provided from external sources in syslog format, the events
identify with the IP address in the syslog header. This identification causes events to identify incorrectly
when they are processed with the standard syslog protocol. The syslog redirect protocol provides
administrators a method to substitute an IP address from the event payload into the syslog header to
correctly identify the event source.
To substitute an IP address, administrators must identify a common field from their Check Point Firewall
event payload that contains the proper IP address. For example, events from Splunk Forwarders use
orig= in the event payload to identify the original IP address for the Check Point firewall. The protocol
substitutes in the proper IP address to ensure that the device is properly identified in the log source. As
Check Point Firewall events are forwarded, QRadar automatically discovers and create new log sources
for each unique IP address.
Substitutions are that are performed with regular expressions and can support either TCP or UDP syslog
events. The protocol automatically configures iptables for the initial log source and port configuration. If
an administrator decides to change the port assignment a Deploy Full Configuration is required to
update the iptables configuration and use the new port assignment.
Configuring a log source for Check Point forwarded events
To collect raw events that are forwarded from an external source, you must configure a log source before
events are forwarded to IBM Security QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. From the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for your log source.
8. From the Log Source Type list, select Check Point.
9. From the Protocol Configuration list, select Syslog Redirect.
10. Configure the following values:
226
QRadar DSM Configuration Guide
Table 124. Syslog redirect protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as
an identifier for the Check Point Firewall events.
The log source identifier must be unique value.
Log Source Identifier Regex
Type the regular expression (regex) needed to identify
the Check Point Firewall IP address from the event
payload.
Example: Administrators can use the following regular
expression to parse Check Point Firewall events that are
provided by Splunk Forwarders.
orig=(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})
Perform DNS Lookup On Regex Match
Select the Perform DNS Lookup On Regex Match check
box to enable DNS functionality, which is based on the
Log Source Identifier parameter value.
By default, the check box is not selected.
Listen Port
Type the port number that is used by QRadar to accept
incoming syslog redirect events.
The default listen port is 517.
The port number that you configure must match the port
that you configured on the appliance that forwards the
syslog events. Administrators cannot specify port 514 in
this field.
Protocol
From the list, select either UDP or TCP.
The syslog redirect protocol supports any number of
UDP syslog connections, but restricts TCP connections to
2500. If the syslog stream has more than 2500 log
sources, you must enter a second Check Point log source
and listen port number.
Enabled
Select this check box to enable the log source. By default,
the check box is selected.
Credibility
From the list, select the Credibility of the log source. The
range is 0 - 10.
The credibility indicates the integrity of an event or
offense as determined by the credibility rating from the
source devices. Credibility increases if multiple sources
report the same event. The default is 5.
Target Event Collector
From the list, select the Target Event Collector to use as
the target for the log source.
Coalescing Events
Select the Coalescing Events check box to enable the log
source to coalesce (bundle) events.
By default, automatically discovered log sources inherit
the value of the Coalescing Events list from the System
Settings in QRadar. When you create a log source or edit
an existing configuration, you can override the default
value by configuring this option for each log source.
Incoming Event Payload
From the Incoming Event Payload list, select the
incoming payload encoder for parsing and storing the
logs.
33 Check Point
227
Table 124. Syslog redirect protocol parameters (continued)
Parameter
Description
Store Event Payload
Select the Store Event Payload check box to enable the
log source to store event payload information.
By default, automatically discovered log sources inherit
the value of the Store Event Payload list from the
System Settings in QRadar. When you create a log source
or edit an existing configuration, you can override the
default value by configuring this option for each log
source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
Check Point Multi-Domain Management (Provider-1)
You can configure IBM Security QRadar to integrate with a Check Point Multi-Domain Management
(Provider-1) device.
All events from Check Point Multi-Domain Management (Provider-1) are parsed by using the Check
Point Multi-Domain Management (Provider-1) DSM. You can integrate Check Point Multi-Domain
Management (Provider-1) using one of the following methods:
v “Integrating syslog for Check Point Multi-Domain Management (Provider-1)”
v “Configuring OPSEC for Check Point Multi-Domain Management (Provider-1)” on page 229
Note: Depending on your Operating System, the procedures for using the Check Point Multi-Domain
Management (Provider-1) device can vary. The following procedures are based on the Check Point
SecurePlatform operating system.
Integrating syslog for Check Point Multi-Domain Management
(Provider-1)
This method ensures that the Check Point Multi-Domain Management (Provider-1) DSM for IBM Security
QRadar accepts Check Point Multi-Domain Management (Provider-1) events by using syslog.
About this task
QRadar records all relevant Check Point Multi-Domain Management (Provider-1) events.
Configure syslog on your Check Point Multi-Domain Management (Provider-1) device:
Procedure
1. Type the following command to access the console as an expert user:
expert
A password prompt is displayed.
2. Type your expert console password. Press the Enter key.
3. Type the following command:
csh
4. Select the wanted customer logs:
mdsenv <customer name>
5. Input the following command:
# nohup $FWDIR/bin/fw log -ftn | /usr/bin/logger -p <facility>.<priority> 2>&1 &
228
QRadar DSM Configuration Guide
Where:
v <facility> is a syslog facility, for example, local3.
v <priority> is a syslog priority, for example, info.
You are now ready to configure the log source in QRadar.
The configuration is complete. The log source is added to QRadar as the Check Point Multi-Domain
Management Provider-1 syslog events are automatically discovered. Events that are forwarded to
QRadar are displayed on the Log Activity tab.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Check Point
Multi-Domain Management (Provider-1) as Check Point FireWall-1 events.
About this task
The following configuration steps are optional. To manually configure a log source for Check Point
Multi-Domain Management (Provider-1) syslog events:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Check Point Firewall-1.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 125. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as
an identifier for events from your Check Point
Multi-Domain Management (Provider-1) appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
Configuring OPSEC for Check Point Multi-Domain Management
(Provider-1)
This method ensures that the IBM Security QRadar Check Point FireWall-1 DSM accepts Check Point
Multi-Domain Management (Provider-1) events by using OPSEC.
33 Check Point
229
About this task
In the Check Point Multi-Domain Management (Provider-1) Management Domain GUI (MDG), create a
host object that represents the QRadar. The leapipe is the connection between the Check Point
Multi-Domain Management (Provider-1) and QRadar.
To reconfigure the Check Point Multi-Domain Management (Provider-1) SmartCenter (MDG):
Procedure
1. To create a host object, open the Check Point SmartDashboard user interface and select Manage >
Network Objects > New > Node > Host.
2. Type the Name, IP address, and write comments if needed.
3. Click OK.
4. Select Close.
5. To create the OPSEC connection, select Manage > Servers and OPSEC Applications > New >
OPSEC Application Properties.
6. Type a Name, and write comments if needed.
The Name that you enter must be different than the name used in Step 2.
7. From the Host drop-down menu, select the QRadar host object that you created.
8. From Application Properties, select User Defined as the Vendor type.
9. From Client Entries, select LEA.
10. To configure the Secure Internal Communication (SIC) certificate, click Communication and enter an
activation key.
11. Select OK and then Close.
12. To install the Policy on your firewall, select Policy > Install > OK.
Configuring an OPSEC log source
You can configure the log source in IBM Security QRadar:
Procedure
1. Login to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. From the Log Source Type list, select Check Point FireWall-1.
7. Using the Protocol Configuration list, select OPSEC/LEA.
The OPSEC/LEA protocol parameters are displayed
8. Log Source Name - Type a name for the log source.
9. Log Source Identifier - Type the IP address for the log source. This value must match the value that
you typed in the Server IP parameter.
10. Server IP - Type the IP address of the Check Point Multi-Domain Management (Provider-1).
11. Server Port - Type the Port number that is used for OPSEC/LEA. The default is 18184.
You must ensure that the existing firewall policy allows the LEA/OPSEC connection from your
QRadar.
230
QRadar DSM Configuration Guide
12. OPSEC Application Object SIC Attribute - Type the SIC DN of the OPSEC Application Object.
13. Log Source SIC Attribute - Type the SIC Name for the server that generates the log source.
SIC attribute names can be up to 255 characters in length and are case-sensitive.
14. Specify Certificate - Ensure that the Specify Certificate check box is clear.
15. Pull Certificate Password - Type the activation key password.
16. Certificate Authority IP - Type the Check Point Manager Server IP address.
17. OPSEC Application - Type the name of the OPSEC Application that requests a certificate.
Example: If the value is CN=QRadar-OPSEC,O=cpmodule...tdfaaz, the OPSEC Application value is
QRadar-OPSEC
18. Click Save.
19. On the Admin tab, click Deploy Changes.
Related concepts:
“OPSEC/LEA protocol configuration options” on page 34
To receive events on port 18184, configure a log source to use the OPSEC/LEA protocol.
33 Check Point
231
232
QRadar DSM Configuration Guide
34 Cilasoft QJRN/400
IBM Security QRadar collects detailed audit events from Cilasoft QJRN/400® software for IBM i.
To collect events, administrators can configure Cilasoft QJRN/400 to forward events with syslog, or
optionally configure the integrated file system (IFS) to write events to a file. Syslog provides real-time
events to QRadar and provides automatic log source discovery for administrators, which is the easiest
configuration method for event collection. The IFS option provides an optional configuration to write
events to a log file, which can be read remotely by using the log file protocol. QRadar supports syslog
events from Cilasoft QJRN/400 V5.14.K and later.
To configure Cilasoft QJRN/400, complete the following tasks:
1. On your Cilasoft QJRN/400 installation, configure the Cilasoft Security Suite to forward syslog events
to QRadar or write events to a file.
2. For syslog configurations, administrators can verify that the events forwarded by Cilasoft QJRN/400
are automatically discovered on the Log Activity tab.
Cilasoft QJRN/400 configurations that use IFS to write event files to disk are considered an alternative
configuration for administrators that cannot use syslog. IFS configurations require the administrator to
locate the IFS file and configure the host system to allow FTP, SFTP, or SCP communications. A log source
can then be configured to use the log file protocol with the location of the event log file.
Configuring Cilasoft QJRN/400
To collect events, you must configure queries on your Cilasoft QJRN/400 to forward syslog events to IBM
Security QRadar.
Procedure
1. To start the Cilasoft Security Suite, type the following command:
IJRN/QJRN
The account that is used to make configuration changes must have ADM privileges or USR privileges
with access to specific queries through an Extended Access parameter.
2. To configure the output type, select one of the following options:
To edit several selected queries, type 2EV to access the Execution Environment and change the Output
Type field and type SEM.
3. To edit large numbers of queries, type the command CHGQJQRYA and change the Output Type field and
type SEM.
4. On the Additional Parameters screen, configure the following parameters:
Table 126. Cilasoft QJRN/400 output parameters
Parameter
Description
Format
Type *LEEF to configure the syslog output to write events
in Log Extended Event Format (LEEF).
LEEF is a special event format that is designed to for
IBM Security QRadar.
© Copyright IBM Corp. 2005, 2018
233
Table 126. Cilasoft QJRN/400 output parameters (continued)
Parameter
Description
Output
To configure an output type, use one of the following
parameters to select an output type:
*SYSLOG - Type this parameter to forward events with the
syslog protocol. This option provides real-time events.
*IFS - Type this parameter to write events to a file with
the integrated file system. This option requires the
administrator to configure a log source with the log file
protocol. This option writes events to a file, which can be
read in only 15-minute intervals.
IP Address
Enter the IP address of your IBM Security QRadar
system.
If an IP address for IBM Security QRadar is defined as a
special value in the WRKQJVAL command, you can type
*CFG.
Events can be forwarded to either the QRadar Console,
an Event Collector, an Event Processor, or your IBM
Security QRadar all-in-one appliance.
Type 514 or *CFG as the port for syslog events.
Port
By default, *CFG automatically selects port 514.
Tag
This field is not used by IBM Security QRadar.
Facility
This field is not used by IBM Security QRadar.
Severity
Select a value for the event severity.
For more information about severity that is assigned to
*QRY destinations, look up the command WRKQJFVAL
in your Cilasoft documentation.
For more information on Cilasoft configuration parameters, see the Cilasoft QJRN/400 User's Guide.
Syslog events that are forwarded to IBM Security QRadar are viewable on the Log Activity tab.
Configuring a Cilasoft QJRN/400 log source
IBM Security QRadar automatically discovers and creates a log source for syslog events that are
forwarded from Cilasoft QJRN/400.
About this task
These configuration steps are optional.
Procedure
1. Log in to IBM Security QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for your log source.
6. From the Log Source Type list, select Cilasoft QJRN/400.
7. From the Protocol Configuration list, select Syslog.
234
QRadar DSM Configuration Guide
Note: If Cilasoft QJRN/400 is configured to write events to the integrated file system with the *IFS
option, the administrator must select Log File, and then configure the log file protocol.
8. Configure the protocol values.
Learn more about syslog protocol parameters:
Table 127. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Enter the IP address as an identifier for events from your
Cilasoft QJRN/400 installation.
The Log Source Identifier must be unique value.
Enabled
Select the Enabled check box to enable the log source.
By default, the check box is selected.
Credibility
Select the Credibility of the log source. The range is 0 10.
The credibility indicates the integrity of an event or
offense as determined by the credibility rating from the
source devices. Credibility increases if multiple sources
report the same event. The default is 5.
Target Event Collector
Select the Target Event Collector to use as the target for
the log source.
Coalescing Events
Select this check box to enable the log source to coalesce
(bundle) events.
By default, automatically discovered log sources inherit
the value of the Coalescing Events list from the System
Settings in IBM Security QRadar. When you create a log
source or edit an existing configuration, you can override
the default value by configuring this option for each log
source.
Incoming Event Payload
From the list, select the Incoming Event Payload encoder
for parsing and storing the logs.
Store Event Payload
Select the Store Event Payload check box to enable the
log source to store event payload information.
By default, automatically discovered log sources inherit
the value of the Store Event Payload list from the
System Settings in IBM Security QRadar. When you
create a log source or edit an existing configuration, you
can override the default value by configuring this option
for each log source.
9. Click Save.
10. On the Admin tab, click Deploy Changes.
Related concepts:
“Log File protocol configuration options” on page 22
To receive events from remote hosts, configure a log source to use the Log File protocol.
34 Cilasoft QJRN/400
235
236
QRadar DSM Configuration Guide
35 Cisco
Several Cisco DSMs can be integrated with IBM Security QRadar.
Cisco ACE Firewall
The Cisco ACE firewall can be integrated with IBM Security QRadar.
QRadar can accept events that are forwarded from Cisco ACE Firewalls by using syslog. QRadar records
all relevant events. Before you configure QRadar to integrate with an ACE firewall, you must configure
your Cisco ACE Firewall to forward all device logs to QRadar.
Configuring Cisco ACE Firewall
To forward Cisco ACE device logs to IBM Security QRadar:
Procedure
1. Log in to your Cisco ACE device.
2. From the Shell Interface, select Main Menu > Advanced Options > Syslog Configuration.
3. The Syslog Configuration menu varies depending on whether there are any syslog destination hosts
configured yet. If no syslog destinations are configured, create one by selecting the Add First Server
option. Click OK.
4. Type the host name or IP address of the destination host and port in the First Syslog Server field.
Click OK.
The system restarts with new settings. When finished, the Syslog server window displays the host
that is configured.
5. Click OK.
The Syslog Configuration menu is displayed. Notice that options for editing the server configuration,
removing the server, or adding a second server are now available.
6. If you want to add another server, click Add Second Server.
At any time, click the View Syslog options to view existing server configurations.
7. To return to the Advanced menu, click Return.
The configuration is complete. The log source is added to QRadar as Cisco ACE Firewall events are
automatically discovered. Events that are forwarded to QRadar by Cisco ACE Firewall appliances are
displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco ACE
Firewalls.
About this task
The following configuration steps are optional. You can manually create a log source for QRadar to
receive syslog events.
To manually configure a log source for Cisco ACE Firewall:
© Copyright IBM Corp. 2005, 2018
237
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco ACE Firewall.
9. From the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 128. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco ACE Firewalls.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco Aironet
You can integrate Cisco Aironet devices with IBM Security QRadar.
About this task
A Cisco Aironet DSM accepts Cisco Emblem Format events by using syslog. Before you configure QRadar
to integrate with a Cisco Aironet device, you must configure your Cisco Aironet appliance to forward
syslog events.
To configure Cisco Aironet to forward events:
Procedure
1. Establish a connection to the Cisco Aironet device by using one of the following methods:
v Telnet to the wireless access point
v Access the console
2. Type the following command to access privileged EXEC mode:
enable
3. Type the following command to access global configuration mode:
config terminal
4. Type the following command to enable message logging:
logging on
5. Configure the syslog facility. The default is local7.
logging <facility>
238
QRadar DSM Configuration Guide
where <facility> is, for example, local7.
6. Type the following command to log messages to your QRadar:
logging <IP address>
where <IP address> is IP address of your QRadar.
7. Enable timestamp on log messages:
service timestamp log datatime
8. Return to privileged EXEC mode:
end
9. View your entries:
show running-config
10. Save your entries in the configuration file:
copy running-config startup-config
The configuration is complete. The log source is added to QRadar as Cisco Aironet events are
automatically discovered. Events that are forwarded to QRadar by Cisco Aironet appliances are
displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco
Aironet.
About this task
The following configuration steps are optional. To manually configure a log source for Cisco Aironet:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Aironet.
9. From the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 129. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco Aironet appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
35 Cisco
239
Cisco ACS
The Cisco ACS DSM for IBM Security QRadar accepts syslog ACS events by using syslog and UDP
multiline.
QRadar records all relevant and available information from the event. You can integrate Cisco ACS with
QRadar by using one of the following methods:
v Configure your Cisco ACS device to directly send syslog to QRadar for Cisco ACS v5.x. See
“Configuring Syslog for Cisco ACS v5.x.”
v Configure your Cisco ACS device to directly send syslog to QRadar for Cisco ACS v4.x. See
“Configuring Syslog for Cisco ACS v4.x” on page 242.
v Configure your Cisco ACS device to directly send UDP multiline syslog to QRadar. See “Configuring
UDP multiline syslog for Cisco ACS appliances” on page 52
Note: QRadar supports only Cisco ACS versions earlier than v3.x using a Universal DSM.
Configuring Syslog for Cisco ACS v5.x
The configuration of syslog forwarding from a Cisco ACS appliance with software version 5.x involves
several steps.
About this task
You must complete the following tasks:
Procedure
1. Create a Remote Log Target
2. Configure global logging categories
3. Configure a log source
Creating a Remote Log Target
Creating a remote log target for your Cisco ACS appliance.
Log in to your Cisco ACS appliance.
On the navigation menu, click System Administration > Configuration > Log Configuration > Remote
Log Targets.
The Remote Log Targets page is displayed.
Click Create.
Configure the following parameters:
Table 130. Remote target parameters
Parameter
Description
Name
Type a name for the remote syslog target.
Description
Type a description for the remote syslog target.
Type
Select Syslog.
IP address
Type the IP address of QRadar or your Event Collector.
Click Submit.
240
QRadar DSM Configuration Guide
You are now ready to configure global policies for event logging on your Cisco ACS appliance.
Configuring global logging categories
To configure Cisco ACS to forward log failed attempts to IBM Security QRadar:
Procedure
1. On the navigation menu, click System Administration > Configuration > Log Configuration >
Global.
The Logging Categories window is displayed.
2. Select the Failed Attempts logging category and click Edit.
3. Click Remote Syslog Target.
4. From the Available targets window, use the arrow key to move the syslog target for QRadar to the
Selected targets window.
5. Click Submit.
You are now ready to configure the log source in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco ACS
v5.x.
About this task
However, you can manually create a log source for QRadar to receive Cisco ACS events.
To manually configure a log source for Cisco ACS:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. From the Log Source Type list, select Cisco ACS.
7. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
8. Configure the following values:
Table 131. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for Cisco ACS
events.
9. Click Save.
10. On the Admin tab, click Deploy Changes.
The configuration is complete.
35 Cisco
241
Configuring Syslog for Cisco ACS v4.x
The configuration of syslog forwarding from a Cisco ACS appliance with software version 4.x involves a
few steps.
About this task
Complete the following steps:
Procedure
1. Configure syslog forwarding
2. Configure a log source
Configuring syslog forwarding for Cisco ACS v4.x
Configuration of an ACS device to forward syslog events to IBM Security QRadar.
About this task
Take the following steps to configure the ACS device to forward syslog events to QRadar
Procedure
1. Log in to your Cisco ACS device.
2. On the navigation menu, click System Configuration.
The System Configuration page opens.
3. Click Logging.
The logging configuration is displayed.
4. In the Syslog column for Failed Attempts, click Configure.
The Enable Logging window is displayed.
5. Select the Log to Syslog Failed Attempts report check box.
6. Add the following Logged Attributes:
v Message-Type
v User-Name
v Nas-IP-Address
v Authen-Failure-Code
v Caller-ID
v NAS-Port
v Author-Data
v Group-Name
v Filter Information
v Logged Remotely
7. Configure the following syslog parameters:
Table 132. Syslog parameters
Parameter
Description
IP
Type the IP address of QRadar.
Port
Type the syslog port number of IBM Security QRadar. The default is port 514.
Max message length (Bytes) - Type 1024 as the maximum syslog message length.
Type
242
QRadar DSM Configuration Guide
Note: Cisco ACS provides syslog report information for a maximum of two syslog servers.
8. Click Submit.
You are now ready to configure the log source in QRadar.
Configuring a log source for Cisco ACS v4.x
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco ACS
v4.x.
About this task
The following configuration steps are optional.
To manually create a log source for Cisco ACS v4.x, take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. From the Log Source Type list, select Cisco ACS.
7. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
8. Configure the following values:
Table 133. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for Cisco ACS
events.
9. Click Save.
10. On the Admin tab, click Deploy Changes.
The configuration is complete.
Configuring UDP multiline syslog for Cisco ACS appliances
The Cisco ACS DSM for IBM Security QRadar accepts syslog events from Cisco ACS appliances with log
sources that are configured to use the UDP Multiline Syslog protocol.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the Data Sources section, click the Log Sources icon, and then click Add.
4. In the Log Source Name field, type a name for your log source.
5. From the Log Source Type list, select Cisco ACS.
6. From the Protocol Configuration list, select UDP Multiline Syslog.
7. Configure the parameters:
35 Cisco
243
The following parameters require specific values to collect events from Cisco ACS appliances:
Table 134. Cisco ACS log source parameters
Parameter
Value
Log Source Identifier
Type the IP address, host name, or name to identify your
Cisco ACS appliance.
Listen Port
The default port number that is used by QRadar to
accept incoming UDP Multiline Syslog events is 517. You
can use a different port. The valid port range is 1 - 65535.
To edit a saved configuration to use a new port number,
complete the following steps.
1. In the Listen Port field, type the new port number
for receiving UDP Multiline Syslog events.
2. Click Save.
The port update is complete and event collection starts
on the new port number.
Message ID Pattern
\s(\d{10})\s
Event Formatter
Select Cisco ACS Multiline from the list.
Related concepts:
“UDP multiline syslog protocol configuration options” on page 50
To create a single-line syslog event from a multiline event, configure a log source to use the UDP
multiline protocol. The UDP multiline syslog protocol uses a regular expression to identify and
reassemble the multiline syslog messages into single event payload.
Cisco ASA
You can integrate a Cisco Adaptive Security Appliance (ASA) with IBM Security QRadar.
A Cisco ASA DSM accepts events through syslog or NetFlow by using NetFlow Security Event Logging
(NSEL). QRadar records all relevant events. Before you configure QRadar, you must configure your Cisco
ASA device to forward syslog or NetFlow NSEL events.
Choose one of the following options:
v Forward events to QRadar by using syslog. See “Integrate Cisco ASA Using Syslog”
v Forward events to QRadar by using NetFlow (NSEL). See “Integrate Cisco ASA for NetFlow by using
NSEL” on page 246
Integrate Cisco ASA Using Syslog
Integrating Cisco ASA by using syslog involves the configuration of a log source, and syslog forwarding.
Complete the following tasks to integrate Cisco ASA by using syslog:
v “Configuring syslog forwarding”
v “Configuring a log source” on page 245
Configuring syslog forwarding
To configure Cisco ASA to forward syslog events, some manual configuration is required.
Procedure
1. Log in to the Cisco ASA device.
2. Type the following command to access privileged EXEC mode:
244
QRadar DSM Configuration Guide
enable
3. Type the following command to access global configuration mode:
conf t
4. Enable logging:
logging enable
5. Configure the logging details:
logging console warning
logging trap warning
logging asdm warning
Note: The Cisco ASA device can also be configured with logging trap informational to send
additional events. However, this may increase the event rate (Events Per Second) of your device.
6. Type the following command to configure logging to IBM Security QRadar:
logging host <interface> <IP address>
Where:
v
<interface> is the name of the Cisco Adaptive Security Appliance interface.
v
<IP address> is the IP address of QRadar.
Note: Using the command show interfaces displays all available interfaces for your Cisco device.
7. Disable the output object name option:
no names
Disable the output object name option to ensure that the logs use IP addresses and not the object
names.
8. Exit the configuration:
exit
9. Save the changes:
write mem
Results
The configuration is complete. The log source is added to QRadar as Cisco ASA syslog events are
automatically discovered. Events that are forwarded to QRadar by Cisco ASA are displayed on the Log
Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco ASA.
The following configuration steps are optional.
About this task
To manually configure a log source for Cisco ASA syslog events:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
35 Cisco
245
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Adaptive Security Appliance (ASA).
9. From the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 135. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your OSSEC installations.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Integrate Cisco ASA for NetFlow by using NSEL
Integrating Cisco ASA for Netflow by using NSEL involves two steps.
This section includes the following topics:
v “Configuring NetFlow Using NSEL”
v “Configuring a log source” on page 247
Configuring NetFlow Using NSEL
You can configure Cisco ASA to forward NetFlow events by using NSEL.
Procedure
1. Log in to the Cisco ASA device command-line interface (CLI).
2. Type the following command to access privileged EXEC mode:
enable
3. Type the following command to access global configuration mode:
conf t
4. Disable the output object name option:
no names
5. Type the following command to enable NetFlow export:
flow-export destination <interface-name> <ipv4-address or hostname> <udp-port>
Where:
v <interface-name> is the name of the Cisco Adaptive Security Appliance interface for the NetFlow
collector.
v <ipv4-address or hostname> is the IP address or host name of the Cisco ASA device with the
NetFlow collector application.
v <udp-port> is the UDP port number to which NetFlow packets are sent.
Note: IBM Security QRadar typically uses port 2055 for NetFlow event data on QRadar QFlow
Collectors. You must configure a different UDP port on your Cisco Adaptive Security Appliance for
NetFlow by using NSEL.
246
QRadar DSM Configuration Guide
6. Type the following command to configure the NSEL class-map:
class-map flow_export_class
7. Choose one of the following traffic options:
To configure a NetFlow access list to match specific traffic, type the command:
match access-list flow_export_acl
8. To configure NetFlow to match any traffic, type the command:
match any
Note: The Access Control List (ACL) must exist on the Cisco ASA device before you define the
traffic match option in “Configuring NetFlow Using NSEL” on page 246.
9. Type the following command to configure the NSEL policy-map:
policy-map flow_export_policy
10. Type the following command to define a class for the flow-export action:
class flow_export_class
11. Type the following command to configure the flow-export action:
flow-export event-type all destination <IP address>
Where <IP address> is the IP address of QRadar.
Note: If you are using a Cisco ASA version before v8.3 you can skip“Configuring NetFlow Using
NSEL” on page 246 as the device defaults to the flow-export destination. For more information, see
your Cisco ASA documentation.
12. Type the following command to add the service policy globally:
service-policy flow_export_policy global
13. Exit the configuration:
exit
14. Save the changes:
write mem
You must verify that your collector applications use the Event Time field to correlate events.
Configuring a log source
To integrate Cisco ASA that uses NetFlow with IBM Security QRadar, you must manually create a log
source to receive NetFlow events.
About this task
QRadar does not automatically discover or create log sources for syslog events from Cisco ASA devices
that use NetFlow and NSEL.
Note: Your system must be running the current version of the NSEL protocol to integrate with a Cisco
ASA device that uses NetFlow and NSEL. The NSEL protocol is available on IBM Support,
http://www.ibm.com/support, or through auto updates in QRadar.
To configure a log source:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
35 Cisco
247
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Adaptive Security Appliance (ASA).
9. Using the Protocol Configuration list, select Cisco NSEL.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 136. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source.
Collector Port
Type the UDP port number that is used by Cisco ASA to forward NSEL events. The
valid range of the Collector Port parameter is 1-65535.
QRadar typically uses port 2055 for NetFlow event data on the QRadar QFlow
Collector. You must define a different UDP port on your Cisco Adaptive Security
Appliance for NetFlow that uses NSEL.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are forwarded to QRadar by Cisco ASA are
displayed on the Log Activity tab. For more information on configuring NetFlow with your Cisco
ASA device, see your vendor documentation.
Cisco CallManager
The Cisco CallManager DSM for IBM Security QRadar collects application events that are forwarded from
Cisco CallManager devices that are using Syslog.
Before events can be received in QRadar, you must configure your Cisco Call Manager device to forward
events. After you forward Syslog events from Cisco CallManager, QRadar automatically detects and adds
Cisco CallManager as a log source.
Configuring syslog forwarding
You can configure syslog on your Cisco CallManager:
Procedure
1. Log in to your Cisco CallManager interface.
2. Select System Enterprise > Parameters.
The Enterprise Parameters Configuration is displayed.
3. In the Remote Syslog Server Name field, type the IP address of the QRadar Console.
4. From the Syslog Severity For Remote Syslog messages list, select Informational.
The Informational severity selection allows the collection of all events at the information level and
later.
5. Click Save.
6. Click Apply Config.
248
QRadar DSM Configuration Guide
The syslog configuration is complete. You are now ready to configure a syslog log source for Cisco
CallManager.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco
CallManager devices.
About this task
The following configuration steps are optional. To manually configure a syslog log source for Cisco
CallManager take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Call Manager.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 137. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco CallManager.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco CatOS for Catalyst Switches
The Cisco CatOS for Catalyst Switches DSM for IBM Security QRadar accepts events by using syslog.
QRadar records all relevant device events. Before you configure a Cisco CatOS device in QRadar, you
must configure your device to forward syslog events.
Configuring syslog
Configuring your Cisco CatOS device to forward syslog events.
About this task
Take the following steps to configure your Cisco CatOS device to forward syslog events:
35 Cisco
249
Procedure
1. Log in to your Cisco CatOS user interface.
2. Type the following command to access privileged EXEC mode:
enable
3. Configure the system to timestamp messages:
set logging timestamp enable
4. Type the following command with the IP address of IBM Security QRadar:
set logging server <IP address>
5. Limit messages that are logged by selecting a severity level:
set logging server severity <server severity level>
6. Configure the facility level to be used in the message. The default is local7.
set logging server facility <server facility parameter>
7. Enable the switch to send syslog messages to the QRadar.
set logging server enable
You are now ready to configure the log source in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco
CatOS appliances.
About this task
The following configuration steps are optional.
To manually configure a syslog log source for Cisco CatOS:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco CatOS for Catalyst Switches.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 138. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events
from your Cisco CatOS for Catalyst Switch appliance.
11. Click Save.
250
QRadar DSM Configuration Guide
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco Cloud Web Security
The IBM Security QRadar DSM for Cisco Cloud Web Security (CWS) collects web usage logs from a Cisco
Cloud Web Security (CWS) storage by using an Amazon S3 - compatible API.
The following table describes the specifications for the Cisco Cloud Web Security DSM:
Table 139. Cisco Cloud Web Security DSM specifications
Specification
Value
Manufacturer
Cisco
DSM name
Cisco Cloud Web Security
RPM file name
DSM-CiscoCloudWebSecurity-QRadar_versionbuild_number.noarch.rpm
Supported versions
N/A
Protocol
Amazon AWS S3 REST API
Event format
W3C
Recorded event types
All web usage logs
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Cisco CWS product information (https://
www.cisco.com/go/cws)
To integrate Cisco Cloud Web Security with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs, in the order that they are listed, on your QRadar Console:
v Protocol Common RPM
v Amazon AWS REST API Protocol RPM
v DSMCommon RPM
v Cisco Cloud Web Security DSM RPM
2. Enable Log Extraction in your Cisco ScanCenter (administration portal).
3. Add a Cisco Cloud Web Security log source on the QRadar Console. The following table describes the
parameters that require specific values for Cisco Cloud Web Security event collection:
Table 140. Cisco Cloud Web Security log source parameters
Parameter
Value
Log Source type
Cisco Cloud Web Security
Protocol Configuration
Amazon AWS S3 REST API
Log Source Identifier
The Log Source Identifier can be any valid value and
does not need to reference a specific server. The Log
Source Identifier can be the same value as the Log
Source Name. If you configured more than one Cisco
CWS log source, you might want to identify the first log
source as ciscocws1, the second log source as ciscocws2,
and the third log source as ciscocws13.
35 Cisco
251
Table 140. Cisco Cloud Web Security log source parameters (continued)
Parameter
Value
Signature Version
Select Signature Version 2.
If your Cisco CWS API is using Signature Version 4,
contact your system administrator.
Region Name (Signature V4 only)
The region that is associated with the Amazon S3 bucket.
Service Name (Signature V4 only)
Type s3. The name of the Amazon Web Service.
Bucket Name
The name of the Cisco CWS bucket where the log files
are stored.
Endpoint URL
https://vault.scansafe.com/
Public Key
The access key to enable log extraction from the Cisco
CWS bucket.
Access Key
The secret key to enable log extraction from the Cisco
CWS bucket.
Directory Prefix
The location of the root directory on the Cisco CWS
storage bucket from where the Cisco CWS logs are
retrieved. For example, the root directory location might
be cws-logs/.
File Pattern
.*?\.txt\.gz
Event Format
W3C. The log source retrieves W3C text formatted
events.
Use Proxy
When a proxy is configured, all traffic for the log source
travels through the proxy so that QRadar can access the
Amazon AWS S3 buckets.
Configure the Proxy Server, Proxy Port, Proxy
Username, and Proxy Password fields. If the proxy does
not require authentication, leave the Proxy Username
and Proxy Password fields blank.
Automatically Acquire Server Certificate(s)
If you select Yes, QRadar downloads the certificate and
begins trusting the target server.
Recurrence
Specifies how often the Amazon AWS S3 REST API
Protocol connects to the Cisco CWS API to check for new
files, and retrieves them if they exist. The format is
M/H/D for Months/Hours/Days. The default is 5 M.
Every access to an AWS S3 bucket incurs a monetary cost
to the account that owns the bucket. Therefore, a smaller
recurrence value increases the cost.
The following table shows a sample event message from Cisco Cloud Web Security:
252
QRadar DSM Configuration Guide
Table 141. Cisco Cloud Web Security sample message
Event name
Low level category
Sample log message
c:comp - block
Access Denied
2016-08-22 18:22:34 GMT
<IP_address1>
<IP_address1>
GET
http
www.example.com
80
/
Mozilla/5.0
(Windows NT 6.1;
WOW64; rv:45.0) Gecko/20100101
Firefox/45.0
0
0
0
<IP_address2>
c:comp
Block all
block
category
Computers and Internet
<IP_address1>
0
Unknown
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Cloud Web Security to communicate with QRadar
To send events from Cloud Web Security to IBM Security QRadar, you must enable log extraction in
Cisco CWS ScanCenter.
Before you begin
The log extraction service must be enabled and provisioned for your company. You must have super user
administrator privileges to access the Log Extraction page.
Procedure
1. Log in to your Cisco ScanCenter account.
2. Click the Admin tab to view the administration menus.
3. From the Your Account menu, click Log Extraction.
4. In the Actions column in the Credentials area, click Issue Key.
5. In the Warning dialog box, click Issue & Download.
A key pair is issued and the keypair.csv file is downloaded.
The Access Key and Last issued column values are updated. The secret key does not display in the
user interface (UI).
6. Open the keypair.csv file and make a copy of the accessKey and secretKey. The keypair.csv file
contains a 20 character string access key and a 40 character string secret key. The key pair values that
you copied are used when you configure the log source in QRadar.
7. From the Connection Details pane, copy and record the values in the Endpoint and Bucket columns.
The connection details values that you copied are used when you configure the log source in QRadar.
What to do next
Configure the log source in QRadar.
For more information about Cisco CWS log extraction, see the Cisco ScanCenter Administrator Guide,
Release 5.2 on the Cisco website (https://search.cisco.com/search?query=cisco%20scancenter
%20administrator%20guide&locale=enUS&tab=Cisco).
Related tasks:
35 Cisco
253
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Cisco CSA
You can integrate a Cisco Security Agent (CSA) server with IBM Security QRadar.
The Cisco CSA DSM accepts events by using syslog, SNMPv1, and SNMPv2. QRadar records all
configured Cisco CSA alerts.
Configuring syslog for Cisco CSA
Configuration of your Cisco CSA server to forward events.
About this task
Take the following steps to configure your Cisco CSA server to forward events:
Procedure
1. Open the Cisco CSA user interface.
2. Select Events > Alerts.
3. Click New.
The Configuration View window is displayed.
4. Type in values for the following parameters:
v Name - Type a name that you want to assign to your configuration.
v Description - Type a description for the configuration. This step is not a requirement.
5. From the Send Alerts, select the event set from the list to generate alerts.
6. Select the SNMP check box.
7. Type a Community name.
The Community name that is entered in the CSA user interface must match the Community name
that is configured on IBM Security QRadar. This option is only available for the SNMPv2 protocol.
8. For the Manager IP address parameter, type the IP address of QRadar.
9. Click Save.
You are now ready to configure the log source in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco CSA
appliances.
About this task
To manually configure a syslog log source for Cisco CSA, take the following configuration steps, which
are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
254
QRadar DSM Configuration Guide
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco CSA.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 142. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco CSA appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco FireSIGHT Management Center
The IBM Security QRadar DSM for Cisco FireSIGHT Management Center collects FireSIGHT Management
Center events by using the eStreamer API service.
Cisco FireSIGHT Management Center is formerly known as Sourcefire Defense Center.
QRadar supports FireSIGHT Management Center version 5.2 to version 6.2.0.1
Configuration overview
To integrate with FireSIGHT Management Center, you must create certificates in the FireSIGHT
Management Center interface, and then add the certificates to the QRadar appliances that receive
eStreamer event data.
If your deployment includes multiple FireSIGHT Management Center appliances, you must copy the
certificate for each appliance that sends eStreamer events to any temporary location on the QRadar Event
Collector. The certificate allows the FireSIGHT Management Center appliance and the QRadar Console or
QRadar Event Collectors to communicate by using the eStreamer API to collect events.
To integrate QRadar with FireSIGHT Management Center, use the following steps:
1. Create the eStreamer certificate on your FireSIGHT Management Center appliance.
2. Import a Cisco FireSIGHT Management Center certificate in QRadar.
3. Configure a log source in QRadar for your FireSIGHT Management Center appliances.
Supported event types
QRadar supports the following event types from FireSIGHT Management Center:
v Discovery Events
v Correlation and White List Events
v Impact Flag Alerts
v User Activity
35 Cisco
255
v Malware Events
v File Events
v Connection Events
v Intrusion Events
v Intrusion Event Packet Data
v Intrusion Event Extra Data
Intrusion events that are categorized by the Cisco FireSIGHT Management Center DSM in QRadar use
the same QRadar Identifiers (QIDs) as the Snort DSM to ensure that all intrusion events are categorized
properly.
Intrusion events in the 1,000,000 - 2,000,000 range are user-defined rules in FireSIGHT Management
Center. User-defined rules that generate events are added as an Unknown event in QRadar, and
include additional information that describes the event type. For example, a user-defined event can
identify as Unknown:Buffer Overflow for FireSIGHT Management Center.
The following table provides sample event messages for the Cisco FireSIGHT Management Center DSM:
Table 143. Cisco FireSIGHT Management Center sample messages supported by the Cisco FireSIGHT Management
Center device.
Event name
Low level category
Sample log message
User Login Change Event
Computer Account Changed
DeviceType=Estreamer
DeviceAddress
=<IP_address>
CurrentTime=150774
0597988
netmapId=0
recordTyp
e=USER_LOGIN_CHANGE_EVENT
record
Length=142
timestamp=01 May 201
5 12:13:50
detectionEngineRef=
0
ipAddress=<IP_address>
MACAddres
s=<MAC_address>
hasIPv6=tru
e
eventSecond=1430491035
eve
ntMicroSecond=0
eventType=USER_
LOGIN_INFORMATION
fileNumber=00
000000
filePosition=00000000
ipV6Address=<IPv6_address>
userLoginInformation.timestamp=
1430491035
userLoginInformati
on.ipv4Address=<IP_address>
userLog
inInformation.userName=username
userLoginInformation.userRef=0
userLoginInformation.protocol
Ref=710
userLoginInformation.ema
il=
userLoginInformation.ipv6Ad
dress=<IP_address>
userLoginIn
formation.loginType=0
userLogi
nInformation.reportedBy=IPAddress"
User Removed Change Event
User Account Removed
DeviceType=Estreamer DeviceAddress
=<IP_address>
CurrentTime=15077
43344985
netmapId=0
recordTyp
e=USER_REMOVED_CHANGE_EVENT
reco
rdLength=191
timestamp=21 Sep 201
7 14:53:14
detectionEngineRef=
0
ipAddress=<IP_address>
MACAddress
=<MAC_address>
hasIPv6=tru
e
eventSecond=1506016392
event
MicroSecond=450775
eventType=DELE
TE_USER_IDENTITY
fileNumber=0000
0000
filePosition=00000000
ip
V6Address=<IPv6_address>
userIn
formation.id=1
userInformatio
n.userName=username
userInformat
ion.protocol=710
userInformation
.firstName=firstname
userInformation
.lastName=lastname
userInformation
.email=EmailAddress
userInformation.department=R
esearch
userInformation.phone
=000-000-0000
256
QRadar DSM Configuration Guide
Table 143. Cisco FireSIGHT Management Center sample messages supported by the Cisco FireSIGHT Management
Center device. (continued)
Event name
Low level category
Sample log message
INTRUSION EVENT EXTRA
DATA RECORD
Information
DeviceType=Estreamer DeviceAddress
=<IP_address>
CurrentTime=150774
0690263
netmapId=0
recordType=
INTRUSION_EVENT_EXTRA_DATA_RECORD
r
ecordLength=49
timestamp=01 May 20
15 15:32:53
eventExtraData.eventId=
393275
eventExtraData.eventSecond=
1430505172
eventExtraData.managed
Device.managedDeviceId=6
eventExtr
aData.managedDevice.name=manageddevic
e.<Server>.example.com
eventExtraData
.extraDataType.eventExtraDataType.ty
pe=10
eventExtraData.extraDataTyp
e.eventExtraDataType.name=HTTP Hostn
ame
eventExtraData.extraDataType
.eventExtraDataType.encoding=String
eventExtraData.extraData=www.example.com
RUA User record
Information
DeviceType=Estreamer DeviceAddress
=<IP_address>
CurrentTime=15077
40603372
netmapId=0
recordTyp
e=RUA_USER_RECORD
recordLength=
21
timestamp=11 Oct 2017 13:50:
02
userRef=2883
protocolRef=
710
userName=UserName
Related tasks:
“Creating Cisco FireSIGHT Management Center 5.x and 6.x certificates”
IBM Security QRadar requires a certificate for every FireSIGHT Management Center appliance in your
deployment. Certificates are generated in pkcs12 format and must be converted to a keystore and a
truststore file, which are usable by QRadar appliances.
“Importing a Cisco FireSIGHT Management Center certificate in QRadar” on page 259
The estreamer-cert-import.pl script for QRadar converts your pkcs12 certificate file to a keystore and
truststore file and copies the certificates to your QRadar appliance. Repeat this procedure for each
FireSIGHT Management Center pkcs12 certificate that you need to import to your QRadar Console or
Event Collector.
“Configuring a log source for Cisco FireSIGHT Management Center events” on page 260
QRadar does not automatically discover Cisco FireSIGHT Management Center events. You must
configure a log source in QRadar.
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
Creating Cisco FireSIGHT Management Center 5.x and 6.x certificates
IBM Security QRadar requires a certificate for every FireSIGHT Management Center appliance in your
deployment. Certificates are generated in pkcs12 format and must be converted to a keystore and a
truststore file, which are usable by QRadar appliances.
Procedure
1. Log in to your FireSIGHT Management Center interface.
v If you are using version 5.x, select System > Local > Registration.
v If you are using version 6.x, select System > Integration.
2. Click the eStreamer tab.
3. Select the types of events that you want FireSIGHT Management Center to send to QRadar, and then
click Save.
The following image lists the types of events that FireSIGHT Management Center sends to QRadar.
35 Cisco
257
Figure 5. FireSIGHT Management Center eStreamer Event Configuration
4. Click Create Client in the upper right side of the window.
5. In the Hostname field, type the IP address or host name, depending on which of the following
conditions applies to your environments.
v If you use a QRadar Console or you use a QRadar All-in-One appliance to collect eStreamer events,
type the IP address or host name of your QRadar Console.
v If you use a QRadar Event Collector to collect eStreamer events, type the IP address or host name
for the Event Collector.
v If you use QRadar High Availability (HA), type the virtual IP address.
6. Optional: In the Password field, type a password for your certificate. If you choose to provide a
password, the password is required to import the certificate.
7. Click Save.
The new client is added to the eStreamer Client list and the host can communicate with the eStreamer
API on port 8302.
8. Click Download Certificate for your host to save the pkcs12 certificate to a file location.
9. Click OK to download the file.
What to do next
You are now ready to import your FireSIGHT Management Center certificate to your QRadar appliance.
Related tasks:
“Importing a Cisco FireSIGHT Management Center certificate in QRadar” on page 259
The estreamer-cert-import.pl script for QRadar converts your pkcs12 certificate file to a keystore and
truststore file and copies the certificates to your QRadar appliance. Repeat this procedure for each
FireSIGHT Management Center pkcs12 certificate that you need to import to your QRadar Console or
Event Collector.
258
QRadar DSM Configuration Guide
Importing a Cisco FireSIGHT Management Center certificate in QRadar
The estreamer-cert-import.pl script for QRadar converts your pkcs12 certificate file to a keystore and
truststore file and copies the certificates to your QRadar appliance. Repeat this procedure for each
FireSIGHT Management Center pkcs12 certificate that you need to import to your QRadar Console or
Event Collector.
Before you begin
You must have root or su - root privileges to run the estreamer-cert-import.pl import script.
About this task
The estreamer-cert-import.pl import script is stored on your QRadar Event Collector when you install
the FireSIGHT Management Center protocol.
The script converts and imports only 1 pkcs12 file at a time. You are required import a certificate only for
the QRadar appliance that receives the FireSIGHT Management Center events. For example, after the
FireSIGHT Management Center event is categorized and normalized by an Event Collector in a QRadar
deployment, it is forwarded to the QRadar Console. In this scenario, you would import a certificate to the
Event Collector.
When you import a new certificate, existing FireSIGHT Management Center certificates on the QRadar
appliance are renamed to estreamer.keystore.old and estreamer.truststore.old.
Procedure
1. Log in as the root user by using SSH on the QRadar appliance that will receive the events.
2. Copy the downloaded certificate from your FireSIGHT Management Center appliance to a temporary
directory on the QRadar Event Collector.
3. Type the following command to import your pkcs12 file.
/opt/qradar/bin/estreamer-cert-import.pl -f <pkcs12_absolute_filepath> options
The -f parameter is required. All other parameters that are described in the following table are
optional.
Table 144. Import script command parameters
Parameter
Description
-f
Identifies the file name of the pkcs12 files to import.
-o
Overrides the default eStreamer name for the keystore
and truststore files. Use the -o parameter when you
integrate multiple FireSIGHT Management Center
devices. For example, /opt/qradar/bin/estreamer-certimport.pl -f <file name> -o <IP_address>
The import script creates the following files:
v /opt/qradar/conf/<IP_address>.keystore
v /opt/qradar/conf/<IP_address>.truststore
-d
Enables verbose mode for the import script. Verbose
mode is intended to display error messages for
troubleshooting purposes when pkcs12 files fail to
import properly.
-p
Specifies a password if a password was provided when
you generated the pkcs12 file.
-v
Displays the version information for the import script.
-h
Displays a help message about using the import script.
35 Cisco
259
Results
The import script displays the location where the import files were copied.
Example:
Figure 6. Sample import script output
Configuring a log source for Cisco FireSIGHT Management Center
events
QRadar does not automatically discover Cisco FireSIGHT Management Center events. You must
configure a log source in QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon, and then click Add.
5. From the Log Source Type list, select Cisco FireSIGHT Management Center.
6. From the Protocol Configuration list, select Cisco Firepower eStreamer.
7. Configure the following parameters:
Parameter
Description
Server Address
The IP address or host name of the FireSIGHT
Management Center device.
Server Port
The port number that the FireSIGHT Management Center
device is configured to accept connection requests on.
The default port that QRadar uses for the FireSIGHT
Management Center device is 8302.
Keystore Filename
The directory path and file name for the keystore private
key and associated certificate. By default, the import
script creates the keystore file in the following directory:
/opt/qradar/conf/estreamer.keystore
Truststore Filename
The directory path and file name for the truststore files.
The truststore file contains the certificates that are trusted
by the client. By default, the import script creates the
truststore file in the following directory:
/opt/qradar/conf/estreamer.truststore
Request Extra Data
Select this option to request intrusion event extra data
from FireSIGHT Management Center. For example, extra
data includes the original IP address of an event.
260
QRadar DSM Configuration Guide
Parameter
Description
Domain
Note: Domain Streaming Requests are only supported
for eStreamer version 6.x. Leave the Domain field blank
for eStreamer version 5.x.
The domain where the events are streamed from.
The value in the Domain field must be a fully qualified
domain. This means that all ancestors of the desired
domain must be listed starting with the top-level domain
and ending with the leaf domain that you want to
request events from.
Example:
Global is the top level domain, B is a second level
domain that is a subdomain of Global, and C is a
third-level domain and a leaf domain that is a
subdomain of B. To request events from C, type the
following value for the Domain parameter:
Global \ B \ C
8. Click Save.
Cisco FWSM
You can integrate Cisco Firewall Service Module (FWSM) with IBM Security QRadar.
The Cisco FWSM DSM for QRadar accepts FWSM events by using syslog. QRadar records all relevant
Cisco FWSM events.
Configuring Cisco FWSM to forward syslog events
To integrate Cisco FWSM with IBM Security QRadar, you must configure your Cisco FWSM appliances to
forward syslog events to QRadar.
About this task
To configure Cisco FWSM:
Procedure
1. Using a console connection, telnet, or SSH, log in to the Cisco FWSM.
2. Enable logging:
logging on
3. Change the logging level:
logging trap <level>
Where <level> is set from levels 1-7. By default, the logging trap level is set to 3 (error).
4. Designate QRadar as a host to receive the messages:
logging host [interface] ip_address [tcp[/port] | udp[/port]] [format emblem]
For example:
logging host dmz1 192.0.2.1
Where 192.0.2.1 is the IP address of your QRadar system.
You are now ready to configure the log source in QRadar.
35 Cisco
261
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco
FWSM appliances.
About this task
The following configuration steps are optional. To manually configure a syslog log source for Cisco
FWSM, take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Firewall Services Module (FWSM).
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 145. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco FWSM appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco IDS/IPS
The Cisco IDS/IPS DSM for IBM Security QRadar polls Cisco IDS/IPS for events by using the Security
Device Event Exchange (SDEE) protocol.
About this task
The SDEE specification defines the message format and the protocol that is used to communicate the
events that are generated by your Cisco IDS/IPS security device. QRadar supports SDEE connections by
polling directly to the IDS/IPS device and not the management software, which controls the device.
Note: You must have security access or web authentication on the device before you connect to QRadar.
After you configure your Cisco IDS/IPS device, you must configure the SDEE protocol in QRadar. When
you configure the SDEE protocol, you must define the URL required to access the device.
For example, https://www.example.com/cgi-bin/sdee-server.
262
QRadar DSM Configuration Guide
You must use an http or https in the URL, which is specific to your Cisco IDS version:
v If you are using RDEP (for Cisco IDS v4.0), check that /cgi-bin/event-server is at the end of the URL.
For example, https://www.example.com/cgi-bin/event-server
v If you are using SDEE/CIDEE (for Cisco IDS v5.x and later), check that /cgi-bin/sdee-server is at the
end of the URL.
For example, https://www.example/cgi-bin/sdee-server
QRadar does not automatically discover or create log sources for syslog events from Cisco IDS/IPS
devices. To integrate Cisco IDS/IPS device events with QRadar, you must manually create a log source
for each Cisco IDS/IPS in your network.
To configure a Cisco IDS/IPS log source by using SDEE polling:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Intrusion Prevention System (IPS).
9. Using the Protocol Configuration list, select SDEE.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 146. SDEE parameters
Parameter
Description
Log Source Identifier
Type an IP address, host name, or name to identify the SDEE event source. IP
addresses or host names allow QRadar to identify a log file to a unique event
source.
The log source identifier must be unique for the log source type.
URL
Type the URL address to access the log source, for example,
https://www.example.com/cgi-bin/sdee-server. You must use an http or https
in the URL.
Here are some options:
v If you are using SDEE/CIDEE (for Cisco IDS v5.x and later), check that
/cgi-bin/sdee-server is at the end of the URL. For example,
https://www.example.com/cgi-bin/sdee-server
v If you are using RDEP (for Cisco IDS v4.0), check that /cgi-bin/eventserver is at the end of the URL. For example, https://www.example.com/cgibin/event-server
Username
Type the user name. This user name must match the SDEE URL user name that
is used to access the SDEE URL. The user name can be up to 255 characters in
length.
35 Cisco
263
Table 146. SDEE parameters (continued)
Parameter
Description
Password
Type the user password. This password must match the SDEE URL password
that is used to access the SDEE URL. The password can be up to 255 characters
in length.
Events / Query
Type the maximum number of events to retrieve per query. The valid range is 0
- 501 and the default is 100.
Force Subscription
Select this check box if you want to force a new SDEE subscription. By default,
the check box is selected.
The check box forces the server to drop the least active connection and accept a
new SDEE subscription connection for this log source.
Clearing the check box continues with any existing SDEE subscription.
Severity Filter Low
Select this check box if you want to configure the severity level as low.
Log sources that support SDEE return only the events that match this severity
level. By default, the check box is selected.
Severity Filter Medium
Select this check box if you want to configure the severity level as medium.
Log sources that support SDEE return only the events that match this severity
level. By default, the check box is selected.
Severity Filter High
Select this check box if you want to configure the severity level as high.
Log sources that support SDEE return only the events that match this severity
level. By default, the check box is selected.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are polled from your Cisco IDS/IPS appliances are
displayed on the Log Activity tab of QRadar.
Cisco IronPort
IBM Security QRadar DSM for Cisco IronPort retrieves logs from the following Cisco products: Cisco
IronPort, Cisco Email Security Appliance (ESA), and Cisco Web Security Appliance (WSA). The Cisco
IronPort DSM retrieves web content filtering events (W3C format), Text Mail Logs, and System Logs.
To integrate Cisco IronPort with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs from the IBM Support Website (https://www.ibm.com/support/fixcentral/) onto your QRadar
Console:
v Log File Protocol RPM
v Cisco IronPort DSM RPM
2. Configure Cisco IronPort to communicate with QRadar.
3. Optional: Add a Cisco IronPort log source by using the Log File protocol.
4. Optional: Add a Cisco IronPort log source by using the Syslog protocol.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
264
QRadar DSM Configuration Guide
Cisco IronPort DSM specifications
The following table describes the specifications for the Cisco IronPort DSM.
Table 147. Cisco IronPort DSM specifications
Specification
Value
Manufacturer
Cisco
DSM name
Cisco IronPort
RPM file name
DSM-CiscoIronPort-QRadar_versionbuild_number.noarch.rpm
Supported versions
v Cisco IronPort: V5.5, V6.5, V7.1, V7.5
v Cisco ESA: V10.0
v Cisco WSA: V10.0
Protocol
Syslog: Cisco IronPort, Cisco WSA
Log File Protocol: Cisco IronPort, Cisco ESA
Event format
W3C
Recorded event types
Text Mail Logs, System Logs, Web Content, Filtering
Events
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Cisco Email Security Appliance (http://www.cisco.com/
c/en/us/products/security/email-security/index.html)
Cisco Web Security Appliance (http://www.cisco.com/c/
en/us/products/security/web-security-appliance/
index.html)
Configuring Cisco IronPort appliances to communicate with QRadar
Complete the configuration on Cisco IronPort appliances so that they can send events to QRadar.
Procedure
1. To configure your Cisco IronPort Appliance to push Web Content Filter events, you must configure a
log subscription for the Web Content Filter that uses the W3C format. For more information, see your
Cisco IronPort documentation.
2. To configure your Cisco Email Security Appliance (ESA) to push message data, anti-virus events, you
must configure a log subscription. For more information, see the Cisco ESA documentation:
Configuring Log Subscriptions (https://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa100/ESA_10-0_User_Guide.pdf).
3. To configure your Cisco Web Security Appliance (WSA) to push Web Proxy filtering and traffic
monitoring activity events, you must configure a log subscription. For more information, see the Cisco
WSA documentation: Adding and Editing Log Subscriptions (https://www.cisco.com/c/dam/en/us/
td/docs/security/wsa/wsa_10-0/WSA_10-1-0_UserGuide.pdf).
Configuring a Cisco IronPort and Cisco ESA log source by using the
log file protocol
You can configure a log source on the QRadar Console so that Cisco IronPort and Cisco Email Security
Appliance (ESA) can communicate with QRadar by using the log file protocol.
35 Cisco
265
Procedure
Configure a Cisco IronPort log source on the QRadar Console by using the log file protocol. The
following tables describe the Log File log source parameters that require specific values for retrieving logs
from Cisco IronPort and Cisco ESA.
Table 148. Cisco IronPort log source parameters for Log File
Parameter
Value
Log Source type
Cisco IronPort
Protocol Configuration
Log File Protocol
Log Source Identifier
The Log Source Identifier can be any valid value,
including the same value as the Log Source Name
parameter, and doesn't need to reference a specific server.
Service Type
From the list, select the protocol that you want to use
when retrieving log files from a remote server. The
default is SFTP.
The underlying protocol that is used to retrieve log files
for the SCP and SFTP service type requires that the
server that is specified in the Remote IP or Hostname
field has the SFTP subsystem enabled.
Remote IP or Hostname
Type the IP address or host name of the device that
contains the event log files.
Remote Port
Type the port that is used to communicate with the
remote host. The valid range is 1 - 65535. The options
include:
v FTP - TCP Port 21
v SFTP - TCP Port 22
v SCP - TCP Port 22
If the host for your event files is using a non-standard
port number for FTP, SFTP, or SCP, you must adjust the
port value.
Remote User
Type the user name necessary to log in to the host that
contains the event files.
Remote Password
Type the password necessary to log in to the host.
Confirm Password
Confirm the password necessary to log in to the host.
SSH Key File
If the system is configured to use key authentication,
type the path to the SSH key.
When an SSH key file is used, the Remote Password
field is ignored.
Remote Directory
Type the directory location on the remote host from
which the files are retrieved. The directory path is
relative to the user account that is used to log in.
Note:
For FTP only. If the log files are in the remote user’s
home directory, you can leave the remote directory
blank. A blank remote directory field supports systems
where a change in the working directory (CWD)
command is restricted.
266
QRadar DSM Configuration Guide
Table 148. Cisco IronPort log source parameters for Log File (continued)
Parameter
Value
Recursive
Select this check box to enable the file pattern to search
sub folders. By default, the check box is clear.
This option is ignored for SCP file transfers.
FTP File Pattern
Must use a regular expression that matches the log files
that are generated.
The FTP file pattern that you specify must match the
name that you assigned to your event files. For example,
to collect files that end with .log, type the following
command: .*\.log.
For more information, see the Oracle Java documentation
(http://docs.oracle.com/javase/tutorial/essential/regex/
).
Start Time
Type the time of day for the log source to start the file
import.
This parameter functions with the Recurrence value to
establish when and how often the Remote Directory is
scanned for files.
Recurrence
Type a time interval to determine how frequently the
remote directory is scanned for new event log files. The
minimum value is 15 minutes.
The time interval can include values in hours (H),
minutes (M), or days (D). For example, a recurrence of
2H scans the remote directory every 2 hours.
Run On Save
Select this check box to start the log file import
immediately after the administrator saves the log source.
After the first file import, the log file protocol follows the
start time and recurrence schedule that is defined by the
administrator.
When selected, this check box clears the list of previously
downloaded and processed files.
EPS Throttle
Type the number of Events Per Second (EPS) that the
protocol cannot exceed.
The valid range is 100 - 5000.
Processor
From the list, select gzip.
Ignore Previously Processed File(s)
Select this check box to track files that were processed by
the log file protocol. QRadar examines the log files in the
remote directory to determine if a file was previously
processed by the log file protocol. If a previously
processed file is detected, the log file protocol does not
download the file for processing. All files that weren't
previously processed are downloaded.
This option only applies to FTP and SFTP Service Types.
35 Cisco
267
Table 148. Cisco IronPort log source parameters for Log File (continued)
Parameter
Value
Change Local Directory?
Select this check box to define the local directory on the
QRadar Console for storing downloaded files during
processing.
Administrators can leave this check box clear for more
configurations. When this check box is selected, the Local
Directory field is displayed so that you can configure the
local directory to use for storing files.
Event Generator
W3C. The Event Generator uses W3C to process the web
content filter log files.
File Encoding
From the list box, select the character encoding that is
used by the events in your log file.
Folder Separator
Type the character that is used to separate folders for
your operating system. The default value is /.
Most configurations can use the default value in Folder
Separator field.
This field is intended for operating systems that use a
different character to define separate folders. For
example, periods that separate folders on mainframe
systems.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring a Cisco IronPort and Cisco WSA log source by using the
Syslog protocol
You can configure a log source on the QRadar Console so that the Cisco IronPort Appliance and Cisco
Web Security Appliance (WSA) can communicate with QRadar by using the Syslog protocol.
Procedure
Configure a Cisco IronPort log source on the QRadar Console by using Syslog. The following tables
describe the Syslog log source parameters that require specific values for retrieving logs from Cisco
IronPort and Cisco WSA.
Table 149. Cisco IronPort log source parameters for Syslog
Parameter
Value
Log Source type
Cisco IronPort
Protocol Configuration
Syslog
268
QRadar DSM Configuration Guide
Table 149. Cisco IronPort log source parameters for Syslog (continued)
Parameter
Value
Log Source Identifier
The IPv4 address or host name that identifies the log
source.
If your network contains multiple devices that are
attached to a single management console, specify the IP
address of the individual device that created the event. A
unique identifier, such as an IP address, prevents event
searches from identifying the management console as the
source for all of the events.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Sample event messages
Use these sample event messages as a way of verifying a successful integration with QRadar. Replace the
sample IP addresses, etc. with your own content.
The following table shows a sample event message from Cisco IronPort:
Table 150. Cisco IronPort sample message supported by the Cisco IronPort device
Event name
Low level category
Sample log message
Mailserver_info
Information
Mon Apr 17 19:57:20
2003 Info: MID 6 ICID
5 From:
<sender@remotehost.co
m>
TCP_CONNECT
Information
timestamp=1296564861.
465 x-latency=72 cip=
127.0.0.1 xresultcodehttpstatus=
TCP_MISS_
SSL/200 scbytes=
0 csmethod=
TCP_CONNE
CT csurl=192.0.2.1:443
cs-username=- xhierarchyorigin=
DIRECT/192.0.2.1
cs(MIME_type)
=- xacltag=
DECRYPT_WE
BCAT_7-DefaultGroupDefaultGroup-NONENONENONEDefaultGroup
Cisco IOS
You can integrate Cisco IOS series devices with IBM Security QRadar.
The Cisco IOS DSM for QRadar accepts Cisco IOS events by using syslog. QRadar records all relevant
events. The following Cisco Switches and Routers are automatically discovered as Cisco IOS series
devices, and their events are parsed by the Cisco IOS DSM:
35 Cisco
269
v Cisco 12000 Series Routers
v Cisco 6500 Series Switches
v Cisco 7600 Series Routers
v Cisco Carrier Routing System
v Cisco Integrated Services Router.
Note: Make sure all Access Control Lists (ACLs) are set to LOG.
Configuring Cisco IOS to forward events
You can configure a Cisco IOS-based device to forward events.
About this task
Take the following steps to configure your Cisco device:
Procedure
1. Log in to your Cisco IOS Server, switch, or router.
2. Type the following command to log in to the router in privileged-exec:
enable
3. Type the following command to switch to configuration mode:
conf t
4. Type the following commands:
logging <IP address>
logging source-interface <interface>
Where:
v <IP address> is the IP address of the IBM Security QRadar host and the SIM components.
v <interface> is the name of the interface, for example, dmz, lan, ethernet0, or ethernet1.
5. Type the following to configure the priority level:
logging trap warning
logging console warning
Where warning is the priority setting for the logs.
6. Configure the syslog facility:
logging facility syslog
7. Save and exit the file.
8. Copy the running-config to startup-config by typing the following command:
copy running-config startup-config
You are now ready to configure the log source in QRadar.
The configuration is complete. The log source is added to QRadar as Cisco IOS events are
automatically discovered. Events that are forwarded to QRadar by Cisco IOS-based devices are
displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco IOS.
About this task
The following configuration steps are optional. To manually configure a log source for Cisco IOS-based
devices, take the following steps:
270
QRadar DSM Configuration Guide
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select one of the following devices:
v Cisco IOS
v Cisco 12000 Series Routers
v Cisco 6500 Series Switches
v Cisco 7600 Series Routers
v Cisco Carrier Routing System
v Cisco Integrated Services Router
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 151. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco IOS-based device.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco Identity Services Engine
The IBM Security QRadar DSM for Cisco Identity Services Engine (ISE) collects device events from Cisco
ISE appliances by using the UDP Multiline Syslog protocol.
The following table describes the specifications for the Cisco Identity Services Engine DSM:
Table 152. Cisco Identity Services Engine DSM specifications
Specification
Value
Manufacturer
Cisco
DSM name
Cisco Identity Services Engine
RPM file name
DSM-CiscoISE-QRadar_version-build_number.noarch.rpm
Supported versions
1.1 to 2.2
Protocol
UDP Multiline Syslog
Event format
Syslog
Recorded event types
Device events
35 Cisco
271
Table 152. Cisco Identity Services Engine DSM specifications (continued)
Specification
Value
Automatically discovered?
No
Includes identity?
Yes
Includes custom properties?
No
More information
Cisco website (https://www.cisco.com/c/en/us/
products/security/identity-services-engine/index.html)
To integrate Cisco ISE with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console. RPMs are available for download from the IBM support website
(http://www.ibm.com/support):
v DSMCommon RPM
v Cisco Identity Services Engine DSM RPM
2. Configure your Cisco ISE appliance to send UDP Multiline Syslog events to QRadar.
3. Add a Cisco Identity Services Engine log source on the QRadar Console. The following table describes
the parameters that require specific values to collect events from Cisco ISE:
Table 153. Cisco Identity Services Engine log source parameters
Parameter
Value
Log Source type
Cisco Identity Service Engine
Protocol Configuration
UDP Multiline Syslog
Log Source Identifier
The IP address or host name of the Cisco Identity Service
Engine device that sends UDP Multiline Syslog events to
QRadar.
Listen Port
Type 517 as the port number used by QRadar to accept
incoming UDP Multiline Syslog events. The valid port
range is 1 - 65535.
Note: UDP Multiline Syslog events can be assigned to
any port that is not in use, except for port 514. The
default port that is assigned to the UDP Multiline
protocol is UDP port 517. For a list of ports that are used
by QRadar, see Common ports and servers used by QRadar
in the IBM Security QRadar Administration Guide or in the
IBM Knowledge Center (https://www.ibm.com/
support/knowledgecenter/SS42VS_7.3.0/
com.ibm.qradar.doc/
c_qradar_adm_ports_and_servers.html).
To edit a saved configuration to use a new port number,
complete the following steps:
1. In the Listen Port field, type the new port number
for receiving UDP Multiline Syslog events.
2. Click Save.
The port update is complete and event collection starts
on the new port number.
Message ID Pattern
Type the following regular expression (regex) to filter the
event payload messages:
CISE_\S+ (\d{10})
4. Configure a remote logging target on your Cisco ISE appliance.
272
QRadar DSM Configuration Guide
5. Configure the event logging categories on your Cisco ISE appliance.
6. Verify that QRadar is configured correctly.
The following table shows a sample normalized event message from Cisco Identity Services Engine:
Table 154. Cisco Identity Services Engine sample message
Event name
Low level category
Sample log message
AUTHEN_PASSED
Admin Login Successful
<181>Jan 26 15:00:15 cisco.ise
.test.com CISE_Administrative_and_
Operational_Audit 0000003812 1 0
2015-01-26 15:00:15.510 +00:00 00
00008620 51001 NOTICE Administrator
-Login: Administrator authenticatio
n succeeded, ConfigVersionId=84,
AdminInterface=GUI, AdminIPAddress
=x.x.x.x, AdminSession=0DE37
0E55527018DAA537F60AAAAAAAA, Admin
Name=adminUser, OperationMessage
Text=Administrator authentica
tion successful,
FAILED_ATTEMPT
General Authentication Failed
<181>Oct 31 16:35:39 isi CISE_Failed_Attempts
0000199854 2017-10-31 16:35:39.919 +01:00
0021309086 5400 NOTICE Failed-Attempt:
Authentication failed, ConfigVersionId=4, Device
IP Address=x.x.x.x, Device Port=33987,
DestinationIPAddress=x.x.x.x,
DestinationPort=1812,
RadiusPacketType=AccessRequest,
UserName=admin, Protocol=Radius,
RequestLatency=8, NetworkDeviceName=device1,
User-Name=admin, NAS-Identifier=12782c2b-747a4894-9689-000000000000,
NetworkDeviceProfileName=Cisco,
NetworkDeviceProfileId=efb762c5-9082-4c79-a101000000000000, IsThirdPartyDeviceFlow=false,
AcsSessionID=isi/298605301/000000,
AuthenticationMethod=PAP_ASCII,
SelectedAccessService=Default Network Access,
FailureReason=22056 Subject not found in the
applicable identity store(s), Step=11001,
Step=11017, Step=11117, Step=15049, Step=15008,
Step=15048, Step=15048, Step=15048, Step=15048,
Step=15006, Step=15041, Step=15006, Step=15013,
Step=24210, Step=24216, Step=22056, Step=22058,
Step=22061, Step=11003
Related concepts:
“UDP multiline syslog protocol configuration options” on page 50
To create a single-line syslog event from a multiline event, configure a log source to use the UDP
multiline protocol. The UDP multiline syslog protocol uses a regular expression to identify and
reassemble the multiline syslog messages into single event payload.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
35 Cisco
273
“Configuring a remote logging target in Cisco ISE”
To forward syslog events to IBM Security QRadar, you must configure your Cisco ISE appliance with a
remote logging target.
“Configuring logging categories in Cisco ISE”
The Cisco Identity Services Engine DSM for IBM Security QRadar collects syslog events from multiple
event logging categories. To define which events are forwarded to QRadar, you must configure each
event logging category on your Cisco ISE appliance.
Configuring a remote logging target in Cisco ISE
To forward syslog events to IBM Security QRadar, you must configure your Cisco ISE appliance with a
remote logging target.
Procedure
1. Log in to your Cisco ISE Administration Interface.
2. From the navigation menu, select Administration > System > Logging > Remote Logging Targets.
3. Click Add, and then configure the following parameters:
Option
Description
Name
Type a unique name for the remote target system.
Description
You can uniquely identify the target system for users.
IP Address
Type the IP address of the QRadar Console or Event
Collector.
Port
Type 517 or use the port value that you specified in your
Cisco ISE log source for QRadar
Facility Code
From the Facility Code list, select the syslog facility to
use for logging events.
Maximum Length
Type 1024 as the maximum packet length allowed for the
UDP syslog message.
4. Click Submit.
What to do next
Configure the logging categories that are forwarded by Cisco ISE to QRadar.
Configuring logging categories in Cisco ISE
The Cisco Identity Services Engine DSM for IBM Security QRadar collects syslog events from multiple
event logging categories. To define which events are forwarded to QRadar, you must configure each
event logging category on your Cisco ISE appliance.
Procedure
1. Log in to your Cisco ISE Administration Interface.
2. From the navigation menu, select Administration > System > Logging > Logging Categories.
The following list shows the supported event logging categories for the IBM Security QRadar DSM
for Cisco Identity Services Engine:
v AAA audit
v Failed attempts
v Passed authentication
v AAA diagnostics
v Administrator authentication and authorization
274
QRadar DSM Configuration Guide
v Authentication flow diagnostics
v Identity store diagnostics
v Policy diagnostics
v Radius diagnostics
v Guest
v Accounting
v Radius accounting
v Administrative and operational audit
v Posture and client provisioning audit
v Posture and client provisioning diagnostics
v Profiler
v System diagnostics
v Distributed management
v Internal operations diagnostics
v System statistics
3. Select an event logging category, and then click Edit.
4. From the Log Severity list, select a severity for the logging category.
5. In the Target field, add your remote logging target for QRadar to the Select box.
6. Click Save.
7. Repeat this process for each logging category that you want to forward to QRadar.
Events that are forwarded by Cisco ISE are displayed on the Log Activity tab in QRadar.
Cisco NAC
The Cisco NAC DSM for IBM Security QRadar accepts events by using syslog.
QRadar records all relevant audit, error, failure events, quarantine, and infected system events. Before
you configure a Cisco NAC device in QRadar, you must configure your device to forward syslog events.
Configuring Cisco NAC to forward events
You can configure Cisco NAC to forward syslog events:
Procedure
1. Log in to the Cisco NAC user interface.
2. In the Monitoring section, select Event Logs.
3. Click the Syslog Settings tab.
4. In the Syslog Server Address field, type the IP address of your IBM Security QRadar.
5. In the Syslog Server Port field, type the syslog port number. The default is 514.
6. In the System Health Log Interval field, type the frequency, in minutes, for system statistic log
events.
7. Click Update.
You are now ready to configure the log source in QRadar.
Configuring a log source
To integrate Cisco NAC events with IBM Security QRadar, you must manually create a log source to
receive Cisco NAC events
35 Cisco
275
About this task
QRadar does not automatically discover or create log sources for syslog events from Cisco NAC
appliances.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco NAC Appliance.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 155. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco NAC appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are forwarded to QRadar by Cisco NAC are
displayed on the Log Activity tab.
Cisco Nexus
The Cisco Nexus DSM for IBM Security QRadar supports alerts from Cisco NX-OS devices.
Syslog is used to forward events from Cisco Nexus to QRadar. Before you can integrate events with
QRadar, you must configure your Cisco Nexus device to forward syslog events.
Configuring Cisco Nexus to forward events
You can configure syslog on your Cisco Nexus server to forward events:
Procedure
1. Type the following command to switch to configuration mode:
config t
2. Type the following commands:
logging server <IP address> <severity>
Where:
v <IP address> is the IP address of your QRadar Console.
v <severity> is the severity level of the event messages, that range 0 - 7 in value.
For example, logging server 192.0.2.1 6 forwards information level (6) syslog messages to 192.0.2.1.
3. Type the following command to configure the interface for sending syslog events:
logging source-interface loopback
4. Type the following command to save your current configuration as the startup configuration:
276
QRadar DSM Configuration Guide
copy running-config startup-config
The configuration is complete. The log source is added to IBM Security QRadar as Cisco Nexus events
are automatically discovered. Events that are forwarded to QRadar by Cisco Nexus are displayed on
the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco
Nexus.
About this task
The following configuration steps are optional. To manually configure a log source for Cisco Nexus, take
the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Nexus.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 156. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco Nexus appliances.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete. For more information on configuring a Virtual Device Context (VDC)
on your Cisco Nexus device, see your vendor documentation.
Cisco Pix
You can integrate Cisco Pix security appliances with IBM Security QRadar.
The Cisco Pix DSM for QRadar accepts Cisco Pix events by using syslog. QRadar records all relevant
Cisco Pix events.
Configuring Cisco Pix to forward events
You can configure Cisco Pix to forward events.
35 Cisco
277
Procedure
1. Log in to your Cisco PIX appliance by using a console connection, telnet, or SSH.
2. Type the following command to access Privileged mode:
enable
3. Type the following command to access Configuration mode:
conf t
4. Enable logging and time stamp the logs:
logging on
logging timestamp
5. Set the log level:
logging trap warning
6. Configure logging to IBM Security QRadar:
logging host <interface> <IP address>
Where:
v <interface> is the name of the interface, for example, DMZ, LAN, ethernet0, or ethernet1.
v <IP address> is the IP address of the QRadar host.
The configuration is complete. The log source is added to QRadar as Cisco Pix Firewall events are
automatically discovered. Events that are forwarded to QRadar by Cisco Pix Firewalls are displayed
on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco Pix
Firewalls.
About this task
The following configuration steps are optional.
To manually configure a log source for Cisco Pix, take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco PIX Firewall.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
278
QRadar DSM Configuration Guide
Table 157. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco Pix Firewall.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco Stealthwatch
The IBM Security QRadar DSM for Cisco Stealthwatch receives events from a Cisco Stealthwatch device.
The following table identifies the specifications for the Cisco Stealthwatch DSM:
Table 158. Cisco Stealthwatch DSM specifications
Specification
Value
Manufacturer
Cisco
DSM name
Cisco Stealthwatch
RPM file name
DSM-CiscoStealthwatch-QRadar_versionbuild_number.noarch.rpm
Supported versions
6.8
Protocol
Syslog
Event format
LEEF
Recorded event types
Anomaly, Data Hoarding, Exploitation, High Concern
Index, High DDoS Source Index, High Target Index,
Policy Violation, Recon, High DDoS Target Index, Data
Exfiltration, C&C
Automatically discovered?
Yes
Includes identity?
No
Includes Custom properties?
No
More information
Cisco Stealthwatch website (http://www.cisco.com)
To integrate Cisco Stealthwatch with QRadar, complete the following steps:
1. If automatic updates are not configured, download the most recent version of the following RPMs on
your QRadar Console:
v DSMCommon RPM
v Cisco Stealthwatch DSM RPM
2. Configure your Cisco Stealthwatch device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a Cisco Stealthwatch log source on the
QRadar Console. The following table describes the parameters that require specific values for Cisco
Stealthwatch event collection:
Table 159. Cisco Stealthwatch log source parameters
Parameter
Value
Log Source type
Cisco Stealthwatch
Protocol Configuration
Syslog
Log Source
A unique identifier for the log source.
35 Cisco
279
The following table shows a sample syslog message that is supported by the Cisco Stealthwatch device:
Table 160. Cisco Stealthwatch sample syslog message
Event name
Low-level category
Sample log message
16
Network Threshold Policy
Violation
May 5 18:11:01 127.0.0.1 May 05 18:
11:01 <Server> StealthWatch[3706]:
LEEF:2.0|Lancope|Stealthwatch|6.8|
16|0x7C|src=<Source_IP_address>|
dst=<Destination_IP_address>|dstP
ort=|proto=|msg=The total traffic
inbound + outbound exceeds the acc
eptable total traffic values.|fullm
essage=Observed 3.95G bytes. Expect
ed 2.22M bytes, tolerance of 50 all
ows up to 1.92G bytes.|start=201705- 05T18:10:00Z|end=|cat=High Tot
al Traffic|alarmID=3L-1CR1- JI38-Q
GNE-2|sourceHG=<Country>|targetHG=
Unknown|sourc eHostSnapshot=https:
//<Server>/ smc/getHostSnapshot?do
mainid= 123&hostip=<Server_IP>&date
=201 7-05- 05T18:10:00Z|targetHost
Snapsh ot=https://<Server>/smc/get
Host Snapshot?domainid=123&hostip
=<IP_address>&date=2017-05- 05T18
:10:00Z|flowCollectorName =<Server2>
|flowCollectorIP=<IP_address2>|do
main=example.com|exporterName =|
exporterIPAddress=|exporterInf o
=|targetUser=|targetHostname=|
sourceUser=|alarmStatus=ACTIV
E|alarmSev=Major
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Cisco Stealthwatch to communicate with QRadar
About this task
Cisco Stealthwatch can forward events of different message types, including customized syslog messages,
to third parties.
Procedure
1. Log in to the Stealthwatch Management Console (SMC) as an administrator.
2. In the menu bar, click Configuration > Response Management.
3. From the Actions section in the Response Management menu, click Add > Syslog Message.
4. In the Add Syslog Message Action window, configure the following parameters:
Parameter
Value
Name
The name for the syslog message action.
280
QRadar DSM Configuration Guide
Parameter
Value
Enabled
This check box is enabled by default.
IP Address
The IP address of the QRadar Event Collector.
Port
The default port is port 514.
Format
Select Syslog Formats.
5. Enter the following custom format:
LEEF:2.0|Lancope|Stealthwatch|6.8|{alarm_type_id}|0x7C|src={source_ip}
|dst={target_ip}|dstPort={port}|proto={protocol}|msg={alarm_type_description}|
fullmessage={details}|start={start_active_time}|end={end_active_time}
|cat={alarm_category_name}|alarmID={alarm_id}|sourceHG={source_host_group_names}|
targetHG={target_host_group_names}|sourceHostSnapshot={source_url}|
targetHostSnapshot={target_url}|flowCollectorName={device_na me}|
flowCollectorIP={device_ip}|domain={domain_name}|exporterName=
{exporter_hostname}|exporterIPAddress ={exporter_ip}|
exporterInfo={exporter_label}|targetUser={target_username}|
targetHostname={target_hostname}|s ourceUser={source_username}|alarmStatus=
{alarm_status}|alarmSev={alarm_severity_name}
6. Select the custom format from the list and click OK.
Note: Use the Test button to send test message to QRadar
7. Click Response Management > Rules.
8. Click Add and select Host Alarm.
9. Provide a rule name in the Name field.
10. Create rules by selecting values from the Type and Options menus. To add more rules, click the
ellipsis icon. For a Host Alarm, combine as many possible types in a statement as possible.
11. In the Action dialog, select IBM QRadar syslog action for both Active and Inactive conditions. The
event is forwarded to QRadar when any predefined condition is satisfied.
Cisco Umbrella
The IBM Security QRadar DSM for Cisco Umbrella collects DNS logs from Cisco Umbrella storage by
using an Amazon S3 compatible API.
To integrate Cisco Umbrella with QRadar, complete the following steps:
1. If automatic updates are not enabled, RPMs are available for download from the IBM support website
(http://www.ibm.com/support). Download and install the most recent version of the following RPMs
on your QRadar Console in the order that they are listed.
v Protocol Common RPM
v Amazon AWS REST API Protocol RPM
v Cisco Cloud Web Security DSM RPM
v Cisco Umbrella DSM RPM
2. Configure your Cisco Umbrella to communicate with QRadar.
3. Add a Cisco Umbrella log source on the QRadar Console. The following table describes the
parameters that require specific values for Cisco Umbrella event collection:
Table 161. Amazon AWS S3 REST API log source parameters
Parameter
Value
Log Source type
Cisco Umbrella
Protocol Configuration
Amazon AWS S3 REST API
35 Cisco
281
Table 161. Amazon AWS S3 REST API log source parameters (continued)
Parameter
Value
Log Source Identifier
Type a unique name for the log source.
The Log Source Identifier can be any valid value and
does not need to reference a specific server. The Log
Source Identifier can be the same value as the Log
Source Name. If you configured more than one Cisco
Umbrella log source, you might want to identify the first
log source as ciscoumbrella1, the second log source as
ciscoumbrella2, and the third log source as
ciscoumbrella3.
Signature Version
Select AWSSIGNATUREV2 or AWSSIGNATURE4.
AWSSIGNATUREV2 does not support all Amazon AWS
regions. If you are using a region that supports only
AWSSIGNATUREV4, you must choose
AWSSIGNATUREV4 from the list.
Note: If you need to create a log source to retrieve
events from multiple regions, you must choose
AWSSIGNATUREV4.
Region Name (Signature V4 only)
The region that is associated with the Amazon S3 bucket.
Bucket Name
The name of the AWS S3 bucket where the log files are
stored.
Endpoint URL
https://s3.amazonaws.com
The Endpoint URL can be different depending on the
device configurations.
Authentication Method
Access Key ID / Secret Key
Standard authentication that can be used from
anywhere.
EC2 Instance IAM Role
If your QRadar managed host is running in an
AWS EC2 instance, choosing this option will use
the IAM Role from the instance metadata
assigned to the instance for authentication and
no keys are required. This method will only
work for managed hosts that are running within
an AWS EC2 container.
Access Key ID
The public access key that is required to access the AWS
S3 bucket.
Secret Key
The private access key that is required to access the AWS
S3 bucket.
Directory Prefix
The location of the root directory on the Cisco Umbrella
storage bucket from where the Cisco Umbrella logs are
retrieved. For example, the root directory location might
be dnslogs/.
File Pattern
.*?\.csv\.gz
Event Format
Select Cisco Umbrella CSV from the list. The log source
retrieves CSV formatted events.
282
QRadar DSM Configuration Guide
Table 161. Amazon AWS S3 REST API log source parameters (continued)
Parameter
Value
Use Proxy
If QRadar accesses the Amazon Web Service by using a
proxy, enable the check box.
If the proxy requires authentication, configure the Proxy
Server, Proxy Port, Proxy Username, and Proxy
Password fields. If the proxy does not require
authentication, configure the Proxy Username and Proxy
Password fields.
Automatically Acquire Server Certificate(s)
If you select Yes, QRadar automatically downloads the
server certificate and begin trusting the target server.
This option can be used to initialize a newly created log
source, obtain certificates, and replace expired
certificates.
Recurrence
How often the Amazon AWS S3 REST API Protocol
connects to the Amazon cloud API, checks for new files,
and retrieves them if they exist. Every access to an AWS
S3 bucket incurs a cost to the account that owns the
bucket. Therefore, a smaller recurrence value increases
the cost.
Type a time interval to determine how frequently the
remote directory is scanned for new event log files. The
minimum value is 1 minute. The time interval can
include values in hours (H), minutes (M), or days (D).
For example: 2H = 2 hours, 15M = 15 minutes.
EPS Throttle
The maximum number of events per second.
The default is 5000.
Related concepts:
“Configure Cisco Umbrella to communicate with QRadar”
QRadar collects Cisco Umbrella events from an Amazon S3 bucket. You need to configure your Cisco
Umbrella to forward events to QRadar.
“Cisco Umbrella DSM specifications” on page 284
The following table describes the specifications for the Cisco Umbrella DSM.
“Sample event messages” on page 284
Use these sample event messages as a way of verifying a successful integration with QRadar.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configure Cisco Umbrella to communicate with QRadar
QRadar collects Cisco Umbrella events from an Amazon S3 bucket. You need to configure your Cisco
Umbrella to forward events to QRadar.
Follow the procedures that are mentioned in Cisco online documentation to configure your Cisco
Umbrella:
Cisco Umbrella Log Management in Amazon S3(https://support.umbrella.com/hc/en-us/articles/
231248448-Cisco-Umbrella-Log-Management-in-Amazon-S3.
35 Cisco
283
Cisco Umbrella DSM specifications
The following table describes the specifications for the Cisco Umbrella DSM.
Table 162. Cisco Umbrella DSM specifications
Specification
Value
Manufacturer
Cisco
DSM name
Cisco Umbrella
RPM file name
DSM-CiscoUmbrella-QRadar_versionbuild_number.noarch.rpm
Supported versions
N/A
Protocol
Amazon AWS S3 REST API
Event format
Cisco Umbrella CSV
Recorded event types
Audit
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Cisco Umbrella product information page
(https://umbrella.cisco.com)
Sample event messages
Use these sample event messages as a way of verifying a successful integration with QRadar.
The following tables provide sample event messages for the Cisco Umbrella DSM:
Table 163. Cisco Umbrella sample syslog message
Event name
Low level category
Sample log message
NOERROR
18081 (DNS In Progress)
{"sourceFile":"test_2017-11-17-15-30-dcd8.
csv.gz","EventType":"DNSLog","Timestamp":
"2017-11-17 15:30:27","MostGranularIdenti
ty":"Test","Identities":"Test","Internal
Ip":"<IP_address>","ExternalIp":
"<External_IP_address>","Action":
"Allowed","QueryType":"28
(AAAA)","ResponseCode":"NOERROR","Domain"
:"abc.aws.amazon.com.","Categories":
"Ecommerce/Shopping"}
Table 164. Cisco Umbrella sample event message
Event name
Low level category
Sample log message
NOERROR
18081 (DNS In Progress)
"2015-01-16 17:48:41","Active
DirectoryUserName","ActiveDirectoryUser
Name,ADSite,Network","<IP_address1>",
"<IP_address2>","Allowed","1 (A)",
"NOERROR","domain-visited.com.",
"Chat,Photo Sharing,Social Network
ing,Allow List"
Cisco VPN 3000 Concentrator
The Cisco VPN 3000 Concentrator DSM for IBM Security QRadar accepts Cisco VPN Concentrator events
by using syslog.
284
QRadar DSM Configuration Guide
About this task
QRadar records all relevant events. Before you can integrate with a Cisco VPN concentrator, you must
configure your device to forward syslog events to QRadar.
To configure your Cisco VPN 3000 Concentrator:
Procedure
1. Log in to the Cisco VPN 3000 Concentrator command-line interface (CLI).
2. Type the following command to add a syslog server to your configuration:
set logging server <IP address>
Where <IP address> is the IP address of QRadar or your Event Collector.
3. Type the following command to enable system messages to be logged to the configured syslog
servers:
set logging server enable
4. Set the facility and severity level for syslog server messages:
v
set logging server facility <server_facility_parameter>
v
set logging server severity <server_severity_level>
The configuration is complete. The log source is added to QRadar as Cisco VPN Concentrator events
are automatically discovered. Events that are forwarded to QRadar are displayed on the Log Activity
tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco VPN
3000 Series Concentrators.
About this task
These configuration steps are optional.
To manually configure a log source, take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco VPN 3000 Series Concentrator.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
35 Cisco
285
Table 165. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco VPN 3000 Series Concentrators.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco Wireless Services Module
You can integrate a Cisco Wireless Services Module (WiSM) device with IBM Security QRadar.
A Cisco WiSM DSM for QRadar accepts events by using syslog. Before you can integrate QRadar with a
Cisco WiSM device, you must configure Cisco WiSM to forward syslog events.
Configuring Cisco WiSM to forward events
You can configure Cisco WiSM to forward syslog events to IBM Security QRadar.
About this task
Take the following steps to configure Cisco WiSM to forward syslog events:
Procedure
1. Log in to the Cisco Wireless LAN Controller user interface.
2. Click Management > Logs > Config.
The Syslog Configuration window is displayed.
3. In the Syslog Server IP Address field, type the IP address of the QRadar host that receives the
syslog messages.
4. Click Add.
5. Using the Syslog Level list, set the severity level for filtering syslog messages to the syslog servers
by using one of the following severity levels:
v Emergencies - Severity level 0
v Alerts - Severity level 1 (Default)
v Critical - Severity level 2
v Errors - Severity level 3
v Warnings - Severity level 4
v Notifications - Severity level 5
v Informational - Severity level 6
v Debugging - Severity level 7
If you set a syslog level, only those messages whose severity level is equal to or less than the
selected syslog level are sent to the syslog server. For example, if you set the syslog level to
Warnings (severity level 4), only those messages whose severity is 0 - 4 are sent to the syslog
servers.
6. From the Syslog Facility list, set the facility for outgoing syslog messages to the syslog server by
using one of the following facility levels:
v Kernel - Facility level 0
v User Process - Facility level 1
v Mail - Facility level 2
286
QRadar DSM Configuration Guide
v System Daemons - Facility level 3
v Authorization - Facility level 4
v Syslog - Facility level 5 (default value)
v Line Printer - Facility level 6
v USENET - Facility level 7
v Unix-to-Unix Copy - Facility level 8
v Cron - Facility level 9
v FTP Daemon - Facility level 11
v System Use 1 - Facility level 12
v System Use 2 - Facility level 13
v System Use 3 - Facility level 14
v System Use 4 - Facility level 15
v Local Use 0 - Facility level 16
v Local Use 1 - Facility level 17
v Local Use 2 - Facility level 18
v Local Use 3 - Facility level 19
v Local Use 4 - Facility level 20
v Local Use 5 - Facility level 21
v Local Use 6 - Facility level 22
v Local Use 7 - Facility level 23
7. Click Apply.
8. From the Buffered Log Level and the Console Log Level lists, select the severity level for log
messages sent to the controller buffer and console by using one of the following severity levels:
v Emergencies - Severity level 0
v Alerts - Severity level 1
v Critical - Severity level 2
v Errors - Severity level 3 (default value)
v Warnings - Severity level 4
v Notifications - Severity level 5
v Informational - Severity level 6
v Debugging - Severity level 7
If you set a logging level, only those messages whose severity is equal to or less than that level are
logged by the controller. For example, if you set the logging level to Warnings (severity level 4), only
those messages whose severity is 0 - 4 are logged.
9. Select the File Info check box if you want the message logs to include information about the source
file. The default value is enabled.
10. Select the Proc Info check box if you want the message logs to include process information. The
default value is disabled.
11. Select the Trace Info check box if you want the message logs to include trace back information. The
default value is disabled.
12. Click Apply to commit your changes.
13. Click Save Configuration to save your changes.
The configuration is complete. The log source is added to QRadar as Cisco WiSM events are
automatically discovered. Events that are forwarded by Cisco WiSM are displayed on the Log
Activity tab of QRadar.
35 Cisco
287
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Cisco
WiSM.
About this task
The following configuration steps are optional.
To manually configure a log source for Cisco WiSM, take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Wireless Services Module (WiSM).
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 166. Syslog Protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco WiSM appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Cisco Wireless LAN Controllers
The Cisco Wireless LAN Controllers DSM for IBM Security QRadarcollects events that are forwarded
from Cisco Wireless LAN Controller devices by using syslog or SNMPv2.
This section includes the following topics:
v “Configuring syslog for Cisco Wireless LAN Controller” on page 289
v “Configuring SNMPv2 for Cisco Wireless LAN Controller” on page 290
Before you begin
If you collect events from Cisco Wireless LAN Controllers, select the best collection method for your
configuration. The Cisco Wireless LAN Controller DSM for QRadar supports both syslog and SNMPv2
events. However, syslog provides all available Cisco Wireless LAN Controller events, whereas SNMPv2
sends only a limited set of security events to QRadar.
288
QRadar DSM Configuration Guide
Configuring syslog for Cisco Wireless LAN Controller
You can configure the Cisco Wireless LAN Controller to forward syslog events to IBM Security QRadar.
Procedure
1. Log in to your Cisco Wireless LAN Controller interface.
2. Click the Management tab.
3. From the menu, select Logs > Config.
4. In the Syslog Server IP Address field, type the IP address of your QRadar Console.
5. Click Add.
6. From the Syslog Level list, select a logging level.
The Information logging level allows the collection of all Cisco Wireless LAN Controller events above
the Debug logging level.
7. From the Syslog Facility list, select a facility level.
8. Click Apply.
9. Click Save Configuration.
What to do next
You are now ready to configure a syslog log source for Cisco Wireless LAN Controller.
Configuring a syslog log source in IBM Security QRadar
QRadar does not automatically discover incoming syslog events from Cisco Wireless LAN Controllers.
You must create a log source for each Cisco Wireless LAN Controller that provides syslog events to
QRadar.
About this task
To configure a log source in QRadar, take the following steps:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Cisco Wireless LAN Controllers.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 167. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco Wireless LAN Controller.
Enabled
Select the Enabled check box to enable the log source. By default, the check box is
selected.
35 Cisco
289
Table 167. Syslog protocol parameters (continued)
Parameter
Description
Credibility
From the list, select the credibility of the log source. The range is 0 - 10. The
credibility indicates the integrity of an event or offense as determined by the
credibility rating from the source devices. Credibility increases if multiple sources
report the same event. The default is 5.
Target Event Collector
From the list, select the Target Event Collector to use as the target for the log
source.
Coalescing Events
Select this check box to enable the log source to coalesce (bundle) events.
Automatically discovered log sources use the default value that is configured in the
Coalescing Events drop-down list in the QRadar Settings window on the Admin
tab. However, when you create a new log source or update the configuration for an
automatically discovered log source that you can override the default value by
configuring this check box for each log source. For more information on settings,
see the IBM Security QRadar Administration Guide.
Incoming Event Payload
From the list, select the incoming payload encoder for parsing and storing the logs.
Store Event Payload
Select this check box to enable or disable QRadar from storing the event payload.
Automatically discovered log sources use the default value from the Store Event
Payload drop-down list in the QRadar Settings window on the Admin tab.
However, when you create a new log source or update the configuration for an
automatically discovered log source that you can override the default value by
configuring this check box for each log source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Configuring SNMPv2 for Cisco Wireless LAN Controller
SNMP event collection for Cisco Wireless LAN Controllers allows the capture of events for IBM Security
QRadar
About this task
The following events are collected:
v SNMP Config Event
v bsn Authentication Errors
v LWAPP Key Decryption Errors
Procedure
1. Log in to your Cisco Wireless LAN Controller interface.
2. Click the Management tab.
3. From the menu, select SNMP > Communities.
You can use the one of the default communities that are created or create a new community.
4. Click New.
5. In the Community Name field, type the name of the community for your device.
6. In the IP Address field, type the IP address of QRadar.
The IP address and IP mask that you specify is the address from which your Cisco Wireless LAN
Controller accepts SNMP requests. You can treat these values as an access list for SNMP requests.
7. In the IP Mask field, type a subnet mask.
290
QRadar DSM Configuration Guide
8. From the Access Mode list, select Read Only or Read/Write.
9. From the Status list, select Enable.
10. Click Save Configuration to save your changes.
What to do next
You are now ready to create a SNMPv2 trap receiver.
Configuring a trap receiver for Cisco Wireless LAN Controller
Trap receivers that are configured on Cisco Wireless LAN Controllers define where the device can send
SNMP trap messages.
About this task
To configure a trap receiver on your Cisco Wireless LAN Controller, take the following steps:
Procedure
1. Click the Management tab.
2. From the menu, select SNMP > Trap Receivers.
3. In the Trap Receiver Name field, type a name for your trap receiver.
4. In the IP Address field, type the IP address of IBM Security QRadar.
The IP address you specify is the address to which your Cisco Wireless LAN Controller sends SNMP
messages. If you plan to configure this log source on an Event Collector, you want to specify the
Event Collector appliance IP address.
5. From the Status list, select Enable.
6. Click Apply to commit your changes.
7. Click Save Configuration to save your settings.
What to do next
You are now ready to create a SNMPv2 log source in QRadar.
Configuring a log source for the Cisco Wireless LAN Controller that
uses SNMPv2
IBM Security QRadar does not automatically discover and create log sources for SNMP event data from
Cisco Wireless LAN Controllers. You must create a log source for each Cisco Wireless LAN Controller
providing SNMPv2 events.
About this task
Take the following steps to create a log source for your Cisco Wireless LAN Controller:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
35 Cisco
291
8. From the Log Source Type list, select Cisco Wireless LAN Controllers.
9. Using the Protocol Configuration list, select SNMPv2.
10. Configure the following values:
Table 168. SNMPv2 protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Cisco Wireless LAN Controller.
Community
Type the SNMP community name that is needed to access the system that contains
the SNMP events. The default is Public.
Include OIDs in Event
Payload
Select the Include OIDs in Event Payload check box.
This option allows the SNMP event payload to be constructed by using name-value
pairs instead of the standard event payload format. OIDs in the event payload are
needed to process SNMPv2 or SNMPv3 events from certain DSMs.
Enabled
Select the Enabled check box to enable the log source. By default, the check box is
selected.
Credibility
From the list, select the credibility of the log source. The range is 0 - 10. The
credibility indicates the integrity of an event or offense as determined by the
credibility rating from the source devices. Credibility increases if multiple sources
report the same event. The default is 5.
Target Event Collector
From the list, select the Target Event Collector to use as the target for the log
source.
Coalescing Events
Select this check box to enable the log source to coalesce (bundle) events.
Automatically discovered log sources use the default value that is configured in the
Coalescing Events drop-down in the QRadar Settings window on the Admin tab.
However, when you create a new log source or update the configuration for an
automatically discovered log source, you can override the default value by
configuring this check box for each log source. For more information on settings,
see the IBM Security QRadar Administration Guide.
Store Event Payload
Select this check box to enable or disable QRadar from storing the event payload.
Automatically discovered log sources use the default value from the Store Event
Payload drop-down in the QRadar Settings window on the Admin tab. However,
when you create a new log source or update the configuration for an automatically
discovered log source, you can override the default value by configuring this check
box for each log source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete. Events that are forwarded to by Cisco Wireless LAN Controller are
displayed on the Log Activity tab of QRadar.
292
QRadar DSM Configuration Guide
36 Citrix
Citrix NetScaler and Citrix Access Gateway DSMs.
The Citrix NetScaler DSM for IBM Security QRadar accepts all relevant audit log events by using syslog.
The Citrix Access Gateway DSM accepts access, audit, and diagnostic events that are forwarded from
your Citrix Access Gateway appliance by using syslog.
Citrix NetScaler
To integrate Citrix NetScaler events with IBM Security QRadar, you must configure Citrix NetScaler to
forward syslog events.
Procedure
1. Using SSH, log in to your Citrix NetScaler device as a root user.
2. Type the following command to add a remote syslog server:
add audit syslogAction <ActionName> <IP Address> -serverPort 514 -logLevel Info -dateFormat
DDMMYYYY
Where:
<ActionName> is a descriptive name for the syslog server action.
<IP Address> is the IP address or host name of your QRadar Console.
Example:
add audit syslogAction action-QRadar 192.0.2.1 -serverPort 514
-logLevel Info -dateFormat DDMMYYYY
3. Type the following command to add an audit policy:
add audit syslogPolicy <PolicyName> <Rule> <ActionName>
Where:
<PolicyName> is a descriptive name for the syslog policy.
<Rule> is the rule or expression the policy uses. The only supported value is ns_true.
<ActionName> is a descriptive name for the syslog server action.
Example:
add audit syslogPolicy policy-QRadar ns_true action-QRadar
4. Type the following command to bind the policy globally:
bind system global <PolicyName> -priority <Integer>
Where:
<PolicyName> is a descriptive name for the syslog policy.
<Integer> is a number value that is used to rank message priority for multiple policies that are
communicating by using syslog.
Example:
bind system global policy-QRadar -priority 30
When multiple policies have priority (represented by a number value that is assigned to them) the
lower number value is evaluated before the higher number value.
5. Type the following command to save the Citrix NetScaler configuration.
© Copyright IBM Corp. 2005, 2018
293
save config
6. Type the following command to verify that the policy is saved in your configuration:
sh system global
Note: For information on configuring syslog by using the Citrix NetScaler user interface, see
http://support.citrix.com/article/CTX121728 or your vendor documentation.
The configuration is complete. The log source is added to QRadar as Citrix NetScaler events are
automatically discovered. Events that are forwarded by Citrix NetScaler are displayed on the Log
Activity tab of QRadar.
Configuring a Citrix NetScaler log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Citrix
NetScaler.
About this task
This procedure is optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Citrix NetScaler.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 169. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events
from your Citrix NetScaler devices.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
Citrix Access Gateway
Configuration of syslog on your Citrix Access Gateway to forward events to the QRadar Console or
Event Collector.
Procedure
1. Log in to your Citrix Access Gateway web interface.
2. Click the Access Gateway Cluster tab.
3. Select Logging/Settings.
4. In the Server field, type the IP address of your QRadar Console or Event Collector.
5. From the Facility list, select a syslog facility level.
6. In the Broadcast interval (mins), type 0 to continuously forward syslog events to QRadar.
294
QRadar DSM Configuration Guide
7. Click Submit to save your changes.
Results
The configuration is complete. The log source is added to QRadar as Citrix Access Gateway events are
automatically discovered. Events that are forwarded to QRadar by Citrix Access Gateway are displayed
on the Log Activity tab in QRadar.
Configuring a Citrix Access Gateway log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Citrix
Access Gateway appliances.
About this task
This procedure is optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Citrix Access Gateway.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 170. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events
from your Citrix Access Gateway appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
36 Citrix
295
296
QRadar DSM Configuration Guide
37 Cloudera Navigator
The IBM Security QRadar DSM for Cloudera Navigator collects events from Cloudera Navigator.
The following table identifies the specifications for the Cloudera Navigator DSM:
Table 171. Cloudera Navigator DSM specifications
Specification
Value
Manufacturer
Cloudera
DSM name
Cloudera Navigator
RPM file name
DSM-ClouderaNavigator-Qradar_versionbuild_number.noarch.rpm
Supported versions
v2.0
Protocol
Syslog
Recorded event types
Audit events for HDFS, HBase, Hive, Hue, Cloudera
Impala, Sentry
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Cloudera Navigator website (www.cloudera.com)
To integrate Cloudera Navigator with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Cloudera Navigator DSM RPM
2. Configure your Cloudera Navigator device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a Cloudera Navigator log source on the
QRadar Console. The following table describes the parameters that require specific values for
Cloudera Navigator event collection:
Table 172. Cloudera Navigator log source parameters
Parameter
Value
Log Source type
Cloudera Navigator
Protocol Configuration
Syslog
Log Source Identifier
The IP address or host name in the Syslog header. Use
the packet IP address, if the Syslog header does not
contain an IP address or host name.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
© Copyright IBM Corp. 2005, 2018
297
Configuring Cloudera Navigator to communicate with QRadar
You can configure Cloudera Navigator device to send JSON format syslog events to IBM Security
QRadar.
Before you begin
Ensure that Cloudera Navigator can access port 514 on the QRadar system.
About this task
When you install Cloudera Navigator, all audit logs are collected automatically. However, you must
configure Cloudera Navigator to send audits logs to QRadar by using syslog.
Procedure
1. Do one of the following tasks:
v Click Clusters > Cloudera Management Service > Cloudera Management Service.
v On the Status tab of the Home page, click the Cloudera Management Service link in Cloudera
Management Service table.
2. Click the Configuration tab.
3. Search for Navigator Audit Server Logging Advanced Configuration Snippet.
4. Depending on the format type, enter one of the following values in the Value field:
v log4j.logger.auditStream = TRACE,SYSLOG
v log4j.appender.SYSLOG = org.apache.log4j.net.SyslogAppender
v log4j.appender.SYSLOG.SyslogHost = <QRadar Hostname>
v log4j.appender.SYSLOG.Facility = Local2
v log4j.appender.SYSLOG.FacilityPrinting = true
v log4j.additivity.auditStream = false
5. Click Save Changes.
298
QRadar DSM Configuration Guide
38 CloudPassage Halo
The CloudPassage Halo DSM for IBM Security QRadar can collect event logs from the CloudPassage
Halo account.
The following table identifies the specifications for the CloudPassage Halo DSM:
Table 173. CloudPassage Halo DSM Specifications
Specification
Value
Manufacturer
CloudPassage
DSM name
CloudPassage Halo
RPM file name
DSM-CloudPassageHalo-build_number.noarch.rpm
Supported versions
All
Event format
Syslog, Log file
QRadar recorded event types
All events
Automatically discovered?
Yes
Included identity?
No
More information
CloudPassage website (www.cloudpassage.com)
To integrate CloudPassage Halo with QRadar, use the following steps:
1. If automatic updates are not enabled, download the latest versions of the following RPMs:
v DSMCommon RPM
v CloudPassage Halo RPM
2. Configure your CloudPassage Halo to enable communication with QRadar.
3. If QRadar does not automatically detect CloudPassage Halo as a log source, create a CloudPassage
Halo log source on the QRadar Console.
Configuring CloudPassage Halo for communication with QRadar
To collect CloudPassage Halo events, download and configure the CloudPassage Halo Event Connector
script to send syslog events to QRadar.
Before you begin
Before you can configure the Event Connector, you must create a read-only CloudPassage API key. To
create a read-only key, log in to your CloudPassage Portal and click Add New Key on the Site
Administration window.
About this task
The Event Connector script requires Python 2.6 or later to be installed on the host on which the Event
Connector script runs. The Event Connector makes calls to the CloudPassage Events API, which is
available to all Halo subscribers.
Note: You can configure the CloudPassage Halo Event Collect to write the events to file for QRadar to
retrieve by using the Log File Protocol, however, this method is not recommended.
© Copyright IBM Corp. 2005, 2018
299
Procedure
1. Log in to the CloudPassage Portal.
2. Go to Settings > Site Administration.
3. Click the API Keys tab.
4. Click Show for the key you want to use.
5. Copy the key ID and secret key into a text file.
Ensure that the file contains only one line, with the key ID and the secret key separated by a vertical
bar/pipe (|), for example, your_key_id|your_secret_key. If you want to retrieve events from
multiple Halo accounts, add an extra line for each account.
6. Save the file as haloEvents.auth.
7. Download the Event Connector script and associated files from https://github.com/cloudpassage/
halo-event-connector-python.
8. Copy the following files to a Linux or Windows system that has Python 2.6 (or later) installed:
v haloEvents.py
v cpapi.py
v cputils.py
v remote_syslog.py (use this script only if you deploy the Event Connector on Windows and you
want to send events through syslog)
v haloEvents.auth
9. Set the environment variables on the Linux or Windows system:
v On Linux, include the full path to the Python interpreter in the PATH environment variable.
v On Windows, set the following variables:
– Set the PATH variable to include the location of haloEvents.py and the Python interpreter.
– Set the PYTHONPATH variable to include the location of the Python libraries and the Python
interpreter.
10. To send events through syslog with the Event Connector is deployed on a Windows system, run the
haloEvents.py script with the --leefsyslog=<QRadar IP> switch:
haloEvents.py --leefsyslog=192.0.2.1
By default, the Event Connector retrieves existing events on initial connection and then retrieves
onlynew events thereafter. To start event retrieval from a specific date, rather than retrieving all
historical events on startup, use the --starting=<date> switch, where date is in the YYYY-MM-DD
format:
haloEvents.py --leefsyslog=192.0.2.1 --starting=2014-04-02
11. To send events through syslog and deploy the Event Connector on a Linux system, configure the
local logger daemon.
a. To check which logger the system uses, type the following command:
ls -d /etc/*syslog*
Depending on what Linus distribution you have, the following files might be listed:
v
– rsyslog.conf
– syslog-ng.conf
– syslog.conf
b. Edit the appropriate .conf file with relevant information for your environment.
Example configuration for syslog-ng:
source s_src {
file("/var/log/leefEvents.txt");
};
destination d_qradar {
300
QRadar DSM Configuration Guide
udp("qradar_hostname" port(514));
};
log {
source(s_src); destination(d_qradar);
};
c. To run the haloEvents.py script with the leeffile=<filepath> switch, type the following
command:
haloEvents.py --leeffile=/var/log/leefEvents.txt
You can include --starting=YYYY-MM-DD switch to specify the date from which you want events
to be collected for on initial startup.
Note: As an alternative to using syslog, you can write events to a file for QRadar to retrieve by
using the Log File protocol. For Windows or Linux to write the events to a file instead, use the
--leeffile=<filename> switch to specify the file to write to.
Configuring a CloudPassage Halo log source in QRadar
To collect CloudPassage Halo events, configure a log source in QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. From the Log Source Type list, select CloudPassage Halo.
7. From the Protocol Configuration list, select Syslog or Log File.
8. Configure the remaining parameters:
9. Click Save.
10. On the Admin tab, click Deploy Changes.
38 CloudPassage Halo
301
302
QRadar DSM Configuration Guide
39 CloudLock Cloud Security Fabric
The IBM Security QRadar DSM for CloudLock Cloud Security Fabric collects events from the CloudLock
Cloud Security Fabric service.
The following table describes the specifications for the CloudLock Cloud Security Fabric DSM:
Table 174. CloudLock Cloud Security Fabric DSM specifications
Specification
Value
Manufacturer
CloudLock
DSM name
CloudLock Cloud Security Fabric
RPM file name
DSM-CloudLockCloudSecurityFabric-Qradar_versionbuild_number.noarch.rpm
Supported versions
NA
Protocol
Syslog
Event format
Log Event Extended Format (LEEF)
Recorded event types
Incidents
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Cloud Cybersecurity (https://www.cloudlock.com/
products/)
To integrate CloudLock Cloud Security Fabric with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console in the order that they are listed:
v DSMCommon RPM
v CloudLock Cloud Security Fabric DSM RPM
2. Configure your CloudLock Cloud Security Fabric service to send Syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a CloudLock Cloud Security Fabric log
source on the QRadar Console. The following table describes the parameters that require specific
values for CloudLock Cloud Security Fabric event collection:
Table 175. CloudLock Cloud Security Fabric log source parameters
Parameter
Value
Log Source type
CloudLock Cloud Security Fabric
Protocol Configuration
Syslog
The following table provides a sample event message for the CloudLock Cloud Security Fabric DSM:
© Copyright IBM Corp. 2005, 2018
303
Table 176. CloudLock Cloud Security Fabric sample message supported by the CloudLock Cloud Security Fabric
service
Event name
Low level category
Sample log message
New Incident
Suspicious Activity
LEEF: 1.0|Cloudlock|API|v2|Incidents|
match_count=2 sev=1 entity_id=ebR4q6DxvA entity_origin
_type=document group=None url=https://example.com/
a/path/file/d/<File_path_ID/
view?usp=drivesdk CloudLockID=xxxxxxxxxx updated_at=
2016¬01-20T15:42:15.128356+0000 entity_owner_email=
user@example.com cat=NEW entity_origin_id=
<File_path_ID> entity_mime_type=text/
plain devTime=2016¬01-20T15:42:14.913178+0000
policy=Custom Regex resource=confidential.txt usrName=
Admin Admin realm=domain policy_id=xxxxxxxxxx
devTimeFormat=yyyy¬MM-dd’T’HH:mm:ss.SSSSSSZ
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring CloudLock Cloud Security Fabric to communicate with
QRadar
You can configure CloudLock Cloud Security Fabric to communicate with QRadar by using a Python
script.
Before you begin
v To collect incidents from CloudLock, a script that makes CloudLock API calls is required. This script
collects incidents and coverts them to Log Event Extended Format (LEEF).
v Python is required.
Procedure
1. Generate a CloudLock API token. To generate an API token in CloudLock, open the Settings. Go to
the Integrations panel. Copy the Access token that appears on the page.
2. Go to the CloudLock Support website (https://www.cloudlock.com/support/). Open a support case
to obtain the cl_sample_incidents.py file and then schedule the script for event collection.
304
QRadar DSM Configuration Guide
40 Correlog Agent for IBM z/OS
The CorreLog Agent for IBM z/OS DSM for IBM Security QRadar can collect event logs from your IBM
z/OS servers.
The following table identifies the specifications for the CorreLog Agent for IBM z/OS DSM:
Specification
Value
Manufacturer
CorreLog
DSM name
CorreLog Agent for IBM z/OS
RPM file name
DSM-CorreLogzOSAgent_qradar-version_buildnumber.noarch.rpm
Supported versions
7.1
7.2
Protocol
Syslog LEEF
QRadar recorded events
All events
Automatically discovered
Yes
Includes identity
No
Includes custom event properties
No
More information
Correlog website (https://correlog.com/solutions-andservices/sas-correlog-mainframe.html)
To integrate CorreLog Agent for IBM z/OS DSM with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent CorreLog Agent for IBM
z/OS RPM on your QRadar Console.
2. For each CorreLog Agent instance, configure your CorreLog Agent system to enable communication
with QRadar.
3. If QRadar does not automatically discover the DSM,, create a log source on the QRadar Console for
each CorreLog Agent system you want to integrate. Configure all the required parameters, but use the
following table for specific Correlog values:
Parameter
Description
Log Source Type
CorreLog Agent for IBM zOS
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
© Copyright IBM Corp. 2005, 2018
305
Configuring your CorreLog Agent system for communication with
QRadar
For the procedure to configure your Correlog Agent system for communication with QRadar, see the
CZA - CorreLog Agent for z/OS manual that you received from CorreLog with your Agent for z/OS
software distribution.
About this task
Use the following sections of the CZA - CorreLog Agent for z/OS manual:
v General considerations in Section 1: Introduction.
v Procedure in Section 2: Installation.
v Procedure in the Section 3: Configuration.
Ensure that you complete the Tailoring the Installation for a Proprietary Syslog Extension/IBM
Security QRadar instructions.
When you start the CorreLog agent, if QRadar does not collect z/OS events, see the Troubleshooting
topic in Section 3.
v If you want to customize the optional CorreLog Agent parameter file, review QRadar normalized event
attributes in Appendix G: Fields.
306
QRadar DSM Configuration Guide
41 CrowdStrike Falcon Host
The IBM Security QRadar DSM for CrowdStrike Falcon Host collects LEEF events that are forwarded by
a Falcon SIEM Connector.
The following table describes the specifications for the CrowdStrike Falcon Host DSM:
Table 177. CrowdStrike Falcon Host DSM specifications
Specification
Value
Manufacturer
CrowdStrike
DSM name
CrowdStrike Falcon Host
RPM file name
DSM-CrowdStrikeFalconHost-QRadar_versionbuild_number.noarch.rpm
Supported versions
N/A
Protocol
Syslog
Event format
LEEF
Recorded event types
Falcon Host Detection Summary
Falcon Host Authentication Log
Falcon Host Detect Status Update Logs
Customer IOC Detect Event
Hash Spreading Event
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
CrowdStrike website (https://www.crowdstrike.com/
products/falcon-host/
To integrate CrowdStrike Falcon Host with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs in the order that they are listed, on your QRadar Console:
v DSMCommon RPM
v CrowdStrike Falcon Host DSM RPM
2. Install and configure your Falcon SIEM connector to send events to QRadar.
3. If QRadar does not automatically detect the log source, add a CrowdStrike Falcon Host log source on
the QRadar Console. The following table describes the parameters that require specific values for
CrowdStrike Falcon Host event collection:
Table 178. CrowdStrike Falcon Host log source parameters
Parameter
Value
Log Source type
CrowdStrike Falcon Host
Protocol Configuration
Syslog
Log Source Identifier
The IP address or host name where the Falcon SIEM
Connector is installed.
© Copyright IBM Corp. 2005, 2018
307
The following table shows a sample event message from CrowdStrike Falcon Host:
Table 179. CrowdStrike Falcon Host sample message
Event name
Low level category
Sample log message
Suspicious Activity
Suspicious Activity
LEEF:1.0|CrowdStrike|FalconHost
|1.0|Suspicious Activity|
devTime=2016-06-09 02:57:28
src=<Source_IP_address>
srcPort=49220
dst=<Destination_IP_address> domain=INITECH
cat=NetworkAccesses
usrName=<Username>
devTimeFormat=yyyy-MM-dd HH:mm:ss
connDir=0 dstPort=443
resource=<Resource>
proto=TCP url=https:
//example.com/url
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring CrowdStrike Falcon Host to communicate with QRadar
To send LEEF events from CrowdStrike Falcon Host to IBM Security QRadar, you must install and
configure Falcon SIEM connector.
Before you begin
You must have access with administrator privileges to the Falcon Streaming API. To enable access, contact
Crowdstrike support (support@crowdstrike.com).
Procedure
1. Obtain an API key and UUID to configure SIEM Connector.
a. Log in to the Falcon user interface.
b. Select People App, and then click the Customer tab. The People App option is only visible to
admin users.
c. Click Generate new API key.
d. Make a copy of the API key and the UUID.
2. Install the Falcon SIEM Connector.
Note: The Falcon SIEM Connector needs to be deployed on premise on a system running either
CentOS or RHEL 6.x-7.x. Internet connectivity to the CrowdStrike Cloud is also required.
Note: You must have Admin (root) privileges.
v Use the provided RPM to install the Falcon SIEM Connector.
rpm -Uhv /path/to/file/cs.falconhoseclient-<build_version>.<OS_version>.rpm
The Falcon SIEM Connector installs in the /opt/crowdstrike/ directory by default.
A service is created in the /etc/init.d/cs.falconhoseclientd/ directory.
3. Configure the SIEM Connector to forward LEEF events to QRadar. The configuration files are located
in the /opt/crowdstrike/etc/ directory.
308
QRadar DSM Configuration Guide
v Rename cs.falconhoseclient.leef.cfg to cs.falconhoseclient.cfg for LEEF configuration
settings. The SIEM Connector uses cs.falconhoseclient.cfg configuration by default.
The following table describes some of the key parameter values for forwarding LEEF events to
QRadar.
Table 180. Key parameter values
Key
Description
Value
version
The version of authentication to be
used. In this case, it is the API Key
Authentication version.
2
api_url
The SIEM connector connects to this
endpoint URL.
https://firehose.crowdstrike.com/
sensors/entities/datafeed/v1
app_id
An arbitrary string identifier for
connecting to Falcon Streaming API.
Any string. For example,
FHAPI-LEEF
api_key
The API key is used as the credential
for client verification.
Obtained at step 1
api_uuid
The UUID is used as the credential
for client verification.
Obtained at step 1
send_to_syslog_server
To enable or disable syslog push to
syslog server, set the flag to true or
false.
true
host
The IP or host name of the SIEM.
The QRadar SIEM IP or host name
where the Connector is forwarding
the LEEF events.
header_delim
Header prefix and fields are
delimited by this value.
The value must be a pipe (|).
field_delim
The delimiter value that is used to
separate key-value pairs.
The value must be a tab (\t).
time_fields
This datetime field value is converted The default field is devTime (device
to specified time format.
time). If a custom LEEF key is used
for setting device time, use a different
field name .
4. Start the SIEM Connector service by typing the following command:
service cs.falconhoseclientd start
a. If you want to stop the service, type the following command:
service cs.falconhoseclientd stop
b. If you want to restart the service, type the following command:
service cs.falconhoseclientd restart
What to do next
Verify that Falcon SIEM Connector is configured to send events to QRadar.
41 CrowdStrike Falcon Host
309
310
QRadar DSM Configuration Guide
42 CRYPTOCard CRYPTO-Shield
The IBM Security QRadar CRYPTOCard CRYPTO-Shield DSM for QRadar accepts events by using syslog.
To integrate CRYPTOCard CRYPTO-Shield events with QRadar, you must manually create a log source to
receive syslog events.
Before you can receive events in QRadar, you must configure a log source, then configure your
CRYPTOCard CRYPTO-Shield to forward syslog events. Syslog events that are forwarded from
CRYPTOCard CRYPTO-Shield devices are not automatically discovered. QRadar can receive syslog events
on port 514 for both TCP and UDP.
Configuring a log source
IBM Security QRadar does not automatically discover or create log sources for syslog events from
CRYPTOCard CRYPTO-Shield devices.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select CRYPTOCard CRYPTOShield.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 181. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as
an identifier for events from your CRYPTOCard
CRYPTO-Shield device.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
Configuring syslog for CRYPTOCard CRYPTO-Shield
To configure your CRYPTOCard CRYPTO-Shield device to forward syslog events:
Procedure
1. Log in to your CRYPTOCard CRYPTO-Shield device.
2. Configure the following System Configuration parameters:
Important: You must have CRYPTOCard Operator access with the assigned default Super-Operator
system role to access the System Configuration parameters.
v log4j.appender.<protocol> - Directs the logs to a syslog host where:
© Copyright IBM Corp. 2005, 2018
311
–
<protocol> is the type of log appender, that determines where you want to send logs for storage.
The options are as follows: ACC, DBG, or LOG. For this parameter, type the following entry:
org.apache.log4j.net.SyslogAppender
v log4j.appender.<protocol>.SyslogHost <IP address> - Type the IP address or host name of the
syslog server where:
– <Protocol> is the type of log appender, that determines where you want to send logs for storage.
The options are as follows: ACC, DBG, or LOG.
– <IP address> is the IP address of the IBM Security QRadar host to which you want to send logs.
Specify the IP address parameter after the log4j.apender.<protocol> parameter is configured.
The configuration is complete. Events that are forwarded to QRadar by CRYPTOCard CRYPTO-Shield
are displayed on the Log Activity tab.
312
QRadar DSM Configuration Guide
43 CyberArk
IBM Security QRadar supports several CyberArk DSMs.
CyberArk Privileged Threat Analytics
The IBM Security QRadar DSM for CyberArk Privileged Threat Analytics collects events from a CyberArk
Privileged Threat Analytics device.
The following table describes the specifications for the CyberArk Privileged Threat Analytics DSM:
Table 182. CyberArk Privileged Threat Analytics DSM specifications
Specification
Value
Manufacturer
CyberArk
DSM name
CyberArk Privileged Threat Analytics
RPM file name
DSM-CyberArkPrivilegedThreatAnalyticsQradar_version-build_number.noarch.rpm
Supported versions
V3.1
Protocol
Syslog
Recorded event types
Detected security events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
CyberArk website (http://www.cyberark.com)
To integrate CyberArk Privileged Threat Analytics with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v CyberArk Privileged Threat Analytics DSM RPM
v DSMCommon RPM
2. Configure your CyberArk Privileged Threat Analytics device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a CyberArk Privileged Threat Analytics
log source on the QRadar Console. The following table describes the parameters that require specific
values for CyberArk Privileged Threat Analytics event collection:
Table 183. CyberArk Privileged Threat Analytics log source parameters
Parameter
Value
Log Source type
CyberArk Privileged Threat Analytics
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
© Copyright IBM Corp. 2005, 2018
313
Configuring CyberArk Privileged Threat Analytics to communicate with
QRadar
To collect all events from CyberArk Privileged Threat Analytics, you must specify IBM Security QRadar
as the syslog server and configure the syslog format. The CyberArk Privileged Threat Analytics device
sends syslog events that are formatted as Log Event Extended Format (LEEF).
Procedure
1. On the CyberArk Privileged Threat Analytics machine, go to the /opt/tomcat/diamond-resources/
local/ directory, and open the systemparm.properties file in a text editor such as vi.
2. Uncomment the syslog_outbound property and then edit the following parameters:
Parameter
Value
Host
The host name or IP address of the QRadar system.
Port
514
Protocol
UDP
Format
QRadar
Example: The following is an example of the syslog_outbound property:
syslog_outbound=[{"host": "SIEM_MACHINE_ADDRESS", "port": 514, "format": "QRadar",
"protocol": "UDP"}]
Example: The following is an example of the syslog_outbound property specifying multiple syslog
recipients, separated by commas:
syslog_outbound=[{"host": "SIEM_MACHINE_ADDRESS", "port": 514, "format": "QRadar",
"protocol": "UDP"} , {"host": "SIEM_MACHINE_ADDRESS1", "port": 514, "format": "QRadar",
"protocol": "UDP"} , ...]
3. Save the systemparm.properties configuration file, and then close it.
4. Restart CyberArk Privileged Threat Analytics.
CyberArk Vault
The CyberArk Vault DSM for IBM Security QRadar accepts events by using syslog that is formatted for
Log Enhanced Event Format (LEEF).
QRadar records both user activities and safe activities from the CyberArk Vault in the audit event logs.
CyberArk Vault integrates with QRadar to forward audit logs by using syslog to create a detailed log of
privileged account activities.
Event type format
CyberArk Vault must be configured to generate events in Log Enhanced Event Protocol (LEEF) and to
forward these events by using syslog. The LEEF format consists of a pipe ( | ) delimited syslog header,
and tab separated fields in the log payload section.
If the syslog events from CyberArk Vault are not formatted properly, examine your device configuration
or software version to ensure that your appliance supports LEEF. Properly formatted LEEF event
messages are automatically discovered and added as a log source to QRadar.
Configuring syslog for CyberArk Vault
To configure CyberArk Vault to forward syslog events to IBM Security QRadar:
314
QRadar DSM Configuration Guide
Procedure
1. Log in to your CyberArk device.
2. Edit the DBParm.ini file.
3. Configure the following parameters:
Table 184. Syslog parameters
Parameter
Description
SyslogServerIP
Type the IP address of QRadar.
SyslogServerPort
Type the UDP port that is used to connect to QRadar. The default value
is 514.
SyslogMessageCodeFilter
Configure which message codes are sent from the CyberArk Vault to
QRadar. You can define specific message numbers or a range of
numbers. By default, all message codes are sent for user activities and
safe activities.
Example: To define a message code of 1,2,3,30 and 5-10, you must
type: 1,2,3,5-10,30.
SyslogTranslatorFile
Type the file path to the LEEF.xsl translator file. The translator file is
used to parse CyberArk audit records data in the syslog protocol.
4. Copy LEEF.xsl to the location specified by the SyslogTranslatorFile parameter in the DBParm.ini
file.
Results
The configuration is complete. The log source is added to QRadar as CyberArk Vault events are
automatically discovered. Events that are forwarded by CyberArk Vault are displayed on the Log
Activity tab of QRadar.
Configuring a log source for CyberArk Vault
IBM Security QRadar automatically discovers and creates a log source for syslog events from CyberArk
Vault.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select CyberArk Vault.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
43 CyberArk
315
Table 185. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as
an identifier for events from your CyberArk Vault
appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
316
QRadar DSM Configuration Guide
44 CyberGuard Firewall/VPN Appliance
The CyberGuard Firewall VPN Appliance DSM for IBM Security QRadar accepts CyberGuard events by
using syslog.
QRadar records all relevant CyberGuard events for CyberGuard KS series appliances that are forwarded
by using syslog.
Configuring syslog events
To configure a CyberGuard device to forward syslog events:
Procedure
1. Log in to the CyberGuard user interface.
2. Select the Advanced page.
3. Under System Log, select Enable Remote Logging.
4. Type the IP address of IBM Security QRadar.
5. Click Apply.
The configuration is complete. The log source is added to QRadar as CyberGuard events are
automatically discovered. Events that are forwarded by CyberGuard appliances are displayed on the
Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from CyberGuard
appliances.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select CyberGuard TSP Firewall/VPN.
9. From the Protocol Configuration list, select Syslog.
10. For the Log Source Identifier parameter, enter the IP address or host name for the log source as an
identifier for events from your CyberGuard appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
© Copyright IBM Corp. 2005, 2018
317
318
QRadar DSM Configuration Guide
45 Damballa Failsafe
The Failsafe DSM for IBM Security QRadar accepts syslog events by using the Log Event Extended
Format (LEEF), enabling QRadar to record all relevant Damballa Failsafe events.
Damballa Failsafe must be configured to generate events in Log Event Extended Format(LEEF) and
forward these events by using syslog. The LEEF format consists of a pipe ( | ) delimited syslog header,
and tab separated fields in the log event payload.
If the syslog events that are forwarded from your Damballa Failsafe are not correctly formatted in LEEF
format, you must check your device configuration or software version to ensure that your appliance
supports LEEF. Properly formatted LEEF event messages are automatically discovered and added as a log
source to QRadar.
Configuring syslog for Damballa Failsafe
To collect events, you must configure your Damballa Failsafe device to forward syslog events to IBM
Security QRadar.
Procedure
1. Log in to your Damballa Failsafe Management Console.
2. From the navigation menu, select Setup > Integration Settings.
3. Click the QRadar tab.
4. Select Enable Publishing to IBM Security QRadar.
5. Configure the following options:
v Hostname - Type the IP address or Fully Qualified Name (FQN) of your QRadar Console.
v Destination Port - Type 514. By default, QRadar uses port 514 as the port for receiving syslog
events.
v Source Port - This input is not a requirement. Type the Source Port your Damballa Failsafe device
uses for sending syslog events.
6. Click Save.
The configuration is complete. The log source is added to QRadar as Damballa Failsafe events are
automatically discovered. Events that are forwarded by Damballa Failsafe are displayed on the Log
Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Damballa
Failsafe devices.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
© Copyright IBM Corp. 2005, 2018
319
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Damballa Failsafe.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 186. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Damballa Failsafe devices.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
320
QRadar DSM Configuration Guide
46 DG Technology MEAS
The IBM Security QRadar DSM for DG Technology MEAS can collect event logs from your DG
Technology MEAS servers.
The following table identifies the specifications for the DG Technology MEAS DSM:
Table 187. DSM Specifications for DG Technology MEAS
Specification
Value
Manufacturer
DG Technology
Log source type
DG Technology MEAS
RPM file name
DSM-DGTechnologyMEAS-build_number.noarch.rpm
Supported versions
8.x
Protocol configuration
LEEF Syslog
Supported event types
Mainframe events
Automatically discovered?
Yes
Includes identity?
No
Includes custom event properties
No
More information
DG Technology website (http://www.dgtechllc.com)
To integrate DG Technology MEAS DSM with QRadar, use the following procedures:
1. If automatic updates are not enabled, download and install the most recent DG Technology MEAS
RPM on your QRadar Console.
2. For each instance of DG Technology MEAS, configure your DG Technology MEAS system to enable
communication with QRadar.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring your DG Technology MEAS system for communication
with QRadar
To collect all audit logs and system events from DG Technology MEAS, you must specify QRadar as the
syslog server.
Procedure
1. Log in to your DG Technology MEAS server.
2. Type the following command:
java meas/MeasServer 41000 m=qwl lo=IP_address_of_QRadar_host
© Copyright IBM Corp. 2005, 2018
321
Results
When QRadar receives events from your DG Technology MEAS, a log source is automatically created and
listed on the Log Sources window.
322
QRadar DSM Configuration Guide
47 Digital China Networks (DCN)
The Digital China Networks (DCN) DCS/DCRS Series DSM for IBM Security QRadar can accept events
from Digital China Networks (DCN) switches by using syslog.
IBM Security QRadar records all relevant IPv4 events that are forwarded from DCN switches. To
integrate your device with QRadar, you must configure a log source, then configure your DCS or DCRS
switch to forward syslog events.
Supported Appliances
The DSM supports the following DCN DCS/DCRS Series switches:
v DCS - 3650
v DCS - 3950
v DCS - 4500
v DCRS - 5750
v DCRS - 5960
v DCRS - 5980
v DCRS - 7500
v DCRS - 9800
Configuring a log source
IBM Security QRadar does not automatically discover incoming syslog events from DCN DCS/DCRS
Series switches.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select DCN DCS/DCRS Series.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following value:
Table 188. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address, host name, or name for the log source for use as an identifier
of your DCN DCS/DCRS Series switch.
Each log source that you create for your DCN DCS/DCRS Series switch includes a
unique identifier, such as an IP address or host name.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
© Copyright IBM Corp. 2005, 2018
323
The log source is added to QRadar. You are now ready to configure your Digital China Networks
DCS or DCRS Series switch to forward events to QRadar.
Configuring a DCN DCS/DCRS Series Switch
To collect events, you must configure your DCN DCS/DCRS Series switch in IBM Security QRadar.
Procedure
1. Log in to your DCN DCS/DCRS Series Switch command-line interface (CLI).
2. Type the following command to access the administrative mode:
enable
3. Type the following command to access the global configuration mode:
config
The command-line interface displays the configuration mode prompt:
Switch(Config)#
4. Type the following command to configure a log host for your switch:
logging <IP address> facility <local> severity <level>
Where:
v <IP address> is the IP address of the QRadar Console.
v <local> is the syslog facility, for example, local0.
v <level> is the severity of the syslog events, for example, informational. If you specify a value of
informational, you forward all information level events and later (more severe), such as,
notifications, warnings, errors, critical, alerts, and emergencies.
For example,
logging <IP_address> facility local0 severity informational
5. Type the following command to save your configuration changes:
write The configuration is complete. You can verify the events that are forwarded to QRadar by
viewing events in the Log Activity tab.
324
QRadar DSM Configuration Guide
48 Enterprise-IT-Security.com SF-Sherlock
The IBM Security QRadar DSM for Enterprise-IT-Security.com SF-Sherlock collects logs from your
Enterprise-IT-Security.com SF-Sherlock servers.
The following table describes the specifications for the Enterprise-IT-Security.com SF-Sherlock DSM:
Table 189. Enterprise-IT-Security.com SF-Sherlock DSM specifications
Specification
Value
Manufacturer
Enterprise-IT-Security.com
DSM name
Enterprise-IT-Security.com SF-Sherlock
RPM file name
DSM-EnterpriseITSecuritySFSherlock-Qradar_versionbuild_number.noarch.rpm
Supported versions
v8.1 and later
Event format
Log Event Extended Format (LEEF)
Recorded event types
All_Checks, DB2_Security_Configuration, JES_Configuration,
Job_Entry_System_Attack, Network_Parameter, Network_Security,
No_Policy, Resource_Access_Viol, Resource_Allocation, Resource_Protection,
Running_System_Change, Running_System_Security,
Running_System_Status, Security_Dbase_Scan, Security_Dbase_Specialty,
Security_Dbase_Status, Security_Parm_Change, Security_System_Attack,
Security_System_Software, Security_System_Status, SF-Sherlock,
Sherlock_Diverse, Sherlock_Diverse, Sherlock_Information,
Sherlock_Specialties, Storage_Management, Subsystem_Scan,
Sysplex_Security, Sysplex_Status, System_Catalog, System_File_Change,
System_File_Security, System_File_Specialty, System_Log_Monitoring,
System_Module_Security, System_Process_Security, System_Residence,
System_Tampering, System_Volumes, TSO_Status, UNIX_OMVS_Security,
UNIX_OMVS_System, User_Defined_Monitoring, xx_Resource_Prot_Templ
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Enterprise-IT-Security website (http:/www.enterprise-it-security.com)
To integrate Enterprise-IT-Security.com SF-Sherlock with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Enterprise-IT-Security.com SF-Sherlock DSM RPM
v DSM Common RPM
2. Configure your Enterprise-IT-Security.com SF-Sherlock device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a Enterprise-IT-Security.com SF-Sherlock
log source on the QRadar Console. The following table describes the parameters that require specific
values for Enterprise-IT-Security.com SF-Sherlock event collection:
Table 190. Enterprise-IT-Security.com SF-Sherlock log source parameters
Parameter
Value
Log Source type
Enterprise-IT-Security.com SF-Sherlock
© Copyright IBM Corp. 2005, 2018
325
Table 190. Enterprise-IT-Security.com SF-Sherlock log source parameters (continued)
Parameter
Value
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Enterprise-IT-Security.com SF-Sherlock to communicate
with QRadar
Before you can send SF-Sherlock events and assessment details to QRadar, implement the SF-Sherlock 2
QRadar connection kit.
About this task
The information that is sent to QRadar can be defined and selected in detail. Regardless of the selected
transfer method, all information reaches QRadar as LEEF-formatted records.
Procedure
1. Install the UMODQR01 and UMODQR02 SF-Sherlock SMP/E user modifications by using the
corresponding SHERLOCK.SSHKSAMP data set members.
2. If you send SF-Sherlock’s LEEF records to a QRadar syslog daemon, which is generally the preferred
transfer method, you must install the SF-Sherlock universal syslog message router in the USS
environment of z/OS. You will find all installation details within the UNIXCMDL member of the
SHERLOCK.SSHKSAMP data set.
3. Optional: If you transfer the logs by FTP or another technique, you must adapt the UMODQR01 user
modification.
4. Enter the IP address for the QRadar LEEF syslog server, transfer method (UDP or TCP), and port
number (514) in the QRADARSE member of SF-Sherlock’s init-deck parameter configuration file.
5. Allocate the QRadar related log data set by using the ALLOCQRG job of the SHERLOCK.SSHKSAMP
data set. It is used by the SHERLOCK started procedure (STC) to keep all QRadar LEEF records
transferring to QRadar.
6. The QRDARTST member of the SHERLOCK.SSHKSAMP data set can be used to test the SF-Sherlock
2 QRadar message routing connection. If QRadar receives the test events, the implementation was
successful.
7. Enable the SF-Sherlock 2 QRadar connection in your SF-Sherlock installation by activating
QRADAR00 (event monitoring) and optionally, the QRADAR01 (assessment details) init-deck
members, through the already prepared ADD QRADARxx statements within the $BUILD00 master control
member.
8. Refresh or recycle the SHERLOCK started procedure to activate the new master control member that
enables the connection of SF-Sherlock to QRadar.
326
QRadar DSM Configuration Guide
49 Epic SIEM
The IBM Security QRadar DSM for Epic SIEM can collect event logs from your Epic SIEM.
The following table identifies the specifications for the Epic SIEM DSM:
Table 191. Epic SIEM DSM specifications
Specification
Value
Manufacturer
Epic
DSM name
Epic SIEM
RPM file name
DSM-EpicSIEM-QRadar_version-build_number.noarch.rpm
Supported versions
Epic 2014, Epic 2015, Epic 2017
Event format
LEEF
Recorded event types
Audit
Authentication
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
Epic website (http://www.epic.com/)
To integrate Epic SIEM DSM with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Epic SIEM DSM RPM
v DSMCommon RPM
2. Configure your Epic SIEM device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add an Epic SIEM log source on the QRadar
Console. The following table describes the parameters that require specific values for Epic SIEM event
collection:
Table 192. Epic SIEM log source parameters
Parameter
Value
Log Source type
Epic SIEM
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
© Copyright IBM Corp. 2005, 2018
327
Configuring Epic SIEM 2014 to communicate with QRadar
To collect syslog events from Epic SIEM 2014, you must add an external syslog server for the IBM
Security QRadar host.
Procedure
1. If all web services are not enabled for your instance of Interconnect, complete the following steps to
run the required SendSIEMSyslogAudit service:
a. To access the Interconnect Configuration Editor, click Start > Epic 2014 > Interconnect >
your_instance > Configuration Editor.
b. In the Configuration Editor, select the Business Services form.
c. On the Service Category tab, click SendSIEMSyslogAudit.
d. Click Save
2. Log in to your Epic server.
3. Click Epic System Definitions (%ZeUSTBL) > Security > Auditing Options > SIEM Syslog Settings
> SIEM Syslog Configuration.
4. Use the following table to configure the parameters:
Parameter
Description
SIEM Host
The host name or IP address of the QRadar appliance.
SIEM Port
514
SIEM Format
LEEF (Log Event Extended Format).
5. From the SIEM Syslog Settings menu, click SIEM Syslog and set it to enabled.
The SIEM Syslog Sending daemon is automatically started when the environment is set to runlevel
Up or when you enable SIEM Syslog.
6. If you want to stop the daemon, from the SIEM Syslog Settings menu, click SIEM Syslog and set it
to disabled.
Important: If you stop the daemon when the syslog setting is enabled, the system continues to log
data without purging. If you want to stop the daemon when the syslog setting is enabled, contact
your Epic representative or your system administrator.
Configuring Epic SIEM 2015 to communicate with QRadar
To collect events in IBM Security QRadar, you must configure the messaging queue values on your Epic
SIEM 2015 system.
Procedure
1. From the command line, select Interconnect Administrator's Menu > Messaging Queues Setup.
2. Type an asterisk (*) to create the EMPSYNC queue.
3. Enter the queue values identified in the following table for each of the prompts.
Table 193. Queue values for EMPSYNC prompts
Prompt
Value
Queue ID
Type an ID for the queue.
Queue Name
EMPSYNC
Descriptor
EMPSYNC
Run on Node
Press the Enter key. The value is automatically
populated.
328
QRadar DSM Configuration Guide
Table 193. Queue values for EMPSYNC prompts (continued)
Prompt
Value
IC Servers
Press the Enter key, without typing a value.
Edit advanced settings for this queue?
Yes
Does this queue handle synchronous outgoing messages? Yes
Associate this descriptor with a queue type for outgoing
communication?
Yes
Queue Type
EMP
4. Type an asterisk (*) to create the EMPASYNC queue.
5. Enter the queue values identified in the following table for each of the prompts.
Table 194. Queue values for EMPASYNC prompts
Prompt
Value
Queue ID
Type an ID for the queue.
Queue Name
EMPASYNC
Descriptor
EMPASYNC
Run on Node
Press the Enter key. The value is automatically
populated.
IC Servers
Press the Enter key, without typing a value.
Edit advanced settings for this queue?
Yes
Does this queue handle synchronous outgoing messages? No
Associate this descriptor with a queue type for outgoing
communication?
Yes
Queue Type
EMP
6. Deploy a new interconnect instance by using Kuiper.
7. Access the Interconnect Configuration Editor in Windows, by clicking Start > Epic 2015 >
Interconnect > your_instance > Configuration Editor.
8. Select the General Web Service Host role.
9. In Cache Connections, manually add the queue by the queue type, EMP.
10. Set the number of threads to 2.
For more information about thread count recommendations, refer to your Epic documentation.
Important: Do not enable any services on the Business Services tab.
11. Log in to your Epic server.
12. Click Epic System Definitions (%ZeUSTBL) > Security > Auditing Options > SIEM Syslog
Settings.
13. Select SIEM Syslog Configuration, and then configure the following parameters:
Parameter
Value
SIEM Host
Your QRadar Event Collector host name or IP address.
SIEM Port
514
SIEM Format
LEEF (Log Event Extended Format)
Check Application Layer Response
Disable
14. Return to the SIEM Syslog Settings Menu.
49 Epic SIEM
329
15. Select SIEM Syslog and set it to Enabled.
Note: The SIEM Syslog Sending daemon is automatically started when the environment is set to
runlevel Up or when you enable SIEM Syslog. If you want to stop the daemon, from the SIEM
Syslog Settings menu, click SIEM Syslog and set it to Disabled.
Configuring Epic SIEM 2017 to communicate with QRadar
To collect events in IBM Security QRadar, you must configure the messaging queue values on your Epic
SIEM 2017 system.
Procedure
1. From the command line, select Interconnect Administrator's Menu > Messaging Queues Setup.
2. Type an asterisk (*) to create the EMPSYNC queue.
3. Enter the queue values identified in the following table for each of the prompts.
Table 195. Queue values for EMPSYNC prompts
Prompt
Value
Queue ID
Type an ID for the queue.
Queue Name
EMPSYNC
Descriptor
EMPSYNC
Run on Node
Press the Enter key. The value is automatically
populated.
IC Servers
Press the Enter key, without typing a value.
Edit advanced settings for this queue?
Yes
Does this queue handle synchronous outgoing messages? Yes
Associate this descriptor with a queue type for outgoing
communication?
Yes
Queue Type
EMP
4. Type an asterisk (*) to create the EMPASYNC queue.
5. Enter the queue values identified in the following table for each of the prompts.
Table 196. Queue values for EMPASYNC prompts
Prompt
Value
Queue ID
Type an ID for the queue.
Queue Name
EMPASYNC
Descriptor
EMPASYNC
Run on Node
Press the Enter key. The value is automatically
populated.
IC Servers
Press the Enter key, without typing a value.
Edit advanced settings for this queue?
Yes
Does this queue handle synchronous outgoing messages? No
Associate this descriptor with a queue type for outgoing
communication?
Yes
Queue Type
EMP
6. Deploy a new interconnect instance by using Kuiper.
330
QRadar DSM Configuration Guide
7. Access the Interconnect Configuration Editor in Windows, by clicking Start > Epic 2017 >
Interconnect > your_instance > Configuration Editor.
8. Select the General Web Service Host role.
9. In Cache Connections, manually add the queue by the queue type, EMP.
10. Set the number of threads to 2.
For more information about thread count recommendations, see your Epic documentation.
Important: Do not enable any services on the Business Services tab.
11. Log in to your Epic server.
12. Click Epic System Definitions (%ZeUSTBL) > Security > Auditing Options > SIEM Syslog
Settings.
13. Select SIEM Syslog Configuration, and then configure the following parameters:
Parameter
Value
SIEM Host
Your QRadar Event Collector host name or IP address.
SIEM Port
514
SIEM Format
LEEF (Log Event Extended Format)
Check Application Layer Response
Disable
14. Return to the SIEM Syslog Settings Menu.
15. If you want to reduce traffic that comes in to your SIEM system, disable the auditing events that
your system does not require:
a. Click SIEM Syslog Configuration Options > Edit Events List.
b. From the Edit Events List, select T for each event that you want to disable.
c. Click Q to quit.
16. Select SIEM Syslog and set it to Enabled.
Note: The SIEM Syslog Sending daemon is automatically started when the environment is set to
runlevel Up or when you enable SIEM Syslog. If you want to stop the daemon, from the SIEM
Syslog Settings menu, click SIEM Syslog and set it to Disabled.
49 Epic SIEM
331
332
QRadar DSM Configuration Guide
50 ESET Remote Administrator
The IBM Security QRadar DSM for ESET Remote Administrator collects logs from ESET Remote
Administrator.
The following table describes the specifications for the ESET Remote Administrator DSM:
Table 197. ESET Remote Administrator DSM specifications
Specification
Value
Manufacturer
ESET
DSM name
ESET Remote Administrator
RPM file name
DSM-ESETRemoteAdministrator-QRadar_versionbuild_number.noarch.rpm
Supported versions
6.4.270
Protocol
Syslog
Event format
Log Extended Event Format (LEEF)
Recorded event types
Threat
Firewall aggregated
Host Intrusion Protection System (HIPS) aggregated
Audit
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
ESET website (https://www.eset.com/us/support/
download/business/remote-administrator-6)
To integrate ESET Remote Administrator with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs in the order that they are listed, on your QRadar Console:
v DSMCommon RPM
v ESET Remote Administrator DSM RPM
2. Configure your ESET Remote Administrator server to send LEEF formatted syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add an ESET Remote Administrator log source
on the QRadar Console. The following table describes the parameters that require specific values for
ESET Remote Administrator event collection:
Table 198. ESET Remote Administrator log source parameters
Parameter
Value
Log Source type
ESET Remote Administrator
Protocol Configuration
Syslog
Log Source Identifier
The IP address or host name of the ESET Remote
Administration server.
4. To check that QRadar parses the events correctly, review the following sample event message.
© Copyright IBM Corp. 2005, 2018
333
The following table shows a sample event message from ESET Remote Administrator:
Table 199. ESET Remote Administrator sample message
Event name
Low level category
Sample log message
Native user login
User Login Success
<14>1 2016-08-15T14:52:31.888Z
hostname ERAServer 28021 - ⌂LEEF:1.0|ESET|RemoteAdministrator
|<Version>|Native user login|cat=
ESET RA Audit Event sev=2 devTime
=Aug 15 2016 14:52:31 devTime
Format=MMM dd yyyy HH:mm:ss src=
<Source_IP_address> domain=Native user
action=Login attempt target=
username detail=Native user
’username’ attempted to
authenticate. result=Success
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring ESET Remote Administrator to communicate with QRadar
Configure your ESET Remote Administrator (ERA) server to send LEEF formatted syslog events to IBM
Security QRadar.
About this task
To complete the configuration, you must enable the Syslog server, and then configure the logging
settings.
Note:
The required parameters listed in the following steps are configured in the Server Settings pane. To see a
graphic, go to the ESET website. (http://help.eset.com/era_admin/64/en-US/
index.html?admin_server_settings_export_to_syslog.htm)
Procedure
1. Log in to your ERA web console.
2. In the Admin navigation pane, click Server Settings.
3. In the SYSLOG SERVER area, select the Use Syslog server check box.
4. In the Host field, type the host name for your QRadar Event Collector.
5. In the Port field, type 514.
6. In the LOGGING area, select the Export logs to Syslog check box.
7. From the Exported logs format list, select LEEF.
8. Click Save.
334
QRadar DSM Configuration Guide
51 Exabeam
The IBM Security QRadar DSM for Exabeam collects events from an Exabeam device.
The following table describes the specifications for the Exabeam DSM:
Table 200. Exabeam DSM specifications
Specification
Value
Manufacturer
Exabeam
DSM name
Exabeam
RPM file name
DSM-ExabeamExabeam-Qradar_versionbuild_number.noarch.rpm
Supported versions
v1.7 and v2.0
Recorded event types
Critical
Anomalous
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Exabeam website (http://www.exabeam.com)
To integrate Exabeam with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the Exabeam
DSM RPM on your QRadar Console:
2. Configure your Exabeam device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add an Exabeam log source on the QRadar
Console. The following table describes the parameters that require specific values for Exabeam event
collection:
Table 201. Exabeam log source parameters
Parameter
Value
Log Source type
Exabeam
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Exabeam to communicate with QRadar
To collect syslog events from Exabeam, you must add a destination that specifies QRadar as the syslog
server.
© Copyright IBM Corp. 2005, 2018
335
Procedure
1. Log in to your Exabeam user interface (https://<Exabeam_IP>:8484).
2. Select https://<Exabeam_IP>:8484 and type #setup at the end of the url address.
https://<Exabeam_IP>:8484/#setup
3. In the Navigation pane, click Incident Notification.
4. Select Send via Syslog and configure the following syslog parameters.
Parameter
Description
IP Address or Hostname
The IP address of the QRadar Event Collector .
Protocol
TCP
Port
514
Syslog Severity Level
Emergency
336
QRadar DSM Configuration Guide
52 Extreme
IBM Security QRadar accepts events from a range of Extreme DSMs.
Extreme 800-Series Switch
The Extreme 800-Series Switch DSM for IBM Security QRadar accepts events by using syslog.
QRadar records all relevant audit, authentication, system, and switch events. Before you configure your
Extreme 800-Series Switch in QRadar, you must configure your switch to forward syslog events.
Configuring your Extreme 800-Series Switch
Configuring the Extreme 800-Series Switch to forward syslog events.
About this task
To manually configure the Extreme 800-Series Switch:
Procedure
1. Log in to your Extreme 800-Series Switch command-line interface.
You must be a system administrator or operator-level user to complete these configuration steps.
2. Type the following command to enable syslog:
enable syslog
3. Type the following command to create a syslog address for forwarding events to QRadar:
create syslog host 1 <IP address> severity informational facility local7 udp_port 514 state
enable
Where: <IP address> is the IP address of your QRadar Console or Event Collector.
4. Optional: Type the following command to forward syslog events by using an IP interface address:
create syslog source_ipif <name> <IP address>
Where:
v <name> is the name of your IP interface.
v <IP address> is the IP address of your QRadar Console or Event Collector.
The configuration is complete. The log source is added to QRadar as Extreme 800-Series Switch events
are automatically discovered. Events that are forwarded to QRadar by Extreme 800-Series Switches are
displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Extreme
800-Series Switches.
About this task
The following configuration steps are optional. To manually configure a log source:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
© Copyright IBM Corp. 2005, 2018
337
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Extreme 800-Series Switch.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 202. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Extreme 800-Series Switch.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Extreme Dragon
The Extreme Dragon DSM for IBM Security QRadar accepts Extreme events by using syslog to record all
relevant Extreme Dragon events.
About this task
To configure your QRadar Extreme Dragon DSM, use the following procedure:
Procedure
1. Create an Alarm Tool policy by using a Syslog notification rule. See “Creating a Policy for Syslog.”
2. Configure the log source within QRadar. See “Configuring a log source ” on page 340.
3. Configure Dragon Enterprise Management Server (EMS) to forward syslog messages. See “Configure
the EMS to forward syslog messages” on page 340.
Creating a Policy for Syslog
This procedure describes how to configure an Alarm Tool policy by using a syslog notification rule in the
Log Event Extended Format (LEEF) message format.
About this task
LEEF is the preferred message format for sending notifications to Dragon Network Defense when the
notification rate is high or when IPv6 addresses are displayed. If you do not want to use syslog
notifications in LEEF format, refer to your Extreme Dragon documentation for more information.
To configure Extreme Dragon with an Alarm Tool policy by using a syslog notification rule, complete the
following steps:
Procedure
1. Log in to the Extreme Dragon EMS.
2. Click the Alarm Tool icon.
3. Configure the Alarm Tool Policy:
In the Alarm Tool Policy View > Custom Policies menu tree, right-click and select Add Alarm Tool
Policy.
338
QRadar DSM Configuration Guide
4. In the Add Alarm Tool Policy field, type a policy name.
For example:
QRadar
5. Click OK.
6. In the menu tree, select QRadar.
7. To configure the event group:
Click the Events Group tab.
8. Click New.
The Event Group Editor is displayed.
9. Select the event group or individual events to monitor.
10. Click Add.
A prompt is displayed.
11. Click Yes.
12. In the right column of the Event Group Editor, type Dragon-Events.
13. Click OK.
14. Configure the Syslog notification rule:
Click the Notification Rules tab.
15. Click New.
16. In the name field, type QRadar-RuleSys.
17. Click OK.
18. In the Notification Rules pane, select the newly created QRadar-RuleSys item.
19. Click the Syslog tab.
20. Click New.
The Syslog Editor is displayed.
21. Update the following values:
v Facility - Using the Facility list, select a facility.
v Level - Using the Level list, select notice.
v Message - Using the Type list, select LEEF.
LEEF:Version=1.0|Vendor|Product|ProductVersion|eventID|devTime|
proto|src|sensor|dst|srcPort|dstPort|direction|eventData|
The LEEF message format delineates between fields by using a pipe delimiter between each
keyword.
22. Click OK.
23. Verify that the notification events are logged as separate events:
Click the Global Options tab.
24. Click the Main tab.
25. Make sure that Concatenate Events is not selected.
26. Configure the alarm information:
Click the Alarms tab.
27. Click New.
28. Type values for the parameters:
v Name - Type QRadar-Alarm.
v Type - Select Real Time.
v Event Group - Select Dragon-Events.
v Notification Rule - Select the QRadar-RuleSys check box.
52 Extreme
339
29. Click OK.
30. Click Commit.
31. Navigate to the Enterprise View.
32. Right-click on the Alarm Tool and select Associate Alarm Tool Policy.
33. Select the newly created QRadar policy. Click OK.
34. In the Enterprise menu, right-click the policy and select Deploy.
You are now ready to configure a syslog log source in QRadar.
Configuring a log source
You are now ready to configure the log source in IBM Security QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Extreme Dragon Network IPS.
9. From the Protocol Configuration list, select Syslog.
For more information about Extreme Dragon device, see your Extreme Dragon documentation.
Note: Using the event mapping tool in the Log Activity tab, you can map a normalized or raw event
to a high-level and low-level category (or QID). However, you cannot map combination Dragon
messages using the event mapping tool. For more information, see the IBM Security QRadar User Guide
.
Configure the EMS to forward syslog messages
Starting with Dragon Enterprise Management Server (EMS) v7.4.0 appliances, you must use syslog-ng for
forwarding events to a Security and Information Manager such as IBM Security QRadar.
Syslogd has been replaced by syslog-ng in Dragon EMS v7.4.0 and later.
To configure EMS to forward syslog messages, you must choose one of the following:
v If you are using syslog-ng and Extreme Dragon EMS v7.4.0 and later, see “Configuring syslog-ng Using
Extreme Dragon EMS V7.4.0 and later.”
v If you are using syslogd and Extreme Dragon EMS v7.4.0 and below, see “Configuring syslogd Using
Extreme Dragon EMS V7.4.0 and earlier” on page 341.
Configuring syslog-ng Using Extreme Dragon EMS V7.4.0 and later
This section describes the steps to configure syslog-ng in non-encrypted mode and syslogd to forward
syslog messages to IBM Security QRadar.
About this task
If you are using encrypted syslog-ng, refer to your Extreme documentation.
Do not run both syslog-ng and syslogd at the same time.
340
QRadar DSM Configuration Guide
To configure syslog-ng in non-encrypted mode:
Procedure
1. On your EMS system, open the following file:
/opt/syslog-ng/etc/syslog-ng.conf
2. Configure a Facility filter for the Syslog notification rule.
For example, if you selected facility local1:
filter filt_facility_local1 {facility(local1); };
3. Configure a Level filter for the Syslog notification rule.
For example, if you selected level notice:
filter filt_level_notice {level(notice); };
4. Configure a destination statement for the QRadar.
For example, if the IP address of the QRadar is 192.0.2.1 and you want to use syslog port of 514, type:
destination siem { tcp("192.0.2.1" port(514)); };
5. Add a log statement for the notification rule:
log { source(s_local); filter (filt_facility_local1); filter (filt_level_notice);
destination(siem); };
6. Save the file and restart syslog-ng.
cd /etc/rc.d ./rc.syslog-ng stop ./rc.syslog-ng start
7. The Extreme Dragon EMS configuration is complete.
Configuring syslogd Using Extreme Dragon EMS V7.4.0 and earlier
If your Dragon Enterprise Management Server (EMS) is using a version earlier than V7.4.0 on the
appliance, you must use syslogd for forwarding events to a Security and Information Manager such as
IBM Security QRadar.
Procedure
1. On the Dragon EMS system, open the following file:
/etc/syslog.conf
2. Add a line to forward the facility and level you configured in the syslog notification rule to
QRadar.
For example, to define the facility local1 and level notice:
local1.notice @<IP address>
Where:
<IP address> is the IP address of the QRadar system.
3. Save the file and restart syslogd.
cd /etc/rc.d ./rc.syslog stop ./rc.syslog start
The Extreme Dragon EMS configuration is complete.
Extreme HiGuard Wireless IPS
The Extreme HiGuard Wireless IPS DSM for IBM Security QRadar records all relevant events by using
syslog
Before you configure the Extreme HiGuard Wireless IPS device in QRadar, you must configure your
device to forward syslog events.
52 Extreme
341
Configuring Enterasys HiGuard
To configure the device to forward syslog events:
Procedure
1. Log in to the HiGuard Wireless IPS user interface.
2. In the left navigation pane, click Syslog, which allows the management server to send events to
designated syslog receivers.
The Syslog Configuration pane is displayed.
3. In the System Integration Status section, enable syslog integration.
Enabling syslog integration allows the management server to send messages to the configured syslog
servers. By default, the management server enables syslog.
The Current Status field displays the status of the syslog server. The choices are: Running or
Stopped. An error status is displayed if one of the following occurs:
v One of the configured and enabled syslog servers includes a host name that cannot be resolved.
v The management server is stopped.
v An internal error occurred. If this error occurs, contact Enterasys Technical Support.
4. From Manage Syslog Servers, click Add.
The Syslog Configuration window is displayed.
5. Type values for the following parameters:
v Syslog Server (IP Address/Hostname) - Type the IP address or host name of the syslog server
where events are sent.
Note: Configured syslog servers use the DNS names and DNS suffixes configured in the Server
initialization and Setup Wizard on the HWMH Config Shell.
v Port Number - Type the port number of the syslog server to which HWMH sends events. The
default is 514.
v Message Format - Select Plain Text as the format for sending events.
v Enabled? - Select Enabled? if you want events to be sent to this syslog server.
6. Save your configuration.
The configuration is complete. The log source is added to IBM Security QRadar as HiGuard events
are automatically discovered. Events that are forwarded to QRadar by Enterasys HiGuard are
displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Extreme
HiGuard.
About this task
The following configuration steps are optional. To manually configure a log source for Extreme HiGuard:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
342
QRadar DSM Configuration Guide
8. From the Log Source Type list, select Extreme HiGuard.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 203. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Extreme HiGuard.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Extreme HiPath Wireless Controller
The Extreme HiPath Wireless Controller DSM for IBM Security QRadar records all relevant events by
using syslog.
QRadar supports the following Extreme HiPath Wireless Controller events:
v Wireless access point events
v Application log events
v Service log events
v Audit log events
Configuring your HiPath Wireless Controller
To integrate your Extreme HiPath Wireless Controller events with IBM Security QRadar, you must
configure your device to forward syslog events.
About this task
To forward syslog events to QRadar:
Procedure
1. Log in to the HiPath Wireless Assistant.
2. Click Wireless Controller Configuration.
The HiPath Wireless Controller Configuration window is displayed.
3. From the menu, click System Maintenance.
4. From the Syslog section, select the Syslog Server IP check box and type the IP address of the device
that receives the syslog messages.
5. Using the Wireless Controller Log Level list, select Information.
6. Using the Wireless AP Log Level list, select Major.
7. Using the Application Logs list, select local.0.
8. Using the Service Logs list, select local.3.
9. Using the Audit Logs list, select local.6.
10. Click Apply.
You are now ready to configure the log source in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Extreme
HiPath. The following configuration steps are optional.
52 Extreme
343
About this task
To manually configure a log source for Extreme HiPath:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Extreme HiPath.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 204. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Extreme HiPath.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete. For more information about your Extreme HiPath Wireless Controller
device, see your vendor documentation.
Extreme Matrix Router
The Extreme Matrix Router DSM for IBM Security QRadar accepts Extreme Matrix events by using
SNMPv1, SNMPv2, SNMPv3, and syslog.
About this task
You can integrate Extreme Matrix Router version 3.5 with QRadar. QRadar records all SNMP events,
syslog login, logout, and login failed events. Before you configure QRadar to integrate with Extreme
Matrix, you must take the following steps:
Procedure
1. Log in to the switch/router as a privileged user.
2. Type the following command:
set logging server <server number> description <description> facility <facility> ip_addr <IP
address> port <port> severity <severity> Where:
v <server number> is the server number with values 1 - 8.
v <description> is a description of the server.
v <facility> is a syslog facility, for example, local0.
v <IP address> is the IP address of the server that receives the syslog messages.
v <port> is the default UDP port that the client uses to send messages to the server. Use port 514
unless otherwise stated.
v <severity> is the server severity level with values 1 - 9, where 1 indicates an emergency, and 8 is
debug level.
344
QRadar DSM Configuration Guide
For example:
set logging server 5 description ourlogserver facility local0 ip_addr 192.0.2.1 port 514
severity 8
3. You are now ready to configure the log source in QRadar.
Select Extreme Matrix E1 Switch from the Log Source Type list.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Extreme Matrix K/N/S Series Switch
The Extreme Matrix Series DSM for IBM Security QRadar accepts events by using syslog. QRadar records
all relevant Matrix K-Series, N-Series, or S-Series standalone device events.
About this task
Before you configure QRadar to integrate with a Matrix K-Series, N-Series, or S-Series, take the following
steps:
Procedure
1. Log in to your Extreme Matrix device command-line interface (CLI).
2. Type the following commands:
a. set logging server 1 ip-addr <IP Address of Event Processor> state enable
b. set logging application RtrAcl level 8
c. set logging application CLI level 8
d. set logging application SNMP level 8
e. set logging application Webview level 8
f. set logging application System level 8
g. set logging application RtrFe level 8
h. set logging application Trace level 8
i. set logging application RtrLSNat level 8
j. set logging application FlowLimt level 8
k. set logging application UPN level 8
l. set logging application AAA level 8
m. set logging application Router level 8
n. set logging application AddrNtfy level 8
o. set logging application OSPF level 8
p. set logging application VRRP level 8
q. set logging application RtrArpProc level 8
r. set logging application LACP level 8
s. set logging application RtrNat level 8
t. set logging application RtrTwcb level 8
u. set logging application HostDoS level 8
v. set policy syslog extended-format enable
For more information on configuring the Matrix Series routers or switches, consult your vendor
documentation.
3. You are now ready to configure the log sources in QRadar.
52 Extreme
345
To configure QRadar to receive events from an Extreme Matrix Series device, select Extreme Matrix
K/N/S Series Switch from the Log Source Type list.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Extreme NetSight Automatic Security Manager
The Extreme NetSight Automatic Security Manager DSM for IBM Security QRadar accepts events by
using syslog.
About this task
QRadar records all relevant events. Before you configure an Extreme NetSight Automatic Security
Manager device in QRadar, you must configure your device to forward syslog events.
To configure the device to send syslog events to QRadar:
Procedure
1. Log in to the Automatic Security Manager user interface.
2. Click the Automated Security Manager icon to access the Automated Security Manager
Configuration window.
Note: You can also access the Automated Security Manager Configuration window from the Tool
menu.
3. From the left navigation menu, select Rule Definitions.
4. Choose one of the following options:
If a rule is configured, highlight the rule. Click Edit.
5. To create a new rule, click Create.
6. Select the Notifications check box.
7. Click Edit.
The Edit Notifications window is displayed.
8. Click Create.
The Create Notification window is displayed.
9. Using the Type list, select Syslog.
10. In the Syslog Server IP/Name field, type the IP address of the device that receives syslog traffic.
11. Click Apply.
12. Click Close.
13. In the Notification list, select the notification that is configured.
14. Click OK.
15. You are now ready to configure the log source in QRadar.
To configure QRadar to receive events from an Extreme NetSight Automatic Security Manager
device, select Extreme NetsightASM from the Log Source Type list.
For more information about your Extreme NetSight Automatic Security Manager device, see your
vendor documentation.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
346
QRadar DSM Configuration Guide
Extreme NAC
The Extreme NAC DSM for IBM Security QRadar accepts events by using syslog. QRadar records all
relevant events.
For details on configuring your Extreme NAC appliances for syslog, consult your vendor documentation.
After the Extreme NAC appliance is forwarding syslog events to QRadar, the configuration is complete.
The log source is added to QRadar as Extreme NAC events are automatically discovered. Events that are
forwarded by Extreme NAC appliances are displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Extreme
NAC.
About this task
The following configuration steps are optional. To manually configure a log source for Extreme NAC:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Extreme NAC.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 205. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Extreme NAC appliances.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Extreme stackable and stand-alone switches
The Extreme stackable and stand-alone switches DSM for IBM Security QRadar accepts events by using
syslog.
About this task
QRadar records all relevant events. Before you configure an Extreme stackable and stand-alone switches
device in QRadar, you must configure your device to forward syslog events.
To configure the device to forward syslog events to QRadar:
52 Extreme
347
Procedure
1. Log in to the Extreme stackable and stand-alone switch device.
2. Type the following command:
set logging server <index> [ip-addr <IP address>] [facility <facility>] [severity
<severity>] [descr <description>] [port <port] [state <enable | disable>] Where:
v <index> is the server table index number (1 - 8) for this server.
v <IP address> is the IP address of the server you want to send syslog messages. You do not have to
enter an IP address. If you do not define an IP address, an entry in the Syslog server table is
created with the specified index number, and a message is displayed indicating that there is no
assigned IP address.
v <facility> is a syslog facility. Valid values are local0 to local7. You do not have to enter a facility
value. If the value is not specified, the default value that is configured with the set logging default
command is applied.
v <description> is a description of the facility/server. You do not have to enter a description.
v <port> is the default UDP port that the client uses to send messages to the server. If not specified,
the default value that is configured with the set logging default command is applied. You do not
have to enter a port value.
v <enable | disable> enables or disables this facility/server configuration. You do not have to
choose an option. If the state is not specified, it does not default to either enable or disable.
v <severity> is the server severity level that the server will log messages. The valid range is 1 - 8. If
not specified, the default value that is configured with the set logging default command is applied.
You do not have to input a severity value. The following are valid values:
v 1: Emergencies (system is unusable)
v 2: Alerts (immediate action needed)
v 3: Critical conditions
v 4: Error conditions
v 5: Warning conditions
v 6: Notifications (significant conditions)
v 7: Informational messages
v 8: Debugging message
3. You can now ready to configure the log source in QRadar.
To configure QRadar to receive events from an Extreme stackable and stand-alone switch device:
From the Log Source Type list, select one of the following options:
v Extreme stackable and stand-alone switches
v Extreme A-Series
v Extreme B2-Series
v Extreme B3-Series
v Extreme C2-Series
v Extreme C3-Series
v Extreme D-Series
v Extreme G-Series
v Extreme I-Series
For more information about your Extreme stackable and stand-alone switches, see your vendor
documentation.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
348
QRadar DSM Configuration Guide
Extreme Networks ExtremeWare
The Extreme Networks ExtremeWare DSM for IBM Security QRadar records all relevant Extreme
Networks ExtremeWare and Extremeware XOS device events from using syslog.
To integrate QRadar with an ExtremeWare device, you must configure a log source in QRadar, then
configure your Extreme Networks ExtremeWare and Extremeware XOS devices to forward syslog events.
QRadar does not automatically discover or create log sources for syslog events from ExtremeWare
appliances.
Configuring a log source
To integrate with IBM Security QRadar, you must manually create a log source to receive the incoming
ExtremeWare events that are forwarded to QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Extreme Networks ExtremeWare Operating System (OS).
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 206. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your ExtremeWare appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are forwarded to QRadar by Extreme Networks
ExtremeWare appliances are displayed on the Log Activity tab.
For information on configuring syslog forwarding for your Extremeware appliances, see your vendor
documentation.
Extreme XSR Security Router
The Extreme XSR Security Router DSM for IBM Security QRadar accepts events by using syslog.
About this task
QRadar records all relevant events. Before you configure an Extreme XSR Security Router in QRadar, you
must configure your device to forward syslog events.
To configure the device to send syslog events to QRadar:
52 Extreme
349
Procedure
1. Using Telnet or SSH, log in to the XSR Security Router command-line interface.
2. Type the following commands to access config mode:
a. enable
b. config
3. Type the following command:
logging <IP address> low
Where: <IP address> is the IP address of your QRadar.
4. Exit from config mode.
exit
5. Save the configuration:
copy running-config startup-config
6. You are now ready to configure the log sources in QRadar.
Select Extreme XSR Security Routers from the Log Source Type list.
For more information about your Extreme XSR Security Router, see your vendor documentation.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
350
QRadar DSM Configuration Guide
53 F5 Networks
IBM Security QRadar accepts events from a range of F5 Networks DSMs.
F5 Networks BIG-IP AFM
The F5 Networks BIG-IP Advanced Firewall Manager (AFM) DSM for IBM Security QRadar accepts
syslog events that are forwarded from F5 Networks BIG-IP AFM systems in name-value pair format.
About this task
QRadar can collect the following events from F5 BIG-IP appliances with Advanced Firewall Managers:
v Network events
v Network Denial of Service (DoS) events
v Protocol security events
v DNS events
v DNS Denial of Service (DoS) events
Before you can configure the Advanced Firewall Manager, you must verify that your BIG-IP appliance is
licensed and provisioned to include Advanced Firewall Manager.
Procedure
1. Log in to your BIG-IP appliance Management Interface.
2. From the navigation menu, select System > License.
3. In the License Status column, verify that the Advanced Firewall Manager is licensed and enabled.
4. To enable the Advanced Firewall Manager, select System > Resource > Provisioning.
5. From the Provisioning column, select the check box and select Nominal from the list.
6. Click Submit to save your changes.
Configuring a logging pool
A logging pool is used to define a pool of servers that receive syslog events. The pool contains the IP
address, port, and a node name that you provide.
Procedure
1. From the navigation menu, select Local Traffic > Pools.
2. Click Create.
3. In the Name field, type a name for the logging pool.
For example, Logging_Pool.
4. From the Health Monitor field, in the Available list, select TCP and click <<.
This clicking action moves the TCP option from the Available list to the Selected list.
5. In the Resource pane, from the Node Name list, select Logging_Node or the name you defined in
“Configuring a logging pool.”
6. In the Address field, type the IP address for the QRadar Console or Event Collector.
7. In the Service Port field, type 514.
8. Click Add.
9. Click Finish.
© Copyright IBM Corp. 2005, 2018
351
Creating a high-speed log destination
The process to configure logging for BIG-IP AFM requires that you create a high-speed logging
destination.
Procedure
1. From the navigation menu, select System > Logs > Configuration > Log Destinations.
2. Click Create.
3. In the Name field, type a name for the destination.
For example, Logging_HSL_dest.
4. In the Description field, type a description.
5. From the Type list, select Remote High-Speed Log.
6. From the Pool Name list, select a logging pool from the list of remote log servers.
For example, Logging_Pool.
7. From the Protocol list, select TCP.
8. Click Finish.
Creating a formatted log destination
The formatted log destination is used to specify any special formatting that is required on the events that
are forwarded to the high-speed logging destination.
Procedure
1. From the navigation menu, select System > Logs > Configuration > Log Destinations.
2. Click Create.
3. In the Name field, type a name for the logging format destination.
For example, Logging_Format_dest.
4. In the Description field, type a description.
5. From the Type list, select Remote Syslog.
6. From the Syslog Format list, select Syslog.
7. From the High-Speed Log Destination list, select your high-speed logging destination.
For example, Logging_HSL_dest.
8. Click Finished.
Creating a log publisher
Creating a publisher allows the BIG-IP appliance to publish the formatted log message to the local syslog
database.
Procedure
1. From the navigation menu, select System > Logs > Configuration > Log Publishers.
2. Click Create.
3. In the Name field, type a name for the publisher.
For example, Logging_Pub.
4. In the Description field, type a description.
5. From the Destinations field, in the Available list, select the log destination name that you created in
“Configuring a logging pool” on page 351 and click << to add items to the Selected list.
This clicking action moves your logging format destination from the Available list to the Selected list.
To include local logging in your publisher configuration, you can add local-db and local-syslog to the
Selected list.
352
QRadar DSM Configuration Guide
Creating a logging profile
Use the Logging profile to configure the types of events that your Advanced Firewall Manager is
producing and to associate these events with the logging destination.
Procedure
1. From the navigation menu, select Security > Event Logs > Logging Profile.
2. Click Create.
3. In the Name field, type a name for the log profile.
For example, Logging_Profile.
4. In the Network Firewall field, select the Enabled check box.
5. From the Publisher list, select the log publisher that you configured.
For example, Logging_Pub.
6. In the Log Rule Matches field, select the Accept, Drop, and Reject check boxes.
7. In the Log IP Errors field, select the Enabled check box.
8. In the Log TCP Errors field, select the Enabled check box.
9. In the Log TCP Events field, select the Enabled check box.
10. In the Storage Format field, from the list, select Field-List.
11. In the Delimiter field, type , (comma) as the delimiter for events.
12. In the Storage Format field, select all of the options in the Available Items list and click <<.
This clicking action moves all of the Field-List options from the Available list to the Selected list.
13. In the IP Intelligence pane, from the Publisher list, select the log publisher that you configured.
For example, Logging_Pub.
14. Click Finished.
Associating the profile to a virtual server
The log profile you created must be associated with a virtual server in the Security Policy tab. This
association allows the virtual server to process your network firewall events, along with local traffic.
About this task
Take the following steps to associate the profile to a virtual server.
Procedure
1. From the navigation menu, select Local Traffic > Virtual Servers.
2. Click the name of a virtual server to modify.
3. From the Security tab, select Policies.
4. From the Log Profile list, select Enabled.
5. From the Profile field, in the Available list, select Logging_Profile or the name you specified in
“Creating a logging profile” and click <<.
This clicking action moves the Logging_Profile option from the Available list to the Selected list.
6. Click Update to save your changes.
The configuration is complete. The log source is added to IBM Security QRadar as F5 Networks
BIG-IP AFM syslog events are automatically discovered. Events that are forwarded to QRadar by F5
Networks BIG-IP AFM are displayed on the Log Activity tab of QRadar.
53 F5 Networks
353
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from F5
Networks BIG-IP AFM. However, you can manually create a log source for QRadar to receive syslog
events.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select F5 Networks BIG-IP AFM.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 207. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your F5 BIG-IP AFM appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
F5 Networks BIG-IP APM
The F5 Networks BIG-IP Access Policy Manager (APM) DSM for IBM Security QRadar collects access and
authentication security events from a BIG-IP APM device by using syslog.
To configure your BIG-IP LTM device to forward syslog events to a remote syslog source, choose your
BIG-IP APM software version:
v “Configuring Remote Syslog for F5 BIG-IP APM 11.x”
v “Configuring a Remote Syslog for F5 BIG-IP APM 10.x” on page 355
Configuring Remote Syslog for F5 BIG-IP APM 11.x
You can configure syslog for F5 BIG-IP APM 11.x.
About this task
To configure a remote syslog for F5 BIG-IP APM 11.x take the following steps:
Procedure
1. Log in to the command-line of your F5 BIG-IP device.
2. Type the following command to add a single remote syslog server:
354
QRadar DSM Configuration Guide
tmsh syslog remote server {<Name> {host <IP address>}} Where:
v <Name> is the name of the F5 BIG-IP APM syslog source.
v <IP address> is the IP address of the QRadar Console.
For example,
bigpipe syslog remote server {BIGIP_APM {host 192.0.2.1}}
3. Type the following to save the configuration changes:
tmsh save sys config partitions all
The configuration is complete. The log source is added to QRadar as F5 Networks BIG-IP APM events
are automatically discovered. Events that are forwarded to QRadar by F5 Networks BIG-IP APM are
displayed on the Log Activity tab in QRadar.
Configuring a Remote Syslog for F5 BIG-IP APM 10.x
You can configure syslog for F5 BIG-IP APM 10.x
About this task
To configure a remote syslog for F5 BIG-IP APM 10.x take the following steps:
Procedure
1. Log in to the command-line of your F5 BIG-IP device.
2. Type the following command to add a single remote syslog server:
bigpipe syslog remote server {<Name> {host <IP address>}} Where:
v <Name> is the name of the F5 BIG-IP APM syslog source.
v <IP address> is the IP address of QRadar Console.
For example,
bigpipe syslog remote server {BIGIP_APM {host 192.0.2.1}}
3. Type the following to save the configuration changes:
bigpipe save
The configuration is complete. The log source is added to IBM Security QRadar as F5 Networks
BIG-IP APM events are automatically discovered. Events that are forwarded to QRadar by F5
Networks BIG-IP APM are displayed on the Log Activity tab.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from F5
Networks BIG-IP APM appliances.
About this task
These configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
53 F5 Networks
355
8. From the Log Source Type list, select F5 Networks BIG-IP APM.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your F5 Networks BIG-IP APM appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Configuring F5 Networks BIG-IP ASM
The IBM Security QRadar F5 Networks BIG-IP Application Security Manager (ASM) DSM collects web
application security events from BIG-IP ASM appliances by using syslog.
About this task
To forward syslog events from an F5 Networks BIG-IP ASM appliance to QRadar, you must configure a
logging profile.
A logging profile can be used to configure remote storage for syslog events, which can be forwarded
directly to QRadar.
Procedure
1. Log in to the F5 Networks BIG-IP ASM appliance user interface.
2. In the navigation pane, select Application Security > Options.
3. Click Logging Profiles.
4. Click Create.
5. From the Configuration list, select Advanced.
6. Type a descriptive name for the Profile Name property.
7. Optional: Type a Profile Description.
If you do not want data logged both locally and remotely, clear the Local Storage check box.
8. Select the Remote Storage check box.
9. From the Type list, select 1 of the following options:
a. In BIG-IP ASM V12.1.2 or earlier, select Reporting Server.
b. In BIG-IP ASM V13.0.0 or later, select key-value pairs.
10. From the Protocol list, select TCP.
11. In the IP Address field, type the IP address of the QRadar Console and in the Port field, type a port
value of 514.
12. Select the Guarantee Logging check box.
Note: Enabling the Guarantee Logging option ensures the system log requests continue for the web
application when the logging utility is competing for system resources. Enabling the Guarantee
Logging option can slow access to the associated web application.
13. Select the Report Detected Anomalies check box to allow the system to log details.
14. Click Create.
356
QRadar DSM Configuration Guide
The display refreshes with the new logging profile. The log source is added to QRadar as F5
Networks BIG-IP ASM events are automatically discovered. Events that are forwarded by F5
Networks BIG-IP ASM are displayed on the Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from F5
Networks BIG-IP ASM appliances.
About this task
These configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select F5 Networks BIG-IP ASM.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 208. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your F5 Networks BIG-IP ASM appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
F5 Networks BIG-IP LTM
The F5 Networks BIG-IP Local Traffic Manager (LTM) DSM for IBM Security QRadar collects networks
security events from a BIG-IP device by using syslog.
Before events can be received in QRadar, you must configure a log source for QRadar, then configure
your BIG-IP LTM device to forward syslog events. Create the log source before events are forwarded as
QRadar does not automatically discover or create log sources for syslog events from F5 BIG-IP LTM
appliances.
Configuring a log source
To integrate F5 BIG-IP LTM with IBM Security QRadar, you must manually create a log source to receive
syslog events.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
53 F5 Networks
357
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select F5 Networks BIG-IP LTM.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 209. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your BIG-IP LTM appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
You are now ready to configure your BIG-IP LTM appliance to forward syslog events to QRadar.
Configuring syslog forwarding in BIG-IP LTM
You can configure your BIG-IP LTM device to forward syslog events.
You can configure syslog for the following BIG-IP LTM software version:
v “Configuring Remote Syslog for F5 BIG-IP LTM 11.x”
v “Configuring Remote Syslog for F5 BIG-IP LTM 10.x” on page 359
v “Configuring Remote Syslog for F5 BIG-IP LTM 9.4.2 to 9.4.8” on page 359
Configuring Remote Syslog for F5 BIG-IP LTM 11.x
You can configure syslog for F5 BIG-IP LTM 11.x.
About this task
To configure syslog for F5 BIG-IP LTM 11.x take the following steps:
Procedure
1. Log in to the command-line of your F5 BIG-IP device.
2. To log in to the Traffic Management Shell (tmsh), type the following command:
tmsh
3. To add a syslog server, type the following command:
modify /sys syslog remote-servers add {<Name> {host <IP address> remote-port 514}}
Where:
v <Name> is a name that you assign to identify the syslog server on your BIG-IP LTM appliance.
v <IP address> is the IP address of IBM Security QRadar.
For example,
modify /sys syslog remote-servers add {BIGIPsyslog {host 192.0.2.1 remote-port 514}}
4. Save the configuration changes:
save /sys config
Events that are forwarded from your F5 Networks BIG-IP LTM appliance are displayed on the Log
Activity tab in QRadar.
358
QRadar DSM Configuration Guide
Configuring Remote Syslog for F5 BIG-IP LTM 10.x
You can configure syslog for F5 BIG-IP LTM 10.x.
About this task
To configure syslog for F5 BIG-IP LTM 10.x take the following steps:
Procedure
1. Log in to the command line of your F5 BIG-IP device.
2. Type the following command to add a single remote syslog server:
bigpipe syslog remote server {<Name> {host <IP_address>}} Where:
v <Name> is the name of the F5 BIG-IP LTM syslog source.
v <IP_address> is the IP address of IBM Security QRadar.
For example:
bigpipe syslog remote server {BIGIPsyslog {host 192.0.2.1}}
3. Save the configuration changes:
bigpipe save
Note: F5 Networks modified the syslog output format in BIG-IP v10.x to include the use of local/
before the host name in the syslog header. The syslog header format that contains local/ is not
supported in QRadar, but a workaround is available to correct the syslog header. For more
information, see http://www.ibm.com/support.
Events that are forwarded from your F5 Networks BIG-IP LTM appliance are displayed on the Log
Activity tab in QRadar.
Configuring Remote Syslog for F5 BIG-IP LTM 9.4.2 to 9.4.8
You can configure syslog for F5 BIG-IP LTM 9.4.2 to 9.4.8.
About this task
To configure syslog for F5 BIG-IP LTM 9.4.2 to 9.4.8 take the following steps:
Procedure
1. Log in to the command-line of your F5 BIG-IP device.
2. Type the following command to add a single remote syslog server:
bigpipe syslog remote server <IP address>
Where: <IP address> is the IP address of IBM Security QRadar. For example:
bigpipe syslog remote server 192.0.2.1
3. Type the following to save the configuration changes:
bigpipe save
The configuration is complete. Events that are forwarded from your F5 Networks BIG-IP LTM
appliance are displayed on the Log Activity tab in QRadar.
F5 Networks FirePass
The F5 Networks FirePass DSM for IBM Security QRadar collects system events from an F5 FirePass SSL
VPN device using syslog.
53 F5 Networks
359
By default, remote logging is disabled and must be enabled in the F5 Networks FirePass device. Before
receiving events in QRadar, you must configure your F5 Networks FirePass device to forward system
events to QRadar as a remote syslog server.
Configuring syslog forwarding for F5 FirePass
To forward syslog events from an F5 Networks BIG-IP FirePass SSL VPN appliance to IBM Security
QRadar, you must enable and configure a remote log server.
About this task
The remote log server can forward events directly to your QRadar Console or any Event Collector in
your deployment.
Procedure
1. Log in to the F5 Networks FirePass Admin Console.
2. On the navigation pane, select Device Management > Maintenance > Logs.
3. From the System Logs menu, select the Enable Remote Log Server check box.
4. From the System Logs menu, clear the Enable Extended System Logs check box.
5. In the Remote host parameter, type the IP address or host name of your QRadar.
6. From the Log Level list, select Information.
The Log Level parameter monitors application level system messages.
7. From the Kernel Log Level list, select Information.
The Kernel Log Level parameter monitors Linux kernel system messages.
8. Click Apply System Log Changes.
The changes are applied and the configuration is complete. The log source is added to QRadar as F5
Networks FirePass events are automatically discovered. Events that are forwarded to QRadar by F5
Networks BIG-IP ASM are displayed on the Log Activity tab in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from F5
Networks FirePass appliances.
About this task
The following configuration steps are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select F5 Networks FirePass.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
360
QRadar DSM Configuration Guide
Table 210. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your F5 Networks FirePass appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
53 F5 Networks
361
362
QRadar DSM Configuration Guide
54 Fair Warning
The Fair Warning DSM for IBM Security QRadar retrieves event files from a remote source by using the
log file protocol.
QRadar records event categories from the Fair Warning log files about user activity that is related to
patient privacy and security threats to medical records. Before you can retrieve log files from Fair
Warning, you must verify that your device is configured to generate an event log. Instructions for
generating the event log can be found in your Fair Warning documentation.
When you configure the log file protocol, make sure that the host name or IP address that is configured
in the Fair Warning system is the same as configured in the Remote Host parameter in the log file
protocol configuration.
Configuring a log source
You can configure IBM Security QRadar to download an event log from a Fair Warning device.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list box, select Fair Warning.
9. Select the Log File option from the Protocol Configuration list.
10. In the FTP File Pattern field, type a regular expression that matches the log files that are generated
by the Fair Warning system.
11. In the Remote Directory field, type the path to the directory that contains logs from your Fair
Warning device.
12. From the Event Generator list, select Fair Warning.
13. Click Save.
14. On the Admin tab, click Deploy Changes.
The configuration is complete. For more information on full parameters for the log file protocol, see
the IBM Security QRadar Managing Log Sources Guide.
For more information on configuring Fair Warning, consult your vendor documentation.
Related tasks:
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
© Copyright IBM Corp. 2005, 2018
363
364
QRadar DSM Configuration Guide
55 Fasoo Enterprise DRM
The IBM Security QRadar DSM for Fasoo Enterprise DRM (Digital Rights Management) collects logs from
a Fasoo Enterprise DRM device.
The following table describes the specifications for the Fasoo Enterprise DRM DSM:
Table 211. Fasoo Enterprise DRM DSM specifications
Specification
Value
Manufacturer
Fasoo
DSM name
Fasoo Enterprise DRM
RPM file name
DSM-FasooFED-QRadar_version-build_number.noarch.rpm
Supported versions
5.0
Protocol
JDBC
Event format
name-value pair (NVP)
Recorded event types
Usage events
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
Fasoo website (http://en.fasoo.com/Fasoo-EnterpriseDRM)
To integrate Fasoo Enterprise DRM with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v JDBC Protocol RPM
v DSMCommon RPM
v FasooFED DSM RPM
2. Configure a log source to connect to the Fasoo Enterprise DRM database and retrieve event.
3. Add a Fasoo Enterprise DRM log source on the QRadar Console. The following table describes the
parameters that require specific values to collect event from Fasoo Enterprise DRM:
Table 212. Fasoo Enterprise DRM log source parameters
Parameter
Value
Log Source type
Fasoo Enterprise DRM
Protocol Configuration
JDBC
Log Source Identifier
Since the protocol is JDBC, you need to use a specific format. For
example, for Fasoo Enterprise DRM, use the following format:
<Fasoo_Enterprise_DRM_Database>@
<Fasoo_Enterprise_DRM_Database_Server_IP _or_Host_Name>
You must use the values of the Fasoo Enterprise DRM database
and the database Server IP address or host name.
Database Type
© Copyright IBM Corp. 2005, 2018
From the list, select the type of the Fasoo Enterprise DRM
database.
365
Table 212. Fasoo Enterprise DRM log source parameters (continued)
Parameter
Value
Database Name
The name of the Fasoo Enterprise DRM database. The database
name must match the database name that is specified in the Log
Source Identifier field.
IP or Hostname
The IP address or host name of the Fasoo Enterprise DRM
database server.
Port
The port number that is used by the database server.
Username
The user name that is required to connect to the database.
Password
The password that is required to connect to the database. The
password can be up to 255 characters in length.
Confirm Password
The confirmation password must be identical to the password
that you typed for the Password parameter.
Authentication Domain
If you selected MSDE for the Database Type and the database is
configured for Windows, define a Window Authentication
Domain. Otherwise, leave this field blank.
Database Instance
If you selected MSDE for the Database Type and you have
multiple SQL server instances, type the database instance.
If you use a non-standard port for the database or access is
blocked to port 1434 for SQL database resolution, the Database
Instance parameter must be left blank in the log source
configuration.
Table Name
view_fut_log
The name of the view that includes the event records.
Select List
Type an asterisk (*) to select all fields from the table or view.
The list of fields to include when the table is polled for events.
Compare Field
log_date
The Compare Field is used to identify new events that are added
between queries to the table.
Start Date and Time
Optional. Type the start date and time for database polling in the
following format: yyyy-MM-dd HH:mm, with HH specified by
using a 24-hour clock. If the start date or time is clear, polling
begins immediately and repeats at the specified polling interval.
Use Prepared Statements
Select the check box if you want to use prepared statements.
Prepared statements enable the JDBC protocol source to set up
the SQL statement, and then run the SQL statement numerous
times with different parameters. For security and performance
reasons, most JDBC protocol configurations can use prepared
statements.
Polling Interval
The amount of time between queries to the event table. The
default polling interval is 10 seconds. You can define a longer
polling interval by appending H for hours or M for minutes to the
numeric value. The maximum polling interval is 1 week in any
time format. Numeric values that are entered without an H or M
poll in seconds.
EPS Throttle
The number of Events Per Second (EPS) that you do not want
this protocol to exceed. The default value is 20000 EPS.
4. Verify that QRadar is configured correctly.
366
QRadar DSM Configuration Guide
The following table shows a sample normalized event message from Fasoo Enterprise DRM:
Table 213. Fasoo Enterprise DRM sample message
Event name
Low level category
Sample log message
Edit - successful
Update Activity Succeeded
log_id: "xxxxxxxxxxxxxxxxxxxxxx"
log_date: "2016-03-21 14:17:36.000"
log_type: "1" product: "1"
purpose: "16" usage_result: "1"
license_status: "0"
ip: "<Numeric>"
user_code: "usercode"
user_name: "username"
user_dept_code:
"xxxxxxxxxxxxxxxxxxxx"
user_dept_name: "userdeptname"
position_code: "P001"
position_name: "Employee"
content_code:
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
current_content_name:
"New Microsoft PowerPoint
Presentation.pptx"
content_name:
"New Microsoft PowerPoint
Presentation.pptx"
sec_level_code:
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
sec_level_name: "Basic"
system_code: "NULL"
system_name: "NULL"
owner_code: "ownercode"
owner_name: "ownername"
owner_dept_code:
"xxxxxxxxxxxxxxxxxxxx"
owner_dept_name:
"ownerdeptname"
content_create-date:
"2016-03-21 03:41:28.000"
entry_date:
"2016-03-21 13:18:26.670"
Related concepts:
“JDBC protocol configuration options” on page 17
QRadar uses the JDBC protocol to collect information from tables or views that contain event data from
several database types.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Fasoo Enterprise DRM to communicate with QRadar
For IBM Security QRadar to collect log event data, you must create a database view.
Before you begin
The script in this procedure is only intended for MS SQL Servers. For other database types, modifications
to the script will be required for the target database type.
55 Fasoo Enterprise DRM
367
Procedure
1. Log in to SQL Server Management Studio.
2. Create a custom view in your Fasoo database.
USE fed5;
GO
CREATE VIEW view_fut_log
AS
SELECT
dbo.fut_log.log_id,
dbo.fut_log.log_date,
dbo.fut_log.log_type,
dbo.fut_log.product,
dbo.fut_log.purpose,
dbo.fut_log.usage_result,
dbo.fut_log.license_status,
dbo.fut_log.ip,
dbo.fut_user.user_code,
dbo.fut_user.user_name,
dbo.fut_user.user_dept_code,
dbo.fut_user.user_dept_name,
dbo.fut_log.position_code,
dbo.fut_log.position_name,
dbo.fut_content.content_code,
dbo.fut_content.current_content_name,
dbo.fut_content.content_name,
dbo.fut_content.sec_level_code,
dbo.fut_content.sec_level_name,
dbo.fut_content.system_code,
dbo.fut_content.system_name,
dbo.fut_log.owner_code,
dbo.fut_log.owner_name,
dbo.fut_log.owner_dept_code,
dbo.fut_log.owner_dept_name,
dbo.fut_content.content_create_date,
dbo.fut_log.entry_date
FROM dbo.fut_log
INNER JOIN dbo.fut_user
ON dbo.fut_log.user_id =
dbo.fut_user.user_id
INNER JOIN dbo.fut_content
ON dbo.fut_log.content_id =
dbo.fut_content.content_id
GO
368
QRadar DSM Configuration Guide
56 Fidelis XPS
The Fidelis XPS DSM for IBM Security QRadar accepts events that are forwarded in Log Enhanced Event
Protocol (LEEF) from Fidelis XPS appliances by using syslog.
QRadar can collect all relevant alerts that are triggered by policy and rule violations that are configured
on your Fidelis XPS appliance.
Event type format
Fidelis XPS must be configured to generate events in Log Enhanced Event Protocol (LEEF) and forward
these events by using syslog. The LEEF format consists of a pipe ( | ) delimited syslog header, and tab
separated fields that are positioned in the event payload.
If the syslog events forwarded from your Fidelis XPS are not formatted in LEEF format, you must
examine your device configuration or software version to ensure that your appliance supports LEEF.
Properly formatted LEEF event messages are automatically discovered and added as a log source to
QRadar.
Configuring Fidelis XPS
You can configure syslog forwarding of alerts from your Fidelis XPS appliance.
Procedure
1. Log in to CommandPost to manage your Fidelis XPS appliance.
2. From the navigation menu, select System > Export.
A list of available exports is displayed. The list is empty the first time you use the export function.
3. Select one of the following options:
v Click New to create a new export for your Fidelis XPS appliance.
v Click Edit next to an export name to edit an existing export on your Fidelis XPS appliance.
The Export Editor is displayed.
4. From the Export Method list, select Syslog LEEF.
5. In the Destination field, type the IP address or host name for IBM Security QRadar.
For example, 192.0.2.1:::514
The Destination field does not support non-ASCII characters.
6. From Export Alerts, select one of the following options:
v All alerts - Select this option to export all alerts to QRadar. This option is resource-intensive and it
can take time to export all alerts.
v Alerts by Criteria - Select this option to export specific alerts to QRadar. This option displays a
new field where you can define your alert criteria.
7. From Export Malware Events, select None.
8. From Export Frequency, select Every Alert / Malware.
9. In the Save As field, type a name for your export.
10. Click Save.
11. Optional: To verify that events are forwarded to QRadar, you can click Run Now.
© Copyright IBM Corp. 2005, 2018
369
Run Now is intended as a test tool to verify that alerts selected by criteria are exported from your
Fidelis appliance. This option is not available if you selected to export all events in “Configuring
Fidelis XPS” on page 369.
The configuration is complete. The log source is added to QRadar as Fidelis XPS syslog events are
automatically discovered. Events that are forwarded to QRadar by Fidelis XPS are displayed on the
Log Activity tab of QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Fidelis XPS.
However, you can manually create a log source for QRadar to receive syslog events.
About this task
The following configuration steps are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Fidelis XPS.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 214. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Fidelis XPS appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
370
QRadar DSM Configuration Guide
57 FireEye
The IBM Security QRadar DSM for FireEye accepts syslog events in Log Event Extended Format (LEEF)
and Common Event Format (CEF).
This DSM applies to FireEye CMS, MPS, EX, AX, NX, FX, and HX appliances. QRadar records all relevant
notification alerts that are sent by FireEye appliances.
The following table identifies the specifications for the FireEye DSM.
Table 215. FireEye DSM specifications
Specification
Value
Manufacturer
FireEye
DSM name
FireEye MPS
Supported versions
CMS, MPS, EX, AX, NX, FX, and HX
RPM file name
DSM-FireEyeMPS-QRadar_versionBuild_number.noarch.rpm
Protocol
Syslog and TLS Syslog
QRadar recorded event types
All relevant events
Auto discovered?
Yes
Includes identity?
No
More information
FireEye website (www.fireeye.com)
To integrate FireEye with QRadar, use the following procedures:
1. If automatic updates are not enabled, download and install the DSM Common and FireEye MPS RPM
on your QRadar Console.
2. Download and install the latest TLS Syslog Protocol RPM on QRadar.
3. For each instance of FireEye in your deployment, configure the FireEye system to forward events to
QRadar.
4.
For each instance of FireEye, create an FireEye log source on the QRadar Console. The following
tables explain how to configure a log source in Syslog and TLS Syslog for FireEye.
Table 216. Configuring the Syslog log source protocols for FireEye
Parameter
Description
Log Source Type
FireEye
Protocol Configuration
Syslog
Log Source Identifier
Type the IP address or host name for the log source as
an identifier for events from your device.
Table 217. Configuring the TLS Syslog log source protocols for FireEye
Parameter
Description
Log Source Type
FireEye
Protocol Configuration
TLS Syslog
© Copyright IBM Corp. 2005, 2018
371
Table 217. Configuring the TLS Syslog log source protocols for FireEye (continued)
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as
an identifier for events from your device.
TLS Listen Port
The default TLS listen port is 6514.
Authentication Mode
The mode by which your TLS connection is
authenticated. If you select the TLS and Client
Authentication option, you must configure the certificate
parameters.
Certificate Type
The type of certificate to use for authentication. If you
select the Provide Certificate option, you must configure
the file paths for the server certificate and the private
key.
Provided Server Certificate Path
The absolute path to the server certificate.
Provided Private Key Path
The absolute path to the private key.
Note: The corresponding private key must be a
DER-encoded PKCS8 key. The configuration fails with
any other key format.
Maximum Connections
The Maximum Connections parameter controls how
many simultaneous connections the TLS Syslog protocol
can accept for each Event Collector.
The connection limit across all TLS syslog log source
configurations is 1000 connections for each Event
Collector. The default for each device connection is 50.
Note: Automatically discovered log sources that share a
listener with another log source, such as if you use the
same port on the same event collector, count only one
time towards the limit.
Look at “Adding a log source” on page 4 for more common parameters that occur in Syslog and “TLS
syslog protocol configuration options” on page 48 for more TLS Syslog protocol-specific parameters
and their configurations.
Related tasks:
“Configuring your FireEye HX system for communication with QRadar” on page 373
To enable FireEye HX to communicate with IBM Security QRadar, configure your FireEye HX appliance
to forward syslog events.
“Configuring your FireEye system for communication with QRadar”
To enable FireEye to communicate with IBM Security QRadar, configure your FireEye appliance to
forward syslog events.
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring your FireEye system for communication with QRadar
To enable FireEye to communicate with IBM Security QRadar, configure your FireEye appliance to
forward syslog events.
Procedure
1. Log in to the FireEye appliance by using the CLI.
2. To activate configuration mode, type the following commands:
372
QRadar DSM Configuration Guide
enable
configure terminal
3. To enable rsyslog notifications, type the following command:
fenotify rsyslog enable
4. To add QRadar as an rsyslog notification consumer, type the following command:
fenotify rsyslog trap-sink QRadar
5. To specify the IP address for the QRadar system that you want to receive rsyslog trap-sink
notifications, type the following command:
fenotify rsyslog trap-sink QRadar address <QRadar_IP_address>
6. To define the rsyslog event format, type the following command:
fenotify rsyslog trap-sink QRadar prefer message format leef
7. To save the configuration changes to the FireEye appliance, type the following command:
write memory
Related tasks:
“Configuring your FireEye HX system for communication with QRadar”
To enable FireEye HX to communicate with IBM Security QRadar, configure your FireEye HX appliance
to forward syslog events.
Configuring your FireEye HX system for communication with QRadar
To enable FireEye HX to communicate with IBM Security QRadar, configure your FireEye HX appliance
to forward syslog events.
Procedure
1. Log in to the FireEye HX appliance by using the CLI.
2. To activate configuration mode, type the following commands:
enable
configure terminal
3. To add a remote syslog server destination, type the following commands:
logging <remote_IP_address> trap none
logging <remote_IP_address> trap override class cef priority info
4. To save the configuration changes to the FireEye HX appliance, type the following command:
write mem
57 FireEye
373
374
QRadar DSM Configuration Guide
58 FORCEPOINT
IBM Security QRadar supports a range of FORCEPOINT DSMs.
FORCEPOINT is formerly known as Websense.
Related concepts:
155, “Websense,” on page 987
QRadar supports a range of Websense DSMs.
FORCEPOINT Stonesoft Management Center
The IBM Security QRadar DSM for FORCEPOINT Stonesoft Management Center collects events from a
StoneGate device by using syslog.
The following table describes the specifications for the Stonesoft Management Center DSM:
Table 218. Stonesoft Management Center DSM specifications
Specification
Value
Manufacturer
FORCEPOINT
DSM name
Stonesoft Management Center
RPM file name
DSM-StonesoftManagementCenter-QRadar_versionbuild_number.noarch.rpm
Supported versions
5.4 to 6.1
Protocol
Syslog
Event format
LEEF
Recorded event types
Management Center, IPS, Firewall, and VPN events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
FORCEPOINT website (https://www.forcepoint.com)
To integrate FORCEPOINT Stonesoft Management Center with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v DSMCommon RPM
v Stonesoft Management Center DSM RPM
2. Configure your StoneGate device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a Stonesoft Management Center log
source on the QRadar Console. The following table describes the parameters that require specific
values to collect events from Stonesoft Management Center:
Table 219. Stonesoft Management Center log source parameters
Parameter
Value
Log Source type
Stonesoft Management Center
Protocol Configuration
Syslog
© Copyright IBM Corp. 2005, 2018
375
Table 219. Stonesoft Management Center log source parameters (continued)
Parameter
Value
Log Source Identifier
Type a unique name for the log source.
4. Verify that QRadar is configured correctly.
The following table shows a sample normalized event message from Stonesoft Management Center:
Table 220. Stonesoft Management Center sample message
Event name
Low level category
Sample log message
Generic_UDP-RuggedDirector-Denial-Of-Service
Misc DoS
LEEF:1.0|FORCEPOINT
|IPS|5.8.5|Generic_UDP-RuggedDirector-Denial-Of-Service|dev
TimeFormat=MMM dd yyyy HH:mm:
ss
srcMAC=00:00:00:00:00:
00
sev=2
dstMAC=00:00:00:
00:00:00
devTime=Feb 23 2017
10:13:58
proto=17
dstPort=
00000
srcPort=00000
dst=
127.0.0.1
src=127.0.0.1
action=Permit
logicalInter
face=NY2-1302-DMZ_IPS_ASA_Primary
sender="username" Sensor
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring FORCEPOINT Stonesoft Management Center to
communicate with QRadar
Configure Stonesoft Management Center to communicate with QRadar by editing the
LogServerConfiguration.txt file. Configuring the text file allows Stonesoft Management Center to
forward events in LEEF format by using syslog to QRadar.
Procedure
1. Log in to the appliance that hosts your Stonesoft Management Center.
2. Stop the Stonesoft Management Center Log Server.
3. In Windows, select one of the following methods to stop the Log Server.
v Stop the Log Server in the Windows Services list.
v Run the batch file <installation path>/bin/sgStopLogSrv.bat.
In Linux - To stop the Log Server in Linux, run the script <installation path>/bin/sgStopLogSrv.sh
4. Edit the LogServerConfiguration.txt file. The configuration file is located in the following directory:
<installation path>/data/LogServerConfiguration.txt
5. Configure the following parameters in the LogServerConfiguration.txt file:
Table 221. Log server configuration options
Parameter
Value
Description
SYSLOG_EXPORT_FORMAT
LEEF
Type LEEF as the export format to use for syslog.
376
QRadar DSM Configuration Guide
Table 221. Log server configuration options (continued)
Parameter
Value
Description
SYSLOG_EXPORT_ALERT
YES | NO
Type one of the following values:
v Yes - Exports alert entries to QRadar by using the
syslog protocol.
v No - Alert entries are not exported.
SYSLOG_EXPORT_FW
YES | NO
Type one of the following values:
v Yes - Exports firewall and VPN entries to QRadar
by using the syslog protocol.
v No - Firewall and VPN entries are not exported.
SYSLOG_EXPORT_IPS
YES | NO
Type one of the following values:
v Yes - Exports IPS logs to QRadar by using the
syslog protocol.
v No - IPS logs are not exported.
SYSLOG_PORT
514
Type 514 as the UDP port for forwarding syslog
events to QRadar.
SYSLOG_SERVER_ADDRESS
QRadar IPv4
Address
Type the IPv4 address of your QRadar Console or
Event Collector.
6. Save the LogServerConfiguration.txt file.
7. Start the Log Server.
v Windows - Type <installation path>/bin/sgStartLogSrv.bat.
v Linux - Type <installation path>/bin/sgStartLogSrv.sh.
For detailed configuration instructions, see the StoneGate Management Center Administrator's Guide.
What to do next
You are now ready to configure a traffic rule for syslog.
Note: A firewall rule is only required if your QRadar Console or Event Collector is separated by a
firewall from the Stonesoft Management Server. If no firewall exists between the Stonesoft Management
Server and QRadar, you need to configure the log source in QRadar.
Configuring a syslog traffic rule for FORCEPOINT Stonesoft
Management Center
If your Stonesoft Management Center and QRadar are separated by a firewall in your network, you must
modify your firewall or IPS policy to allow traffic between the Stonesoft Management Center and
QRadar.
Procedure
1. From the Stonesoft Management Center, select one of the following methods for modifying a traffic
rule.
v Firewall policies - Select Configuration > Configuration > Firewall.
v IPS policies - Select Configuration > Configuration > IPS.
2. Select the type of policy to modify.
v Firewall - Select Firewall Policies > Edit Firewall Policy.
v IPS - Select IPS Policies > Edit Firewall Policy.
3. Add an IPv4 Access rule by configuring the following parameters for the firewall policy:
58 FORCEPOINT
377
Parameter
Value
Source
Type the IPv4 address of your Stonesoft Management
Center Log server.
Destination
Type the IPv4 address of your QRadar Console or Event
Collector.
Service
Select Syslog (UDP).
Action
Select Allow.
Logging
Select None.
Note: In most cases, you might want to set the logging value to None. Logging syslog connections
without configuring a syslog filter can create a loop. For more information, see the StoneGate
Management Center Administrator's Guide.
4. Save your changes and then refresh the policy on the firewall or IPS.
What to do next
You are now ready to configure the log source in QRadar.
Forcepoint TRITON
The Forcepoint V-Series Content Gateway DSM for IBM Security QRadar supports events for web content
from several Forcepoint TRITON solutions, including Web Security, Web Security Gateway, Web Security
Gateway Anywhere, and V-Series appliances.
About this task
Forcepoint TRITON collects and streams event information to QRadar by using the Forcepoint
Multiplexer component. Before you configure QRadar, you must configure the Forcepoint TRITON
solution to provide LEEF formatted syslog events.
Before you can configure Forcepoint TRITON Web Security solutions to forward events to QRadar, you
must ensure that your deployment contains a Forcepoint Multiplexer.
The Forcepoint Multiplexer is supported on Windows, Linux, and on Forcepoint V-Series appliances.
To configure a Forcepoint Multiplexer on a Forcepoint Triton or V-Series appliance:
Procedure
1. Install an instance of Forcepoint Multiplexer for each Forcepoint Policy Server component in your
network.
v For Microsoft Windows - To install the Forcepoint Multiplexer on Windows, use the TRITON
Unified Installer. The Triton Unified Installer is available for download at http://
www.myforcepoint.com.
v For Linux - To install the Forcepoint Multiplexer on Linux, use the Web Security Linux Installer.
The Web Security Linux Installer is available for download at http://www.myforcepoint.com.
For information on adding a Forcepoint Multiplexer to software installations, see your Forcepoint
Security Information Event Management (SIEM) Solutions documentation.
2. Enable the Forcepoint Multiplexer on a V-Series appliance that is configured as a full policy source or
user directory and filtering appliance:
a. Log in to your Forcepoint TRITON Web Security Console or V-Series appliance.
3. From the Appliance Manager, select Administration > Toolbox > Command Line Utility.
378
QRadar DSM Configuration Guide
4. Click the Forcepoint Web Security tab.
5. From the Command list, select multiplexer, then use the enable command.
6. Repeat “Forcepoint TRITON” on page 378 and “Forcepoint TRITON” on page 378 to enable one
Multiplexer instance for each Policy Server instance in your network.
If more than one Multiplexer is installed for a Policy Server, only the last installed instance of the
Forcepoint Multiplexer is used. The configuration for each Forcepoint Multiplexer instance is stored
by its Policy Server.
What to do next
You can now configure your Forcepoint TRITON appliance to forward syslog events in LEEF format to
QRadar.
Configuring syslog for Forcepoint TRITON
To collect events, you must configure syslog forwarding for Forcepoint TRITON.
Procedure
1. Log in to your Forcepoint TRITON Web Security Console.
2. On the Settings tab, select General > SIEM Integration.
3. Select the Enable SIEM integration for this Policy Server check box.
4. In the IP address or hostname field, type the IP address of your QRadar.
5. In the Port field, type 514.
6. From the Transport protocol list, select either the TCP or UDP protocol option.
QRadar supports syslog events for TCP and UDP protocols on port 514.
7. From the SIEM format list, select syslog/LEEF (QRadar)
8. Click OK to cache any changes.
9. Click Deploy to update your Forcepoint TRITON security components or V-Series appliances.
The Forcepoint Multiplexer connects to Forcepoint Filtering Service and ensures that event log
information is provided to QRadar.
Configuring a log source for Forcepoint TRITON
IBM Security QRadar automatically discovers and creates a log source for syslog events in LEEF format
from Forcepoint TRITON and V-Series appliances.
About this task
The configuration steps for creating a log source are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Forcepoint V Series.
58 FORCEPOINT
379
Note: Forcepoint TRITON uses the Forcepoint V Series Content Gateway DSM for parsing events.
When you manually add a log source to QRadar for Forcepoint TRITON, you should select
Forcepoint V Series.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 222. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
Forcepoint TRITON or V-Series appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar.
Forcepoint V-Series Data Security Suite
The Forcepoint V-Series Data Security Suite DSM for IBM Security QRadar supports Forcepoint V-Series
appliances and the Data Security Suite (DSS) software.
Configuring syslog for Forcepoint V-Series Data Security Suite
The Forcepoint V-Series Data Security Suite DSM accepts events using syslog. Before you can integrate
IBM Security QRadar you, must enable the Forcepoint V-Series appliance to forward syslog events in the
Data Security Suite (DSS) Management Console.
Procedure
1. Select Policies > Policy Components > Notification Templates.
2. Select an existing Notification Template or create a new template.
3. Click the General tab.
4. Click Send Syslog Message.
5. Select Options > Settings > Syslog to access the Syslog window.
The syslog window enables administrators to define the IP address/host name and port number of
the syslog in their organization. The defined syslog receives incident messages from the Forcepoint
Data Security Suite DSS Manager.
6. The syslog is composed of the following fields:
DSS Incident|ID={value}|action={display value - max}|
urgency= {coded}|
policy categories={values,,,}|source={value-display name}|
destinations={values...}|channel={display name}|
matches= {value}|detaills={value}
v Max length for policy categories is 200 characters.
v Max length for destinations is 200 characters.
v Details and source are reduced to 30 characters.
7. Click Test Connection to verify that your syslog is accessible.
What to do next
You can now configure the log source in QRadar. The configuration is complete. The log source is added
to QRadar as OSSEC events are automatically discovered. Events that are forwarded to QRadar by
OSSEC are displayed on the Log Activity tab of QRadar.
380
QRadar DSM Configuration Guide
Configuring a log source for Forcepoint V-Series Data Security Suite
IBM Security QRadar automatically discovers and creates a log source for syslog events from Forcepoint
V-Series Data Security Suite.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Forcepoint V Series.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 223. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from your
Forcepoint V-Series Data Security Suite DSM
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Forcepoint V-Series Content Gateway
The Forcepoint V-Series Content Gateway DSM for IBM Security QRadar supports events for web content
on Forcepoint V-Series appliances with the Content Gateway software.
The Forcepoint V-Series Content Gateway DSM accepts events using syslog to stream events or by using
the log file protocol to provide events to QRadar. Before you can integrate your appliance with QRadar,
you must select one of the following configuration methods:
v To configure syslog for your Forcepoint V-Series, see Configure Syslog for Forcepoint V-Series Data
Security Suite.
v To configure the log file protocol for your Forcepoint V-Series, see Log file protocol for Forcepoint
V-Series Content Gateway.
Configure syslog for Forcepoint V-Series Content Gateway
The Forcepoint V-Series DSM supports Forcepoint V-Series appliances that run the Forcepoint Content
Gateway on Linux software installations.
Before you configure IBM Security QRadar, you must configure the Forcepoint Content Gateway to
provide LEEF formatted syslog events.
58 FORCEPOINT
381
Configuring the Management Console for Forcepoint V-Series Content
Gateway
You can configure event logging in the Content Gateway Manager.
Procedure
1. Log into your Forcepoint Content Gateway Manager.
2. Click the Configure tab.
3. Select Subsystems > Logging.
The General Logging Configuration window is displayed.
4. Select Log Transactions and Errors.
5. Select Log Directory to specify the directory path of the stored event log files.
The directory that you define must exist and the Forcepoint user must have read and write
permissions for the specified directory.
The default directory is /opt/WGC/logs.
6. Click Apply.
7. Click the Custom tab.
8. In the Custom Log File Definitions window, type the following text for the LEEF format.
<LogFormat>
<Name = "leef"/>
<Format = "LEEF:1.0|Forcepoint|WCG|7.6|
%<wsds>|cat=%<wc>
src=%<chi> devTime=%<cqtn>
devTimeFormat=dd/MMM/yyyy:HH:mm:ss Z
http-username=%<caun> url=%<cquc>
method=%<cqhm> httpversion=%<cqhv>
cachecode=%<crc>dstBytes=%<sscl> dst=%<pqsi>
srcBytes=%<pscl> proxy-status-code=%<pssc>
server-status-code=%<sssc> usrName=%<wui>
duration=%<ttms>"/>
</LogFormat>
<LogObject>
<Format = "leef"/>
<Filename = "leef"/>
</LogObject>
Note: The fields in the LEEF format string are tab separated. You might be required to type the LEEF
format in a text editor and then cut and paste it into your web browser to retain the tab separations.
The definitions file ignores extra white space, blank lines, and all comments.
9. Select Enabled to enable the custom logging definition.
10. Click Apply.
What to do next
You can now enable event logging for your Forcepoint Content Gateway.
Enabling Event Logging for Forcepoint V-Series Content Gateway
If you are using a Forcepoint V-Series appliance, contact Forcepoint Technical Support to enable this
feature.
Procedure
1. Log in to the command-line Interface (CLI) of the server running Forcepoint Content Gateway.
2. Add the following lines to the end of the /etc/rc.local file:
382
QRadar DSM Configuration Guide
( while [ 1 ] ; do tail -n1000 -F /opt/WCG/logs/leef.log |
nc <IP Address> 514 sleep 1 done ) &
Where <IP Address> is the IP address for IBM Security QRadar.
3. To start logging immediately, type the following command:
nohup /bin/bash -c "while [ 1 ] ; do
tail -F /opt/WCG/logs/leef.log | nc <IP Address> 514;
sleep 1; done" &
Note: You might need to type the logging command in “Enabling Event Logging for Forcepoint
V-Series Content Gateway” on page 382 or copy the command to a text editor to interpret the
quotation marks.
The configuration is complete. The log source is added to QRadar as syslog events from Forcepoint
V-Series Content Gateway are automatically discovered. Events forwarded by Forcepoint V-Series
Content Gateway are displayed on the Log Activity tab of QRadar.
Configuring a log source for Forcepoint V-Series Content Gateway
QRadar automatically discovers and creates a log source for syslog events from Forcepoint V-Series
Content Gateway.
About this task
The following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Forcepoint V Series.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 224. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Forcepoint V-Series Content Gateway appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
Log file protocol for Forcepoint V-Series Content Gateway
The log file protocol allows IBM Security QRadar to retrieve archived log files from a remote host.
The Forcepoint V-Series DSM supports the bulk loading of log files from your Forcepoint V-Series
Content Gateway using the log file protocol to provide events on a scheduled interval. The log files
contain transaction and error events for your Forcepoint V-Series Content Gateway:
58 FORCEPOINT
383
Configuring the Content Management Console for Forcepoint V-Series Content
Gateway
Configure event logging in the Content Management Console.
Procedure
1. Log into your Forcepoint Content Gateway interface.
2. Click the Configure tab.
3. Select Subsystems > Logging.
4. Select Log Transactions and Errors.
5. Select Log Directory to specify the directory path of the stored event log files.
The directory you define must already exist and the Forcepoint user must have read and write
permissions for the specified directory.
The default directory is /opt/WGC/logs.
6. Click Apply.
7. Click the Formats tab.
8. Select Netscape Extended Format as your format type.
9. Click Apply.
What to do next
You can now enable event logging for your Forcepoint V-Series Content Gateway.
Configuring a log file protocol log source for Forcepoint V-Series Content Gateway
When you configure your Forcepoint V-Series DSM to use the log file protocol, ensure that the host name
or IP address that is configured in the Forcepoint V-Series is configured the same as the Remote Host
parameter in the log file protocol configuration.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select the Forcepoint V Series.
9. From the Protocol Configuration list, select the Log File.
10. From the Service Type list, select the Secure File Transfer Protocol (SFTP) option.
11. In the FTP File Pattern field, type extended.log_.*.old.
12. In the Remote Directory field, type/opt/WCG/logs.
This is the default directory for storing the Forcepoint V-Series log files that you specified in
“Configuring the Content Management Console for Forcepoint V-Series Content Gateway.”
13. From the Event Generator list, select LINEBYLINE.
14. Click Save.
15. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. .
384
QRadar DSM Configuration Guide
59 ForeScout CounterACT
The ForeScout CounterACT DSM for IBM Security QRadar accepts Log Extended Event Format (LEEF)
events from CounterACT using syslog.
QRadar records the following ForeScout CounterACT events:
v Denial of Service (DoS)
v Authentication
v Exploit
v Suspicious
v System
Configuring a log source
To integrate ForeScout CounterACT with IBM Security QRadar, you must manually create a log source to
receive policy-based syslog events.
About this task
QRadar does not automatically discover or create log sources for syslog events from ForeScout
CounterACT appliances.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select ForeScout CounterACT.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 225. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your ForeScout CounterACT appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar.
Configuring the ForeScout CounterACT Plug-in
Before you configure IBM Security QRadar, you must install a plug-in for your ForeScout CounterACT
appliance and configure ForeScout CounterACT to forward syslog events to QRadar.
© Copyright IBM Corp. 2005, 2018
385
About this task
To integrate QRadar with ForeScout CounterACT, you must download, install, and configure a plug-in
for CounterACT. The plug-in extends ForeScout CounterACT and provides the framework for forwarding
LEEF events to QRadar.
Procedure
1. From the ForeScout website, download the plug-in for ForeScout CounterACT.
2. Log in to your ForeScout CounterACT appliance.
3. From the CounterACT Console toolbar, select Options > Plugins > Install. Select the location of the
plug-in file.
The plug-in is installed and displayed in the Plug-ins pane.
4. From the Plug-ins pane, select the QRadar plug-in and click Configure.
The Add QRadar wizard is displayed.
5. In the Server Address field, type the IP address of QRadar.
6. From the Port list, select 514.
7. Click Next.
8. From the Assigned CounterACT devices pane, choose one of the following options:
v Default Server - Select this option to make all devices on this ForeScout CounterACT, forward
events to QRadar.
v Assign CounterACT devices - Select this option to assign which individual devices that are
running on ForeScout CounterACT forward events to QRadar. The Assign CounterACT devices
option is only available if you have one or more ForeScout CounterACT servers.
9. Click Finish.
The plug-in configuration is complete. You are now ready to define the events that are forwarded to
QRadar by ForeScout CounterACT policies.
Configuring ForeScout CounterACT Policies
ForeScout CounterACT policies test conditions to trigger management and remediation actions on the
appliance.
About this task
The plug-in provides an extra action for policies to forward the event to the IBM Security QRadar by
using syslog. To forward events to QRadar, you must define a CounterACT policy that includes the
QRadar update action.
The policy condition must be met at least one time to initiate an event send to QRadar. You must
configure each policy to send updates to QRadar for events you want to record.
Procedure
1. Select a policy for ForeScout CounterACT.
2. From the Actions tree, select Audit > Send Updates to QRadar Server.
3. From the Contents tab, configure the following value:
Select the Send host property results check box.
4. Choose one of the type of events to forward for the policy:
v Send All - Select this option to include all properties that are discovered for the policy to QRadar.
v Send Specific - Select this option to select and send only specific properties for the policy to
QRadar.
386
QRadar DSM Configuration Guide
5. Select the Send policy status check box.
6. From the Trigger tab, select the interval ForeScout CounterACT uses for forwarding the event to
QRadar:
v Send when the action starts - Select this check box to send a single event to QRadar when the
conditions of your policy are met.
v Send when information is updated - Select this check box to send a report when there is a change
in the host properties that are specified in the Contents tab.
v Send periodically every - Select this check box to send a reoccurring event to QRadar on an
interval if the policy conditions are met.
7. Click OK to save the policy changes.
8. Repeat this process to configure any additional policies with an action to send updates to QRadar.
The configuration is complete. Events that are forwarded by ForeScout CounterACT are displayed on
the Log Activity tab of QRadar.
59 ForeScout CounterACT
387
388
QRadar DSM Configuration Guide
60 Fortinet FortiGate Security Gateway
The IBM Security QRadar SIEM DSM for Fortinet FortiGate Security Gateway collects events from
Fortinet FortiGate Security Gateway and Fortinet FortiAnalyzer products.
The following table identifies the specifications for the Fortinet FortiGate Security Gateway DSM:
Table 226. Fortinet FortiGate Security Gateway DSM specifications
Specification
Value
Manufacturer
Fortinet
DSM name
Fortinet FortiGate Security Gateway
RPM file name
DSM-FortinetFortiGate-QRadar_version-build_number.noarch.rpm
Supported versions
FortiOS V5.6 and earlier
Protocol
Syslog
Syslog Redirect
Recorded event types
All events
Auto discovered?
Yes
Includes identity?
Yes
Includes custom properties?
Yes
More information
Fortinet website (http://www.fortinet.com)
To integrate Fortinet FortiGate Security Gateway DSM with QRadar, complete the following steps:
1. If automatic updates are not enabled, download the most recent version of the Fortinet FortiGate
Security Gateway RPM on your QRadar Console:
2. Download and install the Syslog Redirect protocol RPM to collect events through Fortinet
FortiAnalyzer. When you use the Syslog Redirect protocol, QRadar can identify the specific Fortinet
FortiGate Security Gateway firewall that sent the event.
3. For each instance of Fortinet FortiGate Security Gateway, configure your Fortinet FortiGate Security
Gateway system to send syslog events to QRadar.
4. If QRadar does not automatically detect the log source for Fortinet FortiGate Security Gateway, you
can manually add the log source. For the protocol configuration type, select Syslog, and then
configure the parameters.
5. If you want QRadar to receive events from Fortinet FortiAnalyzer, manually add the log source. For
the protocol configuration type, select Syslog Redirect, and then configure the parameters.
The following table lists the specific parameter values that are required for Fortinet FortiAnalyzer
event collection:
Parameter
Value
Log Source Identifier Regex
devname=([\w-]+)
Listen Port
517
Protocol
UDP
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
© Copyright IBM Corp. 2005, 2018
389
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Configuring a syslog destination on your Fortinet FortiGate Security Gateway device”
To forward Fortinet FortiGate Security Gateway events to IBM Security QRadar, you must configure a
syslog destination.
“Configuring a syslog destination on your Fortinet FortiAnalyzer device”
To forward Fortinet FortiAnalyzer events to IBM Security QRadar, you must configure a syslog
destination.
Configuring a syslog destination on your Fortinet FortiGate Security
Gateway device
To forward Fortinet FortiGate Security Gateway events to IBM Security QRadar, you must configure a
syslog destination.
Procedure
1. Log in to the command line on your Fortinet FortiGate Security Gateway appliance.
2. Type the following commands, in order, replacing the variables with values that suit your
environment.
config log syslogd setting
set status enable
set facility <facility_name>
set csv {disable | enable}
set port <port_integer>
set reliable enable
set server <IP_address>
end
example: set facility syslog
Note: If you set the value of reliable as enable, it sends as TCP; if you set the value of reliable as
disable, it sends as UDP.
What to do next
Your deployment might have multiple Fortinet FortiGate Security Gateway instances that are configured
to send event logs to FortiAnalyzer. If you want to send FortiAnalyzer events to QRadar, see Configuring
a syslog destination on your Fortinet FortiAnalyzer device.
Configuring a syslog destination on your Fortinet FortiAnalyzer device
To forward Fortinet FortiAnalyzer events to IBM Security QRadar, you must configure a syslog
destination.
Procedure
1. Log in to your FortiAnalyzer device.
2. On the Advanced tree menu, select Syslog Server.
3. On the toolbar, click Create New.
4. Configure the Syslog Server parameters:
Parameter
Description
Port
The default port is 514.
5. Click OK.
390
QRadar DSM Configuration Guide
61 Foundry FastIron
You can integrate a Foundry FastIron device with IBM Security QRadar to collect all relevant events
using syslog.
To do this you must configure syslog and your log source.
Configuring syslog for Foundry FastIron
To integrate IBM Security QRadar with a Foundry FastIron RX device, you must configure the appliance
to forward syslog events.
Procedure
1. Log in to the Foundry FastIron device command-line interface (CLI).
2. Type the following command to enable logging:
logging on
Local syslog is now enabled with the following defaults:
v Messages of all syslog levels (Emergencies - Debugging) are logged.
v Up to 50 messages are retained in the local syslog buffer.
v No syslog server is specified.
3. Type the following command to define an IP address for the syslog server:
logging host <IP Address>
Where <IP Address> is the IP address of your QRadar.
You are now ready to configure the log source in QRadar.
Configuring a log source
QRadar automatically discovers and creates a log source for syslog events from Foundry FastIron. The
following configuration steps are optional.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Foundry FastIron.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for
events from your Foundry FastIron appliance.
© Copyright IBM Corp. 2005, 2018
391
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
392
QRadar DSM Configuration Guide
62 FreeRADIUS
The IBM Security QRadar DSM for FreeRADIUS collects events from your FreeRADIUS device.
The following table lists the specifications for the FreeRADIUS DSM:
Table 227. FreeRADIUS DSM specifications
Specification
Value
Manufacturer
FreeRADIUS
DSM name
FreeRADIUS
RPM file name
DSM-FreeRADIUS-Qradar_versionbuild_number.noarch.rpm
Supported versions
V2.x
Event format
Syslog
Recorded event types
All events
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
FreeRADIUS website (http://freeradius.org)
To send logs from FreeRADIUS to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the
FreeRADIUS DSM RPM on your QRadar Console.
2. Configure your FreeRADIUS device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a FreeRADIUS log source on the QRadar
Console. The following table describes the parameters that require specific values for FreeRADIUS
event collection:
Table 228. FreeRADIUS log source parameters
Parameter
Value
Log Source type
FreeRADIUS
Protocol Configuration
Syslog
Configuring your FreeRADIUS device to communicate with QRadar
Configure FreeRADIUS to send logs to the syslog daemon of the host and configure the daemon to send
events to QRadar.
Before you begin
You must have a working knowledge of syslog configuration and the Linux distribution.
About this task
FreeRADIUS has multiple distributions. Some files might not be in the same locations that are described
in this procedure. For example, the location of the FreeRADIUS startup script is based on distribution.
Conceptually, the configuration steps are the same for all distributions.
© Copyright IBM Corp. 2005, 2018
393
Procedure
1. Log in to the system that hosts FreeRADIUS.
2. Edit the /etc/freeradius/radius.conf file.
3. Change the text in the file to match the following lines:
logdir = syslog
Log_destination = syslog
log{
destination = syslog
syslog_facility = daemon
stripped_names = no
auth = yes
auth_badpass = no
auth_goodpass = no
}
4. Edit the /etc/syslog.conf file.
5. To configure log options, add the following text.
# .=notice logs authentication messages (L_AUTH).
# <facility_name>.=notice @<IP_address_of_QRadar_Event_Collector_or_QRadar_Console>
# .=err logs module errors for FreeRADIUS.
#<facility_name>.=err @<IP_address_of_QRadar_Event_Collector_or_QRadar_Console>
# .* logs messages to the same target.
# <facility_name>.* @<IP_address_of_QRadar_Event_Collector_or_QRadar_Console>
An example syslog facility name is local1. You can rename it.
To configure a log option, remove the comment tag (#) from one of the active lines that contains an @
symbol.
6. If the configuration change does not load automatically, restart the syslog daemon. The method to
restart the syslog daemon depends on the distribution that is used. The following table lists possible
methods.
Operating system distribution
Command to restart daemon
Red Hat Enterprise Linux
service syslog restart
Debian Linux or Ubuntu Linux
/etc/init.d/syslog restart
FreeBSD operating system
/etc/rc.d/syslogd restart
7. Add the following options to the FreeRADIUS startup script:
v -l syslog
v -g <facility_name>
The -g value must match the facility name in Step 5.
8. Restart FreeRADIUS.
394
QRadar DSM Configuration Guide
63 Generic
IBM Security QRadar supports a range of Generic DSMs.
Generic Authorization Server
The generic authorization server DSM for IBM Security QRadar records all relevant generic authorization
events by using syslog.
You need to configure QRadar to interpret the incoming generic authorization events, and manually
create a log source.
Configuring event properties
To configure IBM Security QRadar to interpret the incoming generic authorization events:
Procedure
1. Forward all authentication server logs to your QRadar system.
For information on forwarding authentication server logs to QRadar, see your generic authorization
server vendor documentation.
2. Open the following file:
/opt/QRadar/conf/genericAuthServer.conf
Make sure you copy this file to systems that host the Event Collector and the QRadar Console.
3. Restart the Tomcat server:
service tomcat restart
A message is displayed indicating that the Tomcat server is restarted.
4. Enable or disable regular expressions in your patterns by setting the regex_enabled property. By
default, regular expressions are disabled. For example:
regex_enabled=false
When you set the regex_enabled property to false, the system generates regular expressions (regex)
based on the tags you entered when you try to retrieve the corresponding data values from the logs.
When you set the regex_enabled property to true, you can define custom regex to control patterns.
These regex configurations are applied directly to the logs and the first captured group is returned.
When you define custom regex patterns, you must adhere to regex rules, as defined by the Java
programming language. For more information, see the following website: http://
download.oracle.com/javase/tutorial/essential/regex/
To integrate the generic authorization server with QRadar, make sure that you specify the classes
directly instead of using the predefined classes. For example, the digit class(/\d/) becomes /[0-9]/.
Also, instead of using numeric qualifiers, rewrite the expression to use the primitive qualifiers
(/?/,/*/ and /+/).
5. Review the file to determine a pattern for successful login:
For example, if your authentication server generates the following log message for accepted packets:
Jun 27 12:11:21 expo sshd[19926]: Accepted password for root from <IP_address> port 1727
ssh2
The pattern for successful login is:
Accepted password.
6. Add the following entry to the file:
login_success_pattern=<login success pattern>
© Copyright IBM Corp. 2005, 2018
395
Where: <login success pattern> is the pattern that is determined in “Configuring event properties” on
page 395.
For example:
login_success_pattern=Accepted password
All entries are case insensitive.
7. Review the file to determine a pattern for login failures.
For example, if your authentication server generates the following log message for login failures:
Jun 27 12:58:33 expo sshd[20627]: Failed password for root from <IP_address> port 1849 ssh2
The pattern for login failures is Failed password.
8. Add the following to the file:
login_failed_pattern=<login failure pattern>
Where: <login failure pattern> is the pattern that is determined for login failure.
For example:
login_failed_pattern=Failed password
All entries are case insensitive.
9. Review the file to determine a pattern for logout:
For example, if your authentication server generates the following log message for logout:
Jun 27 13:00:01 expo su(<Username>)[22723]: session closed for user genuser
The pattern for lookout is session closed.
10. Add the following to the genericAuthServer.conf file:
logout_pattern=<logout pattern>
Where: <logout pattern> is the pattern that is determined for logout in “Configuring event properties”
on page 395.
For example:
logout_pattern=session
All entries are case insensitive.
11. Review the file to determine a pattern, if present, for source IP address and source port.
For example, if your authentication server generates the following log message:
Jun 27 12:11:21 expo sshd[19926]: Accepted password for root from <IP_address> port 1727
ssh2
The pattern for source IP address is from and the pattern for source port is port.
12. Add an entry to the file for source IP address and source port:
source_ip_pattern=<source IP pattern>
source_port_pattern=<source port pattern>
Where: <source IP pattern> and <source port pattern> are the patterns that are identified in
“Configuring event properties” on page 395 for source IP address and source port.
For example:
source_ip_pattern=from
source_port_pattern=port
13. Review the file to determine whether a pattern exists for user name.
For example:
Jun 27 12:11:21 expo sshd[19926]: Accepted password for root from <IP_address> port 1727
ssh2
The pattern for user name is for.
14. Add an entry to the file for the user name pattern:
For example:
396
QRadar DSM Configuration Guide
user_name_pattern=for
You are now ready to configure the log source in QRadar.
Configuring a log source
To integrate generic authorization appliance event with IBM Security QRadar, you must manually create
a log source to receive the events as QRadar does not automatically discover or create log sources for
events from generic authorization appliances.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Configurable Authentication message filter.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 229. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your generic authorization appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are forwarded to QRadar by generic authorization
appliances are displayed on the Log Activity tab.
Generic Firewall
The generic firewall server DSM for IBM Security QRadar accepts events by using syslog. QRadar records
all relevant events.
Configure QRadar to interpret the incoming generic firewall events, and manually create a log source.
Configuring event properties
Configuration of IBM Security QRadar to interpret the incoming generic firewall events.
About this task
Use the following procedure to configure event properties:
Procedure
1. Forward all firewall logs to your QRadar.
For information on forwarding firewall logs from your generic firewall to QRadar, see your firewall
vendor documentation.
2. Open the following file:
/opt/QRadar/conf/genericFirewall.conf
63 Generic
397
Make sure you copy this file to systems that host the Event Collector and the QRadar Console.
3. Restart the Tomcat server:
service tomcat restart
A message is displayed indicating that the Tomcat server is restarted.
4. Enable or disable regular expressions in your patterns by setting the regex_enabled property. By
default, regular expressions are disabled.
For example:
regex_enabled=false
When you set the regex_enabled property to false, the system generates regular expressions based
on the tags you entered while you try to retrieve the corresponding data values from the logs.
When you set the regex_enabled property to true, you can define custom regex to control patterns.
These regex configurations are directly applied to the logs and the first captured group is returned.
When you define custom regex patterns, you must adhere to regex rules, as defined by the Java
programming language. For more information, see the following website: http://
download.oracle.com/javase/tutorial/essential/regex/
To integrate a generic firewall with QRadar, make sure that you specify the classes directly instead of
using the predefined classes. For example, the digit class (/\d/) becomes /[0-9]/. Also, instead of
using numeric qualifiers, rewrite the expression to use the primitive qualifiers (/?/,/*/ and /+/).
5. Review the file to determine a pattern for accepted packets.
For example, if your device generates the following log messages for accepted packets:
Aug. 5, 2005 08:30:00 Packet accepted. Source IP: <Source_IP_address> Source Port: 80
Destination IP: <Destination_IP_address> Destination Port: 80 Protocol: tcp
The pattern for accepted packets is Packet accepted.
6. Add the following to the file:
accept_pattern=<accept pattern>
Where: <accept pattern> is the pattern that is determined in “Configuring event properties” on page
397. For example:
accept pattern=Packet accepted
Patterns are case insensitive.
7. Review the file to determine a pattern for denied packets.
For example, if your device generates the following log messages for denied packets:
Aug. 5, 2005 08:30:00 Packet denied. Source IP: <Source_IP_address> Source Port: 21
Destination IP: <Destination_IP_address> Destination Port: 21 Protocol: tcp
The pattern for denied packets is Packet denied.
8. Add the following to the file:
deny_pattern=<deny pattern>
Where: <deny pattern> is the pattern that is determined in “Configuring event properties” on page
397.
Patterns are case insensitive.
9. Review the file to determine a pattern, if present, for the following parameters:
v source ip
v source port
v destination ip
v destination port
v protocol
For example, if your device generates the following log message:
398
QRadar DSM Configuration Guide
Aug. 5, 2005 08:30:00 Packet accepted. Source IP: <Source_IP_address> Source Port: 80
Destination IP: <Destination_IP_address> Destination Port: 80 Protocol: tcp
The pattern for source IP is Source IP.
10. Add the following to the file:
v source_ip_pattern=<source ip pattern>
v source_port_pattern=<source port pattern>
v destination_ip_pattern=<destination ip pattern>
v destination_port_pattern=<destination port pattern>
v protocol_pattern=<protocol pattern>
Where: <source ip pattern>, <source port pattern>, <destination ip pattern>, <destination
port pattern>, and <protocol pattern> are the corresponding patterns that are identified in
“Configuring event properties” on page 397.
Note: Patterns are case insensitive and you can add multiple patterns. For multiple patterns,
separate by using a # symbol.
11. Save and exit the file.
You are now ready to configure the log source in QRadar.
Configuring a log source
To integrate generic firewalls with IBM Security QRadar, you must manually create a log source to
receive the events as QRadar does not automatically discover or create log sources for events from
generic firewall appliances.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
The Data Sources pane is displayed.
4. Click the Log Sources icon.
The Log Sources window is displayed.
5. Click Add.
The Add a log source window is displayed.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Configurable Firewall Filter.
9. Using the Protocol Configuration list, select Syslog.
The syslog protocol configuration is displayed.
10. Configure the following values:
Table 230. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your generic firewall appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. Events that are forwarded to QRadar by generic firewalls are
displayed on the Log Activity tab.
63 Generic
399
400
QRadar DSM Configuration Guide
64 genua genugate
The IBM Security QRadar DSM for genua genugate collects events from a genua genugate device.
genua genugate produces logs from third-party software such as openBSD and sendMail. The genua
genugate DSM provides basic parsing for the logs from these third-party devices. To achieve more specify
parsing for these logs, install the specific DSM for that device.
The following table lists the specifications for the genua genugate DSM:
Table 231. genua genugate DSM specifications
Specification
Value
Manufacturer
genua
DSM name
genua genugate
RPM file name
DSM-GenuaGenugate-Qradar_versionbuild_number.noarch.rpm
Supported versions
8.2 and later
Protocol
Syslog
Recorded event types
General error messages
High availability
General relay messages
Relay-specific messages
genua programs/daemons
EPSI
Accounting Daemon - gg/src/acctd
Configfw
FWConfig
ROFWConfig
User-Interface
Webserver
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
genua website (https://www.genua.de/en/solutions/
high-resistance-firewall-genugate.html)
To send genua genugate events to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v DSMCommon RPM
v genua genugate DSM RPM
© Copyright IBM Corp. 2005, 2018
401
2. Configure your genua genugate device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a genua genugate log source on the
QRadar Console. Configure all required parameters and use the following table to identify specific
values for genua genugate:
Table 232. genua genugate log source parameters
Parameter
Value
Log Source type
genua genugate
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring genua genugate to send events to QRadar”
Configure genua genugate to send events to IBM Security QRadar.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring genua genugate to send events to QRadar
Configure genua genugate to send events to IBM Security QRadar.
Procedure
1. Log in to genua genugate.
2. Click System > Sysadmin > Logging page.
3. In the IBM QRadar IP Address field, type the IP address of your QRadar Console or Event Collector.
4. Select the Accounting to External check box.
5. Click OK.
402
QRadar DSM Configuration Guide
65 Great Bay Beacon
The Great Bay Beacon DSM for IBM Security QRadar supports syslog alerts from the Great Bay Beacon
Endpoint Profiler.
QRadar records all relevant Endpoint security events. Before you can integrate Great Bay Beacon with
QRadar, you must configure your Great Bay Beacon Endpoint Profiler to forward syslog event messages
to QRadar.
Configuring syslog for Great Bay Beacon
You can configure your Great Bay Beacon Endpoint Profiler to forward syslog events.
Procedure
1. Log in to your Great Bay Beacon Endpoint Profiler.
2. To create an event, select Configuration > Events > Create Events.
A list of currently configured events is displayed.
3. From the Event Delivery Method pane, select the Syslog check box.
4. To apply your changes, select Configuration Apply Changes > Update Modules.
5. Repeat “Configuring syslog for Great Bay Beacon” to configure all of the events that you want to
monitor in IBM Security QRadar.
6. Configure QRadar as an external log source for your Great Bay Beacon Endpoint Profiler.
For information on configuring QRadar as an external log source, see the Great Bay Beacon Endpoint
Profiler Configuration Guide.
You are now ready to configure the log source in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events from Great Bay
Beacon.
About this task
The following configuration steps are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Great Bay Beacon.
9. Using the Protocol Configuration list, select Syslog.
10. Configure the following values:
© Copyright IBM Corp. 2005, 2018
403
Table 233. Syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Great Bay Beacon appliance.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
404
QRadar DSM Configuration Guide
66 HBGary Active Defense
The HBGary Active Defense DSM for IBM Security QRadar accepts several event types that are
forwarded from HBGary Active Defense devices, such as access, system, system configuration, and policy
events.
Events from Active Defense are forwarded in the Log Event Extended Format (LEEF) to QRadar using
syslog. Before you can configure QRadar, you must configure a route for your HBGary Active Defense
device to forward events to a syslog destination.
Configuring HBGary Active Defense
You can configure a route for syslog events in Active Defense for QRadar.
Procedure
1. Log in to the Active Defense Management Console.
2. From the navigation menu, select Settings > Alerts.
3. Click Add Route.
4. In the Route Name field, type a name for the syslog route you are adding to Active Defense.
5. From the Route Type list, select LEEF (Q1 Labs).
6. In the Settings pane, configure the following values:
v Host - Type the IP address or hostname for your QRadar Console or Event Collector.
v Port - Type 514 as the port number.
7. In the Events pane, select any events that you want to forward to QRadar.
8. Click OK to save your configuration changes.
The Active Defense device configuration is complete. You are now ready to configure a log source in
QRadar. For more information on configuring a route in Active Defense, see your HBGary Active
Defense User Guide.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for LEEF formatted syslog events
that are forwarded from Active Defense.
About this task
The following configuration steps are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for the log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select HBGary Active Defense.
9. From the Protocol Configuration list, select Syslog.
© Copyright IBM Corp. 2005, 2018
405
10. Configure the following values:
Table 234. HBGary Active Defense syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for your HBGary Active Defense device.
The IP address or host name identifies your HBGary Active Defense device as a
unique event source in QRadar.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The HBGary Active Defense configuration is complete.
406
QRadar DSM Configuration Guide
67 H3C Technologies
IBM Security QRadar accepts events from a range of H3C Technologies DSMs.
H3C Comware Platform
The IBM Security QRadar DSM for the H3C Comware Platform collects events from a number of network
devices from H3C Technologies. QRadar supports H3C Switches, H3C Routers, H3C Wireless LAN
Devices, and H3C IP Security Devices.
The following table describes the specifications for the H3C Comware Platform DSM:
Table 235. H3C Comware Platform DSM specifications
Specification
Value
Manufacturer
H3C Technologies Co., Limited
DSM name
H3C Comware Platform, H3C Switches, H3C Routers,
H3C Wireless LAN Devices, and H3C IP Security
Devices.
RPM file name
DSM-H3CComware-QRadar_versionbuild_number.noarch.rpm
Supported versions
V7
Protocol
Syslog
Event format
NVP
Recorded event types
System
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
H3C Technologies (http://www.h3c.com)
To integrate H3C Comware Platform, H3C Switches, H3C Routers, H3C Wireless LAN Devices, or H3C
IP Security Devices with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the H3C
Comware Platform DSM RPM on your QRadar Console.
2. Configure your H3C Comware Platform router or device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a H3C Comware Platform log source on
the QRadar Console. The following table describes the parameters that require specific values for H3C
Comware Platform event collection:
Table 236. H3C Comware Platform log source parameters
Parameter
Value
Log Source type
H3C Comware Platform
Protocol Configuration
Syslog
The following table provides a sample syslog event message for the H3C Comware Platform DSM:
© Copyright IBM Corp. 2005, 2018
407
Table 237. H3C Comware Platform sample syslog message
Event name
Low level category
Sample log message
A user's AAA request is rejected
AAA Session Denied
<188>Jun 14 17:11:11 2013
HP %%10AAA/5/AAA_FAILURE:
-AAAType=AUTHOR-AAADomain
=domain1-Service=loginUserName=cwf@system;
AAA is failed.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring H3C Comware Platform to communicate with QRadar
To collect H3C Comware Platform events, enable syslog settings and configure a log host. H3C Switches,
H3C Routers, H3C Wireless LAN Devices, and H3C IP Security Devices are supported by QRadar.
Procedure
1. Log in to the command line interface by using the console port, or by using Telnet or SSH. For more
information about login methods, see the Logging into the CLI section in the configuration guide for
your H3C devices.
2. To access the system view, type the <system_name> system-view command.
3. To enable the syslog settings, type the following commands in the order that they are listed.
a. info-center source default loghost deny
b. info-center source AAA loghost level informational
c. info-center source ACL loghost level informational
d. info-center source FIPS loghost level informational
e. info-center source HTTPD loghost level informational
f. info-center source IKE loghost level informational
g. info-center source IPSEC loghost level informational
h. info-center source LOGIN loghost level informational
i. info-center source LS loghost level informational
j. info-center source PKI loghost level informational
k. info-center source PORTSEC loghost level informational
l. info-center source PWDCTL loghost level informational
m. info-center source RADIUS loghost level informational
n. info-center source SHELL loghost level informational
o. info-center source SNMP loghost level informational
p. info-center source SSHS loghost level informational
q. info-center source TACACS loghost level informational
r. info-center loghost <QRadar Event Collector IP> 514
4. To exit the system view, type the quit <system_name> command.
408
QRadar DSM Configuration Guide
68 Honeycomb Lexicon File Integrity Monitor (FIM)
You can use the Honeycomb Lexicon File Integrity Monitor (FIM) DSM with IBM Security QRadar to
collect detailed file integrity events from your network.
QRadar supports syslog events that are forwarded from Lexicon File Integrity Monitor installations that
use Lexicon mesh v3.1 and later. The syslog events that are forwarded by Lexicon FIM are formatted as
Log Extended Event Format (LEEF) events by the Lexicon mesh service.
To integrate Lexicon FIM events with QRadar, you must complete the following tasks:
1. On your Honeycomb installation, configure the Lexicon mesh service to generate syslog events in
LEEF.
2. On your Honeycomb installation, configure any Lexicon FIM policies for your Honeycomb data
collectors to forward FIM events to your QRadar Console or Event Collector.
3. On your QRadar Console, verify that a Lexicon FIM log source is created and that events are
displayed on the Log Activity tab.
4. Optional. Ensure that no firewall rules block communication between your Honeycomb data collectors
and the QRadar Console or Event Collector that is responsible for receiving events.
Supported Honeycomb FIM event types logged by QRadar
The Honeycomb FIM DSM for IBM Security QRadar can collect events from several event categories.
Each event category contains low-level events that describe the action that is taken within the event
category. For example, file rename events might have a low-level category of either file rename successful
or file rename failed.
The following list defines the event categories that are collected by QRadar for Honeycomb file integrity
events:
v Baseline events
v Open file events
v Create file events
v Rename file events
v Modify file events
v Delete file events
v Move file events
v File attribute change events
v File ownership change events
QRadar can also collect Windows and other log files that are forwarded from Honeycomb Lexicon.
However, any event that is not a file integrity event might require special processing by a Universal DSM
or a log source extension in QRadar.
Configuring the Lexicon mesh service
To collect events in a format that is compatible with IBM Security QRadar, you must configure your
Lexicon mesh service to generate syslog events in LEEF.
© Copyright IBM Corp. 2005, 2018
409
Procedure
1. Log in to the Honeycomb LexCollect system that is configured as the dbContact system in your
network deployment.
2. Locate the Honeycomb installation directory for the installImage directory.
For example, c:\Program Files\Honeycomb\installImage\data.
3. Open the mesh.properties file.
If your deployment does not contain Honeycomb LexCollect, you can edit mesh.properties manually.
For example, c:\Program Files\mesh
4. To export syslog events in LEEF, edit the formatter field.
For example, formatter=leef.
5. Save your changes.
The mesh service is configured to output LEEF events. For information about the Lexicon mesh
service, see your Honeycomb documentation.
Configuring a Honeycomb Lexicon FIM log source in QRadar
IBM Security QRadar automatically discovers and creates a log source for file integrity events that are
forwarded from the Honeycomb Lexicon File Integrity Monitor.
About this task
The following procedure is optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. Optional: In the Log Source Description field, type a description for your log source.
8. From the Log Source Type list, select Honeycomb Lexicon File Integrity Monitor.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 238. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source as an identifier for events from
your Honeycomb Lexicon FIM installation.
The Log Source Identifier must be unique value.
Enabled
Select this check box to enable the log source. By default, the check box is selected.
Credibility
From the list, select the Credibility of the log source. The range is 0 - 10.
The credibility indicates the integrity of an event or offense as determined by the
credibility rating from the source devices. Credibility increases if multiple sources
report the same event. The default is 5.
Target Event Collector
410
From the list, select the Target Event Collector to use as the target for the log
source.
QRadar DSM Configuration Guide
Table 238. Syslog protocol parameters (continued)
Parameter
Description
Coalescing Events
Select this check box to enable the log source to coalesce (bundle) events.
By default, automatically discovered log sources inherit the value of the Coalescing
Events list from the System Settings in QRadar. When you create a log source or
edit an existing configuration, you can override the default value by configuring
this option for each log source.
Incoming Event Payload
From the list, select the incoming payload encoder for parsing and storing the logs.
Store Event Payload
Select this check box to enable the log source to store event payload information.
By default, automatically discovered log sources inherit the value of the Store Event
Payload list from the System Settings in QRadar. When you create a log source or
edit an existing configuration, you can override the default value by configuring
this option for each log source.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
Honeycomb Lexicon File Integrity Monitor events that are forwarded to QRadar are displayed on the
Log Activity tab.
68 Honeycomb Lexicon File Integrity Monitor (FIM)
411
412
QRadar DSM Configuration Guide
69 Hewlett Packard (HP)
IBM Security QRadar can be integrated with several Hewlett Packard (HP) DSMs.
HP Network Automation
The IBM Security QRadar DSM for HP Network Automation collects events from HP Network
Automation software.
The following table describes the specifications for the HP Network Automation DSM:
Table 239. HP Network Automation DSM specifications
Specification
Value
Manufacturer
Hewlett Packard
DSM name
HP Network Automation
RPM file name
DSM-HPNetworkAutomation-QRadar_versionbuild_number.noarch.rpm
Supported versions
V10.11
Protocol
Syslog
Event format
LEEF
Recorded event types
All operational and configuration network events.
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
Hewlett Packard Network Automation
(http://www.hpe.com/software/na)
To integrate HP Network Automation software with QRadar, complete the following steps:
1. If automatic updates are not enabled, download the most recent version of the following RPMs in the
order that they are listed, on your QRadar Console:
v DSMCommon DSM RPM
v HP Network Automation DSM RPM
2. Configure your HP Network Automation software to send LEEF events to QRadar.
3. If QRadar does not automatically detect the log source, add an HP Network Automation log source
on the QRadar Console. The following table describes the parameters that require specific values for
HP Network Automation event collection:
Table 240. HP Network Automation log source parameters
Parameter
Value
Log Source type
HP Network Automation
Protocol Configuration
Syslog
Log Source Identifier
The IP address or host name of the device from where
QRadar collects HP Network Automation events.
The following table shows a sample LEEF message from the HP Network Automation DSM:
© Copyright IBM Corp. 2005, 2018
413
Table 241. HP Network Automation sample message supported by the HP Network Automation software
Event name
Low level category
Sample log message
Device Snapshot
Information
LEEF:1.0|HP|Network
Automation|v10|Device Snapshot|
devTime=Wed Jul 06 08:26:45 UTC
2016 devTimeFormat=EEE
MMM dd HH:mm:ss Z yyyy
src=<Source_IP_address>
eventId=11111111
usrName=UserName
eventText=Snapshot of
configuration taken
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring HP Network Automation Software to communicate with
QRadar
Configure HP Network Automation Software to send LEEF events to IBM Security QRadar.
Before you begin
You must have administrator access to the HP Network Automation Software user interface.
Procedure
1. Log in to the HP Network Automation Software user interface.
2. In the Admin menu, select Event Notification & Response Rules.
3. Click New Event Notification & Respone Rule.
4. Configure the parameters for HP Network Automation.
The following table describes the parameter values to send LEEF events to QRadar:
Parameter
Value
Add Email and Event Rule named
You can use any string. For example, QRadar_logs.
To take this action
Select Send Syslog Message from the list.
When the following events occur
1. Select all of the events.
2. Enable the of any importance button.
3. To take action for For Policy No-Compliance events,
enable the for all policies button.
Rule Status
Enable the Active button.
Syslog Hostname
QRadar host name or IP address.
Syslog Port
514
414
QRadar DSM Configuration Guide
Parameter
Value
Syslog Message
LEEF:1.0|HP|Network
Automation|v10|
$EventType$|devTime=
$EventDate$
devTimeFormat=EE
E MMM dd HH:mm:ss Z
yyyy src=$IPAddress$
eventId=$EventID$
usrName=$EventUserName$
eventText=
$EventText$
Note: All event attributes are tab delimited. For example,
devTime, devTimeFormat, and more. Copy the Syslog
Message value into a text editor, and then verify that the
attributes are tab delimited and remove any new line
characters.
Note: The version number v10 in the LEEF header can
be replaced with the exact version of your HP Network
Automation software. If you change any other
components of the format string, events might not
normalize or unknown events might occur.
5. Click Save.
HP ProCurve
You can integrate an HP ProCurve device with IBM Security QRadar to record all relevant HP Procurve
events using syslog.
About this task
Take the following steps to configure your HP ProCurve device to forward syslog events to QRadar.
Procedure
1. Log into the HP ProCurve device.
2. Type the following command to make global configuration level changes.
config
If successful, the CLI will change to the following prompt:
ProCurve(config)#
3. Type the following command:
logging <syslog-ip-addr>
Where: <syslog-ip-addr> is the IP address of QRadar.
4. To exit config mode, press CTRL+Z.
5. Type the following command: write mem to save the current configuration to the startup configuration
for your HP ProCurve device.
You are now ready to configure the log source in QRadar.
Configuring a log source
IBM Security QRadar automatically discovers and creates a log source for LEEF formatted syslog events
that are forwarded from Active Defense.
69 Hewlett Packard (HP)
415
About this task
These configuration steps are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for the log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select HP ProCurve.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 242. HP ProCurve syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for your HP ProCurve device.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
HP Tandem
You can integrate an HP Tandem device with IBM Security QRadar. An HP Tandem device accepts
SafeGuard Audit file events by using a log file protocol source.
About this task
A log file protocol source allows QRadar to retrieve archived log files from a remote host. The HP
Tandem DSM supports the bulk loading of log files by using the log file protocol source.
When you configure your HP Tandem device to use the log file protocol, ensure that the host name or IP
address that is configured in the HP Tandem device and in the Remote Host parameter are the same.
The SafeGuard Audit file names use the following format:
Annnnnnn
The single alphabet character A is followed by a seven-digit decimal integer nnnnnnn, which increments by
1 each time a name is generated in the same audit pool.
You are now ready to configure the log source and protocol in QRadar.
Procedure
1. From the Log Source Type list, select HP Tandem.
2. To configure the log file protocol, from the Protocol Configuration list, select Log File.
3. From the Event Generator list, select HPTANDEM
416
QRadar DSM Configuration Guide
Note: Your system must be running the current version of the log file protocol to integrate with an
HP Tandem device:
For more information about HP Tandem, see your vendor documentation.
Hewlett Packard UNIX (HP-UX)
You can integrate an HP-UX device with IBM Security QRadar. An HP-UX DSM accepts events by using
syslog.
About this task
You can configure syslog on your HP-UX device to forward events to QRadar.
Procedure
1. Log in to the HP-UX device command-line interface.
2. Open the following file:
/etc/syslog.conf
3. Add the following line:
<facility>.<level><destination>
Where:
v <facility> is auth.
v <level> is info.
v <destination> is the IP address of the QRadar.
4. Save and exit the file.
5. Type the following command to ensure that syslogd enforces the changes to the syslog.conf file.
kill -HUP `cat /var/run/syslog.pid`
Note: Back quotation marks are used in the command line.
You are now ready to configure the log source in QRadar.
Configure a log source
IBM Security QRadar automatically discovers and creates a log source for syslog events forwarded from
HP-UX.
About this task
The following configuration steps are optional:
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for the log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Hewlett Packard UniX.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
69 Hewlett Packard (HP)
417
Table 243. HP-UX syslog parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for your Hewlett Packard UniX device.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The configuration is complete.
418
QRadar DSM Configuration Guide
70 Huawei
IBM Security QRadar can integrate with several Huawei DSMs.
Huawei AR Series Router
The Huawei AR Series Router DSM for IBM Security QRadar can accept events from Huawei AR Series
Routers by using syslog.
QRadar records all relevant IPv4 events that are forwarded from Huawei AR Series Router. To integrate
your device with QRadar, you must create a log source, then configure your AR Series Router to forward
syslog events.
Supported routers
The DSM supports events from the following Huawei AR Series Routers:
v AR150
v AR200
v AR1200
v AR2200
v AR3200
Configuring a log source
IBM Security QRadar does not automatically discover incoming syslog events from Huawei AR Series
Routers.
About this task
If your events are not automatically discovered, you must manually create a log source from the Admin
tab in QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Huawei AR Series Router.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
© Copyright IBM Corp. 2005, 2018
419
Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address, host name, or name for the log source as an identifier for your
Huawei AR Series Router.
Each log source that you create for your Huawei AR Series Router must include a
unique identifier, such as an IP address or host name.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. You are now ready to configure your Huawei AR Series Router
to forward events to QRadar.
Configuring Your Huawei AR Series Router
To forward syslog events to IBM Security QRadar, you must configure your Huawei AR Series Router as
an information center, then configure a log host.
About this task
The log host that you create for your Huawei AR Series Router can forward events to your QRadar
Console or an Event Collector.
Procedure
1. Log in to your Huawei AR Series Router command line Interface (CLI).
2. Type the following command to access the system view:
system-view
3. Type the following command to enable the information center:
info-center enable
4. Type the following command to send informational level log messages to the default channel:
info-center source default channel loghost log level informational debug state off trap
state off
5. Optional: To verify your Huawei AR Series Router source configuration, type the command:
display channel loghost
6. Type the following command to configure the IP address for QRadar as the log host for your switch:
info-center loghost <IP address> facility <local>
Where:
v <IP address> is the IP address of the QRadar Console or Event Collector.
v <local> is the syslog facility, for example, local0.
For example,
info-center loghost <IP_address> facility local0
7. Type the following command to exit the configuration:
quit
The configuration is complete. You can verify events that are forwarded to QRadar by viewing events
on the Log Activity tab.
Huawei S Series Switch
The Huawei S Series Switch DSM for IBM Security QRadar can accept events from Huawei S Series
Switch appliances by using syslog.
420
QRadar DSM Configuration Guide
QRadar records all relevant IPv4 events that are forwarded from Huawei S Series Switches. To integrate
your device with QRadar, you must configure a log source, then configure your S Series Switch to
forward syslog events.
Supported switches
The DSM supports events from the following Huawei S Series Switches:
v S5700
v S7700
v S9700
Configuring a log source
IBM Security QRadar does not automatically discover incoming syslog events from Huawei S Series
Switches.
About this task
If your events are not automatically discovered, you must manually create a log source from the Admin
tab in QRadar.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. On the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. In the Log Source Description field, type a description for the log source.
8. From the Log Source Type list, select Huawei S Series Switch.
9. From the Protocol Configuration list, select Syslog.
10. Configure the following values:
Table 244. Syslog protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address, host name, or name for the log source as an identifier for your
Huawei S Series switch.
Each log source that you create for your Huawei S Series switch must include a
unique identifier, such as an IP address or host name.
11. Click Save.
12. On the Admin tab, click Deploy Changes.
The log source is added to QRadar. You are now ready to configure your Huawei S Series Switch to
forward events to QRadar.
Configuring Your Huawei S Series Switch
To forward syslog events to IBM Security QRadar, you must configure your Huawei S Series Switch as an
information center, then configure a log host.
70 Huawei
421
About this task
The log host that you create for your Huawei S Series Switch can forward events to your QRadar Console
or an Event Collector.
Procedure
1. Log in to your Huawei S Series Switch command line Interface (CLI).
2. Type the following command to access the system view:
system-view
3. Type the following command to enable the information center:
info-center enable
4. Type the following command to send informational level log messages to the default channel:
info-center source default channel loghost log level informational debug state off trap
state off
5. Optional: To verify your Huawei S Series Switch source configuration, type the command:
display channel loghost
6. Type the following command to configure the IP address for QRadar as the log host for your switch:
info-center loghost <IP address> facility <local>
Where:
v <IP address> is the IP address of the QRadar Console or Event Collector.
v <local> is the syslog facility, for example, local0.
For example,
info-center loghost <IP_address> facility local0
7. Type the following command to exit the configuration:
quit
The configuration is complete. You can verify events that are forwarded to QRadar by viewing events
on the Log Activity tab.
422
QRadar DSM Configuration Guide
71 HyTrust CloudControl
The IBM Security QRadar DSM for HyTrust CloudControl collects events from HyTrust CloudControl
devices.
The following table lists the specifications for the HyTrust CloudControl DSM:
Table 245. HyTrust CloudControl DSM specifications
Specification
Value
Manufacturer
Hytrust
DSM name
HyTrust CloudControl
RPM file name
DSM-HyTrustCloudControl-Qradar_versionbuild_number.noarch.rpm
Supported versions
V3.0.2 through V3.6.0
Protocol
Syslog
Recorded event types
All events
Automatically discovered?
Yes
Includes identity?
Yes
Includes custom properties?
No
More information
Hytrust web site (http://www.hytrust.com)
To collect HyTrust CloudControl events, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v DSMCommon RPM
v HyTrust CloudControl DSM RPM
2. Configure your HyTrust CloudControl device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a HyTrust CloudControl log source on the
QRadar Console. The following table describes the parameters that require specific values that are
required for HyTrust CloudControl event collection:
Table 246. HyTrust CloudControl log source parameters
Parameter
Value
Log Source type
HyTrust CloudControl
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring HyTrust CloudControl to communicate with QRadar” on page 424
To collect HyTrust CloudControl events, you must configure your third-party device to send events to
IBM Security QRadar
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
© Copyright IBM Corp. 2005, 2018
423
Configuring HyTrust CloudControl to communicate with QRadar
To collect HyTrust CloudControl events, you must configure your third-party device to send events to
IBM Security QRadar
Procedure
1. Log in to HyTrust CloudControl.
2. From the HTA Management Console, select Configuration > Logging.
3. From the HTA Logging Aggregation options, select External.
4. From the Logging Aggregation Template Type options, select either Proprietary or CEF.
5. In the HTA Syslog Servers field, type the IP address for QRadar.
424
QRadar DSM Configuration Guide
72 IBM
IBM Security QRadar supports a number of IBM DSMs.
IBM AIX
IBM Security QRadar provides the IBM AIX Audit and IBM AIX Server DSMs to collect and parse audit
or operating system events from IBM AIX devices.
IBM AIX Server DSM overview
The IBM AIX Server DSM collects operating system and authentication events using syslog for users that
interact or log in to your IBM AIX appliance.
The following table identifies the specifications for both IBM AIX DSM Server:
Table 247. IBM AIX Server DSM specifications
Specification
Value
Manufacturer
IBM
DSM names
IBM AIX Server
RPM file names
DSM-IBMAIXServer-QRadar_versionbuild_number.noarch.rpm
Supported versions
V5.X, V6.X, and V7.X
Protocol type
Syslog
QRadar recorded event types
Login or logoff events
Session opened or session closed events
Accepted password and failed password events
Operating system events
Automatically discovered?
Yes
Includes identity?
Yes
More information
IBM website (http://www.ibm.com/)
To integrate IBM AIX Server events with QRadar, complete the following steps:
1. If automatic updates are not enabled, download the latest version of the IBM AIX Server DSM.
2. Configure your IBM AIX Server device to send syslog events to QRadar.
3. Configure a syslog-based log source for your IBM AIX Server device. Use the following
protocol-specific parameters:
Parameter
Description
Log Source Type
IBM AIX Server
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
© Copyright IBM Corp. 2005, 2018
425
“Configuring your IBM AIX Server device to send syslog events to QRadar”
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring your IBM AIX Server device to send syslog events to QRadar
Procedure
1. Log in to your IBM AIX appliance as a root user.
2. Open the /etc/syslog.conf file.
3. To forward the system authentication logs to QRadar, add the following line to the file:
auth.info @QRadar_IP_address
A tab must separate auth.info and the IP address of QRadar. For example:
##### begin /etc/syslog.conf
mail.debug /var/adm/maillog
mail.none /var/adm/maillog
auth.notice /var/adm/authlog
lpr.debug /var/adm/lpd-errs
kern.debug /var/adm/messages
*.emerg;*.alert;*.crit;*.warning;*.err;*.notice;*.info /var/adm/messages
auth.info
@<IP_address>
##### end /etc/syslog.conf
4. Save and exit the file.
5. Restart the syslog service:
refresh -s syslogd
IBM AIX Audit DSM overview
The IBM AIX Audit DSM collects detailed audit information for events that occur on your IBM AIX
appliance.
The following table identifies the specifications for the IBM AIX Audit DSM:
Table 248. IBM AIX Audit DSM specifications
Specification
Value
Manufacturer
IBM
DSM names
IBM AIX Audit
RPM file names
DSM-IBMAIXAudit-QRadar_versionbuild_number.noarch.rpm
Supported versions
V6.1 and V7.1
Protocol type
Syslog
Log File Protocol
QRadar recorded event types
Audit events
Automatically discovered?
Yes
Includes identity?
No
More information
IBM website (http://www.ibm.com/)
To integrate IBM AIX Audit events with QRadar, complete the following steps:
1. Download the latest version of the IBM AIX Audit DSM.
426
QRadar DSM Configuration Guide
2. For syslog events, complete the following steps:
a. Configure your IBM AIX Audit device to send syslog events to QRadar. See “Configuring IBM
AIX Audit DSM to send syslog events to QRadar” on page 428.
b. If QRadar does not automatically discover the log source, add an IBM AIX Audit log source. Use
the following IBM AIX Audit-specific values in the log source configuration:
Parameter
Value
Log Source Type
IBM AIX Audit
Protocol Configuration
Syslog
3. For log file protocol events, complete the following steps:
a.
b.
Configure your IBM AIX Audit device to convert audit logs to the log file protocol format.
Configure a log file protocol-based log source for your IBM AIX Audit device. Use the following
protocol-specific values in the log source configuration:
Parameter
Value
Log Source Type
IBM AIX Audit
Protocol Configuration
Log File
Service Type
The protocol to retrieve log files from a remote server.
Important: If you select the SCP and SFTP service type,
ensure that the server that is specified in the Remote IP
or Hostname parameter has the SFTP subsystem
enabled.
Remote Port
If the host for your event files uses a non-standard port
number for FTP, SFTP, or SCP, adjust the port value.
SSH Key File
If you select SCP or SFTP as the Service Type, use this
parameter to define an SSH private key file. When you
provide an SSH Key File, the Remote Password
parameter is ignored.
Remote Directory
The directory location on the remote host where the files
are retrieved. Specify the location relative to the user
account you are using to log in.
Restriction: For FTP only. If your log files are in a
remote user home directory, leave the remote directory
blank to support operating systems where a change in
the working directory (CWD) command is restricted.
FTP File Pattern
The FTP file pattern must match the name that you
assigned to your AIX audit files with the -n parameter
in the audit script. For example, to collect files that start
with AIX_AUDIT and end with your time stamp value,
type AIX_Audit_*.
FTP Transfer Mode
ASCII is required for text event logs that are retrieved by
the log file protocol by using FTP.
Processor
NONE
Change Local Directory?
Leave this check box clear.
Event Generator
LineByLine
The Event Generator applies more processing to the
retrieved event files. Each line of the file is a single
event. For example, if a file has 10 lines of text, 10
separate events are created.
Related tasks:
72 IBM
427
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring IBM AIX Audit DSM to send syslog events to QRadar”
To collect syslog audit events from your IBM AIX Audit device, redirect your audit log output from your
IBM AIX device to the IBM Security QRadar Console or Event Collector.
“Configuring IBM AIX Audit DSM to send log file protocol events to QRadar” on page 429
Configure the audit.pl script to run each time that you want to convert your IBM AIX audit logs to a
readable event log format for QRadar.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring IBM AIX Audit DSM to send syslog events to QRadar
To collect syslog audit events from your IBM AIX Audit device, redirect your audit log output from your
IBM AIX device to the IBM Security QRadar Console or Event Collector.
About this task
On an IBM AIX appliance, you can enable or disable classes in the audit configuration. The IBM AIX
default classes capture a large volume of audit events. To prevent performance issues, you can tune your
IBM AIX appliance to reduce the number of classes that are collected. For more information about audit
classes, see your IBM AIX appliance documentation.
Procedure
1. Log in to your IBM AIX appliance.
2. Open the audit configuration file:
/etc/security/audit/config
3. Edit the Start section to disable the binmode element and enable the streammode element:
binmode = off
streammode = on
4. Edit the Classes section to specify which classes to audit.
5. Save the configuration changes.
6. Open the streamcmds file:
/etc/security/audit/streamcmds
7. Add the following line to the file:
/usr/sbin/auditstream | /usr/sbin/auditselect -m -e "command != logger && command !=
auditstream && command != auditpr && command != auditselect"|auditpr -t0 -h eclrRdi -v |sed
-e :a -e '$!N;s/\n / /;ta' -e 'P;D'| /usr/bin/logger -p local0.debug -r &
8. Save the configuration changes.
9. Edit the syslog configuration file to specify a debug entry and the IP address of the QRadar Console
or Event Collector:
*.debug @ip_address
Tip: A tab must separate *.debug from the IP address.
10. Save the configuration changes.
11. Reload your syslog configuration:
refresh -s syslogd
12. Start the audit script on your IBM AIX appliance:
audit start
428
QRadar DSM Configuration Guide
What to do next
The IBM AIX Audit DSM automatically discovers syslog audit events that are forwarded from IBM AIX
to QRadar and creates a log source. If the events are not automatically discovered, you can manually
configure a log source.
Configuring IBM AIX Audit DSM to send log file protocol events to QRadar
Configure the audit.pl script to run each time that you want to convert your IBM AIX audit logs to a
readable event log format for QRadar.
Before you begin
To use the audit script, you are required to install a version of Perl 5.8 or above on your IBM AIX
appliance
About this task
This procedure requires you to configure two files:
Audit configuration file
The audit configuration file identifies the event classes that are audited and the location of the
event log file on your IBM AIX appliance. The IBM AIX default classes capture many audit
events. To prevent performance issues, you can configure the classes in the audit configuration
file. For more information about configuring audit classes, see your IBM AIX documentation.
Audit script
The audit script uses the audit configuration file to identify which audit logs to read and converts
the binary logs to single-line events that QRadar can read. The log file protocol can then retrieve
the event log from your IBM AIX appliance and import the events to QRadar. The audit script
uses the audit.pr file to convert the binary audit records to event log files QRadar can read.
Run the audit script each time that you want to convert your audit records to readable events.
You can use a cron job to automate this process. for example, you can add 0 * * * * /audit.pl
to allow the audit script to run hourly. For more information, see your system documentation.
Procedure
1. Log in to your IBM AIX appliance.
2. Configure the audit configuration file:
a. Open the audit configuration file:
etc/security/audit/config
b. Edit the Start section to enable the binmode element.
binmode = on
c. In the Start section, edit the configuration to determine which directories contain the binary audit
logs. The default configuration for IBM AIX auditing writes binary logs to the following
directories:
trail = /audit/trail
bin1 = /audit/bin1
bin2 = /audit/bin2
binsize = 10240
cmds = /etc/security/audit/bincmds
In most cases, you do not have to edit the binary file in the bin1 and bin2 directories.
d. In the Classes section, edit the configuration to determine which classes are audited. For
information on configuring classes, see your IBM AIX documentation.
e. Save the configuration changes.
3. Start auditing on your IBM AIX system:
72 IBM
429
audit start
4. Install the audit script:
a. Access the IBM Support website (http://www.ibm.com/support).
b. Download the audit.pl.gz file.
c. Copy the audit script to a folder on your IBM AIX appliance.
d. Extract the file:
tar -zxvf audit.pl.gz
Start the audit script:
e.
./audit.pl
You can add the following parameters to modify the command:
Parameter
Description
-r
Defines the results directory where the audit script writes
event log files for QRadar.
If you do not specify a results directory, the script writes
the events to the following /audit/results/ directory.
The results directory is used in the Remote Directory
parameter in the log source configuration uses this value.
To prevent errors, verify that the results directory exists
on your IBM AIX system.
-n
Defines a unique name for the event log file that is
generated by audit script. The FTP File Pattern
parameter in the log source configuration uses this name
to identify the event logs that the log source must
retrieve in QRadar
-l
Defines the name of the last record file.
-m
Defines the maximum number of audit files to retain on
your IBM AIX system. By default, the script retains 30
audit files. When the number of audit files exceeds the
value of the -m parameter, the script deletes the audit file
with the oldest time stamp.
-t
Defines the directory that contains the audit trail file. The
default directory is /audit/trail.
What to do next
The IBM AIX Audit DSM automatically discovers log file protocol audit events that are forwarded from
IBM AIX to QRadar and creates a log source. If the events are not automatically discovered, you can
manually configure a log source.
IBM i
The IBM Security QRadar DSM for IBM i, formerly known as AS/400 iSeries, collects audit records and
event information from IBM i systems.
The following table identifies the specifications for the IBM i DSM:
Table 249. IBM i DSM specifications
Specification
Value
Manufacturer
IBM
DSM name
IBM i
430
QRadar DSM Configuration Guide
Table 249. IBM i DSM specifications (continued)
Specification
Value
Supported versions
V5R4 and later
RPM file name
DSM-IBMi-Qradar_version-build_number.noarch.rpm
Protocol
Log File Protocol
Syslog
Recorded event types
Audit records and events
Automatically discovered?
No
Includes identity?
Yes
Includes custom properties?
No
More information
IBM website (http://www.ibm.com/)
To collect events from IBM i systems, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the IBM i DSM
RPM on your QRadar Console.
2. Configure your IBM i system to communicate with QRadar.
3. Add an IBM i log source on the QRadar Console by using the following table to configure the
parameters that are required to collect IBM i events:
Table 250. IBM i log source parameters
Parameter
Value
Log Source Type
IBM i
Protocol Configuration
Log File
If you are using the PowerTech Interact or LogAgent for
System i® software to collect CEF formatted syslog
messages, you must select the Syslog option
Service Type
Secure File Transfer Protocol (SFTP)
Related tasks:
“Configuring IBM i to integrate with IBM Security QRadar”
You can integrate IBM i with IBM Security QRadar.
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
“Configuring Townsend Security Alliance LogAgent to integrate with QRadar” on page 435
You can collect all audit logs and system events from Townsend Security Alliance LogAgent. You must
configure Alliance LogAgent for the IBM Security QRadar LEEF and configure a destination that specifies
QRadar as the syslog server.
Configuring IBM i to integrate with IBM Security QRadar
You can integrate IBM i with IBM Security QRadar.
Procedure
1. From IBM Fix Central (http://www.ibm.com/support/fixcentral), download the following file:
AJLIB.SAVF
72 IBM
431
2. Copy the AJLIB.SAVF file to a computer or terminal that has FTP access to IBM i.
3. Create a generic online SAVF file on the IBM i by typing the following command:
CRTSAVF QGPL/SAVF
4. Use FTP on the computer or terminal to replace the IBM i generic SAVF file with the AJLIB.SAVF file
that you downloaded.
Type the following commands:
bin
cd qgpl
lcd c:\
put ajlib.savf savf
quit
If you are transferring your SAVF file from another IBM i system, send the file by placing the FTP
sub-command mode BINARY before the GET or PUT statement.
5. Restore the AJLIB file on IBM i by typing the following command:
RSTLIB SAVLIB(AJLIB) DEV(*SAVF) SAVF(QGPL/AJLIB)
AJLIB provides the mapping and data transfer support that is needed to send IBM i audit journal
entries to QRadar.
6. Run AJLIB/SETUP
The setup screen is used to configure AJLIB for FTP, SFTP, or a local path to receive the processed
entries.
The server user ID is required for FTP or SFTP, and a password is required for FTP. While FTP
handles line delimiter conversions, you set the line feed to the expected value for the type of system
that receives the SFTP transfers.
7. If you want to use SFTP, run AJLIB/GENKEY.
This command generates the SSH key pair that is required for SFTP authentication. If the key pair
exists, it is not replaced. If you want to generate a new key pair, before you run this command,
remove the existing key files from the /ajlib/.ssh directory.
For more information about SSH key pair configuration on the IBM i , see http://www-01.ibm.com/
support/docview.wss?uid=nas8N1012710
8. After you generate a key pair, use the following steps to enable the use of the key pair on the server:
a. Copy the id_rsa.pub file from the /ajlib directory to the SSH server, and then install it in the
appropriate folder.
b. Ensure that the SSH server is added to the known_hosts file of the user profile that runs the
AJLIB/AUDITJRN command.
9. Use the appropriate user profile to do the following steps:
a. Start a PASE (Portable Application Solutions Environment) shell by typing the following
command:
call qp2term
b. Start a session with the SSH server by typing the following command:
ssh -T <user>@<serveraddress>
c. If prompted, accept the system key, and enter a password.
d. Type exit, to close the SSH session.
If you want to run these steps under a different IBM i profile than the one that runs the
AJLIB/AUDITRN command, copy the .ssh directory and known_hosts file to the home directory of
the profile that is used to run this command.
10. To configure the filtering of specific entry types, use the AJLIB/SETENTTYP command.
11. Set up the data collection start date and time for the audit journal library (AJLIB) by typing the
following command:
432
QRadar DSM Configuration Guide
AJLIB/DATETIME
If you start the audit journal collector, a failure message is sent to QSYSOPR.
The setup function sets a default start date and time for data collection from the audit journal to
08:00:00 of the current day.
To preserve your previous start date and time information from a previous installation, you must run
AJLIB/DATETIME. Record the previous start date and time and type those values when you run
AJLIB/SETUP. The start date and time must contain a valid date and time in the six character
system date and system time format. The end date and time must be a valid date and time or left
blank.
12. Run AJLIB/AUDITJRN.
The audit journal collection program starts and sends the records to your remote FTP server: If the
transfer to the FTP server fails, a message is sent to QSYSOPR. The process for starting
AJLIB/AUDITJRN is typically automated by an IBM i job Scheduler, which collects records
periodically.
If the FTP transfer is successful, the current date and time information is written into the start time
for AJLIB/DATETIME to update the gather time, and the end time is set to blank. If the FTP transfer
fails, the export file is erased and no updates are made to the gather date or time.
Manually extracting journal entries for IBM i
You can run the DSPJRN command to extract journal entries for IBM i when an audit journal receiver
chain is broken.
About this task
Run the ALJIB/DATETIME command to set the Start Date to *OUTF. This command forces the processing
program to use the pre-built QTEMP/AUDITJRN outfile for parsing, instead of using the date time to
extract journal entries. After you run the parsing program command AJLIB/AUDITJRN, the DATETIME
is set to the new processing date.
Procedure
1. Log in to your IBM i system command-line interface (CLI).
2. Run DSPJRN.
The only changeable parameters in the following example are RCVRNG and ENTTYP. Do not change any
other command parameters. Ensure that ENTTP matches the AJLIB/SETENTTYP command settings.
DSPJRN JRN(QSYS/QAUDJRN) RCVRNG(AUDRCV0001 AUDRCV0003)
JRNCDE((T)) ENTTYP(*ALL)
OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) OUTFILE(QTEMP/AUDITJRN)
ENTDTALEN(*VARLEN 16000 100)
3. To set the Date Time to use outfile *OUTF support, run the AJLIB/DATETIME command.
72 IBM
433
Figure 7. DSPJRN Start and End Times
4. Run AJLIB/AUDITJRN.
Results
The DATETIME is set to the next start date.
Pulling Data Using Log File Protocol
You can configure IBM i as the log source, and to use the log file protocol in IBM Security QRadar:
Procedure
1. To configure QRadar to receive events from an IBM i system, you must select the IBM i option from
the Log Source Type list.
2. To configure the log file protocol for the IBM i DSM, you must select the Log File option from the
Protocol Configuration list and define the location of your FTP server connection settings.
Note: If you are using the PowerTech Interact or LogAgent for System i software to collect CEF
formatted syslog messages, you must select the Syslog option from the Protocol Configuration list.
3. Use the log file protocol option that you select a secure protocol for transferring files, such as Secure
File Transfer Protocol (SFTP).
434
QRadar DSM Configuration Guide
Configuring Townsend Security Alliance LogAgent to integrate with
QRadar
You can collect all audit logs and system events from Townsend Security Alliance LogAgent. You must
configure Alliance LogAgent for the IBM Security QRadar LEEF and configure a destination that specifies
QRadar as the syslog server.
Procedure
1. Log in to your Townsend Security Alliance LogAgent appliance.
2. Add the ALLSYL100 to your library list by typing the following command:: addlible allsy1100.
3. To display the main menu select go symain.
4. Select the option for Configuration
5. Select Configure Alliance LogAgent and configure the following parameters.
Parameter
Description
Interface version
4=IBM QRadar LEEF
Transmit
1=Yes
Data queue control
1=Yes
Format
4=IBM QRadar LEEF
6. From the configuration menu, select Work With TCP Clients.
7. Select option 2 to change the SYSLOGD client and configure the following parameters.
Parameter
Description
Status
1=Active
Autostart client
1=Yes
Remote IP address
IP address of QRadar
Remote port number
514
8. From the Configuration menu, select Start LogAgent Subsystem. Events flow to QRadar.
What to do next
After TCP services start, consider automatically starting the Alliance LogAgent subsystem by modifying
your IPL QSTRUP program to include the following statements:
/* START ALLIANCE LOGAGENT */
QSYS/STRSBS ALLSYL100/ALLSYL100
MONMSG MSGID(CPF0000)
For more information about installing and configuring for Independent Auxiliary Storage Pool
operation, and more filter options for events, see your vendor documentation.
IBM BigFix
The IBM BigFix DSM for IBM Security QRadar accepts system events in Log Extended Event Format
(LEEF) retrieved from IBM BigFix.
IBM BigFix is formerly known as IBM Tivoli® Endpoiont Manager.
QRadar uses the IBM BigFix SOAP protocol to retrieve events on a 30-second interval. As events are
retrieved, the IBM BigFix DSM parses and categorizes the events for QRadar. The SOAP API for IBM
72 IBM
435
BigFix is only available after you install the Web Reports application. The Web Reports application for
IBM BigFix is required to retrieve and integrate IBM BigFix system event data with QRadar.
Note: QRadar supports IBM BigFix versions 8.2.x to 9.5.2.
To integrate IBM BigFix with QRadar, you must manually configure a log source. Events from IBM BigFix
are not automatically discovered.
v Log in to QRadar.
v Click the Admin tab.
v Click the Log Sources icon.
v Click Add.
v In the Log Source Name field, type a name for the log source.
v In the Log Source Description field, type a description for the log source.
v From the Log Source Type list, select BigFix.
v From the Protocol Configuration list, select BigFix SOAP.
Configure the following values:
IBM BigFix SOAP protocol configuration
Parameter
Description
Log Source Identifier
Type the IP address or host name for your IBM BigFix appliance.
The IP address or host name identifies your IBM BigFix as a unique event source in
QRadar.
Type the port number that is used to connect to the IBM BigFix by using the SOAP
API.
Port
By default, port 80 is the port number for communicating with IBM BigFix. If you
are use HTTPS, you must update this field to the HTTPS port number for your
network. Most configurations use port 443 for HTTPS communications.
Use HTTPS
Select this check box to connect by using HTTPS.
If you select this check box, the host name or IP address you specify uses HTTPS to
connect to your IBM BigFix. If a certificate is required to connect by using HTTPS,
you must copy any certificates that are required by the QRadar Console or
managed host to the following directory:
/opt/qradar/conf/trusted_certificates
QRadar support certificates with the following file extensions: .crt, cert, or .der.
Copy any required certificates to the trusted certificates directory before you save
and deploy your changes.
Username
Type the user name that is required to access your IBM BigFix.
Password
Type the password that is required to access your IBM BigFix.
Confirm Password
Confirm the password necessary to access your IBM BigFix.
For more information about configuring QRadar to import IBM BigFix vulnerabilities assessment
information, see the IBM Security QRadar Vulnerability Assessment Guide.
Click Save.
On the Admin tab, click Deploy Changes.
436
QRadar DSM Configuration Guide
Related concepts:
“IBM BigFix SOAP protocol configuration options” on page 16
To receive Log Extended Event Format (LEEF) formatted events from IBM BigFix appliances, configure a
log source that uses the IBM BigFix SOAP protocol.
IBM BigFix Detect
The IBM Security QRadar DSM for IBM BigFix Detect collects events from the IBM BigFix Detect
platform.
The following table describes the specifications for the IBM BigFix Detect DSM:
Table 251. IBM BigFix Detect DSM specifications
Specification
Value
Manufacturer
IBM
DSM name
IBM BigFix Detect
RPM file name
DSM-IBMBigFixDetect-QRadar_versionbuild_number.noarch.rpm
Supported versions
V9.5
Protocol
IBM BigFix EDR REST API Protocol
Event format
LEEF
Recorded event types
IOC and IOA alerts
Automatically discovered?
No
Includes identity?
No
Includes custom properties?
No
More information
IBM BigFix website (http://www-03.ibm.com/security/
bigfix/index.html)
To integrate IBM BigFix Detect with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v Protocol Common RPM
v IBM BigFix EDR REST API Protocol RPM
v DSM Common RPM
v IBM BigFix Detect DSM RPM
2. Configure your IBM BigFix Detect for API access.
3. Add an IBM BigFix Detect log source on the QRadar Console. The following table describes the
parameters that require specific values to collect event from IBM BigFix Detect:
Table 252. IBM BigFix Detect log source parameters
Parameter
Value
Log Source type
IBM BigFix Detect
Protocol Configuration
IBM BigFix EDR REST API
API Hostname or IP
The host name or IP address of the BigFix EDR API
API Port
The port number that is used to access the API.
The default is 443.
72 IBM
437
Table 252. IBM BigFix Detect log source parameters (continued)
Parameter
Value
Client Certificate Filename
The PKCS12 certificate file name in the
/opt/qradar/conf/trusted_certificates/ibmbigfixedr
directory in QRadar.
Client Certificate Password
The password that you used for the Client Certificate.
Use Proxy
If QRadar accesses the BigFix EDR API by using a proxy,
enable Use Proxy.
If the proxy requires authentication, configure the Proxy
Server, Proxy Port, Proxy Username, and Proxy
Password fields.
If the proxy does not require authentication, configure
the Proxy Server and Proxy Port fields.
Automatically Acquire Server Certificate(s)
Select Yes for QRadar to automatically download the
server certificate and begin trusting the target server.
EPS Throttle
The maximum number of events per second.
The default is 5000.
4. To verify that QRadar is configured correctly, review the following table to see an example of a
normalized event message.
The following table shows a sample LEEF event message from IBM BigFix Detect:
Table 253. IBM BigFix Detect sample LEEF message
Event name
Low level category
Sample log message
IOC Detected
Suspicious Activity
LEEF:1.0|IBM|IBM BigFix Detect
|BF-Detect.9.5|blue.static|alert_id
=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
xx event_id=xxxxxxxxxxx
ak=00000000000000000000000000000000
0962AA560FD9E45E5270557BB9DA801E
resource=12587632 bf_
endpoint_name=xxxxxxxxxxxx det
ected_ioc=urn:xxx.xxx.example.com:origi
n.bigfixqaedr//example:Indicator-xxx
xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
/ver/1 devTime=Feb 09 2017 06:
11:32.000 UTC detection_descri
ption=IOC 00_jw-mo_File name and pa
th detected. detection_mechani
sm=blue.static risk=medium
sev=5 confidence=low
devTimeFormat=MMM dd yyyy HH:
mm:ss.SSS z
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring IBM BigFix Detect to communicate with QRadar
To configure IBM Security QRadar to collect IOC and IOA alerts from an IBM BigFix Detect system, you
must obtain information that is required for the configuration from your IBM BigFix administrator.
438
QRadar DSM Configuration Guide
Before you begin
Before you can configure QRadar to receive alerts from IBM BigFix Detect, you must contact your IBM
BigFix Administrator and obtain the following information:
v Hostname or IP address
v Port number
v Private key and corresponding certificate, and Trusteer® CA certificate
For more information about the information that is required for sending alerts from BigFix Detect, see the
IBM BigFix documentation (https://www.ibm.com/support/knowledgecenter/SSMNRU_9.5.0/
com.ibm.bigfix.detect.doc/BigFixDetectionandResponse/EDRBigFixAdministratorGuide/
EDR_alerts_QRadar.html).
Procedure
1. Generate the pkcs12 formatted client keystore.
a. Log in to QRadar using SSH.
b. Type the following command:
openssl pkcs12 -inkey <private_key_filename> -in <certificate_filename> -export -out
<PKCS#12_filename>
The parameters are described in the following table:
Parameter
Description
private_key_filename
The Private key that you obtained from the BigFix
administrator.
certificate_filename
The corresponding certificate that you obtained from the
BigFix administrator.
PKCS#12_filename
The output keystore file name. For example,
bigfix_client_certificate.pkcs12
Note: Record the password that you created when you generated the pkcs12 client keystore. The
password is required when you configure the log source.
2. Store the keystore and CA certificate in QRadar.
a. Copy the Trusteer CA certificate in the /opt/qradar/conf/trusted_certificates/ directory in
QRadar.
b. Create a directory named ibmbigfixedr in the /opt/qradar/conf/trusted_certificates/ directory.
c. Copy the keystore.pkcs12 file to the /opt/qradar/conf/trusted_certificates/ibmbigfixedr/
directory that you created. Do not store the client keystore file in any other location.
What to do next
Configure the log source in QRadar by using only the file name of the client keystore file in the
/opt/qradar/conf/trusted_certificates/ibmbigfixedr/ directory. Ensure that you type the file name
correctly in the Client Certificate Filename field. Type the password that you created when you
generated the pkcs12 client keystore, in the Client Certificate Password field.
72 IBM
439
IBM Bluemix Platform
The IBM Security QRadar DSM for the IBM Bluemix Platform collects events logs from your Bluemix
Platform.
The following table identifies the specifications for the Bluemix Platform DSM:
Table 254. Bluemix Platform DSM specifications
Specification
Value
Manufacturer
IBM
DSM name
Bluemix Platform
RPM file name
DSM-IBMBluemixPlatform-7.x-xxxxxxx.noarch.rpm
Supported versions
N/A
Protocol
Syslog, TLS Syslog
Recorded event types
All System (Cloud Foundry) events, some application
events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
IBM website for Bluemix (IBM website for Bluemix)
To integrate Bluemix Platform with QRadar, complete the following steps:
You must perform the installation, third-party configuration, and QRadar configuration procedures in the
order. Installation must always be first, but you can invert the order of the other two procedures, In some
cases, no action is required for the third-party configuration and you can omit the procedure.
1. If automatic updates are not enabled, download and install the most recent version of the Bluemix
Platform DSM RPM on your QRadar Console:
2. Configure your Bluemix Platform device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add a Bluemix Platform log source on the
QRadar Console.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring Bluemix Platform to communicate with QRadar
To collect Bluemix Platform events, you must configure your third-party instance to send events to
QRadar.
Before you begin
You must have an app running in Bluemix so that you can create log drains.
Procedure
1. From the Cloud Foundry command-line interface, type the following command to create a drain:
cf cups drain_name -l syslog://QRadar_IP_Address:514
440
QRadar DSM Configuration Guide
Alteratively, use the following command:
cf cups drain_name -l syslog-tls://QRadar_IP_Address:1513
1513 is the port that is used to communicate with QRadar.
2. Bind the service instance with the following command:
cf bind-service BusinessApp_name drain_name
Integrating Bluemix Platform with QRadar
In most installations, there is only the RPM. For installations where there are multiple RPMs required,
(for example a PROTOCOL RPM and a DSMCommon RPM), ensure that the installation sequence reflects
RPM dependency.
Procedure
1. If required, download and install the latest TLS Syslog RPM on your QRadar Console. You can install
a protocol by using the procedure to manually install a DSM. If automatic updates are configured to
install protocol updates, this procedure is not necessary.
2. Download and install the latest DSMCommon RPM on your QRadar Console. If automatic updates
are configured to install DSM updates, this procedure is not necessary.
3. Download and install the latest Bluemix Platform RPM on your QRadar Console. If automatic updates
are configured to install DSM updates, this procedure is not necessary.
What to do next
You must configure a Bluemix log source in QRadar by using Syslog or Syslog TLS.
Configuring a Bluemix log source to use Syslog
You can configure a Bluemix log source in IBM Security QRadar.
Procedure
1. Log in to QRadar to use Syslog.
2. On the Admin tab, click Data Sources > Log Sources > Add.
3. From the Log Source Type list, select Bluemix Platform.
4. From the Protocol Configuration list, select Syslog.
5. In the Log Source Identifier field, enter the IP address of the Bluemix Loggregator.
Important: It might be necessary to include the IP address and the port, as the Log Source Identifier.
For example, 192.0.2.1:1234.
6. Configure the remaining fields in the Log Sources window as required and click Save.
7. On the Admin tab toolbar, click Deploy Changes.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring a Bluemix log source with TLS Syslog
You can configure a Bluemix log source in IBM Security QRadar to use TLS Syslog.
Procedure
1. Log in to QRadar.
2. On the Admin tab, click Data Sources > Log Sources > Add.
72 IBM
441
3. From the Log Source Type list, select Bluemix Platform.
4. From the Protocol Configuration list, select TLS Syslog.
5. In the Log Source Identifier field, enter the IP address of the Bluemix Loggregator.
6. In the TLS Listen Port field, enter a port number.
7. From the Authentication Mode list, select TLS .
8. From the Certificate Type list, select Provide Certificate.
9. In the Provided Server Certificate Path field, enter the absolute path to the server certificate, for
example:
syslog-tls.cert
10. In the Provided Private Key Path field, enter the absolute path the private key.
The private key must be a DER-encoded PKCS8 key.
11. Configure the remaining fields in the Log Sources window as required and click Save.
12. On the Admin tab toolbar, click Deploy Changes.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
IBM CICS
The IBM CICS DSM collects events from IBM Custom Information Control System (CICS®) on an IBM
z/OS® mainframe that uses IBM Security zSecure.
When you use a zSecure process, events from the System Management Facilities (SMF) can be
transformed into Log Event Extended Format (LEEF) events. These events can be sent near real-time by
using UNIX Syslog protocol or IBM Security QRadar can retrieve the LEEF event log files by using the
Log File protocol and then process the events. When you use the Log File protocol, you can schedule
QRadar to retrieve events on a polling interval, which enables QRadar to retrieve the events on the
schedule that you define.
To collect IBM CICS events, complete the following steps:
1. Verify that your installation meets any prerequisite installation requirements. For more information
about prerequisite requirements, see the IBM Security zSecure Suite 2.2.1 Prerequisites
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/prereqs_qradar.html) .
2. Configure your IBM z/OS image to write events in LEEF format. For more information, see the IBM
Security zSecure Suite: CARLa-Driven Components Installation and Deployment Guide
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/setup_data_prep_qradar.html).
3. Create a log source in QRadar for IBM CICS.
4. If you want to create a custom event property for IBM CICS in QRadar, for more information, see the
IBM Security Custom Event Properties for IBM z/OS technical note (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf).
Before you begin
Before you can configure the data collection process, you must complete the basic zSecure installation
process and complete the post-installation activities to create and modify the configuration.
442
QRadar DSM Configuration Guide
The following prerequisites are required:
v You must ensure parmlib member IFAPRDxx is enabled for IBM Security zSecure Audit on your z/OS
image.
v The SCKRLOAD library must be APF-authorized.
v If you are using the direct SMF INMEM real-time interface, you must have the necessary software
installed (APAR OA49263) and set up the SMFPRMxx member to include the INMEM keyword and
parameters. If you decide to use the CDP interface, you must also have CDP installed and running. For
more information, see the IBM Security zSecure Suite 2.2.1: Procedure for near real-time
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/smf_proc_real_time_qradar.html)
v You must configure a process to periodically refresh your CKFREEZE and UNLOAD data sets.
v If you are using the Log File protocol method, you must configure a SFTP, FTP, or SCP server on your
z/OS image for QRadar to download your LEEF event files.
v If you are using the Log File protocol method, you must allow SFTP, FTP, or SCP traffic on firewalls
that are located between QRadar and your z/OS image.
For instructions on installing and configuring zSecure, see the IBM Security zSecure Suite: CARLa-Driven
Components Installation and Deployment Guide (http://www-01.ibm.com/support/
docview.wss?uid=pub1sc27277200).
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Create a log source for near real-time event feed
The Syslog protocol enables IBM Security QRadar to receive System Management Facilities (SMF) events
in near real-time from a remote host.
The following DSMs are supported:
v IBM z/OS
v IBM CICS
v IBM RACF
v IBM DB2
v CA Top Secret
v CA ACF2
If QRadar does not automatically detect the log source, add a log source for your DSM on the QRadar
console.
The following table describes the parameters that require specific values for event collection for your
DSM:
Table 255. Log source parameters
Parameter
Value
Log Source type
Select your DSM name from the list.
Protocol Configuration
Syslog
Log Source Identifier
Type a unique identifier for the log source.
72 IBM
443
Creating a log source for Log File protocol
The Log File protocol enables IBM Security QRadar to retrieve archived log files from a remote host for
the IBM z/OS, IBM CICS, IBM RACF, IBM DB2, CA Top Secret, and CA ACF2 DSM's.
About this task
Log files are transferred, one at a time, to QRadar for processing. The Log File protocol can manage plain
text event logs, compressed files, or archives. Archives must contain plain-text files that can be processed
one line at a time. Multi-line event logs are not supported by the Log File protocol. IBM z/OS with
zSecure writes log files to a specified directory as gzip archives. QRadar extracts the archive and
processes the events, which are written as one event per line in the file.
To retrieve these events, you must create a log source that uses the Log File protocol. QRadar requires
credentials to log in to the system that hosts your LEEF formatted event files and a polling interval.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for the log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select your DSM name.
8. From the Protocol Configuration list, select Log File.
9. Configure the Log File protocol parameters.
The following table describes the parameters that require specific values for the DSM event
collection:
Table 256. Log File protocol parameters
Parameter
Value
Log Source Identifier
Type an IP address, host name, or name to identify the event source. IP addresses
or host names are suggested as they allow QRadar to identify a log file to a unique
event source.
For example, if your network contains multiple devices, such as multiple z/OS
images or a file repository that contains all of your event logs, you must specify a
name, IP address, or host name for the image or location that uniquely identifies
events for the DSM log source. This specification enables events to be identified at
the image or location level in your network that your users can identify.
Service Type
From the Service Type list, select the protocol that you want to use when retrieving
log files from a remote server. The default is SFTP.
v SFTP - SSH File Transfer Protocol
v FTP - File Transfer Protocol
v SCP - Secure Copy
The underlying protocol that is used to retrieve log files for the SCP and SFTP
service type requires that the server that is specified in the Remote IP or Hostname
field has the SFTP subsystem enabled.
Remote IP or Hostname
444
Type the IP address or host name of the device that stores your event log files.
QRadar DSM Configuration Guide
Table 256. Log File protocol parameters (continued)
Parameter
Value
Remote Port
Type the TCP port on the remote host that is running the selected Service Type.
The valid range is 1 - 65535.
The options include ports:
v FTP - TCP Port 21
v SFTP - TCP Port 22
v SCP - TCP Port 22
If the host for your event files is using a non-standard port number for FTP, SFTP,
or SCP, you must adjust the port value.
Remote User
Type the user name or user ID necessary to log in to the system that contains your
event files.
v If your log files are on your IBM z/OS image, type the user ID necessary to log
in to your IBM z/OS. The user ID can be up to 8 characters in length.
v If your log files are on a file repository, type the user name necessary to log in to
the file repository. The user name can be up to 255 characters in length.
Remote Password
Type the password necessary to log in to the host.
Confirm Password
Confirm the password necessary to log in to the host.
SSH Key File
If you select SCP or SFTP as the Service Type, this parameter gives you the option
to define an SSH private key file. When you provide an SSH Key File, the Remote
Password field is ignored.
Remote Directory
Type the directory location on the remote host from which the files are retrieved,
relative to the user account you are using to log in.
Recursive
If you want the file pattern to search sub folders in the remote directory, select this
check box. By default, the check box is clear.
If you configure SCP as the Service Type, the Recursive option is ignored.
FTP File Pattern
If you select SFTP or FTP as the Service Type, you can configure the regular
expression (regex) needed to filter the list of files that are specified in the Remote
Directory. All matching files are included in the processing.
The IBM z/OS mainframe that uses IBM Security zSecure Audit writes event files
by using the pattern: <product_name>.<timestamp>.gz
The FTP file pattern that you specify must match the name that you assigned to
your event files. For example, to collect files that start with zOS and end with .gz,
type the following code:
zOS.*\.gz
Use of this parameter requires knowledge of regular expressions (regex). For more
information about regex, see Lesson: Regular Expressions. (http://
download.oracle.com/javase/tutorial/essential/regex/)
FTP Transfer Mode
This option displays only if you select FTP as the Service Type. From the list, select
Binary.
The binary transfer mode is needed for event files that are stored in a binary or
compressed format, such as zip, gzip, tar, or tar+gzip archive files.
SCP Remote File
If you select SCP as the Service Type you must type the file name of the remote
file.
72 IBM
445
Table 256. Log File protocol parameters (continued)
Parameter
Value
Start Time
Type the time of day you want the processing to begin. For example, type 00:00 to
schedule the Log File protocol to collect event files at midnight.
This parameter functions with the Recurrence value to establish when and how
often the Remote Directory is scanned for files. Type the start time, based on a
24-hour clock, in the following format: HH: MM.
Recurrence
Type the frequency, beginning at the Start Time, that you want the remote directory
to be scanned. Type this value in hours (H), minutes (M), or days (D).
For example, type 2H if you want the remote directory to be scanned every 2 hours
from the start time. The default is 1H.
Run On Save
If you want the Log File protocol to run immediately after you click Save, select
this check box.
After the Run On Save completes, the Log File protocol follows your configured
start time and recurrence schedule.
Selecting Run On Save clears the list of previously processed files for the Ignore
Previously Processed File parameter.
EPS Throttle
Type the number of Events Per Second (EPS) that you do not want this protocol to
exceed. The valid range is 100 - 5000.
Processor
From the list, select gzip.
Processors enable event file archives to be expanded and contents are processed for
events. Files are processed after they are downloaded to QRadar. QRadar can
process files in zip, gzip, tar, or tar+gzip archive format.
Ignore Previously Processed
File(s)
Select this check box to track and ignore files that are already processed by the Log
File protocol.
QRadar examines the log files in the remote directory to determine whether a file is
previously processed by the Log File protocol. If a previously processed file is
detected, the Log File protocol does not download the file for processing. All files
that are not previously processed are downloaded.
This option applies only to FTP and SFTP service types.
Change Local Directory?
Select this check box to define a local directory on your QRadar for storing
downloaded files during processing.
It is suggested that you leave this check box clear. When this check box is selected,
the Local Directory field is displayed, which gives you the option to configure the
local directory to use for storing files.
Event Generator
From the Event Generator list, select LineByLine.
The Event Generator applies more processing to the retrieved event files. Each line
is a single event. For example, if a file has 10 lines of text, 10 separate events are
created.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
The DSM configuration is complete. If your DSM requires custom event properties, see the IBM
Security Custom Event Properties for IBM z/OS technical note. (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf)
446
QRadar DSM Configuration Guide
IBM DataPower
The IBM Security QRadar DSM collects event logs from your IBM DataPower® system.
IBM DataPower is formerly known as IBM WebSphere® DataPower.
The following table identifies the specifications for the IBM DataPower DSM.
Table 257. IBM DataPower DSM specifications
Specification
Value
Manufacturer
IBM
DSM Name
DataPower
RPM file name
DSM-IBMDataPower-QRadar_versionbuild_number.noarch.rpm
Supported versions
FirmwareV6 and V7
Protocol
Syslog
QRadar recorded event types
All Events
Log source type in QRadar UI
IBM DataPower
Auto discovered?
Yes
Includes identity?
No
Includes custom properties?
No
For more information
IBM web page (http://www.ibm.com/)
To send events from IBM DataPower to QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the IBM
DataPower DSM on your QRadar Console.
2. For each instance of IBM DataPower, configure the IBM DataPower system to communicate with
QRadar.
3. If QRadar does not automatically discover IBM DataPower, create a log source for each instance of
IBM DataPower on the QRadar Console. Use the following IBM DataPower specific values:
Parameter
Value
Log Source Type
IBM DataPower
Protocol Configuration
Syslog
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring IBM DataPower to communicate with QRadar”
To collect IBM DataPower events, configure your third-party system to send events to IBM Security
QRadar.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring IBM DataPower to communicate with QRadar
To collect IBM DataPower events, configure your third-party system to send events to IBM Security
QRadar.
72 IBM
447
Before you begin
Review the DataPower logging documents to determine which logging configuration changes are
appropriate for your deployment. See IBM Knowledge Center (http://www-01.ibm.com/support/
knowledgecenter/SS9H2Y_7.0.0/com.ibm.dp.xi.doc/logtarget_logs.html?lang=en).
Procedure
1. Log in to your IBM DataPower system.
2. In the search box on the left navigation menu, type Log Target.
3. Select the matching result.
4. Click Add.
5. In the Main tab, type a name for the log target.
6. From the Target Type list, select syslog.
7. In the Local Identifier field, type an identifier to be displayed in the Syslog event payloads
parameter on the QRadar user interface.
8. In the Remote Host field, type the IP address or host name of your QRadar Console or Event
Collector.
9. In the Remote Port field, type 514.
10. Under Event Subscriptions, add a base logging configuration with the following parameters:
Parameter
Value
Event Category
all
Minimum Event Priority
warning
Important: To prevent a decrease in system performance,
do not use more than one word for the Minimum Event
Priority parameter.
11. Apply the changes to the log target.
12. Review and save the configuration changes.
IBM DB2
The IBM DB2 DSM collects events from an IBM DB2 mainframe that uses IBM Security zSecure.
When you use a zSecure process, events from the System Management Facilities (SMF) can be
transformed into Log Event Extended Format (LEEF) events. These events can be sent near real-time by
using UNIX Syslog protocol or IBM Security QRadar can retrieve the LEEF event log files by using the
Log File protocol and then process the events. When you use the Log File protocol, you can schedule
QRadar to retrieve events on a polling interval, which enables QRadar to retrieve the events on the
schedule that you define.
To collect IBM DB2 events, complete the following steps:
1. Verify that your installation meets any prerequisite installation requirements. For more information
about prerequisite requirements, see the IBM Security zSecure Suite 2.2.1 Prerequisites
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/prereqs_qradar.html) .
2. Configure your IBM DB2 image to write events in LEEF format. For more information, see the IBM
Security zSecure Suite: CARLa-Driven Components Installation and Deployment Guide
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/setup_data_prep_qradar.html).
3. Create a log source in QRadar for IBM DB2.
448
QRadar DSM Configuration Guide
4. If you want to create a custom event property for IBM DB2 in QRadar, for more information, see the
IBM Security Custom Event Properties for IBM z/OS technical note (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf).
Before you begin
Before you can configure the data collection process, you must complete the basic zSecure installation
process and complete the post-installation activities to create and modify the configuration.
The following prerequisites are required:
v You must ensure parmlib member IFAPRDxx is enabled for IBM Security zSecure Audit on your z/OS
image.
v The SCKRLOAD library must be APF-authorized.
v If you are using the direct SMF INMEM real-time interface, you must have the necessary software
installed (APAR OA49263) and set up the SMFPRMxx member to include the INMEM keyword and
parameters. If you decide to use the CDP interface, you must also have CDP installed and running. For
more information, see the IBM Security zSecure Suite 2.2.1: Procedure for near real-time
(http://www.ibm.com/support/knowledgecenter/en/SS2RWS_2.2.1/com.ibm.zsecure.doc_2.2.0/
installation/smf_proc_real_time_qradar.html)
v You must configure a process to periodically refresh your CKFREEZE and UNLOAD data sets.
v If you are using the Log File protocol method, you must configure a SFTP, FTP, or SCP server on your
z/OS image for QRadar to download your LEEF event files.
v If you are using the Log File protocol method, you must allow SFTP, FTP, or SCP traffic on firewalls
that are located between QRadar and your z/OS image.
For instructions on installing and configuring zSecure, see the IBM Security zSecure Suite: CARLa-Driven
Components Installation and Deployment Guide (http://www-01.ibm.com/support/
docview.wss?uid=pub1sc27277200).
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Create a log source for near real-time event feed
The Syslog protocol enables IBM Security QRadar to receive System Management Facilities (SMF) events
in near real-time from a remote host.
The following DSMs are supported:
v IBM z/OS
v IBM CICS
v IBM RACF
v IBM DB2
v CA Top Secret
v CA ACF2
If QRadar does not automatically detect the log source, add a log source for your DSM on the QRadar
console.
72 IBM
449
The following table describes the parameters that require specific values for event collection for your
DSM:
Table 258. Log source parameters
Parameter
Value
Log Source type
Select your DSM name from the list.
Protocol Configuration
Syslog
Log Source Identifier
Type a unique identifier for the log source.
Creating a log source for Log File protocol
The Log File protocol enables IBM Security QRadar to retrieve archived log files from a remote host for
the IBM z/OS, IBM CICS, IBM RACF, IBM DB2, CA Top Secret, and CA ACF2 DSM's.
About this task
Log files are transferred, one at a time, to QRadar for processing. The Log File protocol can manage plain
text event logs, compressed files, or archives. Archives must contain plain-text files that can be processed
one line at a time. Multi-line event logs are not supported by the Log File protocol. IBM z/OS with
zSecure writes log files to a specified directory as gzip archives. QRadar extracts the archive and
processes the events, which are written as one event per line in the file.
To retrieve these events, you must create a log source that uses the Log File protocol. QRadar requires
credentials to log in to the system that hosts your LEEF formatted event files and a polling interval.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for the log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select your DSM name.
8. From the Protocol Configuration list, select Log File.
9. Configure the Log File protocol parameters.
The following table describes the parameters that require specific values for the DSM event
collection:
Table 259. Log File protocol parameters
Parameter
Value
Log Source Identifier
Type an IP address, host name, or name to identify the event source. IP addresses
or host names are suggested as they allow QRadar to identify a log file to a unique
event source.
For example, if your network contains multiple devices, such as multiple z/OS
images or a file repository that contains all of your event logs, you must specify a
name, IP address, or host name for the image or location that uniquely identifies
events for the DSM log source. This specification enables events to be identified at
the image or location level in your network that your users can identify.
450
QRadar DSM Configuration Guide
Table 259. Log File protocol parameters (continued)
Parameter
Value
Service Type
From the Service Type list, select the protocol that you want to use when retrieving
log files from a remote server. The default is SFTP.
v SFTP - SSH File Transfer Protocol
v FTP - File Transfer Protocol
v SCP - Secure Copy
The underlying protocol that is used to retrieve log files for the SCP and SFTP
service type requires that the server that is specified in the Remote IP or Hostname
field has the SFTP subsystem enabled.
Remote IP or Hostname
Type the IP address or host name of the device that stores your event log files.
Remote Port
Type the TCP port on the remote host that is running the selected Service Type.
The valid range is 1 - 65535.
The options include ports:
v FTP - TCP Port 21
v SFTP - TCP Port 22
v SCP - TCP Port 22
If the host for your event files is using a non-standard port number for FTP, SFTP,
or SCP, you must adjust the port value.
Remote User
Type the user name or user ID necessary to log in to the system that contains your
event files.
v If your log files are on your IBM z/OS image, type the user ID necessary to log
in to your IBM z/OS. The user ID can be up to 8 characters in length.
v If your log files are on a file repository, type the user name necessary to log in to
the file repository. The user name can be up to 255 characters in length.
Remote Password
Type the password necessary to log in to the host.
Confirm Password
Confirm the password necessary to log in to the host.
SSH Key File
If you select SCP or SFTP as the Service Type, this parameter gives you the option
to define an SSH private key file. When you provide an SSH Key File, the Remote
Password field is ignored.
Remote Directory
Type the directory location on the remote host from which the files are retrieved,
relative to the user account you are using to log in.
Recursive
If you want the file pattern to search sub folders in the remote directory, select this
check box. By default, the check box is clear.
If you configure SCP as the Service Type, the Recursive option is ignored.
FTP File Pattern
If you select SFTP or FTP as the Service Type, you can configure the regular
expression (regex) needed to filter the list of files that are specified in the Remote
Directory. All matching files are included in the processing.
The IBM z/OS mainframe that uses IBM Security zSecure Audit writes event files
by using the pattern: <product_name>.<timestamp>.gz
The FTP file pattern that you specify must match the name that you assigned to
your event files. For example, to collect files that start with zOS and end with .gz,
type the following code:
zOS.*\.gz
Use of this parameter requires knowledge of regular expressions (regex). For more
information about regex, see Lesson: Regular Expressions. (http://
download.oracle.com/javase/tutorial/essential/regex/)
72 IBM
451
Table 259. Log File protocol parameters (continued)
Parameter
Value
FTP Transfer Mode
This option displays only if you select FTP as the Service Type. From the list, select
Binary.
The binary transfer mode is needed for event files that are stored in a binary or
compressed format, such as zip, gzip, tar, or tar+gzip archive files.
SCP Remote File
If you select SCP as the Service Type you must type the file name of the remote
file.
Start Time
Type the time of day you want the processing to begin. For example, type 00:00 to
schedule the Log File protocol to collect event files at midnight.
This parameter functions with the Recurrence value to establish when and how
often the Remote Directory is scanned for files. Type the start time, based on a
24-hour clock, in the following format: HH: MM.
Recurrence
Type the frequency, beginning at the Start Time, that you want the remote directory
to be scanned. Type this value in hours (H), minutes (M), or days (D).
For example, type 2H if you want the remote directory to be scanned every 2 hours
from the start time. The default is 1H.
Run On Save
If you want the Log File protocol to run immediately after you click Save, select
this check box.
After the Run On Save completes, the Log File protocol follows your configured
start time and recurrence schedule.
Selecting Run On Save clears the list of previously processed files for the Ignore
Previously Processed File parameter.
EPS Throttle
Type the number of Events Per Second (EPS) that you do not want this protocol to
exceed. The valid range is 100 - 5000.
Processor
From the list, select gzip.
Processors enable event file archives to be expanded and contents are processed for
events. Files are processed after they are downloaded to QRadar. QRadar can
process files in zip, gzip, tar, or tar+gzip archive format.
Ignore Previously Processed
File(s)
Select this check box to track and ignore files that are already processed by the Log
File protocol.
QRadar examines the log files in the remote directory to determine whether a file is
previously processed by the Log File protocol. If a previously processed file is
detected, the Log File protocol does not download the file for processing. All files
that are not previously processed are downloaded.
This option applies only to FTP and SFTP service types.
Change Local Directory?
Select this check box to define a local directory on your QRadar for storing
downloaded files during processing.
It is suggested that you leave this check box clear. When this check box is selected,
the Local Directory field is displayed, which gives you the option to configure the
local directory to use for storing files.
Event Generator
From the Event Generator list, select LineByLine.
The Event Generator applies more processing to the retrieved event files. Each line
is a single event. For example, if a file has 10 lines of text, 10 separate events are
created.
10. Click Save.
452
QRadar DSM Configuration Guide
11. On the Admin tab, click Deploy Changes.
The DSM configuration is complete. If your DSM requires custom event properties, see the IBM
Security Custom Event Properties for IBM z/OS technical note. (http://public.dhe.ibm.com/
software/security/products/qradar/documents/71MR1/SIEM/TechNotes/
IBM_zOS_CustomEventProperties.pdf)
Integrating IBM DB2 Audit Events
The IBM DB2 DSM allows you to integrate your DB2 audit logs into IBM Security QRadar for analysis.
The db2audit command creates a set of comma-delimited text files with a .del extension that defines the
scope of audit data for QRadar when auditing is configured and enabled. Comma-delimited files created
by the db2audit command include:
v audit.del
v checking.del
v context.del
v execute.del
v objmaint.del
v secmaint.del
v sysadmin.del
v validate.del
To integrate the IBM DB2 DSM with QRadar, you must:
1. Use the db2audit command to ensure the IBM DB2 records security events. See your IBM DB2 vendor
documentation for more information.
2. Extract the DB2 audit data of events contained in the instance to a log file, depending on your version
of IBM DB2.
3. Use the Log File protocol source to pull the output instance log file and send that information back to
QRadar on a scheduled basis. QRadar then imports and processes this file.
Related tasks:
“Extracting audit data for DB2 v8.x to v9.4”
You can extract audit data when you are using IBM DB2 v8.x to v9.4.
“Extracting audit data for DB2 v9.5” on page 454
You can extract audit data when you are using IBM DB2 v9.5.
Extracting audit data for DB2 v8.x to v9.4
You can extract audit data when you are using IBM DB2 v8.x to v9.4.
Procedure
1. Log into a DB2 account with SYSADMIN privilege.
2. Type the following start command to audit a database instance:
db2audit start
For example, the start command response might resemble the following output:
AUD00001 Operation succeeded.
3. Move the audit records from the instance to the audit log:
db2audit flush
For example, the flush command response might resemble the following output:
AUD00001 Operation succeeded.
4. Extract the data from the archived audit log and write the data to .del files:
72 IBM
453
db2audit extract delasc
For example, an archive command response might resemble the following output:
AUD00001 Operation succeeded.
Note: Double-quotation marks (") are used as the default text delimiter in the ASCII files, do not
change the delimiter.
5. Remove non-active records:
db2audit prune all
6. Move the .del files to a storage location where IBM Security QRadar can pull the file. The movement
of the comma-delimited (.del) files should be synchronized with the file pull interval in QRadar.
You are now ready to create a log source in QRadar to collect DB2 log files.
Extracting audit data for DB2 v9.5
You can extract audit data when you are using IBM DB2 v9.5.
Procedure
1. Log in to a DB2 account with SYSADMIN privilege.
2. Move the audit records from the database instance to the audit log:
db2audit flush
For example, the flush command response might resemble the following output:
AUD00001 Operation succeeded.
3. Archive and move the active instance to a new location for future extraction:
db2audit archive
For example, an archive command response might resemble the following output:
Node AUD Archived or Interim Log File Message
---- --- ----------------------------- 0 AUD00001 dbsaudit.instance.log.0.20091217125028 AUD00001 Operation succeeded.
Note: In DB2 v9.5 and later, the archive command replaces the prune command.
The archive command moves the active audit log to a new location, effectively pruning all non-active
records from the log. An archive command must be complete before an extract can be executed.
4. Extract the data from the archived audit log and write the data to .del files:
db2audit extract delasc from files db2audit.instance.log.0.200912171528
For example, an archive command response might resemble the following output:
AUD00001 Operation succeeded.
Note: Double-quotation marks (") are used as the default text delimiter in the ASCII files, do not
change the delimiter.
5. Move the .del files to a storage location where IBM Security QRadar can pull the file. The movement
of the comma-delimited (.del) files should be synchronized with the file pull interval in QRadar.
You are now ready to create a log source in QRadar to collect DB2 log files.
454
QRadar DSM Configuration Guide
IBM Federated Directory Server
The IBM Security QRadar DSM collects events from IBM Federated Directory Server systems.
The following table identifies the specifications for the IBM Federated Directory Server DSM:
Table 260. IBM Federated Directory Server DSM specifications
Specification
Value
Manufacturer
IBM
DSM name
IBM Federated Directory Server
RPM file name
DSM-IBMFederated DirectoryServer-Qradar_versionbuild_number.noarch.rpm
Supported versions
V7.2.0.2 and later
Event format
LEEF
Recorded event types
FDS Audit
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
Security Directory Server information in the IBM
Knowledge Center ((http://www-01.ibm.com/support/
knowledgecenter/SSVJJU/welcome)
To send events from IBM Federated Directory Server to QRadar, complete the following steps:
1. If automatic updates are not enabled, download the most recent version of the following RPMs on
your QRadar Console:
v DSMCommon RPM
v IBM Federated Directory Server DSM RPM
2. Configure QRadar monitoring on your IBM Federated Directory Server device.
3. If QRadar does not automatically detect the log source, add an IBM Federated Directory Server log
source on the QRadar Console. The following table describes the parameters that require specific
values for IBM Federated Directory Server event collection:
Table 261. IBM Federated Directory Serve log source parameters
Parameter
Value
Log Source type
IBM Federated Directory Server
Protocol Configuration
Syslog
Log Source Identifier
The source IP or host name of the IBM Federated
Directory Server.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring IBM Federated Directory Server to monitor security events” on page 456
Configure IBM Federated Directory Server to monitor security events, which are generated when an entry
is added, modified, or deleted in the target
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
72 IBM
455
Configuring IBM Federated Directory Server to monitor security events
Configure IBM Federated Directory Server to monitor security events, which are generated when an entry
is added, modified, or deleted in the target
Procedure
1. Log in to your IBM Federated Directory Server.
2. In the navigation pane, under Common Settings, click Monitoring.
3. On the Monitoring page, click the QRadar tab.
4. To indicate that you want to monitor security events, on the QRadar page, select Enabled .
5. Configure the parameters
6. In the Map file field, specify the path and file name of the map file that configures the various
QRadar LEEF attributes for the event.
7. Click Select to browse for the map file. The default value points to the LDAPSync/QRadar.map file.
8. In the Date format mask field, specify a standard Java SimpleDateFormat mask to use for date values
that are written in mapped LEEF attributes.
This value controls both the value of the devTimeFormat attribute and the formatting of date values
in the event. The default value is the ISO 8601 standard mask, MMM dd yy HH:mm:ss, which creates a
string, Oct 16 12 15:15:57.
IBM Fiberlink MaaS360
The IBM Fiberlink® MaaS360® DSM for IBM Security QRadar can collect event logs from the Fiberlink
MaaS360 console.
The following table identifies the specifications for the IBM Fiberlink MaaS360 DSM:
Table 262. IBM Fiberlink MaaS360 DSM Specification
Specification
Value
Manufacturer
IBM
DSM name
IBM Fiberlink MaaS360
RPM file name
DSM-IBMFiberlinkMaaS360
Supported versions
N/A
Event format
LEEF
QRadar recorded event types
Compliance rule events
Device enrollment events
Action history events
Automatically discovered?
No
Included identity?
Yes
Includes custom properties?
No
More information
Fiberlink MaaS360 website (http://www.maas360.com/)
To integrate IBM Fiberlink MaaS360 with QRadar, use the following steps:
1. If automatic updates are not enabled, download the latest versions of the following RPMs:
v DSMCommon RPM
v IBM Fiberlink REST API Protocol RPM
v IBM Fiberlink MaaS360 RPM
456
QRadar DSM Configuration Guide
2. Configure your Fiberlink MaaS360 instance to enable communication with QRadar.
3. Add an IBM Fiberlink MaaS360 log source on the QRadar Console.
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring an IBM Fiberlink MaaS360 log source in QRadar
To collect IBM Fiberlink MaaS360 events, configure a log source in QRadar.
Before you begin
To enable IBM Fiberlink MaaS360 to communicate with QRadar, you must enable the REST API. Contact
Fiberlink customer service to enable the REST API for your Fiberlink MaaS360 account.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. From the Log Source Type list, select IBM Fiberlink MaaS360.
7. From the Protocol Configuration list, select IBM Fiberlink REST API.
8. Configure the following IBM Fiberlink REST API parameters:
Parameter
Description
Log Source Identifier
Type a unique identifier for the log source.
The Log Source Identifier can be set to any valid value
and does not need to reference a specific server. You can
set the Log Source Identifier to the same value as the
Log Source Name. If you have more than one IBM
Fiberlink MaaS360 log source that is configured, you
might want to identify the first log source as fiberlink1,
the second log source as fiberlink2, and the third log
source as fiberlink3.
Login URL
The URL for the Fiberlink MaaS360 REST server.
Username
The user name that is used to access the MaaS360 APIs.
Users with the following administrator roles can access
the APIs:
v Service Administrator
v Administrator
v Administrator-Level 2
Password
The password that is used to access your MaaS360 APIs.
Secret Key
The secret key that is provided by Fiberlink Customer
Service when you enabled the REST API.
App ID
The App ID that was provided by Fiberlink Customer
Service when you enabled the REST API.
72 IBM
457
Parameter
Description
Billing ID
The Billing ID for your Fiberlink MaaS360 account.
Platform
The platform version of the Fiberlink MaaS360 console.
App Version
The App Version of the application that corresponds to
your REST API account.
Use Proxy
If QRadar accesses the Fiberlink MaaS360 API by using a
proxy, select the Use Proxy check box.
If the proxy requires authentication, configure the Proxy
Server, Proxy Port, Proxy Username, and Proxy
Password fields.
If the proxy does not require authentication, configure
the Proxy Server and Proxy Port fields
Automatically Acquire Server Certificate(s)
QRadar automatically downloads the server certificate
and begins trusting the target server when the Yes option
is selected.
9. Configure the remaining parameters.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
IBM Guardium
IBM Guardium®® is a database activity and audit tracking tool for system administrators to retrieve
detailed auditing events across database platforms.
These instructions require that you install the 8.2p45 fix for InfoSphere® Guardium. For more information
about this fix, see the Fix Central website at http://www.ibm.com/support/fixcentral/.
IBM Security QRadar collects informational, error, alert, and warnings from IBM Guardium by using
syslog. IBM Security QRadar receives IBM Guardium Policy Builder events in the Log Event Extended
Format (LEEF).
QRadar can only automatically discover and map events of the default policies that ship with IBM
Guardium. Any user configured events that are required are displayed as unknowns in QRadar and you
must manually map the unknown events.
Configuration overview
The following list outlines the process that is required to integrate IBM Guardium with QRadar.
1. Create a syslog destination for policy violation events. For more information, see “Creating a syslog
destination for events” on page 459.
2. Configure your existing policies to generate syslog events. For more information, see “Configuring
policies to generate syslog events” on page 459.
3. Install the policy on IBM Guardium. For more information, see “Installing an IBM Guardium Policy”
on page 460.
4. Configure the log source in QRadar. For more information, see “Configuring a log source” on page
460.
5. Identify and map unknown policy events in QRadar. For more information, see “Creating an event
map for IBM Guardium events” on page 461.
458
QRadar DSM Configuration Guide
Creating a syslog destination for events
To create a syslog destination for these events on IBM Guardium, you must log in to the command line
interface (CLI) and define the IP address for IBM Security QRadar.
Procedure
1. Using SSH, log in to IBM Guardium as the default user.
Username: <username>
Password: <password>
2. Type the following command to configure the syslog destination for informational events:
store remote add daemon.info <IP address>:<port> <tcp|udp>
For example,
store remote add daemon.info <IP_address> tcp
Where:
v <IP address> is the IP address of your QRadar Console or Event Collector.
v <port> is the syslog port number that is used to communicate to the QRadar Console or Event
Collector.
v <tcp|udp> is the protocol that is used to communicate to the QRadar Console or Event Collector.
3. Type the following command to configure the syslog destination for warning events:
store remote add daemon.warning <IP address>:<port> <tcp|udp>
Where:
v <IP address> is the IP address of your QRadar Console or Event Collector.
v <port> is the syslog port number that is used to communicate to the QRadar Console or Event
Collector.
v <tcp|udp> is the protocol that is used to communicate to the QRadar Console or Event Collector.
4. Type the following command to configure the syslog destination for error events:
store remote add daemon.err <IP address>:<port> <tcp|udp>
Where:
v <IP address> is the IP address of your QRadar Console or Event Collector.
v <port> is the syslog port number that is used to communicate to the QRadar Console or Event
Collector.
v <tcp|udp> is the protocol that is used to communicate to the QRadar Console or Event Collector.
5. Type the following command to configure the syslog destination for alert events:
store remote add daemon.alert <IP address>:<port> <tcp|udp>
Where:
v <IP address> is the IP address of your QRadar Console or Event Collector.
v <port> is the syslog port number that is used to communicate to the QRadar Console or Event
Collector.
v <tcp|udp> is the protocol that is used to communicate to the QRadar Console or Event Collector.
You are now ready to configure a policy for IBM InfoSphere Guardium.
Configuring policies to generate syslog events
Policies in IBM Guardium are responsible for reacting to events and forwarding the event information to
IBM Security QRadar.
Procedure
1. Click the Tools tab.
2. From the left navigation, select Policy Builder.
72 IBM
459
3. From the Policy Finder pane, select an existing policy and click Edit Rules.
4. Click Edit this Rule individually.
The Access Rule Definition is displayed.
5. Click Add Action.
6. From the Action list, select one of the following alert types:
v Alert Per Match - A notification is provided for every policy violation.
v Alert Daily - A notification is provided the first time a policy violation occurs that day.
v Alert Once Per Session - A notification is provided per policy violation for unique session.
v Alert Per Time Granularity - A notification is provided per your selected time frame.
7. From the Message Template list, select QRadar.
8. From Notification Type, select SYSLOG.
9. Click Add, then click Apply.
10. Click Save.
11. Repeat “Configuring policies to generate syslog events” on page 459 for all rules within the policy
that you want to forward to QRadar.
For more information on configuring a policy, see your IBM InfoSphere Guardium vendor
documentation. After you have configured all of your policies, you are now ready to install the
policy on your IBM Guardium system.
Note: Due to the configurable policies, QRadar can only automatically discover the default policy
events. If you have customized policies that forward events to QRadar, you must manually create a
log source to capture those events.
Installing an IBM Guardium Policy
Any new or edited policy in IBM Guardium must be installed before the updated alert actions or rule
changes can occur.
Procedure
1. Click the Administration Console tab.
2. From the left navigation, select Configuration > Policy Installation.
3. From the Policy Installer pane, select a policy that you modified in “Configuring policies to generate
syslog events” on page 459.
4. From the drop-down list, select Install and Override.
A confirmation is displayed to install the policy to all Inspection Engines.
5. Click OK.
For more information on installing a policy, see your IBM InfoSphere Guardium vendor documentation.
After you install all of your policies, you are ready to configure the log source in IBM Security
QRadar.
Configuring a log source
IBM Security QRadar only automatically discovers default policy events from IBM Guardium.
About this task
Because of the configurable nature of policies, it is suggested that you configure a log source manually
for IBM Guardium.
460
QRadar DSM Configuration Guide
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. Click Add.
5. In the Log Source Name field, type a name for the log source.
6. In the Log Source Description field, type a description for the log source.
7. From the Log Source Type list, select IBM Guardium.
8. From the Protocol Configuration list, select Syslog.
9. Configure the following values:
Table 263. IBM Guardium syslog configuration
Parameter
Description
Log Source Identifier
Type the IP address or host name for the IBM InfoSphere Guardium appliance.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
Creating an event map for IBM Guardium events
Event mapping is required for a number of IBM Guardium events. Due to the customizable nature of
policy rules, most events, except the default policy events do not contain a predefined IBM Security
QRadar Identifier (QID) map to categorize security events.
About this task
You can individually map each event for your device to an event category in QRadar. Mapping events
allows QRadar to identify, coalesce, and track recurring events from your network devices. Until you
map an event, all events that are displayed in the Log Activity tab for IBM Guardium are categorized as
unknown. Unknown events are easily identified as the Event Name column and Low Level Category
columns display Unknown.
As your device forwards events to QRadar, it can take time to categorize all of the events for a device, as
some events might not be generated immediately by the event source appliance or software. It is helpful
to know how to quickly search for unknown events. When you know how to search for unknown events,
we suggest that you repeat this search until you are satisfied that most of your events are identified.
Procedure
1. Log in to QRadar.
2. Click the Log Activity tab.
3. Click Add Filter.
4. From the first list, select Log Source.
5. From the Log Source Group list, select the log source group or Other.
Log sources that are not assigned to a group are categorized as Other.
6. From the Log Source list, select your IBM Guardium log source.
7. Click Add Filter.
The Log Activity tab is displayed with a filter for your log source.
8. From the View list, select Last Hour.
Any events that are generated by the IBM Guardium DSM in the last hour are displayed. Events that
are displayed as unknown in the Event Name column or Low Level Category column require event
mapping in QRadar.
72 IBM
461
Note: You can save your existing search filter by clicking Save Criteria.
You are now ready to modify the event map.
Modifying the event map
Modifying an event map allows for the manual categorization of events to a IBM Security QRadar
Identifier (QID) map. Any event that is categorized to a log source can be remapped to a new QRadar
Identifier (QID).
About this task
IBM Guardium event map events that do not have a defined log source cannot be mapped to an event.
Events without a log source display SIM Generic Log in the Log Source column.
Procedure
1. On the Event Name column, double-click an unknown event for IBM Guardium.
The detailed event information is displayed.
2. Click Map Event.
3. From the Browse for QID pane, select any of the following search options to narrow the event
categories for a QRadar Identifier (QID):
v From the High-Level Category list, select a high-level event categorization.
v For a full list of high-level and low-level event categories or category definitions, see the Event
Categories section of the IBM Security QRadar Administration Guide.
v From the Low-Level Category list, select a low-level event categorization.
v From the Log Source Type list, select a log source type.
The Log Source Type list gives the option to search for QIDs from other log sources. Searching for
QIDs by log source is useful when events are similar to another existing network device. For example,
IBM Guardium provides policy events, you might select another product that likely captures similar
events.
4. To search for a QID by name, type a name in the QID/Name field.
The QID/Name field gives the option to filter the full list of QIDs for a specific word, for example,
policy.
5. Click Search.
A list of QIDs are displayed.
6. Select the QID you want to associate to your unknown event.
7. Click OK.
QRadar maps any additional events that are forwarded from your device with the same QID that
matches the event payload. The event count increases each time that the event is identified by
QRadar.
If you update an event with a new QRadar Identifier (QID) map, past events that are stored in
QRadar are not updated. Only new events are categorized with the new QID.
IBM IMS
The IBM Information Management System (IMS™) DSM for IBM Security QRadar allows you to use an
IBM mainframe to collect events and audit IMS database transactions.
To integrate IBM IMS events with QRadar, you must download scripts that allow IBM IMS events to be
written to a log file.
Overview of the event collection process:
462
QRadar DSM Configuration Guide
1. The IBM mainframe records all security events as Service Management Framework (SMF) records in a
live repository.
2. The IBM IMS data is extracted from the live repository using the SMF dump utility. The SMF file
contains all of the events and fields from the previous day in raw SMF format.
3. The qeximsloadlib.trs program pulls data from the SMF formatted file. The qeximsloadlib.trs
program only pulls the relevant events and fields for QRadar and writes that information in a
condensed format for compatibility. The information is saved in a location accessible by QRadar.
4. QRadar uses the log file protocol source to retrieve the output file information for QRadar on a
scheduled basis. QRadar then imports and processes this file.
Configuring IBM IMS
You can integrate IBM IMS with QRadar:
Procedure
1. From the IBM support website (http://www.ibm.com/support), download the following compressed
file:
QexIMS_bundled.tar.gz
2. On a Linux-based operating system, extract the file:
tar -zxvf qexims_bundled.tar.gz
The following files are contained in the archive:
v qexims_jcl.txt - Job Control Language file
v qeximsloadlib.trs - Compressed program library (requires IBM TRSMAIN)
v qexims_trsmain_JCL.txt - Job Control Language for TRSMAIN to decompress the .trs file
3. Load the files onto the IBM mainframe by using the following methods:
Upload the sample qexims_trsmain_JCL.txt and qexims_jcl.txt files by using the TEXT protocol.
4. Upload the qeximsloadlib.trs file by using BINARY mode transfer and append to a pre-allocated
data set. The qeximsloadlib.trs file is a tersed file that contains the executable (the mainframe
program QexIMS). When you upload the .trs file from a workstation, pre-allocate a file on the
mainframe with the following DCB attributes: DSORG=PS, RECFM=FB, LRECL= 1024,
BLKSIZE=6144. The file transfer type must be binary mode and not text.
Note: QexIMS is a small C mainframe program that reads the output of the IMS log file (EARLOUT
data) line by line. QexIMS adds a header to each record that contains event information, for example,
record descriptor, the date, and time. The program places each field into the output record, suppresses
trailing blank characters, and delimits each field with the pipe character. This output file is formatted
for QRadar and the blank suppression reduces network traffic to QRadar. This program does not need
much CPU or I/O disk resources.
5. Customize the qexims_trsmain_JCL.txt file according to your installation-specific information for
parameters.
For example, jobcard, data set naming conventions, output destinations, retention periods, and space
requirements.
The qexims_trsmain_JCL.txt file uses the IBM utility TRSMAIN to extract the program that is stored
in the qeximsloadlib.trs file.
An example of the qexims_trsmain_JCL.txt file includes:
//TRSMAIN JOB (yourvalidjobcard),Q1labs,
// MSGCLASS=V
//DEL EXEC PGM=IEFBR14 //D1 DD DISP=(MOD,DELETE),DSN=<yourhlq>.QEXIMS.TRS
// UNIT=SYSDA, // SPACE=(CYL,(10,10))
//TRSMAIN EXEC PGM=TRSMAIN,PARM=’UNPACK’
//SYSPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=12901,RECFM=FBA)
72 IBM
463
//INFILE DD DISP=SHR,DSN=<yourhlq>.QEXIMS.TRS
//OUTFILE DD DISP=(NEW,CATLG,DELETE),
// DSN=<yourhlq>.LOAD, // SPACE=(CYL,(1,1,5),RLSE),UNIT=SYSDA
//
The .trs input file is an IBM TERSE formatted library and is extracted by running the JCL, which
calls the TRSMAIN. This tersed file, when extracted, creates a PDS linklib with the qexims program as
a member.
6. You can STEPLIB to this library or choose to move the program to one of the LINKLIBs that are in
LINKLST. The program does not require authorization.
7. The qexims_jcl.txt file is a text file that contains a sample JCL. You must configure the job card to
meet your configuration.
The qexims_jcl.txt sample file includes:
//QEXIMS JOB (T,JXPO,JKSD0093),DEV,NOTIFY=Q1JACK,
// MSGCLASS=P,
// REGION=0M //* //*QEXIMS JCL VERSION 1.0 FEBRUARY 2011
//*
//************************************************************
//* Change dataset names to site specific dataset names *
//************************************************************
//SET1 SET IMSOUT=’Q1JACK.QEXIMS.OUTPUT’,
// IMSIN=’Q1JACK.QEXIMS.INPUT.DATA’
//************************************************************
//* Delete old datasets *
//************************************************************
//DEL EXEC PGM=IEFBR14 //DD1 DD DISP=(MOD,DELETE),DSN=&IMSOUT,
// UNIT=SYSDA, // SPACE=(CYL,(10,10)), // DCB=(RECFM=FB,LRECL=80)
//************************************************************
//* Allocate new dataset
//************************************************************
//ALLOC EXEC PGM=IEFBR14 //DD1 DD DISP=(NEW,CATLG),DSN=&IMSOUT,
// SPACE=(CYL,(21,2)),
// DCB=(RECFM=VB,LRECL=1028,BLKSIZE=6144)
//EXTRACT EXEC PGM=QEXIMS,DYNAMNBR=10,
// TIME=1440 //STEPLIB DD DISP=SHR,DSN=Q1JACK.C.LOAD
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=* //IMSIN DD DISP=SHR,DSN=&IMSIN
//IMSOUT DD DISP=SHR,DSN=&IMSOUT
//*FTP EXEC PGM=FTP,REGION=3800K //*INPUT DD *
//*<target server>
//*<USER>
//*<PASSWORD>
//*ASCII //*PUT ’<IMSOUT>’ /TARGET DIRECTORY>/<IMSOUT>
//*QUIT
//*OUTPUT DD SYSOUT=* //*SYSPRINT DD SYSOUT=*
//*
8. After the output file is created, you must make one of the following choices:
v Schedule a job to transfer the output file to an interim FTP server.
v Each time the job completes, the output file is forwarded to an interim FTP server. You must
configure the following parameters in the sample JCL to successfully forward the output to an
interim FTP server:
For example:
//*FTP EXEC PGM=FTP,REGION=3800K
//*INPUT DD *
//*<target server>
//*<USER>
//*<PASSWORD> //*ASCII //*PUT ’<IMSOUT>’
/TARGET DIRECTORY>/<IMSOUT>
//*QUIT //*OUTPUT DD SYSOUT=*
//*SYSPRINT DD SYSOUT=*
464
QRadar DSM Configuration Guide
Where:
v <target server> is the IP address or host name of the interim FTP server to receive the output file.
v <USER> is the user name required to access the interim FTP server.
v <PASSWORD> is the password required to access the interim FTP server.
v <IMSOUT> is the name of the output file saved to the interim FTP server.
For example:
PUT ’Q1JACK.QEXIMS.OUTPUT.C320’ /192.0.2.1/IMS/QEXIMS.OUTPUT.C320
Note: You must remove commented lines that begin with //* for the script to properly forward the
output file to the interim FTP server.
You are now ready to configure the log file protocol.
9. Schedule QRadar to retrieve the output file from IBM IMS.
If the mainframe is configured to serve files through FTP, SFTP, or allow SCP, then no interim FTP
server is required and QRadar can pull the output file directly from the mainframe. The following text
must be commented out using //* or deleted from the qexims_jcl.txt file:
//*FTP EXEC PGM=FTP,REGION=3800K //*INPUT DD *
//*<target server>
//*<USER> //*<PASSWORD> //*ASCII
//*PUT ’<IMSOUT>’
/<TARGET DIRECTORY>/<IMSOUT>
//*QUIT //*OUTPUT DD SYSOUT=*
//*SYSPRINT DD SYSOUT=*
You are now ready to configure the log file protocol.
Configuring a log source
A log file protocol source allows IBM Security QRadar to retrieve archived log files from a remote host.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. Click the Log Sources icon.
4. From the Log Source Type list, select IBM IMS.
5. Using the Protocol Configuration list, select Log File.
6. Configure the following parameters:
Table 264. Log file protocol parameters
Parameter
Description
Log Source Identifier
Type the IP address or host name for the log source. The log source identifier must
be unique for the log source type.
Service Type
From the list, select the protocol that you want to use when retrieving log files from
a remove server. The default is SFTP.
v SFTP - SSH File Transfer Protocol
v FTP - File Transfer Protocol
v SCP - Secure Copy
The underlying protocol that is used to retrieve log files for the SCP and SFTP
service types requires that the server specified in the Remote IP or Hostname field
has the SFTP subsystem enabled.
Remote IP or Hostname
Type the IP address or host name of the IBM IMS system.
72 IBM
465
Table 264. Log file protocol parameters (continued)
Parameter
Description
Remote Port
Type the TCP port on the remote host that is running the selected Service Type. If
you configure the Service Type as FTP, the default is 21. If you configure the
Service Type as SFTP or SCP, the default is 22.
The valid range is 1 - 65535.
Remote User
Type the user name necessary to log in to your IBM IMS system.
The user name can be up to 255 characters in length.
Remote Password
Type the password necessary to log in to your IBM IMS system.
Confirm Password
Confirm the Remote Password to log in to your IBM IMS system.
SSH Key File
If you select SCP or SFTP from the Service Type field you can define a directory
path to an SSH private key file. The SSH Private Key File gives the option to ignore
the Remote Password field.
Remote Directory
Type the directory location on the remote host from which the files are retrieved. By
default, the newauditlog.sh script writes the human-readable logs files to the
/var/log/ directory.
Recursive
Select this check box if you want the file pattern to also search sub folders. The
Recursive parameter is not used if you configure SCP as the Service Type. By
default, the check box is clear.
FTP File Pattern
If you select SFTP or FTP as the Service Type, this gives the option to configure the
regular expression (regex) used to filter the list of files that are specified in the
Remote Directory. All matching files are included in the processing.
For example, if you want to retrieve all files in the
<starttime>.<endtime>.<hostname>.log format, use the following entry:
\d+\.\d+\.\w+\.log.
Use of this parameter requires knowledge of regular expressions (regex). For more
information, see the following website: http://download.oracle.com/javase/
tutorial/essential/regex/
FTP Transfer Mode
This option appears only if you select FTP as the Service Type. The FTP Transfer
Mode parameter gives the option to define the file transfer mode when log files are
retrieved over FTP.
From the list, select the transfer mode that you want to apply to this log source:
v Binary - Select Binary for log sources that require binary data files or compressed
.zip, .gzip, .tar, or .tar+gzip archive files.
v ASCII - Select ASCII for log sources that require an ASCII FTP file transfer. You
must select NONE for the Processor field and LineByLine the Event Generator
field ASCII is used as the transfer mode.
SCP Remote File
If you select SCP as the Service Type, you must type the file name of the remote
file.
Start Time
Type the time of day you want the processing to begin. This parameter functions
with the Recurrence value to establish when and how often the Remote Directory
is scanned for files. Type the start time, based on a 24-hour clock, in the following
format: HH: MM.
Recurrence
Type the frequency, beginning at the Start Time, that you want the remote directory
to be scanned. Type this value in hours (H), minutes (M), or days (D).
For example, type 2H if you want the directory to be scanned every 2 hours. The
default is 1H.
466
QRadar DSM Configuration Guide
Table 264. Log file protocol parameters (continued)
Parameter
Description
Run On Save
Select this check box if you want the log file protocol to run immediately after you
click Save. After the Run On Save completes, the log file protocol follows your
configured start time and recurrence schedule.
Selecting Run On Save clears the list of previously processed files for the Ignore
Previously Processed File(s) parameter.
EPS Throttle
Type the number of Events Per Second (EPS) that you do not want this protocol to
exceed. The valid range is 100 - 5000.
Processor
If the files on the remote host are stored in a .zip, .gzip, .tar, or tar+gzip archive
format, select the processor that allows the archives to be expanded and the
contents to be processed.
Ignore Previously Processed
File(s)
Select this check box to track files that are processed and you do not want the files
to be processed a second time. This applies only to FTP and SFTP Service Types.
Change Local Directory?
Select this check box to define the local directory on your QRadar system that you
want to use for storing downloaded files during processing. We recommend that
you leave the check box clear. When the check box is selected, the Local Directory
field is displayed, which gives the option to configure the local directory to use for
storing files.
Event Generator
From the Event Generator list, select LineByLine.
7. Click Save.
The configuration is complete. Events that are retrieved by using the log file protocol are displayed on
the Log Activity tab of QRadar.
IBM Informix Audit
The IBM Informix® Audit DSM allows IBM Security QRadar to integrate IBM Informix audit logs into
QRadar for analysis.
QRadar retrieves the IBM Informix archived audit log files from a remote host using the log file protocol
configuration. QRadar records all configured IBM Informix Audit events.
When configuring your IBM Informix to use the log file protocol, make sure the host name or IP address
configured in the IBM Informix is the same as configured in the Remote Host parameter in the log file
protocol configuration.
You are now ready to configure the log source and protocol in QRadar:
v
To configure QRadar to receive events from an IBM Informix device, you must select the IBM Informix
Audit option from the Log Source Type list.
v
To configure the log file protocol, you must select the Log File option from the Protocol Configuration
list.
Use a secure protocol for transferring files, such as Secure File Transfer Protocol (SFTP).
Related concepts:
“Log File protocol configuration options” on page 22
To receive events from remote hosts, configure a log source to use the Log File protocol.
Related tasks:
72 IBM
467
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
IBM Lotus Domino
You can integrate an IBM Lotus® Domino®® device with IBM Security QRadar. An IBM Lotus Domino
device accepts events by using SNMP.
Setting Up SNMP Services
To set up the SNMP services on the IBM Lotus Domino server:
Procedure
1. Install the Lotus Domino SNMP Agent as a service. From the command prompt, go to the
Lotus\Domino directory and type the following command:
Insnmp -SC
2. Confirm that the Microsoft SNMP service is installed.
3. Start the SNMP and LNSNMP services. From a command prompt, type the following commands:
v net start snmp
v net start lnsnmp
4. Select Start > Program > Administrative Tools > Services to open the Services MMC
5. Double-click on the SNMP service and select the Traps tab.
6. In the Community name field, type public and click add to list.
7. In the Traps destinations section, select Add and type the IP address of your IBM Security QRadar.
Click Add.
8. Click OK.
9. Confirm that both SNMP agents are set to Automatic so they run when the server boots.
Setting up SNMP in AIX
Before you begin
Make sure TCP/IP and SNMP are properly installed and configured on the server.
You must log in as a root user.
Procedure
1. Stop the LNSNMP service with the following command:
lnsnmp.sh stop
2. Stop the SNMP subsystem with the following command:
stopsrc -s snmpd
3. Configure SNMP to accept LNSNMP as an SMUX peer. Add the following line to /etc/snmpd.peers
"Lotus Notes Agent" 1.3.6.1.4.1.334.72 "NotesPasswd"
4. Configure SNMP to accept an SMUX association from LNSNMP. Add the following line to
/etc/snmpd.conf or /etc/snmpdv3.conf
smux 1.3.6.1.4.1.334.72 NotesPasswd
5. Start the SNMP subsystem with the following command:
startsrc -s snmpd
6. Start the LNSNMP service with the following command:
468
QRadar DSM Configuration Guide
lnsnmp.sh start
7. Create a link to the LNSNMP script
ln -f -s /opt/ibm/lotus/notes/latest/ibmpow/lnsnmp.sh /etc/lnsnmp.rc
8. Configure LNSNMP service to start during the system restart. Add the following line to the end of
/etc/rc.tcpip
/etc/lnsnmp.rc start
Starting the Domino Server Add-in Tasks
After you configure the SNMP services, you must start the Domino server add-in tasks.
About this task
Use the following procedure for each Domino partition.
Procedure
1. Log in to the Domino Server console.
2. To support SNMP traps for Domino events, type the following command to start the Event
Interceptor add-in task:
load intrcpt
3. To support Domino statistic threshold traps, type the following command to start the Statistic
Collector add-in task:
load collect
4. Arrange for the add-in tasks to be restarted automatically the next time that Domino is restarted. Add
intrcpt and collect to the ServerTasks variable in Domino's NOTES.INI file.
Configuring SNMP Services
You can configure SNMP services:
About this task
Configurations might vary depending on your environment. See your vendor documentation for more
information.
Procedure
1. Open the Domino Administrator utility and authenticate with administrative credentials.
2. Click the Files tab, and the Monitoring Configuration (events4.nsf) document.
3. Expand the DDM Configuration Tree and select DDM Probes By Type.
4. Select Enable Probes, and then select Enable All Probes In View.
Note: You might receive a warning when you complete this action. This warning is a normal
outcome, as some of the probes require more configuration.
5. Select DDM Filter.
You can either create a new DDM Filter or edit the existing DDM Default Filter.
6. Apply the DDM Filter to enhanced and simple events. Choose to log all event types.
7. Depending on the environment, you can choose to apply the filter to all servers in a domain or only
to specific servers.
8. Click Save. Close when finished.
9. Expand the Event Handlers tree and select Event Handlers By Server.
10. Select New Event Handler.
72 IBM
469
11. Configure the following parameters:
v Basic - Servers to monitor: Choose to monitor either all servers in the domain or only specific
servers.
v Basic - Notification trigger: Any event that matches the criteria.
v Event - Criteria to match: Events can be any type.
v Event - Criteria to match: Events must be one of these priorities (Check all the boxes).
v Event - Criteria to match: Events can have any message.
v Action - Notification method: SNMP Trap.
v Action - Enablement: Enable this notification.
12. Click Save. Close when finished.
You are now ready to configure the log source in IBM Security QRadar.
Configuring your IBM Lotus Domino device to communicate with
QRadar
IBM Security QRadar does not automatically discover incoming syslog events from your IBM Lotus
Domino device.
About this task
You must manually create a log source from the Admin tab in QRadar.
Procedure
1. Click the Admin tab.
2. Click the Log Sources icon.
3. Click Add.
4. In the Log Source Name field, type a name for your log source.
5. From the Log Source Type list, select IBM Lotus Domino.
6. From the Protocol Configuration list, select SNMPv2.
7. Configure the following values:
Table 265. SNMPv2 protocol parameters
Parameter
Description
Log Source Identifier
Type an IP address, host name, or name to identify the SNMPv2 event source.
IP addresses or host names are recommended as they allow QRadar to identify a log
file to a unique event source.
Community
Type the SNMP community name required to access the system containing SNMP
events.
Include OIDs in Event
Payload
Clear the value from this check box.
When selected, this option constructs SNMP events with name-value pairs instead of
the standard event payload format.
8. Click Save.
9. On the Admin tab, click Deploy Changes.
470
QRadar DSM Configuration Guide
IBM Privileged Session Recorder
The IBM Security QRadar DSM for IBM Privileged Session Recorder can collect event logs from your IBM
Privileged Session Recorder device.
The following table lists the specifications for the IBM Privileged Session Recorder DSM.
Table 266. IBM Privileged Session Recorder specifications
Specification
Value
Manufacturer
IBM
DSM name
Privileged Session Recorder
RPM filename
DSM-IBMPrivilegedSessionRecorder
Protocol
JDBC
QRadar recorded event types
Command Execution Audit Events
Automatically discovered?
No
Includes identity?
No
More information
IBM website (http://www.ibm.com/)
To collect IBM Privileged Session Recorder events, use the following procedures:
1. If automatic updates are not enabled, download and install the following RPMs on your QRadar
Console:
v Protocol-JDBC RPM
v IBM Privileged Session Recorder DSM RPM
2.
On the IBM Security Privileged Identity Manager dashboard, obtain the database information for the
Privileged Session Recorder data store and configure your IBM Privileged Session Recorder DB2
database to allow incoming TCP connections.
3. For each instance of IBM Privileged Session Recorder, create an IBM Privileged Session Recorder log
source on the QRadar Console. Use the following table to define the Imperva SecureSphere
parameters:
Table 267. IBM Privileged Session Recorder log source parameters
Parameter
Description
Log Source Type
IBM Privileged Session Recorder
Protocol Configuration
JDBC
Log Source Identifier
DATABASE@HOSTNAME
Database Type
DB2
Database Name
The Session Recorder data store name that you
configured on the IBM Privileged Identity Manager
dashboard.
IP or Hostname
The Session Recorder database server address.
Port
The port that is specified on IBM Privileged Identity
Manager dashboard.
Username
The DB2 database user name
Password
The DB2 database password
Predefined Query
IBM Privileged Session Recorder
Use Prepared Statements
This option must be selected.
Start Date and Time
The initial date and time for the JDBC retrieval.
72 IBM
471
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Configuring IBM Privileged Session Recorder to communicate with QRadar”
Before you can configure a log source in IBM Privileged Session Recorder for IBM Security QRadar,
obtain the database information for the Privileged Session Recorder data store. You must also configure
your IBM Privileged Session Recorder DB2 database to allow incoming TCP connections from QRadar.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring IBM Privileged Session Recorder to communicate with
QRadar
Before you can configure a log source in IBM Privileged Session Recorder for IBM Security QRadar,
obtain the database information for the Privileged Session Recorder data store. You must also configure
your IBM Privileged Session Recorder DB2 database to allow incoming TCP connections from QRadar.
IBM Privileged Session Recorder is a component of IBM Security Privileged Identity Manager.
Procedure
1. Log in to the IBM Security Privileged Identity Manager web user interface.
2. Select the Configure Privileged Identity Manager tab.
3. Select Database Server Configuration in the Manage External Entities section.
4. In the table, double-click the Session Recording data store row in the Database Server Configuration
column.
5. 5. Record the following parameters to use when you configure a log source in QRadar:
IBM Privileged Session Recorder Field
QRadar Log Source Field
Hostname
IP or Hostname
Port
Port
Database name
Database Name
Database administrator ID
Username
Configuring a log source for IBM Privileged Session Recorder
QRadar does not automatically discover IBM Privileged Session Recorder events. To integrate IBM
Privileged Session Recorder event data, you must create a log source for each instance from which you
want to collect event logs.
Procedure
1. Log in to QRadar.
2. Click the Admin tab.
3. In the navigation menu, click Data Sources.
4. Click the Log Sources icon.
5. Click Add.
6. In the Log Source Name field, type a name for your log source.
7. From the Log Source Type list, select IBM Privileged Session Recorder.
8. From the Protocol Configuration list, select JDBC.
472
QRadar DSM Configuration Guide
9. Configure the parameters for the log source. These parameters are found in “JDBC protocol
configuration options” on page 17.
10. Click Save.
11. On the Admin tab, click Deploy Changes.
Related concepts:
“JDBC protocol configuration options” on page 17
QRadar uses the JDBC protocol to collect information from tables or views that contain event data from
several database types.
IBM Proventia
IBM Security QRadar supports a number of IBM Proventia DSMs.
Several IBM Proventia DSMs are supported by QRadar:
IBM Proventia Management SiteProtector
The IBM Proventia® Management SiteProtector DSM for IBM Security QRadar accepts SiteProtector
events by polling the SiteProtector database.
The DSM allows QRadar to record Intrusion Prevention System (IPS) events and audit events directly
from the IBM SiteProtector database.
Note: The IBM Proventia Management SiteProtector DSM requires the latest JDBC Protocol to collect
audit events.
The IBM Proventia Management SiteProtector DSM for IBM Security QRadar can accept detailed
SiteProtector events by reading information from the primary SensorData1 table. The SensorData1 table is
generated with information from several other tables in the IBM SiteProtector database. SensorData1
remains the primary table for collecting events.
IDP events include information from SensorData1, along with information from the following tables:
v SensorDataAVP1
v SensorDataReponse1
Audit events include information from the following tables:
v AuditInfo
v AuditTrail
Audit events are not collected by default and make a separate query to the AuditInfo and AuditTrail
tables when you select the Include Audit Events check box. For more information about your
SiteProtector database tables, see your vendor documentation.
Before you configure QRadar to integrate with SiteProtector, we suggest that you create a database user
account and password in SiteProtector for QRadar.
Your QRadar user must have read permissions for the SensorData1 table, which stores SiteProtector
events. The JDBC - SiteProtector protocol allows QRadar to log in and poll for events from the database.
Creating a QRadar account is not required, but it is recommended for tracking and securing your event
data.
Note: Ensure that no firewall rules are blocking the communication between the SiteProtector console
and QRadar.
72 IBM
473
Configuring a log source
You can configure IBM Security QRadar to poll for IBM SiteProtector events:
Procedure
1.
2.
3.
4.
Click the Admin tab.
Click the Log Sources icon.
Click Add.
In the Log Source Name field, type a name for your log source.
5. From the Log Source Type list, select IBM Proventia Management SiteProtector.
6. Using the Protocol Configuration list, select JDBC - SiteProtector.
7. Configure the following values:
Table 268. JDBC - SiteProtector protocol parameters
Parameter
Description
Log Source Identifier
Type the identifier for the log source. The log source identifier must be defined in
the following format:
<database>@<hostname>
Where:
v <database> is the database name, as defined in the Database Name parameter.
The database name is required.
v <hostname> is the host name or IP address for the log source as defined in the
IP or Hostname parameter. The host name is required.
The log source identifier must be unique for the log source type.
Database Type
From the list, select MSDE as the type of database to use for the event source.
Database Name
Type the name of the database to which you want to connect. The default
database name is RealSecureDB.
IP or Hostname
Type the IP address or host name of the database server.
Port
Type the port number that is used by the database server. The default that is
displayed depends on the selected Database Type. The valid range is 0 - 65536.
The default for MSDE is port 1433.
The JDBC configuration port must match the listener port of the database. The
database must have incoming TCP connections that are enabled to communicate
with QRadar.
The default port number for all options includes the following ports:
v MSDE - 1433
v Postgres - 5432
v MySQL - 3306
v Oracle - 1521
v Sybase - 1521
If you define a Database Instance when using MSDE as the database type, you
must leave the Port parameter blank in your configuration.
Username
Type the database user name. The user name can be up to 255 alphanumeric
characters in length. The user name can also include underscores (_).
Password
Type the database password.
The password can be up to 255 characters in length.
Confirm Password
474
Confirm the password to access the database.
QRadar DSM Configuration Guide
Table 268. JDBC - SiteProtector protocol parameters (continued)
Parameter
Description
Authentication Domain
If you select MSDE as the Database Type and the database is configured for
Windows, you must define a Windows Authentication Domain. Otherwise, leave
this field blank.
The authentication domain must contain alphanumeric characters. The domain
can include the following special characters: underscore (_), en dash (-), and
period(.).
Database Instance
If you select MSDE as the Database Type and you have multiple SQL server
instances on one server, define the instance to which you want to connect.
If you use a non-standard port in your database configuration, or blocked access
to port 1434 for SQL database resolution, you must leave the Database Instance
parameter blank in your configuration.
Table Name
Type the name of the view that includes the event records. The default table
name is SensorData1.
AVP View Name
Type the name of the view that includes the event attributes. The default table
name is SensorDataAVP.
Response View Name
Type the name of the view that includes the response events. The default table
name is SensorDataResponse.
Select List
Type * to include all fields from the table or view.
You can use a comma-separated list to define specific fields from tables or views,
if needed for your configuration. The list must contain the field that is defined in
the Compare Field parameter. The comma-separated list can be up to 255
alphanumeric characters in length. The list can include the following special
characters: dollar sign ($), number sign (#), underscore (_), en dash (-), and
period(.).
Compare Field
Type SensorDataRowID to identify new events added between queries to the table.
Polling Interval
Type the polling interval, which is the amount of time between queries to the
event table. The default polling interval is 10 seconds.
You can define a longer polling interval by appending H for hours or M for
minutes to the numeric value. The maximum polling interval is 1 week in any
time format. Numeric values without an H or M designator poll in seconds.
Use Named Pipe
Communication
If you select MSDE as the Database Type, select this check box to use an
alternative method to a TCP/IP port connection.
When a Named Pipe connection is used, the user name and password must be
the appropriate Windows authentication user name and password and not the
database user name and password. Also, you must use the default Named Pipe.
Database Cluster Name
If you select the Use Named Pipe Communication check box, the Database
Cluster Name parameter is displayed. If you are running your SQL server in a
cluster environment, define the cluster name to ensure Named Pipe
communication functions properly.
Include Audit Events
Select this check box to collect audit events from IBM SiteProtector.
By default, this check box is clear.
Use NTLMv2
Select the Use NTLMv2 check box to force MSDE connections to use the
NTLMv2 protocol when it communicates with SQL servers that require NTLMv2
authentication. The default value of the check box is selected.
If the Use NTLMv2 check box is selected, it has no effect on MSDE connections
to SQL servers that do not require NTLMv2 authentication.
72 IBM
475
Table 268. JDBC - SiteProtector protocol parameters (continued)
Parameter
Description
Use SSL
Select this check box if your connection supports SSL communication.
Log Source Language
Select the language of the log source events.
8. Click Save.
9. On the Admin tab, click Deploy Changes.
The configuration is complete.
IBM ISS Proventia
The IBM Integrated Systems Solutions®® (ISS) Proventia DSM for IBM Security QRadar records all
relevant IBM Proventia® events by using SNMP.
Procedure
1. In the Proventia Manager user interface navigation pane, expand the System node.
2. Select System.
3. Select Services.
The Service Configuration page is displayed.
4. Click the SNMP tab.
5. Select SNMP Traps Enabled.
6. In the Trap Receiver field, type the IP address of your QRadar you want to monitor incoming SNMP
traps.
7. In the Trap Community field, type the appropriate community name.
8. From the Trap Version list, select the trap version.
9. Click Save Changes.
You are now ready to configure QRadar to receive SNMP traps.
10. To configure QRadar to receive events from an ISS Proventia device. From the Log Source Type list,
select IBM Proventia Network Intrusion Prevention System (IPS).
For more information about your ISS Proventia device, see your vendor documentation.
Related concepts:
“SNMPv2 protocol configuration options” on page 40
You can configure a log source to use the SNMPv2 protocol to receive SNMPv2 events.
“SNMPv3 protocol configuration options” on page 40
You can configure a log source to use the SNMPv3 protocol to receive SNMPv3 events.
IBM QRadar Packet Capture
The IBM Security QRadar DSM for IBM QRadar Packet Capture collects events from an IBM Security
Packet Capture device.
The following table describes the specifications for the IBM QRadar Packet Capture DSM:
Table 269. IBM QRadar Packet Capture DSM specifications
Specification
Value
Manufacturer
IBM
DSM name
IBM QRadar Packet Capture
RPM file name
DSM-IBMQRadarPacketCapture-QRadar_versionbuild_number.noarch.rpm
476
QRadar DSM Configuration Guide
Table 269. IBM QRadar Packet Capture DSM specifications (continued)
Specification
Value
Supported versions
IBM QRadar Packet Capture V7.2.3 to V7.2.7
IBM QRadar Network Packet Capture V7.3.0
Protocol
Syslog
Event format
LEEF
Recorded event types
All events
Automatically discovered?
Yes
Includes identity?
No
Includes custom properties?
No
More information
IBM website (http://www.ibm.com/support/
knowledgecenter/SS42VS_7.2.8/com.ibm.qradar.doc/
c_pcap_introduction.html)
IBM QRadar Network Packet Capture knowledge center
(https://www.ibm.com/suppport/knowledgecenter/
SS42VS_7.2.8/kc_gen/toc-gen43.html)
To integrate IBM QRadar Packet Capture with QRadar, complete the following steps:
1. If automatic updates are not enabled, download and install the most recent version of the following
RPMs on your QRadar Console:
v DSMCommon RPM
v IBM QRadar Packet Capture DSM RPM
2. Configure your IBM QRadar Packet Capture device to send syslog events to QRadar.
3. If QRadar does not automatically detect the log source, add an IBM QRadar Packet Capture log
source on the QRadar Console. The following table describes the parameters that require specific
values to collect events from IBM QRadar Packet Capture:
Table 270. IBM QRadar Packet Capture log source parameters
Parameter
Value
Log Source type
IBM QRadar Packet Capture
Protocol Configuration
Syslog
4. To verify that QRadar is configured correctly, review the following tables to see examples of parsed
event messages.
The following table shows a sample event message from IBM QRadar Packet Capture:
Table 271. IBM QRadar Packet Capture sample message
Event name
Low level category
Sample log message
User Added
User Account Added
May 10 00:01:04 <Server>
LEEF: 2.0|IBM|QRadar Packet
Capture|7.2.7.255-1G
|UserAdded|cat=Admin msg=User
<Username> has been added
The following table shows a sample event message from IBM QRadar Network Packet Capture:
72 IBM
477
Table 272. IBM QRadar Network Packet Capture sample message
Event name
Low level category
Sample log message
Packet Capture Statistics
Information
<14>Mar 1 20:39:41 <Server> LEEF:
2.0|IBM|Packet Capture|7.3.0|1|^|
captured_packets=8844869^captured
_packets_udp=4077106^captured_
bytes_udp=379169082^total_packets
=9090561^captured_bytes=27938019
18^captured_bytes_tcp=2379568101
^compression_ratio=27.4^captured
_packets_tcp=4356387^oldest_packet
=2017-03-01T20:39:41.915555490Z^
total_bytes=2853950159
Related tasks:
“Adding a DSM” on page 4
If your system is disconnected from the Internet, you might need to install a DSM RPM manually.
“Adding a log source” on page 4
If a log source is not automatically discovered, you can manually add a log source to receive events from
your network devices or appliances.
Configuring IBM QRadar Packet Capture to communicate with QRadar
To collect IBM QRadar Packet Capture events, you must configure event forwarding to a remote syslog
server.
Procedure
1. Using SSH, log in to your IBM QRadar Packet Capture device as the root user.
2. Choose one of the following options to enable syslog.
a. Option 1: Open the /etc/rsyslog.conf file in a text editor such as vi:
vi /etc/rsyslog.conf
Then add the following line at the end of the file:
*.* @@<QRadar Event collector IP>:514
b. Option 2: Create the <filename>.conf file in the /etc/rsyslog.d/ directory, and then add the
following line to the file that you created:
*.* @@<QRadar Event collector IP>:514
3. Restart the Syslog service by typing the following command:
service rsyslog restart
The message logs are sent to the QRadar Event Collector and local copies are saved.
Note: