US government agencies were relatively unaffected by the Blaster worm this week, crediting their ability to stop the worm to a solid security process, bolstered by a determination to rid systems of the vulnerability long before it could be exploited.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Dave Wray, a spokesman for the US Department of Homeland Security, said the relatively minor impact of the Blaster worm on federal operations "indicates that federal agencies have taken appropriate actions to prevent exploitation of this vulnerability."
Tom Pyke, chief information officer at the US Department of Commerce, said his agency learned of the vulnerability last month through the Federal Computer Incident Response Center. The centre, along with the Office of Management and Budget, held a teleconference at the time with all federal CIOs to discuss the potential impact of the flaw on federal operations.
"At that point, we undertook a crash effort using a process we've had in place for the last year," said Pyke. "Our initial determination was that many of our systems were already protected through routine updates, and the rest of them were protected in very short order through either automated patching or restrictions to router tables that isolated the systems until they could be patched."
As a result, the Commerce Department had no reported infections by the Blaster worm across its systems, which number more than 39,900.
A similar success story comes from Lawrence Livermore National Laboratory, where more than 10,000 systems were patched before the worm ever showed its head on the internet.
"At one point, we were sitting around waiting for a worm to develop because our security director correctly conjectured that the transport vehicle [for the exploit] was going to be a worm," said Kenneth Neves, CIO at Lawrence Livermore.
"But we didn't wait for a worm or a signature. Had we taken the standard approach, which is to wait for the signature to appear, we would have been compromised."
Neves credited the California-based lab's security chain of command, which has someone responsible for security initiatives at each level.
Mark Graff, chief cybersecurity officer at Lawrence Livermore, said the policies at the lab gave his team plenty of time to deal with the threat. And, even though most of the lab's patch-deployment process is automated, many of the unique systems used by scientists had to be fixed manually.
Lab officials also learned some important lessons in dealing with the Blaster worm, said Graff. "There are very complicated trade-offs in trying to decide exactly how far to go in making special adjustments to the firewall," he said.
"We had a team looking at exactly which additional ports, if any, we needed to block. And we have to ask ourselves in every instance what the operational impact would be."
At the US Department of Defense, the Joint Task Force for Computer Network Operations (JTF-CNO) sent an urgent message on 25 July to combatant commanders and service agencies to apply the patches needed to fix the vulnerability.
"The JTF-CNO also directed actions that are designed to block or limit any attempts at exploitation, and we are assessing and investigating sensor data and incident reports," said Timothy McFadden, a spokesman for the JTF-CNO.
"Attempts to hijack or degrade the Internet are simply a fact of modern life. DOD computer systems are attacked every day."
A senior official at the Port Authority of New York and New Jersey who requested anonymity said port authority operations were unaffected by the worm. But the agency still faces the usual challenges of balancing a need to test new patches with the need to get a fix out in the field quickly.
The real question, said the official, "is when is Microsoft going to deliver on its commitment to develop more secure software?"
The worm, also known as Lovsan, takes advantage of a known vulnerability in a Windows component called the Distributed Component Object Model interface, which handles messages sent using the remote procedure call (RPC) protocol. RPC is a common protocol that software programs use to request services from other programs running on servers in a networked environment.
Dan Verton writes for Computerworld