There are several things that I did not see in the article. It seems to imply that Voip handsets and Voip servers share the same infrastructure as workstations. This is already recipe for trouble as even a normal business use could seriously affect the phones.
Today, these networks really need to be separate, either physically or through VLANs, as a lot of network architectures cannot readily address both needs: throughput for business application or latency for Voip.
The only application of NAC that I can see useful today is if somebody mistakenly (or not) connects a PC to the Voip network. Using NAC (802.1x actually in this case) would make sure that this device cannot connect at all and that the disruption is limited to that port.
Latest software headlines from Network World:
Kernel developers, Wall Street to come together
Zoho launches e-mail app with offline, mobile access
|
Does Verizon's Voyager stack up to the iPhone? |
|
|
5 IT skills that won't boost your salary 
[1,407]
Women 4 times more likely than men to cough up personal info [589]
Japan's 10 funniest tech-related commercials [Videos] [407]
Throwing away a promo CD is "unauthorized distribution"? [1,265]
Adults too quick to dismiss educational video games [682]
Attack of the iPhone clones [Slideshow] [578]
10 things IT needs to know about AJAX [1,258]
This Year's 25 Geekiest 25th Anniversaries [Slideshow] [409]
|
|
NAC can help VoIP far more
I blogged on the ideas here at the En Garde blog at blog.consentry.com, but just wanted to quickly comment that NAC, in a fuller form, can do much more to help VoIP then just incidentally protect it from viruses. If true Network ACCESS Control is implemented vs. just simple admission control where endpoints are scanned, then a NAC system can also control what devices are allowed to communicate with the VoIP elements. So you could create a policy that says only VoIP phones can communicate with the call manager and vice-versa, providing a much greater form of protection against attack than simply blocking worms by checking endpoints.
Michelle McLean
ConSentry Networks
mmclean-at-consentry-com
Helping is what NAC Must Do
As the CTO of a network security company, I’ve watched the NAC market evolve from its infancy. I believe that NAC promises to further secure IP Telephony environments and that it's this kind of micro-application (e.g. VoIP, peer-to-peer policies, IRC and IM governance, etc) that forms the foundational business benefit of implementing NAC.
To that end, Mirage Networks released a set of IP Telephony rules in 2005, and continually qualify the product via Avaya's DevConnect program. We encourage IT staffs that currently have, or have plans for, IP Telephony implementations to ask their prospective NAC vendors how they plan to integrate into IP Telephony environments. Some starting discussion points:
1. What does "A" mean in NAC? If the NAC solution begins and ends with “Admission” versus “Access”, it’s likely going to be useless beyond the tangential. A NAC solution focused on policy enforcement throughout an endpoint's network lifecycle is much better suited to securing IP telephony environments.
2. Do no harm to your voice network. The nature of real time streaming protocols is well-documented elsewhere. However, it is worth noting the danger of latency injection when evaluating NAC solutions.
3. Keep it simple. Is there a general purpose OS device in the IPTel Segment? Is there an endpoint attempting to enter a stream without sending control packets? Is an unauthorized TFTP server attempting to send configuration data to your phones? There are basic but high value, course-grained policies, spanning pre and post admission, which can be brought to bear to further secure IP Telephony infrastructure without requiring back flips or wide scale OS dependant agent deployments.
A recent white paper, “NAC and Internet Protocol Telephony: Securing Enterprise Voice-Over-IP Environments” provides further detail: http://miragenetworks.com/products/white_papers.asp
-Grant Hartline, CTO, Mirage Networks