February 21, 2024

All rights reserved. This product and documentation related are protected by copyright and distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this product or documentation related may be reproduced in any form or by any means without the prior written authorization of SOC Prime. While every precaution has been taken in the preparation of this book, SOC Prime assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

Threat Detection Marketplace

Rule Deployment into On-Prem Elastic Stack Environments

We've improved the capabilities of deploying rules into on-prem Elastic Stack environments by adding the possibility to:

Create a dedicated Data Plane for on-prem Elastic Stack
Set up a Job with a Config, a Preset, and a Custom Field Mapping profile and deploy the rules from the Job via TDM API Integration Tool

Now, the flow of deploying rules is as follows:

Configure a Data Plane (no credentials required).
1. Go to Account icon > Platform Settings > Data Planes and click Add Data Plane.
2. In the modal that appears, select Elastic Stack as your platform and enable the On Pem switch.
3. Name your Data Plane and choose whether to share it to your company.
4. Select Automation and direct deployment from a Sigma rule page as the place to use the Data Plane.
5. Click Save Changes
Create a Job.
1. Go to Threat Detection Marketplace > Automation > Jobs and click Create Job.
2. Name your Job.
3. Select Elastic as your platform and set the content type to Detection Rule (Lucene) or Watcher (currently, only these two content types can be deployed into on-prem environments).
4. Select the Tenant to which the Data Plane created in the previous step belongs, and then select the Data Plane itself.
  
  Note:
  You can set both on-prem and cloud Data Planes in the same Job. In this case, the deployment into the cloud Data Plane will be carried out by TDM's automation, while deployment into the on-prem Data Plane will be performed by TDM API Integration Tool.
5. Select the Content Lists from which you want to deploy content.
6. Choose if you want to Use Default Custom Field Mapping based on Log Source. Optionally select the Config for alternative translations and Presets.
7. The value of the Schedule dropdown does not matter since it's the TDM API Integration Tool that performs the deployment to on-prem environments.
8. Click Save Changes.
9. Enable the Job on the Jobs page.
Install the TDM API Integration Tool and configure deployment into your on-prem Elastic Stack environment.
1. Download TDM API Integration Tool from the corresponding Content Pack on Threat Detection Marketplace.
2. Install the Tool following the instructions provided in its Guide (it can be downloaded from the Content Pack page as well).
3. In the Tool's config file:
  - Set the input type to job and set the job_name parameter to the name of the Job you've created in Threat Detection Marketplace.
  - Set the output type to xpack-watcher (corresponds to the Watcher content type in Job settings) or elasticsearch-rule (corresponds to the Detection Rule (Lucene) content type in Job settings). Set the output parameters according to the TDM API Integration Tool's guide.
  - Set other parameters in the config file according to the TDM API Integration Tool's guide.
4. Run the TDM API Integration Tool's script to deploy the content linked to the specified Job.

Uncoder AI

Support for Roota

We've added support for translating from Roota, a public-domain language for collective cyber defense, created to make threat detection, incident response, and actor attribution simple. It acts as an open-source wrapper on top of the majority of existing SIEM, EDR, XDR, and Data Lake query languages.

From Roota, you can translate into the following formats:

Platform	Type	Data Schema
AWS Athena	Query	OCSF
AWS OpenSearch	Query (Lucene)	ECS
AWS OpenSearch	Rule (JSON)	ECS
Chronicle Security	Query (UDM)	UDM
Chronicle Security	Rule (YARA-L)	UDM
CrowdStrike Endpoint Security	Query (SPL)	Default
ElastAlert	Alert (Lucene)	ECS
Elastic Stack	Query (Lucene)	ECS
Elastic Stack	Detection Rule (Lucene)	ECS
Elastic Stack	Rule (Watcher)	ECS
Elastic Stack	Kibana SavedSearch (JSON)	ECS
Falcon LogScale	Query	Default
Falcon LogScale	Alert	Default
Graylog	Query	Default
IBM QRadar	Query (AQL)	LEEF
Microsoft Defender for Endpoint	Query (Kusto)	Default
Microsoft Sentinel	Query (Kusto)	Default
Microsoft Sentinel	Rule (Kusto)	Default
Sigma	Sigma	Default
Splunk	Query (SPL)	Default
Splunk	Alert (SPL)	Default

To learn more about Roota's capabilities and check out its specifications, visit the dedicated GitHub repository.

More Cross-Platform Translations

We've expanded the range of supported cross-platform translation languages (also known as "reverse translations") and improved their quality. Now, the following languages are available for reverse translations:

