Samurai MDR

• 1: Boost Scoring
• 2: How do I know if my integration is functioning?
• 3: Samurai Glossary of Terms
• 4: Telemetry Data Source Categorization

1 - Boost Scoring

Boost Scoring is a technique used by the Samurai platform which improves the ability to find Advanced Persistent Threats (APTs) by using a methodology which helps to link seemingly unrelated events allowing the platform to determine where a set of events becomes notable enough to warrant investigation as a threat.

This is done by using the ability to identify suspicious activities using the combined insights offered by multiple enrolled sources, irrespective of technology type or vendor. This enables detection using activities and events that normally would not be of a significant interest by themselves. When seen in combination however they represent individual aspects of a threat. Boost scoring provides a method to link these events and strengthen their relevance when they are combined.

By grouping activities and events on a user and entity basis and Mitre tactic basis, Boost scoring enables identification of suspicious behaviors which are identified via combined insights. The Boost score increases over time providing more accurate confidence and threat severity scoring for each group over time.

Figure 1: Boost scoring

By keeping the Group state for a long period of time (typically over 60 days) Samurai is able to detect evasive threats that have stayed dormant for a longer period of time after the initial breach by linking additional events which can be linked to the initial breach attempt.

Once a Boost score reaches a predetermined level it will be used to generate an alert which is presented to SOC analysts. This helps to suppress single indicators from raising alerts, and rather permits the gathering of evidence until a confidence threshold is reached where the raising of an alert is justified.

This technique enables detection of dormant threats and slow-moving attacks (a traditional evasion technique). Suspicious activities are assessed in their entirety regardless of threat severity, time or log source.

Simply put, Boost scoring helps to find the balance between too many alerts (false positives) and too few alerts (false negatives) and in that process selecting the activity which is of real importance in identifying the activity of threat actors.

2 - How do I know if my integration is functioning?

One of the things you will need to know is that integrations you have configured are working correctly and sending telemetry to the Samurai platform.

Integration Health

You can easily get an overview of which of your Integrations are not healthy by viewing the Telemetry Dashboard or Telemetry Monitoring. This gives you a concise overview of any integrations which are unhealthy - or in other words, Integrations where the Samurai platform has not seen events over specific time periods:

The fact that an Integration is unhealthy doesn’t necessarily mean that there is a fault. For example, your integration may send telemetry intermittently - is this case we highlight this in the Info field.

Telemetry Monitoring Notifications

Samurai will send email notifications to registered application users if no events are seen for an integration over 24hrs. You can opt-in to receive notifications by submitting a ticket in the Samurai MDR portal or during MDR onboarding.

Managing Integration Health

There are a few factors which could result in telemetry not being properly ingested. This article takes you through the main factors which could impact whether an integration is working or not, who is responsible for them, and how to address them.

In order for a log source to be ingested into the platform, the following main areas need to be functioning properly:

• Platform is available: We are responsible for making sure that the Samurai platform is available.
• Log source configuration: Often the first place to check is that the log source is correctly configured to send logs. If your log source uses a Cloud Collector, you will also need to check that the Cloud Collector is functioning and healthy. Make sure that you have followed all of the configuration steps outlined in the configuration guide for the Integration.
• Connectivity: Any log sources using Local Collectors are dependent on internet connectivity between your premises and the Samurai platform. Check that your internet connection is available and that firewalls are configured to allow traffic. The Local Collector article also provides a detailed explanation of all of the ports that a Local Collector needs to have open in order to function correctly.
• Local Collector: If your log source uses a Local Collector, you will need to ensure that the Local Collector is available. You will also need to ensure that the virtualization platform that hosts the Local Collector is healthy. For more information see the section on Local Collectors below.
• Cloud Collector: If your log source uses a Cloud Collector, the health of your integration is also dependent on the Cloud Collector being operational. If your log source is correctly configured but it remains unhealthy, it is our responsibility to ensure the Cloud Collector is operational for you.
• Cloud Native Collector: If you leverage a Cloud Native Collector, you will need to ensure that it is available. As the Cloud Native Collector is a transport method and monitors a cloud storage account, ensure that your integrated sources are sending and storing data to the storage account.

Local Collectors

