Modernizing Enterprise Security for An Application-Centric World

For decades, enterprise security has focused disproportionately on one thing: stopping attackers from breaking in. But while defense in depth remains an important priority, the concept of a security perimeter has changed significantly.

Of course, core IT assets — whether on-premises or cloud-hosted — still need to be identified and secured against external threats. In a growing number of cases, however, threat actors don’t need to break in at all. They are finding gaps in modern application delivery models, such as compromising the credentials of a trusted user or exploiting a flawed API implementation, that allow them to walk right in.

This new threat landscape requires a two-pronged security strategy: 

1. Find and eliminate gaps in security controls before they can be exploited 

2. Recognize that breakdowns are inevitable and take steps to limit the “blast radius” and accelerate detection and response when security incidents inevitably occur

In some cases, security teams attempted to mitigate this risk by adding additional firewall choke points within the internal network to slow threat actors’ progress. Unfortunately, more often than not, these architectures did more harm than good. They added significant cost and administrative overhead for security teams. They also introduced performance bottlenecks. And the policy enforcement they offered was often far too coarse to slow the advance of a sophisticated threat actor.

Identity security is pivotal to prevent breaches in perimeterless enterprises. As the traditional security perimeter dissolves, the emphasis shifts to verifying the identity of users and devices that access the network. This verification is central to the ZTNA model, which mandates that every access request be authenticated, authorized, and encrypted, irrespective of the request's origin. Aspects to consider and protect include: 

• Devices (how to ensure device compliance)

• Users (how users are authenticated)

• Networks (how users connect to our network)

• Applications (how users access data) 

• Data (how data is stored and used)

• Visibility and analytics (how data is processed and visualized)

• Automation and orchestration (how processes are automated) 

Akamai supports companies in their journeys to Zero Trust via many different capabilities, including multi-factor authentication (MFA), microsegmentation, and API security.

The explosion in API use in recent years has put an even bigger spotlight on the fact that the enterprise security perimeter as we once knew it no longer exists. By exposing APIs to the internet, enterprises are taking critical business logic and opening it up to the outside world. And while a WAAP platform can provide foundational protection for APIs, it is not practical to understand and contextualize a conversation between a client and an API by inspecting individual requests at the application perimeter. In many cases, legitimate and malicious API requests are completely indistinguishable from one another at this level.

Further amplifying API risk is the fact that APIs may be implemented by many different developers across the organization, each with varying levels of security awareness. It’s common for APIs to be spun up quickly to solve specific business problems. Even if the basics, such as sound authentication practices, are implemented, human nature is to assume that APIs will only be used for their intended purposes. For this reason, it’s common for APIs to be implemented without sufficient validation that their business logic cannot be abused.

Here’s a real-world example of this concept. Two California college students recently discovered a flaw in the implementation of an API in a network of widely used internet-connected laundry machines. The primary purpose of the API was to support a mobile application used to pay for the use of the machines, check account balances, and so forth.

The mobile application included guardrails for what users were allowed to do. However, the back-end API did not include any validation logic. By analyzing the network traffic while using the laundry app, students found they could circumvent the app’s security checks and send commands that were not available through the app itself directly to servers. For example, if the client requested that a drying cycle start, the API fulfilled the request. If the client requested that US$1 million be added to a customer’s account, the API fulfilled the request.

Although this is a basic example, you can start to see the tremendous potential that exists for threat actors to exploit flaws in API implementations to cause significant business harm. And the scary part is that a WAAP, though still important, cannot detect or stop these types of tactics.

An API request to load US$1 million to a laundry app wallet that rarely holds more than US$100 is highly anomalistic when viewed in context but is nearly identical to a legitimate API request from the perspective of a WAAP. This is why it’s essential to complement the foundational protection that WAAPs provide with ongoing behavioral analytics that can spot API abuse that would otherwise blend in with legitimate API activity.

Akamai’s investments in this area, including our recent acquisition of Noname Security, represent the next logical extension of the modern enterprise security architecture. Like microsegmentation, our API security capabilities now provide essential protection beyond the traditional concept of an enterprise perimeter.

Akamai’s acquisition of Noname Security, which we completed in June 2024, accelerates our market leadership in API security in several important ways. Noname’s capabilities enable our customers to extend visibility and intelligence across all API traffic locations and accommodate a much wider range of business, integration, and deployment requirements.

This all starts with visibility.

Noname Security’s data suggests that customers discover, on average, 40% more APIs in their environment than originally anticipated. This speaks to another important dimension of the modern API security challenge: It isn’t just that security teams may not have their arms around securing their APIs; they might literally not know that the majority of them even exist.

By enhancing API discovery capabilities, we enable our customers to truly understand the scope of their API risk and make informed decisions about how to prioritize improvements to their API security posture.

And when it’s time to execute those strategies, the advanced capabilities enabled by Noname Security will help Akamai customers:

• Extend API visibility and intelligence across all API traffic locations and accommodate a much wider range of business requirements

• Take advantage of a broad array of integration and deployment options across cloud-hosted, self-hosted, and distributed models

• Gain access to enterprise-ready features such as dashboards, role-based access control, self-service configuration, and an advanced automated response system

• Seamlessly integrate API security capabilities with the rest of their IT and security stack

Critically, Noname Security will also allow Akamai customers to “shift left” with their API security by testing APIs for vulnerabilities right from within the continuous integration and continuous delivery (CI/CD) pipeline. This approach combines proactive avoidance of API vulnerabilities with continual monitoring for signs of API abuse after the point of implementation.