My blog reader had an unexpected surprise for me this morning - a brand new Javascript based trojan that appears to have been automatically downloaded to my PC via the RSS feed of a blog I subscribe to. According to the virus encyclopedia entry, this trojan was discovered just two days ago. Last week I was on the road for a couple of days and it’s possible my blog reader would have downloaded this before my antivirus updated with the latest signatures, in which case my computer could well have been compromised.

We’ve been running our entire office on a Napera N24 since last year, so the trojan had little opportunity to slip past the up to date antivirus and antispyware software enforced on every computer on our network. Still, it was nice to see a live demonstration of the short time between discovery and proliferation of a threat, and the need to continuously monitor computer health via NAP. Yesterday I was talking to a customer about exactly this type of scenario and how we designed the Napera products to manage it. I didn’t have an inkling that I would be living proof within 24 hours!

Andrew Conry-Murray at InformationWeek stopped by at Interop for a video interview to talk about Napera products and NAC in the SME.

Calvin Choe from the Microsoft NAP team also came by to chat about NAP.

We wrapped up at Interop last night. This was another great show for Napera, and thanks to everyone who stopped by. It was good to catch up with the folks we didn’t see at RSA! I’ll post links later to a couple of video interviews we did at the show.

With RSA edging closer to Interop this year, heading to Las Vegas for Interop seemed like a repeat of what we did just a few weeks ago in San Francisco. On a personal note, I like the idea of RSA moving away from their traditional Valentines Day timing, but scheduling these two shows only weeks apart makes me wonder if RSA is trying to elbow Interop out of the picture just as Interop is making a comeback. That would be a great shame, because Interop is a unique tradeshow. The mix of attendees is very different to RSA and the Interop Labs has always been a valuable industry event that cuts through a lot of the marketing hype and gets down to packets and protocols.

This year the staging for relevant portions of Interop Labs was scheduled during the RSA conference itself, making it tough for smaller companies like Napera to attend both. Essentially it came down to the choice of key engineers meeting with customers at RSA or meeting other engineers at Interop Labs, and the customers always win out. Next year I’m sure the stars will align and we look forward to participating in both.

Yours truly spreading the word about Napera in the Microsoft Partner Pavilion

It may not be the halcyon days of the late 90’s when Interop took over the massive Las Vegas Convention Center, but judging from the mood at today’s show the buzz is definitely back at Interop!

NAC is everywhere, and Mike Fratto’s sneak peek of the Information Week Third Annual NAC survey confirms what you can tell by just walking around the show floor - there is a huge amount of interest from customers in NAC solutions, and we’ve had lots of interesting meetings today.

Speaking of Information Week, Andrew Conroy-Murray just published a great profile on Napera, and I recorded a brief video interview with Andrew for TechWeb that should be published shortly. Hopefully you’ll be able to hear us over the Frank Sinatra and Barbra Streisand impersonators crooning in the next booth!

I’m speaking Wednesday at 1pm in the Microsoft booth (1719, right near the main exhibit floor entrance). I can’t croon like Ole Blue Eyes, but stop by and say hello if you have a moment.

Todd, Robin and Cary in a rare serious moment.

Napera was proud to be a sponsor of the 1st Pacific Rim Regional Collegiate Cyber Defense Competition held this weekend at the Microsoft campus. For ChrisB and I, it was a rare opportunity to see students in action in a highly technical scenario, and we were both impressed by the levels of skill on display as they defended their network from the Red Team. Special props go to the team from the University of Washington Computer Science & Engineering for taking the top score.

I’m sure everyone who participated is already on their way to a promising career in information security. As I mentioned to several people at the event, Napera has intern and full time positions open and we welcome inquiries at careers@napera.com.

All eyes were on screens as the competition started Saturday morning.

The Napera team will be at Interop 2008 in Vegas next week. We’ll be demonstrating our products and talking to analysts and press about our approach to securing the small and medium enterprise. If you’d like to meet, please visit us at the Microsoft NAP partner pavilion - Booth 1719. We’ll post further updates from the show floor during the week.

With the news today that Windows XP Service Pack 3 has been released to manufacturing, the last piece of the network health puzzle falls into place for Windows users.

Why is XP SP3 so important? Because it includes the Microsoft Network Access Protection health agent first available in Windows Vista. In turn, the NAP agent enables Windows XP systems to report health over the network. Napera products leverage Microsoft’s NAP architecture for health information, and we can provide health diagnosis of Windows Vista, Mac OS X and now Windows XP systems on customer networks.

A number of our customers continue to use Windows XP, and we’ve been eagerly awaiting this release to provide them with full health functionality across their entire network without requiring them to install a third party agent. End users should see XP SP3 appear on Microsoft update next week, and it will become an automatic download starting in June.

We’re excited to welcome Pierre Blom and Austin Wright, our brand new European sales team. We convened at Napera HQ on Mercer Island this week to plan our European launch.

Pierre and Austin were key members of the international team at WatchGuard, and have many years of experience in the network security market throughout Europe and the Middle East. They will be attending Infosec Europe in London next week to meet with our channel partners in EMEA. Please email sales @ napera.com if you’d like to arrange a meeting with them.

Cary, Austin, Todd and Pierre at dinner on Mercer Island

Networking behemoth Cisco has finally made good on its 2006 commitment to integrate their proprietary NAC products with Microsoft’s NAP architecture, and the result should be shipping any month now.

