Slashdot Mirror
Border Security System Left Open
7x7 writes "Wired News is running an article on documents they recovered via the Freedom of Information Act and a lawsuit. From the article:"
A computer failure that hobbled border-screening systems at airports across the country last August occurred after Homeland Security officials deliberately held back a security patch that would have protected the sensitive computers from a virus then sweeping the internet, according to documents obtained by Wired News." It looks like Zotob made it in to the supposedly protected network."
Running Windows and neglecting the precautions that Windows requires.
Zotob scanned for systems with port 445 open. In the name of the Flying Spaghetti Monster, why weren't those systems behind a firewall? On a closed network so that someone couldn't just plug in an infected laptop?
Then comes a vulnerability that Microsoft marks as "critical" and a patch that Microsoft says should be installed immediately. A sane patch management policy *might* delay installations but only if some temporary mitigation were in place (like, say, a firewall, or less snarkily an updated IPS).
It looks like Zotob made it in to the supposedly protected network.
I'm supposed to be surprised that the department that is there to "protect" us from attack fell to an easily preventable virus?
Not when that same agency appoints Gator (now Claria) executive, D. Reed Freeman, to their Data Privacy and Integrity Advisory Committee or when that very same agency hired its own Chief Privacy Officer from Doubleclick.
No, I couldn't muster less shock at the irony if my nutsack depended on it.
Tom Caudron
http://tom.digitalelite.com/politics.html
-Tom
While stating "deliberately held back a security patch" might be factually correct and a good catch line, I think it's highly misleading: it directs the reader towards many of the wrong conclusions.
Later in the article: "Officials -- not unreasonably, say security experts -- wanted to test the patch before installing it." Well, duh. This is the interesting story. They couldn't get through the tests that they SHOULD do fast enough.
The problem is agility and testability of the systems and deployment. The easiest solution has nothing to do with MS, nothing to do with windows, and everything to do with giving your test group more respect and resources.
This is not a problem inherently Microsoft's making. You can argue up and down that patches should be faster, product more secure etc. In the end, it's plausible that discovery, patch, exploit can come with bad timing in any system. System admins and project managers that don't plan for this are asking for trouble.
Elaboration: I push very hard to ensure that all my products have automated tests. My company's Desktop Engineering department requires automated tests of all its myriad apps (DE is not my department, won't take credit). I force redesign if a product can't be tested cheaply. The benefit is: I need new feature x tomorrow (maybe some suprise regulation) or company needs patch y tomorrow (e.g. Zotob worm). Where we've achieved our test automation goals (haven't in all cases, but our coverage is good enough), we can hit a few buttons, run our tests. Repeat on all 20 configurations / platforms. 90% of the time, we find no problems, and can deploy. If it's critical, you take the risk and deploy. If not, you go on to slower manual testing to complete coverage.
Had this US-VISIT program implemented adequate and automated tests, they could have deployed in a few days, not a few weeks. The methods and tools to do so have nothing to do with Microsoft. They don't even make the type of test automation tool required for this - although I know they have one for internal use.
My motto: "A cat is no trade for integrity."
From 2001 to 2003 there was a 'porn czar' in Utah.