A friend working at a very large institution told me about an incident – that was thankfully contained – but where initial access was jaw droppingly easy.

While the victim workstation was behind a secure web gateway, the SWG was not enforcing any restrictions – and a malicious payload was downloaded.

This is a huge organization – complicated yes, but not short on resources.  I am jealous of their tooling – and the attention they garner from vendors (every deal there is massive) – yet they just couldn’t implement a critical security control to any effect.

I can relate to the challenges – I suspect there was unacceptable friction – maybe too many false positives – perhaps an overwhelming number of support tickets – but to end up with NO policy enforcement as the answer?

So, what went wrong?  Poor leadership or risk management of course – but was there a challenge in just building a working framework on their SWG?  Were the staff not trained on how to approach policy creation – how to breakdown complex business requirements?

This is why I have pushed my entitlement-based policies mantra – to structure enforcement policy entitlements as microservices to which consumers or communities subscribe.

I developed this mindset to help my teams think about HOW to implement their tools – to provide access where required – while blocking unauthorized activity or malicious content.

I find when we attend technical training – the examples for implementation use what I consider legacy thinking when building enforcement rules.

They often describe a community (a department or business unit) and attempt to build a policy structure around those groups.  But communities in organizations are complex and dynamic – and such a structure will become quickly outdated, or require exceptions that make enforcement unpredictable.

How can security teams breakdown real-world requirements, when they hampered by outdated concepts that keep getting reinforced?

Here is my preferred approach:

1. Don’t try to capture the totality of what every community needs at the start – it is too daunting and ever changing
2. Think first about entitlements (or enforcements) first – what could be allowed and what will always be denied (the approved destinations, processes, applications, etc.)
3. Build a policy around those entitlements first – the framework of the structure are the services you allow – defined as narrowly as possible for the tool – like microservices to be called
4. Some traditional policy concepts still apply – place more specific entitlements at the top and a default “deny all” at the end
5. When the policy is built – now allow various communities to choose to subscribe to the defined entitlements (as the source objects or groups using each micro-service as needed)
6. Communities can then be organic – and DO NOT need to be tied to departments, organization units or job titles
7. Add and remove people or objects from communities as requirements change – but there should not be much change to the overall policy structure – the entitlement based microservices – if built correctly

Again – while my example I write about here are simplified – they have endured in practice and my teams have fully adopted this mindset.

There is an elegance to our new security policies – and a stark difference between our newer tools and our legacy platforms where the policies can seem inflexible.

But most importantly, whether you adopt this approach or no – we must focus on how to implement our tools. Otherwise – regardless of our technical skill or generous budgets – we are putting our organizations at risk.