I’m sure most folks have probably seen this already–as Bruce Schneier blogged about it–but I’ll post it here just the same; it is just too darn funny: Matt Blaze has a new game.
Security Excuse Bingo
August 13th, 2007Unwired at Nortel
August 3rd, 2007John Roese, Nortel’s CTO, has a nice post on why he thinks we are almost at the point where enterprise network infrastructure can go wireless only. He’s careful not to say we’re exactly there now, but certainly sees Nortel as a leader in this space. He writes:
It is our position that, after a decade of evolution, both Wi-Fi and broadband wireless (4G) technologies are getting close enough to the expectations of the customer that we are becoming able to build the Unwired Enterprise from an access perspective.
I’m seeing this as well, though I think wired will be around for a long time to come. At Identity Engines, we have a prominent enterprise customer that finally decided to deploy wired at a new facility only because the VoIP quality wasn’t yet there for wireless. Furthermore, our experience in the education market shows that wireless only is already here in principle for many university students and staff; these university users frequently never connect to the wired network, even in their home location. The next several years will be interesting indeed, Roese thinks they might even shift the vendor landscape:
This is great for mobility and productivity from a customer view, but it is also an inflection point that can force a re-thinking of the enterprise LAN architecture. That is something that happens very rarely but, when it does, the market can be remade and the vendor landscape can be transformed.
I tend to agree but I think it might cause more of a trend towards commodity, standards-based, network infrastructure coupled closely with robust identity management for the network. Then again, I could be a bit biased in this regard…
False Positives at 725 Rounds a Minute
August 2nd, 2007OK, 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
Facial Recognition Accuracy
August 2nd, 2007Since my last two posts have been about biometrics how about one related concerning crowd facial recognition? Bruce Schneier points to German test results (in German):
Two hundred frequent travellers volunteered to have their faces recorded and three different systems tried to recognize the faces in the crowds of a train station. Results (in German): 60% recognition at best, 30% on average (depending on light and other factors).
Facial recognition in a crowded public place seems like an extraordinarily hard computing problem to solve. Oditogre, an early commenter to Bruce’s original post raises an interesting question:
Google translator mangled it pretty badly, but I got the gist enough that it didn’t seem to say how many false positives there were. That would be the biggest issue, to me. If they can achieve 30% recognition rate with 0% false positive rate, that could well be a very effective system for catching fugitives, but otherwise, it’s just going to be a bad waste of money.
I personally don’t see how you can have a 30% success rate with zero false positives. Network IDS systems can’t prevent false positives and they’re working with binary data. Later on in the comments it appears that the false positive rate was .1%. While this may seem good, imagine how many folks will walk past a particular point in Times Square today or the Otemachi metro station in Tokyo.
Technorati Tags: biometrics
Reconstructing Fingerprints Used in Biometrics
August 2nd, 2007Dr. Terry Boult, of the University of Colorado Vision and Security Technology Lab, responded to my last post with some excellent research that is much more current than the paper I originally mentioned. I haven’t had time to drill into all of it but the first paper from Arun Ross, Jidnya Shah, and Anil Jain entitled From Template to Image: Reconstructing Fingerprints from Minutiae Points was very interesting. Based on my cursory examination, it seems to confirm the 2003 paper’s hypothesis that reconstructing biometric data is possible for other types of biometric systems beyond those employing facial recognition:
The salient feature of this noniterative method to generate ridges is its ability to preserve the minutiae at specified locations in the reconstructed ridge map. Experiments using a commercial fingerprint matcher suggest that the reconstructed ridge structure bears close resemblance to the parent fingerprint.
He also points to some research on “cancelable biometrics” including a paper of his own (link is dead for some reason). The IBM Exploratory Computer Vision Group has a brief description of how one system works. The full paper can be found here. In short, the system seems to distort the original biometric in a repeatable way so that each time the biometric is entered it is only stored in its distorted form, never in its original form. If it gets compromised you can issue a new biometric “distorted” in a different way. I haven’t looked through the other papers yet but if they work similar to the IBM proposal I have some questions.
I’m not sure exactly how this is different from the “template” of a normal biometric except perhaps that the user could control the process? Assuming it is different, the problem I see is how do you know whether the biometric system you are using supports this capability? Say your OS supported this function but your bank or government didn’t. If you are using fingerprints for all of them we’re back to the same problem that Dr. Boult calls the “biometric dilemma.” Also, doesn’t the biometric scanner need to keep your biometric data originally (even if only briefly) in order to distort it? If so, we’re back to my “perfect system” assumption.
It still seems to me that the way to truly revoke a biometric has more to do with medicine and surgery than it does with information technology. I look forward to getting better educated on this in the future and I’m glad to see research underway.
Technorati Tags: biometrics
More Biometrics Bad News
August 1st, 2007To the surprise of–I’m hoping–fewer and fewer people, Andy Adler at the University of Ottawa has published a paper showing how the digital template of biometric data can be reformed into a close approximation of the original biometric data. The example uses facial recognition but according to the paper, “While results are demonstrated for face recognition algorithms, the conceptual framework should be applicable to any biometric algorithm.”
Kim Cameron’s blog pointed me to this, though the paper’s header seems to indicate it was published in 2003. Late last year I revisited my thinking on Biometrics here; it all still applies. Any security system will have vulnerabilities of some sort or another. One of the considerations though, is what the impact is of any single vulnerability. With biometric systems, because the same biometric data can be used in multiple places, the impact could well extend beyond the exposed system. This makes the security of your biometric data only as strong as the weakest place that stores it. When that reality is coupled with the truism that you can’t revoke your biometric data, we wind up with a real problem.
Technorati Tags: biometrics
AAA in IPJ Part 2
July 9th, 2007Part two of a two-part article titled Network Authentication, Authorization, and Accounting was just published in the Internet Protocol Journal. I wrote the article to be a survey of the entire AAA space and so it covers a lot of ground without spending too much time in one place. If you are new to AAA or are looking for a conceptual model of AAA to help others grasp its concepts, please take a look. Here’s a snippet:
Network Authentication, Authorization, and Accounting has been used since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And finally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. The first part of this two-part series focused on the overall concepts of AAA, the elements involved in AAA communications, and high-level approaches to achieving specific AAA goals. It was published in IPJ Volume 10, No. 1. This second part of the series discusses the protocols involved, specific applications of AAA, and considerations for the future of AAA.
Although AAA is often thought of as the exclusive province of the Remote Authentication Dial-In User Service (RADIUS) protocol, in reality a range of protocols is involved at various stages of the AAA conversation. This section introduces these AAA protocols, organized according to the parties involved in the communication. We divide AAA communications into the following categories: Client to Policy Enforcement Point (PEP), PEP to Policy Decision Point (PDP), Client to PDP, and PDP to Policy Information Point (PIP).
Multi-touching my EAP Type
July 6th, 2007My fellow OpenSEA colleagues Messers Oltsik and Gast have both recently pointed to the need for more 802.1X support in non-PC devices. Last year I made a post indicating that support seemed to be improving and I certainly agree that OpenSEA can help accelerate this. The iPhone is definitely a step in the other direction though. As Matthew points out, Mac OS X already has a native supplicant and the iPhone supposedly runs Mac OS X. I’m guessing this is more a matter of QA resources butting up against launch plans than anything else; my iPhone’s browser still crashes from time to time which certainly seems like a higher priority.
I wonder how sensitive the multi-touch interface is? It would be interesting if you could record guestures as a way to access a password wallet. The iPhone keyboard does a great job of correcting common English language mistakes but it is quite horrible at entering passwords like dkIH$l_73n!.
On an unrelated note, seeing that Matthew is using the same WordPress default template as I am left me feeling sheepish. As Jack says about Marla in Fight Club, “Her lie reflected my lie.” Oh well, none of you really suspected I had any HTML skills I’m sure.
Technorati Tags: 802.1X, Supplicant
On Standards and Startups
June 13th, 2007With the news that inline NAC vendor Caymas Systems has gone under, questions from the customer base are bound to come up about the merits of buying products from startups. Time Greene over at Network World has been following the story and has a quote from just such a concerned customer. Kim Hansen at the City of Sioux Falls said:
I can guarantee you that our next SSL vendor will be based on size and dollars, and not just features and ease of use. I need a company that is going to be around in the long run.
Working at a startup myself it is easy to be alarmed by Hansen’s comment. I even sat on a panel at DIDW with Sanjay Uppal, Caymas’ former CEO. There are a few lessons here for vendors and customers alike looking at the startup space.
- Demand standards - I can’t tell you how many times I’ve used IDE’s support of standards to mitigate concerns with deploying technology from our relatively young company. While this certainly can’t completely save you if a startup fails, it does improve the odds that you can salvage some of the work you’ve done if you ever need to find a replacement. Real customer loyalty comes from executing on standards better than anyone else, not from locking folks in to proprietary solutions.
- Be extra diligent with data-plane solutions – Caymas’ product sits inline to the flow of network traffic. By offering advanced firewall capabilities and hardware-accelerated traffic inspection, products like Caymas add new functionality over and above what most customers have in their existing infrastructure. However, this technology often comes at a steep cost in up front dollars and ongoing support and administration. I’ve gotten feedback from a number of customers who are wary of new inline solutions. Part of it is Hansen’s newfound concern, but another part is just the comfort level of putting a brand new vendor, regardless of their reliability, inline within an existing functioning network. The “if it ain’t broke…” adage seems to apply here. Control-plane solutions that leverage functionality on existing infrastructure gives you a natural escape valve; you can always turn the new feature off and be right back where you were.
- It isn’t about the awards – Caymas, whose website was still up at the time of this writing, has a whole bunch of awards from the likes of Forrester, Gartner, and Infoworld. These types of awards are designed to encourage a customer to buy a product, and make them more comfortable with that decision. A better metric for the skeptical IT buyer is customer count and growth path. How many customers have bought the product and deployed it in production? What is the growth tragectory in the customer count since the company first shipped product?
Walking away from startups completely will limit any company’s ability to solve leading-edge problems quickly. While sticking only with established vendors is a choice some companies make, you sacrifice a lot by doing so: not only do you lose the technology advantages of the startup, but also the enhanced responsiveness of a startup to your organization’s specific needs. Startups can play a role in most organization’s networks, they just need a bit more attention to the purchase decision than selecting the offering from your favorite giant vendor.
ACLs for Everyone!
June 12th, 2007The IETF draft I’ve been tracking that defines a common format to communicate IP ACLs via RADIUS is now an official RFC. 4849 has a nice ring to it, hopefully it will become part of the networking and security vernacular like 1918 or 2827. Remember the RFC doesn’t mean anything until the industry builds support into its products. If you are a customer of Cisco, Juniper, Nortel or any other networking vendor I encourage you to ask for RFC 4849 support as soon as possible. Supporting it makes sense in almost all access devices: firewalls, wired switches, WLAN APs, and VPN gateways. Enabling role-based access control throughout your network is becoming less of a dream each day; RFC 4849 gets us one big step closer by defining a mechanism to support ACLs in heterogeneous network infrastructure. Here’s the abstract, scary that I get excited by this stuff:
While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588.