<![CDATA[[SecurityRatty] tag: ietf]]> http://securityratty.com/tag/ietf Fri, 21 Mar 2008 22:39:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[A Security Assessment of the Internet Protocol]]> http://securityratty.com/article/ebac4e1107d0d958cc5b67c257c5ea71 http://securityratty.com/article/ebac4e1107d0d958cc5b67c257c5ea71 Interesting:

Preface

The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them.

While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.

Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.

The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.

As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.

Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.

There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.

This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.

Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.

]]> Wed, 20 Aug 2008 03:48:56 +0000 internet assessment security assessment security security flaws flaws internet technology internet operations community protocols A Security Assessment of the Internet Protocol <![CDATA[Top 5: Why Customers Consider NAC]]> http://securityratty.com/article/83f7c84a6d60d185873164921594ef4d http://securityratty.com/article/83f7c84a6d60d185873164921594ef4d On a daily (and nightly) basis I have the wonderful experience of talking to, chatting about, presenting on or asking questions of customers about NAC.

At each of these opportunities, I like to ask ‘Why are you considering NAC?”

Here’s my Top 5 of Why Customers Consider NAC (or think they want NAC). This is not based on any other organization’s research or polls, nor is it based on analyst analysis. It’s not based on forethought or musings of an ‘expert’. It’s just my personal experience from my daily interactions.

#1: Endpoint Compliance
I put this one first, because I think it’s the most-hyped and possibly least significant. I know, that’s harsh, especially when endpoint compliance seems to be the big bat NAC carries around. Truth be told, it’s more of an ‘icing on the cake’ for the people I talk to. Until the auto-remediation features are a little more mature, the idea of checking for much beyond presence of anti-virus and possibly patches is unattractive. Frankly, endpoint compliance for LAN-based devices can be a Charlie Foxtrot except under the most ideal circumstances. There are many large organizations and DoD groups that need endpoint compliance, and that’s a primary driver for them. For the rest, one of the other reasons below is a primary compelling feature and endpoint checking is just another knob they can play with.

The lack of fervent interest in endpoint checking is why I had to disagree so strongly with Stiennon’s when he advises in his NWW article “Don’t even bother investing in NAC”. The entire premise of his issues with NAC center around various endpoing checking. (You can check out Shimel’s response  too Stiennon’s blog here.)

#2: Guest Access
Believe it or not, the most frequent response I get for “why are you considering NAC” is “guest access”. Guest access seems to be a thorn in every organization’s side. It’s a simple problem with impossibly complex solutions… or so they think. For years, we’ve been provisioning safe and secure guest access for customers with the use of clean and simple protocol-less VLANs and so, I know that about 82% of the time, there are much simpler ways to offer guest access than by rolling out a full NAC implementation. If guest access is your primary and only goal with a NAC solution, there’s probably a better, faster and less expensive solution. If money and time are no object, then NAC can be a good way to get from point A to B and give you a few fun technical trinkets to play with.

#3: Edge Port Security
After guest access, the next thing I hear most is interest in adding edge port security with a 802.1X NAC solution. (We call this Layer 2 NAC.) I tend to think for the time being, this is NAC’s sweet spot. Note I said ‘for the time being’, I think this may change in the next 18-24 months. But for now, the ability to lock down edge ports and secure switch-to-switch links is an extremely attractive feature. Outside of the 802.1X protocol, there aren’t really any other ways to skin this cat. I know what you’re thinking… you don’t have to do NAC to use 802.1X… and that’s certainly true, but for a network of any size, NAC makes an 802.1X implementation easier to manage and monitor centrally and gives you more of that NAC icing we all love.

When the 802.1X-REV comes out (probably early 2009) I think you’ll see organizations that have previously blown off 1X seriously considering it for all the added security and multi-user support it will bring to the table.

