IBM QRadar SIEM

​

What Oleria discovers

• Users - every deployed QRadar user, with username, email, user role, security profile, and, on multi-tenant Consoles, tenant. Oleria also shows:
  • Status - a user on QRadar’s built-in Disabled user role is shown as disabled. Every other user is shown as enabled.
  • Administrator status - users whose role holds System Administrator (ADMIN), Security Administrator (SAASADMIN), or Administrator Manager (ADMINMANAGER) are marked as administrators.
  • Last login - the user’s most recent successful sign-in from QRadar’s login history.
  • Password age - when the user’s current local QRadar password was set.
  • Authentication method - password sign-in for local users, or single sign-on (SSO) when the Console uses SAML and the user isn’t Local Only. Users who signed in to the API with a username and password are marked as having API access.
• User roles - every user role, with the QRadar capabilities it grants. QRadar’s built-in Admin, All, WinCollect, and Disabled roles are marked as standard roles, and all others as custom roles. Each user and authorized service holds exactly one role.
• Security profiles - every security profile, shown as a group. A security profile controls which domains, networks, and log sources its members can see, so each membership lists the profile’s domains. A profile with no domains grants all data. The built-in Admin profile is marked as built in. Each user and authorized service belongs to exactly one profile.
• Non-human identities (NHIs):

  Identity	Shown as
  Authorized services	API token, with its user role, security profile, tenant, creation date, expiry date, and last use. Once its expiry date has passed, the token is shown as disabled, and its credential as expired. A service with no expiry date is marked as never expiring. When QRadar reports who created the service, and that user or authorized service is discovered, it’s shown as the token’s owner.
  App Framework apps	Application, enabled while the app is running. Oleria shows the QRadar user whose authority the app uses, the capabilities the app requests, its security profile, and the user who installed it, shown as its owner.
  WinCollect agents	Workload identity, enabled when QRadar reports the agent as enabled, with its host, version, and last heartbeat.
  Disconnected Log Collectors	Workload identity, with its host, creation date, and last event time. A collector whose status reports a failure or a disabled state is shown as disabled. Its public authentication keys and client certificate appear as credentials, and the certificate shows its expiry date.

• Activity - two QRadar audit sources:
  • successful and failed sign-ins from QRadar’s login history, with the source IP address and whether the user signed in through the Console or the API;
  • SIM Audit events from QRadar’s event store: configuration changes (authorized services added or removed, users added or deleted, user role and security profile changes, password changes, and other settings changes), user actions, sign-outs and expired sessions, and Risk Manager configuration changes.
  Every event keeps its QRadar event name. Events are attributed to the user or authorized service that made them. QRadar’s own system events are attributed to a QRadar system account. Events from a username Oleria can’t match, such as a deleted user, keep that username but have no actor. On a Username and password connection, Oleria drops the events of its own QRadar user.

​

Prerequisites

• A QRadar SIEM Console reachable from the internet over HTTPS on port 443, by DNS name. Oleria doesn’t connect to IP addresses, other ports, or through an on-premises agent.
• The Console’s host on Oleria’s egress allowlist. Before you connect, contact support@oleria.com with the Console’s host name, such as qradar.example.com, and ask for it to be allowlisted.
• A QRadar administrator who can create user roles and authorized services and deploy changes.
• A user role for Oleria with these QRadar capabilities, and the Admin security profile. See Create the Oleria credential in QRadar.
  • System Administrator (ADMIN). On QRadar on Cloud, Security Administrator (SAASADMIN) can replace it for reading, with the limits in Known limitations.
  • Administrator Manager (ADMINMANAGER)
  • Log Activity (EventViewer)
• Optional: the PEM-encoded CA certificate that issued the Console’s TLS certificate, if the Console uses a self-signed or private certificate. Oleria always verifies the Console’s certificate.
• Admin access on the Oleria platform to add a new integration.

​

Create the Oleria credential in QRadar

​

Permissions for reading

​

Permissions for remediation actions

​

Connect QRadar to Oleria

• QRadar rejected the credential (HTTP 401) - check the token, or the username and password. Check that the authorized service hasn’t expired and that you deployed changes after creating it.
• The QRadar credential’s user role lacks System Administrator - assign a user role with System Administrator and the Admin security profile, then deploy changes.
• QRadar Console … is not reachable from Oleria - check that the Console is reachable over public HTTPS on port 443, and that Oleria support has added its host to the egress allowlist.
• The QRadar Console … presented a certificate Oleria does not trust - paste the Console’s CA certificate into Console CA certificate (PEM), or install a publicly trusted certificate on the Console. A host that isn’t on Oleria’s egress allowlist can also cause this error.
• QRadar REST API not found (HTTP 404) - check that QRadar Console URL is your Console’s address.
• The console offers no supported REST API version - the Console runs a QRadar release older than 7.5.0 Update Package 6. Upgrade the Console, then try again.

​

Edit the integration

• Leave Authorized service token or Password blank to keep the stored value.
• If you switch Authentication method, enter the credential for the new method.
• Clear Console CA certificate (PEM) to remove the stored CA certificates.

​

Verify the integration

​

Remediation actions

