November 2024 (2)

Juniper Networks is a leading provider of high-performance networking equipment and software, specializing in routing, switching, and security solutions for enterprises and service providers. Focused on simplifying network operations, Juniper leverages AI-driven platforms like Mist AI to enhance performance and streamline troubleshooting for organizations worldwide.

The new integration includes:

• 2 supported logs -

  • Juniper Switch Logs

  • Juniper Firewall Logs

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

• Mapping to the Hunters Login Schema and Network Schema

Learn more here

Microsoft Defender Advanced Hunting logs provide rich data sets that enable security analysts to proactively search for potential threats across an organization’s environment. These logs contain detailed information about events such as file creation, network connections, and process activities, which can be queried using Kusto Query Language (KQL). Advanced hunting in Defender allows for real-time analysis, pattern detection, and correlation of security incidents, helping teams identify and respond to attacks more efficiently.

⚠️ IMPORTANT

These logs replace the following:

• Some data types under Defender for Endpoint (see here)

• Defender XDR Identity Query logs

The new integration includes:

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

Learn more here

OpenStack is a free, open standard cloud computing platform. It is mostly deployed as infrastructure-as-a-service (IaaS) in both public and private clouds where virtual servers and other resources are made available to users. The software platform consists of interrelated components that control diverse, multi-vendor hardware pools of processing, storage, and networking resources throughout a data center. Users manage it either through a web-based dashboard, through command-line tools.

The new integration includes:

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

Learn more here

Databricks is a cloud-based data analytics platform that unifies data engineering, science, and machine learning. Built by the creators of Apache Spark, it combines data lake and warehouse capabilities, enabling organizations to manage, process, and analyze data at scale on major cloud providers like AWS, Azure, and Google Cloud.

The new integration includes:

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

Learn more here

CloudSEK is a cybersecurity company specializing in predictive threat intelligence powered by artificial intelligence. It offers solutions like XVigil, which monitors and identifies threats such as data leaks, phishing attacks, and brand impersonation across the web, including the dark and deep web. CloudSEK focuses on proactive risk management, helping organizations mitigate potential threats before they escalate. Its AI-driven approach provides real-time insights and actionable intelligence, empowering businesses to protect their assets and reputation effectively.

The new integration includes:

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

Learn more here

Keycloak is an open-source identity and access management solution offering SSO, user management, and support for OAuth 2.0, OpenID Connect, and SAML. It simplifies authentication and authorization for apps with features like social login, multi-factor authentication, and a user-friendly admin console.

The new integration includes:

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

• Mapping to the Hunters Login Schema

Learn more here

Wiz's EKS Runtime logs contain monitoring and security insights provided for Amazon Elastic Kubernetes Service (EKS) workloads. Wiz enhances cloud-native security by analyzing runtime logs to detect misconfigurations, vulnerabilities, and runtime threats within EKS clusters. These logs provide real-time visibility into containerized applications, helping organizations identify suspicious behavior, such as unauthorized access or privilege escalation. By integrating runtime logs with Wiz’s broader cloud security platform, teams can ensure compliance and maintain a robust security posture across Kubernetes environment

The new integration includes:

• Ingestion of the data to the data lake

• Mapping the data to IOC Search

Learn more here

Detector ID: nozomi_alerts

We’ve created a new third-party detector for Nozomi, bringing in highly suspicious Nozomi alerts. As Nozomi alerts are very frequent and noisy, this detector was designed to exclude the majority of false positives by filtering out posture-like alerts, such as alerts with a Type ID of INCIDENT:WEAK-PASSWORDS,  SIGN:CLEARTEXT-PASSWORD, and more. It will also filter out alerts originating from known vulnerability scanners (e.g., Qualys), and in some use cases, filter out alerts that don’t involve inbound/outbound internet traffic.

Detector ID: edr_comsvcs_process_dump

We’ve enhanced coverage to include obfuscated commands, including special characters, escape sequences and unusual syntax such as junk data.

Detector ID: edr_cmd_suspicious_silent_execution_patterns

We’ve enhanced coverage to detect more cases and escape attempts, ensuring better visibility and protection against additional techniques.

Detector ID: microsoft_365_defender_cloud_application_alerts

Following internal quality improvement monitoring we’ve found that this third-party detector generates a massive number of leads and all are being added to the SOC queue.

To improve this, we’ve adjusted the SOC queue threshold and scoring layer to:

• Increase the default SOC queue threshold from 1 to 6 and keep the base Confidence score at 5.

• Add confidence modifiers to increase confidence when the alert Severity value is Medium or High.

• Only Medium and High severity alerts will enter the SOC queue.

These actions will reduce the number of alerts from this detector by 75%.

Detector ID: claroty_ctd_alerts

While previously, this detector alerted only on "Known Threat" type alerts, it will now present all relevant alerts from Claroty CTD. In addition, the CTD Login and CTD Denial of Service alerts have a separate processor and will not enter the SOC queue ( claroty_ctd_dos_alerts and claroty_ctd_login_alerts).

The alerts will display information about the source and destination devices, and divide them into three categories:

• OT Device

• IoT Device

• IT Device

Detector ID: guardduty_ec2_findings

This third-party detector was found to be overflowing the SOC Queue with a large number of alerts, by default. To solve this issue, we’ve performed the following steps:

• Adjusted the SOC queue threshold for this detector by increasing the default SOC queue threshold from 1 to 4 and keeping the base confidence score at 5.

• Added a new custom rule that will lower confidence for events of port probing for ports that are not included in NMAP’s top 100 ports.

• Applied the following adjustments to the existing scoring layers:

  • Confidence will increase if the remote IP or requested domain are not benign according to PulseDive.

  • Confidence will increase if the remote IP or requested domain were found in one of our TI feeds.

These actions will reduce the number of alerts in the SOC queue by 84%.

Previously, our third-party alerts for CrowdStrike were based on the “Detects API” and with it older event types, which according to CrowdStrike will be deprecated in the upcoming year. This legacy API posed challenges due to its non-linear and stateful event structure, leading to potential data oversight, as events could update post-detection, and problems with extracting the data since it was all grouped under various arrays.

To address these limitations, we are transitioning to the CrowdStrike Falcon “Event Streams API”. The new system utilizes the EppDetectionSummary and XdrDetectionSummary events, which treat each update as an individual event, resulting in a more consistent and reliable detection process.

In response to this change, we have developed two new detectors designed to support the new API structure:

crowdstrike_endpoint_detection_alerts (based on EppDetectionSummaryEvent)

crowdstrike_xdr_detection_alerts (based on XdrDetectionSummaryEvent)

We have ensured that all relevant scoring and Enrichment processes are operational on these new detectors.

We highly recommend integrating CrowdStrike alerts via the new API and transitioning to these updated detectors to take full advantage of the enhancements made.

Detector ID: cs_new_lsass_access_from_unsigned_module

As part of an ongoing content quality monitoring process, we’ve found that this detector was noisy due to the learning key being very volatile and affected by uuids, username folders, and different product versions. To solve this issue we’ve performed the following steps:

• Created a normalized version of the learning key that is more stable and less volatile.

• TTL was extended from 30 days to 60 days.

• We filtered out specific use cases of known legitimate executables that generate a lot of noise.

These improvements are expected to decrease noise by 45%.

Detector ID: edr_office_writes_suspicious_pe_file

As part of an ongoing content quality monitoring process, we decided to make the following updates to this detector:

• To support noise reduction, we created a normalized version of the learning key that is less volatile and more effective.

• By default, the detector’s leads did not enter the SOC Queue, regardless of the confidence. Due to the above-mentioned improvements in noise reduction, and further analysis, we’ve changed the settings so leads may enter the SOC Queue in case some of the scoring models raise the confidence. For example, if the written PE file (represented by “target file hash sha256”) has some positive VT results (VT scoring model), or the machine in scope is vulnerable.

These improvements are expected to decrease noise by 60% and allow 2% of the highly suspicious leads to enter the SOC Queue.

Detector ID: okta_logs_security_request_blocked

The change will take place on December 2, 2024.

The detector is based on Okta’s event for blocked requests ( event_type = security.request.blocked ). Hence, the severity is very low. Okta’s event doesn’t provide context regarding the user who tried to connect and presents only an internal Okta system user ( actor_alternate_id = system@okta.com ).

The low value of the detector (low severity and lack of context) does not justify the noise it creates that may reach thousands of leads per month.

Detector ID: azure_microsoft_security_alerts

The change will take place on December 2, 2024.

This detector produces alerts that are lacking information and context. Delving into the issue we found that the alerts are based on MICROSOFT.SECURITY/LOCATIONS/ALERTS/ACTIVATE/ACTION in AZURE_ACTIVITY. The events logged there have most of their fields censored.

We also found that the relevant alerts existed in other Office365 Third-party alerts such as microsoft_365_defender_endpoint_alerts.

These findings render azure_microsoft_security_alerts unnecessary and lacking minimum value.