#4: User & Resource Accounting
Unless you have a 3rd party solution or want to dig through mounds of RADIUS syslogs, you probably don’t have a good way to account for user authentication and accountability of resource access throughout the network. Most vendors’ NAC solutions already have pretty good logging and reporting features built in today. Depending on the solution and integration of other devices, you may even get detailed accounts of which user viewed exactly what, when and from where. This is a great selling point to organizations that are trying to follow strict regulations for accountability of financial or extremely sensitive resources. The standards bodies (IEEE, TNC framework and IETF) are coming out with more and more ways to leverage 3rd party security devices within NAC. The IF-MAP is a great example and we’ll be seeing more I’m sure.

#5: Dynamic VLAN Assignment
Lastly, but not least, I hear a lot of customers that are looking for a good way to dynamically provision attributes, such as VLAN assignment and QoS to users or devices. It makes switch configuration and management much simpler, and eliminates the need to assign port-based VLANs. The ability to leverage your existing user directory and define both broad and very granular attributes is certainly a draw, and NAC is a great way to offer that.

That wraps up my Top 5. Of course, there are plenty more drivers, both business-based or technology-based, but these are the 5 I hear most.

# # #

]]> Sat, 31 May 2008 18:10:33 +0000 nac solution 3rd party solution nac solution bat nac carries nac center vendors nac solutions offer offer guest access Top 5: Why Customers Consider NAC <![CDATA[Internet Protocol Version 6]]> http://securityratty.com/article/de3abd31ad8fcfc01fcd4cc0d0b6ccef http://securityratty.com/article/de3abd31ad8fcfc01fcd4cc0d0b6ccef ]]> Thu, 22 May 2008 10:32:02 +0000 distinguish ipv6 ipv6 world wide web technical features task force government internet ipv4 not-so-distant future Internet Protocol Version 6 <![CDATA[Stiennon says NAC is dead - I must be in heaven!]]> http://securityratty.com/article/303363943cb0483159b85ed27a6dd94a http://securityratty.com/article/303363943cb0483159b85ed27a6dd94a That gadfly of the security world, Richard Stiennon says NAC is dead. In fact he says NAC actually never was and never will be. Of course, this is the same Richard Stiennon who said IDS was dead so many years ago. If NAC is only half as alive as IDS has been, I would be very happy. Why do I call Richard a gadfly? Because Richards MO is trying to find what the next hot thing is and to jump on it, then another hot thing comes by he runs to that and so on and so on. He thought anti-spyware was big and joined Web Root, after a relatively short time there he left. He than took a whirl at his own analyst firm, when a few others were forging a new breed of analyst firm and after a short time doing that moved on again. He then was CMO at Fortinet and again after a short time left there too. Now he is the CEO of an MSSP (hey, I hear SaaS is the next big thing), how long this will keep his attention or the powers that be keep him on is anybodys guess. But if past track record is any indication, Richard will hop on the next big thing sometime next year. I mention this because fundamentally I think Richard's attention span or maturation horizon is why he does not see that NAC is marching on.

As you can probably guess I strongly disagree with Richard's opinion on this one. However, to understand why, some clarification is necessary:

1. Richard is mixing metaphors with Network Admission Control and Network Access Control. Both are NAC. Admission control was coined by Cisco, access control was first used by Gartner I believe. Richard seems to indicate that admission control is bad, access control or at least some definitions of it are OK. More importantly, Richard uses admission control as a code word for pre-connect health checks, access control for identity based and post-connect control. I think both are very important and as I have said many times a good NAC solution needs all of these.

2. NAC vendors being depressed, etc. Yes Richard some NAC vendors not making it are depressed and having lay offs and hard times. That is the way of capitalism and competitive markets I am afraid. There are winners and losers. I would bet that even in the $500 million /year UTM market that you spent a whole year in, there are some vendors who are just not making it and would be classified as depressed.

3. Gartner says several NAC vendors are getting traction. They recently released a marketscope on NAC and sorry Richard, but StillSecure is one of the few out of 17 vendors which was given a positive rating, the highest rating Gartner gave. BTW Richard in that same marketscope your "buddies at Gartner" estimated the NAC market at $225m for 2007 and expect 100 percent growth in 2008. In case your calculator is not handy Richard, that should put NAC around the $450m mark in 2008. Not that different than the number for the UTM space that you use in your article. Hopefully that will allow you to put your "magnifying spectacles" away, unless there is another reason why you would use them to make something look bigger than it is.

