System Management Principle Number 6:
If you remove one more bit, the system will fail.Minimal installs, when applied to systems, result in systems that have higher security availability.
This isn't new. This is just a restatement and perhaps an extension of normal securing and hardening of systems. The following are examples of how to apply least bit to various parts of your systems and applications.
File System Permissions (rights) are least bit when removing one more role, right or permission results in a failed application. The goal is to minimize permissions, either by starting with no permission bits and adding permissions until the application is fully functional, or by starting with a best guess on permissions and removing rights & permissions until the application fails. Ideally the vendor would have tested and configured the minimum permissions and rights for the application.
That rarely, if ever happens. The best example I've encountered is a couple decades ago when installing WordPerfect Office (now Novell GroupWise). The WordPerfect Office instructions gave a whole page of detailed instructions on exactly what file system permissions were needed through the entire application directory structure (Read, Filescan, Create, Modify, Write, Erase, etc). I tested every one of them & found that they almost had the principle down perfect. They only one extra bit in on one directory.
Avoid, at all costs, the system admin shortcut of 'just give it full rights, we can figure out what to take away later'. Later never happens.
Oh - and for the Unix'ers reading this - Netware actually HAD file system permissions.
File Systems are full of abandoned applications, abandoned installations, dead scripts and unused Java run-times (how many of those do you have on your servers?). Every one of them is a violation of the least bit principle.
Operating System Installations start with the most minimal installation possible. Use the 'Base' or 'Core' installation and add packages or options as needed for application functionality. Never, under any circumstances, do anything resembling 'full install'. Vendors might balk. System managers need to un-balk the vendors. We were told that Sun E25K's must have the full operating system installed and that our minimal, stripped-down install wasn't supported. We responded by advising that we could, if we so desired, run our 32 core Oracle servers on HPUX.
Microsoft, with Windows Server Core, appears to be moving in this direction also. Thank you Redmond. I'm starting to like you.
Minimal operating system installs carry security bonuses. It's a fine day when you can read down the weekly or monthly list of security vulnerabilities and X them off with 'not vulnerable, package not installed'.
This is a continuation of the age old hardening practice of minimizing the ports that a server listens on, and minimizing the number of services that are running. Except that the services are not even installed.
Databases have options, features and configuration that keep us busy full-time figuring out what they do & why we need them. DBA's are pretty good at minimizing user rights and roles. The least bit principle applies not only to user rights and roles, but also to database feature installation. If the application isn't using a feature, the feature should not be installed. With a minimally installed and configured Oracle base, when you walk through the quarterly Oracle nightmare that they call a Critical Patch Update, half the time you get lucky. You get to mark yourself down as 'not vulnerable, package not installed'.
Applications ship with every feature enabled. Disable them all and re-enable the ones that you are using. Delete sample applications and configs. Please. Remove all unnecessary bits from configuration files. If you cannot walk down through the application installation directory and know what each file & directory does, you've got to start reading & calling your vendor tech support. Tomcat does NOT need sample bindings, or whatever it comes pre-configured with. An Apache config can be a couple thousand bytes, instead of 40k. There is no reason to load 30 modules when your Apache instance is serving up plain old HTML. Your goal is 'not vulnerable, module not loaded'.
This also requires separation of application data from application code (or binaries, or executables). Any directory that has both executable code and data cannot be secured by the least bit principle.
Application vendors, including open-source projects, that ship fully configured applications are not doing system administrators and security people a favor. They are forcing us to walk through and entire application and figure out if all three deploy directories are really needed.
Application developers that write applications that mix executables and data should have their 401K's converted to Bear Stearns stock.
Firewalls and Load Balancers are obviously candidates for least bit. For firewalls, the least bit implies that every firewall rule can be tracked back to required application functionality. That also implies that the application managers or system managers know exactly which sever talks to whom, in what direction and on what port(s). Time to call the vendor. If they cannot tell you exactly what ports and protocols are used by each component of their application, then you need to admit to yourself that you bought the wrong product from the wrong vendor. And if they wrote an application that uses randomly generated ephemeral ports that can't be firewalled, you know you bought the wrong product.
For load balancers, the least bit implies not only that old, dead load balancer configs are removed, but also that the load balancer is configured to only forward URL's that are required by the application. If the application has an index.html in the application root and a half dozen jar/ear/war files, the load balancer should only forward index.html and /application/* for each jar/ear/war. At least then you know that if someone screws up and deploys a new, unsecured application, or forgets to de-provision an old application, the load balancer will toss the request rather than forward it on. In this case, the least bit principle results in an substantially longer and more complex configuration.
Network Devices. For switches and routers, this applies to the device firmware or operating system and the configuration. The least bit principle requires us to load the minimum operating system or feature set that is required for required functionality or application support. That means that you load base IOS images, not enterprise images, unless you have a specific requirement for enterprise features.
As security devices, the configuration should permit minimum required traffic and should block protocols and services that are not required for the functionality of the device attached to the switch or router. This means enabling more features on the switch or router (DHCP snooping, spanning tree root guard, etc.) In other words, the network devices only pass required traffic, blocking all other traffic.
This also applies to standard hardening of network devices, such as disabling unnecessary services, as is presumably already being done by network administrators.
Application Deprovisioning is the tail end of least bit principle. The final task when taking an application out of service is to remove its bits from servers, file systems, load balancers, databases and firewalls. As long as those bits are still in your datacenter, all the security baggage that application carried with it are still around your neck.
If this is System Management Principle #6, I suppose I'll have to dream up #1 through #5. When I think of them, I'll blog about them.
