Okta Privileged Access provides a flexible framework for controlling who can access what privileged resources and how. This includes resource groups for managing resources, security policies for controlling access, administrative roles to manage them, and principals to use them. Invariably configuring the PAM solution will introduce risk. But how to monitor and manage the risk in your environment? This article looks at how risk in an Okta Privileged Access could be determined and exposed through an Access Certification campaign.

This is a follow-on article to OPA and Access Certification – Getting Roles into the Group Description where I looked at how to update Okta group descriptions to include Okta Privileged Access roles and policies.

Okta Privileged Access and Risk

Okta Privileged Access (OPA) is a Privileged Access Management product – it controls access to privileged systems and accounts. There will always be some risk associated with managing this access. It is important to minimise risk through effective implementation of policy. But in a complex deployment, risk may not be apparent due to overlapping or unexpected combinations of policy. It is sometimes hard to see where policies intersect or overlap and the implications of this.

In OPA, this risk may be due to the user assignment (through groups) to policies – i.e. who can access what privileged resource and how. It may also come from the administrative roles assigned to users (through groups) – i.e. who can set or modify the policy. There should be a plan for the design of these groups, roles and policies. There should also be review mechanisms, such as discussed in this article.

Defining Risk

Any risk definition would be a combination of the level of access and the type of resource being accessed. Accessing a production server with a mission critical database as the superuser of that server carries a lot more risk than a regular (non-admin) access to a test server.

Understanding the risk associated with a resource being accessed is largely a business problem – someone needs to assign a rating to different resources. However we can look at the roles and policies in OPA to get an understanding of risk. For example accessing a server using the superadmin account or admin elevation is higher risk than accessing a server with a non-admin account.

For this article I looked at the different options for admin roles and security policies in OPA and built a mechanism to evaluate them. The following sections define the risks I’ve identified and the level I’ve assigned to them – LOW, MEDIUM or HIGH. This is subjective but can be used as a guide.

Also, the data model on the policies means that there are multiple levels, such as rules within policies and different resource assignments and conditions in each rule. The approach I have taken is that the first of the highest risk bubbles up to a higher level. For example if a rule has two HIGH level risks, and one MEDUIM level risk, the rule will be considered to have the first HIGH level rule. For the sake of the exercise, it doesn’t really matter which HIGH risk is used, just that the rule is a HIGH level risk.

Role Risk

There are different OPA administrative role assignments, with the system-wide roles having more scope (thus risk) than the delegated roles.

For this exercise I have assumed the following risk conditions:

• Any of PAM Administrator (pam_admin), Security Administrator (security_admin) or Resource Administrator (resource_admin) = HIGH
• Any of the Delegated roles = MEDIUM

These roles are mapped directly to groups.

Secret Policy Risk

OPA policy can be either Secret Policy or Server Policy. Secret policy defines what actions can be taken on folders and secrets, with administrative actions of create/update/delete and read-only actions of list and reveal (secrets). Secret policies can also have conditions tied to them, such as access request and MFA (soon).

For this exercise I have assumed the following risk conditions:

• Any of create/update/delete on folders or secrets, without any additional controls = HIGH
• Any of create/update/delete on folders or secrets, with any additional controls = MEDIUM
• Read-only (folder/secret list & secret reveal) = LOW

You could argue that the risk relates to the secrets being accessed, but we cannot determine that just by looking at policies. You would need to assign risk ratings to different folders and secrets.

Server Policy Risk

Server Policy in OPA controls which servers a user can access, what accounts they can use (individual or shared), if the individual account can be elevated to admin rights, and what controls to apply (access request, MFA, session recording etc.).

For this exercise I have assumed the following risk conditions:

• System admin account (root, Administrator) without additional controls = HIGH
• System admin account (root, Administrator) with additional controls = MEDIUM
• Other shared account without additional controls = MEDIUM
• Other shared account with additional controls = LOW
• Elevated to admin without additional controls = HIGH
• Elevated to admin with additional controls = MEDIUM
• Individual without elevation = LOW