4. NAC being created by Cisco in 2003 to solve the worm problem. Richard, perhaps that is why Cisco did NAC. BTW, they announced in like November or December, 2003. We released Safe Access in April 2004. It was under development for at least 12 months before that. We did not call it NAC of course, our working title was endpoint policy compliance. Richard today Safe Access solves that same problem, endpoint policy compliance. We have not deviated from our original plans around this from day one. It is purpose built to solve a problem that customer after customer told us was they wanted a solution to. Maybe that is why we have had success with the product.

We did not jump on the latest, hottest thing bandwagon. In fact I have found that companies and people who jump on the latest big thing, inevitably fail. You cannot time the stock market or the technology market. The NAC market is a perfect example of this. Companies who have taken products that were not successful in another incarnation and morphed them into a NAC product are the companies that are failing. Maybe I am more of an EF Hutton type than you are Richard, but I believe in building a company the old fashioned way. Find a problem that customers are willing to pay for a solution for. Then build that solution and bring it to market and work hard making it the best it can be. If you did your research right and you built the right product, the market will come to you. It may take longer than you think, but if you keep at it, cream always rises to the top and quality always wins. You cannot win running to the next big thing, see through what you start to the finish. Richard if you want to consider that some free advice, take it!

5. NAC is only for the .edu market. Again Richard take some time to dig in here. Yes the edu market is a big adopter of NAC. But let me give you some other examples. Any network that will have a large number of unmanaged visitors or guests is going to be fertile ground for NAC. That includes the government sector, where many users are contractors or visitors. I know you have much disdain for the federal governments IT security practices Richard, but if you spend a little time (there is that phrase again) digging in to what they are doing, you will see that NAC does indeed solve a real security problem for them and is why we have had a great deal of success in the government vertical.

Richard no one ever claimed that NAC is a reason to avoid other security tools. Just the opposite, NAC should work with and leverage your existing network infrastructure and security technologies.

6. NAC does not tie you down to one vendors eco-system if you don't want it to. The TCG/NAP interoperability and now the new IETF standards are bringing one standard to NAC. It does not tie you down, but frankly in case you haven't noticed with all of the moving around, Microsoft already has you pretty tied to one vendors eco-system and frankly Cisco has you pretty tied to another. Don't be so naive Richard.

BTW, I notice you like what ConSentry and Nevvis do without quarantine. While neither of those companies are apparently setting the world on fire as secure switches, you should check out our white paper on a phased approach to NAC that talks about NAC being more than quarantine. You can get it here.

Authors note: BTW Richard while I am chief blogger here at StillSecure, my official title is chief strategy officer and I have been working here for about 7 years now.

]]> Fri, 02 May 2008 18:48:36 +0000 nac solution nac solution nac vendors market stock market nac market richard richard stiennon Stiennon says NAC is dead - I must be in heaven! <![CDATA[Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more]]> http://securityratty.com/article/d47e0757b7a447223299541c460a193c http://securityratty.com/article/d47e0757b7a447223299541c460a193c

Synopsis:  Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more

Welcome to Blue Box: The VoIP Security Podcast #78, a 40-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 17MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on February 25, 2008. Yes, that was two months ago... we know!

You may also listen to this podcast right now:

Show Content:

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Tue, 29 Apr 2008 10:56:49 +0000 voip security news news listener comment line comments listener comments comment line cisco phone podcast Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more <![CDATA[Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more]]> http://securityratty.com/article/5012fddf567c518c66082afa468b2250 http://securityratty.com/article/5012fddf567c518c66082afa468b2250

Synopsis:  Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more

Welcome to Blue Box: The VoIP Security Podcast #78, a 40-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 17MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on February 25, 2008. Yes, that was two months ago... we know!

You may also listen to this podcast right now:

