Network stability is a concept most system administrator instinctively know about: however, no organization actually had any need to willingly enforce it or even care about until recent years.
It’s only with the huge rise of mobile devices and their penetration inside enterprise environments that network – or better, infrastructure – stability has indeed become an issue.
What do we mean with infrastructure stability?
Stability is a property of any system behaving in a consistent, somehow foreseeable way. Most things in the world are somehow stable: you are not expecting your house to fall on your head, nor the hole in the wall you spent your Sunday fixing to pop open once again.
Just the same is true in networks, especially large networks. While new systems are being added on a rather regular basis, the vast majority of the infrastructure components keep running consistently until they stop serving their intended purposes and are then stopped forever.
Obviously, IT in large companies tend to err on the side of preservation, keeping useless services running when no one is actually using them anymore, “just in case”: that is, machines tend to have a very long persistence on the infrastructure. Furthermore, servers are generally expensive and the addition of a new system should be tracked and is, in any case, associated with a given project needs.
This has been true for years and every administration tactic or enterprise governance strategy leverages the inherent stability of “good old hardware”.
It’s heavy, it’s there and will keep being there until you actually unplug and archive it.
However, administrators in virtualized infrastructures are experiencing something different, something help desks and workstation ops have been struggling with for some years now: instability of the asset.
Indeed, it is not uncommon for any virtualization-enabled company to create machines only to have them turned off at some, rather close, point. They have fulfilled their intended purpose, but are not deleted because it is entirely plausible that they will be needed again at some point in the future. After all, it is not taking up rack or storage room space and it is not draining power. Considering how cheap disk storage has became, it seems very logical to just store it somewhere. Everyone can then forget about that very machine, administrators included.
Until it pops in the network again. Maybe some developer needed the machine, or maybe it used to run some software which is needed only that very day.
That machine escaped weeks or months of maintenance: antivirus definitions, security updates and security policies are at least as old as the last boot.
This means its level of security is quite under the expected and monitored current status of the network; it will, very likely, have the same network connection it used to have, possibly bypassing any network access control (NAC) or quarantine verification (technologies which, in any case, are not so common in the server domain).
What’s more, it could still host some worms the administrators managed to banish from the network weeks before.
Obviously, such a virtual machine can easily become a new vector of “re-infection” in the network, or be the perfect low-hanging fruit for attackers: the awakened guest operating system could be vulnerable to well-known attacks, whose corresponding exploits could have been developed and well-tested by the attackers. In such a scenario, even a short vulnerability window where the patches are quickly applied would be enough for the aggressor.
The need for quarantine system to assess the inherent instability of virtualization environments is, I think, quite evident. Unfortunately this is, once again, one of the unanswered questions of real-world virtualization security.
