Experts debate NAC: usefulness vs. cost

Security experts Joel Snyder and Richard Stiennon debate the pros/cons of NAC, with Snyder arguing that NAC is extremely useful and Stiennon saying it isn't worth the expense

Is NAC worthwhile? In Network World's first chat face-off, security experts Joel Snyder and Richard Stiennon debate the pros and cons.

Network World recently hosted our first chat face-off with two security experts who hold opposing views on the value of network access control. On the pro-NAC side was Joel Snyder (pictured, top) and on the con side, Richard Stiennon. Joel is a senior partner with Opus One, a consulting firm in Tucson, AZ, and a member of Network World Lab Alliance. He has been working with networks and information security since 1981 and has penned several books. Stiennon is a security consultant, popular speaker and founder of Seccom Global, a managed security service provider focused on unified threat management. He writes the Stiennon on Security blog for Network World. What follows is a full, edited transcript of the event.

Moderator-Julie: We are ready to begin. Welcome to our guests.

Richard_Stiennon: Hello!

Joel_Snyder: Hiya everyone!

Moderator-Julie: Before we start with your opinions on the pros/cons of NAC, let's define the technology. Joel, what is your definition of NAC? (Richard, after Joel replies we will ask for your response to this question.)

Joel_Snyder: What's my definition of NAC? ... OK, give me a sec.

Richard_Stiennon: Time's up.

Joel_Snyder: NAC is User-Focused, Network Based, Access Control. NAC changes how we do access control. That's the "AC" in NAC. And it's NETWORK Access Control. That's the "N". With NAC, What You Are Allowed To Do = Who You Are + Your Endpoint Security Status + How You Behave. That "equals sign" is not a static either; it's f(), a continuously evaluated function. This is not discrete math; it's calculus. Thus, What You Are Allowed To Do (ACCESS CONTROL) is continuously evaluated based on things that change, largely How You Behave.

In simpler terms, AC = Auth [Authentication] + EPC [End Point Control] + NBAD [Network Behavior Anomaly Detection]. Anyone who does NAC has to decide which of these three components is important, and how important. Thus, you can have NAC solutions which are 100% EPC and 0% Auth and 0% NBAD. You can have some which are 100% Auth and 0% EPC and 0% NBAD. And you can even have some where AC = 0%, because all they're doing is getting a report.