Show Content:

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Tue, 29 Apr 2008 09:56:50 +0000 voip security news news listener comment line comments listener comments comment line cisco phone podcast Blue Box #78: Cisco IP phone vulnerabilties, WiFi handset insecurity, IETF security-related news, VoIP security news, listener comments and more <![CDATA[Information Week's Virtual NAC Tradeshow]]> http://securityratty.com/article/a3388dc9dfac5d70ddc54a2fb89d42fb http://securityratty.com/article/a3388dc9dfac5d70ddc54a2fb89d42fb I know I’ve had another week of being a bad blogger- but you’ll find out why soon. There are several current and upcoming projects I’m going to let you in on. For now, I want to tell you about the Virtual NAC Tradeshow!


Today (April 22nd), Information Week opened the virtual doors to it’s virtual tradeshow- an online show hall, full of NAC information, whitepapers and on-demand presentations from a variety of specialists and industry experts. You can explore technical and business-oriented information and even view Mike’s product reviews of some of today’s popular NAC products. GO forth and Visit the NAC Immersion Virtual Tradeshow.

And yes- you can even see a ‘Featured Speaker’ presentation by me on Preparing the Organization for NAC.

Visit the InformationWeek booth for that one, and all the other fun presentations from Mike and the NAC crew. Robert Richardson, director of Computer Security Institute speaks on the role of identity. Steve Hanna, co-chair of TCG/TNC and IETF working groups provides update and information on NAC frameworks and standards. Robert Marley, CSO for Pennsylvania will lend some insight to endpoint security.

And in case you are wondering, that is my first recorded presentation of this type. I have learned through this experience that it’s evidently impossible for me to use a teleprompter. There are a million little details to worry about while recording this- I’m retarded and we had to redo it a time or two ;)

Check out vendor booths, and add whitepapers and other ‘goodies’ to your tradeshow bag… just like the real thing…. well, except for no t-shirts or stress sticks.

# # #

]]> Wed, 23 Apr 2008 00:59:05 +0000 information nac nac information information week nac crew virtual nac tradeshow nac frameworks week presentation Information Week's Virtual NAC Tradeshow <![CDATA[Blue Box #77: Skype security vulnerability, German gov't looks at trojans, undersea cable cuts, Microsoft and Yahoo, VoIP security news and more]]> http://securityratty.com/article/81cca6f1392389302fa7e6d5bdc8ba8f http://securityratty.com/article/81cca6f1392389302fa7e6d5bdc8ba8f

Synopsis: Blue Box #77: Skype security vulnerability, German gov't looks at trojans, undersea cable cuts, Microsoft and Yahoo, VoIP security news and more

Welcome to Blue Box: The VoIP Security Podcast #76, a 36-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 17MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on February 4, 2008.

You may also listen to this podcast right now:

Show Content:

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Tue, 25 Mar 2008 14:13:34 +0000 security skype security vulnerability vulnerability voip security news voip security professional listener comment line comment line podcast practical voip security Blue Box #77: Skype security vulnerability, German gov't looks at trojans, undersea cable cuts, Microsoft and Yahoo, VoIP security news and more <![CDATA[Blue Box #77: Skype security vulnerability, German gov't looks at trojans, undersea cable cuts, Microsoft and Yahoo, VoIP security news and more]]> http://securityratty.com/article/5e11cc3a2e8dabc13b7ec6f000392917 http://securityratty.com/article/5e11cc3a2e8dabc13b7ec6f000392917

Synopsis: Blue Box #77: Skype security vulnerability, German gov't looks at trojans, undersea cable cuts, Microsoft and Yahoo, VoIP security news and more

Welcome to Blue Box: The VoIP Security Podcast #76, a 36-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 17MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on February 4, 2008.

You may also listen to this podcast right now:

