Threat detection

The identification of threats occurs through two distinct approaches:

1. Signature-Based: Static recognition based on known malicious patterns, with regularly updated signature files.
2. Behavioral-Based: Dynamic recognition through Machine Learning models.

Both approaches also work on historical data stored within the repository, which can be queried for the entire set retention period. The management platform enables manual searching for Indicators of Compromise (IOC) in the collected data. It should be noted that a specific destination IP may be considered an IOC, indicating evidence of some form of attack or threat. The management platform of our XDR solution allows the generation of specific queries to search for such data across all destination IPs associated with connections. 

Here is an example query to perform the search just described, assuming you want to search for the destination IP 224.0.0.252:

The query is set to also return the count of the number of connections involving that IP. Additionally, as previously mentioned, the platform allows the configuration of an alert that sends a notification every time the IP appears within a connection.

The solution integrates Machine Learning models designed for detecting anomalous behaviors within the monitored infrastructure. To ensure adequate performance metrics, these models are trained using data from the infrastructure itself, regardless of their source (logs from network devices, network traffic intercepted by the probe, logs from identity solutions, events from the static ISD component, etc.). The solution comes with a set of preconfigured models for incident detection; however, it is possible to develop additional ML models to recognize specific anomalous behaviors characteristic of the monitored organization's business.

The models can be configured to operate on a specific input bucket, corresponding to a series of indices in the data repository. Each model, when configured in this way, can learn the standard behavior of the network through data from multiple sources to detect suspicious behaviors on devices that are not directly monitored (devices without any installed agent). This is crucial for monitoring the behavior of devices owned by guest or occasional users who, for obvious reasons, are not directly monitored by the cybersecurity solutions implemented by the organization.

Below is the JSON related to one of the models integrated into the XDR solution:

{
      "state" : {
         "loss" : 0.00905147445824953,
         "trained" : true
      },
      "settings" : {
         "min_threshold" : 0,
         "default_bucket" : "input",
         "run" : {
            "detect_anomalies" : true,
            "flag_abnormal_data" : true,
            "save_prediction" : true,
            "output_bucket" : "output",
            "save_output_data" : true
         },
         "interval" : 60,
         "forecast" : 5,
         "span" : 20,
         "type" : "timeseries",
         "features" : [
            {
               "io" : "io",
               "field" : "conn.id.resp_h.keyword",
               "default" : 0,
               "anomaly_type" : "high",
               "measurement" : "traffic",
               "metric" : "cardinality",
               "name" : "Number_of_ips"
            },
            {
               "metric" : "cardinality",
               "name" : "open_ports",
               "measurement" : "opened_ports",
               "field" : "conn.id.resp_p",
               "io" : "i",
               "default" : 0
            }
         ],
         "grace_period" : 0,
         "default_datasource" : "input",
         "name" : "ipsvsport",
         "seasonality" : {
            "daytime" : true,
            "weekday" : true
         },
         "max_threshold" : 0,
         "bucket_interval" : "1m",
         "max_evals" : 10,
         "timestamp_field" : "@timestamp",
         "offset" : 30
      }
   }

Here is an example configuration of input and output buckets. The first indicates the set of data on which the model will be trained, while the second represents the container in which the model will store the predictions made:

buckets:
  - name: input
    type: elasticsearch
    addr: localhost:9200
    index: logstash-*
    doc_type: _doc

  - name: output
    type: elasticsearch
    addr: localhost:9200
    index: output-models
    doc_type: _doc

storage:
  path: /var/lib/loudml

server:
  listen: 0.0.0.0:8077

#

Furthermore, the Machine Learning models used by the XDR solution assign a score to each predicted event. The assigned score indicates the priority and therefore the severity of the just occurred event. Once a certain score threshold is surpassed, the event is considered anomalous and therefore prioritized.

Using ML models, the solution performs behavioral-based IOC recognition. Each IOC can be modified, and it is possible to add new custom indicators based on the requirement mentioned earlier, assigning the corresponding ATT&CK category each time. 

Each macrocategory defined by the framework is associated with a specific dashboard on the platform. Each dashboard contains a series of visualizations, each set to detect IOCs of attacks and threats related to the category associated with the dashboard itself.