Immutable infrastructure is more secure

An immutable server is a server that, once deployed, is never modified, patched or upgraded. It is merely replaced with a new updated instance if required. Immutable infrastructure extends this approach to the entire cloud.

Immutable infrastructure can be inherently more secure by making it much easier to detect when a resource has been maliciously modified.

Chad Fowler introduced Immutable Servers in 2013 when he described normal mutable infrastructure as:

[it] becomes finicky. It only accepts deploys in a certain manual way. The init scripts no longer work unless you do something special and unexpected … the system becomes a house of cards. You fear any change and you fear replacing it since you don’t know everything about how it works.

The beauty of immutable infrastructure is that it not only solves many of these reliability issues, but also transforms security.

Mutability, the Vector for Compromise

Mutability is oxygen for hackers. Nearly all persistent attacks will modify the underlying system in some way. Such changes include replacing binaries or libraries, adding programs or root kits, opening network ports and modifying critical data. Preventing these changes is key to preventing attacks. Detecting such changes is paramount for an effective defense.

Although, preventing modifications on a mutable system is hard. Detecting changes on an immutable system is easy.

In a mutable system, that is patched and updated, it is extremely difficult to conclusively know if the changes to the system are authorized or not. Linux makes this especially difficult.

With Linux, binaries and libraries are scattered over many directories: /boot, /bin, /usr/bin, /lib, /usr/lib, /opt/bin, /usr/local/bin and many more. Configuration files are similarly scattered over /etc, /opt/etc, /usr/local/etc, /usr/lib etc. These directories have files that should never be modified and others that are regularly updated. When the system update services run, they often create temporary files in these directories as well. Consequently, it is very difficult to lock down these all these directories and perform authorized system and software updates at the same time.

Through various heroics, you can try to detect which modifications are authorized and only permit system updates during specific time windows. But this also opens windows of opportunity for hackers. Clever attackers can piggyback their hacks to coincide with authorized system updates and thus “sneak through the gate” undetected.

Immutable servers solve this entire mess. With an immutable server, any change is an indication of compromise — as no modifications are authorized, ever!

When Intrusion Detection Systems are coupled with immutable servers, they can detect changes to the system in real-time and either quarantine, stop or terminate the server immediately.

Extended to the entire cloud, the immutable paradigm enables an entire cloud service to be exactly configured and monitored for any unauthorized changes. It is thus much harder for an attacker to modify or corrupt the service without immediate detection.

On the cloud-side, Terraform can audit the configuration for deviations and can re-apply the desired configuration. On AWS, this means detecting changes to VPCs, service groups, accounts, IAM roles etc.

With SenseDeep, we’ve utilized this approach of immutable infrastructure and it has significantly simplified the task of securing our service.

This is the future for secure operation in the cloud. Immutable infrastructure is here to stay and will become the norm. With tools like Terraform, building immutable servers and configurations is easier than ever.