Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

Best Practice Frequency of Applying Web Server Updates

Posted on 2014-01-29
6
Medium Priority
?
998 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
6 Comments
 
LVL 80

Accepted Solution

by:
arnold earned 400 total points
ID: 39821879
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 41

Assisted Solution

by:Kyle Abrahams
Kyle Abrahams earned 400 total points
ID: 39821891
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 83

Expert Comment

by:David Johnson, CD, MVP
ID: 39821989
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
Veeam Task Manager for Hyper-V

Task Manager for Hyper-V provides critical information that allows you to monitor Hyper-V performance by displaying real-time views of CPU and memory at the individual VM-level, so you can quickly identify which VMs are using host resources.

 
LVL 65

Assisted Solution

by:btan
btan earned 800 total points
ID: 39822944
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 33

Assisted Solution

by:shalomc
shalomc earned 400 total points
ID: 39826766
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 65

Assisted Solution

by:btan
btan earned 800 total points
ID: 39827105
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

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Happy holidays! Your Ops team can pack their bags. IT management and IT management tools are dead. Or at least that’s according to a new blog from Tech Target on AWS’s new Managed Services (MS) offering.
As tax season makes its return, so does the increase in cyber crime and tax refund phishing that comes with it
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.

596 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