Parallel systems, in case any of two has known exploits

Question

As software becomes more and more complex it's harder and harder to keep it secure down the entire line. Discussing this problem with a friend we were opting some pretty extreme solutions and wondered whether the following is done anywhere (presumably in companies that would also air gap at least parts of their infrastructure):

Having two parallel systems ready and switching whenever a dangerous public exploit is known about any of the software in any of the two stacks. For example, one setup based on Microsoft software, and another set up based on open source software. This could be done on any level, be it routers, server and even down to actual desktops ("PA: Please reboot your system as soon as possible to the Windows OS until further notice").

Now, I have never even needed to consider such a set up, but I have been in situations where I knew our systems were hackable, but sometimes had to wait for hours before some kind of temporary workaround was available online. In those cases you watch your logfiles a bit more closely and shut down your entire system in case of a breach I guess, but that's far from foolproof (especially in cases where no identifiable logging is available in the first place).

Answer 1

While most items have already been picked up and discussed by dr jimbob in his answer, I would like to draw your attention to the following:

1. This kind of problem is called "common mode failure".

2. Nancy G. Leveson has studied common mode failures and the purported solution of redundant software (software stacks, as you describe) and noted that commonality may go much deeper than expected. For instance, both systems may share an implementation of some protocol, which means you're hosed if there's a vuln sitting somewhere inside. The same developer may have been hired by the two companies, or the coders were too lazy and unimaginative to invent their own algorithm and simply picked the same algorithm from a publicly available source. There's really no limit to such commonalities, and you cannot rule out any of them without thorough examination of the code.

3. Having both stacks online means a gifted and resourceful adversary will be able to get inside both and possibly subvert the switching mechanism.

4. Having a hot and a cold stack means the cold stack has to be kept up-to-date with all security patches (hence, it's not entirely cold, even if updates are done behind the air-gap, and does not provide total availability).

5. The biggest drawback of your scheme is that there is a fundamental commonality in place: both systems are implemented in software. If you really want to defend in depth against an advanced threat, build a separate, simplified system that does not rely on sophisticated networks. Plain old telephony (even sound-powered telephony) and human operators are very useful for this very purpose.

Answer 2

This seems somewhat counterproductive. It's a lot more work to maintain a redundant system, built on an entirely different software stack, and keeping the data synced between the two very-different systems. It more than doubles the work necessary (maintaining two systems doubles the work, and then keeping them synced and consistent). The expertise required will be different on very different stacks, so you'll probably have to have a whole new set of staff and deal with all the overhead of group intercommunication.

It also doubles the potential exposure. Instead of being vulnerable to just zero-day attacks on the stack you chose, your data is vulnerable to being stolen if either stack has any zero-day holes in them whenever that stack is operational. (This wouldn't be the case if one stack is always offline from the outside world until needed).

Granted, in cases where downtime is completely unacceptable such a solution may make some sense, where you have a standard stack with all your fancy features, and a somewhat simplified in-case-of emergency stack that you switch to if there's a problem with your main systems or they are undergoing a major upgrade.

Answer 3

I've never heard of anyone doing exactly your approach. When you consider zero day vulnerabilities, this doesn't help you much, as you have no idea what zero days exist in each stack. It could potentially double your exposure, as an attacker with a zero day in stack B could wait until you switch from A to B, and then attack you.

A somewhat similar principle is widely followed however. A common network design is "internet - firewall - dmz - firewall - internal network". In such designs, some security experts advocate using firewalls from two different vendors. The theory is that if a vulnerability exists in a firewall from one vendor, it won't exist in the other, so it won't be possible for an attacker to get from the internet to the internal network.

In fact, this used to be standard advice, but it has now been discredited. The problem is that your internal network is most at risk from browser-based attacks on workstations, and using two different firewalls does absolutely nothing to address that. In addition, it has turned out that firewalls seem to be a pretty safe bet - few serious vulnerabilities have been discovered.

It's more common these days to have a single firewall with multiple connections for DMZ, internal networks, etc. In fact, such an arrangement is preferable because it makes it cheaper and easier to set up isolated network segments, and that has far more security benefits than using multiple firewall vendors.