How to Reduce Risk Through Configuration Hardening
Keeping your organization safe from cyber threats is harder today than ever. Attackers are becoming more sophisticated. They are exploiting new vulnerabilities and finding ones that have been undiscovered for years. On top of that there are the phishing and brute force attacks. Educating your staff helps mitigate the phishing threat. Adding the appropriate hardware helps reduce the brute force attacks but expands your attack surface. Configuration Hardening can help protect your attack surface.
Devices today are delivered with the capability to do many things. The challenge for configuration hardening is not everyone knows or uses all the capabilities. Think of your configuration as windows in your house. When your house was built, it had windows everywhere. Configuration hardening is going from room to room and determining how many windows you have in each room and what will be done to secure them. Should they be closed off permanently? Should they be locked but a key will open them? Should protections be put around the window and then leave the window open? Not knowing all your windows means you could have open attack vectors and not even know it.
Configuration Hardening is the selective process of reducing your attack surface. To successfully harden your configuration, you need to ensure that you know what your devices should do for your organization, that your devices can only perform the job they are needed for, and that your devices are regularly updated to stay ahead of new vulnerabilities. Finally, you want to validate the hardening on a regular basis.
Configuration Hardening has many benefits. It improves your security processes (e.g., password controls). It helps reduce your attack surface (e.g., remove unnecessary services). It helps you adhere to compliance requirements (e.g., recurring scanning and audits). It helps reduce overall risk. Finally, it can help with contract compliance.
I like to start with good documentation. In today’s world, that does not usually mean spending days or weeks writing things no one will ever read. It means making sure your organization has documented policies and standards that cover configuration hardening. These are things like effective password and encryption policies to name a few. A network diagram and architecture will help define part of the scope but having a complete CMDB is the best way to know your exposure. Your networks tools should be able to generate this for you.
Configuration Hardening is not a onetime exercise. You must manage change for each device by having a standard configuration for each device type. You must address changes to the actual devices and to the standard. This means you have to know all your devices and what can and should be done to them.
Beware of over hardening your configuration. That is not a good thing either. Locking down too many things could impact your customers and employees as much as a successful attack. This means that after you understand your hardware and how it is all connected, you need to understand the software, business, and operations that run on it. If you over harden things, it could make it difficult for your customers to interact or take additional hours for IT to maintain or update the devices.
Finally, you need to do regular assessments of your devices. What do you need to check? How often? Who will do it? What will be done with the results? Just checking for vulnerabilities will not keep you safe in the long run. Analyzing the results and acting on them by patching, updating, and refreshing your standard images is the goal. The assessments will also help you identify added, changed, or removed devices.
Knowing your environment and having a change management process will help, but you still need to identify and prioritize the work to be done. You can identify the work by leverage your scanning services or baselines. Some examples of this are CIS-CAT, Nessus (or other vulnerability scanners), Compliance Policy Scans, and the Microsoft Security Scorecard. You can also review your current vulnerability scans. Reviewing them can potentially direct you to a process change that will harden your configuration. These sources will also help define criticality and if something is being exploited or not.
Once you have standard images, you need to determine how the hardening will be rolled out. The preferred method is through Global Policies. Using global policies allows you to change in one spot and easily push it out to the correct devices. Sometimes the GPO won’t work, and a local setting will have to be made. This can typically also be done with a script and your software distribution tool. It is more complicated and manual. It is also potentially more error prone as individual machines could have slightly different configurations. This could cause the manual script to fail and require human intervention to finish deploying the package.
Account management is also important to configuration hardening. While entire papers can and have been written on Privileged Account Management, the whole topic is outside the scope of this paper. Suffice to say that you should run all software as a non-privileged user (one without administrative rights) to diminish the effects of a successful attack. You should also apply the Principle of Least Privilege to all systems and services and make sure that unneeded accounts are removed. Review default accounts and watch for new accounts to be created, especially ones created outside of the standard process.
Encryption should also be looked at for devices and communications. There should be up to date encryption for data at rest and data in transit.
A few years ago, Microsoft released exploit guard policies that close almost all the major vectors without impacting the user experience. More information can be found here: Windows Defender Exploit Guard policy - Configuration Manager | Microsoft Docs
More recently the Conti Playbook was released. The cookbook detailed how the organization trains its people to attack devices. NGS wrote a blog “PROTECTING AGAINST THE CONTI GROUP’S TTP’S”. It will be found on the NGS Blog page (https://www.newgenesis.solutions/blog) in May.
Once you have a good idea of your environment, you need to prioritize the work. For example, there might be unneeded services running on workstations or servers. Keeping all the software current, having passwords reset from the defaults, and strong passwords rules with MFA should be implemented. Having an active firewalls and up-to-date antivirus solutions are all more important than removing unneeded services. Removing the unneeded services should happen, but the priority of the work needs to be understood too.
There is not a single formula for everyone on prioritizing the work. There are some very good general guidelines to help pick the top priorities. One guideline is if your device is external facing and has vulnerabilities that are being actively exploited, those should be a top priority. Another guideline is if the device is used in PROD it probably needs more attention than a DEV or QA machine. This isn’t always the case and the guidelines for each business need to be determined based on business needs.
Once you have determined a roadmap of changes for each device type, review your current build images and organization policies. Check Active Directory for your group policies and Remote Server Administration Tool (RSAT). What needs to be updated?
If you do not have a build image for each device type, you should consider creating one. Use your testing systems and determine the requirements. What system functionality and features are needed? What does that mean for the hardware and software configuration?
Once you have built a system image that represents the current standard for a device and a roadmap for updating it, deploy it and test each one. Join it to the company domain. Make sure that it is fully patched, and all the proper security tools are installed and are being updated regularly.
Once your documentation is together, create a plan. Configuration Hardening is considerable work over multiple devices. Divide and conquer the problem. If different groups work on different devices, split the work between them to get the more done at once. For example, one group might be hardening End User Workstations while another is working on Network devices and a third is working on Servers. Knowing the entire environment and what is running on each device will enable you prioritize and reduce your risk faster.
Before any changes are made, a change process needs to be followed. Full testing across multiple platforms (DEV, Test, and QA) needs to be done. There should be a change request process and documented approval for the change. A full backout / recovery plan should be included in case any issues occur. Finally, all changes should be communicated to impacted parties.
For the testing, use small groups of changes in each environment (DEV, Test, and QA). This allows you to roll back and identify the specific conflicting policy or change if there are issues. Making too many changes at once makes it significantly harder to identify the root cause. Allow time for the changes to settle in and be used. If you test thoroughly, you will have a higher confidence that the final deployment being correct.
Include the business and IT Engineering teams to validate those changes will not have a negative impact. If you have one, leverage a test organizational unit. Begin your test against non-critical IT systems, then move on to business operations. Once the testing is complete, push the changes to the full organization. You can then move on to the next set of configuration hardening items.
As you work through your configuration hardening process, you should do regular vulnerability scans of all devices. The results need to be analyzed, and all new vulnerabilities filtered out. Filtering out new vulnerabilities gives them time to work through the normal patch process. Anything left after filtering out the new items are things that have failed the patch process, or the patch process failed to include them. These are two different issues which should both return process changes to the patching process. Additionally, the results should be reviewed to determine is new hardening measures are needed.
Configuration Hardening is not a one-time event. It is part of a security mindset. Monitoring your entire environment, watching for changes, keeping everything updated (as appropriate), adding in compensating controls for items that can’t be changed, and being vigilant about cyber threats are all needed. Configuration Hardening is a journey, not a destination. The road will constantly change, but the steps on the journey are the same and carry you safely onward.