June 20, 2009 at 2:03 am
Comments posted to this topic are about the item Lax Security - Database Weekly (June 22, 2009)
June 20, 2009 at 6:50 am
I'm very curious about what you mean by patching your server.
We do patch our Windows servers every month, have software to keep track of what was patched and what was not, and patch what needs to be fixed, etc... But as far as SQL, there were 2 security patches last year that were completed this year. That's all in several years (the only for 2005 and not sure if SQL 2000 had any before that), and even those were minor and had work-arounds.
So if you are talking about Windows, yes we keep everything patched, and have done the same with these security patches in SQL.
I'm curious now is if you are advocating applying every CU when they are released. If yes, how does that relate to database security?
June 20, 2009 at 9:34 am
Anyone who was in employment when SQL Slammer hit is unlikely to leave servers unpatched.
SQL Slammer caused so many problems because it attacked all editions of SQL Server so the DBAs who thought they were safe by applying SP3a to Standard, Developer and Enterprise editions of SQL2000 got a really nasty shock from all the mystery MSDE installations that had turned up in their organisation.
Ideally there should be some auditing software that can track down the various copies of SQLExpress and identify their patch levels.
Things to consider
1. Which copies are internet downloads?
2. Which copies power up a 3rd party application?
3. Can the 3rd party applications be patched?
4. How many copies SQL Express have you got in total
5. Can they be patched remotely from a central point. You don't want 300 employees trying to download a service pack in one go!
June 20, 2009 at 1:22 pm
We've finally gotten serious about updating a whole bunch of our production servers (mainly SQL 2000, SQL 2005 seem to be up to date). But the scary thing is how many production servers are out there with SQL Server on them that we know nothing about (there seem to be a lot Sharepoint related ones out there) and when something goes wrong, we're expected to have known about them, even though we have not had anything to do with installing them.
We're finally getting strict on that and tell all the dev and qa people above us (literally, we're in the basement...go figure), that if we (the DBA's) don't install it, we don't support it, and if they expect us to, it will come out of their budget. And when we finally do get around to patching up a production server, it FIRST has to be done in the dev and qa environments, tested, before we install it in production. Sometimes it's not a lack of desire as we try to insist on the latest patches and service packs, but a lack of willpower and resources. To give them credit, we have the security team on board with this, insistinng on at least a quarterly patch implementation (emergency patches excepted) so it's always good to get support like that when you insist on patching.
Cheers.
Gaby A.
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
June 22, 2009 at 3:11 am
People who read the editorial generally are aware that they are running database software and that it is likely to need patching.
There are countless applications out in the wild where the database has been installed as a black box and the purchaser has generally has no idea about what has been installed or how to patch it.
I am currently doing some project management work on a voluntary basis for a charity that involves product selection, and have been surprised by the number of software packages being sold that run on MSDE, some still using SQL 7 MSDE.
If you add the number of SQL Server installations in SMBs where the database is a black box to your total, it would astound me if the % of sites that never patch SQL Server was not at least double the 11% quoted in the article.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
June 22, 2009 at 7:36 am
I keep SQL Server patched on the known servers and on my desktop (Dev Editition). But, as has been mentioned, it's entirely possible there are copies of Dev or Express on the network that I don't know about.
If you install the contact manager for Outlook, that installs a copy of MSDE/Express, and patches for it get included in the Microsoft Update service, if you run that.
Once had a whole building's LAN brought to its knees by a laptop that had a demo copy of a CRM called "Everest" on it, because it installed a copy of MSDE 2000, and it was never patched, and got Slammer. Same LAN had been crashed a few months earlier by someone accidentally getting the network cables mixed up on an IP phone. Fun times!
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 22, 2009 at 8:25 am
I was speaking of SQL Server patches, but Windows ones would count as well. Typically there is someone else that handles patching Windows in most companies I've seen, even small ones. Separate from the developer / DBA. If you're the sysadmin stuck with SQL Server, then you probably do both.
The other patches for SQL Server, not security ones, could impact the way things work. I'm not sure if they are security related in any way, though they'd include security items. Each includes previous patches.
I don't recommend the CUs unless you are affected severely by an issue and can't wait for the yearly service pack. These items aren't comprehensively tested.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply