Second part of QRadar 7.3.2 features

As promised in the last month, please find the second part of the QRadar 7.3.2 features article. As for today (mid of February), a new version is still not available for public, but I could see another new build generated in this month (20190201201121) and I believe we are days only from issuing a new version. So, let’s list  a few of QRadar 7.3.2 features, not mentioned in the previous article:

DrQ: Command Line Healthcheck

DrQ is a great tool for QRadar admins, who are responsible for the day-to-day work on the system. Admins looking after the health of the system, its updates, and investigating performance and availability for SOC analysts will find new support for dealing with any problems which could appear on QRadar. This script can run on the command line manually or integration into custom scripts is not a problem, too. As a result, of course, it can run on cron and start at any suitable time for admins.DrQ

It is lightweight problem detection and it is amalgamated into a library of checks developed and maintained by support, so there is not a lot of configuration or maintenance necessary. It checks on the specific managed host, not on the whole deployment, so use “all_servers.sh” script if you want to test each component in deployment.  DrQ installs and updates own library on each managed host via autoupdates but installation rpms packets are in 7.3.2 version. You might be surprised, but it was actually already partly provided… Yes, you can find already in your system a cliniq file, which is part of this new tool. It will consist of three elements:

  • drq – engine for the health check
  • diagnostiq – the initial rollout of tests which the engine runs
  • cliniq – runs drq and all diagnostic tests in single command line functionality

DrQ configuration file located in /etc/drq/config.d/*.toml file can be customisable as well as each test file found in /opt/ibm/si/diagnostiq/* in JSON standard. External developers can add own functionality to modules installed on your appliance. This feature will be available in future, but we can be sure that DrQ is very promising for every admin. DrQ is one of the most useful QRadar 7.3.2 features.

SAML 2.0 Authentication

Another of QRadar 7.3.2 features is SAML stands for Security Assertion Markup Language. It is standard for exchanging authentication and authorization data between security domains. SAML standard based on XML protocol uses security tokens, which containing assertions and passing information about an end user between an authority and a Service Provider. The standard enables web-based, single sign-on (SSO) across the domain, which reduces the necessity of multiple authentication tokens for each user. From QRadar 7.3.2 support for this standard lets many customers, who already use this standard, for seamless integration with their existing servers when they initiated single sign-on or single logout. However, QRadar does not support multiple IDPs at the same time.

  1. Having an existing SAML 2.0 Identity Provider (IDP),  you need only upload the IDP metadata and configure service provider parameters and authorization parameters.
  2. After that optionally you can upload customer’s x509 certificates, if not using the pre-installed QRadar_SAML certificates.
  3. Create local users if selecting local authorization.
  4. Deploy.
  5. Download the QRadar SP SAML metadata file.
  6. Download QRadar SAML certificate’s root and intermediate certificates and CRLs if selecting the pre-installed certificate.
  7. Configure the IDP server with the QRadar metadata file and certificate files.
  8. Logout QRadar and re-login.SAML authentication

If you would run into troubles with SAML authentication, then you can restore QRadar to use the default system login with the following steps. Edit the /opt/qradar/conf/login.conf file and change ModuleClass=com.q1labs.uiframeworks.auth.SAMLLoginModule
to
ModuleClass=com.q1labs.uiframeworks.auth.UserConfLoginModule
Clear the browser cache and log in as an Admin user. After you complete your investigation, change the attribute back to SAMLLoginModule and clear the browser cache again.

Translating to AQL

Among other QRadar 7.3.2 features, this one is really exciting. It is quite simple in general, but important for these customers who are not literate with Advanced Query Language (AQL). Having saved search (for Events or Flows), with one click button, you can have translated it to AQL. Based on the copy to clipboard, you can paste this query in Advanced Search option after modifications, store more definitions of searches, keep them saved in a separate file or share with others.

This feature let all QRadar users be more proficient in AQL and use this language more frequently without too many mouse clicks.

Another great feature is adding support to API (in version 10) for users’ accounts. Now, there are following fields available

/config/access/users
/config/access/users/{id}
/staged_config/access/users
/staged_config/access/users/{id}

This introduces the following changes

  • A new table: user_settings introduced
  • Some columns from the user’s table have been migrated to the user_settings table.
  • users table is staged, but user_settings is not staged
  • user_settings contains user details that do not require a deploy to change.

Audit logging remains the same and user’s login in or log out are available in this audit.log.

There are still more features (in QRM and QVM), which I still didn’t describe. I hope eventually it will happen.

Terms and Conditions