Archive for the ‘General Security’ Category

Market Acceptance of Wired 802.1X Improving

Monday, September 24th, 2007

Well besides all the good news on the open supplicant front, it has been a while since I mentioned 802.1X adoption in general. We’re certainly seeing more interest in wired 802.1X at my company but it is seen often in the news these days as well. Here are a couple examples: first up is Intel adding hardware 802.1X support to its latest motherboards (the implications of this on virtualized OS instances could be interesting). And second, Linksys is expanding its low-end SMB line into the security arena with support for 802.1X. This adds more evidence to my contention that the core enforcement capabilities in network infrastructure are becoming commodities. I firmly believe that the future of network security will not be about more sophisticated packet inspection or manipulation techniques but rather the intelligent control of the methods we already have.

Technorati Tags: , ,

Functionality Forgoing Forklifts

Wednesday, August 15th, 2007

My favorite techno-contrarian Nick Carr has a post linking to an article he just had published in Director magazine. It contains 10 common-sense approaches to reducing IT costs. Many of his points are good but in particular I want to confirm a growing trend he calls out: customers’ general distaste for significant infrastructure migrations. More and more, companies want to take advantage of what they already have. He writes:

Since then [2001] exciting new technologies have also emerged that have allowed businesses to use their existing IT equipment more effectively and avoid buying new gear. Suddenly, companies are finding they can cut their IT budgets and still have the computing capabilities they need. Smart IT management is all about getting more for less.

As I talk to customers about identity management for networks many of them approach it assuming that a new overlay network is not an acceptable solution. They are looking for a layer of intelligence to let them take advantage of what they already have in place, even if their LAN infrastructure is a few years old. I expect this trend to result in more challenges for the nascent inline LAN security market beyond Caymas’ closure. I’ve been maintaining for a while that we’ve got most of the core packet processing capabilities that we need, now it’s all about intelligent management of our existing investment.

Technorati Tags: ,

Reconstructing Fingerprints Used in Biometrics

Thursday, August 2nd, 2007

Dr. 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:

More Biometrics Bad News

Wednesday, August 1st, 2007

To 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:

On Standards and Startups

Wednesday, June 13th, 2007

With 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.

  1. 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.
  2. 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.
  3. 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.

Technorati Tags: ,

(IdM-N) + (IdM-A) = IdM

Wednesday, May 2nd, 2007

Eric Norlin responded to my Identity Management for Networks post with some thoughts of his own. It sounds like we are mostly on the same page (i.e. he agrees sticking the “N” or “A” at the end might help) however he did point out some real challenges to the merger of the two spaces:

Sean sees identity management becoming a “single entity.” I’m not as optimistic. There’s an awful lot of legacy to get through here — legacy of job titles, legacy of how software and networking companies are organized, just plain legacy. Will IdM-N and IdM-A products and suites have to learn how to be intertwined? Absolutely. Will they merge? That sounds like a ten year job to me.

I actually think we agree here more than we disagree. I absolutely agree that this will take a while, perhaps not 10 years, but certainly more than a couple. Eric’s post and my conversations at the recent NAC conference got me thinking about the phases of integration. This certainly isn’t a binary switch-over and I doubt we’ll want to get to one solution from a vendor that addresses all your identity needs. Hopefully Eric will chime in here as I’m guessing I’m missing some steps, but these are the big stages of integration that jump to mind.

  1. Networks and applications use the same back end directory for user authentication. I think we’re mostly here now, or very close to it. Whether it be through a meta / virtual directory or direct to an AD or LDAP store, the customers that I’m engaged with either are already using a single directory infrastructure or are rapidly moving toward it. Of course bridging across multiple directories, groups, and attributes will remain critical, but this will be pain experienced equally by the applications and the network.
  2. Networks and applications trigger authorization policy based on the same groups and attributes. This isn’t yet happening consistently within applications so it certainly isn’t happening consistently between networks and applications. Getting this to happen has a lot to do with step three, below.
  3. HR user provisioning systems create one user record which automatically has associated application and networking rights. This is another place where we have work to do. Today an HR provisioning system from one large vendor might only deal with rights and authorizations for that large vendor’s applications and not the rest of the infrastructure’s needs. However, creating the right workflow so that, say, the HR system can define a user as an employee, privileged employee, or contractor would allow the network to inherit those authorizations and enforce them within the network context.
  4. Network and application policy decision points (PDPs) share policies or audit information. This is another area that needs lots of work. Standards like XACML make this easier, but there still needs to be a defined schema for the attributes and an understanding of why the policies would be shared. Two easy examples would be one, allowing an application to query audit data within the network to see that a given user has a secure network connection before granting access to a sensitive area. The second is the application PDP informing the network of the systems the user has access to; the network could then prevent IP connectivity to disallowed applications. (Note: server virtualization will make this tricky.)
  5. A single PDP brokers policy decisions for networks and applications. I doubt we’d ever get here for all network and application requests (nor would we likely want to) but it seems likely that subsets of applications and networks will share a common PDP. This PDP could then share policies with other PDPs inside or outside the organization.


So as I was saying earlier, this isn’t going to happen all at once. I’d also expect different organizations to go different lengths down this road based on their culture, politics, and business needs. In general based on my dealings with customers, there is a definite desire to make this happen primarily for business efficiency and compliance.