If your integration is utilizing a Local Collector, firstly make sure it’s running as expected. If there is a problem with your Local Collector you should receive an email notification of status change. Login to the Samurai MDR portal and check the Collector Health. This is a status that is shown in the Collector navigation item in the application (Offline, Unavailable, Healthy, Not-Healthy, Provisioning). 

When you drill down into a Local Collector in the Samurai MDR portal, you are provided a view which shows you the health of the Collector, together with all of the Integrations that are configured to use that Collector:

For integrations that utilize a Cloud Collector or Cloud Native Collector you can jump directly to checking the Integration status.

Integration Status

Once you have confirmed that the Local Collector is Healthy (communicating with Samurai), check the Integration status. From the Collectors menu (applicable to both Local Collectors and Cloud Collector) you can view associated integrations to view their state of health. Alternatively, navigate to the Integrations page. Refer to Integrations for further steps.

In both cases you will see a column called ‘Last Event Seen’. This column provides a timestamp (in the format [yyyy:mm:dd], [hh:mm:ss]) represented in Universal Time Coordinated (UTC) of the last received event.

Within the current version of Samurai we monitor for ‘Last Event Seen’ within specific timeframes that relate directly to the Status - a table below outlines the time periods and related status.

If for some reason, the Integration is not healthy or not available (e.g. not Green), then run through the Integration guide for your specific device and confirm there are no other controls blocking the traffic to the Local Collector or Cloud / Native Collector.

If your Integration is of type Local or Cloud and is not healthy or not available, then review the integration configuration to ensure it is correct and also ensure you followed the appropriate Integration guide for your device.

If you still have issues and please raise a ticket via the Samurai MDR portal

Querying the detail

If you would like to go into more detail about the events from your log sources, you can make use of Advanced Query to analyze the events stored in the data lake. This will help you to answer questions like:

• Is my log source generating logs intermittently? By querying your log source over a period of time, the graphical representation of events will quickly show you time periods when your log source was not generating logs:
  

• When did my log source last generate an event and what was that event? You can easily find the last time when a log source generated an event. This will be the same as the “Last Event Seen” field for the Integration. For instance, the following query shows the last log generated in the last 7 days:
  

• Is my log source configured to generate correctly formatted logs? Sometimes a configuration error on your log source might result in your log source generating incorrectly formatted logs. By examining the raw log content you can check that your logs are correctly formatted. This will assist in correcting any configuration errors which may have resulted in incorrectly formatted logs being sent.

• Is my log source sending the logs I need? By checking the types of events generated, you can verify that you have configured the log source to send the logs you require, and that it is generating them. For instance, in this example, we are verifying that a device is generating DNS logs as expected:
  

3 - Samurai Glossary of Terms

The definitions provided below are used within Samurai documentation, all legal terms can be found under Legal.

Advanced Analytics:

Detection capabilities, including machine learning, big data, and complex event processing analysis, that are used by the Samurai platform.

Alert:

Security detection made by the Samurai platform or third party vendor where we are ingesting telemetry.

Boost Scoring:

Boost Scoring is a technique used by the Samurai platform which improves the ability to find Advanced Persistent Threats (APTs) by using a methodology which helps to link seemingly unrelated events.

Collector:

A Collector is responsible for ingesting telemetry (or logs) into the Samurai platform. There are three main types of Collector, namely Local Collectors, Cloud Collectors and Cloud Native Collectors. 

A Local Collector is a virtual appliance which is deployed in your environment. Typically you will use the Local Collector as the destination for syslog messages produced by your devices. 

A Cloud Collector provides the ability to ingest telemetry from cloud platforms and services, and is hosted centrally as part of the Samurai platform. You do not need to do anything to deploy a Cloud Collector.

A Cloud Native Collector is used to monitor public cloud storage and pull data into the Samurai ingestion platform.

Correlation:

The ability for our systems to find a common linkage in Logs or Events (via source or destination IP address, Common Vulnerabilities and Exposures identifier, or other attributes) and combine them within one Event to add context to an Alert.

Enrichment:

The process of adding contextual information (such as geolocation, evidence from packet captures or other data) to log information, either programmatically, or by a Security Analyst.

Event:

All of the individual data points (Telemetry) ingested via Collectors into the Samurai platform are known as Events. Through the use of Advanced Analytics, our systems are able to generate Alerts from Events which indicate the presence of threat actor activity. All events are stored in our data lake, and can be queried using Advanced Query.

Global Threat Intelligence Center (GTIC):

