Handler on Duty: Adrien de Beaupre
contact us
contact us
Your session is about to expire. Please reload or submit to avoid getting logged out.
| If testing is required, then test it for a few days. Every day a working patch is sitting around is one more day for hackers to do millions of dollars of damage. I'm surprised companies don't get sued for doing slow monthly patching. It's a liability. |
| Waiting for M$ or a middleware vendor (AV, FW, IDS, etc.) to release a patch "later" when *something* can be done now verges on the edge of corporate malfeasance, if not outright nonfeasance. |
| It is mostly about education and awareness MS guys are good at propaganda. I have seen the improvement in awareness of even the n00best user since the new screens started appearing. |
| For generic MS COTS software such as exchange etc... its a good idea. For 3rd party apps its something that may not be feasible do to the fragile nature of a lot of specialized software. |
| exceptions should be based on 'risk to users', not 'risk to vendors' |
| Monthy is good, unless the delay in pushing out a patch puts systems at greater potential risk than flaws in the patch itself. |
| Monthly patches are fine for most things, critical problems need to be addressed sooner. |
| every 2 weeks to better combat faster threats |
| How about making an OS with no loopholes?? /perfectworld |
| Risk doesn't occur in monthly increments |
| Not necessarily monthly, but patches should follow a well-define deployment train that includes QA testing. |
| No, MS takes long enough to release 0day patches as it is. |
| Users have been a barrier to patches -- having a monthly patch cycle gives me a bigger hammer to demand downtime |
| It's too frequent for "routine" stuff, and likely not flexible enough to close critical security risk windows. |
| Monthly good, unlessin' there's an exployt out thar! |
| Depends, If an exploit is out then I need the patch yesterday. If the bad guys don't know the details of the vulnerability yet, I can wait a month for a well tested patch. |
| should be high granularity and short cycle per entity: Don't patch the SYSTEM, patch the affected COMPONENT, and design components with a high granularity and specific task in mind... oh, wait, that's (U|Li)nux =) |
| Too many times patches have broken systems |
| It works unless the exploit is already out there. |
| Good idea, bad timing |
| It depends on the severity of the bug. More severe == more need for an immediate patch, even if it breaks one other thing. (That one other thing can be fixed later, either in an updated patch or some other update.) |
| monthly is good.. regular cleanups.. but ASAP for criticals are greatly welcome |
| I just think that it allows the hackers advance time to prepare to reverse engineer the patches. |
| Whichever way it's done will be wrong. |
| Publicly known and exploited vulnerabilities should have patches issued out of cycle |
| Yes, generally monthly patching is adequate for most situations, although there needs to be an alternate vehicle in place to deliver notification and address serious "Day 0" exploit issues. |
| I want choices on the amount of risk I take and need patches as early as possible. They must test it 100% |
| no matter how you do it, it is a royal pain. Critical problems with current exploits need to come out ASAP. |
| No appliance should need repaired once every month. The fix is building a better product. |
| patch quality from microsoft improved with planned monthly releases |
| One man's security fix is another man's administration nightmare |
| The principle of a monthly patch cycle is good for planning your workload, but there must be the opportunity to bring a patch forward if the security implications require... such as with wmf |
| I am a normal home-single-pc-user and I like it - I think for admins it must be heaven! |
| Gee, with Apple they just test the patch and post it when it's ready... |
| Everyone knows Black Tuesday and us Security 'guys' can plan for it |
| Monthly is great for planning, but the occasional zero day should be expedited and released off-cycle. |
| As soon as the patch is ready for release. Why wait and put the users to more risk, if you have a ready made patch. |
| didn't know if "it depends" covered it. Yes, a regular cycle is good. But need fixes as quickly as possible when circumstances dictate. |
| We need a candidate patch with vulnerability details as soon as possible. We have resources in-house to test patches or develop workarounds, but are stymied when the vendor keeps quiet to enforce its cycle. |
| Exploits don't occur on a monthly schedule, why should patches? |
| The ability to plan is very useful - I ensure I'm never on vacation on Patch Tuesday, etc. On the other hand, if there is an emerging threat, patches should be released off schedule. |
| Exploits don't wait till the second Tuesday and neither should the patches... |
| The nature of the vulnerability is a factor. Severity. |
| Monthly cycles are great when vulnerability discovery is also on a monthly cycle, which happens how often? |
| zero day exploits need immediate patching, if the vendor cannot provide this it is time to re-evaluate vendors |
| Monthly is fine if there are other ways to mitigate/minimize the potential damage and risks. |
| monthly patching is a nightmare for dial-up users |
| If they need to patch their software monthly it qualifies as alpha software and should never have been released in the first place. Patches for security flaws should be released immediately. |
| Welcome to Microsoft world |
| Monthly is often enough for patches, but too late when there are public exploits out. |
| No, workload peaks are bad, delaying a safe tested patch release when it could be applied is riskier, if there is unpatched risk then the choice of a less safe patch is better than no choice of any patch. |
| If they would do it right the first time, we wouldn't need fast responses! |
| A bad patch is worse than no patch at all |
| Generally yes, a monthly patch cycle is good as planning can be done. There should be a break in the monthly patching cycle if the risk is very high and there is an imminent threat. More vendors should follow suit. |
| it is a security disaster |
