Archive for the ‘General Security’ Category

« Older Entries
Newer Entries »

Stirring the Biometric Pot

Wednesday, September 6th, 2006

Update 9/11/06: Kim Cameron’s blog is picking up the biometrics thread as well.

The topic of biometric authentication is making the rounds in various blogs. Phil Becker writes that he considers biometrics “the only true identity based authentication” with everything else as “an approximation of identity validation to some acceptable degree of risk or certainty.” Dick Hardt takes issue with this:

Someone can lift my fingerprint from the case of my laptop, create a facsimile and use that with the fingerprint reader. A fingerprint can actually less secure in some ways then a password. No authentication technology is 100%, just like nothing can be 100% secure. Adding multiple factors to authentication is how we increase certainty.

Also, at my favorite potpourri blog BoingBoing I read that schools in Georgia are allowing a fingerprint scan to buy lunches which prompted a small debate about the merits and risks of biometric authentication. Here’s a snipped of the original post:

Schools in Rome, Georgia, are implementing a system that lets children “pay” for their school lunches with a fingerprint scan. Previously, students had to enter a personal ID number to access their lunch accounts.

I don’t think Phil’s post was necessarily extolling the virtues of biometrics so much as trying to draw a distinction between the different forms of authentication and how they can be used in a basic case study. However, the virtues of biometrics are worth discussing. Before I sat down to write this, I looked back at the section on biometrics in my book. With the assumed gracious permission of my publisher, here is the relevant copy:

Biometrics incorporates the idea of using “something you are” as a factor in authentication. It can be combined with something you know or something you have. Biometrics can include voice recognition, fingerprints, facial recognition, and iris scans. In terms of enterprise security, fingerprint recognition systems are the most economical biometric technology. The main benefit of biometrics is that users don’t need to remember passwords; they just stick their thumb on a scanner and are granted access to a building, PC, or VPN connection if properly authorized.

Biometrics should not be deployed in this fashion, however. The technology isn’t mature enough, and even if it were, relying on a single factor for authentication leaves you open to holes. One option is to consider biometrics as a replacement for a smart card or an OTP. The user still must combine the biometric authentication with a PIN of some sort.

A significant barrier to biometrics is that it assumes a perfect system. That is, one of the foundations of public key cryptography is that a certificate can be revoked if it is found to be compromised. How, though, do you revoke your thumb? Biometrics also assumes strong security from the reader to the authenticating system. If this is not the case, the biometric information is in danger of compromise as it transits the network. Once this information is compromised, attackers can potentially launch an identity spoofing attack claiming a false identity. (This is one of the main reasons including a second factor in the authentication process is desirable.)

Although this could also be considered a strength from an ease-of-use standpoint, the final problem with biometrics is when the same biometric data is used in disparate systems. If my government, employer, and bank all use fingerprints as a form of identification, a compromise in one of those systems could allow all systems to be compromised. After all, your biometric data is only as secure as the least-secure location where it is stored. For all these reasons, look carefully at the circumstances around any potential biometric solution to an identity problem.

I was curious if I would agree with my statements made back in 2004 when the book was first published. As it turns out I’m willing to cede that biometrics are more mature as a technology today but I’ve not yet read anything which indicates that the core vulnerabilities have been addressed. As listed above, those are:

  1. Single-factor deployment is most common
  2. Revocation is impossible (Or its corollary, a perfect system is assumed)
  3. One piece of biometric data can be used in authentication decisions across multiple autonomous systems (weakest link problem)

