Best Practices and Lessons Learned
A privileged user is defined as “A user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform”1 (NIST SP 800-172). These roles are typically called a ‘root user’ or ‘superuser’ and these roles are defined the same as ‘privileged user’. Privileged users have access to systems at an elevated level and these accounts ‘sell’ for a bigger price tag on the Dark Web for a reason: because they allow attackers to infiltrate critical systems directly and quickly.2 If an attacker has a standard user account information, that is bad but the worst they can do is open applications, access email, browse the intranet, and that is about it unless they are able to elevate the privileges of that normal user. Nearly three out of four (75%) breaches of data performed by bad actors was done leveraging privileged user credentials to enable them to exfiltrate data.3 Controlling and managing your privileged users is mandatory in today’s world given the level and focus of attacks. The way to drastically lower the risk of privileged accounts is to use Privileged Identity Management (PIM) but many organizations struggle on where to begin and best practices for this strategy. PIM enables temporary, elevated access for roles, also known as “just in time” access.
There are six key strategies to use in deploying PIM and they map out in acronym form as DEFEND:
- Define Roles
- Educate Owners
- Find All Players
- Enforce Least-Privilege
- Need to Test
- Document All Processes.
Privileged Identity Management (PIM) is not a tool or technology but is the process an organization uses to manage privileged access and accounts. PIM is the term that describes the process of tracking, managing, and securing root/superuser accounts.4 Many cloud service providers have their PIM solutions available for use, but the six DEFEND strategies are applicable to any deployment in the cloud or on-premises.
Defining roles is the most important step of all six and is first for that reason. Roles are defined as “a job function or employment position to which people or other system entities may be assigned in a system” and “a collection of permissions in a role-based access control, usually associated with a position in your organization”. 5 These positions and their associated permissions must be clearly defined and granular. For some roles, applying a restricted scope of permissions should be limited to a single administrative unit, a service owner, or a specific application. Role definition should include if they need to be time-bound or geographic region. Roles should be risk-ranked and managed based upon that level. A role that is root or superuser across a whole domain should be severely limited in number and obsessively logged and monitored. At the bottom of the pyramid would be the roles confined with restricted scope and could be more of those roles the further the scope is restricted.
Educate owners is a step often missed or done without fully following through to ensure the process and goals are well understood. Understanding the process and outcomes is key to building trust with the users and therefore their adoption of the process. The team can ‘force’ this to happen by diktat, simply placing policy and rules for users to obey. However, organizations will find much greater success if they partner with their business and technical owners to have them understand the importance and steps for success. Suggested business language to explain this importance of PIM process would be: It protects sensitive data, reduces risk of operational interruption, and any subsequent losses due to reputational, litigation, and regulatory damages. The use of PIM is considered best-practice and an integral part of any Identity and Access Management program that meets current frameworks and standards. Educate owners is not confined to the why but should expand to the how. How to use the PIM system, as a consumer or administrator, so they are effective and efficient.
Entitlements are attributes that a role give users specific abilities to perform (or not) actions based upon that role definition. Examples would be ability to change, read, update, or delete (CRUD) resources and/or configuring administrator console. Educating owners about each of this granularity is a necessary step to get them to adhere to least-privilege when reviewing access requests for approval. Education also includes the need for access reviews and what role owners should be looking for when doing these reviews. Best practice is to review these at least quarterly and any person who no longer needs the role should be removed as quickly as the process allows.
Find all key players is important because oftentimes an organization will get blinders on when it comes to getting the right people involved. The use of any PIM tools and process will affect a large number, if not all, of your organization. It may not affect every person, but given we operate in a software-driven workplace, it will affect nearly every group or department. As products and software are rolled into the PIM process and tools, more of your organization will be controlled and managed. This greater increasing reach means it is best to start small, with a group or product that is confined to a manageable number of cycles of the project team’s time. Learn from these early releases to improve key player identification of who and when roles should be assigned, and stakeholders get informed and educated. These key players can help define the ‘least-privilege’ access required for roles identified.
Enforce least-privilege is key to success in any PIM deployment. The ‘old’ or ‘lazy’ way of giving too many privileges to a user as a way of avoiding potential access issues leads to users being able to perform actions they should not. The misuse of an account does not have to be intentional to cause an event or incident. A user with too many privileges that makes them a superuser (or root) will eventually, with enough time and fatigue, make a mistake that will lead to an event. Least-privilege is defined as “The principle that a security architecture should be designed so that each entity (user) is granted the minimum system resources and authorizations that the entity needs to perform its functions.”6 “Minimum system resources and authorizations” is key here as each role must be given only those rights (change, read, update, delete, print, move, etc..) that they require to do their job. Nothing more. This may take some tuning (see Need to Test), but the time to do this ‘tuning’ is much less time than one will spend in an event, incident, or breach. Lastly, keep in mind that Least-privilege is a key concept in zero trust and having PIM deployed with least-privilege is viewed as core to success in ZT strategy.7
Need to test draws on the principle that there is required tuning on role permissions and that deployment of PIM should be done in sprints or bursts, not as a big bang conversion of all roles in an organization. Testing requires planning, meaning it should be a project that runs in bursts. For this reason, these projects often lend themselves Agile or Scrum project methodology, if available. Best practice would be to have a DEV or TEST environment to evaluate both effectiveness and stability of the implementation of PIM tools and process. For higher risk role implementation, ensure there is a tiger-team team ready to drastically lower the risk of operational impact during production transition. Tiger-team in these instances would consist of the subject-matter experts (SMEs) and engineers who can perform any root-cause analysis and remediation should any issues arise during this critical cut-over for higher risk roles. As your organization and PIM project team make their way down the risk pyramid, it will perfect the methodology of implementation and support, lending itself to the bigger groups and roles down that risk pyramid (see below, a high-level example).
Document all processes is a requirement foremost so the strategy and processes are repeatable and trackable. If a process or strategy is not documented, it is not going to be done again the same way, even by the same person, because there is no way to ensure all steps are completed. Documentation is important because it is what any second- or third-line risk roles would use to evaluate whether your PIM process is best-practice and being correctly followed. At the top level is the Standard and a PIM could be its own process or be a sub-part of an overall IAM Standard. However, it is described and documented, it must be informed by a framework (NIST-CSF, ISO 27001, or similar) to ensure it covers all the control requirements expected. The PIM Standard would then inform what controls should be accomplished in the process documentation. Adding steps for how the process is completed, tied to the controls described in the PIM standard ensures all are covered. These documents should be stored in a system of record for standards and policies to track versions and show which are officially published, review and approval process. Lastly, a runbook of how to do day-to-day tasks would be published where it can be more actively updated as daily processes can and should be ‘improved’ as opportunity arises. A runbook should still have a review and approval of any changes, but a lower threshold to Standards and Process documentation.
An overwhelming number of breaches occur due to elevated privilege accounts not being managed securely. Privileged Identity Management is a key process, along with certain tools and technologies, to dramatically improve the risk in your organization’s favor and making it significantly harder for the bad actors to break into your systems. The DEFEND steps enable a strategy to improve success of implementation and user acceptance of PIM in your organization.
References:
1https://csrc.nist.gov/glossary/term/privileged_user#:~:text=A%20user%20who%20is%20authorized,are%20not%20authorized%20to%20perform 2https://www.welivesecurity.com/2020/07/09/billions-stolen-passwords-sale-dark-web/ 3https://securis.com/news/74-of-data-breaches-start-with-privileged-credential-abuse/ 4https://oxfordcomputertraining.com/glossary/privileged-identity-management/ 5https://csrc.nist.gov/glossary/term/role#:~:text=Definition(s)%3A,be%20assigned%20in%20a%20system 6https://csrc.nist.gov/glossary/term/least_privilege#:~:text=NIST%20SP%20800%2D12%20Rev,needs%20to%20perform%20its%20function 7https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf
About the Author: Maria Rasner works at Truist Financial Corp as the lead for PAM on Identity Access Remediation and an active member and contributor for Truist Cloud Security Program. She holds a couple of identity-access related certifications from IMI (Identity Management Institute) and a couple of cloud security certifications from Azure & AWS. Maria has been in cybersecurity for over 5 years and is an active mentor in Women in Technology. She is also part of the Asian-American Business Resource Group Steering Committee at Truist. Maria is an active member in her local ISSA chapter and a Contributor Member of Identity Defined Security Alliance. She enjoys attending cybersecurity conferences to learn and share. She enjoys traveling internationally with her family and watching British detective shows in one of her favorite things to do to relax.
