Security guru Joel Snyder from Opus One recently starred as the guest of a live Network World chat where he discussed the state of network access control. Snyder says that those who are anti-NAC simply don't understand the technology. He answered a slew of technical questions from attendees including why ACLs are better than VLANs, the dirty dark corner of NAC (management) and why some anti-NAC experts have got it all wrong.
Security guru Joel Snyder from Opus One recently starred as the guest of a live Network World chat where he discussed the state of network access control. Snyder says that Microsoft is emerging as one of the clear winners of NAC, but that Microsoft's technology is a foundation from which to build, not an end-all. He also says that those who are anti-NAC simply don't understand the technology. He answered a slew of technical questions from attendees including why ACLs are better than VLANs, the dirty dark corner of NAC (management) and the how and why of 802.1X. What follows is a full transcript.
Moderator-Keith: Please welcome security guru Joel Snyder, a senior partner with consulting firm Opus One from Tucson, Ariz., and member of the Network World Lab Alliance. Today's chat will focus on the facts and fictions about NAC, answering questions about what NAC products can and cannot do, including integration with wireless, technology shortcomings, plug-ins and more.
Joel_Snyder: Keith, it's great to be here!
Moderator-Julie: While waiting for Joel to type up answers to the first questions rolling in, here's a pre-submitted question: You just got back from Interop Labs with a lot of NAC testing. What are the most interesting things you learned?
Joel_Snyder: Thanks for asking! I'll put in a pitch for the Interop Labs NAC resource Web site (http://www.opus1.com/nac/). That has a bunch of our white papers (about 13 of them), all of our device configurations, classes on NAC, and basically about 90 MB of stuff that we've gathered and learned about NAC. The really interesting thing we noticed is that things are finally beginning to converge. We ran a nice little graphic (click on the "Click to see" diagram) in NWW last week talking about the family trees, and the key is that people seem to be willing to let Microsoft take a leading role in NAC. So we really focused on that: what comes built-in with XP SP3 and Vista? And then how do you extend things if you don't like what's built-in? We definitely had other policy decision points besides MS NPS---Cisco, Avenda Systems, Juniper, and Radiator, plus FreeRADIUS sort-of. Even on the client side, there are interesting things. For example, you can add more system health agents/verifiers, or you can go for other supplicants, or you can do non-Windows or pre-XPSP3 operating systems, or you can worry about other devices, like cameras and VoIP phones and printers. What we ended up with was about a dozen demonstrations, all showing what you need for a complete NAC solution. And it really focused on "let's start with Microsoft and work out from there." Much more satisfying than trying to have three silos like we've done in the past that don't work together. [Editor's note: Also check out Network World's NAC Buyer's Guide which compares dozens of NAC products.]
Brian: I've been asked to investigate .1x for port-based authentication. I have reservations recommending this for production use because of the mixed clients on our 1,000-node LAN (Macs running 10.4 and 10.5, PCs with Windows 95 to Vista). I think support would turn into a nightmare, plus I don't know of anyone using .1x. What are your thoughts?
Joel_Snyder: I hear you. 802.1X is outstanding technology, but you do have to have client support. Macs 10.4/10.5 are no problem - it's all built-in. For Windows, though, you're going to be restricted to Win 2000 SP3 and later. Of course, the Juniper guys are going to say you should go with Odyssey, which has a unified experience and supports earlier Windows versions and is great stuff and I can vote for that as well. Support nightmare? Hard to say. I'm of the belief that once you work through the initial problems, you end up having lower support calls. It's going to depend on what your environment is. If you're talking an education market, that's one thing. If you're talking an enterprise, I think it's manageable.
By the way, it's 802.1X, not 802.1x. Common mistake but if you use the upper-case version you'll have the l33t privilege of correcting some of your vendors, too.
fyatim: We have seen some consolidation in the NAC space. Can you provide an update on the NAC market and where it's heading?
Joel_Snyder: Towards Microsoft, for sure. The key is that the desktop is EVERYTHING and Microsoft is making the right noises about standards and openness and making things work in the big picture. So we have already seen Microsoft and the Trusted Computing Group (TCG) get together, and I think it's only a matter of time before we also see the other vendors like Cisco at least have a good accommodation of the Microsoft Network Access Protection (NAP) framework.
RalphSam2: I work for a large company. We have about 30K employees in 500 sites across North America. Management wants to see centralized NAC. All product evaluations are going badly. What is good for large site (more than 1,000 people) is not good for small sites (less than 10). What should we do?
Joel_Snyder: Well, boy, that's a softball. Of course, you should hire Opus One to help :-) But really, I think that you need to step back and figure out what it is that you care about MOST in your NAC deployment. Are you doing this for access control? For endpoint security? You have to narrow down what it is you want and then you can put together a solution that will work based on your requirements. I agree that there is no single universal answer, but I think that if designed correctly, you can do it. What we saw at Interop was the ability to move from VLANs (which definitely won't work at small sites) up to Access Control Lists (ACLs), which work and scale beautifully. If you haven't gone down that path, I'd suggest thinking in those terms. A lot of little guys are fixated on VLANs, which just don't scale.
shelly: Can you say more about why you think ACLs are better/more scalable than VLANs for network access control? It seems to me that ACLs can get very large if your network isn't easily summarizable. How do you choose between them?
Joel_Snyder: Good question and thanks! The deal with VLANs that I don't like is that we have already burned them in most networks. We're using them for other things, and making changes to the VLAN infrastructure is hard unless you have a green-field network, which no one does. However, with ACLs, you can push onto the EXISTING VLAN structure and not have to screw with it. This also solves the hand-waving problem of getting people to jump around VLANs as they go into and out of quarantine, which (as a Mac user) I really feel for. Very true that the ACLs can get ugly, but I am thinking that you aren't going for total control at the port level, but broad swaths of control. If you want LOTS of ACLs, then you need to go with specialized hardware: Consentry, Nevis, and I think that HP is talking that talk as well. I'm really bullish on ACLs now that Interop's Labs helped prove that they work. We're talking about anterior cruciate ligaments here, right?
Tom2342: Since the NAP client from Microsoft alone doesn't offer anywhere near the amount of endpoint data that some other vendors' NAC clients offer, why would you want to bother with it at all?
Joel_Snyder: Dude. The NAP client is just a base. You don't just do everything that Microsoft says, right? They provide a great base and you build on top of that to meet your needs. If you're a small site, you stick with them. but if you have Symantec, then you layer their SEP11 on top of that using the NAP SHA/SHV. If you have McAfee, same deal. Sophos, same deal. We tested Avenda and Blue Ridge as well in the labs, all sitting on top of NAP. The reason you START with Microsoft is that they know more about their own O/S than anyone else, so that is going to maximize the ability to interoperate. And then you take your preferred end-point security partner and put it on top using the SHA/SHV model. It is totally clean and totally extensible.
Moderator-Julie Pre-submitted question: TCG/TNC just announced IF-MAP What's that all about and what do you think of it? [Editor's note: TCG's NAC scheme is called Trusted Network Connect (TNC)].
Joel_Snyder: IF-MAP is very cool. We were lucky because TCG gave us advance access under NDA and we were able to get a white paper out on it at the same instant that it was announced. Talk about a scoop! Anyway, IF-MAP is all about having a structured way to store, correlate, and retrieve identity, access control, and security posture information about users and devices on a network. The cool thing about IF-MAP is that it's not just for NAC, although that's a first step. It's a way to finally bring together a whole world of policy and status information that just has been totally proprietary or even un-doable in the past.
I am totally stoked about IF-MAP because I think that this has been one of the main things missing from standards-based NAC and it closes a huge hole. I hope that we get great adoption. The TNC guys seem to have about a half-dozen vendors all already including IF-MAP in their products that they were demoing in their booth at Interop. Aruba, ArcSight, Juniper, Lumeta, nSolutions, Infoblox were all doing the demos.
RandyJ: I am looking to implement NAC next year on our campus. We are a wireless campus with some wired. I have talked to a lot of different vendors. What are the top two companies you would recommend, and why?
Joel_Snyder: Well, it depends, which one is buying you lunch? Honestly, though, I can't answer that very easily without knowing exactly what you're trying to accomplish. The obvious answer is Bradford, because they understand and do education better than anyone else (in my testing, anyway). They are built around education issues, so that's going to be well suited. From there, it's hard to say. I'd look to see what other partners you have good relationships with and see if they can meet your needs. In other words, if you're an Enterasys shop, go talk to them. Foundry, etc.
Leo: Can you comment on the relationship between Microsoft and Cisco on NAC now and project it in the future? Truly cooperative and division of labor? Or collision ahead?
Joel_Snyder: Hard to say. There are a lot of personalities involved. I'd say that right now we've got two titans who are hard-pressed to cooperate trying to figure out a modus vivendi. Even if there is a lot of joy together, it is inevitable that Microsoft and Cisco will have different interests in the long run. I don't see a big collision, because Microsoft's primary interest is in the desktop and Cisco has no intention of competing there. Things like NPS might go by the wayside as Cisco readies new versions of their NAC management solution and completely re-architects ACS and the CCA stuff. What I personally see is that Cisco owns 74% of the switch market and Microsoft owns 95% (or more) of the desktop market and that's not going to change too much in the long run. So I would look to Cisco for leadership in the areas that they are strong: switching, wiring closets, etc., and Microsoft for leadership in the areas that they are absolutely top in: desktop. Having either cross into the other's territory seems like danger.
WillBean11: The title of the chat is 'fact and fiction,' so what are some of the 'fictions' surrounding NAC that we should be aware of?
Joel_Snyder: Oh, good question. What are the top myths about NAC? How about that it's all about end-point security? We have some luminaries on our own staff who seem confused about that. NAC is about ACCESS CONTROL and NETWORKs, and USER FOCUS. That's the biggest confusion. Another one: that a NAC product solves your needs. I haven't seen a network larger than 100 devices where a single vendor solution answered all problems. Let me see if I can think up more as we go along...
Moderator-Julie: I think you are referring to Rich Stiennon in his Stiennon on Security blog. He called it: "Don't even bother investing in Network Admission Control" where he did a big NAC attack. Got any response?
Joel_Snyder: I think that Rich is a pretty bright guy, but a lot of his thinking about NAC is colored by a bit of tunnel-vision about what NAC is good for. He's really focusing on the end-point security stuff, and his comments in that area are pretty solid. But he's very lost when it comes to the big picture, because he's not thinking of NAC except through this very narrow view. If you really step back and understand what NAC is all about, then you see that Rich is focusing on about 1/4 of the solution. I don't think that he's intentionally misleading anyone; he just has a definition of NAC which is really restrictive and not at all in concert with what the rest of the NAC world believes in.
Ricky: What are your suggestions for handling non-Windows machines, or "non-OS" devices altogether - e.g. IP phones, cameras, medical devices, etc.?
Joel_Snyder: MAC auth bypass is the strongest approach for non-OS devices. You use that with a nice strong access control (i.e., phones can only act like phones because there's an ACL and a firewall keeping them in) and maybe back it up with a device profiler like a Great Bay box. For non-Windows, harder question. Big issue here is that you have to say what you think is important about your NAC deployment. Are you all about end-point security? If so, what does that mean for a Mac? Or if it's all about access control, then focus on 802.1X for those puppies. I wouldn't do Mac Auth Bypass for OSes that can do 802.1X or which have browsers. I'd do 802.1X or dump them in a captive portal if you want to abuse them a lot.
Moderator-Keith: Abuse the "end users," not the devices, right? :-)
Joel_Snyder: Right. Make 'em hit a captive portal every time they sit down. That's abuse, in my book.
Mash: How do you make sure, that MAC-based auth for IP-phones and such, doesn't become your hacker's favorite security-hole in NAC-networks? Just spoof the MAC with the MAC of a Cisco or Nortel IP-phone, and you're in, right?
Joel_Snyder: Well, you better not be "in." Right? You have to be controlled when you're in, so if you are saying you're a phone, then you better be ACLed or VLANed or whatever so that you can only ACT like a phone. If you just dump the phone on the network with full access privileges then you're not getting the point of NAC, the ACCESS CONTROL part. Sorry for the caps. Anyway, yes, then the hacker can still wander around your VOIP network with whatever ports and protocols you've allowed her, but you deal with that by using IF-MAP (in the future) or something like a Great Bay box (today) and let behavior-based information modify your policy decision.
RonM20747: We're looking at implementing NAC within the next year. We've got users that come in via a VPN and use RDP to get to their desktops. What is the recommended way to handle that with NAC?
Joel_Snyder: It depends on the firewall. If you are firewalling down so that they ONLY have RDP then there's not a lot of issue involved with end-point health. Sure, someone could be screen scraping on the RDP on the client and you might not know about it, but that's a pretty unusual situation. I would say that if you have already gone Citrix-y or RDP and the desktop is really what matters, then just do a normal wired NAC on the "end" desktop (the one that they're RDPing to) and don't worry so much about the end user on the VPN. You're already doing authentication and firewall on them. What harm can they "really" do that's worth the effort of NAC? Alternatively: go with SSL VPN and use one of the end-point host checkers that are in all the SSL VPN products. That gives you user-focused access controls and a health check, which is the essence of NAC By the way, I wrote a story on that saying that SSL VPN is the same as NAC.
Mash: TNC seems to have been going in the right direction for quite a while. And they are way ahead of the IETF taskforce. Microsoft also seems to be very open to "the TNC way." But Cisco keeps saying their mantra, that "we work with NAC, where it belongs, in IETF", which seems to be just an excuse for selling proprietary for now. What's happening in the IETF taskforce? When can we expect to see some actual standards from them? Will they be adopted by the industry? And will it turn out to be TNC with an IETF standard name?
Joel_Snyder: I have to say that I'm very depressed about the whole IETF thing. I had a long argument about this with Jim Martin, an old IETF stalwart. The problem is that the IETF is focusing on what has already been done by TNC and is not breaking new ground in areas that TNC has not covered. So what we're ending up with is a re-thinking of the same protocols by essentially the same guys which seems to me to be a huge waste of time. I don't know about Cisco's thinking here, but we're ending up with the same darn protocols in IETF and TNC. But what we need is the IETF guys to do a big-picture thing, like they did with IPSEC in RFC2401. That would be cool. But I am not holding out hope. I'm just depressed about it. Sigh.
shelly: Are there any good network management tools that you recommend for monitoring and troubleshooting 802.1X-based NAC deployments?
Joel_Snyder: Talk about a dark and dusty corner of NAC. You have found one of the ugliest ones. Russ Rice was hitting me on that at NAC Day [at Interop], talking about troubleshooting as the last frontier. Short answer: no good answer. Long answer. Look at tools like Splunk to get all your logs together and really searchable. I don't think that SIMs are the answer here because they're not about debugging, so you want some huge log aggregator that can do structured searches.
Moderator-Julie Pre-submitted question: Hi. We've looked at several NAC products, One in particular, Identity Driven Manager by HP, for the most part suites our needs. One problem however we come across is that enabling RADIUS authentication on our edge switches inhibits clients to check in with PXE servers. We use PXE on all our machines for on-the-fly rebuilds. While I realize this is a flaw within RADIUS authentication on a switch I really want to know what other products could help us address this problem? Thanks, Mark.
Joel_Snyder: PXE is one of the dark corners of NAC, so I understand where you're coming from. The situation with PXE is that you have a device which wants to get on the network, but it has nothing but a MAC address. Also, it has a pretty tight DHCP timer and if you don't get it on the network fast, then you've got a problem and it'll fail over. There are two approaches you can take here. First is that you can use Guest VLAN and second is that you can use MAC Authentication Bypass.
I don't know as one or the other is "better" -- it sounds like you may want to see which one your switches are compatible with. However, either can be used to resolve the PXE question. In our lab, we use MAC Auth Bypass because we have to know the MAC address ANYWAY to get it into the PXE server, so we just drop that into the RADIUS database and point those users over to a special PXE VLAN. You don't have to be that specialized if you don't want. You could just stick them in the same VLAN as other MAB devices (printers, for example). It would depend on how strict you are and what you're doing for MAB in other areas.
WillBean11: This may be unrelated to NAC, but I was wondering what Joel's thoughts were on IPv6 and the latest "we're doomed" chants going around. Is the sky falling on IPv4 or not?
Joel_Snyder: The sky is falling, indeed. I'm on some mailing lists out of ARIN where there's a lot of argument on that, but no one is disputing that IPv4 is running out of space. The question is where and what we're going to do about it when it happens. I predict rioting in the streets and widespread violence. That, plus a lot of IP address theft. Obviously, we're going to be able to put this off a long time, but honestly we are running out of addressable Internet space with all the devices going up nowadays, and NAT is not going to solve it forever. So you can either figure out how you're going to solve it a couple of years ahead of everyone else, or you can wait until your ISP suddenly says "No, no more addresses available," and then panic. I'm in favor of the panic approach, but there are those who want to plan ahead and be reasonable and well thought out.
WillBean11: So you don't buy the argument that we have plenty of addresses and it's just the ISPs that are hoarding them? (that's one theory I've heard)
Joel_Snyder: I don't buy it. I was helping a client with a crisis last weekend that could have been solved by another /29 of space (Nothing in the big picture) and the ISP just said, "No deal. You can't have it." They got a new ISP with more space, but they're running out too. Yes, there is some slop and wastage and unused addresses (look at Interop's 45/8!) but there is an end. 32-bits is not enough for a world with 6+ billion people and 12+ billion cell phones and Wiis and whatever.
Moderator-Julie Pre-submitted question: Hello Joel, it Eric from La Reunion. Have you tested the HP NAC/IDM solution? Best regards, Eric
Joel_Snyder: I have not had an opportunity to test the IDM stuff. I have had a couple of briefings on it, and certainly the PowerPoint is impressive. The whole idea of Identity Driven Manager (IDM) is that you can add policies to your NAP NPS server. That, to me, is totally kick-ass. NPS is a fine little framework, but as soon as you try and do anything exciting with it in terms of access controls, then you run into a brick wall. NPS is more focused on the remediation/end-point compliance lifecycle.
So that's why IDM is slick - it (at least in the PowerPoint) has got a lot of policy-based power that helps to round out NPS. IDM adds ACLs, QoS, and time/location stuff. Of course, the only issue with IDM is that it's layered on top of ProCurve Management and is ProCurve specific - so if you're not an HP ProCurve shop, it won't help much. But I'll put in a big-fat caveat, which is that I haven't tested it and so take everything I say here with a grain of salt.
SC: We are looking at SSL-VPN for remote access 1st and down the road NAC for the inside network. Should we go single vendor or wait to see what IF-MAP brings in post-admission control?
Joel_Snyder: I'd solve the pain point first with a good solution (SSL VPN) and then re-surface in 6 months to see what's happening with IF-MAP. Too early to put eggs in IF-MAP basket this month. I have hopes, but hopes are not products.
NAC%20Dog: How soon do you think the trusted platform modules embedded in laptops and desktops will become a significant part of NAC deployments?
Joel_Snyder: Could be a long time. If Microsoft includes it in the Windows Security Center SHA, then we're in better shape. But we have a LOT of TPM chips that aren't being used in a LOT of desktops, laptops, and servers. I think that a lot of folks just don't get TPM, which is OK, but there also seem to be a lot of product managers in vendors who ALSO don't get it. Try putting pressure. Make 'em figure it out.
Mash: Reply to the MAC auth answer: Fine answer, thanks! I didn't see it in the big picture with IF-MAP, so that's fine!
Joel_Snyder: Even with phones, I think if you've got a solid firewall between your VoIP network and the rest of the world, you're probably going to be safe even without.
Moderator-Julie Pre-submitted question: Do you have to disable NAC on a switch port with a non 802.1x device attached i.e printer? If the answer is yes what will happen if someone removes the printer and then plugs a PC in?
Joel_Snyder: Absolutely not. You have to have a way to handle corner cases, like printers. This calls for a bunch of switch configuration that is specifically designed to make this work. What most people have done is use MAC authentication bypass (available in almost all modern switches) which does a MAC auth of the device if it doesn't talk 802.1X. By the way, a lot of printers nowadays, phones, and even video cameras will talk 802.1X. But if it doesn't, then you do a MAC auth and put the guy on the printer VLAN or apply the printer ACL.
If someone then sneaks a PC on that port, you have two options. If the sneaky guy hasn't stolen the MAC address, then everything works fine - they don't get access, or they fall into the Guest VLAN and a captive portal. If the sneaky guy has stolen the MAC address, then you let them in as a printer. That presumably (if you haven't screwed up) limits what they can do because they can only act like a printer. And if you've got more concerns, then you can use something like a Great Bay Beacon (Cisco resells that; I don't know what they call it) to do device profiling and if the guy pretending to be a printer starts acting up, then you can knock them off and send an alert.
Moderator-Julie Pre-submitted question: We have a full Cisco switch/routed/firewalled/VoIP network and are warming to Cisco NAC as an infrastructure based NAC deployment: a) Will NAC work from behind a Cisco phone/unmanaged switch? b) If "a)" is possible what happens if some devices on an unmanaged switch are 802.1x and some are not? c) How does NAC work with wireless (i.e devices like phones/pc's moving from one WAP to another)?
Joel_Snyder: Whoa, dude. What is this, get-it-all-in-one-question week? Let me give you the fast answers, and you can write back in if you need more detail. (a) yes, but you may have restrictions on what ACL and VLAN you can do. See David Newman's 10Gig Switch test for a specific discussion of the restrictions. (b) It depends on what you want to do with them. If you want to drop them on a guest VLAN, no problem, although now you're crossing the streams and that sounds like a bad idea. (Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.) (c) 802.1X is 802.1X. That's the beauty of it all. GO between wired, 802.11, 802.16, whatever. You will have a re-auth in some wireless gear, which is perhaps bad. This is a good argument for an integrated wireless management system (in your case, probably the Airespace stuff, but Aruba and Aerohive would do the same).
Sam: Will NAC work from behind an unmanaged switch?
Joel_Snyder: Define "work." Obviously you don't have total control the way you do with a switch, but you can do lots of NAC things. I think in the last answer I mentioned David Newman's article on switches which talks about some of the limitations. I'll also point you to http://www.opus1.com/nac/teamwhitepapers/2008-09SwitchFeatures.pdf which is a white paper on switch features that are relevant to this question.
shelly: Do you have a favorite EAP type that you recommend for people trying to deploy 802.1X?
Joel_Snyder: You want me to say "EAP FAST" don't you? Honestly, though, it doesn't much matter. You want an EAP method that will let you send your posture information through. Frankly, the choice of EAP method is the last thing you do: you start with your client and Policy Decision Point and figure out what method they support in common. I suspect that EAP methods are fast becoming a non-knowledge-area with 802.1X nowadays and people will just use whatever works.
I believe that PEAP will dominate because of the NAP client, and if that works, then I don't see any reason to argue against it. The personal problem I have with PEAP is that it doesn't support non-Microsoft authentication systems (like our RADIUS server here at Opus One). But I consider my personal problem too small. In the world at large, there's Active Directory and not a lot else that we should be yanking people around for.
Mash" In Microsoft NAP, there's a "test-mode", where you can get the reports on devices that would have been denied access to network, if policies were enforced. Wouldn't that be a good way to start and that way see what you have to find workarounds/solutions for, before deploying full-scale? (Whether or not you end up with Microsoft NAP or some other vendors NAC?)
Joel_Snyder: Totally. Who could disagree with that? Only an idiot will turn on all NAC features on the same moment. You start with non-enforcement and maybe even non-authentication. Slide things in slowly and pragmatically and reasonably. ALL NAC vendors should have a Test-Mode, just like all IPSes should. Anyone that doesn't is defective in my book. And your strategy is totally the way to go. How many times can I put totally in an answer? Totally, Dude (or Dudette).
Moderator-Julie: Pre-submitted question: How secure is Microsoft's new networking "mesh" technology?
Joel_Snyder: I am not entirely sure I know what you're thinking of here, so I'm going to assume you're talking about wireless mesh, which is pretty interesting stuff from an access point of view - but a total nightmare from a security point of view. My general thinking is that if you use any kind of mesh wireless where 'foreign' access points may participate, you should be doing end-to-end encryption of any traffic that you care about, either with a VPN client or application layer encryption. But I'm not sure what this has to do with NAC.
Joel_Snyder: As long as we have a lull, I'll put in one more pitch for the Interop data at http://www.opus1.com/nac/. This is the best NAC resource we could put together for implementers and technical people, and there's no marketing fluff attached. The white papers are my favorite part … although not as funny as this chat. And no cheese references.
Moderator-Keith: That cheese reference wasn't very gouda...
Joel_Snyder: At least it was brie-f.
Moderator-Julie: Final pre-submitted question: If we were to use an end-point NAC system i.e Sophos, how easy would it be for a malware coder to write software to manipulate NAC code sent in the pre- and post-admission stages so to fool the NAC system into thinking that the PC is virus free when it isn't?
Joel_Snyder: Well, first of all, let's disabuse a notion that having a virus checker turned on and current says anything about having a virus. You can have both and that's normal behavior. Of course, the goal is reducing your RISK of having a virus by making sure that the A/V is up to date. But don't think that just because you can tell whether the user has A/V turned on and up-to-date that it says anything about whether or not they're infected.
But now let's talk about "how easy." Well, it depends on the units you're measuring "easy" in. Everything involving software is fake-able at one level or another. The best world would be using a TPM (Trusted Platform Module) to ensure that the NAC stuff is intact. If not, then I guess I'd say that it's 6 gallons of easy, maybe 8 gallons. However, you can't have absolute security. What we're trying to do here is go from NO end-point checking to SOME end-point checking. The real answer here is to add in behavioral technologies so that if someone does turn out to be a bad apple and you don't catch them with on-device software you can at least catch them by having your IDS or IPS interact with your NAC solution.
Mash: Microsoft is trying to sell their ConfigMgr with the argument, that auto-remediation is tightly integrated with Microsoft NAP. Are they just "hyping"?
Joel_Snyder: I think that lots of vendors are able to do remediation, as well as Microsoft. I wouldn't let the Microsoft guys say that they are the only ones who can do remediation. Lots of end-point security vendors can do that, and maybe even better than Microsoft. I'm actually not much of a desktop guy so I don't know how much better or worse, but I bet "at least as good as."
Moderator-Keith: With all of our questions answered, let me take this time to thank Joel again for joining us, and for the awesome questions asked and answered. Joel, u are da man.
Joel_Snyder: Keith, *YOU* are da man. And even with the ch33s3 l33+ speak!
Moderator-Keith: Please remember to mark your calendars for our upcoming chats:
Thursday, May 15, 2 p.m. to 3 p.m. ET, "Open source and its changing role in the enterprise", with Stormy Peters.
Wednesday, May 28, 2 p.m. to 3 p.m. ET, "Crimeware: Understanding new attacks and defenses," with authors Markus Jakobsson and Zulfikar Ramzan
Tuesday, June 10, 2 p.m. to 3 p.m. ET, "Enterprise technology trends IT departments can’t afford to ignore" with John Hagel and Eric Openshaw
See http://www.networkworld.com/chat/ for details.
Joel_Snyder: All right, thanks to everyone for listening and groaning at our puns... I hope you have a great week!
Also, check out the transcripts of other recent chats.