If you look at Cisco's original product, and Microsoft's original product, they were all about EPC. There was 0% Auth, 0% NBAD, and even (in Microsoft's case) 0% AC. Everyone is allowed to pick whatever product solves whatever problem they have. Those guys were early adopters and solving an old problem: bad juju on corporate networks. They've moved on. And if they hadn't, that wouldn't be a problem either. We have multiple vendors not so everyone can compete for the same dollar, but so that different solutions to problems can exist. Products are not substitutable. Problems are not the same. All this is fine. NAC is a technology. Not a product. That's my definition. .

Moderator-Julie: Richard, What is your definition of NAC?

Richard_Stiennon: Sheesh. I knew NAC was complicated but I thought it would easier to define. Like: NAC is access control on steroids. It adds machine state, as in configuration, virus signatures, etc. to the access control equation. The concept was introduced by Cisco in 2003 as a solution to the problem created by MSBlaster: networks getting infected by laptops brought into work. Like other things on steroids NAC is prone to heart failure, internal bleeding, complications, and just plain ugly appearances.

Moderator-Julie: OK, second question: Joel, what do you see as the value of NAC? (Richard, after Joel replies we will ask for your response to this question.)

Joel_Snyder: Look, NAC is important for one key reason: it changes our focus. For years and years we've spent our time being focused on the perimeter. Then we started to look inside. But we have always been focused on IP addresses: poke hole in firewall for IP A to get to IP B on port C. The same is true with IPsec. Even though people have had the opportunity to do fine-grained VPN, no one does because the products make it a nightmare. Let's get some history in here.

Then SSL VPN came around and needed a hook, and the hook that caught was "per-user policy." All that blabbing about policy on firewalls was no good without tools, and suddenly the SSL VPN guys had it. We could put people into groups and focus on the USER for our security policy - which is as God intended it. Not the IP address, but the person. [Note: See also VPNs: Six burning questions]

NAC is taking this kind of USER-FOCUS and bringing it into the world of the network. It is a tool for doing USER-FOCUSED NETWORK-BASED ACCESS CONTROLS. That's what NAC is, and why its so exciting. And, of course, the "user" is actually the sum of "the user person" and "the device they're using," since to a network guy like me the user and the laptop/desktop are the same entity. NAC lets us take security where we couldn't do it before. That's why NAC is valuable. 

Moderator-Julie: Richard, what do you think is the value of NAC and what would you say in response to Joel's answer to this question?

Richard_Stiennon: Ewww, hold on while I clear my palate. I am a network guy too but I do not want to go places I have not gone before. I agree that NAC changes focus. It changes it away from security and networking and towards infrastructure and desktops. At a detriment to overall security.

Moderator-Julie: Joel, do you have a rebuttal to Richard's response?

Joel_Snyder: You'd have to explain the detriment part to me, because I don't get it. (He opens the door wide...)

Richard_Stiennon: OK, look at it this way. We are in an era of greater and greater threats. We have Chinese hackers in our networks, insiders stealing IDs and credit cards, bots and DDoS threats. And for some reason during all of this violent change vendors such as Cisco, Microsoft, etc. want us to stop everything and implement their particular brand of binding between machines and networks. NAC is not a security solution at all.

Joel_Snyder: Are you making a zero-sum game argument here? That if we spend time on NAC, then we're not spending time on Chinese hackers? Because I don't think that the statement that NAC is not security is really defensible, honestly.

Richard_Stiennon: You bet. Most of the CIOs I know, not only have no extra budget this year but are being asked to reduce their spend.

Joel_Snyder: Access Control is one of the fundamental things we do for security.

Richard_Stiennon: We better get into our definitions; I have NO PROBLEM with user access control. I have LOTS of problems with end point access control.

Joel_Snyder: You're implying that NAC is a net cost. I believe that it can be a net savings.

Richard_Stiennon: I believe NAC is a net cost *and* something that reduces value of the network to the enterprise.

Joel_Snyder: Well, I don't want to get into this "agree to disagree" nonsense, but ... no, it isn't, and no, it doesn't. :-)

Moderator-Julie: Richard, if NAC is not the answer, what is the answer to enforcing end-point security and other policies? (Joel, after Richard replies, we will ask for your response to this question.)

Richard_Stiennon: Oh, so we *are* talking about end point enforcement?

Joel_Snyder: Well, Julie is.

Richard_Stiennon: I thought Symantec, Microsoft, BigFix had addressed that. I am a network guy. I don't deal with end points except that I have to use one. That is for the help desk guys.

Joel_Snyder: By definition of the existence of MBlaster, Symantec, Microsoft, and BigFix had NOT fixed it.

Richard_Stiennon: So for end point enforcement I would suggest talking to patch management companies. MSBlaster was essentially a zero day [exploit] for most enterprises. If they had had NAC fully deployed they still would have gotten hit.

Joel_Snyder: Absolutely, patch management companies like BigFix, Lumension (the old Patchlink), they are a vital part of SOME NAC deployments. Those that require end-point security. Not all NAC deployments require end-point security. (See definition above...)

Richard_Stiennon: So to do NAC you need multiple vendors' products to work together?

Joel_Snyder: To do networking, you need multiple vendors' products to work together. Again, NAC isn't a product. It's a technology, like dynamic routing.

Richard_Stiennon: For networking, you get them to work together using a nice understandable protocol like TCP/IP. What is the NAC standard these vendors follow to make sure they work together?

Joel_Snyder: NAC standards are a separate issue, really completely orthogonal to whether or not NAC is useful. I agree we need better standards, we need better compliance to standards.

Richard_Stiennon: So you must have a case where interoperability is NOT needed, like an all Cisco solution?

Joel_Snyder: No. At the iLabs at Interop, we had a dozen vendors, all playing together. You're not getting, I think, that NAC is a point of view and a technology. It's not a product. I can put together - and have - a NAC solution that includes multivendor interoperability.

Richard_Stiennon: I agree that it is turning into a religion, which makes me an atheist.

Joel_Snyder: Every NAC solution has interoperability. 75% of enterprises have Cisco. So NAC has to work with that. And 99.99% of enterprises have Windows. So NAC has to work with that. But interoperability, again, is deflecting us from the main question, which is: is it useful or not?

Richard_Stiennon: So NAC is a way to enforce the duopoly of Cisco-Microsoft? Your question presupposes that NAC is WORTH it.

Joel_Snyder: Look, interoperability is a given. And it's been proven, without Cisco's help. Let's move on to the usefulness of the technology, and not whether TCG/TNC has their act together.

Richard_Stiennon: So, what is the useful purpose of NAC. It is not threat protection obviously.

Joel_Snyder: Nothing is obvious. NAC is as I defined it is User-focused. Network-based. Access-control. It's useful because we've never had that before.

Richard_Stiennon: SO why do we need end points!!!??? User access control has been around since day one.

Joel_Snyder: No, user access control hasn't. Yes, of course we had authentication. Look at how many people used 802.1X in the LAN. Not many. Why? Well, the clients sucked. That got fixed. People were afraid of it, because analyst firms told them to be. And, most importantly, we had no real tools to manage it.

Richard_Stiennon: I was configuring RADIUS 14 years ago. It is needed and works.

Joel_Snyder: RADIUS doesn't mean we know who's on the other end of a hole in the wall.

Richard_Stiennon: So NAC is the answer to problems with deploying access control?

Joel_Snyder: Authentication by itself is interesting, but not interesting enough to make the pain of 802.1X worth taking on. Everyone knows that a new technology has a pain and a benefit/pleasure. If the pain is greater than the benefit, then it won't be absorbed. It's that simple. NAC lets us bring together a bunch of disparate pieces (802.1X, user-focused policy, end-point security, IDS/NBAD) and integrate them. That's what was missing. That's what's available today. That's where we are going. That's why NAC is interesting. That's why people are excited.

Richard_Stiennon: Let's talk about NAC's pain.

Joel_Snyder: Why do you keep deflecting from the question of whether it's useful? Pain. Interoperability. Let's stick to one topic.

Richard_Stiennon: I knew you were hot on Microsoft NAP, Joel, so I took some time to look at it. I am horrified. Look at all those components! A 2008 server to run System Health Validators, System Health Agents on SP3 and above machines, for IPSec you need an additional Health Registration Authority on presumably another Win08 machine (the same as your CA?), and an IPsec Relying Party EC on each desktop and server. (I am not even sure what those are but there are separate ones for wireless and wired access.)

So, when setting up an IPSec connection there is a server that issues a health certificate (x.509)? Is that before or after Phase 1? Phase 2? Is the certificate revoked after every session? What happens if the SHA determines the endpoint is no longer in compliance? Does it tear down the IPSec tunnel? Is the certificate revoked? How do all these things talk to each other? What protocols/ports do they use? I would not want to deploy something like this without paying a consulting firm millions of dollars. Scary stuff. .

Joel_Snyder: I'm not sure how to answer that. How about: "I don't think you're getting the point of NAP?" No one is particularly interested in NAP in IKE v1. What NAP makes interesting is the ability to have a STANDARD architecture for how end-point compliance will interact with the network and the PDP.

Richard_Stiennon: Then how do you check someone's machine state when they are VPNing in?

Joel_Snyder: The SSL VPN guys have had a great strategy for that for five years.

Richard_Stiennon: You just said STANDARDs were not part of the discussion of the value of NAC.

Joel_Snyder: You're the one who brought up NAP. I'm still trying to keep us on topic of usefulness. Look, it's a technology. Many enterprises use it, but how they use it and where they use it varies depending on what problem they want to solve. As I see it, your vision of NAC is like you coming in and saying that Dynamic Routing is no good because RIP doesn't scale. Well, you'd be wrong on both counts: for some people who don't need scale, RIP is fine. And RIP is not dynamic routing, just as asking end points if they're infected is not NAC.

Richard_Stiennon: OK, let's take some cases to discuss usefulness.

Joel_Snyder: OK. The Blue Ridge guys sent me a list of 11 of them yesterday :-)

