Understanding the UBA Risk Score

Posted on Updated on

The Use Behaviour Analytics (UBA) app is one of the most interesting QRadar apps. It allows you to detect internal threats, such as rouge employees and compromised accounts. The UBA works by observing the behaviour of each user and attributing a risk score for each person. For each UBA rule triggered, the risk score for the user is incremented. In this way you can track which users are performing risky (or abnormal) actions. Once a user surpass the company risk threshold, an offence is generated for the user. If a user stays a long period of time without having any risky action, then the risk is gradually decreased, which is called risk decay.

UBA Risk Score Example
UBA Risk Score – Example

To exemplify the risk score concept, take a look on the figure above. Let’s imagine that John access a suspicious website. This triggers an UBA rule that increase his user risk by 10 points. Then, John logs into a server and escalate his privileges to root for the first time. Again, an UBA rule is triggered and his risk is increased. After that, he does not present any risky behaviour for 8 hours, so his score slowly starts to decay. Eight hours later, John dumps an entire SQL database, increasing his risk again. After that, he SSH into a server in Russia, which also increases his score. At this point, his risk is higher than the company threshold risk, so an offence is generated for John. After that, even if John’s risk decay, his offence will still be open.

This example shows the real value of the UBA app, since each small action is not enough for a traditional rule-based offence. However the combined actions are indeed suspicious and the UBA app was able to detect it.

If you want to learn more about the UBA and other QRadar apps, check this online course in which the main QRadar apps are presented.

Using RSyslog to monitor and forward log files to QRadar

Posted on Updated on

Although it is possible to use SSH/SFTP/SCP to collect log files with QRadar, that option may not be the most appropriated for every company. Those collection methods, called pull-collection, requires an extra account in the system (so QRadar can login to collect the log). Moreover, the pull-collection methods collect the logs in an interval (usually, 5 minutes), meaning that logs may take up to 5 minutes to arrive in QRadar.

One alternative for collecting logs stored in files is using the rsyslog service, which is already pre-installed in the majority of the RedHat and CentOS versions. Those services are able to monitor a log file and forward each new log line to QRadar.

The first step is to check which version of rsyslog you have:

$ rsyslogd -version

 

If you have the newer rsyslog versions (7.x or above), then edit the /etc/rsyslog.conf file and add the following lines:

#### Load the file reader module ####
module(load="imfile" PollingInterval="10")

#### Configure to read a file ####
input(type="imfile" File="/var/log/logfile1.log" 
Tag="LogFileName:" 
StateFile="/var/spool/rsyslog/state-LogFileName" 
Severity="info" 
Facility="local3")

#### Forward the logs to QRadar
local3.info @@qradar_ip_address:514

 

If you have the legacy versions (5.x or below), then edit the /etc/rsyslog.conf file and add the following lines:

##### Load file reader module #######
$ModLoad imfile

##### Configure to read a file ########
$InputFileName /var/log/logfile1.log
$InputFileTag LogFileName:
$InputFileStateFile state-LogFileName
$InputFileSeverity info
$InputFileFacility local3
$InputRunFileMonitor  

##### Set the file monitoring for every 10 seconds ######
$InputFilePollInterval 10

##### Forward logs in local3.info to Qradar #######
local3.info                     @@qradar_ip_address:514

 

After the changes being done on the rsyslog.conf file, all you have to to is restart the service:

$ systemctl stop rsyslog
$ systemctl start rsyslog

To check if the service was started without errors, check the status by:

$ systemctl status rsyslog

If everything worked well, your service should be started without any errors.

One very common issue is when the rsyslog is not able to access the log file. This usually happens due to the SELinux service, which blocks access to sensitive files on the machine. To check if that is the case, temporarily disable the SELinux by using the following command:

$ setenforce 0

After that, restart rsyslog and check if the error persist. If it the issue is solved, then all you have to do is adding an exception to your SELinux to allow rsyslog to access the specific log file.

Using Syslog-ng to monitor and forward log files to QRadar

Posted on Updated on

Although it is possible to use SSH/SFTP/SCP to collect log files with QRadar, that option may not be the most appropriated for every company. Those collection methods, called pull-collection, requires an extra account in the system (so QRadar can login to collect the log). Moreover, the pull-collection methods collect the logs in an interval (usually, 5 minutes), meaning that logs may take up to 5 minutes to arrive in QRadar.

