What are possible implementations (or examples) of the four-eyes principle?

Question

Michael Grünewald recently posted this comment:

A very important method you do not mention is the “four-eyes principle” which is used in the finance – either as a regulatory obligation or as a safe-guard. In the software industry it is implemented in various ways, as e.g. code reviews but also can be used to validate commands affecting live systems.

Correct me if I'm wrong, but I was taught that the "four-eyes principle" is about something that is "approved to happen", after at least 2 human beings (and/or automated processes) gave their prior blessing. Or to use the (slightly corrected) wording about the "two-(wo)man rule" from Wikipedia:

The two-man rule is a control mechanism designed to achieve a high level of security for especially critical material or operations. Under this rule all access and actions requires the presence of two authorized people at all times.

Regulatory obligations are, pretty sure, off topic here, but in the context of "safe-guard", what are the possible conceptual implementations of this four-eyes principle, which probably could apply to any platform / OS / hardware being used?

Answer 1

One of the implementation on code is the Pull Request model (PR) popularized by GitHub.

The main reasoning behind is that only a small set of maintainers of the product will be allowed to merge code into the release branch. Every new feature/bugfix will happen on a new branch and once done will be defined as a pull request.

This allows to test on the merge from actual release (master) code with the code in the PR in an automatic way (Travis being the most popular for public project actually) and give a first feed back on the code quality. Travis CI (for example) can run on the result of actual master with the code from the pull request merged into it, so it will fail if the merge is impossible, or if the commands defined in the travisci.yml return a non zero exit code

Once the automatic tests have passed, for the 4 eyes principle, it still requires a configurable number of persons to review and approve the change before it gets merged obviously at least 1 person (who is not the PR author) to enforce 4 eyes reviewing the changes.

There's a wide range of options to merge automatically once the quorum of reviewers is met or to still need a manual merge by a maintainer.

The permissions to review and merge can be separated which helps giving more people the right to "vote" on the merge status while keeping the possibility to restrict who can actually do the merge.

Answer 2

Code Reviews

This is about having at least 1 other person look at the code written by somebody, eg to evaluate if it meets some predefined criteria like:

• Coding standards (indentations, etc).
• Inline documentation.
• Maintainability of the code.
• Error handling.
• Completeness (eg if/then/else or case/when constructs cover all possible cases).

Approvals to update some target environments

This is about having at least 2 confirmations from some person and/or automated system before it is allowed to update some target environment (which may be live, or may be something like some master file / baseline library). Some examples are:

• Only a limited set of warnings are allowed when transforming (building) source components in executable components.
• Some set of automated tests must have completed without any probems.
• Some human beings must have indicated their prior approval (and without that, any attempts to update the target environments will automatically fail).

Answer 3

These are strategies/patterns I can think of:

Separation of Duty

DevOps, to my view at least, does not means embodying of both dev and ops in a single person. So it is still possible to separate the duty such that the one writing the code (dev) is not the one executing it (ops).

For example, if an SQL statement is to be executed on the live environment, one writes the SQL and another executes it. What this presupposed is the the one executing need to also have an understanding of the SQL and not just execute.

Deploy trigger

While there are merit to continuously deploy. Team in a more regulated industry can appoint another (separate) party to trigger the deploy instead of deploying automatically. Checklist, automated tests, checksums are possible checks before triggering deploy.

Once triggered, the automation can go ahead to execute the deployment.

Pair Programming

Personally I have not cited this technique as a method to auditor to satisfy the check and balance principle. But potentially I think it can be a strategy.

MFA

I might be stretching a little with this one, but it is possible that for some reason that you don't want unilateral entry into a system, someone can hold the password and another person hold the token or device for one time code. So that, 2 person must be present to assess the system.