Richard_Stiennon: Please mention ONE that is not EDU or MIL.

Joel_Snyder: What's the problem with EDU and MIL?

Richard_Stiennon: Having a product that addresses education and military needs does not an enterprise market make. That is niche.

Joel_Snyder: It's a frickin' huge niche. But OK, let's get off that.

Richard_Stiennon: For those that address it yup.

Joel_Snyder: OK, so here's a simple example, an organization that provides IT services to a BUNCH of small sub-organizations.

Richard_Stiennon: A MSSP [managed security service provider]?

Joel_Snyder: No -- let's say it's one of the large states in the US and it's a semi-outsourced IT department. Each of the sub-departments, like the Senate, the House, etc., is a warring faction. Indeed, each of the senators is at war with each other. In this particular case, the problem we solved was that each senator/representative/staffer needed to be "on their LAN" no matter where they were in the capital city.

Richard_Stiennon: Great application for network segmentation. VLANs within the network VDOMs at the IP layer.

Joel_Snyder: No, VLANs doesn't work. Doesn't scale in this case. But VLANs would have worked, if there weren't hundreds of them. In any case, that doesn't matter. What was critical was that the network users be assured that they were not being connected to the wrong part of the network. NAC helped. We let them auth, that assigned a group, the group implied an ACL.