I’ve yet to read a paper which convincingly addresses these issues in a way that doesn’t depend on each given deployment doing the right thing. Consider the extent of the security used in Rome, Georgia. Perhaps it is quite significant. However, I wouldn’t be surprised if biometrics was deployed purely as a convenience feature without a lot of regard for security. When that Georgia student goes on to bigger and better things his biometric data can be used again, perhaps to authenticate him to his financial institution or to grant him access to a foreign country. Though I’ll admit biometric attacks aren’t trivial, the impact of the attacks are monumental particularly if they allow an adversary to assume the identity of the victim in multiple systems. Imagine the worth of an entire school system’s biometric data. This could include tomorrow’s potential business and government leaders not to mention your average consumer going about their lives. I’m not trying to be alarmist here, but despite multiple discussions of the risks, people don’t seem to be listening. I’d love to be corrected here as the IT guy in me loves the simplicity of biometrics. For the time being though, I haven’t seen a way to avoid the risks.

Technorati Tags: ,

Posted in General Security | 3 Comments »

Pernicious Security

Friday, August 18th, 2006

The rising tide of regulation, vulnerabilities, and exposure of IT security issues means more and more IT folks may find themselves going the way of Todd Acheson and Tom Reid who were both fired after data breaches at Ohio University were exposed. Having spent some time in IT, at professional services firms, and at vendors, I’ve heard plenty of vague allusions to getting fired or not fired by making a bad or good decision around network security. I wonder if anyone is trending this data over time? I would expect as regulation increases, so will unrequested early-retirement.

However, it raises the issue of what techniques can you deploy to protect your network against both the relentless advance of security threats and a similarly relentless onslaught by auditors. The challenge here is that these two aspects may not necessarily be in alignment. What you do to comply with your auditors may not be what is most needed on your network to improve its overall security. However auditors, because of their influence, make things happen in terms of budget allocation and staffing resources. This can lead to pernicious security. Pernicious security is security that seems like a good idea but actually takes resources away from another security initiative that would be more beneficial.

In the NAC space I have to wonder if the focus on posture validation is really where we ought to be spending our time. After all, host-security-controls themselves have the ability to stay up to date and to enforce access restrictions if they are not. Guests can be forced through a restrictive IPS device to limit the damage they can cause. However, the basic foundation of network authentication and authorization of the user is new functionality with significant new benefit: centralized network-wide audit of access, role-based access rights, and guest management. Posture is a great addition to this user foundation but viewing it as the goal itself seems incorrect. As I’ve discussed before, the NAC and authenticated networks space is hard enough without trying to solve the hardest element of it first.

Technorati Tags: ,

Posted in General Security, Network Authentication | No Comments »

Inference-based Identity

Thursday, August 10th, 2006

The AOL-search disclosure debacle is interesting in two ways. First, I’m amused that people are shocked with how easy it is to determine someone’s identity by way of their search queries. Second, I can’t fathom how some faction within AOL thought releasing this data would be a good idea. For some background, The New York Times has a nice article on how a reporter fairly easily tracked down the real-world identity of user 4417749.

But it got me to thinking… Since search history can pretty easily tell you the identity of someone, an IDS / IPS within an enterprise can tell you that and more. These capabilities within IDS and other “big brother” technologies have spawned privacy concerns among their controlled users. “Corporations are not democracies” is the general response: the computer you are using is not your property, nor are the software applications, or the network you access … and so on.

Setting aside what sorts of private things your employer could already know about you based on your network-use, imagine using the same set of data for identity. Let’s call it “inference-based” identity. An inference-based identity system could identify users or devices without their overt participation. Such systems can operate in a very similar way to an IDS. Companies like Great Bay can already do some of this. They determine whether a given MAC address is a Windows PC, a fax machine, a security card reader, or nearly anything else. They do this by increasing the confidence of their classification with each new piece of data they gather until voilá! They make an identification.

Great Bay is doing this to help organizations migrate to 802.1X but a system built specifically for the broader identity problem seems more possible all the time. This would be similar to what Arbor Network’s DoS prevention does with NetFlow, only doing it packet-by-packet with the intention of determining identity information. Each packet or flow inspected would provide clues to the identity of the user and host. IDS certainly becomes more powerful when informed by identity but contemplating an IDS inferring identity is something else entirely.

