How to create a general access policy

This document guides you through creating a general access policy in EPM macOS, applicable to all devices that have the EPM macOS agent installed.

Access path

1. In Segura® Platform, on the navigation bar, hover over the Products Menu and select EPM.
2. In the side menu, select Policies > macOS > Access Policies.
3. Click Add to create a new policy.

Segregation screen

1. On the Segregation screen, select the General option. This option ensures that the policy will be applied to all devices with the EPM macOS agent active.
2. Click Continue.

General tab

1. Fill in the following fields:
   • Category*: select Applications.
   • Name*: Define a representative name for the policy.
   • Status*: check Enabled to activate immediately.
   • Action*: select the default action of the policy:
     • Allowlist: only the defined applications are allowed.
     • Denylist: the defined applications are blocked.
2. Click Continue to proceed to the next step.

Applications tab

On this tab, define the policy rules and enable session recording if necessary.

1. To record user activities during application usage, enable the Record session for these applications option.
2. In Strategy, select how the criteria will be evaluated:
   • Match any: the policy is applied if any criterion is met.
   • Match all: the policy is applied only if all criteria are met.
3. In the New table, add rows and configure:
   • CRITERIA (left column) and RULE (right column).
   • Click Add to insert a new rule.
4. Add rules using the following criteria:
   Info

   To obtain the necessary criteria, see How to obtain access policy criteria.

   • Use of regular expressions (Regex): For text-based criteria such as Path, Executable Name, or Arguments, you can use regular expressions in the PCRE2 standard in the Rule field.
     This allows you to create flexible patterns to cover different application scenarios. :::
   • Application Name: The name of the application you want to allow or block.
   • Bundle Identifier: The unique identifier of the application package.
   • Code Signature: The digital signature of the application, used to verify authenticity and integrity.
   • Path (Installation Path): The full path in the file system to the application’s executable.
   • Developer Identity: The developer or organization that signed the application.
   • Version: The specific version of the application you want to allow or block.
   • Sha256 Executable Hash: SHA-256 hash of the executable, used to verify file integrity.
   • SHA512 Executable Hash: SHA-512 hash of the executable, used to verify file integrity.
   • Executable Name: The name of the executable file; may optionally include arguments to target specific executions.
   • Application Category: The category/type of the app (e.g., Productivity, Games, Entertainment).
   • Username (User): The local account under which the application runs.
   • Arguments: Command-line parameters required or expected during the app execution.
5. Click Continue.

Workflow tab

Workflow tab

The Workflow tab will only be displayed if Allowlist is selected as the main action of the policy.

Elevation settings

1. Check Require reason to elevate applications to require the user to provide a justification.
2. Check Require approval to elevate applications if you want elevation to depend on approval.

If approval is enabled, also configure:

1. Approvals required: minimum number of approvals to allow execution.
2. Disapprovals required to cancel: number of rejections that end the request.
3. Approval in levels: activates chained approval logic with multiple levels.

Access request settings

1. Check Governance ID required when justifying? if you want to require this field.
2. Check Always add user manager to approvers? to automatically include the requester’s manager in the approval flow.
3. Click Continue to proceed to the next step.

Review tab