A step-by-step guide to least privilege

A workflow for EPM for Linux

Scope of this guide

This guide covers the full end-to-end setup workflow for least privilege access on Linux endpoints with BeyondTrust Endpoint Privilege Management (EPM). The idea is simple: give people only the access they need to get their work done, and nothing more.

Following this guide will help you tighten security across your Linux systems, maintain consistent access controls, and capture the audit trails required for SOC 2, ISO 27001, CIS Benchmarks, and PCI-DSS.

Prerequisites

Confirm the prerequisites are in place.

• BeyondTrust EPM for Linux cloud license
• Management console access. Admin-level credentials to EPM Pathfinder
• EPM agent installed on endpoints. EPM Linux agent deployed to all target Linux hosts.
• Network connectivity. Linux endpoints can communicate with the EPM cloud service
• Inventory of user roles and commands. Document of current privileged users and the commands they use

Workflow: Setting up least privilege

The eight steps walk through the complete configuration lifecycle.

Step 1: Enable role-based policy

Role-Based Policy (RBP) is the governance framework that drives all least privilege decisions in EPM for Linux. Enabling RBP switches the system from a flat permission model to a structured hierarchy in which permissions are defined by roles, and roles are assigned to users or groups.

Without RBP, all users may operate under a single, undifferentiated policy. Enabling RBP allows you to define distinct permission profiles for different job functions (e.g., developer, DBA, sysadmin) and to enforce those boundaries consistently across all managed endpoints.

How to

1. Log in to the BeyondTrust EPM cloud management console using your administrator credentials.
2. Navigate to Policy Management from the left-hand navigation menu.
3. Select Policy Settings (or Global Settings, depending on your console version).
4. Locate the Role-Based Policy toggle or checkbox in the Access Control section.
5. Enable Role-Based Policy and confirm the action when prompted.
6. Save your changes. The console will confirm that RBP mode is now active.

Note: Enabling RBP may not immediately change any end-user behavior. Users will continue to operate under any existing policy until roles and command groups are fully configured and deployed.

Step 2: Create command groups

Command groups are collections of Linux commands or command patterns that you want to control as a unit. Rather than writing individual rules for every possible command, you group related commands together and then apply permissions to the whole group at once. This simplifies policy management as your environment scales.

Command groups are the core of least privilege enforcement at the command level. A well-designed set of command groups lets you express business requirements clearly: a 'Network Diagnostics' group for approved troubleshooting tools, a 'Package Management' group for approved update commands, and so on.

Plan your command groups

Before creating groups in the console, document the commands each user persona legitimately needs. A useful planning matrix might look like this:

How to

1. In the management console, navigate to the What tile in the policy editor.
2. Click Add Command Group and provide a descriptive name (e.g., 'Network Diagnostics - Read Only').
3. Add individual commands using exact paths (e.g., /bin/ping) or patterns using wildcards where appropriate.
4. Set the command disposition to Allow or Reject as required for each entry.
5. Optionally, add a description to document the business justification for the group.
6. Save the command group. Repeat this process for each command group identified in your planning matrix.

⚠️

