Creating an Adaptive Access policy
You can create an Adaptive Access policy from the IBM® Security Verify administrative console.
- Log in to the IBM Security Verify administration console.
From the navigation menu, click
.A table lists the available policies by name and description. The icons indicate whether the policy can be edited or deleted . A lock icon indicates that the policy is preset and can't be modified or deleted.
- Click Add policy.
- Provide the policy name and optionally, a policy description.
- Click Next.
- Enable the Adaptive Access toggle button.
- Optional: Change the actions for each risk level.
Table 1. Risk levels and remediation actions Risk level Description Default actions Available remediation actions Very High A user that is assessed as a very high risk must be considered as a critical risk to the business. Either the user was acting in a suspicious way or the device that they are using is unknown, not trusted, or contains malware. Block
- Block (Override)
- The block action overrides all other decisions in the policy.
- MFA (Override)
- The MFA action overrides all other decisions in the policy.
- Allow (Override)
- The allow action overrides all other decisions in the policy.
- The user is denied access.
- MFA always
- Always require MFA, even in the same session.
- MFA per session
- If not already done, force MFA.
- The user is granted access.
- MFA options
- You can select one or more methods that can be used for multifactor authentication.
- Email OTP
- SMS OTP
- Time-based OTP
- IBM Verify
- Voice OTP
High A user that is assessed as a high risk must confirm their identity back to the business each time they attempt to access an adaptive access enabled application. This multi-factor authentication ensures that the business can trust that the user who is accessing the application is in fact the expected user. MFA Always Medium A user that is assessed as a medium risk must confirm their identity once per session. This multi-factor authentication ensures that during the initial application authentication the user is actually who they are logging in as. Subsequent authentication requests do not require a second-level authentication. When the session expires, the user is required to provide more authentication. MFA per session Low A user that is assessed as a low risk does not need to provide any additional insights into who they are beyond their initial authentication. All subsequent accesses to the application are allowed. When the current Verify session expires, the users are required to reconfirm their identity. Access to applications is granted. Allow
- Optional: Enable the user notification toggle to notify the user when access
is challenged or denied.
Table 2. Email information Attribute Description User action Location If available, the name of the city and country from where the request originated. Validates that this location is a known location from where the user authenticated in the past. Browser The name and version of the browser from which the request originated. Validates that this browser is a known browser that the user used for authentication to the application. IP address The IP address that the request came in from. If possible, validates whether the IP address is known.
- Click Next.
- Optional: Add a rule.
- Optional: Change the action for the Default
Rule. Click the for the Default rule and select an action from the menu. Then, click Save.
- Click Save. The policy is added to the list of available policies and can be selected when you set the access policy for the administration console and home page.
Manage the policy rules. See Managing Adaptive Access policy rules.