From security at the perimeter to security at every interaction

If you pay attention to tech headlines, you’ve probably noticed that new security threats and breaches—particularly those involving APIs—are on the rise.

This isn’t because APIs are inherently vulnerable—if they are managed and configured properly, they are actually part of a robust enterprise security layer. And the uptick in security incidents is only partly because bad actors’ skills and tactics have continued to progress.

Rather, one of the biggest factors in all the breaches and vulnerabilities is that application development methods have evolved very rapidly, and not all enterprises’ security approaches have kept up.

security at perimeter.pngPut simply, the security models that enable the connected experiences that today’s customers expect are significantly different from the security models that provided adequate protection just a few years ago.

Before mobile apps, the data flow for creating a digital experience was very straightforward: a browser called a website attached to a database. In this approach to application development, the network perimeter served as protection, creating a “walled garden” around the data with a single “guard” mediating access. Specifically, credentials were exchanged for a cookie, and the cookie remained within the walled garden.

chart from security one.pngMany active parts of the Internet still largely rely on this structure, but web applications quickly grew more complicated. Developers started leveraging reusable components, all deployed in the same container, in their applications. Concepts such as sticky sessions were introduced to help manage scale. Independently scalable web and data tiers enabled new, more immersive digital experiences. But the security paradigm remained essentially the same—a reliance on the network perimeter.

chart from security two.jpgToday, the situation is significantly different. Legacy application development techniques generally cannot support the experiences that customers demand, and modern approaches to application development (and the agility and feature richness that these approaches enable) do not easily support aging security methods.

Modern applications and digital experiences are composed of many pieces connected via APIs. The UI is detached from the business logic. Components within the user experience are run as independently deployable services, some originating inside the enterprise and some hosted elsewhere. The applications are built differently and consumed differently, making for richer experiences and faster, more responsive development—but also obviating many legacy security approaches.

Many businesses are investing in microservices, for example, to enable faster, more efficient application development. But whereas in traditional models, applications are deployed to application servers, in a microservices-based architecture, servers are deployed to the application.

One consequence is that tasks previously handled by the application server—such as authentication, authorization, and session management—are shifted to each microservice. If an organization has thousands of such microservices powering their applications across multiple clouds, how can its IT leaders even begin to think of a perimeter? chart from security three.jpgThe customer’s end experience relies on interactions among numerous components—and each needs to be secured.

When a user orders a ride-sharing service, for instance, many services combine via APIs for the end experience—services to pinpoint the user’s location and match the user with nearby drivers, services to call the user’s profile and customer information, services to enable the user to purchase a ride, services to chart routes, etc. Some of these services originate within the ride-sharing business and some are external services that the ride-sharing business leverages via digital ecosystems.

To the end user, these services must produce a seamless experience, with robust security and low friction at each point in the process. Effectively securing all of these interactions is in many ways an exercise in moving outside the network perimeter to manage and secure APIs wherever they are.

Likewise, government agencies as well large corporations have similarly exposed their systems—including customer data, in many cases—because of mismanaged APIs. It’s dangerous when even a single user’s credentials are compromised, as might happen in the case a phishing attack—and it can be exponentially worse if a misconfigured API compromises data for millions.

Historically, many enterprises applied management and security to only a subset of APIs—for example, those shared with internal partners and hosted behind the corporate firewall (within a walled garden, for example). But because network perimeters no longer contain all the experiences that drive business, enterprises should think of each API as a possible point of business leverage and a possible point of vulnerability.

To adapt to today’s application development demands and threat environment, in other words, APIs should be managed and secured, regardless of where they are located. There are no gardens or firewalls, just billions of interactions that need to be protected, and if enterprises don’t have control over and visibility into each one, they’re leaving their data vulnerable.