Four chains, four Wi-Fi pay policies: CIO magazine looks at Borders, McDonald's, Panera, and Starbucks, and how they're offering Wi-Fi. I'd like to suggest you read this article, but the author writes, "Right now, according to Hotspot Locations, there are more than 33,000 WLAN hotspots worldwide, and more than 10,000 in the United States alone." I don't know who "Hotspot Locations" is, and I need to disclose that I have a financial interest in what must be their competitor, JiWire, but any hotspot finder that calls them "WLAN Hotspots" and reports 11,712 in the U.S. and 33,106 worldwide just isn't working very hard. JiWire lists over 230,000 hotspots worldwide, and notes over 60,000 in the U.S., while Boingo and iPass each resell access to over 100,000 hotspots worldwide.

Up, up, and away in my beautiful, my beautiful warballoon: Defcon hackers deployed a balloon with Wi-Fi receivers on it 150 feet in the air to scan for network vulnerabilities in Las Vegas last week. They found 1/3rd of networks had no encryption--although I always wonder if they're using passive scanning where 802.1X allows a limited connection for authentication and appears "open" in some ways, or if they were actively scanning, in which case 802.1X networks would be unavailable.

Cincinnati Metro service has Wi-Fi on 20 buses: The free service supplied by AT&T in an ads-for-access deal with the authority was placed after a couple years of testing on a relatively long commuter run. The authority spends $15,000 per bus to setup a connection, which seems rather pricey. Other authorities are paying in the low thousands, from what I've seen, so I'm not sure what their particular case is.

Some of the major obstacles we face with 802.1X center around creating a smooth end user experience.  We, as integrators, have the distinct ability to make ‘whatever’ work- we find a way. But, what I hear most from my customers is “it has to be easy for the end user.”  (Sometimes they go on a little further, but I’ll leave it at that.)

Why does it matter?

Wireless, wireless, wireless. Although wired 1X is popular with our customer-base, the world isn’t quite flocking to it yet. However, 802.1X is certainly the best way to increase security and ease management of wireless networks. It’s standard, it’s flexible, it’s widely-supported by devices and endpoints and it eliminates the need for pre-shared keys or secondary passwords. It’s what most enterprises, government and educational organizations are implementing now, so it’s important.

What are some of the problems?

The end user will have some adjustments to make, and network admins and support desks aren’t always thrilled with the propect of re-training users for these expectations.

Well, sure you can! There is a little trick now, though.

As part of the move to the Microsoft NAP integration, they’ve broken out the wired and wireless supplicant management into two pieces. Until SP3, all 1X was handled in the Wireless Zero Configuration (WZCSVC) service. The wired 1X supplicant is handled now by a different service and must be manually started.

In Windows XP SP3, the supplicants are each handled separately by these services…
    •  Wireless 802.1X: WZCSVC service
    •  Wired 802.1X: Wired AutoConfig service (DOT3SVC)

Instead of duplicating a lott’a text, you can find detailed instructions for manual and pushed wired 1X configurations on Microsoft KB article 953650.

You can also learn more about Microsoft NAP integration in the Network Access Protection Q&A site.

# # #

I’m juggling blog-moving with blog-posting and trying to find the happy medium. Coming soon though, are two NAC/1X series I hope you’ll enjoy…

NAC Vendor Sauce Series: Fishing out Features
Each NAC solution on the market has it’s own special NAC ‘sauce’ , a feature that sets it apart, or makes it better for certain situations, than others. This series highlights the advantages of each solution and includes Juniper, Cisco, Symantec, Enterasys, ProCurve, StillSecure, Napera along with a few others.

802.1X Vulnerabilities: Designing for Security
Often, users put too much stake in 802.1X, relying on it too heavily in many circumstances. There are vulnerabilities with 1X, but most can be mitigated or avoided with smart planning. This series describes various vulnerabilities with 802.1X, gives you details on each and provides information on how to protect yourself from them. To get started, check out my 802.1X Technology Primer.

# # #

Because of non-disclosure and other confidentiality contracts with various partners, vendors and manufacturers, we’ve had sealed lips for almost exactly 12 months. Now that it’s been made public by the media, I can share a little information with you and explain why I think you should be excited.

What cat is out of the bag now? HP ProCurve’s network access control solution leverages endpoint management technology from StillSecure’s Secure Access solution. Information Week spilled the beans, so to speak, in Mike Fratto’s recent 2008 NAC Survey Analytic Report. (See page 32)

Now, at this point, I can probably lump you into one of three groups… 1) You don’t care or have no clue what this means 2) You care but think this means HP ‘has no NAC’… or group 3) You know about StillSecure’s success and ProCurve’s integration and think this is a great combination.

I’m sure everyone will have their own opinion- I happen to be in Group 3. Why? Because HP has taken the power of their servers, leveraged a very solid endpoint management tool and incorporated a variety of other management and security features by way of their identity management solution.

• The endpoint security. StillSecure’s Safe Access solution has been winning awards and earning stars for years. You can probably Google it, or check out some of Shimel’s blog  posts, such as this one, with 4- and 5-star reviews from SC Magazine. In fact, just this year (and in previous years) Safe Access was voted Best Endpoint Security Solution by SC Magazine and has won numerous other awards and accolades from various analysts and media firms. They have a clean, user-friendly GUI, a solid Linux platform and a variety of testing methods, deployment options and switch integrations. (And no, you don’t need ProCurve switches, the NAC integration is ready for your Cisco, Extreme, or whatever you have).

• User management. Combine one of the highest-rated endpoint security solutions with ProCurve switches, the #2 leader in the switching market (and Magic Quadrant resident) and the full integration with ProCurve’s Identity Driven Manager platform and you have one amazingly capable access control system. With ProCurve IDM, you can integrate directly with their NAC 800 appliance to offer per-user (or per-group) ACLs, QoS, restrictions or priviliges. Rules can be identity-based, time-based, location-based, or a combination of all. And, IDM eases 802.1X integration by offering users a central management and repository for user settings and VLAN assignments; it really is ProCurve’s special sauce and a distinguishing feature.

• Switch security. The integration of advanced switch security functions, such as DHCP snooping, Dynamic ARP protection and dynamic IP lockdown gives ProCurve another leg-up to fight common known attacks for both in-line and out-of-band NAC deployments.

• Zero-day protection. It gets better, the new Dynamic Configuration Arbiter (DCA) functions in ProCurve’s Pro-vision switches gives customers the unique advantage of integrating the NAC and IDM with ProCurve’s Network Immunity Solution (NIM). NIM uses flow analysis from sFlow and network behaviour anomaly detection (NBAD) to detect and automatically remediate on the edge. In English, that means we can use ProCurve’s NIM to detect attacks and take action at the edge port, such as blocking the port, locking out the MAC address of the offender, rate-limiting, or even mirroring the traffic to an IDS for further inspection. The super-nice part is, all the sFlow and NBAD works on wireless too. (Hey Stiennon, did you hear that?)

• Full integration. Unlike some of the other network-based NAC vendors, ProCurve has done an exceptional job of integrating these features and we’ll continue to see more integration in future revisions of the softwares and as more TNC/TCG integration frameworks are released (such as IF-MAP).

I think the strong integration with the infrastructure and the ability to leverage a mature endpoint integrity will make HP a ‘real’ player in the NAC market moving forward.

Not to knock other NAC solutions- Choosing a NAC is like selecting the perfect wine for your dish- there’s no 1 ‘right’ choice for all occasions. Each have their advantages and disadvantages. There are several that have special sauces and you’ll actually be seeing more on that soon…

# # #

Apple splits its 802.1X support into two pieces. There's basic support built into the iPhone 2.0 software, found in the Settings application's Wi-Fi section. Click Other. Click the None label next to Security, and the WPA Enterprise and WPA2Enterprise options appear. Select either, and the main login screen lets you enter the network's name (SSID), a user name, and a password. This basic method is limited to WPA Enterprise and WPA2 Enterprise, the two most common (and most secure) forms of 802.1X.

Most enterprises will want much more control over this process, and Apple provides the iPhone Configuration Utility, currently available in its most complete form only as a Mac OS X application, and in more limited forms as Web 2.0 applications for Windows and Mac OS X.

The utility serves two purposes: creating configuration profiles, including for multiple Wi-Fi networks and VPN connections; and allowing iPhones in an enterprise to run internally developed iPhone software. The Wi-Fi profiles allow you to create WEP or WPA/WPA2 802.1X configurations, and include support for choosing allowed EAP messaging types, configuring authentication elements associated with a given EAP type, and adding server certificates and names for better authentication control.

