Slow Patches
-
What can you do about this? A security flaw is discovered and the vendor issues a patch. However before you apply it, a hacker uses the vulnerability to attack your systems. That happened to the state of Georgia where a database flaw was exploited.
This is one of those areas where the IT guys are really stuck. The vendors work to get patches out and I love the once a month cycle that Microsoft has implemented. But that means that from the first Tuesday when patches are released you are vulnerable to an exploit while you are testing. Yes, I know that you are vulnerable before that, but for the most part the security flaw isn't made public until then.
I know at some of my larger companies we'd have a team working from Tuesday to Friday to test on a number of machines with a limited scope deployment on Friday and then the wide scale deployment the following Friday. There were exception machines that might remain unpatched, but most servers would get patched within two weeks.
Which can be an eternity on the Internet. Two weeks for someone to attack your system? That's a long time.
But what can you do? Applying patches on day zero means you haven't tested well. And things can always break, so you'll always have some time period where your database servers are vulnerable.
You just hope no one gets in that quickly.
Steve Jones
-
My experience is that database servers tend to have more robust perimeter security than other servers.
IIS on the other hand is more likely to be public facing and therefore be less secure.
Of course this is the reason why I hate the idea of having a shared database/web server.
-
It's a question of balancing risk. What's the probability of the vulnerability being exploited and what damage might that do against the probability of the patch causing an issue and the damage that might cause. An analysis of the issues identified in patches tested to date will give a good indication of the latter. Then, it's some simple statistics to find that balance point (although may be influenced by politics). If the vulnerability is serious enough, it might be entirely rational to deploy a completely untested patch - rather bring your systems down for the day than have a few thousand high net worth customer account details stolen.
-
I won't say this is the case with all vendors, but this should apply to most major vendors. If there is a security exploit in any of your systems facing the outside (open to the public), then fixes should be applied immediately.
Ideally, and practically, this should be able to happen for any system because:
- Backups of all data, all system states, etc. should be taken regularly, especially before applying fixes or configuration changes. If this isn't currently happening, it could be your biggest flaw, as even with exstensive testing, there's the possibility that something was missed.
- There should be a SLA with your software vendor (this applies mostly to the smaller vendors). This insures that the delivered software is of high quality, and just not pushed out to meet a deadline. If they are not willing to put in writing that their software will work for you 9x.x% of the time, and back that with finances, then why are you doing business with them, as the risk/cost for loss of business would be less if you wrote the software in house.
- Finally, if your business is large enough to have at least three people working on testing fixes and patches, then it should be tested 24 hours a day until testing is completed (3 shifts). If fixes are released on a schedule, then the testers can plan for it accordingly.
Can your business afford to be open to attack for a day, week, month? Can your business afford to have its data compromised? If your answers are no, make sure the above is happening.
Enjoy!
A Brown
Manage all of your backups in one simple job using this script. -
There should be a SLA with your software vendor (this applies mostly to the smaller vendors). This insures that the delivered software is of high quality, and just not pushed out to meet a deadline. If they are not willing to put in writing that their software will work for you 9x.x% of the time, and back that with finances, then why are you doing business with them, as the risk/cost for loss of business would be less if you wrote the software in house.
Have you read the EULA that M$ puts on ALL their products?...
...
Except for the Limited Warranty and to the maximum extent permitted by applicable law, Microsoft and its suppliers provide the Software and support services (if any) AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the Software, and the provision of or failure to provide support or other services, information, software, and related content through the Software or otherwise arising out of the use of the Software.
...
Now, If that is M$, are you going to push harder the little guys?...
* Noel -
To the best of my knowlegde with regards to MS, even if you buy a support ticket with a credit card, they will work 24-7 to resolve a production issue. Also, if the problem is determined to be a bug in their software, they will refund you the cost of the support ticket, or not subtract from the balance of support hours (if you have an hour-based support contract).*
So yes, if the vendor is not willing to provide 24-7 support for your business, then either hire people to write it in-house, or write an SLA with a $damage$ clause.
SLA issue aside, IMO testing should be 24-7 until a safe/unsafe outcome is reached.
* Don't hold me to that, I only speak from my past support incidents that were caused by bugs. Not a penny/hour spent from my card/contract.
Enjoy!
A Brown
Manage all of your backups in one simple job using this script. -
It seems to be overlooked in these discussions that there is no such thing as zero risk, in the computer world or the physical world. It's possible someone will break in, it's possible there will be a fire, it's possible that an externality will destroy your credibility (like the dog food contamination event recently), it's possible (as shown by recent news) that an employee will go mad and shoot the place up. Nothing is guaranteed in this world and never will be.
Do everything you can to reduce risk, but it will never be zero. Thats' life. Don't whine.
...
-- FORTRAN manual for Xerox Computers --
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply