At Akamai, our mission is to make application and API security highly effective and easy. As part of that effort, we are excited to announce the Adaptive Security Engine — a new core technology powering Akamai’s application and API protection offerings, designed to enable a hands-off approach to protecting web applications and APIs with the highest degree of confidence.  

Our North Star while architecting the new engine was to give customers:

• Strong, high-quality security outcomes
• High confidence in protecting applications and APIs without gating app-dev teams and impacting legitimate users
• A high degree of available configuration and automation flexibility
• A low- to no-touch operational experience for protecting entire web application and API estates — at scale

Although the above is achievable today, our newest technology is designed to take security outcomes to the next level — a quantum leap in delivering the best defense while simultaneously reducing operational friction. At Akamai, protecting apps and APIs is what we do best — as evidenced by our market-leading position and validated by the customers we successfully serve — and this passion has continued to accelerate our journey to breakthrough ideas.

Let’s dive into the latest technologies behind the Adaptive Security Engine and how they work together to optimize protections and drive out complexity for our customers.    

Adaptive threat detections 

Supreme coverage and accuracy with the ability to adapt automatically to new threats

Akamai’s unparalleled visibility into malicious activity across more than 1.3B daily client interactions across the internet gives us unique insight into attackers armed with new tactics, tools, and skills. The intelligence derived from this insight allows us to understand the different risk profiles of incoming requests attempting to hit your applications and APIs. 

We’ve created a new multidimensional threat scoring model that combines this platform intelligence with data/metadata from each request. We then action this data with decision-making logic designed to accurately identify real attacks. Adaptive detections are especially effective in identifying highly targeted, evasive, and stealthy attacks since sophisticated attackers invest more effort and reconnaissance to uncover vulnerable entry points. As attackers scan for vulnerabilities and misconfigurations, we collect and build correlating evidence about their tactics. This not only makes them immediately identifiable, but it leaves behind a historical fingerprint of the types of activities being undertaken should they return later. The harder an attacker tries, the more aggressive our protections get.

In addition to the actual payload and its location within the request, examples of other attack dimensions evaluated for each client include:

• History of reconnaissance or actual attacks against the protected app/API or others on the Akamai platform 
• Any signs of malicious automation and attack tooling 
• Correlation to known sources of attack traffic

The underlying detection engine was fully re-calibrated and enhanced with two new technologies: Smart Detect, which tokenizes the input into a fingerprint for highly accurate detection; and Smart Sniff, which detects the right content-type of the request body to prevent content manipulation and bypass. 

Adaptive detections are automatically updated by Akamai’s threat research to ensure that you are using the latest and strongest protections available. We leverage our expansive infrastructure and systems to passively run all new detections — across the entire Akamai production traffic — and analyze results using machine learning (ML) models for the highest accuracy. This gives you the confidence that automated protections are not just lab-tested against synthetic traffic, but are battle-tested against real-world conditions. 

Self-tuning 

Yes, we are declaring war against any and all points of friction in application and API protection 

The sheer number of alerts that continue to overwhelm security teams make it virtually impossible for analysts to assess and tune every policy. The goal of self-tuning is to take this problem head-on and alleviate security professionals from manual tuning, which can lead to outdated policies, human error, and alert fatigue.

While the new Adaptive Security Engine has been shown to dramatically lower false positives out of the box, it may not lower the number to zero for every application (nor do we claim it will). Self-tuning will, however, move this outcome closer to reality by applying ML, statistical models, and heuristics across all triggers for each of your security policies to accurately differentiate between real attacks and end-user traffic misidentified as attacks. Most notably, it is not a generic platform-wide check that is applied only during initial onboarding, but a continuous process performed 24/7/365, for each of your individual policies without the need for any end-user configuration or intervention.

Figure: Adaptive Security Engine with Self-Tuning

Self-tuning was purposely built to be frictionless and simple. You can opt to receive email alerts when new tuning recommendations are available; then, you can easily review and accept recommendations with one-click via the UI, or automate using AppSec APIs, command-line interface (CLI) or Terraform provider. For greater transparency, a pre-filtered link to Web Security Analytics shows all requests deemed as false positives, and our rationale is provided for each recommendation. While this in itself significantly reduces the operational friction, we won’t stop here. We’re already planning the next iteration of self-tuning where you’ll be able to pre-delegate the “acceptance of recommendations” to Akamai to automatically integrate self-tuning with new detections for a truly zero-touch approach to application and API security.

Configuration and automation flexibility

However you want to configure and automate: We have a tool for that!