The organization within NTT’s Security Holdings responsible for, threat research, vulnerability tracking and the development, aggregation and curation of threat intelligence.

Integration:

Integrations provide the mechanism to ingest telemetry (in other words logs and data) into the Samurai platform.

Managed Detection and Response (MDR):

Samurai Managed Detection and Response is a service which delivers cybersecurity insights, advanced threat detection, response, and protection capabilities via the ingestion of varied telemetry sources including cloud, network, compute and mobility sources. Supported telemetry combined with our proprietary Advanced Analytics, analyst threat hunting, and AI-based threat detection capabilities translate to faster, more accurate detections and most importantly reduced business risk.

MITRE ATT&CK Framework:

MITRE ATT&CK^® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.

Threats detected by the Samurai platform are mapped against MITRE ATT&CK to assist in better understanding the nature of the activity detected, possible countermeasures and the urgency of response.

Samurai plaform:

Samurai is a vendor-agnostic, cloud native, scalable, API-driven, advanced threat detection, and response platform.

Samurai Hunting Engine

Intelligence-driven detection engine based on the Sigma project but customized by NTT with additional detection capabilities. The Samurai hunting engine performs automated threat hunting to idenfiy and alert on possible adversary activity.

Samurai Real-time Engine

Proprietary NTT developed detection engine that leverages behaviour modeling, machine learning, and the latest threat research to automatically identify suspected threats during real-time analysis of ingested telemetry into Samurai.

Security Incident:

A notable threat to a client environment detected and validated via automation or by Security Analysts. Security Incidents may require a response to mitigate or eliminate the identified threat. Information related to Security Incidents are available via the Samurai MDR portal and downloadable in PDF format as required.

Severity:

Severity is the term used to describe the potential magnitude of impact of a detected threat which is presented as a Security Incident. Severity is presented as Unknown, Low, Medium, High or Critical.

Telemetry:

In the context of Samurai, Telemetry refers to the data, usually in the form of logs, collected from different security solutions and other sources which is then ingested into the Samurai platform. This includes but is not limited to network, firewall , DNS, email, endpoint, server, and cloud workloads.

Each telemetry source contains different types of activity data. The Samurai platform is able to collect a wide variety telemetry in order to detect and hunt for unknown threats and assist in forensic analysis.

Tenant:

A tenant is the entity used to represent an organization using Samurai. Individual users can be invited to one or more tenants.

4 - Telemetry Data Source Categorization

Samurai telemetry support is categorized using the following three levels. These categories describe the estimated value that a specific telemetry data source is expected to add to the Managed Detection & Response (MDR) service, whilst providing clarity and expectations of threat detection capabilities.

1. Foundation

• Vendors and technologies with excellent threat detection, validation and hunting capabilities and where evidence collection is performed (such as IDS/IPS).

2. Detection

• Vendors and technologies with good threat detection capabilities and where evidence collection is performed (such as Sandbox). Although best offered in combination with Foundation sources, Detection level sources are sufficiently high value to be monitored in isolation.

3. Enrichment

• Vendor and technologies with no / limited threat detection / validation capabilities in isolation. Used mainly for correlation, Threat Hunting and Enrichment purposes in combination with Foundation/Detection sources.

Some examples:

• An IDS/IPS telemetry source where full API integration is available and evidence (e.g Packet Capture - PCAP) is collected for analysis would be used for threat detection purposes. However the same technology type without such an integration (e.g syslog only) would only provide data with no actual detail in support of qualifying threats, and would therefore primarily be used for Enrichment purposes in relation to events from sources of a higher support level.
• A DHCP log would add no actual detection capability, but it can be used to identify the actual physical host in a network using dynamic net assignment.

For technologies consisting of a combination of data source types, our policy is that the highest level of support that a source reaches also determines the overall support category of the technology.

For example, a Unified Threat Management (UTM) data source consisting of multiple types (e.g. Firewall, URL, IDS/IPS, Sandbox) would when evidence collection is supported (e.g. PCAP, Sandbox Execution reports) be categorized as a Foundation source as the IDS/IPS with PCAP collection is considered to be at such a level.

A UTM consisting of the same source types, without evidence collection, would be categorized as Detection support as the highest level source would be at Detection level (e.g. URL/FW).

All supported telemetry data sources with the assigned category can be found under Supported Integrations.