Platform	Source	Target
AWS Athena: Query with OCSF data schema	✅	✅
AWS OpenSearch: Query (Lucene) with ECS data schema	✅	✅
AWS OpenSearch: Rule (JSON) with ECS data schema	–	✅
Chronicle Security: Query (UDM) with UDM data schema Rule (YARA-L) with UDM data schema	✅	✅
CrowdStrike Endpoint Security: Query (SPL) with Default data schema	✅	✅
ElastAlert: Alert (Lucene) with ECS data schema	–	✅
Elastic Stack: Query (Lucene) with ECS data schema Detection Rule (Lucene) with ECS data schema	✅	✅
Elastic Stack: Rule (Watcher) with ECS data schema Kibana SavedSearch (JSON) with ECS data schema	–	✅
Falcon LogScale: Query with Default data schema Alert with Default data schema	✅	✅
Graylog: Query with Default data schema	–	✅
IBM QRadar: Query (AQL) with LEEF data schema	✅	✅
Microsoft Defender for Endpoint: Query (Kusto) with Default data schema	✅	✅
Microsoft Sentinel: Query (Kusto) with Default data schema Rule (Kusto) with Default data schema	✅	✅
Sigma: Rule	✅ (Translation from Sigma does not require the reverse translations balance)	✅
Splunk: Query (SPL) with Default data schema Alert (SPL) with Default data schema	✅	✅

Note:

A checkmark against a language in the Source column means that this language can be translated into all languages checkmarked in the Target column.
A checkmark against a language in the Target column means that translations can be generated into this language from all languages checkmarked in the Source column.

Also, Uncoder AI supports:

Translating between different formats of the lame platform (does not require the reverse translations balance):
- AWS OpenSearch:
  - Query (Lucene) with ECS data schema → Rule (JSON) with ECS data schema
- Chronicle Security:
  - Query (UDM) with UDM data schema ↔ Rule (YARA-L) with UDM data schema
- Elastic Stack:
  - Query (Lucene) with ECS data schema ↔ Detection Rule (Lucene) with ECS data schema
  - Query (Lucene) with ECS data schema → Rule (Watcher) with ECS data schema
  - Query (Lucene) with ECS data schema → Kibana SavedSearch (JSON) with ECS data schema
  - Detection Rule (Lucene) with ECS data schema → Rule (Watcher) with ECS data schema
  - Detection Rule (Lucene) with ECS data schema → Kibana SavedSearch (JSON) with ECS data schema
- Falcon LogScale:
  - Query with Default data schema ↔ Alert with Default data schema
- Microsoft Sentinel:
  - Query (Kusto) with Default data schema ↔ Rule (Kusto) with Default data schema
- Splunk:
  - Query (SPL) with Default data schema ↔ Alert (SPL) with Default data schema
Remapping to OCSF (does not require the reverse translations balance):
- AWS OpenSearch Query (Lucene): ECS to OCSF
- AWS OpenSearch Rule (JSON): ECS to OCSF
- Elastic Stack Detection Rule (Lucene): ECS to OCSF
- Elastic Stack Query (Lucene): ECS to OCSF
- Falcon LogScale Alert: Default to OCSF
- Falcon LogScale Query: Default to OCSF
- IBM QRadar Query (AQL): LEEF to OCSF
- Snowflake Query (SQL): Default to OCSF
- Splunk Alert (SPL): Default to OCSF
- Splunk Query (SPL): Default to OCSF
- Sumo Logic Query: Default to OCSF

Key Bug Fixes & Improvements

With this release, we’ve made the following key bug fixes and improvements to enhance the user experience with the SOC Prime Platform:

Improved displaying of rules saved as unstructured JSON. Now, when the user opens such rules in Threat Detection Marketplace, they are automatically presented in a prettified manner while the code stays unstructured. This was implemented for the following platforms:
- Microsoft Sentinel Rule
- Elastic Stack Detection Rule (Lucene)
- Elastic Stack Detection Rule (EQL)
- Elastic Stack Saved Search
- Elastic Stack Watcher
- Sumo Logic CSE Rule
- Falcon LogScale Alert
Fixed a bug where the linked Job was not displayed for some Content Lists on the Lists page
Fixed an issue in translations from Sigma into Chronicle Security Rule where an integer in the detection values could be translated as None
Fixed a wrong text message on the first step of the Single Sign-On Login flow
On the Video Tutorials page, renamed the Copy button to Share and moved it under the video
Updated the style of the Close icon on the modals to create/edit Filters, Presets, and Search Profiles
Fixed a layout issue where the message about the successful change of the industry was overlapped by the header
Fixed the layout of the buttons on the Oh, something went wrong! modal
Added to the TDM API proper handling of the error when the user tries to apply a Custom Field Mapping to a rule saved as a non-valid JSON in a custom repository
Fixed a bug where alternative translations did not have a proper reference link to the original TDM rule
Resolved an issue where updating an Elastic Stack Detection Rule (Lucene) via Inventory sometimes resulted in an error
Fixed a bug where the rules automatically unlocked via a Job were deployed only on the second run of the Job
Fixed a bug in Uncoder AI where the Custom Field Mapping field was shown as available for Apache Kafka ksqlDB, while actually Custom Field Mapping for this platform is not supported

SOC Prime Platform Product Release Notes 5.10.1