Qradar Ahnlab

5 KASPERSKY LAB PROVIDES BEST IN THE INDUSTRY PROTECTION. 5 0% 20% 40% 60% 80% 100% 20 40 60 80 100 N of independent tests/reviews ScoreofTOP3places Bitdefender Sophos G DATA Symantec F-Secure Intel Security (McAfee) Trend Micro Avira Avast BullGuard AVG ESET AhnLab Microsoft Panda Security In 2014 Kaspersky Lab products participated in 93. QRadar can receive logs from systems and devices by using the Syslog protocol, which is a standard protocol. Supported DSMs can use other protocols, as mentioned in the Supported DSM table. You can try to configure third-party applications to send logs to QRadar through the Syslog protocol.

Healthcare IT (HIT) Security is garnering greater attention among healthcare organizations, though most HIT execs indicate they are not fully prepared. In fact, a recent report by the SANS Institute indicates that healthcare organizations are being compromised at an 'alarming' frequency. Given the hefty average cost of an incident coming in at a whopping $800,000, and the fact that over 60% of healthcare organizations reported some type of security breach in 2013, it's not too surprising that a new urgency is being given to improving security.

This is no small endeavor though. Long gone are the days when putting in place a firewall and an anti-virus solution were sufficient to protect your organization. Today's CISO has to concern herself with security across many fronts, such as:

• Are our network devices appropriately configured and not using factory default accounts?
• Has anything new been added to the network, or changes made to existing assets that could increase our risk exposure?
• Are we seeing anything suspicious among virtualized server or communication among these systems?
• Are our mobile devices secure?
• Do our servers and laptops have the current security patches and updates to our antivirus solution deployed?
• Is any abnormal traffic occurring on the network, either by volume or abnormal protocols from specific endpoints?
• Are existing web applications under attack?
• Are new web applications under development hardened and safe from common attacks?
• Is communication taking place with known malevolent external sites?
• Are unauthorized accounts, including internal staff, attempting to increase account privileges or making repeated failed login attempts?
• Is PHI being inappropriately accessed or transmitted?
• Does anything in the thousands of log files generated from these systems indicate something is amiss?

It's a daunting challenge, with a significant penalty in fines, loss of customer trust and organizational reputation at risk should something be missed. In many cases, organizations have implemented point solutions to address some of these individual challenges. However, keeping tabs on all of these individual security solutions and prioritizing where the most significant risk lies can be overwhelming. Similarly doing forensics to identify the root cause of an incident to prevent a recurrence is equally challenging for HIT security personnel whose departments are traditionally underfunded (a recent HIMSS survey showed 49% of respondents spent less than 3% of overall IT budget on security). On top of all of this, security teams must be able to do the reporting required for regulations such as HIPAA, PCI and SOX.

If any of these challenges sound familiar, you should take a look at security intelligence and SIEM solutions like IBM's QRadar. QRadar has been the leading SIEM solution in Gartner's magic quadrant for the past 5 years. It provides a customizable role-based dashboard prioritizing security issues that need to be addressed, and providing extensive capabilities to drill down and investigate suspicious activities. It can receive data from numerous endpoints and security solutions, but it also includes a rich set of capabilities for:

• Network traffic monitoring, both physical and virtual flows, including layer 2, 4 and 7 data
• Flow analysis, including correlation and behavioral analytics
• Log file monitoring and analysis
• Risk assessment, including network discovery and risk simulation
• Vulnerability assessment, including device configuration discovery

QRadar addresses many requirements of the HIPAA Security Rule such as:

• Comprehensive auditing of all transactions moving across a healthcare organization's network and real-time access to months of activity for rapid response to incidents (§164.312 (b)).
• Continuous tracking of inappropriate internal activity such as insider attacks, stealthy scans and inappropriate attempts to access EPHI servers (§164.308 (a) (1)).
• Detection of new and unidentified threats, such as new worms or Trojans, that pass undetected through signature-based virus checking software and appliances (§164.308 (a) (5)).
• Alerts for violations of internal policies, such as non-compliant usage of a Covered Entities (CE's) applications (§164.308 (a) (4)).

QRadar includes the following pre-configured report templates to automate the reporting for these and other compliance needs:

Qradar Ahnlab Log

• Monthly HIPAA 164.312(a)(1) – 4 / 164.312(d) – 3 User Accounts Additions by Admin
• Daily HIPAA 164.308(a)(6) – 3 Incident Response Summary
• Network Traffic Volume
• Daily Top Targeted IPs by VA Risk
• Weekly Top Attacking Hosts
• Monthly Top Targeted Hosts
• Remote Access Activity Summary
• Daily HIPAA 164.308(a)(4) – 1 / 164.312(e)(1) – 1 Internal Network to Internet Traffic
• Weekly HIPAA 164.308(a)(8) – 3 / 164.308(1)(8) – 5 Vulnerability Report
• Monthly HIPAA 164.312(e)(1) – 2, 3, & 4 Traffic to Trusted Segments
• Daily HIPAA 164.308(a)(4) – 1 / 164.312(c)(1) – 2 Traffic Summaries (Details)
• Monthly Top Attacking Hosts
• Daily Top Targeted IPs
• Weekly Top Targeted Hosts
• Daily Top Targeted Hosts
• Top Users by Remote Access Activity
• Weekly HIPAA 164.308(a)(6) – 3 Incident Response Summary
• Daily Top Attacking Hosts
• Weekly Top Virus Sources and Destinations
• Daily Top Security and Policy Offenses
• Weekly HIPAA 164.308(a)(4) – 1 / 164.312(c)(1) – 2 Traffic Summaries (Details)
• Weekly HIPAA 164.308(a)(4) – 1 / 164.312(c)(1) – 2 Traffic Summaries (Time Series)
• Weekly HIPAA 164.312(e)(1) – 2, 3, & 4 Traffic to Trusted Segments
• Weekly Top IPs for Blocked Spam • Daily HIPAA 164.308(a)(4) – 1 / 164.312(c)(1) – 2 Traffic Summaries (Time Series)
• Monthly Top IPs for Blocked SPAM
• Daily Top Virus Sources and Destinations
• Daily HIPAA 164.312(e)(1) – 2, 3, & 4 Traffic to Trusted Segments from Untrusted Segments
• Daily Top IPs for Blocked Spam
• Network Traffic Volume

Unlike other solutions in this space, QRadar's virtual or physical appliances are straightforward to deploy, with some implementation projects completed in as little as 3-5 days. CDW's internal IT team selected QRadar to secure our own environment.

Need to learn more? Post your questions below and reach out to your account manager to arrange a deep dive.

Log sources using syslog are very easy to test in QRadar. However, there are some device types that have only polling type (or file based) protocols as configuration options. Among others, Amazon AWS, IBM BigFix, IBM MaaS360, Cisco IPS are such examples. For these, firing a syslog event with the same format and the same logsourceid in the header is useless, because the log source configuration will not match.

The following workaround can be applied to generate test syslog events for these log sources. This is to be used only in test environments (you don't want to litter your production system with test events anyway).

Go to your console and get a psql connection:

The table sensordeviceprotocols contains the log source type and protocol associations. We add a row to this table such that our tested log source accepts syslog. This table works with identifiers, so you need to find the id of your log source type. For this, use the sensordevicetype table and look for the id column. The column devicetypedescription will help you find the right row. E.g. to find the MaaS360 log source:

This query returns

so we know the id we look for is 361. We also need the id of the syslog protocol, which is 0 (you can find it out from the table sensorprotocol).

Having this we insert a new row:

Qradar Ahnlab 7

Here, the third value is just a unique identifier, whereas the last indicates that this is undocumented.

Now, if you go back to QRadar UI, and try to add a new log source of your selected type, in the drop-down menu a new item appears: Syslog (Undocumented). Select this, and all you need is to provide a logsourceid and save the new log source. You must use the same id as you provided here in your syslog header when sending in your test events.

After these changes, you need to restart the eventprocessing service. I did

but maybe this is an overkill.

Hint: If you want that the test events look like they come from an existing real log source of the same type, you need to create a new log source of the same type, but with the new Syslog (Undocumented) protocol configuration. When creating this, use the same logsourceid as you have in the real log source and make sure that the parsing order prefers the real log source. This way the test log source will never receive any events, all your test events will seem to belong to your original log source.

Log sources using syslog are very easy to test in QRadar. However, there are some device types that have only polling type (or file based) protocols as configuration options. Among others, Amazon AWS, IBM BigFix, IBM MaaS360, Cisco IPS are such examples. For these, firing a syslog event with the same format and the same logsourceid in the header is useless, because the log source configuration will not match.

The following workaround can be applied to generate test syslog events for these log sources. This is to be used only in test environments (you don't want to litter your production system with test events anyway).

Go to your console and get a psql connection:

The table sensordeviceprotocols contains the log source type and protocol associations. We add a row to this table such that our tested log source accepts syslog. This table works with identifiers, so you need to find the id of your log source type. For this, use the sensordevicetype table and look for the id column. The column devicetypedescription will help you find the right row. E.g. to find the MaaS360 log source:

This query returns

so we know the id we look for is 361. We also need the id of the syslog protocol, which is 0 (you can find it out from the table sensorprotocol).

Having this we insert a new row:

Qradar Ahnlab 7

Here, the third value is just a unique identifier, whereas the last indicates that this is undocumented.

Now, if you go back to QRadar UI, and try to add a new log source of your selected type, in the drop-down menu a new item appears: Syslog (Undocumented). Select this, and all you need is to provide a logsourceid and save the new log source. You must use the same id as you provided here in your syslog header when sending in your test events.

After these changes, you need to restart the eventprocessing service. I did

but maybe this is an overkill.

Hint: If you want that the test events look like they come from an existing real log source of the same type, you need to create a new log source of the same type, but with the new Syslog (Undocumented) protocol configuration. When creating this, use the same logsourceid as you have in the real log source and make sure that the parsing order prefers the real log source. This way the test log source will never receive any events, all your test events will seem to belong to your original log source.

Here is the list of log sources for which this workaround should come handy: Best free torrent.

• AhnLab Policy Center APC
• Akamai KONA
• Amazon AWS CloudTrail
• Box
• Cisco Cloud Web Security
• Cisco Identity Services Engine
• Cisco Intrusion Prevention System (IPS)
• Fasoo Enterprise DRM
• Flow Classification Engine
• HP Tandem
• IBM BigFix
• IBM BigFix Detect
• IBM Informix Audit
• IBM Fiberlink MaaS360
• IBM Lotus Domino
• IBM Privileged Session Recorder
• IBM Proventia Management SiteProtector
• IBM Proventia Network Intrusion Prevention System (IPS)
• IBM Security Identity Governance
• IBM Security Identity Manager
• IBM Security Privileged Identity Manager
• IBM SmartCloud Orchestrator
• Juniper Networks AVT
• Juniper Security Binary Log Collector
• Kisco Information Systems SafeNet/i
• McAfee Application/Change Control
• Microsoft Endpoint Protection
• Microsoft Operations Manager
• Microsoft SCOM
• Microsoft Windows Defender ATP
• Netskope Active
• ObserveIT
• Open LDAP Software
• OpenStack
• Oracle Audit Vault
• Oracle BEA WebLogic
• Oracle Enterprise Manager
• Oracle Fine Grained Auditing
• Pirean Access: One
• Resolution1 CyberSecurity
• Riverbed SteelCentral NetProfiler
• Riverbed SteelCentral NetProfiler Audit
• Salesforce Security Auditing
• Salesforce Security Monitoring
• Seculert Seculert
• SOAP Webservice-based messages, pre-normalized
• Sophos Enterprise Console
• Sophos PureMessage
• Sun ONE LDAP
• Sybase ASE
• Symantec Critical System Protection
• Symantec System Center
• Trend Micro Control Manager
• Trend Micro Office Scan
• VMware vCloud Director

The method above was tested on version 7.3.2., table structure might change without notice. You lose your support if you modify psql tables.