Once created, these profiles can be distributed throughout a company via email or as a direct download to the iPhone via an intranet Web server. Apple chose not to encrypt them, which means that certain information that's not secured--such as the shared secret for certain VPN connections--could be disclosed to someone who had access to the profile or could download it off the local network.

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.

Respectfully,

jj

# # #

If you read my blog, or know me, you probably know I do NOT like software (and it usually doesn’t like me). So, I’d be the first to jump on the ‘anti-software-peer-based-NAC’ train, but I think we have to be informed before we jump to conclusions and hop on any trains.

Mirage’s recent blog post on Symantec’s ‘Silly SNAC’ was certainly a result of a mis- (or un-) informed person. Tim did a much better job on his mention of SNAC in the NWW blog, but all the dots still aren’t connected. It proves the point that sometimes we (as bloggers) tend to write based on a feeling and sometimes don’t dig for the fact.

So, in an effort to make sure I understood this new peer-based NAC, I reached out to Patrick Wheeler, Symantec’s Senior Product Manager for Network and Endpoint Security. Based on my conversations with him, and a pretty detailed investigation into the options and configurations of their NAC products, I have some slightly more informed opinion to share with you now.

Symantec has a variety of NAC enforcement components and options. I’m going to keep all the software-type-stuff out of this conversation for the time being. They have (among other things) the NAC Enforcer, an appliance similar to the other NAC controllers we see from traditional hardware vendors. Just like it’s counterparts, Symantec’s NAC Enforcer can be configured for DHCP, inline or 802.1X based enforcement.

The piece that’s different is the integration of the NAC Enforcer with Symantec’s Endpoint Protection Manager server that hosts the policies for the NAC. It’s similar to the management-enforcement configuration we see from other vendors, only the management piece is housed on a server instead of another appliance.

And, just as other vendors offer some type of endpoint integrity agent, the Symantec agent comes in the form of the Symantec NAC Client, which can be used by itself, or integrated with the Symantec Endpoint Protection Client for an even more robust feature-set. (The Endpoint Protection Client offers some additional host-based firewall features that the NAC can leverage).

So, what about the Peer-Based NAC? Ah, well that’s just the first iteration of a ‘vision’ to address mobile corporate users. If employees have laptops in an ad-hoc situation outside of the enterprise infrastructure (and therefore, outside of enterprise enforcement), then the peer-based NAC can port the enforcement rules set at the ‘mothership’ and enforce them individually. The peer-based NAC can protect mobile assets in their most vulnerable situation, outside the security of the corporate network. But, the rules are still set centrally and the peer-based NAC was designed to be just one step towards an added layer of protection, not as a replacement for network-based NAC.

For now, I’ll stay off the hate train, since the peer-based NAC is more of a supplement to a more robust traditional NAC solution. If they move to a fully-host-enforced product, I’ll buy my tickets…

Image shown is copyright of Symantec Corporation.

# # #

For June, we have an 802.1X hat-trick to blame for my slack blogging habits. Over the past few weeks, I’ve had back-to-back 802.1X implementations, one wired, one wireless and one with both. Two government customers and one commercial, not in that order. And I even did one semi-training-slash-semi-implementation-quick-start for another customer.

It’s been fun, but 1X is always challenging. The variety of components, the nature of the interactions and the ‘newness’ of actual implementations make it difficult to work from any type of cookbook or implementation guide. There are just too many variables.

When will it be easier? I think as 1X is more widely implemented in the real world, customers will become more familiar with the concepts and integrators will have more experience to make it go smoothly. For now, everyone has to just take it one step at a time and address issues as they arise. And, for now, I’ll enjoy the job security that 1X offers ;)

Luckily, I’ve had the opportunity to work with a variety of customers and a variety of environments and equipment while hammering out 802.1X. The experience and exposure has certainly given me a unique insight into the issues, complications and solutions that come along with a 1X project.

At present, I think we’ve successfully configured 1X on about a dozen different types of equipment, both switches and wireless APs and controllers, from a variety of vendors. It may not sound like much, but in the world of 1X, that’s quite a variety when you consider each manufacturer has their own ‘system’ for configuring 1X and the commands and procedures can vary greatly even from product-to-product from the same vendor.

Is the 1X streak over? Not at all. We have several customers with NAC and 802.1X projects that we had to queue up for after June 30. I’ll keep you posted!

# # #