Source: https://2.flexiple.com/scale/all-illustrations Break Glass procedures are commonly used to protect and grant emergency access to critical information, such as high-privileged accounts or secrets. Although not limited to information security, these procedures come in many forms and formats. Some require physical access to the secret, or may include a requirement to have two individuals available to […]
Break Glass procedures are commonly used to protect and grant emergency access to critical information, such as high-privileged accounts or secrets. Although not limited to information security, these procedures come in many forms and formats. Some require physical access to the secret, or may include a requirement to have two individuals available to perform the procedure. This last one is usually referred to as the “Two-man rule” or “the two-person concept.” In this article we will discuss a new approach to Break Glass, as a distributed and redundant extension of the “Two-man rule,” which we called the “N-Man rule.”
Taking a closer look at current Break Glass models, one may immediately find several limitations and dependencies like the ones previously mentioned, which are naturally attached or derived from the type of protections required to secure such critical information. And these precautions are in fact absolutely necessary, as the last thing that you want is to have the GodMode keys to your precious assets misused, abused, or exposed.
Although these Break Glass methods can be considered acceptable from a protection standpoint, they don’t actually scale well with highly dynamic and global operational requirements. Take for example the Two-man rule: it is actually possible to split a secret between two individuals, ensuring that no single person would use it autonomously, but you would always need the availability of both individuals, and only those two individuals. So if the time comes to (knock on wood) actually use the emergency access, how do you ensure that you have a global, 24/7 highly-available and immediate access to that secret? How will you rotate that secret efficiently? Will you depend on physical tokens or other similar hard supports? How would that work in terms of global logistics? And what’s the cost of running all of this?
So what if we could actually extend the current Two-man rule in a distributed and redundant manner, in order to overcome some of these limitations? Enter the “N-Man rule.”
The operating principle of the “N-Man rule” is set by the following:
Take a Secret (S) and split it in multiple parts (Sn) according to a defined Replication Factor (rf). Distribute each secret part across multiple Key Custodians (KCn) sequentially. The Replication Factor relation to the number of Key Custodians will need to be in the form of 1<rf<KCn.
No single Key Custodian will have access to the full Secret, but a combination of multiple Key Custodians (depending on the defined Replication Factor) will in fact be able to complete the full original Secret. Nice!
As an example, and in its most simple form, we can have a Secret (S) split by 3 Key Custodians (KCn=3) with a Replication Factor of 2 (rf=2).
How would we split and distribute the multiple Secret parts by all Key Custodians?
With this distribution in place, no single Key Custodian has access to the full Secret, but every combination of 2 Key Custodians can actually complete the full Secret by combining their corresponding Secret parts. Simple, right?
Now what if we have 4 Key Custodians (KCn=4) and keep the same Replication Factor of 2 (rf=2)?
In this case and similar to the previous example, no single Key Custodian has access to the full Secret, but this time around at least any 3 Key Custodians are required to ensure that you can unlock the full Secret (or 2 Key Custodians in specific combinations, which we don’t want), as the Replication Factor remains the same (rf=2).
Finally (and you’re probably already getting where this is going), we can demonstrate how this would fit in a 4 Key Custodians (KCn=4) distribution, but this time with a Replication Factor of 3 (rf=3). The distribution would be:
In this final example, and again, no single Key Custodian has access to the full Secret, but with a Replication Factor of 3 (rf=3) only 2 out of 4 Key Custodians are required to unlock the full Secret.
Taking what we’ve seen here so far, we can identify a few advantages and disadvantages for this model. For advantages we have:
We must note one important disadvantage related to the Secret length. Secrets must be both strong enough and long enough to prevent trivial password guessing attacks from a single party (i.e. minimum 24 characters for an 8 character guessing slot in a KC=3 rf=2 configuration).
In this article we’ve approached some of the current limitations with Break Glass procedures, and proposed an extension to the existing Two-man rule in order to address some of these issues and make the process distributed and redundant.
If you want to have a quick run with this method, we’ve created a very (very) simple PoC Python code to support it, which basically reads a Secret from STDIN and does all the splitting for you based on the configured number of Key Custodians and Replication Factor. The code is available here.
We would love to hear your thoughts on this also, so please feel free to reach us!