The trend towards encrypted communication certainly makes this sort of classification harder, but I imagine there’s enough sent in the clear from most workstations to make a clear identification–and to trend that identification over time as users roam on the network. How hard would it be for a network to determine that Tony from accounting isn’t at his normal workstation but is instead using a machine in a conference center? Technologies like 802.1X support mobility through an overt user action today but when paired with an inference-based identity system you could increase security and also deal with non-802.1X capable devices. Any inference-based system would suffer from delays in determining identity as the first few packets from a host are rarely going to be enough to establish a reasonable identity. The false positive problem of an IDS might also appear, but since you are merely using the various bits of information to make a broader identification decision, the challenges might be mitigated. I would expect to see more work in this space in the next couple years.

As an aside, I can’t help feeling that this same data can also be used over time for frightening things. Imagine your employer trending your network access as you do more and more online. They might be able to spot early signs of depression for example. Imagine the phone call from HR, “We’ve noticed a trend in your Internet use which might indicate you could use some help with your personal life. As a caring employer we’d like to do what we can.” Swap out your employer for your ISP or government and things get even scarier. Big brother indeed.

Technorati Tags: , ,

Posted in General Security, Network Authentication | 1 Comment »

NAC Attacked by NAC Vendor

Thursday, August 3rd, 2006

At Blackhat this year, Ofir Arkin (CTO of NAC vendor Insightix) attacks NAC. It would seem from reading some breathless press reports that major flaws and vulnerabilities have been discovered. The first article about this talk is from Dark Reading and was released almost a month ago. Here are a couple more recent from Infoworld, and Internetweek. Though I did not attend Black Hat this year I’ve reviewed Mr. Arkin’s slides. I have a number of problems with this entire brouhaha.

First, why are so few people reporting on the fact that Mr. Arkin works for a vendor which sells network access control products? In the Infoworld article the author makes no mention of this fact at all besides listing the company Arkin works for. Internetweek goes further by mentioning that Insightix is “an Israel-based developer of agentless, real-time IT infrastructure discovery and monitoring solutions.” Dark Reading is the only one of the three which tells the full story:

Not surprisingly, Insightix is offering products that could help close the vulnerabilities in NAC systems. The Insightix NAC solution, introduced three weeks ago, includes a network discovery tool that not only shows DHCP addresses, but static IP addresses and details on how clients and devices are connected to the network.

I’m no stranger to Black Hat–having presented twice–but both times I was listing design considerations in my own company’s products, not attacking my competitor’s approaches. This is grandstanding at its finest and I’m shocked that most of the media reports I’ve seen so far give Arkin a free pass. A quick visit to Insightix’s own website will make it very clear what role they see themselves playing in the industry.

Second, the posturing of this presentation to the press, to the Black Hat audience themselves, and what was actually delivered in the slides is quite different. First let’s compare a snippet from the InternetWeek article with the Black Hat abstract. First Internetweek:

“People need to understand that NAC is not bulletproof and that’s it’s something important that needs to be taken care of,” he [Arkin] says. “They might already have the right solution to handle their NAC issues, but they need to understand where to apply it.”

Pretty level-headed advice. Now the abstract:

Flaws associated with each and every NAC solution presented would be presented. These flaws allows the complete bypass of each and every network access control mechanism currently offered on the market.

Woah! This is clearly more incendiary and absolute in its damnation of NAC as compared with the press quotes. The grand claims in the abstract raise the question: what flaws were found which allow “the complete bypass of each and every network access control mechanism currently offered on the market?” Now again, I only reviewed the slides that were presented and heard from some of the folks in the room so some of this is conjecture (but hey, this is a blog right?). Since I haven’t seen the slides posted publicly yet, I’ll constrain this post to the flaws described in the press so that I can quote directly.

This leads me to point three: the flaws describes in the press–which should be among the juiciest–seem thin at best. Here’s a snippet from Infoworld:

NAC solutions that enforce access through network switches, such as Cisco Systems’ Network Admission Control, also have weaknesses, he said.

For example, Cisco’s NAC technology is specific to their switches and routers, but enterprises often use a mixture of switching and routing gear. Hackers can find their way into an enterprise network simply by finding and connecting through an unmanaged switch, he said.

Stop the presses; security controls don’t work on devices which don’t run them! Mr. Arkin is raising a very valid deployment concern which architects need to be aware of, but it reminds me of a deployment concern raised in the mid 90s around firewalls: If there are paths in and out of your network that don’t go through firewalls than your firewalls can be bypassed. Deployment concerns are not fatal flaws. However, there is a reason Arkin’s talk was titled “Bypassing NAC Systems” not “NAC Deployment Considerations.” First, as I know first hand, the Black Hat conference likes flashy titles. Second, so does the press. This is too bad because for the most part the information in his presentation presents useful design considerations around NAC as well as a substantial section providing an overview of NAC’s different approaches.

To wrap up, when evaluating a security control you should measure it against what you actually want to accomplish with it. As Mr. Arkin points out in his presentation, the definition of NAC is nebulous. Therefore describing ways to completely circumvent it seems confusing, even if he did point out novel techniques to do so. This is because without clear design goals and expectations, any system can be shown to fail simply by changing the target objective. This is why common criteria evaluations need to list what they say they protect against so that the measurement is accurate.

As I pointed out in a brief article from last year on NAC from a Cisco perspective, one of the most basic benefits that NAC can provide is to ensure systems that aren’t actively trying to subvert your security don’t become conduits in the proliferation of malicious code. Now I’m certainly no NAC zealot; I’ve written lengthy posts in the past on some of the challenges associated with NAC and I certainly agree that it has plenty of room for improvement. However, this and other elements of NAC’s functionality, have value which is in no way diminished by any of the “flaws” described at Black Hat. John Stewart, the CSO for Cisco (on the IT side of the company) said it well at the end of the InfoWorld article:

“The technology’s immature. But [NAC] will increase my capability to keep my network in good condition. Can it be maneuvered to have false data? Yes. Would it be completely the case that every device on my network will provide false data? Unlikely.”

“It’s inherently going to be found that there are weaknesses. But I think that’s the wrong thing to focus on. We want to address the weaknesses but focus on the benefits,” Stewart said.

I hope that as NAC moves along the adoption curve we can have level headed conversations about its use in networks and that the press, the vendors, and the researchers work together to find out the best way to protect against attacks. Eric Norlin’s more sober analysis is welcome. Also, I came across a very level headed article from earthtimes.org of all places which ignores the hype and just focuses on the useful info Mr. Arkin did present. This is where we need to head. After all, we all want a more secure network…right?

Technorati Tags: , , ,

Posted in 802.1X, General Security, Network Authentication | 1 Comment »

HP ProCurve’s Paul Congdon Gets It

Wednesday, August 2nd, 2006

TechPlanet Asia has a nice interview with HP’s ProCurve CTO Paul Congdon. The interview covers all manner of things centered around NAC and edge security enforcement in switches. I noticed a couple things when reading the interview. First, HP gets it. Paul’s comments taken together with some positive interactions I’ve had with HP’s Mauricio Sanchez have convinced me they understand the opportunity with edge enforcement and are pursuing it aggressively.

Second, HP seems to be pitching this edge play as somehow different from what Cisco is doing which seems a little more like marketing spin. Cisco wants to do edge enforcement just as much as HP does and Paul’s comment that what Cisco is doing is “taking their peripheral security products, putting it on a blade and then shoving it into a high-end chassis at the core of the network” is just plain false. During my time at Cisco I never specified such a design nor did I know anyone who did. It would be like committing architectural seppuku since even if this is something you wanted to do, network cores–as Paul eludes to–are much too fast. Everything was built around enforcement at the wiring closet / distribution layer and then again at the data-center. The core was always meant to be fast and dumb (with the possible exception of basic security techniques like unicast RPF checks and the like). It is clear that HP is trying to differentiate vs. Cisco with security; it will be interesting to see how they do.

