Tag: SIEM

Qradar Support

The MSS now fully supports the Qradar SIEM from IBM in CEF log format. Qradar is an excellent SIEM but requires classifying and mapping every event type it sees to an internal category. Qradar comes with a large number of common IDS rules (~50,000) already classified but not mapped. Besides having to manually map all these rules Qradar-MSS users would also need to continuously create additional Qradar IDs (Qids) to map to the much larger rule set used by the MSS (which changes daily). All this required a mechanism to update Qradar dynamically as new rules are published. With this update released today, no manual classification or mapping operations are necessary.

The MetaFlowsCEF log source automatically parses the 13 event types generated by the MSS and presents them in the Qradar default view. All MSS events are automatically mapped to new or existing Qids without any user manual operations. This makes the Qradar SIEM much easier to use.

To setup Qradar for the MSS perform the following steps:

    1. Download the MetaFlowsCEF log source https://nsm.metaflows.com/sensordevicetype-search-ContentExport-20180809173340.zip to the Qradar box
    2. Import it with the command /opt/qradar/bin/contentManagement.pl -action import -f sensordevicetype-search-ContentExport-20180809173340.zip
    3. Verify the import was successful and assign the MetaFlows sensors to this log source. Also make a note of the log source ID assigned by Qradar to the MetaFlowsCEF log source (something like 400[1-9]).
    4. Edit the file mss.sh of all sensors and add the line export QRADAR=1.
    5. On one of the sensors you designate as the main Qradar updater, create the file /nsm/etc/qradar.ini to allow the sensor to communicate to the Qradar server (see an example below). Also add the line export QRADARLOGSOURCEID=<logsourceid>; where <logsourceid> is the number you noted in step 3. Probably something like 4001, or 4002, etc..
    6. Restart the sensors

Sample qradar.ini:

[DEFAULT]
certificate_file = /nsm/etc/qradar.pem
auth_token = f3f1201b-3562-46d1-9b8b-9a1623870000
server_ip = 123.52.215.20
Where:
/nsm/etc/qradar.pem is a copy of the file located at /etc/httpd/conf/certs/cert.cert on your Qradar box
auth_token is obtained from your QRADAR application
server_ip is the IP address of your Qradar box.

The Qradar updater sensor will automatically add to Qradar new IDS rules added by the sensor’s rule update (which will be the same across all your sensors). This will happen through the Qradar API in the background as the sensor is running. The first time, the updater is run, it will have to catch up with about 50,000 definitions; so it will take many hours. Subsequent updates will take less time.

After each Qradar update, the email associated with the sensor owner will receive a summary of the update process.

Qradar integration is a bit complex; so do not hesitate to contact support@metaflows.com for any questions.

 

Mine for Syslog

Data-Mining-2Just about any device in your network generates syslog events. That is why we now mine all syslog messages appearing in your network weather or not you know of their existence.

The software should be able to understand just about any type of syslog format now (while we continue to refine our parsing). If we do not understand it, we still provide it to you as a generic “unix” type. We set up a default minimum syslog priority of 4 (Warning) that can be customized to adjust the verbosity of the reporting to your preference. Most sites would want to stay at 4 otherwise it is like a fire-hose in most cases.

We are now collecting enough syslog data to also start correlating them with other types of events (IDS, Service Discovery, User Discovery, File Carving, NetFlow, etc.) in the cloud. This a very tall order since syslog data is usually quite bland and verbose. There might be some needles in there; but we definitively will need to use our COR language to find them. Let us know if you have a good heuristic; we will be glad to test it.

For now, besides a simple audit-trail, the syslog messages can also be used for trend analysis and somewhat reinforce what the other parts of our multifunctional system are saying. So, even though they do not provide a smoking gun, they are nice to have around.

 

Lions, Tigers, and DDoS Attacks, Oh My!

DDoS attacks are not new, but they are ever evolving. This article takes a look at the Greatest Hits of 2013 so far and breaks them down.

5 Notorious DDoS Attacks in 2013 : Big Problem for The Internet of Things

 

Are you concerned about DDoS attacks? Well you should be. The MSS is working hard to stop them in your network. Find out how.