¶ Summary
A score is calculated when a new cluster is created or a new alert correlates with an existing cluster. This score can be used to rank clusters so that those needing urgent investigation can be easily found on the SOC.OS workbench. The score of a cluster is calculated by summing together the scores of all the alerts correlated in that cluster. The score of each alert is calculated by multiplying together a base score and a number of user-configured factors. The base score is determined by SOC.OS using vendor severity information in the alert. The configurable factors are:
- Source system multiplier, e.g. increase the score because this alert originated from Darktrace.
- Alert action category multiplier, e.g. decrease the score because the email referenced in this alert was blocked.
- Alert type multiplier, e.g. increase the score because this alert relates to lateral movement.
- Tag multiplier, e.g. increase the score because this alert contains the IP address of a business critical server.
Keep reading for a more detailed explanation and some example scenarios.
¶ Cluster Score
Each cluster in SOC.OS is assigned a score. This score can be used to define search criteria or order query results on the SOC.OS workbench. The scores of the clusters are displayed in the SCORE column.
The score is also displayed in the header section when viewing a specific cluster, as shown below.
The score of a cluster is calculated by adding together the scores of all the alerts that make up that particular cluster.
¶ Alert Score
The score of each alert is calculated by multiplying together a number of factors. Each factor has a value in the range 0.1-10.
¶ Alert base score
The alert base score is derived from vendor information in the alert and is determined when SOC.OS parses the alert. Vendor severity information is reported in many formats, for example
- a numeric value in a CEF header or
- "high", "medium", "low" or "informational" in a severity field.
By mapping to an alert base score, the vendor specific information is standardised to a value on a common scale (0.1-10).
E.g. "low" severity alerts from Fortinet Fortianalyzer are assigned a base score of 0.1.
The alert base score is defined by SOC.OS and, at this stage in the product's development, cannot be configured by users.
¶ Source system score multiplier
The source system multiplier allows you to increase or decrease the score of all alerts ingested from a particular source system. The value can be configured, per source system, in the Scoring Configuration screen.
E.g. increase the score of all AWS GuardDuty alerts by a factor of 2.
The colour of the battery icon indicates of the size of the score multiplier. The colour coding is defined by a key on the Scoring Configuration screen.
¶ Alert action category score multiplier
The alert action category multiplier allows you to increase or decrease the score of alerts based on their action category. The action category of an alert is determined from vendor information when SOC.OS parses the alert. The field can take one of three values:
- Actioned - the source system has taken some preventative action (e.g. the firewall has blocked a connection attempt).
Example vendor terms mapped to this category include blocked, dropped, quarantined, bounce. - Unactioned - the source system has not taken preventative action (e.g. the firewall has allowed a connection attempt).
Example vendor terms mapped to this category include allowed, detected, unhandled, exempt, permitted. - Unknown - the action of the source system cannot be determined from the threat log that SOC.OS has ingested.
A score multiplier for each action category can be configured for each source system.
Each value can be set via the text box or using the corresponding slider.
E.g. halve the score of actioned Proofpoint alerts (i.e. multiply by 0.5) and increase the score of unactioned or unknown Proofpoint alerts by 50% (i.e. multiply by 1.5).
The default score multipliers are set to 0.5 for actioned alerts and 2 for alerts that are unactioned or unknown.
¶ Alert type score multiplier
The alert type multiplier allows you to increase or decrease the score given to alerts of a certain type. These can be configured independently for each source system.
Alert type multipliers can be added using the + ADD ALERT TYPE button and removed using the x button on each row. The alert type can be selected from a dropdown that contains a list of types that have been ingested from this source system. This list can be filtered by typing in a partial alert type. New alert types can also be added to the list, so that scoring rules can be configured for yet unseen alert types.
The score multiplier value can be set via the text box or using the corresponding slider.
E.g. Increase the score of Thinkst Canary
SSH Login Attemptalerts by a factor of 5.
The alert type score multiplier can be used to decrease the significance of certain alert types, so that clusters containing them appear lower in the score ranking. Alternatively, it is also possible to filter out certain alert types. This will prevent SOC.OS from processing alerts of that type and correlating them into clusters. More information can be found in our tutorial on filtering.
¶ Tag score multiplier
Tags allow custom business context to be added to the alert data. For example, critical assets can be tagged based on their IP addresses, domains, user names etc. Each tag has a score multiplier that allows the user to increase or decrease the score of any alert that matches the tag.
The score multipliers for tags are configured on the Custom Enrichment screen.
E.g. boost the score of all alerts that contain the IP address of the authentication server by a factor of 2.5.
If multiple tags match a single alert, their score multipliers are multiplied together.
More information about configuring tags and their score multipliers is available in the custom enrichment tutorial.
¶ Scoring Examples
Given the scoring configuration shown, the below alerts would be scored as follows:
- An unactioned
Device/New or Unusual Remote Command Executionalert with severity 7 is ingested from Darktrace. The IP address in the destination field of the alert matches the IP address of a tagserver:remote accessthat has a score multiplier of 3.
| Base alert score | Source system multiplier | Action category multiplier | Alert type multiplier | Tag multiplier | Total |
| 4* | 1 (a) | 1.4 (b) | 1 | 3 | 16.8 |
* A severity value of 7 in a Darktrace alert maps to a SOC.OS base score of 4. Please see the Alert base score section for more details.
- A
vBulletin.Routestring.widgetConfig.Remote.Code.Executionalert with severity "low" and unknown action is ingested from Fortinet Fortigate.
| Base alert score | Source system multiplier | Action category multiplier | Alert type multiplier | Tag multiplier | Total |
| 0.5* | 3 (c) | 1 (d) | 2 (e) | 1 | 3 |
* A severity of "low" in a Fortigate alert maps to a SOC.OS base score of 0.5. Please see the Alert base score section for more details
If the above alerts correlated together to form a cluster, the score of that cluster would then be:
| Alert 1 score | Alert 2 score | Cluster score |
| 16.8 | 3 | 19.8 |
Are there source systems missing from your scoring configuration screen? Please contact us at support@socos.io