Technorati Tags: ,

A Conference Vijay Would Love

Saturday, February 10th, 2007

It is always interesting to see the entire security vendor community come together and parade their wares at RSA each year. If I put myself in the role of a potential customer, this week saw a dizzying array of vendors, many of whom were chasing the same industry buzzwords. The buzzwords of this conference, just based on my own observations, were:

  • NAC – NAC continues to be a term lacking a comprehensive and agreed-upon definition. As a result, many vendors were claiming NAC support–often with a specific spin based on the capabilities of their company.
  • Data Leakage – Companies attempting to protect data from being inadvertently disclosed were on the rise. It seems nearly impossible to prevent a dedicated adversary from disclosing data she has access to, but simple tagging mechanisms to prevent the accidental “reply-to-all” may be useful.
  • Compliance – The Infosec equivalent of a trump card when it comes to purchasing decisions, it seemed almost every vendor touted help with regulatory compliance as a feature of their products.
  • Policy – Another overused word (without qualifiers) many companies touted policy features.

I suppose this list of buzzwords means a single new startup, focused on all four areas, could probably get a nice batch of seed money from an unsuspecting venture capitalist. I can imagine the pitch now… “Our intuitive UI lets you craft complex policies to define data leakage protections correlated with the NAC status of an endpoint, all with rich ties to compliance reporting for export to an auditor.” I’m sure Vijay, the world’s most desperate venture capitalist, would jump on board.

Technorati Tags:

RSA Conference Next Week

Friday, February 2nd, 2007

Just a quick note to remind folks that next week is the RSA Conference in San Francisco. I’ll be up in the city much of the week and would love to chat with anyone who reads this blog. My company is in booth 430 and I’ll be around there much of the time. If you’d like to chat, drop me a line or swing by the booth.

On another note, sorry about the lack of posts of late. I was working against a publishing deadline which I’ve now met. I’m sure RSA will provide plenty of fodder for future posts. Last year’s RSA was all about NAC, this year it will be interesting to see what the buzz-leader is.

Technorati Tags:

IPv6 Security Update

Monday, January 8th, 2007

Happy New Year everyone! I hope that folks had a great holiday. I thought I’d start off 2007 with a bit of an off-topic post.

Back in 2004 Darrin Miller and I did some work looking into IPv6 security. The major result was a paper describing the various security considerations in IPv6, setting aside IPsec. At the time, the majority of the research we saw was looking at IPsec as the principle means of securing IPv6. Since IPsec support is a “standard” feature of IPv6, this was a reasonable assumption. As it turns out, for various reasons outlined in the paper, this wasn’t such a good idea. The paper was well received and even found its way into some US-CERT recommendations, and was largely reused as chapter nine of Deploying IPv6 Networks.

Fast-forward almost three years from then and some things have changed and many others haven’t. The IETF v6ops working group is still churning out some new docs on the subject which is great. However, just like in 2004, the market seems to be ignoring IPv6. Not even a federal mandate to deploy v6 in the government by 2008 is enough to get things going. GCN recently reported as much, highlighting agency concern that security vendors aren’t migrating their products to IPv6 quick enough.

I’ve not done a lot of poking around in IPv6 security lately. In preparing for this blog post I went through and updated my IPv6 security links page to tag any additional dead links and add a few new ones. The fact that this links page–largely untouched since 2004–returns in the top five results of a google search for “IPv6 security” says more about the attention paid to the subject than a lengthly blog post ever could have. The top result is a presentation (from a former colleague at Cisco) that Darrin and I expanded on in our work. Eric did a great job with that presentation but given the governement’s focus on IPv6, I would have guessed research from 2003 would not be so well ranked.

Technorati Tags: ,

Pogue’s Poor Position on Privacy

Thursday, October 12th, 2006

New York Times journalist David Pogue recently posted about a cool service which is giving away free international phone calls. He then got a fair amount of comments from folks worried that this service might be giving away the calls for a more nefarious purpose such as data mining. I love Pogue’s posts and articles in The Times but I think his response to these comments was a bit short-sighted. He gets some things right when he talks about the privacy we’ve already sacrificed in our daily lives, but he gets it wrong when he describes the value of, for example, listening in on phone calls:

All of the much smaller potential abuses make a whopping assumption: that somebody actually *cares a whit* about you and your mundane daily communications. Yes, of course someone at the phone company could look over your phone records and figure out whom you call. But who would ever be so bored, and–forgive me–what could ever be so boring?

True enough for mundane communications. However, what’s a mundane checking of your bank balance to you is instant identity theft for an adversary. If network security taught us anything it is that an attack which is trivial to manually execute is usually trivial to automate. Imagine someone selectively tapping calls only to a bank’s customer service phone number? How many account numbers, mother’s maiden names, birth dates, and–at least portions of–social security numbers could be harvested? If you went without any voice analysis at all and just listened for the touch-tones you’d already have a wealth of information. Think dsniff for telcos.

Pogue is right however with respect to this specific service. There is nothing new to worry about. We’ve had plenty to worry about all along. Whether that worry is “neurotic” as Pogue describes, I’ll leave to my readers. I’d use voice encryption if it was an option, but until it is I’m not changing the way I live my life.

Technorati Tags: ,