I recently took a firewall administrator’s course – excellent instructor at a great facility – would recommend – but the course content was largely created by the manufacturer. When we were covering policy creation, like most enterprise firewalls, we were able organize rules into sections, layers or similar groupings of related rules. Very helpful – but the illustration used as an example for organizing policies annoyed me to no end.
“Let’s create a section called ‘Accounting Department Access’ rules”
Argh.
I would imagine many would recognize this example within their own security policies – and not just on firewall enforcement points – and it is a problem.
This is an example of what I call a “Community Based Policy” – at it assumes that rules and policies should be organized by a community; as if in any organization, these communities (or even “end-to-end” applications) structures are not constantly in flux.
In a “SecDevOps” world (another outdated term that is best explored in my Code D.R.O.P.S posts) – security teams need to be nimble – but as security professionals, we also need to be able to quickly understand what entitlements our policies are enforcing – and who can access any protected entitlement.
To achieve these goals, we have to move to Entitlement Based Policy (EBP) construction – away from Community Based Policies. (I will use simplified enterprise firewall policies as examples – but Entitlement Based Polices work for really any security enforcement services – including IAM & User Provisioning, End Point Security, etc.).
Entitlement Based Policies (EPB) are focused on the services provided by an object, and permitted by the enforcement agent. These entitlement objects are not only more durable as constructs in organizations – they can be consumed (or “called”) by any community, regardless of how they are defined over time.
To quickly illustrate the difference between a Community Based Policy and an Entitlement Based Policy, let’s review Example 1 below, a simplified version the classroom example:
EXAMPLE 1: Initial Community Based Policy
This simple example should look familiar to most – the Accounting and Human resources teams have bundles of entitlements – some unique and some shared – organized around the community (in this case, “distinct” Departments).
For a quick comparison, in Example 2, let’s look at the same effective rules as an Entitlement Based Policy:
EXAMPLE 2: Initial Entitlement Based Policy
In the Example 2, we see that practically – entitlements are often considered the “destination” in a rule base, offering various services (generally, each service is its own entitlement – we don’t bundle access to ports 443 and 22 in one rule – as these are different entitlements), and communities are the consumers of the service, or the “source” in the firewall policy example.
Initially, this difference appears superficial and perhaps trivial (my own engineers thought the same when we first implemented zero trust networking – but now they are now advocates as more – and more complex – applications and organizational units started leveraging the environment) – but there are practical and important differences in thinking about security management and policy enforcement in this way.
First, communities in organizations are more fluid entities than entitlements. What if only the hiring managers (a sub-section) in the Accounting Department also needed access to the Professional Social Media? Are we creating new section just for Hiring Managers with the same entitlement (object) duplicated from another place in the policy? Same could be said for the few HR team members who help process payroll through the Payroll Partner secure webpage, but don’t need the file transfer entitlement. What if the HR IS systems needed to call a new API from the Payroll Processing partner?
These dynamics are fairly trivial for Entitlement Based Policies to incorporate (Example 3 – New Communities in an Entitlement Based Policy) – as these “new” communities are just added as consumers of the existing entitlements.
EXAMPLE 3: New Communities in an Entitlement Based Policy
Object oriented programming addressed similar challenges faced by developers years ago – why keep repeated functions in hierarchical manner, creating “spaghetti” and inconsistent code. EBP takes up those lessons, and applies them to security policy enforcement.
In real life, Communities in organizations are made of sub-sections and cross sections that change as business goals, functions and roles evolve. They are very rarely monolithic and permanent. It is just foolhardy for the security teams to build enforcement around communities; to try and define and capture these roles based on a point in time organizational chart or application structure (policies should be built on the most stable ground possible). In fact, these community based structures feed the “security is stopping the business from doing its job” cliché – as unexpected, but valid changes to communities complicate a community based policy structure already established.
In contrast, once an entitlement is approved and defined, creating new communities, or adding or removing members from existing communities, requires less structural change to the policy itself – allowing security teams to be more nimble and adapt to business requirements.
Entitlement Based Policies inherent the advantages of Object Oriented Programming. Meaning, entitlements are (encapsulated) providers with services that can be “called” by new consumers as the organization requirements change.
In future posts, we will look at defining entitlement boundaries, more complex rule bases and other applications for EBP (like user provisioning, Identity and Access Management, End Point Security) – but first, let’s review some of the basics of Entitlement Based Policies in firewalls, still the foundational security enforcement agent for most organizations:
- Providers and their services are the Entitlements in EBPs
- Policy sections should be organized by Entitlements (Sections \ Groupings \ Layers)
- Service Providers often tend to be the destination in firewall policies
- Each service (port or closely related ports) is typically its own distinct rule
- Communities are the consumers of Entitlements
- Communities tend to be source in firewall policies
- Communities are expected to be fluid, as valid requirements change
- Since they are not the basis of the policy structure, creating dynamic or cross sectional teams does not complicate the rule base
- A Service Provider can be a consumer of other Entitlements
- Front end web servers can be service providers in one section of the EBP, but be the consumer of middleware or core networking services in another
- This is illustrated in Example 3, and the Internal HR System consuming web services of the Payroll Processing Partner
These simple rules are the basis of EBP – which will be expanded for more complex structures in future posts. Most importantly, the advantages of EBP are the same as those articulated by Object Oriented Programming – more efficient, nimble and predictable outcomes – which can lead to be better security and partnership within the organization.