One alternative for collecting logs stored in files is using the syslog-ng service, which is already pre-installed in the majority of the newer Linux releases. This service can be used to monitor a specific file (in smaller intervals, such as 10 seconds) and in case of any changes, send the logs to QRadar. The configuration is fairly simple, here are the steps:

  1. Check if the syslog-ng is installed:
    $ service syslog-ng status

    if not installed, install using:

    $ apt-get install syslog-ng
  2. Edit the syslog-ng configuration file (usually at: /etc/syslog-ng/syslog-ng.conf), inserting the following lines:
    source s_logfile1 {
    file("[[[PATH_TO_FILE]]]" follow_freq(10) flags(no-parse));
    };
    
    destination d_qradar { 
    tcp("[[[QRADAR_COLLECTOR_IP]]]" port(514) template("<$PRI>$DATE $HOST $MESSAGE\n"));
    };
    
    log { 
    source(s_logfile1); 
    destination(d_qradar);
    };

    The first line adds a “file monitoring” rule to the specific file. You can update the file monitoring frequency (in seconds) by changing the follow_freq parameter.
    The second line adds a syslog destination, if you already had syslog-ng configured for another log monitoring, this line may not be necessary.
    The third line adds a logging action from the source file to the destination syslog recipient.

  3. Restart the syslog-ng service
    $ service syslog-ng restart
  4. Done! You can now check on QRadar if logs are coming.
  5. If you need to troubleshoot, you can check the syslog-ng logs by using the following commands:
    $ syslog-ng
    $ service syslog-ng status

 

QRadar 7.3.1, should you upgrade?

Posted on Updated on

The IBM QRadar 7.3.1 was released in the beginning of 2018. However, several companies still using past versions of the tool. One of the most asked question every time a new release is out is “Why should I upgrade?”. To answer this question, I compiled a list of interesting improvements in the past four major releases. This list was based on the official IBM release notes and several QRadar open mics.

 

QRadar 7.2.7

  • Indexing offence by any field, including custom fields
  • Customize columns on log activity tab, create custom layouts
  • See average EPS for each log source, on admin tab and reports
  • Support of if/then/else and case statements on AQL queries
  • Release of a software version of QRadar
  • All logs and flows are compressed when stored
  • Paging on searches (improving search performance)
  • Change network interface configuration through the web console (IP address, interfaces, bonding, etc)
  • Change firewall rules through the web console
  • New APIs for QVM and incident retrieval

 

QRadar 7.2.8

  • Resource restrictions for specific users (searches)
  • X-Force is already included in the QRadar subscription
  • Reference sets are now domain specific, each client has their own domain set
  • Data retention buckets now can be per tenant
  • Offence assignment is improved and offence screen support tenants
  • Web interface for DSM editor
  • AQL support nested queries
  • IBM Security Master Console now included with qradar. Provides a holistic view of the environment

 

QRadar 7.3.0

  • EPS/FPM is now a shared pool that can be distributed across devices
  • QRadar now runs on RedHat 7.3, which allows LVM for partition management. It also uses the SystemD for service management, meaning that you have to use “systemclt” to manage things in the system, like service start/stop
  • Activation keys are not necessary anymore. You select the type on a list
  • No more limit on log source numbers. The limit is by EPS
  • Tenant management is improved, the tenants can create their own reference sets and custom properties.
  • AQL now supports advanced statements, such as session queries, bitwise operators and functions.
  • Apps now can be outsourced to an external AppNode
  • New interfaces for remote networks and remote services
  • Java deployment editor doesn’t exist anymore, all device management happens through the admin interface

 

QRadar 7.3.1

  • New login screen, new logos and design.
  • New app called Pulse, very interesting dashboards, provide “SOC Views” and fancy graphs
  • Custom properties can now be based in AQL queries
  • Now it is possible to identify if QRadar inverted the flow in the network activity tab
  • Minor patch updates does not cause downtime anymore
  • Event collection now runs as a separated service, meaning you can restart just the event collection in a device
  • New left side menu, allows creating shortcuts and favourites
  • Browser-based notifications
  • New “QRadar Deployment Intelligence App” provides a lot of system health information
  • Possibility to enforce password policy
  • New “QRadar Assistant App” comes already with QRadar. It gives tips on how to use the tool, suggest apps, and provide a live feed of the IBM Security Support twitter.
  • Log source auto-detection can now be controlled, allowing only certain types of log sources to be auto-detected
  • Auto-discovery of event properties.
  • New offering of a Data Storage solution for QRadar, this allows to some of the logs to be collected only and not parsed by the pipeline (saving EPS). This can be interesting if one of the devices is on debug mode.
  • Support to JSON formats in log source extension parsing
  • AQL can now be targeted by event processor, improving search time
  • Geolocation is improved. Now you can manually enter the geolocation of IPs on the network hierarchy, so maps are correct.
  • New App Developer Center, so people can develop their own apps with the IBM SDK
  • Rules can now be triggered by distance on geolocation. “If a traffic comes from more than 100km from here”..
  • The vulnerability manager and risk manager are completely redesigned.
  • The incident forensics module supports packet capture and more advanced features

