{"id":60128,"date":"2022-11-25T09:57:35","date_gmt":"2022-11-25T01:57:35","guid":{"rendered":"https:\/\/version-2.com\/?p=60128"},"modified":"2023-07-24T18:38:17","modified_gmt":"2023-07-24T10:38:17","slug":"hardening","status":"publish","type":"post","link":"https:\/\/version-2.com\/en\/2022\/11\/hardening\/","title":{"rendered":"Hardening"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n

\"\"<\/p>\n\n

Hardening is the process of bringing our OS, application, etc. to a more secure <\/em>state, by configuring the system aside from its default (or previous) settings by reducing the attack surface.<\/p>

This process can (and will) usually include removing software\/services from the OS, removing\/changing default password, patching, and so on.<\/p>

The process of hardening has for its aim to remove configuration vulnerabilities.<\/p>

For example, you can place a password policy on your OS, so that the user has to enter more complex password, than no or a simple password which would classify as a configuration-based vulnerability.<\/p>

The hardening process should be specific for the OS and the threats you\u2019re attempting to control. It would not be the same for a Linux-based server that\u2019s for example a public webserver and for a Windows desktop. This would be different because of the nature of the threats you\u2019re going up against, i.e., you\u2019d need to have different profiles for each of those.<\/p>

This implies that there\u2019s no general <\/em>way to harden systems, however, there are things that you will tend to do that will hold for all those cases. Like, as I already mentioned, removing unnecessary stuff, reducing your attack surface by controlling what could be attacked better, etc.<\/p>

Hardening is not a trivial task, as it requires in-depth understanding of a system you\u2019re hardening. To make an extreme example \u2013 you could set your firewall to block all inbound traffic by default and you would be quite safe, but then again, the reason for that safety would be due to the fact you\u2019ve rendered one of the (main) functionalities of that system unusable \u2013 Accessing the Internet. Thus, you really need to pay attention in order to strike that middle ground between usability and security in a sensible way. You don\u2019t want to have issues with using your daily driver OS, and you don\u2019t want to break it.<\/p>

Layers<\/em><\/p>

Its helpful to think of layers when hardening your systems. One such example can be the webserver I already mentioned. You would have the OS layer, thus you\u2019d need to harden the OS itself, then if your, for example, Apache runs an app server, you\u2019d need to harden that as well. Finally, if you have an application that\u2019s running there \u2013 the code for that application would need to be written securely.<\/p>

This is just an illustration, so that you have a general idea of what to think about when thinking about hardening, but I want to focus more on OSes (if necessary, I will create another OS dedicated article about hardening).<\/p>

Standards<\/em><\/p>

There are standards out there for mostly anything you\u2019d like to harden, and it\u2019s best to follow these. Similar to let\u2019s say secure coding best practices, or any other type of best practices.<\/p>

Also, there are scripts that can audit or remediate your system to a state you wanted, this not only saves you time, but it will also provide you with a good way to avoid any human-based errors, while hardening your system.<\/p>

The standards can be called baselines, benchmarks, policies, standards, etc. Just an fyi. They still describe the same thing\u2026 also, note that these benchmarks are made by a community of security professionals, which is what we want.<\/p>

One such hardening standard is the CIS Benchmarks<\/a>. As you can see on the link, they offer hardening for Mobile Devices, Network Devices, Server\/Desktop Software, Cloud, and more, aside from the OS benchmarks, and it\u2019s a good place to start. Once you\u2019ve found your target system you\u2019d like to harden, you can click on the link for it and download the associated .pdf file for that specific benchmark. (You will need to fill out a form, but after that, you\u2019ll be sent a link where you\u2019ll be able to access all the available .pdfs and download them, for free).<\/p>

Note that the standards needn\u2019t necessarily align with your needs, so even these standards are not a silver bullet that you can implement blindly. Read it, understand it, and assess what you will need before going forward with the implementation.<\/p>

Another one of these baselines is the NIST Configuration Baseline<\/a>, but it\u2019s a bit dated (offering only for Windows 7 and Red Hat \u2013 but if you have Red Hat in your environment, it might be useful to you). Regardless, it\u2019s a good resource to skim through so you can learn a bit more on the topic.<\/p>

One more standard\/baseline is the Securiity Technical Implementation Guides (STIGs)<\/a>, from the DoD Cyber Exchange Team. These are up to date, and cover the latest OSes (mostly) and their respective security standards for hardening them. Do note that these are geared more towards the DoD and their requirements, so there might be some things in there that won\u2019t be useful for your case. However, these are something I\u2019d recommend anyone who wants to harden their system(s) to look at and think of them as general hardening guidelines. To view these, you\u2019ll also need a STIG viewer<\/a>, as they are in an XCCDF<\/a> format.<\/p>

Although this might be a bit of a hassle, it\u2019s worth it because it will give you a very nicely laid out interface with recommended settings, references, information, and more \u2013 all related to the hardening of system(s).<\/p>

SCAP \u2013 Security Content Automation Protocol<\/em><\/p>

This is a NIST standard, and from their website<\/a>, it\u2019s about:<\/p>

The Security Content Automation Protocol (SCAP) is a synthesis of interoperable specifications derived from community ideas. Community participation is a great strength for SCAP, because the security automation community ensures the broadest possible range of use cases is reflected in SCAP functionality.<\/em><\/p>

And<\/p>

NIST’s security automation agenda is broader than the vulnerability management application of modern day SCAP. Many different security activities and disciplines can benefit from standardized expression and reporting. We envision further expansion in compliance, remediation, and network monitoring, and encourage your contribution relative to these and additional disciplines.<\/em><\/p>

The SCAP standard consists of the following components:<\/p>