Adaptive Security Engine has a happy path that is good for a vast majority of customers who want the most balanced experience and security outcome. But if you like to be hands-on with things, Adaptive Security Engine offers an expert mode level of flexibility to run simulations with detection logic; modify debug header behavior and request inspection size; and have a complex set-up of exceptions and conditions for specific policies, hostnames, paths, etc. 

Security and DevOps teams can also operationalize security by integrating calls to Akamai APIs using the CLI, Akamai Terraform, or scripts in your CI/CD automation pipeline. This can not only enable rapid onboard applications, but also uniform management of security policies across large application portfolios, centralize security enforcement across hybrid and multi-cloud infrastructures, and improve collaboration between DevOps and security teams in a GitOps workflow for optimal coverage. Configuration and automation flexibility ensure that powerful security never hinders development velocity.  

It’s time for a new generation of security

To successfully reduce security gaps and mitigate the biggest risks, you need application and API security that not only identifies and stops the most sophisticated attacks, but is easy to use and maintain. Let’s face it: Your security teams don’t have the time to manually investigate every security trigger or tune every policy. At Akamai, we understand that complex security products and operational friction lead to risk; that’s why the new Adaptive Security Engine is designed to intelligently analyze all threats as they arrive in real time, provide security analysts with valuable inputs for far easier decision-making, and reduce false positives in both attack detection and traffic noise.

It’s simple. Security teams today need to automate defenses to better respond to threats across the enterprise without a human having to do that work, while also confirming that the security controls they do have operate with maximum efficiency and flexibility. Threat actors are automating, scaling, and commoditizing their attacks — automating your web application and API defenses in parallel will improve your ability to manage cyberthreats at pace. 

To learn more about the Adaptive Security Engine and Akamai’s web application and API security solutions, contact your Akamai representative.

The post The Adaptive Security Engine — A Quantum Leap Forward for Application and API Protection first appeared on Techcity Company Limited.

A critical remote code-execution vulnerability (CVE-2021-44228) has been publicly disclosed in Log4j, an open-source logging utility that’s used widely in applications, including many by large enterprise organizations. 

The vulnerability allows threat actors to exfiltrate information from, and execute malicious code on, systems running applications that utilize the library by manipulating log messages. There are already reports of servers performing internet-wide scans in attempts to locate vulnerable servers, and our threat intelligence teams are seeing attempts to exploit this vulnerability at alarming volumes. Log4j is incorporated into many popular frameworks and many Java applications, making the impact widespread.

Akamai’s extensive security suite, including Application and API Security solutions, Secure Internet Access Enterprise, and Guardicore Segmentation, is well positioned to help address this vulnerability in different ways. It’s highly recommended that organizations update Log4j to its latest version, 2.16.0. Due to the rapidly escalating nature of this vulnerability, Akamai teams will continue to develop and deploy mitigation measures to support our customers. 

What is the Log4j vulnerability?

On December 9, 2021, a critical vulnerability involving unauthenticated remote code execution and data exfiltration (CVE-2021-44228) in Log4j was reported, causing concern due to how commonly the open source logging function is used. This widespread usage, combined with the ease of exploitation, makes its impact particularly large. The vulnerability is actively being exploited, and security teams worldwide are working on research and mitigations.

A compromised machine allows a threat actor to exfiltrate data and remotely provide software that Log4j executes. This grants an attacker the ability to run arbitrary commands inside a server, exposing information and secrets, as well as allowing that server to be a launchpad for additional attacks, potentially against machines secured deep inside of a network with no direct access to the internet.

Developers in the Java world use Log4j extensively to facilitate the logging of errors and debug information. As a result, product vendors whose software is based on Java may be vulnerable. Even if an application doesn’t use Log4j directly, many common tools and frameworks use Log4j internally and thus may introduce this vulnerability into the application stack.  

What is the severity of the Log4j vulnerability?

Although Akamai first observed exploit attempts of the Log4j vulnerability on December 9, we see growing evidence suggesting it may have been exploited for months. Since publication of the vulnerability, we have seen multiple variants of the exploit at a sustained rate of attack traffic of around 2M attempts per hour. The speed at which the variants are evolving is unprecedented. 

More than half (~57%) of the attacks seen so far are from attackers previously classified as malicious actors in Akamai’s threat intelligence database. We anticipate that due to the sheer volume of unpatched systems, we will continue to see exploit attempts for months to come. Akamai’s security research and incident response teams continue to monitor and protect our infrastructure and customers, leveraging our unique visibility and intelligence.

