July 24, 2017 at 9:12 pm
Comments posted to this topic are about the item Advancing Security
July 25, 2017 at 10:34 am
One thing I would like if MS did it, would be to split off any "security / vulnerability" type updates for SQL (which seem to be few and far between) from the general CU / SP updates. Working in a "vulnerability aware" environment, if I have to install an entire CU for one security fix, I have to take the time to verify that none of the non-security updates broke anything else.
Hasn't happened yet, but there's always a first time.
July 25, 2017 at 11:22 am
jasona.work - Tuesday, July 25, 2017 10:34 AMOne thing I would like if MS did it, would be to split off any "security / vulnerability" type updates for SQL (which seem to be few and far between) from the general CU / SP updates. Working in a "vulnerability aware" environment, if I have to install an entire CU for one security fix, I have to take the time to verify that none of the non-security updates broke anything else.Hasn't happened yet, but there's always a first time.
How would you do this? It's entirely possible the code being patched has also changed with the CU/SP. If you think about code, it's not easy to separate code the changes functionality from code that has security issues. Critical security fixes are released separately, but only for limited CU/SP branches. They can't support every combination of releases, nor would I want them to. That creates other issues, not the least of which is confusion for developers that might be developing the fix.
July 25, 2017 at 11:34 am
Steve Jones - SSC Editor - Tuesday, July 25, 2017 11:22 AMjasona.work - Tuesday, July 25, 2017 10:34 AMOne thing I would like if MS did it, would be to split off any "security / vulnerability" type updates for SQL (which seem to be few and far between) from the general CU / SP updates. Working in a "vulnerability aware" environment, if I have to install an entire CU for one security fix, I have to take the time to verify that none of the non-security updates broke anything else.Hasn't happened yet, but there's always a first time.
How would you do this? It's entirely possible the code being patched has also changed with the CU/SP. If you think about code, it's not easy to separate code the changes functionality from code that has security issues. Critical security fixes are released separately, but only for limited CU/SP branches. They can't support every combination of releases, nor would I want them to. That creates other issues, not the least of which is confusion for developers that might be developing the fix.
Excellent point. I was thinking in terms of your typical OS patches, where individual components can be easily patched for a security issue. SQL is perhaps a bit more akin to something like Word, where a patch might both resolve a bug in the application and simultaneously patch a vulnerability that was caused by the bug. Probably still a bad analogy, but it's the best I can come up with at the moment.
July 25, 2017 at 1:53 pm
The OS isn't a lot different. It's larger, so changes might not collide with security issues, but the same thing comes in both cases. There are just fewer "patches" on the OS.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply