This article was written and contributed by our partner, Akamai.

Enterprise IT infrastructure has evolved in numerous ways over the last 20 years. The critical applications that power modern businesses now often span on-premises infrastructure, cloud workloads, and software as a service (SaaS) platforms. In addition, applications are now accessed in more ways than ever. While direct interaction through traditional user interfaces remains common, many modern application use models do not have a human in the loop at all, instead consisting of machine-to-machine interactions through APIs.

Overall, this evolution has unlocked many business benefits. IT complexity has been reduced in many areas. Business processes have been streamlined and deeper and more impactful third-party partnerships are now possible. User experience has also improved since APIs enable many different third-party services to be integrated into an application, reducing the need for context switching. Finally, APIs can also improve application performance by breaking up monolithic applications into many microservices.

All this good news comes with a stark reality: Threat actors are also innovating. The distributed and interconnected nature of modern applications, along with new and unique attack vectors like APIs, create new opportunities for novel attacks that traditional enterprise security capabilities were not designed to protect against.

For enterprise security teams, this will require a shift in mindset from a perimeter-centric view of security to a strategy focused on modern application delivery and consumption models.

Rethinking the security perimeter

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: 

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

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

A modernized enterprise security architecture

Twenty years ago, most enterprise environments had a well-defined perimeter, with firewalls acting as the primary control points (i.e., castle-and-moat network security). Beyond this perimeter was typically a very flat network and this made breaches an all-or-nothing proposition. Once a threat actor successfully gained access, little would prevent them from discovering vulnerable internal systems and using them to move laterally toward higher-value IT assets (Figure 1).

Once a threat actor successfully gained access, little would prevent them from discovering vulnerable internal systems and using them to move laterally toward higher-value IT assets (Figure 1).
Fig. 1: A hacker can freely move within an enterprise environment after breaching the security perimeter

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.

Essential elements of a modern security architecture

Today, there is no perimeter. Accordingly,  modern security architecture must include the following elements:

A ZeroTrust Network Access (ZTNA) model that can defend against north-south attacks, including scenarios in which a threat actor compromises a legitimate user's device and/or credentials

An identity-based authentication and authorization to ensure that human and machine identities continuously verify that they are who they say they are and can access only the resources needed to perform their essential functions 

An adaptive and granular microsegmentation framework that mitigates east-west attacks by preventing threat actors from using an initial point of compromise to advance toward high-value on-premises or cloud assets

Advanced protection against the new and complex threats introduced by growing API use

Protection of applications against fraud and other vulnerabilities

Scalable defense of hybrid environments against distributed denial-of-service (DDoS)and DNS-based attacks

This type of modern enterprise security architecture drives a strong layered defense-in-depth approach, but increases the level of focus on application-level controls, such as web application and API protection (WAAP). But the recognition that breaches can never be avoided completely is equally important. This is why it's crucial to advance Zero Trust principles from theory to real-world implementation using techniques like ZTNA and microsegmentation to mitigate lateral movement (Figure 2).

This is why it's crucial to advance Zero Trust principles from theory to real-world implementation using techniques like ZTNA and microsegmentation to mitigate lateral movement (Figure 2).
Fig. 2: Akamai's protections safeguard internal systems from hackers and unauthorized users, in line with ZTNA best practices

Which devices to protect

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.

APIs require an entirely new security mindset

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.

An API flaw gets hung out to dry

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.

WAAP solutions are not enough

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.

The impact of API security

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.

Learn more about API Security and Akamai Contact an expert

Technologies