Five ways to achieve identity driven security
Identity-driven security as an idea is gaining currency – and quite right too. But what does it mean, and how does it work? C’mon, this is more than just marketing hype, isn’t it?
Yes! It’s far more than marketing hype. Here are five ways to put identity at the heart of security.
1. Synchronization
Do you want a joined-up organization, or do you want a bunch of disconnected silos?
My wild guess is that you want to be joined up! Part of that is making sure that that the authoritative data that you keep about users (and devices) is available to all departments, directories, services and applications – wherever it is needed – so that accurate authentication and authorization decisions can be taken.
That can only be achieved through regular, reliable synchronization, and it is something that may happen implicitly (e.g. Azure AD (now Microsoft Entra ID) may sync with SAAS apps you have added without you even knowing), or explicitly using technologies like MIM for on-premises synchronization, and AAD Connect (now Microsoft Entra Connect) for bridging cloud and on-premises
2. Authentication
We need to know that you are who you say you are. How do we know?
Well first, we had better have reliable and consistent identity data across our systems (see previous point about synchronization!) Next, synchronization can apply to account names and log-ons (which are attributes like any other), but also to passwords.
It is well established that one strong password is better than the alternatives – and that usually means lots of weak ones, or ones that are written down somewhere (and that is worse than weak ones). But passwords are not enough – in fact, you should just assume your password is known (it may not be, but it is a wise assumption).
Multi-factor authentication (MFA) provides the ability to step up authentication based on risk – for example for high-risk applications and data, for high-risk accounts or where the identity information available (about users, their whereabouts or the devices they are using) suggests it would be appropriate.
Microsoft’s MFA technology enables MFA in the cloud or on-premises. MFA adds the ability to step up authentication based on risk – for example for high-risk applications and data, for high-risk accounts or where the identity information available (about users, their whereabouts or the devices they are using) suggests it would be appropriate. In some cases we might want to refuse access altogether.
Microsoft’s MFA technology enables MFA in the cloud or on-premises, and conditional access provides a policy-based approach based on real time risk assessment.
3. Privileged Access/Identity Management (PIM/PAM)
Having a user account compromised is bad enough, but what about all those privileged accounts, like admin accounts?
Your trusted users are walking around with several sets of credentials that the bad guys would love to get hold of – but that’s OK, because you trust them, right? The trouble is that getting control of a user account is scarily easy – and while that is not really a direct problem; it is just a matter of time before a privileged account crosses paths with a compromised workstation, then the privileged account can be compromised (this is called “sideways movement”). This may take months – but hackers are patient!
A key part of good identity management strategy is ensuring that highly privileged accounts such as administrator accounts are only available when necessary and to the extent that they are necessary (appropriate level of permission). This is called Privileged Access Management (PAM) or Privileged Identity Management (PIM) – for some reason Microsoft use “PIM” in the cloud and “PAM” in premises). The two mechanisms are different, but the effect is the same – the user does not know any privileged credentials, they just get elevated privileges for a period of time (and this can be subject to an approval). Since they do not know any privileged credentials, the chances of a malevolent party getting privileged access is greatly reduced.
4. Effective authorization management
This involves two big and difficult jobs:
- Ensuring that right users get the access they should have need in a timely manner
- Ensuring that they are the only ones that get that access
We grant that access primarily through group memberships, and through claims based on identity data (like user attributes) – and through manual actions. If you have reliable identity data (like user attributes) upon which you can base group memberships and claims, you reduce the need for manual processes (with all the errors they introduce).
If you can step up to a formal roles-based approach – and let’s not pretend this is easy – you can enter a whole new world of reliable authorization management, with associated reporting, attestation (see next point) and other checks and balances.
5. Attestation/certification
This is the process by which we can verify that users actually have the correct permissions – and using technology we can make this easy to do, and regularly enforced.
Actually you could ignore the first 4 steps described above and just do this – but that’s like putting on a band aid, when we really need some strong preventative medicine. Even if you have put in place sensible and practical identity-based rules and processes (including some of those above), then we still need to check that we have the right rules, and that they are working, and that the inevitable associated human processes are not subverting our carefully constructed rules.
Of course, if you have good processes, the job is so much simpler. And if you have a formal role-based system, you can simplify the process of attestation/certification, by certifying roles that chunk up the underlying permissions, rather than the permissions themselves (those permissions may be very numerous, and not named in a way that makes it obvious to the certifier what they mean).