Security Manager's Journal: Taking on the DNS flaw from the other side of the world

Computerworld - I was on the road when the DNS cache-poisoning vulnerability hit. Since "on the road" for me can mean being on the other side of the world, it was good to see that I could effectively address this potentially serious problem while thousands of miles from home.

My travels took me to Hong Kong, mainland China and Germany. My company's recent acquisitions have given us facilities in all three locations, and I always seek to ensure that tying new facilities to our corporate network won't introduce vulnerabilities. The connection itself is simple enough -- we simply order an MPLS circuit or establish a point-to-point VPN -- but I won't give my OK without first checking things out.

I typically ensure that desktop PCs and servers are running antivirus software and that they're up to date with patches. Then I check out how employees, partners, suppliers and other business affiliates are given remote access. This usually includes a systematic review of firewalls, VPN concentrators and any other devices that control access.

Then there's the question of intellectual property protection. That one's very important -- after all, it's usually a company's IP that made us want to acquire it. Finally, I turn my attention to physical security: badge systems, doors, cameras, alarms and security guards.

I was in the midst of all of that when I received an e-mail from the IT department asking for my opinion on the DNS cache-poisoning vulnerability. Having been busy with my review of the facilities (not to mention the logistics of travel itself), I wasn't up to speed on the issue, so I went online and read some of the reports. What I learned was that a vulnerability had been identified that could allow a malicious user to replace legitimate Domain Name System entries with bogus addresses. This is not a new style of vulnerability; the DNS has had its share of security issues, most of them involving either a denial of service or a cache poisoning, as in this case. Is the Threat Real?

Our IT operations team is responsible for monitoring and assessing the risk of all reported vulnerabilities. It's a good idea to assess the risks before taking action. Some reports of vulnerabilities are merely false positives, and sometimes we can opt out of the remediation because we aren't running a vulnerable version of the operating system or application in question, or we just don't have any vulnerable infrastructure. Then you have to consider the availability of exploit code.

If there are no published exploits, we typically keep an eye out for updates rather than jumping to patch our infrastructure. After all, patching and updating critical servers and applications is a risky business. If the patches aren't properly tested, we could render various applications or devices useless. And any disruption to business operations could affect company revenue, which we don't want on our heads.

This time, it was obvious that we would need to take action. Exploit code had been made available on the Internet, and some colleagues warned me that it was capable of disruption. What's more, all the major DNS application providers, from Microsoft to the Internet Systems Consortium, had published patches and alerts. We also had to think about how ignoring this problem would affect customers, since we have DNS servers within our DMZ that serve domain information to them.

So, from the other side of the world, I gave my opinion: We had to fix the problem quickly, even though upgrading some DNS applications would be a fairly intensive process. If there was any grumbling, though, I was too far away to hear it. I was able to turn my attention back to the work at hand.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@ yahoo.com.

Read more about Security in Computerworld's Security Topic Center.