While the most important action to take during any vulnerability is to patch infected systems, security researchers understand that takes time. In many instances, organizations might not yet even have visibility into which systems are vulnerable. As such, additional mitigations must be deployed to reduce the threat surface as much as possible.

To assist in this, Akamai has a number of recommendations. At this time, the greatest amount of attack traffic that we are seeing associated with Log4j is web application–based, therefore the most impactful step that organizations can take after patching is to leverage Akamai’s Web Application and API protections. Read on to learn how and what to do inside your enterprise as attack vectors evolve. 

Mitigating Log4j abuse using Akamai App and API Protection suite

Akamai continues to update web application firewall (WAF) rules to provide protection against this exploit and its many variants. This includes updating rule 3000014 within Akamai’s Kona Rule Set and Adaptive Security Engine. For customers using the Automated Attack Groups, we have updated the Command Injection group. Any customers who currently have those rules or attack groups activated in DENY mode will receive automatic in-line protection for the following protection engines and versions:

• Kona Rule Set — Any version dated October 29, 2019 or later
• Automated Attack Groups — Any version
• Adaptive Security Engine — Any version

Many servers, especially those in high-risk environments such as directly accessible to the internet, may already have been compromised. To identify indicators of compromise, the following command can show exploitation attempts:

sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns)://’ /var/log

To learn more about Akamai’s Web Application and API protections, read more or contact us.

While WAF protections can be highly effective for web servers at this stage, organizations must also consider alternative avenues of attack that may have led to compromise. To that end, we recommend employing microsegmentation to gain visibility to possible exposure and to reduce risk and spread. 

Detection of Log4j abuse using Secure Internet Access Enterprise

Akamai threat researchers have been reviewing customer DNS, proxy, and sinkhole data looking for anomalous behavior relating to the actors attempting to use Log4j vulnerability in the wild. In the DNS data, we were surprised to see DNS queries for domains containing the string “jndi:ldap”. These are invalid DNS queries that contain invalid characters in the domain name and therefore will not resolve. Additionally, we have seen traffic to known malicious domains that were redirected to sinkhole servers; those domains hosted malicious Java code that was used to abuse vulnerable servers. All of these are indications of potential abuse within customer networks. 

Mitigating Log4j abuse using Akamai Guardicore Segmentation

Customers using Akamai Guardicore Segmentation can leverage its process-level visibility to identify vulnerable applications and security risks in the environment. This can then be used to enact precise control over network traffic to stop attacks on vulnerable systems, without disruptions to normal business operations.

What’s under threat: Identify vulnerable Java processes and Log4j abuse

To protect against potential Log4j abuse, it is necessary to first identify potentially exploitable processes. This requires deep visibility into network traffic at the process level, which is provided by Akamai Guardicore Segmentation. Precise visibility into internet connections and traffic allows us to see clearly what mitigation steps need to be taken without disrupting business operations. 

Stopping the attack: Block malicious IoCs and attack vectors

It is imperative to be able to take action once vulnerable applications have been identified. While patching is underway, Akamai Guardicore Segmentation offers a multitude of options for alerting on, stopping, and preventing attacks. Critically, a solution with detailed and precise control over network communication and traffic is required to surgically block or isolate attack vectors, with minimal to no disruption to normal business functions. These include:

• Automatic IoC blocking with Threat Intelligence Firewall (TIFW) and DNS Security 
• Fully quarantine compromised servers 
• Block inbound and outbound traffic to vulnerable assets 
• Block outgoing traffic from Java applications to the internet

Additionally, Guardicore Hunt customers have their environments monitored and investigated continuously by a dedicated team of security researchers. Alerts on security risks and suggested mitigation steps are immediately sent.  

If you’d like to hear more about Akamai Guardicore Segmentation, read more.

Conclusion

Akamai will continue to share its insights as we closely monitor and research Log4j exploits and provide timely updates to our protections and capabilities.

The post Akamai Recommendations for Log4j Mitigation first appeared on Techcity Company Limited.

The post Secure Internet Access first appeared on Techcity Company Limited.

The post Akamai Guardicore Segmentation first appeared on Techcity Company Limited.

The post Account Protector first appeared on Techcity Company Limited.

The post Identity Cloud first appeared on Techcity Company Limited.

The post Bot Manager first appeared on Techcity Company Limited.

The post Akamai MFA first appeared on Techcity Company Limited.

The post Managed Security Service first appeared on Techcity Company Limited.

The post Page Integrity Manager first appeared on Techcity Company Limited.

The post Prolexic first appeared on Techcity Company Limited.

The post App & API Protector first appeared on Techcity Company Limited.