Separation of privilege is an information technology best practice applied by organizations to broadly separate users and processes based on different levels of trust, needs, and privilege requirements. Separation of privilege, also called privilege separation, refers to both the:
- Segmentation of user privileges across various, separate users and accounts
- Compartmentalization of privileges across various application or system sub-components, tasks, and processes.
Similar to the concept of network segmentation, separation of privileges essentially creates “moats” around specific parts of an IT environment. It helps contain intruders close to the point of compromise and restrict lateral movement, while also ensuring that employees, applications, and system processes do not have access to more data than they need. Segmenting privileges and the tasks associated with them also provides the benefit of a cleaner audit trail and simplifying compliance.
Separation of privilege can be implemented in a number of ways, but some common examples include:
How Separation of Privilege Relates to Least Privilege & Separation of Duties
Privilege separation complements the security principle of least privilege (PoLP), which mandates that users, accounts, and computing processes only have the minimal rights and access to resources that they absolutely need.
Let’s examine how this may work in practice. Take, for instance, an IT worker (“wearer of many hats”) at a very small company. This employee may have access to a standard user account, a Domain Administrator Account, and a Local Administrator Account—and still conform to a least privilege access model if all the rights and access within those accounts were actually needed by the IT worker to perform their job.
Working together, least privilege and privilege separation enable workers to perform their duties, while minimizing the opportunity for an attacker to “land and expand”. For instance, if a user who is logged in to an administrator account clicks on a phishing email and the account subsequently becomes compromised, the malware or hacker will have the same privileges of that account — which is considerably more dangerous than had the employee been only logged in as a standard user account.
Often, malware requires elevated code to execute in the first place. So, if least privilege and separation of privilege are adequately enforced, even if a non-privileged account is compromised, there is nothing for the malware to do and nowhere else for it to go.
Also closely related to, and often overlapping with, separation of privilege is the concept of separation of duties (SoD), which promotes the practice of separating tasks and functions between different roles to provide a layer of accountability and to help prevent fraud. In IT teams, one common example of SoD is separating the duties of software developer from tester. This division of duties amongst team members helps to prevent conflicts of interest, while providing extra oversight.
In the event of an insider attack or compromise via malware or a hacker, segregation of privileges, separation of duties, and least privilege all play key roles in helping to ensure that beyond the initial point of compromise or exploit, other lateral privileged users/accounts or system/application components are not impacted.
Privilege separation, least privilege enforcement, and separation of duties, can all be enforced programmatically via policies and technologies, such as with privileged access management (PAM) solutions.
How is Proper Separation of Privilege Created?
Privilege separation requires defining and delineating employee, application, and system roles and tasks so that access is only granted to specific, discrete parts of systems or data as is necessary. When it comes to people, every user should have unique, separate credentials for each of their different account types. Privileged password management solutions can help prohibit password and account sharing, while also enforcing unique passwords for users, applications, and other system components.
In practice, most users outside of IT should only have one standard, non-privileged account.
Using Separation of Privilege for Role-Based Access
When exploring user roles for individuals, processes, and technology, separation of privilege should:
- Understand all roles within or outside an organization that may need access to sensitive data
- Understand the responsibilities, accountabilities, and job tasks of specific roles
- Look at users in terms of individuals, roles, technology, processes, and policies
Using Separation of Privilege for Activities
Once roles are understood, separation of privilege can be based around specific user and application actions:
- Understand all the tasks a specific role or application needs to carry out
- Understand how data is used and transformed by that role or application
- Understand the specific datasets, records, and individual pieces of information required
Once these areas are thoroughly grasped, you can apply the concept of separation of privilege to assign tasks within every individual role or application to the right level of access, and to specific parts of a dataset or system, based around security impact and sensitivity.
Want to learn how to implement separation of privilege across to improve your organization’s security and compliance posture? Contact BeyondTrust today!
Separation of Privilege Related Resources
- What Is Least Privilege & Why Do You Need It? (blog)
- Getting to the Root of Unix & Linux Security: A CISO’s Primer on Privileged Access (white paper)
- Least Privilege Management (solution web page)
- Controlling Unix & Linux Account Privileges: 9 Best Practices (white paper)
- Comprehensive Unix & Linux Privilege and Session Management (solution web page)
Matt Miller, Senior Content Marketing Manager, BeyondTrust
Matt Miller is a Senior Content Marketing Manager at BeyondTrust. Prior to BeyondTrust, he developed and executed marketing strategies on cyber security and cloud technologies in roles at Accelerite (a business unit of Persistent Systems), WatchGuard Technologies, and Microsoft. Earlier in his career Matt held various roles in IR, marketing, and corporate communications in the biotech / biopharmaceutical industry. His experience and interests traverse cyber security, cloud / virtualization, IoT, economics, information governance, and risk management. He is also an avid homebrewer (working toward his Black Belt in beer) and writer.