Using NAC to manage the response to MS12-020

Ok, so this isn’t exactly a timely post.

When MS12-020 came out, it was the biggest patching frenzy I’ve seen in a while.   MS12-020 was a vulnerability in the Remote Desktop Protocol.   While not on by default, this protocol is often enabled on servers and by power users for remote manageability.   This vulnerability in a protocol frequently exposed on the network resulted in a “patch now” attitude.  Our clients were emailing demanding to know our percentage patch compliance.  People were watching on pins and needles to see if a remote code execution exploit became publicly available before patching was complete.

When a denial of service capable exploit for this vulnerability became available, we pushed up our patching timeline figuring the exploitation code couldn’t be far behind.   Systems not running RDP of course are not susceptible so I wanted to target my attention on systems that had RDP and were missing the patch.   Forescout CounterAct made this easy to do.   I set up a rule looking for systems missing MS12-020 and with 3389/TCP open.

From there Forescout allows many possible remediation and enforcement measures.

  •  Send the user an email with instructions on how to patch (Hey Forescout, I’d love to be able to digitally sign those emails so I don’t undermine my antiphishing efforts)
  • Sent HTTP notifications.   (I’ve purchased trusted SSL certificates so users could verify the source)
  • Self-Remediation – HTTP notification with link to patch, forcing user to patch
  • Initiate installing the patch through Microsoft Update/SCCM.

If the situation became dire, I could even use TCPresets or ACLs on the switch port to prevent RDP inbound on systems that haven been patched.

NAC is about so much more than controlling who is admitted to the network.   It is a critical part of endpoint security.