Richard_Stiennon: Oh no! Not ACLs! You are scaring me. What do you use to enforce, manage, log those ACLs?

Joel_Snyder: Look, are you going to keep on topic or not? We're talking about usefulness here. Not the product that they bought to make it work.

Richard_Stiennon: That is useful but should be addressed with networking, not with host agents and a separate server. How much did it COST???

Joel_Snyder: There was a need. The need was met. We used "NAC technology" to do it. In this case, there was no host agent. Turns out that, surprise, surprise, these guys use Windows and Microsoft seems to have given away what they needed. I don't know the total cost. Remember, it was a state legislature. Got hidden in the budget with the Blackhawk helicopters and private jets. But I can put it this way. No one needed to get authority to spend money, because it wasn't a lot.

Richard_Stiennon: So, are you saying that it is good to use existing deployments of technology to accomplish your goals?

Moderator-Julie: We have a number of questions in the queue from attendees, so we are going to move on to answering as many as we can in the time remaining.

lucas_burke: In higher education users can often add any device they want to a network. You don't have the luxury of enterprise level control. To me NAC solves many problems at once - like, tracking stolen devices on my network, enforcing virus standards, shutting down rogue wireless APs, etc. Richard: is there is a better way to do this than NAC? I'd love to hear it.

Richard_Stiennon: I have a huge problem with the laissez faire network admin at higher education. Any protocol, any action is allowed. By deploying NAC you can have absolute control over someone with a misconfigured laptop/server but you refuse to put in the controls needed to stop them from hacking! Or otherwise abusing your system. Within most universities the health systems have already moved over to secure environments. The rest of the organization should look at that as well.

Danny: I believe we must focus on "endpoint security" as the primary traditional goal of NAC. Allowing clean access to the network. I have investigated several NAC solutions, and it appears there aren't viable ones without a true agent. Some may be perishable. I do take some exception to the comment from Joel before as I don't see how "interoperability is a given" if a particular NAC solution uses switches as the enforcement point with proprietary protocols (see a few little guys names Cisco, Nortel and Juniper to name some).

Joel_Snyder: Danny: I'm OK with you wanting to focus on endpoint security for yourself. As I wrote above, whatever it is you need to solve is your problem to solve, and if you want to concentrate on end-point security, that simply says what you want to concentrate on when you evaluate products. Having a good idea of what you want to do ahead of time will massively save you time. Actually, though, Juniper and Cisco for sure will work with standards-based RADIUS attributes. So when I say "interoperability is a given," I mean that it is a given because we proved it at Interop. See, http://www.opus1.com/nac for our results. (I didn't mention Nortel because they didn't play, so I don't know if they will work within standards)

phreno: Richard: Some NAC products offer behavioral policy enforcement. I can get identity, endpoint checks, and behavioral policy enforcement that stops botnets, DDoS attacks, etc. that do find a way onto the network. What other technology offers that?

Richard_Stiennon: Great question. This is where the IPS/AV industry is heading. Allow an infected end point to connect, but do not allow it to harm me. Filter out attacks at the edge. The capability you refer to in some "NAC solutions" is what they call post admission control. That is good but the action should be to drop packets, not end point connections.

chuck: One of the issues at my firm is the worry that vendors and contractors will plug into some LAN jack at one of hundreds of locations and spread malware onto the network. How do you solve this issue (affordably) when you have so many locations and you need to be able to check all that traffic?

Joel_Snyder: Chuck: What I usually call "guest access" is one of the huge drivers for people to look into NAC. Remember, also, that by my definition if you ONLY want to solve guest access, that's OK too.

Richard_Stiennon: Simple to do to. Just authenticate against the network!

Joel_Snyder: There are two subtopics here. One is that the guests need to be inside and the other is that the guests need to be outside. If the guests go on the outside, then you have a lot of easy options. One is that you can auth up the legitimate users, and anyone who doesn't auth properly or isn't on a MAC OUI list (think VoIP phones, printers) gets dumped outside the firewall or on a DSL disposable line.

If the guests go on the inside, then it's harder. You might want to differentiate here between guests and contractors that need internal access. But you can put a pile of CHEAP access controls on the switches you already have by simply recognizing them and doing a captive portal authentication. You can pay Cisco money for something like CCA [Cisco Clean Access, but the product is now called Cisco NAC Appliance], or go open source with similar solutions that only get in the way of the guests.

