Writing a DSM to contribute to the UBA App
Now that QRadar has a User Behaviour Analytics (UBA) App you should be mindful of how DSMs are feeding data into it. The UBA is a rules driven engine that takes user data from events coming in and provides customers with a deeper look at how those users are acting. You can help ensure that the data being consumed by the UBA is of the highest quality by keep a few things in mind. At a high level UBA Rules are looking at the categorization of events into one of 3 pools. Authentication Successful, Authentication Failure, and Privileged Action. The categorization are used for User discovery, and tracking a risk score associated with the username depending on the actions they take, as well as the context of those actions. Making sure that events are categorized correctly and that the right username is being parsed out is the key to better integrations with the UBA.
Always ensure that the username being parsed out seems to be proper and makes sense. It is always assumed that the parsed username is the acting user, never the user being acted upon. It's probably easiest to think of the UBA acting on usernames as a sort of primary key, so having this correct is vital to the UBA not churning on junk usernames, and giving good analysis. An example might be that if a user login failure event has the right username, but a later privileged action has the wrong username later, it would look like two different low threat users when it should be one high threat user being called out by the UBA.
Authentication Successful is looking at when a username first becomes active (very similar to how identity tracking is done.) So the easiest way to begin contributing to UBA is to ensure that:
#1 The Username is properly parsed out.
#2 One of the following categories is used for mapping an event if the parsed out username is logging in:
Authentication.Admin Login Successful
Authentication.Auth Server Login Succeeded
Authentication.Auth Server Session Opened
Authentication.FTP Login Succeeded
Authentication.General Authentication Successful
Authentication.Host Login Succeeded
Authentication.Login with username/password defaults successful
Authentication.Mail Service Login Succeeded
Authentication.Misc Login Succeeded
Authentication.Password Change Succeeded
Authentication.Privilege Escalation Succeeded
Authentication.Remote Access Login Succeeded
Authentication.Samba Login Succeeded
Authentication.SSH Login Succeeded
Authentication.System Security Access Granted
Authentication.Telnet Login Succeeded
Authentication.VoIP Login Succeeded
Authentication.Web Service Login Succeeded
Authentication.Database Login Succeeded
Authentication.IKE Authentication Succeeded
Authentication.RADIUS Authentication Succeeded
Authentication.Station authentication succeeded
Authentication.TACACS Authentication Succeeded
Authentication.User Login Success
These should also be considered for identity events!
Authentication Failure is handled very similarly to the Auth Successful. The UBA rules it fires vary a bit depending on if it is a known active user or an unknown one though. This is important to get correctly as the UBA risk score rises with every Auth Failure. The guidelines are the following:
#1 The Username is parsed out properly.
#2 One of the following categories is used in event mapping if the parsed out username has failed authentication:
Authentication.Admin Login Failure
Authentication.Auth Server Login Failed
Authentication.FTP Login Failed
Authentication.General Authentication Failed
Authentication.Host Login Failed
Authentication.Login with username/password defaults failed
Authentication.Mail Service Login Failed
Authentication.Misc Login Failed
Authentication.Password Change Failed
Authentication.Privilege Escalation Failed
Authentication.Remote Access Login Failed
Authentication.Samba Login Failed
Authentication.SSH Login Failed
Authentication.Telnet Login Failed
Authentication.VoIP Login Failed
Authentication.Web Service Login Failed
Authentication.Database Login Failed
Authentication.IKE Authentication Failed
Authentication.RADIUS Authentication Failed
Authentication.TACACS Authentication Failed
Authentication.User Login Failure
Authentication.Station authentication failed
Privileged Actions are events with an associated username that are not necessarily high risk alone, but bump up after auth failures, or if a lot of them are hit in a row. Caution should be used when using these categories that they aren't coming up too often when they shouldn't since false positives can stack up and cause a user risk score to rise when it shouldn't. Some general rues to follow:
#1 Make sure the username parsing is right! This has to keep being iterated since bad usernames tank the usefulness of the UBA more easily than anything else.
#2 The following categories should be used appropriately, make sure they are not used for ambiguous events, the parsed username should be the acting user (this is especially important for the user added/modified events):
Authentication.Group Added
Authentication.Group Changed
Authentication.Group Member Added
Authentication.Computer Account Added
Authentication.Computer Account Changed
Authentication.Policy Added
Authentication.Policy Change
Authentication.Trusted Domain Added
Authentication.User Account Added
Authentication.User Account Changed
Authentication.User Right Assigned
Authentication.Privilege Escalation Succeeded
Authentication.Computer Account Removed
Authentication.Group Member Removed
Authentication.Group Removed
Authentication.System Security Access Granted
Authentication.System Security Access Removed
Authentication.Trusted Domain Removed
Authentication.User Account Removed
Authentication.User Right Assigned
Authentication.User Right Removed
System.Application Uninstalled
System.Failed Application Modification
System.Failed Configuration Modification
System.Failed File Modification
System.Failed Host-Policy Modification
System.Failed Registry Modification
System.Failed Service Modification
System.Failed Stack Modification
System.File Created
System.File Deleted
System.Host-Policy Created
System.Host-Policy Deleted
System.Registry Deletion
System.Service Uninstalled
System.Successful Configuration Modification
System.Successful File Modification
System.Successful Host-Policy Modification
System.Successful Registry Modification
System.Successful Service Modification
System.Successful Stack Modification
System.System Configuration
System.Successful Configuration Modification
System.System Configuration
System.Service Stopped
System.System Halt
System.Service Installed
System.Registry Addition
System.Service Started
System.Application Installed
There are also rules built around locked out & disabled user login attempts, and if you feel you have these types of events than please contact the IBM Security Technology Alliances team about advice on how to deal with these.
Beyond just the DSM, you can contribute directly to the UBA through sense Events using a rule pack
The UBA looks for category 24000 to 25000, and then if the custom property senseValue exists, and uses that as the 'risk' per event.
The easiest way to integrate is probably just to create a rule, with the test looking for a specific qid. For example if partner X has a qid - 'Detected malicious executable running on host', they could set up a rule just for that qid, and then as the rule response generate a sense event:
put senseValue=10 in the desc
High Level Category = Sense
Low Level = any of the ones listed below
Event name - probably 'VENDOR NAME : Detected malicious executable running on host'
The triggering event here would need a username as well (the dispatched one inherits src/dest port, IP, username and other properties)
Low Level categories for Sense Events:
Sense.User Behavior
Sense.User Geography
Sense.User Time
Sense.User Access
Sense.User Privilege
Sense.User Risk
Sense.Sense Offense
Sense.Resource Risk
Sense.UBA Machine Learning Anomaly
Always ensure that the username being parsed out seems to be proper and makes sense. It is always assumed that the parsed username is the acting user, never the user being acted upon. It's probably easiest to think of the UBA acting on usernames as a sort of primary key, so having this correct is vital to the UBA not churning on junk usernames, and giving good analysis. An example might be that if a user login failure event has the right username, but a later privileged action has the wrong username later, it would look like two different low threat users when it should be one high threat user being called out by the UBA.
Authentication Successful is looking at when a username first becomes active (very similar to how identity tracking is done.) So the easiest way to begin contributing to UBA is to ensure that:
#1 The Username is properly parsed out.
#2 One of the following categories is used for mapping an event if the parsed out username is logging in:
Authentication.Admin Login Successful
Authentication.Auth Server Login Succeeded
Authentication.Auth Server Session Opened
Authentication.FTP Login Succeeded
Authentication.General Authentication Successful
Authentication.Host Login Succeeded
Authentication.Login with username/password defaults successful
Authentication.Mail Service Login Succeeded
Authentication.Misc Login Succeeded
Authentication.Password Change Succeeded
Authentication.Privilege Escalation Succeeded
Authentication.Remote Access Login Succeeded
Authentication.Samba Login Succeeded
Authentication.SSH Login Succeeded
Authentication.System Security Access Granted
Authentication.Telnet Login Succeeded
Authentication.VoIP Login Succeeded
Authentication.Web Service Login Succeeded
Authentication.Database Login Succeeded
Authentication.IKE Authentication Succeeded
Authentication.RADIUS Authentication Succeeded
Authentication.Station authentication succeeded
Authentication.TACACS Authentication Succeeded
Authentication.User Login Success
These should also be considered for identity events!
Authentication Failure is handled very similarly to the Auth Successful. The UBA rules it fires vary a bit depending on if it is a known active user or an unknown one though. This is important to get correctly as the UBA risk score rises with every Auth Failure. The guidelines are the following:
#1 The Username is parsed out properly.
#2 One of the following categories is used in event mapping if the parsed out username has failed authentication:
Authentication.Admin Login Failure
Authentication.Auth Server Login Failed
Authentication.FTP Login Failed
Authentication.General Authentication Failed
Authentication.Host Login Failed
Authentication.Login with username/password defaults failed
Authentication.Mail Service Login Failed
Authentication.Misc Login Failed
Authentication.Password Change Failed
Authentication.Privilege Escalation Failed
Authentication.Remote Access Login Failed
Authentication.Samba Login Failed
Authentication.SSH Login Failed
Authentication.Telnet Login Failed
Authentication.VoIP Login Failed
Authentication.Web Service Login Failed
Authentication.Database Login Failed
Authentication.IKE Authentication Failed
Authentication.RADIUS Authentication Failed
Authentication.TACACS Authentication Failed
Authentication.User Login Failure
Authentication.Station authentication failed
Privileged Actions are events with an associated username that are not necessarily high risk alone, but bump up after auth failures, or if a lot of them are hit in a row. Caution should be used when using these categories that they aren't coming up too often when they shouldn't since false positives can stack up and cause a user risk score to rise when it shouldn't. Some general rues to follow:
#1 Make sure the username parsing is right! This has to keep being iterated since bad usernames tank the usefulness of the UBA more easily than anything else.
#2 The following categories should be used appropriately, make sure they are not used for ambiguous events, the parsed username should be the acting user (this is especially important for the user added/modified events):
Authentication.Group Added
Authentication.Group Changed
Authentication.Group Member Added
Authentication.Computer Account Added
Authentication.Computer Account Changed
Authentication.Policy Added
Authentication.Policy Change
Authentication.Trusted Domain Added
Authentication.User Account Added
Authentication.User Account Changed
Authentication.User Right Assigned
Authentication.Privilege Escalation Succeeded
Authentication.Computer Account Removed
Authentication.Group Member Removed
Authentication.Group Removed
Authentication.System Security Access Granted
Authentication.System Security Access Removed
Authentication.Trusted Domain Removed
Authentication.User Account Removed
Authentication.User Right Assigned
Authentication.User Right Removed
System.Application Uninstalled
System.Failed Application Modification
System.Failed Configuration Modification
System.Failed File Modification
System.Failed Host-Policy Modification
System.Failed Registry Modification
System.Failed Service Modification
System.Failed Stack Modification
System.File Created
System.File Deleted
System.Host-Policy Created
System.Host-Policy Deleted
System.Registry Deletion
System.Service Uninstalled
System.Successful Configuration Modification
System.Successful File Modification
System.Successful Host-Policy Modification
System.Successful Registry Modification
System.Successful Service Modification
System.Successful Stack Modification
System.System Configuration
System.Successful Configuration Modification
System.System Configuration
System.Service Stopped
System.System Halt
System.Service Installed
System.Registry Addition
System.Service Started
System.Application Installed
There are also rules built around locked out & disabled user login attempts, and if you feel you have these types of events than please contact the IBM Security Technology Alliances team about advice on how to deal with these.
Beyond just the DSM, you can contribute directly to the UBA through sense Events using a rule pack
The UBA looks for category 24000 to 25000, and then if the custom property senseValue exists, and uses that as the 'risk' per event.
The easiest way to integrate is probably just to create a rule, with the test looking for a specific qid. For example if partner X has a qid - 'Detected malicious executable running on host', they could set up a rule just for that qid, and then as the rule response generate a sense event:
put senseValue=10 in the desc
High Level Category = Sense
Low Level = any of the ones listed below
Event name - probably 'VENDOR NAME : Detected malicious executable running on host'
The triggering event here would need a username as well (the dispatched one inherits src/dest port, IP, username and other properties)
Low Level categories for Sense Events:
Sense.User Behavior
Sense.User Geography
Sense.User Time
Sense.User Access
Sense.User Privilege
Sense.User Risk
Sense.Sense Offense
Sense.Resource Risk
Sense.UBA Machine Learning Anomaly