A partner once noted that a common mistake they see in Endpoint Detection Response (EDR) deployments is policy sprawl – too many policies, sometimes conflicting – making it difficult to manage or track what is being enforced.

It’s predictable problem – endpoint workloads are likely the most diverse in the organization.   It is tempting to reflect that complexity in the EDR policy.  It is natural to want to create a “Web Servers Policy” or “Accounting Workstations Policy” or some other “community” grouping of endpoints types – and build unique policies around them.

However, if you have read my previous postings – you know that community-based policy structures are the most wrongheaded (and unfortunately common) approaches to policy creation and structure across nearly all security services.

As reminder – communities are fluid within organizations.  “Web Servers” or “Accounting Workstations” sound like fairly static communities – until new applications or new acquisitions inevitably arise – and a new policy needs to be created to accommodate the nuance or change.

Also, the community isn’t important at the policy level – it is the security posture that we need to understand.  Policies should be named and managed by what entitlements the security services enforce.

Enforcement profiles can be applied to various community groupings – and they can be very dynamic – but that dynamism doesn’t have to occur at the policy structure itself.

As a simple example – perhaps Next-Gen Anti-virus has to be disabled for Accounting workstations at subsidiary – and for legacy Web Servers – as both are running some form of (maybe even different) legacy signature-based AV.

Traditional (aka wrongheaded) EDR policy structure could look like this:

• Subsidiary Accounting Workstation Policy
  • Applied to Subsidiary Accounting Workstation Group
• Corporate Workstations Policy
  • Applied to Desktop Operating Systems Group
• Legacy Web Server Policy
  • Applied to Legacy Web Servers Group
• Corporate Server Policy
  • Applied to Servers Operating System Group

Maybe this works for a time – but what does it mean?  Without opening every policy – it’s not clear what is different between them from a security perspective.  What security service is not enforced on the “Legacy Web Servers” as compared to the other servers?

In contrast, an Entitlement (or Enforcement) Based Policy might look like this:

• Behavioral Based Protection Only
  • Applied to Subsidiary Accounting Workstations Group and Legacy Webservers Group
• Next-Gen AV and Behavioral Based Protection
  • Applied to Desktop Operating Systems Group and Server Operating System Groups

Now at glance – it is clear what the difference between enforcement is between the policies – and what that means for communities or groups to which it is applied.

And if the legacy web servers have their legacy signature AV removed – and can start leveraging Next-Gen AV services – no change or removal of a top level policy – just move the Web Server group to the existing Next-Gen AV policy – and that’s it.

Obviously – these are simple examples – but in practice – our EDR policy is simple to understand – and we have very diverse endpoints as well.

As an industry, moving away from using communities as the backbone of policy creation not only simplifies policy structure – it puts focus back on the security we are trying to enforce.

That seems win-win to me.