Labels

Labels allow you to mark or "tag" collections of identifiers with a confirmed disposition or outcome.
The labels are available to both search for and be read in real-time when those identifiers are seen again

Label Uses

Labels are useful for:

• Being available to read in real-time, for rules that automatically influnce overall decision

• Binding collections of attributes together, based on critera

• Supplying the 'truth data' for machine learning models to train and optimise decisions on

• Available to search over in list format (passlist, blocklist, watchlist

Label Properties

Label Name/ID

The label name is what is fundamentally what is used to search for the label.

See Label Reference for all label names/ids.

Label names come from a a fixed set of strings. Only one is permitted per label.  This name also auto-assigns some contexts.

Contexts

Contexts is an array of strings that adds additional details to the label.
The standardised contexts include:

Context: Confidence (input)

Confidence allows assigning a categorical value to the confidence in the marking.
This permits more liberal use of labels vs. needing to be 100% confident to add the label.
Supported confidence context strings from most to least confident:

confirmed
probably
reasonable
slight

Context: Source (input)

Auto-assigned based on how label is added. Can have multiple.

rule
analyst
api
model
data_feed
manual_add
automated_add

Context: Crawler Family (input)

List of bots and crawler genres.

Context: Category (auto)

Auto-assigned based on label name. Groups similar types of label into a higher level category

lists
truth_data
fraud
abuse
security
risk
bot
authentication
identity

Context: Disposition (auto)

Auto-assigned based on label name. Indicates sentiment towards events with that label. From most to least positive:

positive
neutral
suspicious
negative

Label Operations

• Check: Checks for the presence of a specific label on a collection of identifiers

• Add: Creates a new label and assigns it to a collection of identifiers

• Remove: Removes an existing  label from a collection of identifiers

These operations on labels can be performed:

1. Programmatically via API

See Calling the Label API.

2. Automatically via Darwinium rules

The Darwinium rule engine has functions and rule types that allow automatic interaction with labels through logical criteria in real time.

Check Label Function

Check label functions return a boolean when checking for particular label against identifier(s) seen on the processed event.

• checkLabel: Requires a label to match strictly to all identifiers (‘AND’)

  • checkLabel("label_name", [identifiers], ["optional", "contexts"], optional_start, optional_end)

• checkLabelAnyOf: Only requires a label match for any identifier (‘OR’)

  • checkLabelAnyOf("label_name", [identifiers], ["optional", "contexts"], optional_start, optional_end)

// Does device have a block label
checkLabel('block_list', profiling.device.identifier)

// Does device have a block label, with specific context
checkLabel('block_list', profiling.device.identifier, ['manual'])

// Does device have block label added in last month 
checkLabel('block_list', profiling.device.identifier, [], ((timestamp as int) - 1000*60*60*24*30) as datetime, timestamp)

// Does device + user pair have a challenge pass label
checkLabel('challenge_passed', [profiling.device.identifier, identity['ACCOUNT'].username.username])

// Does device appear on any account takeover label? (i.e including when that label has other identifiers too)
checkLabelAnyOf('account_takeover', profiling.device.identifier)

// Does either device or device signature appear on any account takeover label?
checkLabelAnyOf('account_takeover', [profiling.device.identifier, device_signature['VER_1'].identifier])

Add Label Rule

Rule type can automatically add label to identifier(s)

Remove Label Rule

Rule type can automatically remove label from identifier(s)

Add/Remove Label advice

You will likely always want to nest an Add or Remove label rule within an IF statement.

• label_name, string. Name of the label from fixed list. See Label Reference.

• identifiers, array. Collection of Darwinium identifiers to check label on

• contexts, array. Strings that narrow down to only labels with certain context. See Label Reference.

• optional_start, number (optional): Start time to check for events with label present (UTC epoch time in milliseconds)

• optional_end, number (optional): End time to check for events with label present (UTC epoch time in milliseconds)

For more information on the Darwinium rule engine, see rules.

3. Manually via Darwinium Portal GUI

There are GUIs within the Darwinium Portal for analysts to more easily engage with labels.

Labels Tab

Navigate to Labels screen of the Portal through sidebar

Here a user can interact search and view labels that are currently applied, as if they were lists:

• Check (Search and filter): Through search bar

• Add: Labels added through Add Label widget

• Remove: Labels removed through finding them in list and the hitting overlay trash icon

Event Details

In Investigations Tab, clicking on any event produces a sidebar of the details of that event.

Operations are possible within this sidebar:

• Check: Sidebar will display inline if there are labels associated to identifiers on this event. Hovering over the Name gives further details

  

  

• Add: At the top of the sidebar is a button to Add Labels directly to identifier values on this event

• Remove: Not possible in sidebar, use Labels tab or API.

Examples: Label Use Cases

• The label API is called in batch daily to label journey_id that had confirmed fraud outcomes. These labels are then used to:

  • perform trend, benefit and performance analysis of fraud captured

  • perform monthly optimisation of the custom rulesets and machine learning models within Darwinium

• The label API is called with the Email and Device Identifiers associated to accounts at the time they are closed due to being confirmed as mules. These labels are then used to:

  • Trigger automatic rules at Signup to prevent either the Device Identifier or Email from being used to create another account

  • perfom fraud analysis at an Email and Device level to identify behaviours that are indicative of mule activity

• An AddLabel rule automatically labels the combination of an account and device identifier as trusted, when the combination successfully login after passing two factor authentication. These labels are then used to:

  • Recognise the device identifier and account combination on future login attempts. If the label exists within a lookback timeframe of 30days, user is allowed to login without 2FA.

• An AddLabel rule automatically labels accounts that have logged in weekly for the last 3months. These labels are then used to:

  • Offer a more trusted and positive user experience, such as skipping usual validations/checks or offering closed promotions and beta invitations

• An analyst within the Darwinium Portal manually adds labels to IPs deemed suspicious. These labels are then used to:

  • Be available to search for in Investigations part of the Darwinium Portal.

  • Add more negative weighting to any subsequent events that are from this IP

  • Trigger the CallURL function to add to their Case Management any new Signups from this IP for the next week.