Avoid using broad wildcards (e.g., /bin/*) in allowed command groups. Overly permissive patterns can inadvertently grant access to commands that were not intended. Always be as specific as possible.

Step 3: Define secure users

In EPM for Linux, a Secure User is a user account that is managed under the EPM policy framework. Once defined as a secure user, an account's privileged command execution is governed by EPM rather than by the operating system's default sudo configuration. This is the step at which you bring your user population under the control of the least privilege model.

Until a user is defined as a secure user, EPM policies do not apply to them. Correctly defining your secure users ensures comprehensive coverage and prevents policy gaps where some accounts remain unmanaged.

User definition approaches

EPM supports several ways to define who is a secure user:

• Individual user accounts: Add specific Linux usernames directly.
• Local groups: Reference operating system groups (e.g., sudoers, wheel) to bring all members under EPM control.
• Directory groups: Integrate with Active Directory or LDAP to use identity provider groups as the source of truth.

How to

1. Navigate to the Who tile in the policy builder.
2. Click Add User or Add Group and specify the user account name, local group, or directory group.
3. For directory-integrated environments, ensure the EPM agent is configured with the appropriate LDAP or AD connection settings before this step.
4. Assign a meaningful label so the user or group can be easily referenced when creating roles.
5. Review the full list of secure users to confirm all privileged accounts are included. Pay particular attention to service accounts and shared accounts.
6. Save your user definitions.

⚠️

Service accounts and shared accounts should also be defined as secure users if they have the potential to execute privileged commands. Leaving them unmanaged creates a policy gap that attackers may exploit.

Step 4: Create roles

Roles are the central building blocks of the least privilege model in EPM. A role combines three dimensions of control: who can act (users and groups), what they can do (command groups), and on which hosts and at what times.

Well-defined roles allow you to implement the principle of least privilege accurately and maintainably. A change to a role propagates to all users assigned to it, making policy updates fast and consistent across your entire Linux estate.

Role design principles

• Align roles to job functions, not individuals: Junior Developer, Senior DBA, IT Support.
• Start restrictive and expand. Granting is easier than revoking.
• Separate duties where policy requires it. For example, deploying code versus managing the database.
• Scope roles to relevant hosts. A DBA role grants database commands only on database servers.

How to

1. Navigate to the Roles tile in the policy editor.
2. Click Add Role and provide a descriptive name aligned to a job function (e.g., 'Linux Support - Level 1').
3. In the Who section of the role, add the secure users and groups that should hold this role.
4. In the What section, assign the appropriate command groups that define permitted actions. Set allowed and rejected dispositions as required.
5. In the Where section, restrict the role to relevant host groups or individual hostnames. Avoid leaving the scope set to 'All Hosts' unless genuinely required.
6. In the When section (if available), optionally restrict the role to specific time windows (e.g., business hours only) for added control.
7. Configure privilege escalation settings: define whether commands run as root, a service account, or another specified user.
8. Save the role. Repeat for each job function identified in your user inventory.

✅

Consider creating a 'Break Glass' role with elevated permissions for emergency situations. This role can include additional logging requirements and be restricted to a very small number of trusted administrators.

Step 5: Assign roles

Role assignment binds the roles to the users and groups who should operate under them. This step makes your policy configuration effective. Until roles are assigned, no access controls are being enforced.

Role assignment determines the effective permissions for every managed user. A careful, deliberate assignment process prevents both over-privileged accounts (a security risk) and under-privileged accounts (an operational risk).

✅

Best practices

• Review role assignments with team managers first. They know which team members need which access levels.
• Avoid overlapping roles unless you have verified how EPM resolves conflicts. In most configurations, the most permissive role wins.
• Record assignments in a configuration register (spreadsheet or CMDB) so you have an authoritative reference independent of the management console.

How to

1. Navigate to the Roles tile and open each role for editing.
2. Confirm the list of users and groups assigned to the role. Make any adjustments based on the approval process conducted with team managers.
3. Alternatively, navigate to the Who tile, select a user or group, and review all roles assigned to that entity from a user-centric perspective.
4. Verify that every privileged user is accounted for and that no accounts have been left without a role assignment (which would leave them outside policy control).
5. For users who currently rely on unrestricted sudo, confirm that their new EPM role provides equivalent access to everything they genuinely need before proceeding to deployment.
6. Save all assignment changes.

⚠️

Do not go to policy deployment (Step 7) until role assignments are reviewed and approved. Deploying an incomplete policy may disrupt legitimate business operations if users find they cannot run required commands.

Step 6: Audit and monitor

EPM for Linux logs all privileged activity across managed endpoints.

Configure logging before deployment: audit records serve both security (detecting misuse or anomalous behavior) and compliance (demonstrating that least privilege controls operate as designed).

Endpoints deployed before logging is enabled produce no record of early activity.

Activity types

How to

1. In the management console, navigate to Audit and Reporting settings.
2. Enable session logging for all roles that involve elevated privileges.
3. Configure log retention policies in line with your compliance requirements (typically 90 days to 1 year for most frameworks).
4. Set up real-time alerts for high-risk events such as rejected command attempts, access outside business hours, or access to sensitive host groups.
5. Integrate EPM audit logs with your SIEM (Security Information and Event Management) platform if available, to correlate EPM events with other security telemetry.
6. Schedule a recurring review of the EPM Reports section. Recommended cadence: weekly for active operations, monthly for policy review and refinement.

✅

EPM reports can provide evidence of least privilege compliance for audits. Maintain a practice of exporting and archiving monthly summary reports as part of your compliance program.

Step 7: Deploy policies

Policy deployment pushes the configuration you have built out to the EPM agents running on your managed Linux endpoints. Once deployed, the policies become active and users operate under least privilege controls. This is the step when your least privilege model goes live.

Deployment strategy

Deploy in phases. For large or complex environments, a staged rollout limits the blast radius if a policy behaves unexpectedly.

• Phase 1 - Pilot: Deploy to a small group of volunteer users or a non-production host group. Run for one to two weeks, collecting feedback and reviewing audit logs.
• Phase 2 - Expanded Rollout: Deploy to larger host groups, incorporating any policy adjustments identified in the pilot.
• Phase 3 - Full Deployment: Deploy to all remaining managed endpoints once the policy has been validated.

How to

1. In the management console, navigate to Policy Deployment or Policy Distribution.
2. Select the policy or policy set you configured in the preceding steps.
3. Choose the target host group for your initial deployment (pilot group for staged rollouts, or all hosts for a direct deployment).
4. Review the deployment summary to confirm the correct policy is being sent to the correct endpoints.
5. Initiate the deployment. The management console will report deployment status for each endpoint.
6. Verify successful deployment by checking the agent status on a sample of endpoints. Confirm that the EPM policy is active by running a test command that should be allowed, and one that should be rejected.
7. Monitor the audit logs closely in the first 24–48 hours post-deployment for any unexpected rejections that may indicate a policy gap.

⚠️

Before deploying to production, ensure you have a rollback plan. Document the steps required to revert to the previous policy state in the event of a critical operational issue.