I keep the three volumes of Cisco Press books about NAC on my desk as a handy paperweight (1800 pages, actual weight 5.1 lbs), so I’m already aware how complex the Cisco NAC product line is. Ironically, support for NAP appears to have made Cisco NAC more complex, not less. Last year Cisco and Microsoft published a white paper explaining how Cisco Secure ACS works with NAP. The approach relies heavily on 802.1x in addition to a number of different servers. ChrisB posted earlier today on why we don’t think 802.1x will see wide adoption in the small and medium enterprise, and Network World found even the latest Cisco and Dell switches have problems with 802.1x, but that’s just the start of the challenges for Cisco NAC.

When you dig into the details of Cisco’s NAP integration, you quickly realize Cisco did not take the opportunity to simplify their product. For example, the Cisco Secure ACS configuration guide describes a NAP scenario with fifteen steps for implementation. Fifteen steps sounds pretty manageable, right? Wrong! Each of the fifteen steps contains another dozen or so steps. Step 10 promises instructions for setting up Windows Server 2008 and the Microsoft clients, but instead directs you to the wrong URL for the helpful-sounding NAC/NAP Configuration and Troubleshooting Guide (which appears to be missing in action).

Missing documents aside, 250+ steps later you may just have a working NAP integration. The sheer amount of information covered in the Cisco configuration guide might be OK for the large enterprise CCIE who deals with Cisco products every day, but the average IT administrator is going to be overwhelmed. Cisco is a welcome boost to the NAP ecosystem, but I doubt small and medium enterprise customers will be rushing to implement Cisco’s flavor of NAC just because they finally support NAP.

Cisco lab photo courtesy of Roney.

With JJ blogging about 802.1x, I thought it would be timely to talk about why I think small and medium sized enterprises (SMEs) do not and probably never will deploy 802.1x for wired networks.

I make a point of meeting with customers whenever I can. Amongst the small and medium enterprise customers I’ve met, none have shown an interest in deploying 802.1x. The reason is simple - the problems solved by 802.1x do not justify the time and pain involved to setup and maintain it. Many of these customers would love to require everyone to identify themselves prior to joining the network, and want to keep risky machines off their network. They know this makes their networks healthier and easier to maintain. But I’ve yet to meet the customer willing to endure the complexity of 802.1x to get there.

There are two security functions that 802.1x brings to the table: authentication and access control. Authentication is pretty straightforward. Prior to a device gaining access to the network a user must authenticate. (There is also an option to do device authentication, but I’ll disregard that for this post). Access control is more involved. Generally, when people talk about using 802.1x to do access control they mean assigning a device to a particular VLAN depending on the “health” of the device connecting. In the case of Microsoft NAP, this health information is sent via the 802.1x protocol.

Multiple characteristics of 802.1x make it undesirable for most SME networks. First, setting up all the components for 802.1x is an exercise only for those with time, patience and MacGyver-like IT skills. The second and more significant obstacle to 802.1x is the unfriendly end user experience that results when problems occur.

The pain of 802.1x configuration

In typical 802.1x deployments, three separate components need to be configured properly: the client, the switch and the Radius server. Each of these components is usually supplied by a different vendor, and 802.1x introduces plenty of new terminology. 802.1x clients are called supplicants, switches are called authenticators, and 802.1x requires admins to take a crash course in protocols such as PEAP and EAP-TTLS with a helping of PKI.

With so many moving parts, when something goes awry it can be difficult to figure out why. Many hours are wasted reading logs from the switch and the Radius server trying to decipher which is configured improperly. Each switch vendor has its own unique way of setting up 802.1x, so this adventure often reoccurs with each new switch purchase. I have fount that the typical SME has at least three brands of switches in their wiring closet.

Once the switch is talking with the Radius server, there is the challenge of configuring a desktop client on hundreds of computers. Until an 802.1x client can properly authenticate, it can be difficult to determine which component in the chain is causing the problem. This problem repeats with each new 802.1x client. For example, switching between Mac OS X 10.4 and 10.5 involves a completely new 802.1x client configuration.

Keeping the bad guys out (and the good guys too)

Using 802.1x to quarantine user devices that fail health checks usually involves configuring VLANs. In turn, this means setting up redundant network resources such as DHCP servers for each VLAN. I have met very few SMEs that use VLANs for anything other than VoIP. VLANs are not rocket science and are well within the expertise of most IT teams, but a complex VLAN deployment is rare in the SME.

Another difficulty arises when guests and non-guests need to share the same port such as a conference room. As guests are unlikely to have an 802.1x supplicant configured properly, the optimal configuration would allow guests to connect without 802.1x while requiring 802.1x for employee access. With most switches this is not supported, especially if you are using VLANs for quarantine access.

Leaving users in the cold

As I mentioned above, the most significant issue for 802.1x deployments is the user experience when the supplicant cannot successfully communicate with the Radius server. If there are problems, the end result is often a lack of network access. Any chance of automated support over the network is lost. The frustrated user typically picks up the phone and calls the help desk (assuming the 802.1x outage didn’t take out their VoIP phone too). A great example is a user who simply forgets their password. With no IP address, there is no opportunity for an automated password reminder or support call via a web page.

Is there an alternative?

If you are wondering why any SME IT administrator with limited time and budget would deploy 802.1x for a wired network, you may appreciate Napera’s approach to building network products. Most SMEs demand a superior deployment and operating experience with their networking equipment. Until vendors can provide a simpler end-to-end 802.1x, don’t expect significant adoption in SME networks.

It is possible to accomplish the goals of securely controlling access to the network based on identity and health of a computer while delivering a great user experience for both the user and administrator. At Napera we chose to solve this problem by embedding more intelligence into the access switch. It was important to build a product that gave our SME customers tools that are easy to deploy and maintain while delivering the security features desired. We consider this core to ensuring a robust and healthy network. In a future post I will talk specifically about how we did this.