Sean Convery

OK, last post today…I think:

Speaking of hard computing problems, according to Wired’s Danger Room blog, robots with machine guns have now been deployed in Iraq. These robots (dubbed special weapons observation remote reconnaissance direct action system [SWORDS]) have not fired yet but:

Michael Zecca, the SWORDS program manager, tells DANGER ROOM. “But that’ll be happening soon.”

Speaking as someone whose seen commercial security systems fail repeatedly during my time in the industry, I certainly hope their software is better than our software. Something tells me that there isn’t a “powered by Windows Mobile” sticker anywhere on the bot. However, with commercial OSs performing more and more functions for the government, it doesn’t seem completely outside the realm of possibility.

Setting the ethical implications aside of turning war into a game of network Doom, the repercussions of a crypto or software failure in the transmissions from the controller to the bot are enormous. I wonder what they are using and what sort of testing they underwent. I wouldn’t be surprised to see some security through obscurity in there somewhere. On a related note, Steven Murdoch over at Cambridge has an interesting post explaining why software problems are as big or bigger than crypto problems in e-voting systems. The same applies here as well (note his mention of rocket launches):

Good software engineering is necessary but, in the case of voting systems, may be especially difficult to achieve. In fact, such systems have more similarities to the software behind rocket launches than more conventional business productivity software. We should thus expect the consequential high costs and, despite all this extra effort, that the occasional catastrophe will be inevitable.

Technorati Tags: biometrics, security

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: Cisco, HP Procurve, Linksec, NAC

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.

Network World Magazine recently ran a review of Cisco’s new ASA 5500 SSL VPN technology. Nestled in the review are a couple great tidbits about why direct integration between user directories and network infrastructure devices is a bad idea, and why the flexibility of your authentication infrastructure is key to allowing user AAA to work as promised by the tenets of NAC.

In our authentication and authorization tests, we discovered that while the ASA claims to support Active directory and Sun’s Lightweight Directory Access Protocol server, it didn’t support our schema of the Sun LDAP server. When we tried switching over to our SecurID RADIUS server, we discovered that Cisco fully supports the additional RADIUS messages required to integrate with SecurID.

However, Cisco had no flexibility in mapping users to groups, and would have required us to change our existing RADIUS schema, breaking all the other applications plugged into SecurID.

The two critical bits of learning here are first that in real-world deployments, schemas are rarely designed to support the network infrastructure device and often they are non-standard. This is one of the many reasons why direct integration from the network infrastructure device to the directory is architecturally a bad idea. The fact that this was exposed even in a test environment simply magnifies the concern. Second, many current RADIUS servers simply lack the capability to integrate the directories and network devices with the flexibility required by today’s deployments. Interconnecting between ethernet switches, firewalls, VPN gateways, wireless APs, dial-up servers, and Microsoft Active Directory, LDAP, and token servers requires approaching the policy-based AAA problem in a new way.