Archive for the ‘General Security’ Category

IPv6 And Security Architecture Changes

Monday, March 31st, 2008

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

2007 Conjecture Conclusion

Wednesday, January 16th, 2008

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

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: