Welcome to Rules

Rules are the objects within Secure60 that look at the data within the system and decide if a specific action should be taken based on that data

We include a range of Managed Rules with your Secure60 subscription that you can elect to enable on your Projects. These rules are maintained, updated and extended by the Secure60 team to offer ongoing threat protection without any customer action.

Managed Rules include:

• Application, Device, Operating System or Cloud Platform specific Rules
• Entity Analytics Rules

This combination is extremely powerful when used together, It enables both technical level analytics and behavioural analysis to be combined together in the system operation. This results in extremely effective detection of security problems and very low false positive rates.

Rule Configuration

There are 2 elements to Rule configuration and deployment:

• Organisation Settings -> Custom Rule Groups
  • Custom Rule Groups and Rules are created at the Organisation level. They can be marked as inheritable so that these Rule Groups are visible to sub Organisations in your heirarchy
  • Making a Custom Rule Group and Rule at the Organisation level doen’t make the configuration active. For this to happen you need to apply the Rule Group to a Project
• Project Settings -> Rule Groups
  • When you apply a Rule Group to a Project, All Rules within the Rule Group become active on that Project.
  • When a Rule Group is active on a Project the data queries are running against the data in that Project at the frequency specified in the Rule object.

Elements of a Rule

A Rule is the part of the Secure60 platfrom that is responsible for looking at customer data and idenfitying conditions in that data that prompt the system to perform an action or response.

A Rule internally is a JSON object that has a number of elements. You configure a Rule through the Secure60 portal or via the Secure60 API.

Here is an example rule, we discuss the various elements below:

{
  "conditions": [
    {
      "query": "(event_command ~ '(user|add|expires:never)') ",
      "data_type": "event",
      "trigger": "1"
    }
  ],
  "actions": [
    {
      "action_type": "create_signal",
      "_category": "new-user-created-via-net.exe-with-never-expire-option",
      "_description": "Detects creation of local users via the net.exe command with the option \"never expire\"\r\n\n   references: https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/    level: high",
      "_name": "New User Created Via Net.EXE With Never Expire Option",
      "_score": 50
    },
    {
      "action_type": "create_entity",
      "_entities": [
        {
          "_entity_name": "ip_src_address",
          "category": "new-user-created-via-net.exe-with-never-expire-option",
          "_score": 50
        },
        {
          "_entity_name": "user_name",
          "category": "new-user-created-via-net.exe-with-never-expire-option",
          "_score": 50
        },
        {
          "_entity_name": "host_name",
          "category": "new-user-created-via-net.exe-with-never-expire-option",
          "_score": 50
        }
      ]
    }
  ]
}

Rule Execution

The Rule Execution field defines how the Rule is stored and run within the Secure60 platform.

Execution is defined at the Rule object under Organisation Settings and cannot be changed on a Project by Project basis.

There are 2 options when creating a Rule regarding how the Rule will be implemented:

• Polling (Default) - These Rules run on a frequency and look back at a specific data period for each execution
  • Supports the full rich query language
  • Automatically ensures all time periods are covered when looking at data
  • Allows conditions that group data by specific fields or over a time period
• Streaming - These Rules are applied as data enters the Secure60 platform
  • Supports a limited query language
    • Supports conditions that use all operators except regex type
  • Only looks at individual Events one by one. No cumulative or ranges of time window supported

Rule Conditions

This component of a rule defines what data to query and how to filter the source data to specific items of interest.

Key elements:

• query: The query (in Secure60 Syntax) that filters data
• data_type: The type of data to query, eg. Event for raw events

Other elements:

• Allow Lists: list_allow Applies a List to the Rule processing. Allow Lists (also known as Whitelists) stop a Rule from triggering if a value in the List matches the data returned by the Rule

  • Stored an as Array Array Elements:
    • list_id: Specifies the List ID to apply
    • data_field: Specifies the fieldname that will be checked for a match in the List

• Trigger Lists: list_trigger Applies a List to the Rule processing. Trigger Lists activate a Rule to trigger if a value in the List matches the data returned by the Rule

  • If configuring an Exclusion, use a Trigger so that the Exclusion matches and this will avoid firing actions
  • Stored an as Array Array Elements:
    • list_id: Specifies the List ID to apply
    • data_field: Specifies the fieldname that will be checked for a match in the List

• trigger: How many results are need to trigger the Rule Actions to be executed. Default: 1. Only applies to rules with execution POLLING

Refer to Secure60 Syntax for more details on query approach, Lists for a List overview on Lists and also the full API specification is available.

Rule Actions

Rules have Actions, which are internal operations inside the Secure60 platform that happen when a Rule Condition is met

Key elements:

• action_type: The type of action to execute:
  • create_signal
  • create_entity
  • create_threat

Other elements:

• score: Threats and Signals can both have a score associated with their level of risk. Score can be set via a field in the Rule or as part of the Actions definition. More specific (Actions definition) takes precedence.

• severity: Severity indicates a grouping of Threats based on risk. Valid values are: INFO, LOW, MEDIUM, HIGH. A Threat object can have a severity level manually set via the Actions definition or it will be automatically set based on the score of the Threat. Severity value from score number is defined as follows:

  • score 0 = severity INFO
  • score > 0 and < 80 = severity LOW
  • score >= 80 and < 90 = severity MEDIUM
  • score >= 90 = severity HIGH

• source: If you add a source field to the create_threat action, we will look in the data that has triggered the Threat for a field name that is a match for the value of the source field (with fallback to using the text in the field).

  An example where this is useful is that you can have a single rule that creates multiple threats for a specific entity (perhaps a server host_name) the source field might be a technology or problem area.

  Specifically if a vulnerability is detected in PHP and an Event sent into the platform, the source could be the php version and make a threat based on that. You can then have other vulnerabilities with their own source value, like nginx that will create a new threat but you wont get multiple threats for php or nginx.

  You need to tick the checkbox Check by Rule, Entity, Source inside the Create Threat Action defintion for the system to not create duplicate Threats.

API Definition for full specification of Rules

The Secure60 API definition contains the full detail of every field than can be used in a rule: https://www.secure60.io/docs/api/#/Rule%20API/post_admin_1_0_rule

Sample from API: