Let’s fast forward a bit.

In my earlier post about Entitlement Based Policies (EBP), I used basic firewall rules to explain EBP’s advantages over Community Based Policies.  While an EBP does have advantages in simple deployments, the EBP mindset really comes into its own when protecting microservices.

In fact, the EBP approach is basically creating microservices within security enforcement policies.

Security teams were used to n-tier architectures, with north-south enforcement points securing applications hosted within an environment.  They were looking at applications through a key hole.  There might be considerable east-west traffic within any zone, but security teams only needed to know the flows that traversed their enforcement gateways.

With older monolithic application architectures, it was reasonable to organize applications flows “end to end”, with security policies organized around the entire “product”.   The monolithic application was itself was the “community” that defined the required flows between various services – the “entitlements”.

Modern applications architectures are based on microservices – narrowly defined and meant to be dynamically consumed “on demand” by various “customers” (aka – communities).  Therefore, it doesn’t make sense to secure the flows around the monolithic “product”.  Not only does this not align with the thinking behind microservices – inevitably the same microservices will likely appear all over the security policy.  This can put pressure on security teams to keep up with releases and changes, even when those changes are orchestrated.

Of course, transport security, authentication, authorization, etc. are critical with microservices (and well, can be organized by entitlements too) – but traffic filtering firewalls still have an important role to play in limiting the risk surface.

When we first deployed zero-trust networking, it was the traditional “monolithic” approach to designing security that was the biggest “mental” hurdle for my teams to overcome.  Zero-trust networking is an incredible enhancement in securing east-west flows – but it also greatly multiplies the number and granularity of rules within the enforcement policy.  To not add redundancy to an already expanded policy, it is best to organize and encapsulate rules to the specific entitlements (the microservices) – not around the end-to-end product.

In end, it is about how we look at the applications we are trying to secure.

To illustrate these points, here is a simple end-to-end application flow and supporting security policy – “Product A” – in a traditional n-tier environment, using a “monolithic” (product) based policy. 

Diagram 1: “Product A” – N-tier Environment

Example 1: “Product A” – Legacy N-tier “Monolithic” Policy

You can already see that flows within a security zone aren’t represented in the security policy, as they don’t traverse the north-south inspection points.

The exact same application in a zero-trust environment, where security enforcement includes east-west flows, already has more rules. 

Diagram 2: “Product A” – Zero Trust Environment

Example 2: “Product A” – Legacy Zero Trust “Monolithic” Policy

The above “monolithic” rule base will work, so what is problem we are trying to address?  Well, how many organizations have exactly one product or end-to-end application?  How many products have the exclusive use of any given mircoservice for all time?

Even with the introduction of an extremely simple new “Product B”, these issues become apparent.

Diagram 3: “Product B” – Zero Trust Environment

Example 3: Combined Legacy “Monolithic” Policy

As you can see, there is already duplication of the “Microservice 2” object and rules in the security policy. This means any changes to flows or services in “Microservice 2” have to be updated twice.  But the whole point of creating microservices was to isolate changes to narrow scope!  So why wouldn’t security policies try to replicate this thinking?

The same rules, if organized around the ENTITLEMENTS (microservices), would be more flexible to any such changes. Let’s take a look at the same rules, but in an Entitlement Based “Microservices” Security Policy.

Example 4: Combined Entitlement Based “Microservices” Security Policy

Want to add 10 more products front ends to leverage “Microservice 2” – just one rule is updated – not 10 rules in a policy based on the end-to-end products themselves!

In fact, I would wager that exact problem leads to policies becoming more permissive within a specific environment \ namespace – even when zero trust networking is available.  Allowing all services within the environment to communicate – and enforcing only at the north-south, ingress-egress was just easier and more familiar to the security teams.  Maybe this is ok is some isolated development environment – but it is unacceptable in a production environment – and undermines the whole point of zero trust networks.

SecDevOps is not just coordination and communication – it should be about advancing our thinking as well.  Security teams should not be trying to make our development partners “regress” to end-to-end “monolithic” policy designs.  Familiarity is not inherently more secure.  However, narrowly scoping security enforcement to the entitlement is both more secure and flexible – and multiplies the benefits of leveraging microservices for all stakeholders.