Solved

Best Practice Frequency of Applying Web Server Updates

Posted on 2014-01-29
6
926 Views
Last Modified: 2014-11-12
I have a new .NET web application that runs on Windows 2008 R2 (IIS) and SQL 2008 R2. I am planning to host it on Amazon AWS for a new customer.

They have asked me "Are there any standard outage windows used for upgrades and patching?  If so, please detail the frequency of these and the duration."

A few questions:
1. What would you suggest is the best practice for applying Microsoft updates on a live customer facing web application? Review monthly and apply then if appropriate, but on demand if a more critical security patch comes out?

2. Is it best practice to apply all Microsoft (Windows & SQL) patches/updates always (after regression testing the app) or only select a specific subset of them based on some measurement?

Thanks for your help.
0
Comment
Question by:everycloud
6 Comments
 
LVL 76

Accepted Solution

by:
arnold earned 100 total points
Comment Utility
MS releases updates on the first or second tuesday.
Security/critical updates should be applied in a regular interval.
Security that can compromise your site should be more expeditious i.e. an emergency update.

You can have a Saturday window 9-12 that should be enough to perform all your updates.

You may want to replicate the same setup/configuration in-house on which you can test whether the update will have an adverse affect on the functionality of the site, i.e. you use a technique web to sql that MS determines is a vulnerability and an update to either the IIS or SQL will cause errors whenever this method is used.

Updates the fix issues within IIS (including cryptography issues) sql etc. should be done as soon as possible.

others .....

note the update/upgrade windows include changes to the site/sql schema etc.
You can schedule a possible window every weekend, it does not require that you make use of that window.  Check whether they have a notification mechanism such that you would let them know that you are making use of this weekends window.etc.
0
 
LVL 39

Assisted Solution

by:Kyle Abrahams
Kyle Abrahams earned 100 total points
Comment Utility
My general thoughts are to apply all patches when possible.  If they're patching, there's a reason for the patch.  Sure some are less critical, but why not include them?

Monthly or even quarterly is fine unless it's a critical hotfix.  For testing purposes I would apply the same patch(es) to the test environment and test it.  After testing then apply to production.

If you had at least 2 servers in your farm, you could repoint all traffic @ one server.  Then patch the offline one so you wouldn't have any interruptions, swap, and finally rebalance so they're both up and running.

Updates should always happen during off peak hours.  Hope that helps.
0
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
Comment Utility
have 2 instances of the server of which only 1 is active at a time.. patch 1, when ready switch to it, then turn off #2 and then patch it.. rotate between the two..

I believe that Amazon does the update patching for you with no downtime (I know Azure does)
0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 
LVL 61

Assisted Solution

by:btan
btan earned 200 total points
Comment Utility
Most of time is apply updates on a needs only basis. you can also catch this link on best practice
http://technet.microsoft.com/en-us/library/cc750077.aspx

It is always good to continuous monitoring websites for web defacement or vulnerabilities leading to website being compromised due to the commonly owasp vulnerabilities. Web scanner help to surface dynamic code vulnerability and personnally that is the entry point of attack as well as the point to be patched first. The underlying VM OS is important as well and criticality typically  includes assessing if that impact the web apps logic and MS stated severity level. All patch shoild be applied if deem not impacting your web server.  Likely you put up a work in progress message in advanced notice or banner marque or  under maintenance page during the website going down.  

Most of the time patch also need to reboot server if it doesn't such as restart services is good enough then probably downtime for patch can be negligible or none. Off peak hours are chosen snf likely tied after the patch bulletin release schedule.

Network defences like web appl firewall if available offers a windows for user to go execute patching schedule  or buy uou some short time while user try to test and sort out the necesary patching. Sometimes ppl say it is virtual patching to reduce window of exposure so that the website is not down and exposed to public for too long.

Patch testing should be done via staging environment ideally of similar replica or close too before patching the production or primary website. Some have loadbalancer and able to patch the standby and subsequent the active webserver..don't forget the appl and db server for tier architecture which also are crwon jewel that need to maintain secured posture too.
0
 
LVL 32

Assisted Solution

by:shalomc
shalomc earned 100 total points
Comment Utility
If you're on Amazon there are really no excuses to defer patching of security or critical issues. Do not update automatically, so you can easily create a private AMI before update.
Then, whip up a new application instance, patch it, verify application execution, switch servers, and create another private AMI post patch.

Your risk from ignoring critical updates is much higher than the risk of breaking the application.
0
 
LVL 61

Assisted Solution

by:btan
btan earned 200 total points
Comment Utility
In general,
a. Have an early planned patch agreement with provider and focus the critical service and asset to rollout patches with priority.
b. Always test and verify such that patch and hotfix doesn't break apps before pushing releases into production. The emergency fixes may skipped the staging and have it identified and agreed upon, and as always standby rollback plan as contingency.
c. Focus more on the application instances and not only the Host supporting environment (which provider should rightly managed).
d. Staging environment if exposed to the web internet should be treated with the same patching scheme else it should be isolated.
d. Regular scanning should be performed to ascertain security state and sieve out the critical gaps especially those tagged with CVEs (and has no hotfixes or pending patch releases).
e. Hardening not be neglected even with patching e.g. close unnecessary services to leak "gaps" to external probing.

For Amazon, as stated once you deploy an instance you must manage the patch level of your instances yourself, including any updates issued after the AMIs were built. So do see some recommendation to maintain check regularly.

e..g http://aws.amazon.com/articles/1233/
(Tips for Securing Your EC2 Instance)
e.g. http://aws.amazon.com/articles/1767/
(Windows on Amazon EC2 Security Guide)
(use of Surface Area Configuration tool to help configure the attack surface on your SQL Server instances)
e.g. http://aws.amazon.com/security/penetration-testing/
(Penetration Testing)

As always, Amazon shared if you believe you have discovered a security problem with your Windows instances, please contact the regular support channels for Amazon EC2. E.g. http://aws.amazon.com/security/vulnerability-reporting/

Will be good to subscribe to Amazon Security Bulletin RSS Feed to keep abreast of security announcements. http://aws.amazon.com/security/security-bulletins/

I believe for Amazon RDS, it can automate common administrative tasks, such as performing backups and patching the database software that powers your DB Instance. For optional Multi-AZ deployments (currently supported for MySQL and Oracle database engines), Amazon RDS also manages synchronous data replication across Availability Zones and automatic failover.

They have diagnostic too @ http://aws.amazon.com/windows/awsdiagnostics/
(AWS Diagnostics for Microsoft Windows Server Beta)
0

Featured Post

Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

Join & Write a Comment

You cannot be 100% sure that you can protect your organization against crypto ransomware but you can lower down the risk and impact of the infection.
Ransomware continues to be a growing problem for both personal and business users alike and Antivirus companies are still struggling to find a reliable way to protect you from this dangerous threat.
Steps to create a PostgreSQL RDS instance in the Amazon cloud. We will cover some of the default settings and show how to connect to the instance once it is up and running.
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

8 Experts available now in Live!

Get 1:1 Help Now