Noname Security Platform Updates: 3.30 Release

The latest Noname Security 3.30 update includes a new feature that allows for convenient tracking of attacker IP addresses, as well as improved options for triggering workflows to resolve attacks faster. Additionally, the process of installing Noname Remote Engine on local Kubernetes clusters has been simplified.

Core Platform

Configurable User Identifiers

The Noname platform relies on user identifiers to build a baseline behavior for APIs, correlate incidents or attacks, and calculate an attacker confidence score. With this release, you can now configure the location of user identifiers in APIs. This ensures that Noname can extract the correct identifier even if it is placed in custom objects, headers, or JSON web tokens (JWTs) claims. For example, you can now configure Noname to search API headers for specific usernames to identify users. Configurable user identifiers help finetune how Noname correlates anomalies to attacks to block attackers with higher precision.

To learn more about this feature, please see the documentation for Configuring Authentication and Identification.

Combined traffic and prevention for the Apigee plugin

Apigee traffic source and prevention integrations are now combined into a singular process. Previously, the traffic source integration only allowed you to analyze API traffic for vulnerabilities from various environments. At the same time, the prevention integration only enabled you to block suspicious or harmful API runtime activity. Now, Apigee traffic analysis and prevention integrations are combined into a unified plugin, removing the need for separate configurations for traffic ingestion and attack blocking and offering a more efficient deployment experience.

Attacker IP history

The Attackers View in the Runtime module is now enhanced with additional IP-related information about the attacker. The IP Addresses pop-up includes an attacker’s IP history, country, IP reputation score, and unique autonomous system numbers (ASN). This provides visibility into Internet Service Providers (ISPs) an attacker is using and ensures you have the relevant IP information at your fingertips.

Attacker Workflow Improvements

With this release, you can now define additional triggers to invoke workflows associated with attacks. Previously, you could only initiate workflows when a new incident was created. Now, you can start attacker workflows based on additional events and signals. For example, you can now create a policy to initiate blocking when an attack confidence score exceeds a 95% threshold. Additionally, when an API access from a high-risk IP is identified, you can immediately send a Slack notification to the relevant team for follow-up. This allows you to react to attacks in near-real-time, define more granular workflows, and accelerate ‌remediation timelines.

To learn more about attacker workflows, please see workflow documentation.  

Edit predefined datatypes

The Noname platform provides several datatypes to identify personally identifiable data (PII), payment information, credentials, and other sensitive records in the data flowing through your APIs. With this release, you can customize out-of-the-box datatypes to align with your organizational data handling. For example, you can customize the PII datatype according to the way you specify customer addresses. You can also disable the credentials datatype if you expect APIs to contain unencrypted temporary passwords. This allows you to reduce false-positive errors and improve classification accuracy.

To learn more about datatype modifications, please click here.

Enhanced Expired Authentication Token findings

Noname Security can identify expired JSON Web Tokens (JWT) authentication tokens in your APIs and flag them in your Findings. When a client presents an expired JWT to an API endpoint, the expiration is checked, and the token should be rejected. However, some APIs can accept expired JWTs, which can lead to unauthorized access. With this release, it is now easier to spot specific token expiration information in your APIs, and the explanations for these types of Findings are more user-friendly.

Remote Engine Deployment Enhancement (Private Preview)

The Noname Remote Engine can now be deployed on self-hosted or managed K8S clusters using a native Kubernetes Operator. Previously, Remote Engine deployment was a resource-intensive project that involved multiple configuration steps. Now, Kubernetes Operator can manage the entire lifecycle of Remote Engine deployment, including engine version updates. This allows you to perform actions based on specific events in the cluster and automate operational tasks. For example, Remote Engines deployed with this new method can auto-update to ensure you use the latest detection logic and newest Noname capabilities. 

Remote Engine deployment is currently in Private Preview.  

For additional information about the Noname Security 3.30 release, please review the release notes.