| COLUMN |
Security Blog Log: Doing good with exploit code |
 |
|
|
-----------------------------------------------------------------------------------------------------
This month, "Patch Tuesday" week has unfolded in typical fashion, with exploit code surfacing just hours after Microsoft released its 13 security bulletins.
Between that, this week's TechEd conference in Boston and the surprise announcement that Bill Gates will begin to transition out of his day-to-day role at Microsoft, a good chunk of the blogosphere has focused intently on the software giant. The blog of San Francisco-based Ferris Research Inc., for example, described the dominant security theme at this year's TechEd conference:
"Microsoft figures that security software is around 10% of software spending, around $21 billion annually, so this is also a good business opportunity," wrote David Ferris, the firm's president and senior analyst. "This is thus a major area of investment."
While Microsoft outlined its security vision at TechEd, many IT pros were analyzing the latest patches and exploit code from their home bases.
Most bloggers have opted for a detailed, objective analysis of the June patches, as Shane "Dragon" did in his UberDragon Networks blog. Others, like Aviran Mordo, used their blogs to list the latest exploits.
Yet one item in particular, though more than a year old, is well worth reviewing, particularly in light of the exploit code now swirling through cyberspace.
In a February 2005 entry from the Emergent Chaos blog, security expert Adam Shostack responded to Microsoft's ongoing complaint that publishing proof-of-concept code within hours of a patch release puts customers at increased risk.
True, Shostack said, code is required to execute many attacks and without it customers are safer. But, he argued, Microsoft's assertions are off-base since there's no definitive proof that holding back proofs of concept would increase security. In fact, he added, proof-of-concept code can be vital to ensuring security under the following circumstances:
Testing of hardening techniques: If a company uses hardening software … it faces a decision of "Do we need to install this patch?" Someone needs to test the defense against the attack, and because that involves running the attack, it requires code.
Writing IDS rules: If a company uses an intrusion defense system (IDS), someone needs to write a rule for the IDS to detect the new attack. Testing such a rule requires code. Given the short cycle times in which vendors try to ship updates, many customers may wish to test their IDS. Doing so, again, requires the availability of code.
Writing vulnerability scanner rules: If a company uses a non-credentialed vulnerability scanner, that is, one that looks for evidence that an attack can work, rather than evidence of a patch being installed, then the vulnerability scanner authors may well need access to code.
Academic research: Academics who want to create and test new defensive software need access to a zoo of attacks and targets in order to test.
"Yes, code being out there increases the number of people who will use it to attack," he said. "[But] to the best of my knowledge, no one has quantified how much this happens in a defensible experiment."
It's good food for thought as security pros set their sights on the latest flaws and exploits. There's no doubt the bad guys will try to manipulate the latest code to use in an attack, but it's also true that the good guys can use the code to harden their defenses.
|
|
|
|
