In today’s IT security and threat landscape, system administrators are often bombarded with an unrecognizable and often incoherent amount of noise regarding what needs to be done in order to secure any given infrastructure from nefarious activities. Though everyone seems to have something to say regarding the issue of how to best secure your infrastructure, it always boils down to the same formulaic propaganda; educate the common user to be aware of how they will be attacked, apply all security patches for any software running within the network, and buy the latest and greatest security product.
We aren’t going to argue that these three pieces of advice are not valuable, and in fact they often mean the difference between complete system compromise and a simple blocked attack. Education of users to be better prepared to stop an attack before it is even attempted by not opening every file they receive or running every program they can find will go a long way to ensuring the safety of their computers. A proper patch management procedure in place promises to block any known software exploit from being leveraged against the managed system. However, social engineers are very clever people, attackers are not afraid to leverage zero-day vulnerabilities in order to obtain their goals, and any security system put in place to prevent unsolicited access can ultimately be bypassed. Even with the smartest users money can buy, a fully patched system, and the latest and greatest in firewall and antivirus technology, it is still possible for attackers to get in, and this will likely always be true.
Last year, we published a paper that sought to bypass the noise and bring a different perspective to the IT security discussion. This paper offered advice on configurations and mitigations that could be put in place in order to better lock down and secure any given infrastructure. This advice is not meant, in any way, to circumvent the education of users, a proper patch management system, or the use of an antivirus program. These configurations are merely a tool to be used by administrators for the purpose of reducing the number of vulnerabilities that can be leveraged against their network, increasing the difficulty of exploitation for those that can still be used, and reducing the effectiveness of any successful attack.
Last year’s paper focused on mitigations that were commonly recommended by Microsoft in their 2010 security bulletins. This year, we wanted to take a look back at some of those recommendations, analyze how they stood up to the 2011 recommended mitigations, and add any additional findings to our list. These mitigations, by themselves, are not meant to stop every attack against a targeted infrastructure. Their purpose is to greatly increase the amount of effort required by attackers in order to launch a successful attack, stopping the common “drive-by” style attacks, and making targeted attacks more difficult to carry out.
In Configuration We [STILL] Trust
It’s a very common practice to see mitigations given, if available, for any vulnerability advisory or patch bulletin. However, far too often, these mitigations are used as a form of reactive protection, only being applied in place of patching a system either while patches are tested and rolled out, or when patching the system breaks other functionality needed by the machine. In situations such as this, the value of these recommended mitigations is completely ignored because of the need to fix the current, gaping security hole.
Other common situations occur when a patch is rolled out into an environment and the recommended mitigations are never even looked at. Though the problem has been fixed by the patch, one security hole very often opens up interest in the area that was vulnerable, and it is all too common to see one vulnerability lead to several similar vulnerabilities because of this. By evaluating the recommended mitigations and applying them where possible, vulnerabilities that are waiting to be discovered can be proactively blocked and mitigated.