I think therefore IAM: It's not cool, it's not sexy, but it's one of the most important and difficult areas in modern IT
(2021/06/08)
- Reference: 1623141006
- News link: https://www.theregister.co.uk/2021/06/08/iam/
- Source link:
Feature A search on LinkedIn's UK job site just now (1 June 2021) returned 5,265 roles for a network manager; 2,204 for a system administrator; 4,964 for a web developer; and 10,776 for a business analyst. None of these are a particular surprise – they're popular, sought-after careers.
Oh, and there were 1,522 results for "Identity and Access Management" (IAM).
What do you want to be when you grow up?
When, as an IT student, you consider in which field you want to make a career, there are some common choices. Web developer, database administrator, software developer, system manager, network engineer... or more recently something in machine learning (ML), artificial intelligence (AI), quantum computing or cybersecurity.
This is because they are the areas you are taught as a student. Examining the course details of 10 top UK universities' computer science courses reveals a high degree of commonality: systems development, web programming, database systems, data science, AI, cyber security, advanced networking, algorithms, data structures, cryptography, ML, graphics, the list goes on.
If you get the bug for, say, web development, at uni, a career as a web developer is going to be high on the list at graduation. And since not a single one of the universities this correspondent looked at has a course module covering IAM, there's little chance of us turning up at careers fairs desperate to talk to potential employers about access management.
Simple in the simple cases…
IAM is relatively simple in small, new organisations. This is because if we're starting from nothing, we can begin with a core directory service – generally Microsoft's Active Directory (AD) – and build everything with Single Sign-On (SSO). This means we can authenticate to AD either natively or via well-understood protocols such as Active Directory Federation Services (ADFS) or the Lightweight Directory Access Protocol (LDAP).
We have the luxury of insisting that any new service we take on must integrate to the directory service, and that nothing is permitted to have its own internal authentication database except perhaps for specific administrative logins (particularly last-resort admin logins for use when the directory integration is being set up or has broken).
… But it gets very complicated, very quickly
Even in a modestly complex organisation, though, one could argue that IAM is not only one of the most important IT and security tasks in the business, but also one of the most difficult. In such companies IAM is a significant job: in my 450-person day-job business, for example, there are two staff members who solely do IAM and others who also touch on it from time to time.
The average business has systems that authenticate in several ways, typically: (a) directly to the directory service, either natively or via LDAP/ADFS; (b) partially, so that the yes/no decision to permit access is controlled by the directory service but the app also has internal controls over each user's permissions; and (c) the system controls access entirely within its own user database.
[1]
Now, it is hopefully pretty obvious that the primary risk with IAM is a failure to de-provision system access when someone leaves the organisation. The process is fairly straightforward for systems where admission control is handled by the directory service, because ticking the "disabled" box in the control panel will instantly render all the connected applications inaccessible.
[2]Same old complexity beneath Windows 10 Cloud Config means it's unlikely to compete with the likes of Chrome OS
[3]This better not be a cruel prank: Microsoft promises 99.99% uptime for Azure Active Directory from 1 April
[4]Big Blue services enjoy a lie-in: IBM cloud gets the Monday blues and its customers won't have been happy either
[5]Five bag $300,000 in bug bounties after finding 55 security holes in Apple's web apps, IT infrastructure
[6]Move over, Alien vs. Predator: Signing into AWS with an Office 365 login is a real crossover
The difficulty comes with the applications that aren't linked to the directory. In some cases – where you host the apps on-premises or in your private data centre – you can at least take the approach of forcing users to log into your AD network before they're able to get into the application.
It's not perfect, but turning off the AD account prevents the user from accessing the app. In other cases, such as SaaS-based applications with no SSO link into your world, you can hopefully get the vendor to restrict access based on the IP address of the client machine – so again the user has to be connected and logged into something in your private network and you can keep them out of the application by turning off their AD login.
Knowing what to provision
We've established, then, that turning people's accounts off when they leave is a non-trivial thing. Equally tricky, for different reasons, is ensuring that people have the right access to the right things at any given time.
To provision the correct access in the first place, you need one of two things: either (a) fully defined Role Based Access Control (RBAC), in which each of the company's job descriptions is linked to a carefully crafted set of application and systems permissions; or (b) a regime in which "standard" permission sets are defined for most roles and there's a mechanism for getting deviations approved by the right authority. And you need to apply it rigorously.
[7]
[8]
Why is this tricky? Getting RBAC set up in the first place is a long, thankless task and keeping the definitions up to date is a non-trivial thing that needs focus and careful review. And the second option of the two relies on humans doing things, which means errors are inevitable.
Reviews and leavers
And now the hardest part – reviewing what access people have. The hardest question to answer in IAM is: "What applications does X have access to, and what permissions do they have within those applications?"
Imagine a user has just left the business, and you have to deprovision them. Easy, you think: just look in the records for what they have been provisioned with, and take away that access. But no, all it takes is one mistake – one failure to record a change – and your records are instantly invalid. The only reliable way to establish the facts you need are to look in the applications... which means every application for every leaving user. This may sound overkill, until the moment the auditors come along and point out a deprovisioning failure in an app in which you weren't expecting to see a user ID for that person.
Not only this, but you should be doing regular reviews of all your users as a quality check to make sure you've not missed anything (preferably before the aforementioned auditors point your mistakes out to you). Cue lots of manual effort, lots of spreadsheets, lots of Excel VLOOKUPs mapping application user IDs onto HR staff lists. I've seen it done and it's not pretty – you can be looking at months of aggro for just a couple of dozen applications, especially when you bear in mind that if issues are found you have to correct them and then repeat the exercise until the results are spot on. There's no application on the market that eases this task for you, so you either live with a terribly manual task or do what you can with scripts, spreadsheets, macros, screen-scrapers and the like to remove at least some of the monotony.
Skills like a mental octopus
An effective IAM specialist, then, needs to understand applications, design procedures, analyse, agree and write RBAC definitions, police the IAM fulfilment process, produce reports despite there being no off-the-shelf reporting solution, carry out reviews, address inconsistencies and verify the remediation work, interface with and provide data to auditors... alongside an ongoing regime of continuous improvement.
Why, then, does the IAM workload land so often on the Level 1 helpdesk team?
IAM as a skillset
Let us look back at our university course modules from earlier: systems development, database systems, web development, cybersecurity, algorithms, data structures, data science. These are all skills that can be applied in IAM – whether it's for automating the provisioning and deprovisioning of user access to systems (hence reducing the risk of human error), scripting the extraction of access data from applications for reporting, building a relational database for that data to live in so it's easy to query in a reporting tool, devising algorithms for calculating whether a user's login has lain unused for too long.
These are all complex skills, and it is a mistake not to have staff of a sufficient skill level in sufficient numbers to do the job thoroughly and correctly. Of course, there will be tasks that the more junior team members are able to carry out as they gradually develop their experience, knowledge and skills, but IAM is more than just a business-as-usual activity. It needs senior, competent, strategically thinking specialists who understand not just these technological elements but also related subjects such as business risk along with soft skills such as communication and persuasion that they can use to encourage those fulfilling IAM requests to do so robustly and explain to the business users why it's important to be following what might seem to be slightly nebulous procedures involving requests, checks and approvals.
[9]
Employers: don't under-skill your IAM function, then, or it'll end in tears through failed audits or exploitation of vulnerabilities caused by poor access provisioning and deprovisioning. And for those of you reading this who are at the beginning of your careers, or who are reading The Reg in your university residences when you should really be doing your Prolog assignment (and yes, one of the courses I looked at has a module titled "Introduction to Prolog"), don't just look at one of the subjects you've studied and decide on it as a career. What you learn across the breadth of your course could come together to set you up for a career in IAM... and a fiver says there will be a lower applicants-per-role count for those 1,522 roles than for the others mentioned. ®
Get our [10]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.theregister.com/2021/02/03/windows_10_cloud_config/
[3] https://www.theregister.com/2021/01/06/four_nines_azure_active_directory_sla/
[4] https://www.theregister.com/2021/04/26/ibm/
[5] https://www.theregister.com/2020/10/09/apple_bug_bounty_vulnerabilities/
[6] https://www.theregister.com/2019/11/28/now_you_can_use_an_office_365_account_to_sign_in_to_aws/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://whitepapers.theregister.com/
Oh, and there were 1,522 results for "Identity and Access Management" (IAM).
What do you want to be when you grow up?
When, as an IT student, you consider in which field you want to make a career, there are some common choices. Web developer, database administrator, software developer, system manager, network engineer... or more recently something in machine learning (ML), artificial intelligence (AI), quantum computing or cybersecurity.
This is because they are the areas you are taught as a student. Examining the course details of 10 top UK universities' computer science courses reveals a high degree of commonality: systems development, web programming, database systems, data science, AI, cyber security, advanced networking, algorithms, data structures, cryptography, ML, graphics, the list goes on.
If you get the bug for, say, web development, at uni, a career as a web developer is going to be high on the list at graduation. And since not a single one of the universities this correspondent looked at has a course module covering IAM, there's little chance of us turning up at careers fairs desperate to talk to potential employers about access management.
Simple in the simple cases…
IAM is relatively simple in small, new organisations. This is because if we're starting from nothing, we can begin with a core directory service – generally Microsoft's Active Directory (AD) – and build everything with Single Sign-On (SSO). This means we can authenticate to AD either natively or via well-understood protocols such as Active Directory Federation Services (ADFS) or the Lightweight Directory Access Protocol (LDAP).
We have the luxury of insisting that any new service we take on must integrate to the directory service, and that nothing is permitted to have its own internal authentication database except perhaps for specific administrative logins (particularly last-resort admin logins for use when the directory integration is being set up or has broken).
… But it gets very complicated, very quickly
Even in a modestly complex organisation, though, one could argue that IAM is not only one of the most important IT and security tasks in the business, but also one of the most difficult. In such companies IAM is a significant job: in my 450-person day-job business, for example, there are two staff members who solely do IAM and others who also touch on it from time to time.
The average business has systems that authenticate in several ways, typically: (a) directly to the directory service, either natively or via LDAP/ADFS; (b) partially, so that the yes/no decision to permit access is controlled by the directory service but the app also has internal controls over each user's permissions; and (c) the system controls access entirely within its own user database.
[1]
Now, it is hopefully pretty obvious that the primary risk with IAM is a failure to de-provision system access when someone leaves the organisation. The process is fairly straightforward for systems where admission control is handled by the directory service, because ticking the "disabled" box in the control panel will instantly render all the connected applications inaccessible.
[2]Same old complexity beneath Windows 10 Cloud Config means it's unlikely to compete with the likes of Chrome OS
[3]This better not be a cruel prank: Microsoft promises 99.99% uptime for Azure Active Directory from 1 April
[4]Big Blue services enjoy a lie-in: IBM cloud gets the Monday blues and its customers won't have been happy either
[5]Five bag $300,000 in bug bounties after finding 55 security holes in Apple's web apps, IT infrastructure
[6]Move over, Alien vs. Predator: Signing into AWS with an Office 365 login is a real crossover
The difficulty comes with the applications that aren't linked to the directory. In some cases – where you host the apps on-premises or in your private data centre – you can at least take the approach of forcing users to log into your AD network before they're able to get into the application.
It's not perfect, but turning off the AD account prevents the user from accessing the app. In other cases, such as SaaS-based applications with no SSO link into your world, you can hopefully get the vendor to restrict access based on the IP address of the client machine – so again the user has to be connected and logged into something in your private network and you can keep them out of the application by turning off their AD login.
Knowing what to provision
We've established, then, that turning people's accounts off when they leave is a non-trivial thing. Equally tricky, for different reasons, is ensuring that people have the right access to the right things at any given time.
To provision the correct access in the first place, you need one of two things: either (a) fully defined Role Based Access Control (RBAC), in which each of the company's job descriptions is linked to a carefully crafted set of application and systems permissions; or (b) a regime in which "standard" permission sets are defined for most roles and there's a mechanism for getting deviations approved by the right authority. And you need to apply it rigorously.
[7]
[8]
Why is this tricky? Getting RBAC set up in the first place is a long, thankless task and keeping the definitions up to date is a non-trivial thing that needs focus and careful review. And the second option of the two relies on humans doing things, which means errors are inevitable.
Reviews and leavers
And now the hardest part – reviewing what access people have. The hardest question to answer in IAM is: "What applications does X have access to, and what permissions do they have within those applications?"
Imagine a user has just left the business, and you have to deprovision them. Easy, you think: just look in the records for what they have been provisioned with, and take away that access. But no, all it takes is one mistake – one failure to record a change – and your records are instantly invalid. The only reliable way to establish the facts you need are to look in the applications... which means every application for every leaving user. This may sound overkill, until the moment the auditors come along and point out a deprovisioning failure in an app in which you weren't expecting to see a user ID for that person.
Not only this, but you should be doing regular reviews of all your users as a quality check to make sure you've not missed anything (preferably before the aforementioned auditors point your mistakes out to you). Cue lots of manual effort, lots of spreadsheets, lots of Excel VLOOKUPs mapping application user IDs onto HR staff lists. I've seen it done and it's not pretty – you can be looking at months of aggro for just a couple of dozen applications, especially when you bear in mind that if issues are found you have to correct them and then repeat the exercise until the results are spot on. There's no application on the market that eases this task for you, so you either live with a terribly manual task or do what you can with scripts, spreadsheets, macros, screen-scrapers and the like to remove at least some of the monotony.
Skills like a mental octopus
An effective IAM specialist, then, needs to understand applications, design procedures, analyse, agree and write RBAC definitions, police the IAM fulfilment process, produce reports despite there being no off-the-shelf reporting solution, carry out reviews, address inconsistencies and verify the remediation work, interface with and provide data to auditors... alongside an ongoing regime of continuous improvement.
Why, then, does the IAM workload land so often on the Level 1 helpdesk team?
IAM as a skillset
Let us look back at our university course modules from earlier: systems development, database systems, web development, cybersecurity, algorithms, data structures, data science. These are all skills that can be applied in IAM – whether it's for automating the provisioning and deprovisioning of user access to systems (hence reducing the risk of human error), scripting the extraction of access data from applications for reporting, building a relational database for that data to live in so it's easy to query in a reporting tool, devising algorithms for calculating whether a user's login has lain unused for too long.
These are all complex skills, and it is a mistake not to have staff of a sufficient skill level in sufficient numbers to do the job thoroughly and correctly. Of course, there will be tasks that the more junior team members are able to carry out as they gradually develop their experience, knowledge and skills, but IAM is more than just a business-as-usual activity. It needs senior, competent, strategically thinking specialists who understand not just these technological elements but also related subjects such as business risk along with soft skills such as communication and persuasion that they can use to encourage those fulfilling IAM requests to do so robustly and explain to the business users why it's important to be following what might seem to be slightly nebulous procedures involving requests, checks and approvals.
[9]
Employers: don't under-skill your IAM function, then, or it'll end in tears through failed audits or exploitation of vulnerabilities caused by poor access provisioning and deprovisioning. And for those of you reading this who are at the beginning of your careers, or who are reading The Reg in your university residences when you should really be doing your Prolog assignment (and yes, one of the courses I looked at has a module titled "Introduction to Prolog"), don't just look at one of the subjects you've studied and decide on it as a career. What you learn across the breadth of your course could come together to set you up for a career in IAM... and a fiver says there will be a lower applicants-per-role count for those 1,522 roles than for the others mentioned. ®
Get our [10]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.theregister.com/2021/02/03/windows_10_cloud_config/
[3] https://www.theregister.com/2021/01/06/four_nines_azure_active_directory_sla/
[4] https://www.theregister.com/2021/04/26/ibm/
[5] https://www.theregister.com/2020/10/09/apple_bug_bounty_vulnerabilities/
[6] https://www.theregister.com/2019/11/28/now_you_can_use_an_office_365_account_to_sign_in_to_aws/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YL8-wQG4uIbsOpTTclolKAAAAIA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://whitepapers.theregister.com/
Re: HR is the key
Anonymous Coward
In principle, yes.
In practice, HR data is often wrong, and HR processes are convoluted, with HR wanting to stick to their way of working because "That's how we've always done it" despite the fact it hugely complicates the process.
Add into it the crossover between powerhungry HR staff and their underlings who have a degree in mouthbreathing and problems keep on coming.
Anon Coward because I make a lot of money from HR fuckwittery and want to keep on making money.
casperghst42
Interesting read from a write which misses the most obvious about IAM and why it is so difficult do right. The tool of the trade is mostly something like NetIQ Identtity Manager (I do not work for the company) (or something else which can be changed to fit the organization), then this is connected to something like Okta for provisioning (and authorization) , Okta is then using the on Prem-AD (or Office 365) for Authentication.
And as a previous comment said; all identities start from the HR system ... and nothing should be done manually - people make mistakes (often).
RBAC can be done with online tools like NetIQ Identitty Application or Sailpoint - does not matter as long as it's online and that users can request access (roles/premissions) which are granted "now".
Any organization who is using tools like Excel for RBAC administration will at some point end up in a management nightmare.
The biggy, which no one talks about is "red button", if an employee is let go, then the identity needs to be locked down immediately, which only works with systems which act on events - which many of these systems do not.
And lets not forget about Access Governance ... reporting, a tool which suck out all the information and will report if there are things (rights) which should not be there, and especially if they are assigned to people who should not have them.
IAM is complicated, and require knowledge not only about the choosen tool, but also about all the systems which you connect it to (AD, LDAP, SQL, Unix, Cloud, REST, SOAP, etc, etc, etc.).
But it's madly fun to do....
Anonymous Coward
Working in the space, the technology is the easy bit. Making the technology fit processes that don't make sense in an automated workflow is the hard part.
HR is the key
HR has a database of employees. Accounts creation should be automated. Account termination should be automated. Both should be driven by HR data with no human intervention. This will prevent prevent usernames that look more like nicknames,