From security at the perimeter to security at every interaction
This isn’t because APIs are inherently vulnerable– if 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, very quickly, and not all enterprises’ security approaches have been retrofitted.
Put 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. Let’s dig in.
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.
Many 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.
Today, 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 perimeter and some hosted elsewhere.
Rather than cookie-based authentication, applications use token-based methods such as OAuth. The applications are built differently and consumed differently, making for richer experiences and faster, more responsive development – but also development that many legacy security approaches aren’t equipped for.
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 a business has thousands of such microservices powering their applications across multiple clouds, how can its IT leaders even begin to think of a perimeter?
The 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 ridesharing business and some are external services that the ridesharing 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.
In some cases, businesses today offer customers experiences that blend modern dynamic interfaces with legacy models; think of the airline websites in which the front page is responsive, updating flight times instantly and slickly, but the check-out and review revert to more primitive, stilted interfaces.
Stitching together old and new experiences may not only raise security issues such as aging cookie-based authentication versus modern token-based authentication but also negatively impact the business, as failure to retrofit security methods can impede a business’s ability to deliver modern connected experiences that customers expect.
Historically, many enterprises have applied management and security to only a subset of APIs – e.g., 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.
It’s dangerous when even a single user’s credentials are compromised, as might happen in the case of a phishing attack – and it can be exponentially worse if a misconfigured API compromises data for millions.
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.
For many enterprises a first step toward better security is to deploy a secure, highly scalable, identity platform to manage all user interactions. The platform should support open standards such as OAuth 2 and OpenID Connect, which will help integrate microservices into development and allow the organization to move faster, use newer deployment platforms such as Kubernetes, and enable the fluid experiences that customers expect. Beyond authentication alone, visibility and control over API traffic as also essential, as a business cannot manage interactions it cannot see.
Recommended for you: It’s Past Time to Pay Much More Attention to API Security
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.