System Hardening Basics - Less is sometimes more
“If it ain’t the motor, take it off”. For fans of the “Fast and the Furious” movie franchise you already know Dominic Toretto was talking about cars not Cyber Security. However, the concept can (and should) be applied as part of your security strategy. As with most things, keeping it simple is usually a good idea. When preparing computer systems for deployment it is often best to configure them to run the minimum amount of software and services necessary to accomplish the task at hand. A simple example of this is the Print Spooler Service. How many web servers need to be able to print? I’ve never seen one, yet I have audited countless web servers with the service enabled. You may be thinking so what? what’s the big deal? Well, here are some benefits:
Performance. This should make your infrastructure team happy. Every unnecessary service that is removed contributes to releasing system resources (CPU, Memory, IO) and making systems faster. Remember this the next time your Server Admin complains about the overhead of a security service. If they haven’t done their diligence to turn off “unnecessary” services, they should not be targeting necessary services like AV. Remember however that Info Sec and Infrastructure are ultimately on the same team, listen to their concerns as they may have some validity and then work together to tune as appropriate.
Vulnerability Management. With fewer services running you have reduced the attack footprint. Similarly, you have reduced the effort associated with patching. Take the Java Runtime as an example. In March CVE-20222-21449 discovered a flaw in the way Java handles digital signatures that could allow an attacker to forge signatures and circumvent authentication mechanisms. If you have java running on your servers, but not using it, this could still introduce unnecessary risk. Not to pick on Java, the .Net Framework is susceptible to critical vulnerabilities as well. If you don’t need it turn it off, reduce your footprint and the amount of effort your team spends testing and deploying patches.
Compliance. Depending on your industry, you may be required to comply with certain Information Technology standards. PCI for example wants to see that systems are designed to carry out a single function i.e., one Web Server and one Database Server instead of a single co-tenanted server running both applications. Keep this in mind as you architect your systems, it’s a lot easier to accomplish upfront then after you are in production and your auditor identifies it as an issue.
Admittedly, we’ve only scratched the surface, there is a lot more that goes into hardening systems. Hopefully you are already considering the purpose of your computer systems and their requirements before creation, if not this a great time to start.
*Vendors typically publish recommendations for hardening their OS’s/Systems. It’s always a good idea to consult those as you are developing your deployment templates. It’s also a good idea to manage these settings centrally to ensure consistency. GPO’s and DOD STIGS are good resources when you are ready for those next steps.