Archive for the ‘NAC’ Category.

Using NAC to manage the response to MS12-020

April 4, 2012, 3:27 pm

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.

Tags: ,
Category: NAC  |  Comment

Some People Really Need to Look Into NAC

July 4, 2009, 6:59 pm

Over the weekend I was talking to someone who has a mandatory requirement at work to have their computer inspected by the helpdesk every 60 days. If the computer is not inspected the computer is not allowed onto the network.
I’ve heard of such requirements for remote users. Remote users who don’t connect to the company using a VPN are tough to check up on. Requiring a periodic check-in could be a good idea for those users. However, physically checking computers that are manageable devices on your internal company network seems like a waste of time to me. If this story is accurate, I’d like to introduce them to NAC.
I know what you’re saying. First they are using a form of NAC if they can keep unapproved people off the network, and force them to go to the helpdesk to reauthorize themselves every 90 days. Second, some people think of NAC like they think of PKI. It just hasn’t taken off yet and some people think it is one of the more useless “useful technologies.”
NAC is actually useful for quite a bit more than keeping people off the network. If you manually check computers every 60 days, a computer that has broken patching mechanisms or is infected will not be detected for an average of 30 days. NAC would be able to detect this as the computer is connected to the network and on an ongoing recheck schedule. Even if you don’t want to send the user to a remediation page you could alert the helpdesk. Better to be fixing known problems immediately than inconveniencing everyone else every 60 days.
If you do have a NAC project, I’d suggest checking out Forescout. I have been happy with our selection. When we looked at other vendors it wasn’t even close in my opinion. Don’t feel like you have to buy NAC from your network switch vendor or your desktop antivirus vendor.

Tags: ,
Category: NAC  |  Comment

NAC and Patching

July 15, 2008, 7:34 pm

When I was looking at different NAC solutions, I remember one vendor being aghast at my plans for NAC, “NAC isn’t patch management” he sputtered. While I agree that no one is looking to supplant their SMS/patchlink whatever with NAC, making sure every computer meets a baseline requirement is an important goal.
We continued looking at vendors and eventually went with Forescout’s Counteract. As I’ve been implementing it, one of the things that struck me was that Microsoft SMS 2003 is even worse that I thought. We used Forescout to run a check for June 2008 Microsoft patches. What I found was 5% of the systems didn’t have those patches because their SMS was hosed.
Using NAC to gather vulnerability information has a lot of advantages. Unlike vulnerability scans, in many cases I was not restricted by personal firewalls. The Forescout uses a connector so it can run scans on the local machine with admin credentials. A vulnerability scan runs once per week and not every system may be online. With Forescout I have a more accurate view of the patching in the enterprise because the scan can be set to run as the client comes online.
Forescout NAC has given me insight to the network that I didn’t have before. Unfortunately its putting in a 100 watt bulb after you’ve been using 40 watts. With the sudden brightness, you see the cobwebs and dirt that you hadn’t noticed before.
The next steps are to fix the SMS on the 5% systems that are broken. Plans are being drawn up to upgrade to SCCM which uses WSUS for updates. I’m hoping that version will be more robust.

Tags: ,
Category: NAC  |  Comment

Forescout Announces Buyout Program for Orphaned Lockdown Customers

March 31, 2008, 4:49 pm

Last week Forescout announced a program to credit Lockdown customers for their orphaned NAC equipment when they make a Forescout CounterACT purchase.
Lockdown is a NAC vendor that announced it was ceasing operations. Forescout is an up and comer in the NAC market. Personally, I think they are the best NAC choice, and when I get some time, I’ll have an entry about why I think that.
I think this is a great way for Forescout to get their name out there. At the same time though the death of Lockdown does make me even more wary about using a smaller player. Its a classic trade off. Going with the established name means they probably wont go out of business. At the same time, their feature set may not be as good and they wont have good support or response to enhancement requests. With Forescout, there is a risk they will go out of business or be bought by “XYZ Company you hate”. But they will tend to be more responsive and thus have better features.
Different companies have different opinions on the best approach to take. Even if you go with an established “name” company, they may drop your product line when they purchase a smaller named company that has a better product. Its a risk that needs to be considered.

Category: NAC  |  2 Comments