lucas_burke: Richard: networks and desktops aside, from an information security perspective - does NAC lower overall risk?

Richard_Stiennon: I believe NAC does nothing to reduce overall risk. It does not counter the malicious (or stupid) user. It does not stop a hacker from riding in on an authenticated machine, it does not counter zero-day worms. It is not actually a strong authentication solution at all, so you still have to layer that in.

Joel_Snyder: Can I quote from Saturday Night Live here? Jane...

Richard_Stiennon: You ignorant sl*t?

Joel_Snyder: Let's just say that "I disagree." If you can gainsay assert that it doesn't lower risk, then I'll claim the opposite.

Richard_Stiennon: OK, Joel what would you do to prevent an end user from doing a DDoS against the Domain Controller? Or sniff the wire and steal accounts and get into the Oracle database?

Joel_Snyder: "It depends."

Richard_Stiennon: Will NAC be your answer?

Joel_Snyder: One is that the Domain Controller should be protected with its own technology, including a firewall with some anti-DoS technology.

Richard_Stiennon: So you still need to layer security in? Even after spending big bucks on this NAC stuff? Why not just do the security and move on?

Joel_Snyder: Actually, that firewall should have been installed about 10 years ago.

Richard_Stiennon: Not at EDU it isn't.

Joel_Snyder: NAC isn't solving the problem of a DoS against a DC.

Richard_Stiennon: Or of a malicious user doing anything, or any unwarranted action on the network such as injecting an infection!

Joel_Snyder: A malicious user might think twice about doing something if they knew that they were being positively identified every time they sat on the network. Actually, NAC helps a lot with infections.

Richard_Stiennon: Hey, it wasn't me, your NAC just did not see the copy of MSBlaster2009 on my machine.

Joel_Snyder: Because NAC includes the continuously evaluated function of end-point compliance and end-point behavior, NAC gives us the tools to knock someone off who is misbehaving.

Richard_Stiennon: Host AV helps a lot with infections. I just spent millions on it. You mean I need something else to make host AV work? What's up with that?

Joel_Snyder: Without NAC we don't have those tools, or we are reduced to using proprietary products to solve point problems. Yes, you need enforcement. That's the "AC" in NAC.

Richard_Stiennon: I already have those products. Why do I need Microsoft everywhere to enforce them?

Joel_Snyder: Every NAC deployment I've looked at, and everyone I've heard about, has a surprise factor.

Richard_Stiennon: mmm?

Joel_Snyder: The surprise is how UNcompliant PCs are with the host AV. Talk to the most Microsoft-savvy IT departments in the world. They'll tell you they were astonished at how low their compliance level was. And how hard it is to get it up.

Richard_Stiennon: So why not defend against those machines with some active network technology?

Mike88: This question is for both Joel and Richard: My company is currently evaluating a solution to control user access and ensure machines are compliant before connecting to our network. My current anti-virus vendor is capable of delivering integrated NAC functionality that would solve these problems. Do you think that combining anti-virus and NAC is a good strategy?

Joel_Snyder: Mike88: I think that if you like EPC (end-point compliance) as part of your NAC solution, then having it integrated into NAC is a great way to simplify your deployment. If your A/V vendor will give you NAC for cheap or for free, take them up on it.

Richard_Stiennon: You have to answer a few questions. Do you have separate networking and desktop departments? Or are they same person. Don't forget Mike88, that by blocking access based on config you are going to have tons of new support calls. As Joel pointed out most machines are *not* compliant. Is it worth that pain?

Joel_Snyder: NAC doesn't imply blocking. You could do reporting, as some companies have done.

Richard_Stiennon: It implies quarantine and fixing no? Otherwise what the heck are we doing here?

Joel_Snyder: It's a wise first step. It depends on how big of a picture you can put in your head. Authentication, quarantine, etc., are not all necessarily automated. For some enterprises, the pudgy guy with a nightstick at the front door is "authentication." NAC is a solution, not a product. Get that tattooed on your head. NAC is a technology. Put that on the other cheek.

Richard_Stiennon: NAC is a problem, not a solution.

xyz: Richard - Part of access control is resource allocation post authentication and successful authorization. How do we achieve this from the network level without massive ACL management?

Richard_Stiennon: Great question xyz. You need centralized IAM (identify and access management); tons of great solutions out there. Gartner has a whole conference coming on IAM. I would shy away from NAC too.

Joel_Snyder: I'll jump in here too. Sean Convery just wrote a paper on NAC. (He doesn't want to call it NAC, he calls it Authenticated Network Architecture -- ANA). Anyway, the point he makes is that you don't need to have super fine-grained ACLs to get a huge reduction in risk.

Richard_Stiennon: *My* point would be that you NEED to get to fine-grained access control to secure your enterprise.

Joel_Snyder: Fine-grained is a spectrum. Aren't you the guy who just advocated VLANs? I'm saying that if you have coarse control, even go/no-go, that's a reduction in risk.

Richard_Stiennon: We agree.

Joel_Snyder: You have to use somebody like a Chris Hoff or Pete Lindstrom to figure out where the marginal dollar being spent is worth it for marginal reduction in risk. And NAC can accommodate all of those, even simultaneously.

Richard_Stiennon: I just hate that the "no go" of NAC means you are kicked off the network.

Joel_Snyder: We do "no-go" all the time in wireless. It's NAC. Authentication with 802.1X (hidden in WPA). If you don't, no network.

Richard_Stiennon: The NAC definition bubble is expanding here.

Joel_Snyder: AC = auth + EPC + NBAD. Same definition. But 0% EPC. Everything is consistent.

Richard_Stiennon: Where is the policy in that???? That is the most critical function of access control. Policy policy, policy.

Danny: Richard: there was an interesting comment you made earlier, on user access control vs. end-point access control. Can you elaborate on this? Specifically, how would user-based access control help to prevent infected machines from being on the network? Especially considering the mobile "user" who can log-in from various endpoints in and out of the LAN?

Richard_Stiennon: Actually I don't care about infected machines. If a user authenticates you care about what group they are in and what privileges to grant them. Their machine is another issue. Just filter out the bad stuff.

Danny: Joel: how well do you see mobile device OS, MACs, Linux being accommodated for in NAC technologies?

Joel_Snyder: Danny: "not well." Let me elaborate. Obviously, the main concern is the main deployment issue, which is Windows systems. So naturally, they are being handled better than anything else. Also, since EPC is not 0% for anyone following Rich's strategy of NAC, people are more concerned about EPC and EPS in general with Windows than they are with Treos and BlackBerry's (not that this is correct, but we can only fight the last war, right?).

So I have hopes for better support of non-Windows devices (which is the real issue) and with demand, it will come. In a pure authentication sense, they're already well supported.

Richard_Stiennon: Here is my problem with NAC:

1. It is not a security solution at all. There is not a single aspect of any NAC product that protects the network from the malicious user.

2. It is not a zero-day protection. During the next outbreak NAC will do NOTHING to protect the network.

3. It introduces a new layer of technology whose PURPOSE is to block access to the network. Network admins spend most of their work week getting people ON the network. Introducing things that keep them OFF the network is not attractive.

4. It is almost trivial to bypass NAC. All you need to do is corrupt the local agent.

5. It violates Stiennon's first law of network security: Thou shall NEVER trust the endpoint to report its own state.

Moderator-Julie: We are out of time now. We have several more questions that we will forward onto Joel and Richard to answer in their blogs.

Joel_Snyder: I'm the anti-blog. Don't have one, sorry :-) But I do have e-mail... which you can find by typing "Joel Snyder" and clicking "I'm feeling lucky' into Google.

Moderator-Julie: The transcript for this chat will be available within 24 hours on www.networkworld.com and also in the archive section of www.networkworld.com/chat/ and in Microsoft Subnet (www.microsoftsubnet.com) and Cisco Subnet (www.ciscosubnet.com). Also please join us for our upcoming chats. All are at 2 - 3 p.m. ET at http://www.networkworld.com/chat/

Wednesday, July 30 -- Implementing WAN acceleration with Jim Metzler

Tuesday,  August 19-- Facebook: friend or foe? With Curt Monash

Richard_Stiennon: Bye all, thanks for joining.

Joel_Snyder: Bye bye. Keep it safe. Or something.

Also see these recent chat transcripts

Network Access Control: fact and fiction with Joel Snyder

Crimeware: understanding new attacks and defenses, with authors Markus Jakobsson and Zulfikar Ramzan

Counterfeit network gear: how to detect it and protect yourself with Mike Sheldon

Security training as career booster, with Adam Gordon

LAN switch security: What hackers know about your switches with Christopher Paggen

All chat transcripts.

Learn more about this topic

 
1 2 3 4 5 Page 1
Page 1 of 5
IT Salary Survey: The results are in