For this, I have decided that only ‘Access Request’ and ‘MFA’ would be appropriate mitigation controls as they are checked before access is granted. You might consider ‘Session Recording’ a mitigating control, but it is after the fact and less likely to reduce risk.

As with secret policies, you should also consider the servers being accessed and the risk of them being accessed, but we can only look at the policies to determine risk.

Determining Risk for Policies and Groups

The first part of this exercise is to look at the risk associated with policies (and therefore groups of users assigned to the policies). This section will look at the process of collection and then explore the Workflows used to do it.

A later section will look at combining this with role-based risk and writing that to group descriptions.

Collecting the Risks by Group and Policy

Lets look at how we can determine risk in policies and thus the groups assigned to them.

All detail on the policies can be accessed by using the List All Security Policies API endpoint. This endpoint will return a list of complex objects, each one representing a single security policy. These include:

• The id, name and description of the policy

• The principals, a list of the user_groups (and users) assigned to the policy

• The rules, a list of all the rules in a policy. Each rule may contain:
  • The id, name and resource type (secret or server)
  • A resource selector – defining what resource it is assigned to. This is for secret resources
  • Any resource_groups a secret policy may be assigned to
  • The privileges, such as the actions the policy allows for secrets and folders or whether an individual user can be elevated to an admin level when connecting to a server
  • The conditions, any access conditions such as an access request or requiring MFA

To determine a risk level (and assign a reason) all of the policies and their rules must be unpacked, and the different aspects of the policies analysed to find the risk conditions shown earlier.

As there could be multiple risks within a single rule and multiple rules in a policy, the highest must be determined and bubbled up to the policy level. Groups are assigned at the policy level, so the group risk includes the risk of every policy it is connected to.

The following (Workflows table) shows the completed evaluation of risk in my OPA environment.

Let’s look at how this was implemented.

Workflows to Derive Policy Risk

The following workflows are used to produce the table above.

The PAM30* workflows are operating on the policy list and each policy in the list:

• PAM30 – Will use the policies API to get a list of all policies. It calls PAM30a for each policy in the list.

• PAM30a – Will process each policy in the list, stripping out the principals, the policy details (name, desc etc.) and the rules. For each rule it calls RSK10 to perform the rule risk analysis. It will consolidate the risk from all the rules, then call PAM30b to write out the table shown above.

• PAM30b – This writes out each group-policy combination to the table.

There flows are fairly straightforward using standard API cards, and object/list manipulation.

The RSK** flows are evaluating the risk in each policy rule.

The RSK10 flow will run for each rule, and it determines whether a rule is for secrets or servers (resource_type). It will call RSK11 for secret rules and RSK12 for server rules. The logic for the different types of policies could all be in the if/else branch in the RSK10 flow, but I decided to split them out into their own subflows to make it easier to understand and maintain.

The RSK11 flow runs for each secret rule.

It is passed the rule object and will strip out the privileges[0].privilege_value which contains the actions (such as folder_create). The actions are extracted into their own T/F values. Then a True/False Or card is used to determine if any of the administrative actions are true.

It then checks if any conditions are present for the rule. There is currently only the access request condition (MFA soon for secrets) so any conditions (i.e. list.length > 0) means there are mitigating controls. In this case the risk level is set of MEDIUM with message, or if there are no conditions the risk level is set to HIGH with message. These are passed back to RSK10 for consolidation with any other rules for this policy.

The RSK12 flow and it’s subflows run for each server rule. It is passed the rule object and extracts the name, resource_selector, privileges and conditions. Then there are four sections:

• Find Risky Accounts – use RSK12a to determine if root/Administrator, other shared accounts or ordinary accounts are represented in the resource_selectors

• Find Elevated Privileges – use RSK12b to determine if there are any admin_level escalations for ordinary accounts

• Find Mitigating Controls – use RSK12c to determine if any of the conditions are for access request or MFA

• Check Risk Rules – the earlier risk conditions for servers are built into if/elseif/else loops to determine the risk level and message.

Each of the first three sections follow a similar pattern.

