Dual Control is a functionality that means that two entities are required and responsible for a particular action. As a function, Dual Control enabled only authorized, Safe owners to either grant or deny requests to access accounts. The Dual Control feature in CyberArk ensures an additional measure of protection. It enables you to know who wants to access the information in the Safe, for what purpose and the time when the permission is requested. Importantly, as per CyberArk’s Master Policy, Dual Control also enables organizations to ensure that passwords can only be retrieved after ‘permission’ or ‘confirmation’ has been granted only from an authorized Safe Owner(s).
As the name implies, Dual Control involves two layers to ensure greater security. Authorized Safe Owners in an organization or business have the permission to either grant or deny requests to access accounts when they receive them from a user. The feature provides an additional measure of protection because it enables you to see who wants to access the information in the Safe, when and for the purpose of use. It should be borne in mind that the first member of the group who confirms or rejects a request does so on behalf of the whole group. In case more than a single confirmation is required, each group is treated equivalent to a single authorized user and then becomes subject to a single confirmation or rejection.
In the workflow, as soon as a user(s) receives confirmation for a request from an authorized (Safe) user, they are able to access the password that the request was created for and gain access. But, until the permission has been granted, they cannot access on their own in that particular environment.
The manual security workflow involves creating the following steps:
Request created by user: When a user wishes to access an account in an environment wherein the Master Policy enforces Dual Control, he must first create a request. In the request, the user must specify the reason for accessing the account, whether they will access it once or multiple times, and the time period during which they will access it. A notification about the request is sent to Safe users or confirmers who are authorized to confirm this request.
The authorized Safe user either confirms or rejects the request: Through the notification they receive, authorized users can access the request and view its details. Based on these details, authorized users have the necessary permission to either confirm or reject the request. How many authorized users are required to confirm requests is defined in the Master Policy.
The user connects to the account after receiving necessary permission. Each time an authorized Safe user or confirmer responds to the request, the user who created it receives a notification. When the total number of required confirmations has been received for the request, the user receives a final notification. The user now has the permission to activate the confirmation and access the account according to the request specifications.
As long as requests are valid, users can keep accessing provided it is not for a single access. When a request becomes invalid, it cannot be accessed by either the user who created it or by users who are authorized to confirm it.
Requests may become invalid for any of the underneath reasons:
Essentially, the primary purpose of Dual Control in CyberArk is to ensure an additional layer of security whereby control is shared by both the User and the Safe Owner. This has been stated earlier and remains the all-important feature of the function. It involves the following steps –
It is important to remember that this is never an open-ended process. Requests for access are always time-bound and become invalid after the time allotted has lapsed. Requests may become invalid for the reasons mentioned in the above section. If a request becomes invalid, it cannot be accessed by anyone - neither the user who raised it, nor by the Safe owner or any other authorized users who might have confirmed the request.
It is vital that users make use of the access time they have been permitted. In other words, use access to requests as long as they are valid.
Your email address will not be published. Required fields are marked*
Copyright 2022 SecApps Learning. All Right Reserved
Comments ()