Network-centric vs Application-centric Approach

Just a decade ago, Google and Yahoo found out that a government agency was listening in on their servers to exploit a loophole for skipping warrant requirements.

The takeaways:

• Just because it's in our private server doesn't mean it's "private."

• If it can be accessed, we must assume the wrong person is also trying to access it.

• It's best to always assume someone is listening — even in private connections.

Or as NSA puts it in their Embracing a Zero Trust Model CSI:

Zero Trust is a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The Zero Trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information fed from multiple sources to determine access and other system responses.

The network can't be trusted. Now what?

There are currently two approaches to security: the network-centric approach and the application-centric approach. While there’s valid arguments for either approach, the Pomerium team strongly believes the application-centric approach is best suited to protect against existing and future threats.

We also want to emphasize that we believe in combining both approaches to minimize security gaps and maximize peace of mind. However, in an extreme scenario where a company can only do one or the other, there are strong reasons why we believe the application-centric approach should be the default approach.

Let’s first explore what these approaches are.

Network-centric approach

There are many variations of this approach, with the most well-known being the castle-and-moat network model. The network-centric approach views securing the network itself as the ultimate goal. The main focuses are:

• Treating the network as a whole: The network is a collaborative ecosystem and no device is to be treated as an isolated entity. Security measures are designed to protect the flow of information throughout the network.

• Monitoring with observability: How’s the network doing? How do you know? Is anyone in the network that shouldn’t be? Employ tools that monitor everything within the network.

• Centralizing management: One PAM/IAM to rule them all. Access policies should be uniformly enforced throughout the network by ensuring all access to the network is authenticated and authorized by uniform policies.

• Scaling for growth: The network perimeter must be malleable and adaptable for the company’s changing needs and growth. The network blob should never be “constrained.”

• Limiting lateral movement: Implementations such as software defined perimeters (SDNs) can limit an attacker’s ability to traverse your network.

This approach evolved because traditional stated goal is “Hey, protect these applications, but also ensure only users we want to access the applications can get to them.” The implementers of the past found themselves choosing between building access control for each app and service or building it once for all apps and services. Times were different, and it was far easier to simply check for credentials at the front gate of the network to establish a connection. This nominally ensured applications within the network were only receiving requests from authenticated and verified users.

This model meant the application or services don’t need to worry about access control, since the network perimeter was doing the checking. And that’s the end of that, right?

Shortcomings of the network-centric approach

The network-centric approach made sense when companies could control physical access to their network. At the time, you needed to be sitting in the company building or a designated location to gain access. Evolutions of that access, whether through SSH or something else, enabled certain privileged users to gain remote access.

Then two things happened:

• Shift to the cloud

• Embracing remote access

In a bid for operational agility and ease of deployment, companies began deploying to the cloud. There’s nothing wrong with cloud migration or adoption — but certain questions most likely never came to mind when they evaluated the cost of doing so:

• Who has the final control over my cloud?

  • Litmus test: can I deny my cloud provider access to the cloud they’re providing me, or do they have un-auditable access I have no control over?

• Do we have a clearly defined understanding over our network perimeter’s scope and reach in a hybrid or multi-cloud infrastructure?

  • Litmus test: Give your network administration team some time and access to their usual resources, then ask them to individually draw the network blob, encompassing everything they believe is secured. Do they submit different blobs?

    • Test #2: Ask them to give an honest estimate for what coverage the central access policies have over every single application in the network.

Note that no one should blame the network infrastructure team if they have an incomplete view of the network perimeter at any given moment. As a good example, some Americans forget to include Guam and Puerto Rico as territories of the United States, and that’s the very same problem the network infrastructure team is facing. The modern network perimeter is blurry and hard to define, which makes it hard to secure.

And even if you could define that network perimeter, can the perimeter’s verification measures be trusted? The answer is a resounding no.

SP 800-207 [NIST’s Zero Trust Architecture paper] emphasizes that the goal of [Zero Trust] ZT is to “prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible.” Similarly, the National Security Telecommunications Advisory Committee (NSTAC) describes Zero Trust as “a cybersecurity strategy premised on the idea that no user or asset is to be implicitly trusted. It assumes that a breach has already occurred or will occur, and therefore, a user should not be granted access to sensitive information by a single verification done at the enterprise perimeter. Instead, each user, device, application, and transaction must be continually verified.”

— Source: page 5 of CISA’s Zero Trust Maturity Model v2

Application-centric approach

The increasing complexity of current and emerging cloud, multi-cloud, and hybrid network environments combined with the rapidly escalating and evolving nature of adversary threats has exposed the lack of effectiveness of traditional network cybersecurity defenses. Traditional perimeter-based network defenses with multiple layers of disjointed security technologies have proven themselves to be unable to meet the cybersecurity needs due to the current threat environment.

— Source: page 2 of NSA’s Embracing a Zero Trust Security Model

(We unironically believe NSA to be the foremost experts on this topic. Just ask Google.)

Conversely, the application-centric approach flips the script. “Your network can’t be trusted, now what?” is answered with giving each application the ability to enforce access control.

• Focusing on the applications themselves: Applications should treat everything that can reach it as hostile until proven otherwise. Being on a private network does not guarantee privacy or authenticity — the application must be able to verify that itself.

• Applying continuous verification: The application-centric model recognizes that authenticated and authorized access can still be abused. Applications are empowered to deny and reject access if the context of a request is potentially dangerous.

• Providing customized access: Applications should be secured wherever they’re deployed, independent of the environment they’re in.

• Monitoring through observability: This hasn’t changed much from the network-centric approach, but the audit logs should be more granular. Who accessed what, and why was it allowed or denied?

• Scaling for growth: The model should work at scale for innumerable amounts of users or applications across any number of clouds or hybrid on-premise deployments.

• Limiting lateral movement: Because each application is capable of verifying incoming requests, lateral movement is limited by default. Gaining access to the network does not grant access to an application, and gaining access to an application does not grant access to any other application.

Advantages of the application-centric approach

Try this analogy — you have a bunch of gold bars. Which is preferred:

• Keep them collectively in one vault, focusing your efforts on ensuring you control who can access that vault with all the gold bars, or;

• Keep them in their individual vaults, each one requiring a different vault key?

Most people immediately see the value of the second method; you don’t put all your eggs in one network. If one vault is breached, the rest of the vaults are still safe.

To be fair, network-centric proponents will immediate answer respond to this with: “Just use an SD-WAN or SDN to microsegment off the important applications and services and apply access control to those segmented single-application networks” — congratulations, you’ve just recreated the application-centric approach!

The problem with SD-WANs and SDNs for enforcing micro-segmented “one application per network” is they rarely stay that way. Raise your hand if you’ve ever slapped an allow-all into a firewall rule to get something working. You promised yourself you’d close them down later, but you’ve had to move on to other priorities.

Don’t worry if you’re guilty; it’s human nature to take the path of least resistance. But it is also why we shouldn’t be reliant on the network-centric approach. And considering even the end goal of an advanced network-centric approach is to have application-centric access control, why not start there? “The network can't be trusted. Now what?” is answered by “Let’s give the application the means to protect itself.”

Apply both — but secure the application first

It bears repeating that we are not advocating for abandoning the network-centric approach. They’re useful and have a part to play in any defense-in-depth strategy. We are only advocating for the primary focus to be ensuring an application is default-secure, environment-agnostic.

• Breaching your network perimeter should not put your applications at risk.

• Breaching an application should not put other applications at risk.

• Applications in air-gapped networks should not be vulnerable to insider threats.

When assuming breaches, the application-centric approach mitigates far more than the network-centric approach.

But I have a thousand applications across multiple heterogenous environments and securing them individually seems impossible.

We know. Pomerium is designed to enable the application-centric approach at scale. Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN. The result is:

• Easier because you don’t have to maintain a client or software.

• Faster because it’s deployed directly where your apps and services are. No more expensive data backhauling.

• Safer because every single action is verified for trusted identity, device, and context.

Pomerium is used by Forbes Global 2000 companies and trusted by security companies like ExtraHop to secure their internal access. But don’t take other's words for it; we’re completely open source so you can verify Pomerium works.