They call the subflow using a List Map card, which will return the results in a list, with an entry for each resource_selector/privilege/condition passed in. This is because each of these are lists and could have multiple values. When the list is returned, we check to see if there’s something we’re looking for – if it’s a superadmin account (root/Administrator), another shared account, an elevated individual account and mitigation control. This is done using List Find cards. If found the value is used for the last section – the check risk rules.

At the end, the risk level and message for the rule is passed back to RSK10 for consolidation with any other rules for this policy.

The RSK12a flow is checking the selector_type for individual assignments (individual_server_account) or label-based assignments (server_label).

It will look for root/Administrator in the account list and if found flag it as a superuser account. If there’s another shared account assigned it will flag it as such. It also collects the account list and builds a message for the risk. These are returned to RSK12.

The RSK12b flow is looking for admin elevations in the privileges list.

It finds a privilege_type of principal_account_ssh/rdp and if it finds it will flag it as having admin permissions. It will return that flag, a message and accounts list to RSK12.

The RSK12c flow is checking for access requests or MFA conditions.

If it finds either an access_request or mfa condition_type it flags it as a mitigation and returns that, along with text, to RSK12.

As mentioned earlier, the results from RSK12a, RSK12b and RSK12c are used with the risk conditions to determine the highest-risk for this rule. The risks for each rule in a policy are bubbled up to REP30a and the highest one is selected for the policy. This is what is recorded in the table shown earlier.

Next we will use that information to help access certifications.

Viewing Risk in Access Certification

Above we explored how we can determine risk on policies. We can combine risk based on roles to provide a level of risk (and reasons for it) for groups assigned to both policies and roles and present that in the Okta group description. This can be useful in an access certification campaign to see the risk associated with a user’s membership of a specific group.

We can leverage the mechanism above and merge it with a mechanism I built earlier (see article here) to present the risk along with the roles/policies for each group.

Showing Risk in Group Description

In this article I showed how the Okta group description can be updated to include a summary of the roles and policies the group is assigned to. Combining this with the mechanism described above, the risk can be added to that description.

This is very useful in a User Access Review (Access Certification campaign for users) where a manager needs to decide if the user still needs privileged access. The slide-out window for each review (user-resource) row includes the group description.

Whilst the description overflows the field, you can mouse over to see the full description including the roles/policies and associated risk levels.

This should make the life of the business reviewer a lot easier.

Okta Workflows Implementation

This was implemented in Okta Workflows and leverages three components:

• The entire set of flows covered in this article,
• The mechanism to determine risk for policies covered above, and
• A subflow to determine risk based on admin roles assigned to the group.

As per this article, there are two main flows: MAIN and MAINa. MAIN will get get the list of groups in OPA and for each one call MAINa to process that group. MAINa will:

• Check the group is not “owners” or “everyone” (and stop if it is either)
• Get all policies this group is assigned to with risk (this is the mechanism described above)
• Search for the group in Okta and stop if it’s not found
• Use a new flow, RSK20, to determine the admin role risks for this group
• Get group details from Okta
• Build and update the group description in Okta

This new flow, RSK20, determines the risk based on the admin roles assigned. It looks for each of the five standard roles (three system-wide and two delegated) in the list of roles passed in.

If any of the three system-wide roles are found, it sets a HIGH risk level. If either of the two delegated roles are found, it sets a MEDIUM risk level.

Then it converts the role list to a string and appends the risk level. This is returned to the calling flow and added to the group description shown earlier.

Conclusion

This article has shown how you can look at the Okta Privileged Access roles and policies to determine a level of risk for users assigned to groups. It presented a set of risky conditions that could be in the policies and roles and how they can be programmatically evaluated and presented, including by using Okta group descriptions to highlight risk in access certification campaigns.

Ultimately risk will also depend on the privileged resources (such as servers and accounts) that roles and policies apply to, in combination of the types of access and controls applied in Okta Privileged Access. But that would require a wider business evaluation of these resources. Hopefully this article gives you some insight into how you could start the process by looking at the roles and policies and who is assigned to them.