Show Content:

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Tue, 25 Mar 2008 13:13:35 +0000 security skype security vulnerability vulnerability voip security news voip security professional listener comment line comment line podcast 36-minute podcast Blue Box #77: Skype security vulnerability, German gov't looks at trojans, undersea cable cuts, Microsoft and Yahoo, VoIP security news and more <![CDATA[What's holding back NAC?]]> http://securityratty.com/article/f170bfacc77d8fcd7ccb21430dcc63d1 http://securityratty.com/article/f170bfacc77d8fcd7ccb21430dcc63d1 We’ve all been watching some of the pioneering NAC vendors domino down over the past several months. The Lockdown tumble has some questioning the industry again, and as Alan notes, these happenings fuel the fires of NAC’s nay-sayers. (In my opinion, it’s like throwing metal onto open flame… may affect the metal, won’t feed the flame, makes for great steaks).

Chris, an ex-Lockdowner, gives his take on the NAC industry in his recent post-Lockdown blog and I’m in general agreement, but perhaps for different reasons.

I don’t see NAC going away. It definitely has some growing to do, but it will grow and it will be successful. The truth is, NAC has the potential to solve several customer problems and ease a variety of pain points, both for IT and management. If done right (and for the right reasons), it’s both a great technological tool and a business asset.

So, what’s holding back NAC?

Vendors, in a large part, are to blame. Sorry guys, but it’s true. Vendors are causing NAC to be lost in translation, most often because the vendor…  a) doesn’t understand the technology themselves (sales reps),  b) is erroneously pushing their product as a solution to today’s top issue, c) has overestimated the solution and underestimated the project and d) is ultimately trying to make a sale, and so is willing to squish their round peg into your square hole. (okay, no comments on that one).

Vendors will have to start showing they understand when and where their product fits (and when it doesn’t). Until then, I don’t think they’re going to garner enough trust to walk in the door with a solution and close the deal without the customer first exploring (at length) other options and getting other opinions.

Misinformation. Whether it’s due to vendor misinformation or lack of self-education, what I’ve learned is that most organizations have heard of NAC and have a partial understanding of what it does, and really no idea of how. They’ve heard vendor pitches of the wonder-drug cure-all that will solve guest access, or remote access security, endpoint protection, user accounting, etc but they really don’t understand where the technologies came from, what their purposes are, and which pieces of solutions are standard, and which are proprietary.

When I talk about NAC, I find myself constantly apologizing for the industry. We’ve done a great job telling people why they need NAC, but so far we’ve failed horrendously at educating them as to how it’s all supposed to work. Personally, I revamped all my presentations, tabling the technical dives and replacing them with technology primers.

Terminology Twists. The other hardship I see for organizations is the lack of standard terminology. A lot of vendors out there are touting a NAC product- but what does that really mean? It could mean anything- it could mean endpoint integrity or posture checking, it could mean quarantine automation, it could mean a solution for guest provisioning,or  remote access checking. This makes it hard for organizations to parse out the various vendors’ features. Depending on whose Kool-Aid you’re drinking, an ‘enforcer’ could be a software agent, a switch, firewall, or even a computer. 

In order for NAC to grow and find wide adoption, I think we’ll have to see some consistency and consensus in wording and terminology. NAC is a big undertaking, and when entering a commitment like that, organizations need to know exactly what they’re getting to have that warm and fuzzy feeling.

Standard Stalls. The ABC users are, for the most part, seeking standards-based solutions. I think we have a great answer to that, and we’re heading down all the right paths with the IEEE and IETF standards, as well as groups like TNC. But, the truth is, the 802.1X and NAC standards are in constant flux… in a good way… but still in flux. Although we have a great framework in place, some folks are waiting for the dust to settle on Planet NAC before committing.

Once the standards (ie new RADIUS attributes) start to solidify and the changes slow down a bit, I think that will add to the feeling of stability that customers are looking for in a NAC solution.

Migration Migraines. Last, but not least… most organizations that want to migrate to NAC just don’t know where to start, or how to proceed. They need help, either from their vendor, or from an integrator. (That’s where my company fits into the NAC picture). I’m actually working on a detailed migration white paper that will be delivered at a conference later this year.

If we (the industry) want to win the business, it’s up to us to hold our customers’ hands and provide a clear strategic and technical migration plan for them.

# # #

]]> Fri, 21 Mar 2008 22:39:00 +0000 nac product nac product- nac vendors domino solution nac solution standards nac standards nac industry What's holding back NAC?