Third, Paul is the first major infrastructure spokesman that I’m aware of to discuss the IEEE’s LinkSec work:

With 802.1AE and 802.1AR, it means that I can create trusted infrastructure in a plug-and-play fashion. So I’ll be able to take a ProCurve product out of the box, plug it into the network, and that box already has credentials built into it. And it can automatically authenticate to its peer switch and then you can bring up an encrypted link and now all the traffic – spanning trees, routing protocols – is fully protected.

It will be very interesting to see how quickly customers embrace the notion of hop-by-hop crypto and what sort of policy infrastructure is required to make it work properly. People are balking at migrating their switch infrastructure for NAC; I wonder if line-rate crypto is more or less attractive.

Technorati Tags: , , ,

Posted in Crypto and VPNs, General Security, Network Authentication | No Comments »

Burton Catalyst Conference

Thursday, June 22nd, 2006

Last week Burton held the Catalyst conference in San Francisco. Besides some good networking and above-average conference food, there were some interesting talks and a couple thoughts worth posting here. First, I was shocked by the size of the identity management track in terms of the space it occupied. There were four tracks running simultaneously on day one and the identity management track seemed to be bigger in terms of attendance and space than the rest of the tracks combined. Clearly this is a hot space getting a lot of attention.

This leads directly to my second observation though; the entire track made no mention of the network and seemed firmly focused on classic application IDM and single-sign-on initiatives. The network security tracks were similarly devoid of much real detail on identity. This confirms what I’ve been seeing for a while, these two sides just aren’t talking to one another enough. This is somewhat surprising given that the notion of federated identity has a natural role linking the network and the application. While federation today refers to linking the identity systems of multiple organizations, a far easier and equally fruitful endeavor might be to link the network identity event with application identity. Whether using protocols like SAML or something more basic, allowing an application to verify the network identity of a user seems useful.

As network transport gets more secure either through VPNs, WPA, or newer initiatives like the IEEE LinkSec work (802.1ae/af/ar) the network identity event could perhaps be used as a proxy for application authentication in certain environments. Even better would be linking authorization systems using protocols like XACML. Imagine an environment where you can author policies in one location for application and resource access and they are enforced by both the network and the application using differing techniques. Defense-in-depth indeed!

Next up was a great presentation by Bob Blackley titled Identity and Community in Human Society. I hope he posts his slides to the web soon as they are quite interesting. Anyone who quotes T.S. Eliot in a presentation is O.K. by me.

Finally there were a few good mentions of 802.1X. Some of the wireless talks seemed to indicate that though there was an even split between VPN and 802.1X WLAN security solutions, 802.1X was the trend moving forward. The talk delivered by a Sun Microsystems employee on their NAC deployment was interesting principally because it provided further evidence that appliances are getting the early traction in posture validation: Sun deployed Cisco Clean Access instead of Cisco’s 802.1X based NAC architecture. Another mention of the various NAC frameworks (Cisco NAC, NAP, TCG-TNC) suggested waiting until a more baked standard emerges before deploying. As I’ve said in this blog before, there are plenty of things that most enterprises need to do to prepare for NAC–starting with just basic user authentication at the network and a consistent means of communicating with their directory infrastructure.

Posted in 802.1X, Crypto and VPNs, General Security | No Comments »

Embedded Network Security

Wednesday, June 21st, 2006

For a marketing guy, Josh Lucas at Extreme seems to really get it in a recent TechWorld article. Though he quotes the bogus statistic of “80% of attacks coming from the inside” his thoughts on the virtualization of security services and the role of 802.1X as “one of the first ideas of how to distribute enforcement through the network” are spot on. I wish Extreme had a bit more of a footprint in enterprise networks today so that their ideas would hold more weight in the standards bodies and in pushing the incumbents to work faster.

Posted in 802.1X, General Security | 1 Comment »

SecureIT 2006

Monday, March 20th, 2006

