February 12, 2016 at 4:15 pm
TUellner (2/12/2016)
Tony++ (2/12/2016)
You said April 12, 2016 as a date to be out of compliance, but didn't give any details on what makes that date important.Can you share more info & a link to a site from a government or regulatory body, something a CIO would take as a trusted source?
Here's something from the US government's Health and Human Services website:
See the second paragraph.
"Moreover, the security incident was the direct result of ACMHS failing to identify and address basic risks, such as not regularly updating their IT resources with available patches and running outdated, unsupported software."
-Tom
This is kind of misleading as it implies that A) all old software is insecure and B) software that is secure one day instantly becomes insecure when it goes out of official support.
February 12, 2016 at 5:01 pm
ZZartin (2/12/2016)
TUellner (2/12/2016)
Tony++ (2/12/2016)
You said April 12, 2016 as a date to be out of compliance, but didn't give any details on what makes that date important.Can you share more info & a link to a site from a government or regulatory body, something a CIO would take as a trusted source?
Here's something from the US government's Health and Human Services website:
See the second paragraph.
"Moreover, the security incident was the direct result of ACMHS failing to identify and address basic risks, such as not regularly updating their IT resources with available patches and running outdated, unsupported software."
-Tom
This is kind of misleading as it implies that A) all old software is insecure and B) software that is secure one day instantly becomes insecure when it goes out of official support.
It isn't misleading, it's a way of looking at risk. If your database server is 2005 and a vulnerability is discovered/released on Apr 14, or May 10, or Nov 23 of this year, you have no recourse. Whereas if your are on 2008, MS will release a patch (supposedly) or is working on one, which takes the risk and liability out of your hands. You have applied the latest patches, and are waiting on the vendor.
Note that I tend to agree with you. If the software is secure now, it's likely going to stay that way. No one really looks for vulnerabilities in 2005 because it's older and going out of use. However I thought that about OpenSSL and that was around for a long time before we found vulnerabilities.
It comes down to risk. If you have accounted for the issues and have a plan, you may convince an auditor, which ultimately comes down to convincing your insurance company and/or shareholders, and potentially plaintiffs. You are not prohibited from running older software. However you need a plan.
Perhaps you can mitigate with a firewall that prevents all access outside of specific machines, or you have some other method that proves a lack of security patches isn't a risk.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 12, 2016 at 7:49 pm
Ironically and, perhaps shamefully, the really cool thing about 2005 is that you don't have to worry any longer about MS breaking something with a CU or SP. It's been "stable" for several years now. 😛
--Jeff Moden
February 15, 2016 at 6:19 am
We are in parallel with one of our apps going from SQL2005 to 2012. Another small app will be upgraded to 2012 in March. The last one is going to be Saas April 1st. After that we will be totally off SQL2005. Last year I began working on making it a priority to get off of SQL2008 here and we upgraded quite a few apps. This year is more of a push as we will be getting a new General Use SQL2014 in March if all is approved. Like everyone though my guess is that most apps are in SQL2008 or SQL2008R2 and this will take years to upgrade.
March 8, 2016 at 4:53 pm
We'll need to upgrade soon.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply