Best practices in access management (part 2 of 2)
Door Artikel IB5-2021 - Andres Maurer, Robert Metsemakers 13 dec 2021
Authors: Andres Maurer and Robert Metsemakers have extensive security experience in respectively Swiss and Dutch financial services. They wrote this article together in a personal capacity. They can be reached on andres-maurer@hotmail.com and robert.metsemakers@gmail.com.
The first part was published in iB4 and contained best practices for steps 1 to 7 in a generic access management process landscape (see figure 1). This second part describes steps 8 to 13. All steps are based on ‘lessons learned’ and experience gained by the authors in various implementation projects for access management and through regular line activities.
[Figure 1 - Steps in Access Management process]
8. Provisioning
Description
Once an approved ‘access request’ (see step 7) will be transferred from the IAM-system to the target system, the entitlement is resolved into provisioning items, i.e. accounts, privileges, profiles, etc. Provisioning can either be automatic or manual because some systems, applications or platforms do not allow automatic creation of accounts.
Best Practices
• Provide a high-level of automation in provisioning and de-provisioning to keep overhead low, minimize errors and speed up the process.
• Error handling in case of failures or conflict should be clear and ‘before the fact’.
• You need an ability to handle sequencing of multiple provisioning runs in batch mode, because for instance ‘remove all, add 1, add 2’ will have another result than ‘add 1, remove all, add 2’.
• Have an SLA (Service Level Agreement) in place that handles speed, time window, quality, time to fix mistakes and reporting for manual provisioning: especially with externally hosted applications.
• Have an ability to temporarily switch off automatic provisioning in case of emergency.
• Have the ability to roll back to a previous (total) snapshot of all access rights - this will be faster than to roll back ‘all’ access requests from yesterday.
• You need traceability from provisioning items all the way back to the original access request (and name of requestor and a date/time stamp).
• You can use Delta provisioning (= only changes to access are provisioned) or Full Forward provisioning (= when the whole entitlement repository is resolved and provisioned).
9. Account and Privilege Management
Description
The Access Management System must be able to manage the provisioning items efficiently and transparently (add, update, delete) based on the provisioning results. This process ensures that any access management artefacts on the target system can be mapped backed to an entitlement, which can then be mapped back to a request or automated rule.
Best Practices
• You need clear traceability between account name and the owner of the account if SSO (Single Sign On) is not used.
• Maintain single point of entry to manage the entitlement store/database and allow no (or only minimal) manual intervention.
• Bookkeeping of all the entitlement changes (historic ledger) and also the link between the entitlement and the original access request is necessary.
• Provide a clear strategy for handling removal if the provisioning item can be triggered by different access rights/roles. This is about resolving m:n relationships. For instance, if a user has two access rights that are based on one account, then removing one access right should remove only the associated privilege bit, not the account.
10. Temporary Privileged Access Invocation
Description
As only a limited number of users should have access to Production Systems, there has to be an efficient process to grant highly privileged access (like system administrator rights) for only a limited time to Developers or Level 3 supporters to fix incidents. The temporary privileged access should, as the name implies, be automatically revoked after a preset period or sooner when the access is no longer needed.
Best Practices
• Break-glass activation must be provisioned in a very short period. Normally this is done automatically, as in break-glass mode, there is no time to get management approval. So the entitlement should be pre-approved for specific users/roles and can then be activated quickly when needed.
• There has to be traceability between date/time of the break-glass event and of the original initiating incident.
• There has to be a limited ability to prolong the rights in case of emergency (for instance, extend it for 24 hours) and also a limit on the maximum number of extensions to prevent misuse.
• Perform strict JML (joiners, movers, leavers) processing on this selected group of high privileged users (usually system administrators), with timely removal of no longer needed privileged access.
• There must be pre-defined deputies or access groups for allowing these sensitive, high privileged access rights.
11. Reconciliation
Description
This process of comparing the master entitlement repository and the provisioned items on all target systems ensures that there is consistency between the repository and all systems. Changes that are made directly to the target system and hence bypassing the access management process will be detected.
Best Practices
• For a manual reconciliation, it is recommended to have a tool that can show the resolved access rights against the provisioned artefacts from the target system. This will facilitate the operator in doing the comparison faster.
• Define a strategy on how to remediate conflicts that are found during reconciliation.
• The performance of the reconciliation process should not be impacted by the provisioning process, even if they are running in parallel on the same live/production system.
• Reconciliation is done at regular intervals, at a minimum before each entitlement recertification.
• Automatic remediation after reconciliation should not be misused as a workaround for wrongly defined rights or roles.
12. Entitlement and Access Right Recertification
Description
There should be a process in place to ensure that entitlement and access rights/roles are reviewed at regular intervals.
As applications change over time, the access rights and access roles need to be reviewed regularly to ensure that they are still accurate and fit-for-purpose.
To ensure compliance to diverse regulations like Need-to-Know, SOX and so on, a review of user entitlements is required at regular intervals. Normally, only the critical entitlements need to be reviewed.
Entitlement recertification also needs to be an integral part of JML (joiners, movers, leavers).
Best Practices
• Appoint the right person (for instance: department/mandate, knowledge and expertise, personal qualities like precise, inquisitive and attention to detail) to execute the review/recertification.
• Proper context information (like the reason for and criticality of ‘temporary’ exceptions from the rules that are allowed by management) needs to be presented to the reviewer to allow him/her to do the job well.
• Provide a clear recertification strategy to optimize the scope and the required effort. For instance, recertify only critical access.
• Tools used for the review and recertification need to provide an adequate audit trail that provides enough detail but is also not ‘too much information’ to store for the required period.
• If an entitlement is judged to no longer be needed, the reason must be given and the affected user must be informed as this judgement may not be correct.
• Reviewer could delegate the task of reviewing, for instance in the holiday season.
13. Rule Recertification
Description
As the rulesets also create entitlements, they also need to be reviewed as well at regular intervals to affirm that the rules are still correct, complete and relevant.
Best Practices
• Metrics and logs of (automatic) rule execution must be available for the reviewer.
• Simulation (testing) environment of the automatic rules is available for the reviewer.
• Changes to external regulations and internal policies with consequences for user rights and entitlements are communicated timely to the rule owners.
• Rule owners needs to be able to simulate the rules to validate the rule behavior.
• Changes in the business process that result in new, extra or superfluous access rights and privileges need to be factored in. The reviewer is usually the rule owner. This provides the opportunity to the owner to review whether the rule is up to date.
SECTION 2 – MANAGEMENT ASPECTS
Managing Joiners, Movers, Leavers - triggers for the lifecycle of entitlements
A critical factor in ensuring that a corporation’s access management is up to date, is to properly manage the Joiners, Movers, Leavers – also known as JML.
There is often the misconception that JML is a process because, from the outside, there are access management activities during a JML event. However, JML only acts as the trigger for such activities.
Joiner (new to organization)
• Manually ordered rights or automatically assigned rights.
• Quick processing time of access requests to reduce unproductive time of users.
• ‘Replicate’ access rights of the buddy (but keep the buddies clean from ‘temporary exceptions’ from previous jobs on other departments).
• Roles help reduce the number of items to order, because a new user only has to order for instance a ‘banker-set’, ‘investment broker-set’, ‘HR-department-set’ or ‘internal-auditor-set’ of access rights.
Mover (changing in organization, department or function)
• Manually ordered rights or automatically assigned rights.
• Manually removed rights (Entitlement recertification) or automatically removed rights.
• Movers seldom move on an absolute date, and usually get questions about their previous work activities, so a ‘grace period’ for entitlements will help the transition.
• Update Master data repository in the IAM-system. The mover may be an approver or owner of an artefact in the old organization, so a replacement must be defined.
Leaver (leaving organization)
• Remove entitlements automatically (to avoid mistakes, do not leave it to manual process), for instance based on the Human Resources salary administration.
• Deactivating of the registered access rights may be required before actual deletion. For instance, when you need forensics in case of dismissal because of theft or fraud. There can also be approvals etc. in the workflow/pipeline of the leaver that only can be deleted after they have been granted.
• Update the Master data repository (see above).
SECTION 3 - ARCHITECTURE
Description
In a large organization, multiple protocols and platforms can (or will) be used, leading to high maintenance overhead. To mitigate this, IAM should be defined on a strategic level that is valid for the whole organization. If the organization is large and extended to different countries, IAM should fulfill all regulatory and compliance requirements for all impacted regions.
Best Practices
• Develop a Master plan for firm-wide Identity and Access Management.
• Publish information on what is supported as well as how to integrate.
• Build/procure based on the supported IAM architecture patterns.
• Select a framework, stick to it and use it consistently, but know when to deviate from it.
• Always do a proper (and holistic!) analysis of new technology and integrate into the master plan.
• Build on standards like OASIS [1] XACML [2] and Zero Trust [3] Framework [4].
OASIS XACML
• XACML is primarily an attribute-based access control system (ABAC). Access is granted on the fly based on attributes matching. For instance, if user is in city “A” and has job function “B”, grant write access to Application “C”.
• Model that provides common terminology and interoperability between access control implementations.
• Can be used for role-based access control system (RBAC) as well.
Zero Trust Security Model
[Figure 2 - Zero Trust model]
• Change the principle from ‘trust, but verify’ to ‘no trust, always verify’.
• Needs to be implemented holistically but can be implemented in steps.
• Many manufacturers and providers support Zero Trust Security Model.
• Model can also be adopted for Cloud and support micro-segmentation.
• Requires in-depth logging and monitoring.
• Google’s implementation (BeyondCorp) is so reliable that VPN is no longer needed for BYOD.
SECTION 4 – ACCESS MANAGEMENT AND SECURITY MONITORING
Description
Attackers often try, using the standard command set, to gain administrator privileges to perform highly privileged tasks. Accounts or permissions that do not match the master repository may indicate malicious activities. So all actual accounts and permissions have to be reconciled with the master repository frequently to allow corrective actions.
An example of such techniques from the MITRE ATT&CK framework [5] are ‘Create account’, ‘Account manipulation’ and ‘Valid accounts’. Look for more information, for instance on TTP used by (Advanced Persistent Threat groups) APT3 and APT29 [6], on the MITRE website [7].
Misuse of rights or unusual access is often a good indicator of malicious activities and needs to be monitored. For example, look for unusual amounts and quantities, usage time (outside of office hours), place (‘work from home’ as it was called, pre-Covid), date (during holiday/vacation), frequency of use or speed of input.
• Discrepancies detected during reconciliation, especially superfluous accounts and permissions, are highly suspicious and require further investigation.
• Unusual account activities need to be investigated (e.g. Admin login at Midnight, or during her pregnancy leave).
Best Practices – Preventive control
• Use only one master entitlement repository and a high degree of provisioning automation.
• Do all provisioning automatically from the IAM-system and avoid adding accounts or change permissions manually directly on the target system.
• Deactivate the default admin accounts.
• Do not use non-personal or shared accounts.
• Be aware what groups and permissions are highly privileged and monitor them closely.
• Keep an immutable log of privileged user actions.
• Reconciliation must be in place and executed regularly.
• Have a predefined process in place to deal with reconciliation differences that will appear in the future.
Best Practices – Detective control
• Ensure that necessary logs and information are sent timely to the SIEM (Security Information & Events Monitoring) system in a way that allows no manipulation/changing (both in storage and in transit).
• Define the context of the logs for each detection case.
• To avoid false positives, define proper threshold (the number of security events before an alert is triggered) and use multiple indicators of compromise where possible.
• Also, correlate against the planned maintenance time windows and issued Incident tickets.
• Know the normal usage pattern on the different systems.
References
[1] https://www.oasis-open.org/committees/xacml/
[2] https://en.wikipedia.org/wiki/XACML
[3] https://ldapwiki.com/wiki/Zero%20Trust
[4] https://go.forrester.com/blogs/next-generation-access-and-zero-trust/
[5] https://mitre-attack.github.io/attack-navigator/enterprise/
[6] https://www.mitre.org/sites/default/files/pdf/APT3-APT29-software.pdf
[7] https://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/attck-101
Dit artikel verscheen in IB5-2021, de privacy special.
Voor het opgemaakte artikel inclusief de figuren (pdf), klik hier onder op 'Document downloaden'.