By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Judging from the number of companies that posted fixes (some within a day or two of the announcement), I think vendors are taking it very seriously. I can't imagine that companies that use these SNMP applications (telecommunications companies, financials, among others) aren't taking it serious either. Having once managed Earthlink's network management architecture, the first thing I would have done would be to look to my vendors (Cisco, Foundry, Cabletron, among others) for announcements as to their vulnerability. I would then work with the network engineering staff to determine what we could do at the network level to stop customers, hackers, etc., from playing around with our network gear to see if they could crash us. The final step would be to apply (if any) patches from my vendors that fix these problems. How serious is the flaw in your mind?
It's very serious. Hackers can have a field day with an SNMP application that exhibits any of the vulnerabilities. Should companies considered upgrading to SNMP v.3?
Makers of SNMP software have been slow to adopt SNMPv3. This is due mainly to the fact that SNMPv3 is not yet a full standard. We anticipate that it will become a full standard this year. Once this happens, you will begin to see more people add support for V3 to products. Others will continue to be more cautious even after SNMPv3 becomes a full standard. Since SNMPv3 allows you encrypt passwords for authentication as well as encrypt the packet data, this can take up resources on the sending and receiving systems, i.e. the whole encrypt/decrypt functions. It isn't clear if this will adversely affect routers, switches, etc. Once more vendors adopt SNMPv3 and actually use the cryptographic abilities of the standard, we will know more if the added security to SNMP are useful or not. Has the flaw tarnished SNMP's reputation?
No, not really. The vulnerabilities that were discovered by CERT are not with the protocol itself, but with how the protocol was implemented by vendors, companies, etc. Do most companies rely on the patches from software vendors? Or are they taking steps on their own?
Yes, companies almost always rely on vendors. The exception is companies who have written custom SNMP applications in house. This typically happens with large telecommunications or financial companies. Companies like these are usually not interested in reinventing the wheel, so they will use an SNMP toolkit that makes using the protocol easier. Such toolkits are provided either by a real company or by the open source community. It's often easier to get updates, patches, etc., from a real company. When it's an open source toolkit, with maintainers all over the world, it can take a while to see updates and fixes. Companies that use products like HP OpenView, Micromuse Netcool, and the like are at the mercy of the vendor. Since products like these are not distributed in source code form, it makes it impossible for a customer to fix the problem themselves. On the other side of the coin are the companies who used an open source SNMP toolkit to build an application. If they have the programming talent in house, which presumably they do, it would be trivial for a developer to fix the problem in the source code. As a last resort, a company can either turn off SNMP on their devices or, using firewalls, access control lists (ACLs), etc., greatly restrict how SNMP is used in their network. Are a lot of companies putting off fixing it or they jumping on it in earnest?
I don't think companies are putting off fixing the problems. It is almost a no-brainer to find and fix the bugs. This is due in great part to the folks who put together the PROTOS test suite, which has some 22,000 test cases that can break an SNMP application that is susceptible to the vulnerabilities announced by CERT.