Are you sure you want to delete read this blog?
We’ve all encountered the double-confirmation in user interfaces that prevent us from making a big mistake. But if I’m honest, over time, I’ve been conditioned to just clicking “Yes” without reading the warning or advice in the dialog box, not very cyber-secure, right? If the dialog asks me to “type a text” as part of the confirmation, I simply copy and paste the confirmation text…And I am sure that I’m not the only one. This doesn’t mean that the double confirmation has lost its purpose, but merely that it cannot be the sole barrier that protects you, as an administrator, from accidental damage to your most precious applications and data.
As a result, businesses have established many policies and procedures they must follow when caring for their most critical business applications and data. However, there are a few core policies that increase data safety, protect against accidental damage, and also reduce organizational liability. A policy that has its origins in military protocol, has been welcomed into the arsenal of IT security controls and is particularly popular: the two-person commit rule.
With this protocol, there must be two individuals who need to act in concert to perform some action, usually something destructive. They must each perform a separate, independent verification of the action before it can be carried out. Plus, both individuals need to have sufficient knowledge and skill to detect attempts at subversion initiated by the other.
It is immediately clear why this concept is essential for highly sensitive tasks, such as the permanent retirement of application data. It helps prevent unauthorized access or manipulation of systems and ensures that critical actions are performed correctly and with proper approval. While we are not talking about nuclear power plants here, losing critical data can lead to terrible consequences and even businesses forced to close their doors forever. Especially during the current surge of cybercrime, e.g., ransomware attacks, you don’t want a single individual to have the power to delete all your data.
The two-person commit rule isn’t new in IT security
We’re not only talking about protecting against mistakes but also intent. This is an important differentiation. Mistakes are unintentional, where the individual may have acted in good faith and there was no intention to cause harm or damage. On the other hand, an intentional act of destruction, where the individual has a deliberate purpose or motive to cause harm or damage, may require significantly stricter security protocols.
The principle of the two-person rule isn’t new in IT security and, if implemented, it reliably protects against mistakes with sensitive or risky operations. The definition of such an operation varies based on the organization’s policies, regular constraints, or the organization’s industry. However, one can easily understand that operations that involve the deletion or removal of information or resources from a business-critical IT system can be considered a highly sensitive operation and requires stringent security controls.
The process to implement such controls is often achieved through role-based access control (RBAC), where an authenticated user needs to assume a role that grants them the authority to perform an operation. The options for the detailed implementation vary. Let me illustrate a simple example where an administrator has assigned the role of “delete resources” to a user. This role grants the user the ability to delete data. The user does not know the password to assume this role, which resides with a secondary user. In effect, the user can authenticate, but when they want to assume the role of “delete resources,” they need to involve a second user that knows the password. In effect, the user will not be able to delete data on their own. However, did you notice the flaw that is rooted in this example that makes it vulnerable to intentional damage?
The root of all evil
It’s rather obvious, isn’t it? “An administrator has assigned” – in most infrastructure solutions administrators have the power to create user accounts and assign roles. Malicious actors, either the administrators themselves or someone that has stolen their credentials, may assign themselves as a secondary user that helps assume the “delete resources” role, bypassing all security protocols.
While using single-sign-on with an external identity provider like Azure Active Directory (a recent introduction to the Nebulon feature set and a baseline standard for any zero-trust solution) has mitigated this problem to some extent by separating the responsibilities of identity management and infrastructure management, it is a single point of failure. Having a single individual with root privileges means that any other privilege can be produced by this individual. In the context of the two-person rule, this is producing a secondary “virtual” user to do the independent verification of the sensitive operation. Unfortunately, this problem carries itself through all layers of the infrastructure.
For example, a more modern version of the two-person rule can be implemented via GitOps. Here, the infrastructure is declared as code in a Git repository. Users don’t have access to infrastructure, only an automation system. A change to the infrastructure through a Pull Request (PR) requires multiple approvals from individuals as a merge condition. So, multiple individuals need to approve the change. But also here, users may create secondary user accounts to approve their own changes.
The “other” approach
Quite recently we introduced a different approach to the two-person rule. With this approach, we introduced a neutral, third-party into the process. This “other” individual acts like a broker in the process, ensuring that the two actors in the two-person validation process are indeed separate individuals. We call this functionality “Two-Person Commit” and it was rolled out to all customers in January this year via an automatic update in our Nebulon Cloud.
The Two-Person Commit feature allows the implementation of a stringent workflow for your most critical application environments, protecting against accidental or intentional damage to your business-critical data. The workflow is quite simple to explain: An authenticated user requests to perform a restricted action, triggering a representative of our customer satisfaction team to validate the identity of the user and a second user in the organization with the required privileges. This is comparable to a notary when signing a contract. Once verified, the action is approved, and the user can execute it through the Nebulon Cloud via the graphical user interface or API.
I’m certain that you have business-critical applications and data that you want to protect from malicious users’ destructive actions and Nebulon’s zero-trust methodology offers our customers a built-in suite of security with role-based access control for implementing a “least privilege” principle, multi-factor authentication, single-sign on, encryption, auditing, and now Two-Person Commit. To learn more, get in touch with us and learn how Nebulon can secure your critical infrastructure in the data center and at the Edge.