On Wednesday the 22nd I’m speaking at the SecureIT 2006 conference in Anaheim. The talk’s title is “802.1x: An IT Rorschach Test.” The following is the abstract: “The IEEE 802.1x standard for network authentication has been lambasted and praised, called both a dangerous diversion of an organizations resources and the foundation for the next-generation of user-based network services. But which is it? Early deployments of 802.1x (particularly in wired environments) ran into significant deployment issues which left some organizations soured to the entire notion of a campus authentication event at the network edge. This coupled with the relative stability of alternatives such as IPsec, SSL-based VPNs, and simpler options such as in-line web authentication have stalled installations and even pilots. However, there are organizations who are getting use out of 802.1x today and have managed to successfully roll out the technology in service of their organizations business goals. This talk will explore 802.1x deployment focusing on the lessons learned from both successful and unsuccessful early adopters. The largest challenges such as exception management, supplicant strategies, directory integration, and AAA infrastructure availability will be explored in detail. Additional topics covered include IT organizational issues, integration with other security technologies, and the direction of 802.1x as a technology (including security considerations). Attendees should have a basic understanding of network security including AAA. Prior 802.1x knowledge is not required.” I’m still polishing the slides but will post a PDF of them after the conference.

Posted in 802.1X, General Security | No Comments »

RSA 2006 Observations

Friday, February 17th, 2006

This week my company and hundreds of others descended upon the McEnery convention center in San Jose for the annual RSA show. We had great traffic and managed to have scores of conversations with potential customers and partners. While the fact that I am in this space should serve to temper my enthusiasm, the show was all about identity and controlling it at the network edge. There were many new startups as well as established players talking about security enforcement in the campus through user authentication and endpoint posture checking. This only serves to solidify my thoughts around the emerging role that network identity management will play in the coming years. Writing policies within each of these enforcement devices does not scale long term and will lead to compliance challenges, not to mention excessive opex costs. Centralized user and device policy seems like a much more scalable way to go long term given the desire for consistent user access rights paired with the heterogeneous reality of today’s networks.

Posted in General Security, Network Authentication | No Comments »

Goodbye Plug-and-Play

Thursday, November 17th, 2005

Those of you who’ve been in the IT industry for a long enough time have seen a remarkable evolution in connectivity. The evolution occurred so slowly that perhaps you missed it. Let’s back up to the early 1990s before IP really caught on in the enterprise space. Network engineers—myself included—were running around getting our Certified Netware Engineer (CNE) certifications and spending a lot of time building networks that ran IPX. IPX was a remarkably simple protocol that used a variation of the machine MAC address as the L3 IPX address. If this sounds a bit like IPv6, it should. Both derive the L3 address from the L2 address and make connectivity fairly easy, at least on a local level.

Skip forward to the mid 1990s and we were all enamored with the Internet and the possibilities of TCP/IP. Like me, perhaps you took part in the installation of your company’s first Internet firewall / bastion host. One thing you did, firewall or not, was configure static IP addresses. Lots of them…On every host that used TCP/IP. This is because DHCP didn’t materialize first as RFC 1531 until 1993 (It later became RFC 2131) and didn’t get deployed ubiquitously for a while after that. In that time between IPX and DHCP, configuring these static IP addresses was a pain. The chance of misconfiguration was high, and you tracked all your IP networks in an Excel spreadsheet. You knew that Bob’s IP address was 192.0.2.45 because you hard coded it as such just the other day. If you wanted to write a security policy for Bob, for all practical purposes 192.0.2.45 = Bob.

Static configuration was a particular pain for the network admins themselves who were constantly moving machines around the network for testing and troubleshooting. Since the Excel spreadsheet was invariably a bit out of date and your time on any IP network was limited, you tended to guess an address for the last octet of your machine’s IP address. Sometimes you guessed right, sometimes you guessed wrong and the gratuitous ARP caused your stack to shut down. Troubleshooting network connectivity had to do with making sure DNS was set right, the default gateway was set right, and you weren’t conflicting with another’s IP address. Of course the fact that TCP/IP stacks weren’t built into Windows until 1995 presented other problems that I won’t go into here.

