Reduced footprint vs minimal footprint

I read quite often about how a minimal operating system, with all things unnecessary for its expected functionality removed, is “more secure” because of the minimal attack surface.  While there is definitely something to be said for reducing the attack surface, having a minimal OS is not necessarily a good security practice.

“But Matt, if I don’t need something, then I should remove it so that an attacker can’t attack it, right?”  Maybe — it depends on how we define “need”.

If you are running a web server, do you need a mail server, or a print server, or a FTP server also running on that same system?  Probably not.  Remove those extraneous services from your deployment.

If you are running a web server, do you need a firewall ?  Well, the firewall doesn’t help you deliver web pages.  But I think many will accept that removing the firewall for the sake of minimality would be silly.  This is the other end of the spectrum, but helps illustrate the point that pure minimalism can actually negatively impact the security posture.

If you are running a web server, do you need a file system integrity monitor (FSIM) or other secondary defenses?  This is where we start getting into a fuzzy area.  I would argue that you should keep security tooling like an FSIM on your server.  The minimal footprint may help reduce the attack surface, but it will never be zero.  An attacker may still find a way in.  And when they do, you need additional layers (like FSIMs, EP, AV, MAC/SELinux, etc) to mitigate their impact and determine what they have done.  Don’t remove these tools from your OS deployment simply because you have a goal of minimally-sized functioning server.

If you are running a web server, do you need tcpdump, performance co-pilot, puppet, zabbix agent, splunk agent, or other operational tooling?  For normal day to day activity, you should never need these tools.  But occasionally, something will break, or something needs to be changed.  You will need tools that let you troubleshoot and fix, or that have been monitoring and collecting data for a period of time.  And if those tools aren’t already installed, you may not be able to install them during a problem.  Have you ever tried troubleshooting a network problem on a system where you can’t run “yum install tcpdump” because of the network problem?  While these tools are not security tools specifically, these are tools that are operationally necessary.  Consider keeping these tools, at least the critical subset of them, in your OS deployment.

If you are running a web server, do you need perl, python, ruby, and other scripting languages installed?  This requires deeper digging – do any of the tools that you’ve identified from the above scenarios require those languages?  Were they written in perl, python, or ruby, or require those languages for extra functionality ?  Tracing these dependencies can lead to a list of software that you may not have initially considered required, but due to choices of tools are not a requirement.  Assess this carefully, balancing your choice of tools against their requirements, but recognize that you may have to include some of these scripting languages, just to avoid creating security and operational impacts as described earlier.

So remember – your security posture cannot simply be measured by how small the OS deployment is.  Removing security tools from your OS can negatively impact your security posture, and removing operational tools from your OS can negatively impact your operational risk.  Before you start taking a scalpel to your OS with a goal of carving down to the smallest possible size, make sure you take into account your security and operational considerations, and the dependencies they pull in.