• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1037
  • Last Modified:

Best Practice Frequency of Applying Web Server Updates

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.
5 Solutions
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.
Kyle AbrahamsSenior .Net DeveloperCommented:
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.
David Johnson, CD, MVPOwnerCommented:
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)
Firewall Management 201 with Professor Wool

In this whiteboard video, Professor Wool highlights the challenges, benefits and trade-offs of utilizing zero-touch automation for security policy change management. Watch and Learn!

btanExec ConsultantCommented:
Most of time is apply updates on a needs only basis. you can also catch this link on best practice

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.
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.
btanExec ConsultantCommented:
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)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now