The point of this trip down IT memory-lane is that since the deployment of DHCP we’ve been on a wave of more and more ubiquitous connectivity and less and less troubleshooting per connected station. You move your laptop to another segment, plug in, and get an address that works. IPsec VPNs gave us a small taste of problems as the filtering of ICMP Type 3 Code 4 (Fragmentation Needed and DF bit set) messages by overzealous firewall admins led to MTU issues from the IPsec headers. But for the most part, we’ve experienced a decade or so of fairly consistent connectivity. WLANs just extend the reach of the places you can connect and when combined with home broadband, hotel access, etc. we’ve been in IPv4 connectivity nirvana.

Now you may be wondering whom the villain is in this story and there isn’t one, save progress in general. This time it was progress in security. You see, this ubiquitous connectivity combined with nearly all IP connected stations being Internet connected created a breeding ground for network attacks of all sorts. There’s no need to rehash this except to say the last five years haven’t exactly been in the “Win” column for the good guys.

The latest wave of technology to combat the growth of Internet threats of all kinds is a technology type that I’ll call device posture assessment. Posture assessment products exist or are in development everywhere you look (Cisco, Juniper, Microsoft, TCG TNC, Symantec/Sygate, Consentry, etc.). The basic idea of these systems is to query the state of a connecting machine to see if it is an asset of the organization who runs the network, and if it is up to date with its anti-virus, patch levels, firewall policy, etc. These systems often make use of the RADIUS protocol and slightly less commonly the IEEE 802.1X port authentication standard. While these technologies offer great promise as they mature, they also have the unintended consequence of making troubleshooting basic network connectivity harder than I can ever remember it being. Let’s review the list of things that could be wrong in a normal vanilla DHCP enabled IP LAN:

  • Physical layer problems or device failure
  • Network congestion
  • Host TCP/IP stack errors or misconfiguration
  • Router / switch failure or misconfiguration

    I’m sure I’m missing a couple here but I think I’ve got the big ones. Now let’s look at the list of additional problems introduced in a RADIUS / 802.1X enabled posture checking system:

  • Host 802.1x Supplicant Problems
  • Host / server certificate issues (for TLS based EAP types)
  • Congestion / availability of RADIUS server
  • Congestion / availability of posture server
  • Misconfiguration of posture policy rules on server or endpoint
  • MAC address or other device ID not in database
  • Username / password expiry
  • EAP-type / crypto protocol mismatch
  • VLAN assignment / DCHP release – renew problem
  • Port ACL misconfiguration

    Companies who have been delivering these capabilities to the market have been focused on the basic functionality, which has left troubleshooting under developed. This reality has not escaped the notice of magazine reviews but the focus of these articles has been mostly evaluating the promise of the security capability and not taking a serious look at the realities of deploying this in production. Take another quick look at the list of potential problems above. Imagine a caller coming into your help desk complaining about something not working. Now imagine the steps you’d go through trying to figure out what might be wrong.

    The moral of this story, if there indeed even is one, is that while these posture checking technologies offer great promise, we’re still in the land of the bleeding-edge with respect to production deployment. Organizations looking to deploy should first evaluate the robustness of their management infrastructure and the troubleshooting tools that the vendor will provide. Since most of these techniques make use of RADIUS and 802.1X perhaps trying to get those technologies deployed for simple user or device authentication provides a more tractable problem in the near term. As the posture offerings settle down and mature you’ll have set the stage by building out a robust AAA infrastructure to handle whatever standards (de facto or de jure) eventually emerge. The next couple years should prove quite interesting for network connectivity, I look forward to seeing how it all shakes out.

    • Posted in 802.1X, General Security, Network Authentication, RADIUS | 1 Comment »

    « Older Entries
    Newer Entries »