Identity should be at the heart of safeguarding users, devices, apps and data.
Any organization adopting an identity-driven approach to their security, must ask:
- Users – Who is the user? What access should they have?
- Devices – Personal or Corporate? Location? Device Type?
- Apps – Who should have access? What should they have access too?
- Data – What kind of data? Who should have access?
Organizations have many different scenarios to manage, all of which have their own unique security risks, for example:
- Users consuming corporate data on personal devices
- Individual users or whole departments consuming cloud services that are not under the control of the organization
- Organizations adopting multiple cloud services
- Users and organizations sharing data with customers and other business partners
- Corporate applications and data now live both “inside” and “outside’ the organization
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. 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.
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.
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).
Privileged Access/Identity Management (PIM/PAM)
This is called Privileged Access Management (PAM) or Privileged Identity Management (PIM). 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.
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.
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 previous 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).
As companies transform all facets of their business, security is their top concern. This isn’t a surprise. The modern enterprise is under attack and the old perimeter-based approach to security just doesn’t work anymore. Credentials continue to be the top cause of security breach, so companies need to move beyond passwords. They need a single access control layer for all on-premises and cloud applications, and they need a way to govern and protect employee and customer data. The digital enterprise needs a modern identity and access management (IAM) platform.