On Tue, 11 Jan 2011 05:53:44 PST, Zach C said: > change, who knows. I see you mention the time it takes to test patches and > their > effect on your workflow, but I would figure an equal or greater amount of time > would then need to be spent on other solutions as well The trick is to choose other solutions that don't take as much time on an ongoing basis. Let's say for example, you spend 2 hours every month doing regression testing on the patches against XYZ.net that came out on Patch Tuesday. Now imagine if you can properly sandbox XYZ.net - at that point you don't *care* if a security patch comes out. You can choose to only push the patches out to your users if a patch comes along that actually affects your site. Then you're only spending that 2 hours doing regression testing once every 6 or 8 months or so. Sure, that sandboxing may take the first guy a solid man-month or two of time. But then he can package it, and you can then get the package, spend 8 or 10 hours deploying it, and after a few months you've got 2 hours per month back. (Yes, I know "properly sandbox" is a lot of hand-waving. The point is that if you don't do this sort of "what if we do something different" analysis, you're doomed to keep spending time every Patch Tuesday. Also, doing a proper "what would it take?" analysis can be a good thing even if it turns out the new idea is infeasible, because you'll be much more familiar with the innards of the package, which will almost certainly pay off in decreased debugging time down the road, and your overall security knowledge will also increase, which is also a good thing...)
Attachment:
pgpciQt3mmUrc.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/