Sean Convery

I received a reader email asking if IPv6 is going to change the existing approach to security. He writes:

Do you believe that the transition to IPv6 will change the existing security architectures? I have heard from other professional architects, that there will be a transition from perimeter security to host-based security.

While the paper Darrin Miller and I wrote is the best place for a complete answer to that question, I can provide a quick summary and some clarification. Here’s the section on maintaining host and application security from the bottom of page 23:

Although timely patching and host lockdown are critical elements in IPv4, they are even more critical during the early stages of IPv6 because many host protections (firewalls, IDSs, and so on) do not yet broadly support IPv6. Additionally, it is highly likely (though testing is necessary; refer to Appendix A) that the initial introduction of IPv6 into networks will result in some hosts not being properly secured. It is necessary to focus on maintaining host security to ensure that hosts that are compromised will not become stepping stones to compromise other end hosts.

There’s also some information in my book on IPv6. It starts on page 668, which is available on books.google.com.

I actually think the move toward identity-based controls (whether IPv6 or IPv4) will have more of an impact on security architecture than the transition to IPv6 will. The network will remain important as a security control–as will the endpoint–but the shift will be towards more dynamic authorizations based on the the identity of the individual. IPv6 leads to subtle changes in the security architecture and I agree that endpoint controls will increase in importance; I don’t think that network controls will go away though. Security has always been about defense-in-depth and relying only on the host for security puts all your security eggs in one basket.

Technorati Tags: IPv6, security

My 2007 predictions are, of course, now open to criticism. I figure I’ll call myself on some things preemptively and then folks can give me some feedback via comments.

1. “NAC as a term will grow out of favor…” As I said last year, some of these are tough to measure but I think at least a B on this one is appropriate. NAC as a term is growing out of favor and/or morphing in meaning. The definition has shifted away from pure endpoint security controls and more towards identity. So even when the NAC term is used, it means something more today than a year ago. As another data-point, take Cisco’s marketing introduction of TrustSec for example. In their white paper describing the proposed solution the word “posture” appears four times, the word “identity” appears 12 times, and the acryonym “NAC?” Zero.
2. “One of today’s NAC vendors will go under…” This one is clearly an A, Caymas shut its doors in the first half of last year.
3. “One of today’s NAC vendors will get acquired by a larger firm…” AV vendor Sophos picked up NAC vendor Endforce in January so this is another clear-cut A grade. I expect more consolidation in 2008.
4. “An open-source 802.1X supplicant will emerge as a viable alternative to commercial and OS-native supplicants…” OpenSEA was announced, has garnered wide industry support, and is set to find its way into multiple commercial offerings (see my previous posts on this topic). My company was a founding member and we’ve seen lots of participation in the group. JANET(UK) is in the midst of testing the client and has a user-base of 18 million. Though the supplicant is not yet GA, I expect that soon. Given all this an A might be appropriate but I think given where customers are with their production Xsupplicant deployments a B is a safer assessment. As an aside, momentum for Xsupplicant going into 2008 is huge.
5. “Wired 802.1X turns the corner from rare occurrence to early-adopter chic…” I don’t have any objective data to draw from yet but I think this is happening now. At my company we’re seeing much more interest in wired 802.1X; with wired you now authenticate everywhere and so role-based access control (RBAC) is completely viable. That said, I expected more production deployments by now so a B seems fair.

Technorati Tags: 802.1X, NAC, security

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: Identity Management, security

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

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

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: NAC, security

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