Investigating Ransomware Infections with QRadar

Posted on Updated on

Ransomware is the nightmare of most of system administrators and security officers. It’s an emerging threat and the trend unfortunately is upward: more and more companies are being hit by ransomware, from small shops to large corporations.

In a previous post we discussed on how to use your QRadar to detect ongoing ransomware infections. In this post we will be discussing how to investigate ransomware attacks using your SIEM.

You may be wondering, “why bothering if it’s too late?”. It is extremely important to understand the vectors exploited and the timeline of the attack so we can avoid future infections and even stop current ransomware attacks.

Here’s a list of items to check using your QRadar:

  • Anti Virus logs: That seems the most obvious thing to check. We can try to identify if the antivirus detected the threat and which was the first computer affected (the “entry point”). We can also check if the users infected had turned their antivirus off or if the ransomware was not even detected by the antivirus (a potential zero-day).
  • Network Traffic: The majority of the ransomware strains communicate to a Command & Control server for two main reasons: synchronize the malware data, and in some cases, exfiltrate sensitive data. You can use your QRadar to find if your machines are connecting to a new external IP. For example, if you had all your HR laptops infected, and in the same period you observe all the laptops connecting to a new specific IP, that’s most likely the command and control server. You can blacklist this IP in your firewalls and create custom rules on QRadar to alert in case new machines trying to connect to this IP.
  • Windows Logs: The windows logs can provide a lot of useful information
    • Network Connection Logs: You can try to identify the command and control server by the windows network logs. Those logs can also indicate an anomalous number of connections in a port. For example, the latest ransomware threats were exploiting a vulnerability in the SMB protocol, so if you see an unusual number of connections on port 139 or 445, that may indicate a ransomware proliferating into your network. If that’s the case, you can disable the vulnerable service or block the connections on the windows firewall.
    • File Modification Logs: As discussed in this previous post an ongoing ransomware infection generates a lot of “file update” logs. If you detect an anomalous number of file update logs, that may indicate a ransomware threat.
    • USB Logs: Most of the ransomware attacks spread through emails and webpages, but they can also be delivered through infected USB sticks. If you know the approximate time of the infection, you can check for USB logs, looking for inserted devices. If the source is a USB stick, contact the user and make sure other people do not do the same.
  • Email Logs: Most of the ransomware strains use an email phishing campaign as entry point in a company. Check your email logs (example: Microsoft Exchange logs) for suspicious attachments sent to internal users. If you find the first person infected, you can find the sender and prevent other people of receiving similar emails and getting infected.
  • HTTP Logs: Ransomware can also be distributed through malicious websites. If you have your HTTP proxy logs, check for unusual downloads or unusual websites. If you find the source of the ransomware it is easy to block the access and avoid that other users get infected.

Having a proper incident investigation will help you to reduce the impact of an ongoing ransomware attack and may help you to prevent future attacks.

How do you investigate your ransomware attacks? Share with us in the comments.

Monitoring Software-as-a-Service (SaaS) cloud solutions with QRadar

Posted on Updated on

One of the big advantages of having a Software-As-A-Service (SaaS) solution is the fact you don’t need to worry about infrastructure issues, such as patching, network availability, and etc. Also, most of the companies assume that all the security aspects of the solution will be handled by the vendor. Indeed, the vendor is (or should be) responsible for ensuring their system is secure, but it’s important to note that we should still monitor the SaaS solution for hacking attempts, which can be done through QRadar.

Picture this: imagine you have your website on wordpress, you pay wordpress as a service so you don’t need to worry about patching or updates. In theory, the wordpress team also monitors if someone tries to perform an attack against your site (for example, a SQL injection). But let’s say a malicious actor finds out the password of one of your wordpress users and creates a backdoor account for later exploitation. It wouldn’t be flagged by the wordpress security team (since it’s just a new user being created). That’s where QRadar can add value. If you integrate your wordpress with your QRadar solution, you would be able to generate an alert to your system administrator when a user is created or even correlate this event with other events such as pages being modified.