• Oleria refuses to change QRadar’s default admin user, and the QRadar user this integration signs in as.
• Disabling the authorized service this integration connects with fails, because QRadar doesn’t let an authorized service change itself.
• Enable user accounts works only for a user that Oleria moved to the Disabled role, with Disable user accounts or Remove user from role, because it needs the role Oleria recorded. It also refuses to restore a role that holds System Administrator, Security Administrator, or Administrator Manager, because anyone who can edit the user’s description could change the recorded role. In both cases, use Add user to role instead.
• Add user to role can’t assign the Disabled role. Use Disable user accounts instead.
• QRadar requires the Admin security profile for users whose role holds System Administrator or Security Administrator. Oleria refuses to give such a role to a user outside the Admin profile, or to move such a user to another profile.
• If the user already has the role, profile, or status the action asks for, Oleria makes no change. If the change is staged but not deployed, Oleria deploys it only when the staged change carries Oleria’s description note, which is the case for Disable user accounts and for Remove user from role to Disabled. Otherwise the action fails without changing anything, and says that another change is pending for the user. Deploy or discard that change on the QRadar Admin tab, then run the action again. Running Create user or Delete user again also deploys a user or a delete that an earlier attempt staged. Create user refuses a username that a different staged change already uses, so deploy or discard that change first. Delete user succeeds without a change if the user is already gone.
• Reverting an action changes only what the action changed. If the user’s role, profile, or the authorized service’s expiry date changed since the action, or the app is no longer stopped, the revert makes no change and says why.
• Create user needs exactly one security profile, and a password when the Console uses QRadar’s own authentication. Oleria can’t generate a password. Usernames must be 1-60 characters without quotes or slashes, and can’t match an existing user or authorized service.
• If another deploy is running on the Console, Oleria waits up to 5 minutes for it to finish before it deploys. If the Console is still busy after that, the action fails and Oleria rolls back the change it staged, so nothing it wrote stays pending. If Oleria’s own deploy doesn’t finish within 10 minutes or QRadar reports errors for it, Oleria waits up to 10 more minutes and then checks the user. If the change took effect, the action succeeds. If it didn’t, Oleria rolls back the staged change and the action fails. If Oleria still can’t tell, the action fails without a rollback and says so, because rolling back a change that took effect would undo it at the next deploy. Check the user and the Admin tab before you run the action again. A rolled-back Create user deletes the staged user. If the rollback also fails, the error says so and the change stays staged, so it would take effect at the next deploy, including one another administrator runs. Deploy or discard it on the QRadar Admin tab. A failed deploy after Delete user can’t be rolled back, so the delete stays staged.

​

Known limitations

• Some actions aren’t in QRadar’s API. QRadar’s API has no way to remove a user from a security profile (every user needs one), end another user’s sessions, or create a security profile. Oleria doesn’t offer Remove user from group, Revoke sessions, or Create group for QRadar. Security profiles and user roles also can’t be nested, and security profiles have no owners.
• MFA and SSO are inferred. QRadar has no multi-factor authentication (MFA) of its own, and its API doesn’t report the authentication module (LDAP, RADIUS, TACACS, or SAML) the Console uses. Oleria infers SAML from the Console’s authorization settings. Local users show MFA as not required. Other users show MFA as unavailable, because MFA in your identity provider isn’t visible to QRadar. Users of LDAP, RADIUS, and TACACS look the same as local users.
• Last login depends on login history retention. Oleria takes last login from QRadar’s login history, which QRadar keeps only for the Console’s login history retention period. A user with no sign-in in that period shows no last login. QRadar doesn’t record failed sign-ins for SAML users. On a Console with more than 20,000 API (HTTP Basic) sign-ins in its login history, Oleria doesn’t report which users use the API.
• No creation date or password expiry. QRadar doesn’t report when a user was created. Oleria shows when each local password was set, but not when it expires.
• 90 days of history. When you connect, Oleria reads up to 90 days of activity, and the login history goes back no further than its retention period. SIM Audit events from the last five minutes are read on the next sync.
• Oleria’s own activity. On a Username and password connection, Oleria drops the events of its own QRadar user. On an Authorized service token connection, QRadar doesn’t identify which authorized service is calling, so Oleria’s own sign-ins and changes appear as activity of its authorized service.
• QRadar on Cloud credentials. With Security Administrator instead of System Administrator, QRadar hides every user and user role that holds System Administrator. Oleria shows a group named System Administrators not visible to this credential (synthesized) and a role named ADMIN capability (synthesized) to flag them, with no members. Without System Administrator, the login history holds only the credential’s own sign-ins, so users show no last login and no sign-in activity. App Framework apps, WinCollect agents, and Disconnected Log Collectors may not appear, and security profiles may lack their domain names. Remediation actions on users need System Administrator, so they’re unavailable with a Security Administrator credential.
• Authorized services need Administrator Manager. Without it, Oleria discovers only the authorized services this credential created.
• Apps and their tokens aren’t linked. An App Framework app uses its own authorized service. That service appears as a separate API token NHI, not linked to the app.
• App Framework disabled. If the App Framework is disabled on the Console, no apps appear.
• Log collectors can’t be disabled. QRadar’s API has no way to disable WinCollect agents or Disconnected Log Collectors.
• Network access. Oleria connects only over public HTTPS on port 443, to a Console host that Oleria support has added to the egress allowlist. Each Console’s host is allowlisted separately, and there’s no on-premises agent option.

​

Contact us