The easiest way to integrate your SaaS with QRadar is through email alerts from your SaaS solution. Let’s take the WordPress example and put it into a step-by-step:

  • Install the WordPress “Security Audit log” plugin
  • Create a mailbox to receive the alerts
  • Create a script that reads your mailbox and saves into a file. For example, you can modify this script to achieve that.
  • Create a custom DSM parser that interprets the file generated by the script above.
  • Create a log source on QRadar that monitors the file created by the script mentioned on step three. Use the custom DSM on this log source.

The implementation may require some time in the first time, but after setting up your first SaaS it will be trivial to set up the second one (since you will already have the mailbox set up and the script that reads the file). The same step by step can be adapted for a number of other SaaS services, such as: Dropbox, Gmail, Office365, Salesforce, AWS Cloudtrail and CloudWatch, etc…

Some of the events that can be interesting for us: New accounts created, change on security settings, login out of business hours, bruteforce attacks, configuration changes, etc.

Monitoring your SaaS solutions will put you one step ahead, ensuring that even applications on the cloud are being monitored and secure. Remember, even the server not being in your datacentre, the data in a SaaS application still yours.

 

Monitoring Cloud Servers with QRadar

Posted on Updated on

Cloud computing is an inevitable upward trend. Companies are looking for all the benefits cloud computing, such as cost effectiveness and scalability, but they may be neglecting the need of event monitoring in a cloud environment.

Configuring a SIEM solution to collect events from servers in a cloud environment may be simpler than you think. Cloud servers are still servers, meaning that they produce logs and events as any in-house server. In this post we will be discussing few strategies and architectures to consider when planning a QRadar implementation with servers in the cloud.

The first scenario is when you have just few servers in the cloud (less than 15% of your environment, or less than 500EPS coming from the cloud). A easy approach for this scenario can be simply configuring your cloud servers to send logs to your existing in-house QRadar collector (Figure 1). This can be accomplished by using a VPN between your cloud environment and your datacentre, or by configuring your firewalls to allow your cloud servers to send logs directly to your in-house collector. The benefits in this case are the fact that is a very easy setup and there’s virtually no costs. The downside on this design is that if your server generate a high number of events, your firewall/VPN could be overloaded.

Figure 1: Cloud servers sending logs directly to internal SIEM collector
Figure 1: Cloud servers sending logs directly to internal SIEM collector

The second scenario is when you have a substantial amount of servers in the cloud (between 30%-40% of your environment, or less than 5000 EPS). In this case, if you try to send all your events directly through a firewall or VPN you may overload the border network devices of your environment. The recommended approach in this case would be implementing a virtual collector/processor in your cloud environment (Figure 2). The cloud servers would send logs to your virtual collector/processor, which will parse the data locally and compress it before sending to the in-house SIEM collector.  This architecture benefits from the fact that you will have an increased EPS capacity. Also, if your VPN dies or if the network is unstable you don’t lose events due to the fact the collector buffers the logs locally. In other hand, this architecture will have an extra cost (the additional collector) and, even with the traffic being compressed, it still may affect your firewall/VPN performance in case you’re monitoring a large quantity of servers.

Figure 2: Virtual collector in the cloud.
Figure 2: Virtual collector in the cloud.

The third scenario is when most of your servers are in the cloud. In this case, a good approach would be having QRadar collectors (or even your whole QRadar infrastructure) deployed on the cloud, as seen on Figure 3. In this way, your border network devices will not be overloaded by logs sent from cloud servers to your internal SIEM. A similar approach would be having “QRadar as service”, which is a service from IBM where all the SIEM infrastructure is taken care by the IBM team. The advantages of having SIEM as a service is that you don’t need to worry about the SIEM maintenance and there’s little to none setup effort. The disadvantages is that your data will be stored in the IBM cloud environment, which for some companies may not be adequate.

Figure 3: Cloud SIEM solution or QRadar as a Service Architecture.
Figure 3: Cloud SIEM solution or “QRadar as a Service” Architecture.

Those are the three most common approaches when monitoring cloud servers with a SIEM solution. It is important to remember that each case is a case, meaning that each company should analyse their current and future environment before designing a SIEM implementation. You may find that a combination of the presented approaches may suit best your needs. The most important thing is remembering that monitoring servers in the cloud is as important as monitoring in-house servers.