[prev in list] [next in list] [prev in thread] [next in thread]
List: patchmanagement
Subject: Re: [patchmanagement] Required Updates
From: Peter Tsamwa <secmwll () gmail ! com>
Date: 2017-06-29 14:11:32
Message-ID: CAAXm2RoQ3YBcHSwec+Hap2dyc_teXfUFH9CjAsSp3ycw=6zWHg () mail ! gmail ! com
[Download RAW message or body]
Good day Team,
Do you have a patching process document you can share, e.g.
(administrative) guidelines and policies. i want to adopt for my
environment.
You can send it to my gmail
Best Regards
Peter
secmwll@gmail.com
System Administrator
On Thu, Jun 29, 2017 at 3:28 AM, Luke Murray <Luke.Murray@wintec.ac.nz>
wrote:
> Agree with taking the aggressive patching schedule and forcing a deadline
> with a max of a week after original deployment.
>
> There is always the mix between giving the users enough time to defer the
> updates and making sure that devices don't reboot during the work day. But
> my personal opinion is as long as there is a notification to the user that
> the device will restart in x time and to save work there usually shouldn't
> be a problem and if there is - the patches can either be rolled back or PC
> replaced with one from the storeroom.
>
> There is a certain amount of awareness - if users are aware that it is
> that time of month again - they should be prepared for it and soon should
> have it as the norm. If IT changes the way things are done often, it causes
> more confusions and Incidents raised.
>
> 1. Deploy to Test/Dev pilot group on Day 1
> 2. 3-4 days later deploy to Production
>
> Kind regards
>
> Luke Murray
> Snr Infrastructure Engineer
> Wintec
> Private Bag 3036, Waikato Mail Centre, Hamilton 3240
> Phone: +64-(0)7-834 8800 ext 3343
> Fax: +64-(0)7-
> Email: Luke.Murray@wintec.ac.nz
> Web: http://www.wintec.ac.nz/
>
>
>
>
>
>
> -----Original Message-----
> From: Mike Cramer [mailto:mcramer@blizzard.com]
> Sent: Tuesday, 27 June 2017 6:17 AM
> To: Patch Management Mailing List <patchmanagement@listserv.
> patchmanagement.org>
> Subject: RE:[patchmanagement] Required Updates
>
> While I can't divulge our patching strategy, I will say that on a personal
> level I feel aggressive patching schedules should be the norm. I feel like
> extended validation testing is neither necessary nor beneficial, and can be
> dangerous in today's landscape.
>
> Approach patching with a sense that vulnerabilities become weaponizable
> the moment Microsoft publishes the patch. And at this point it is a race to
> patch your systems before the vulnerability can be used against you. This
> isn't always the case with every patch, just like it isn't always the case
> that you should ONLY be concerned when these things make the news (See:
> Wannacry). You should effectively treat every Patch Tuesday as if it were
> the next Wannacry.
>
> Your patch schedule should be something similar:
>
> 1. Deploy to Test Environment on Day 1.
> 2. A/B production server deployment after smoke testing complete.
> 3. Limited Client Rollout after smoke testing complete.
> 4. Full client deployment after limited rollout.
>
> You should be performing Steps 2 & 3 at around the same timeframe.
>
> I'd say you should be done full deployment a maximum of 7 calendar days
> after release. If you encounter a problem with the patch, open a support
> case.
>
> Also, deploy the full "Security Monthly Quality Rollup" patches and not
> just the "Security Only" patches. The fear that the former are at risk of
> breaking more things in my experience is unfounded. In a recent patch for
> Windows Server 2012 for Domain Controllers it was the "Security Only" patch
> that broke DCs while the full patch did not. (See: April Security Only
> Rollup for Windows Server 2012).
>
> An aggressive patch schedule is probably one of the best things you can do
> for your environment over any other thing you could possibly do for
> protection, and in some cases could help save money on solution expenses.
>
> -Mike
>
> -----Original Message-----
> From: Leon Lecky [mailto:leon.lecky@EF.com]
> Sent: Monday, June 26, 2017 9:29 AM
> To: Patch Management Mailing List <patchmanagement@listserv.
> patchmanagement.org>
> Subject: RE:[patchmanagement] Required Updates
>
> I agree with regards to your balance statement, I think we are a bit over
> cautious with regards for testing and pushing out to production so soon.
> It's interesting to know how a lot of people are pushing out updates within
> 1-2 weeks from being released.
>
> Best Regards,
>
> Leon Lecky
> Workstation Analyst, Global IT
>
>
> -----Original Message-----
> From: Steve Yates [mailto:steve@teamITS.com]
> Sent: 26 June 2017 15:49
> To: Patch Management Mailing List <patchmanagement@listserv.
> patchmanagement.org>
> Subject: RE:[patchmanagement] Required Updates
>
> Yeah I didn't really answer your question, sorry. We send to our test
> group the week the updates come out and target deploying to workstations
> the following Monday night/Tuesday morning. Patching is basically a
> balance between "don't want to break something" and "how likely is it a PC
> will get infected and take down the network/company." For 2+ months I
> would ensure management understood the implications of the infection choice
> so my butt wasn't on the line when it happens...
>
> --
>
> Steve Yates
> ITS, Inc.
>
> -----Original Message-----
> From: Leon Lecky [mailto:leon.lecky@EF.com]
> Sent: Monday, June 26, 2017 3:25 AM
> To: Patch Management Mailing List <patchmanagement@listserv.
> patchmanagement.org>
> Subject: RE:[patchmanagement] Required Updates
>
> HI Steve
>
> We are using SCCM to control these updates, that is another issue I
> haven't thought of as well. I'm going to push through management to try get
> these updates out earlier.
>
> How long does it take till you push out updates from patch Tuesday?
>
> Best Regards,
>
> Leon Lecky
> Workstation Analyst, Global IT
>
> -----Original Message-----
> From: Steve Yates [mailto:steve@teamITS.com]
> Sent: 23 June 2017 19:46
> To: Patch Management Mailing List <patchmanagement@listserv.
> patchmanagement.org>
> Subject: RE:[patchmanagement] Required Updates
>
> What are you using to control updates?
>
> I've brought this up before, though possibly not this list...if a PC is
> off from March to say June 15, it won't be able to see the "approved" May
> monthly update from Windows Update. If it is off for a month at a time,
> the cycle repeats...
>
> --
>
> Steve Yates
> ITS, Inc.
>
> From: Leon Lecky [mailto:leon.lecky@EF.com]
> Sent: Friday, June 23, 2017 12:12 PM
> To: Patch Management Mailing List <patchmanagement@listserv.
> patchmanagement.org>
> Subject: [patchmanagement] Required Updates
>
> Hi Everyone
>
> We have a patching life cycle that follows:
>
> Example: June's Patch Tuesday (13th June) > Deployed to Pilot collection
> June's Last Friday (30th June) > Deployed to Test-Ring
> collection
> July's Last Friday (28th July) > Deployed to Fast-Ring
> collection
> August's Last Friday (25th August) > Deployed to
> Production collection
>
> However Junes updates will no longer been seen when it reaches August
> because it has been superseded twice.
>
> We have a dilemma here where computers are no longer seen as required for
> these patches when or life cycle goes into production.
>
> It be good to know from everyone here:
> . Does everyone deploy out patches to their whole estate before it is 60
> days or older or superseded twice?
> . Is it possible to tweak the required numbers so all machines can been
> seen as required again?
>
> Any response will be appreciated!
>
>
> Leon Lecky
> Workstation Analyst, Global IT
>
>
> ---
> PatchManagement.org is hosted by Shavlik
>
> The content on the email list is intended for assisting administrators.
> If you would like to use any of this content in a blog or media
> publication, please contact the owners of the list for approval.
>
> To unsubscribe send a blank email to leave-patchmanagement@
> patchmanagement.org
> If you are unable to unsubscribe via this email address, please email
> owner-patchmanagement@patchmanagement.org
>
>
> ---
> PatchManagement.org is hosted by Shavlik
>
> The content on the email list is intended for assisting administrators.
> If you would like to use any of this content in a blog or media
> publication, please contact the owners of the list for approval.
>
> To unsubscribe send a blank email to leave-patchmanagement@
> patchmanagement.org
> If you are unable to unsubscribe via this email address, please email
> owner-patchmanagement@patchmanagement.org
>
>
> ---
> PatchManagement.org is hosted by Shavlik
>
> The content on the email list is intended for assisting administrators.
> If you would like to use any of this content in a blog or media
> publication, please contact the owners of the list for approval.
>
> To unsubscribe send a blank email to leave-patchmanagement@
> patchmanagement.org
> If you are unable to unsubscribe via this email address, please email
> owner-patchmanagement@patchmanagement.org
>
> ________________________________
>
>
> This electronic mail transmission is intended for the named recipients
> only. It may contain private and confidential information. If this has come
> to you in error you must take no action based upon it, nor must you copy it
> or show it to anyone; please telephone or email the sender at Wintec
> immediately and return the original email. We cannot accept any liability
> for any loss or damage sustained as a result of software viruses. It is
> your responsibility to carry out such virus checking as is necessary before
> opening any attachment which may be included with this message.
>
> ---
> PatchManagement.org is hosted by Shavlik
>
> The content on the email list is intended for assisting administrators.
> If you would like to use any of this content in a blog or media
> publication, please contact the owners of the list for approval.
>
> To unsubscribe send a blank email to leave-patchmanagement@
> patchmanagement.org
> If you are unable to unsubscribe via this email address, please email
> owner-patchmanagement@patchmanagement.org
>
>
---
PatchManagement.org is hosted by Shavlik
The content on the email list is intended for assisting administrators. If you would \
like to use any of this content in a blog or media publication, please contact the \
owners of the list for approval.
To unsubscribe send a blank email to leave-patchmanagement@patchmanagement.org
If you are unable to unsubscribe via this email address, please email
owner-patchmanagement@patchmanagement.org
[Attachment #3 (text/html)]
<div dir="ltr">Good day Team,<div><br></div><div>Do you have a patching process \
document you can share, e.g. (administrative) guidelines and policies. i want to \
adopt for my environment.</div><div><br></div><div>You can send it to my \
gmail</div><div><br></div><div>Best Regards</div><div>Peter</div><div><a \
href="mailto:secmwll@gmail.com">secmwll@gmail.com</a></div><div>System \
Administrator</div></div><div class="gmail_extra"><br><div class="gmail_quote">On \
Thu, Jun 29, 2017 at 3:28 AM, Luke Murray <span dir="ltr"><<a \
href="mailto:Luke.Murray@wintec.ac.nz" \
target="_blank">Luke.Murray@wintec.ac.nz</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Agree with taking the aggressive patching schedule and \
forcing a deadline with a max of a week after original deployment.<br> <br>
There is always the mix between giving the users enough time to defer the updates and \
making sure that devices don't reboot during the work day. But my personal \
opinion is as long as there is a notification to the user that the device will \
restart in x time and to save work there usually shouldn't be a problem and if \
there is - the patches can either be rolled back or PC replaced with one from the \
storeroom.<br> <br>
There is a certain amount of awareness - if users are aware that it is that time of \
month again - they should be prepared for it and soon should have it as the norm. If \
IT changes the way things are done often, it causes more confusions and Incidents \
raised.<br> <br>
1. Deploy to Test/Dev pilot group on Day 1<br>
2. 3-4 days later deploy to Production<br>
<br>
Kind regards<br>
<br>
Luke Murray<br>
Snr Infrastructure Engineer<br>
Wintec<br>
Private Bag 3036, Waikato Mail Centre, Hamilton 3240<br>
Phone: <a href="tel:%2B64-%280%297-834%208800%20ext%203343" \
value="+6478348800">+64-(0)7-834 8800 ext 3343</a><br>
Fax: +64-(0)7-<br>
Email: <a href="mailto:Luke.Murray@wintec.ac.nz">Luke.Murray@wintec.ac.nz</a><br>
Web: <a href="http://www.wintec.ac.nz/" rel="noreferrer" \
target="_blank">http://www.wintec.ac.nz/</a><br> <div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Mike Cramer [mailto:<a \
href="mailto:mcramer@blizzard.com">mcramer@blizzard.com</a>]<br>
Sent: Tuesday, 27 June 2017 6:17 AM<br>
To: Patch Management Mailing List <<a \
href="mailto:patchmanagement@listserv.patchmanagement.org">patchmanagement@listserv.<wbr>patchmanagement.org</a>><br>
Subject: RE:[patchmanagement] Required Updates<br>
<br>
While I can't divulge our patching strategy, I will say that on a personal level \
I feel aggressive patching schedules should be the norm. I feel like extended \
validation testing is neither necessary nor beneficial, and can be dangerous in \
today's landscape.<br> <br>
Approach patching with a sense that vulnerabilities become weaponizable the moment \
Microsoft publishes the patch. And at this point it is a race to patch your systems \
before the vulnerability can be used against you. This isn't always the case with \
every patch, just like it isn't always the case that you should ONLY be concerned \
when these things make the news (See: Wannacry). You should effectively treat every \
Patch Tuesday as if it were the next Wannacry.<br> <br>
Your patch schedule should be something similar:<br>
<br>
1. Deploy to Test Environment on Day 1.<br>
2. A/B production server deployment after smoke testing complete.<br>
3. Limited Client Rollout after smoke testing complete.<br>
4. Full client deployment after limited rollout.<br>
<br>
You should be performing Steps 2 & 3 at around the same timeframe.<br>
<br>
I'd say you should be done full deployment a maximum of 7 calendar days after \
release. If you encounter a problem with the patch, open a support case.<br> <br>
Also, deploy the full "Security Monthly Quality Rollup" patches and not \
just the "Security Only" patches. The fear that the former are at risk of \
breaking more things in my experience is unfounded. In a recent patch for Windows \
Server 2012 for Domain Controllers it was the "Security Only" patch that \
broke DCs while the full patch did not. (See: April Security Only Rollup for Windows \
Server 2012).<br> <br>
An aggressive patch schedule is probably one of the best things you can do for your \
environment over any other thing you could possibly do for protection, and in some \
cases could help save money on solution expenses.<br> <br>
-Mike<br>
<br>
-----Original Message-----<br>
From: Leon Lecky [mailto:<a \
href="mailto:leon.lecky@EF.com">leon.lecky@EF.com</a>]<br>
Sent: Monday, June 26, 2017 9:29 AM<br>
To: Patch Management Mailing List <<a \
href="mailto:patchmanagement@listserv.patchmanagement.org">patchmanagement@listserv.<wbr>patchmanagement.org</a>><br>
Subject: RE:[patchmanagement] Required Updates<br>
<br>
I agree with regards to your balance statement, I think we are a bit over cautious \
with regards for testing and pushing out to production so soon. It's interesting \
to know how a lot of people are pushing out updates within 1-2 weeks from being \
released.<br> <br>
Best Regards,<br>
<br>
Leon Lecky<br>
Workstation Analyst, Global IT<br>
<br>
<br>
-----Original Message-----<br>
From: Steve Yates [mailto:<a \
href="mailto:steve@teamITS.com">steve@teamITS.com</a>]<br>
Sent: 26 June 2017 15:49<br>
To: Patch Management Mailing List <<a \
href="mailto:patchmanagement@listserv.patchmanagement.org">patchmanagement@listserv.<wbr>patchmanagement.org</a>><br>
Subject: RE:[patchmanagement] Required Updates<br>
<br>
Yeah I didn't really answer your question, sorry. We send to our test group the \
week the updates come out and target deploying to workstations the following Monday \
night/Tuesday morning. Patching is basically a balance between "don't want \
to break something" and "how likely is it a PC will get infected and take \
down the network/company." For 2+ months I would ensure management understood \
the implications of the infection choice so my butt wasn't on the line when it \
happens...<br> <br>
--<br>
<br>
Steve Yates<br>
ITS, Inc.<br>
<br>
-----Original Message-----<br>
From: Leon Lecky [mailto:<a \
href="mailto:leon.lecky@EF.com">leon.lecky@EF.com</a>]<br>
Sent: Monday, June 26, 2017 3:25 AM<br>
To: Patch Management Mailing List <<a \
href="mailto:patchmanagement@listserv.patchmanagement.org">patchmanagement@listserv.<wbr>patchmanagement.org</a>><br>
Subject: RE:[patchmanagement] Required Updates<br>
<br>
HI Steve<br>
<br>
We are using SCCM to control these updates, that is another issue I haven't \
thought of as well. I'm going to push through management to try get these updates \
out earlier.<br> <br>
How long does it take till you push out updates from patch Tuesday?<br>
<br>
Best Regards,<br>
<br>
Leon Lecky<br>
Workstation Analyst, Global IT<br>
<br>
-----Original Message-----<br>
From: Steve Yates [mailto:<a \
href="mailto:steve@teamITS.com">steve@teamITS.com</a>]<br>
Sent: 23 June 2017 19:46<br>
To: Patch Management Mailing List <<a \
href="mailto:patchmanagement@listserv.patchmanagement.org">patchmanagement@listserv.<wbr>patchmanagement.org</a>><br>
Subject: RE:[patchmanagement] Required Updates<br>
<br>
What are you using to control updates?<br>
<br>
I've brought this up before, though possibly not this list...if a PC is off from \
March to say June 15, it won't be able to see the "approved" May \
monthly update from Windows Update. If it is off for a month at a time, the cycle \
repeats...<br> <br>
--<br>
<br>
Steve Yates<br>
ITS, Inc.<br>
<br>
From: Leon Lecky [mailto:<a \
href="mailto:leon.lecky@EF.com">leon.lecky@EF.com</a>]<br>
Sent: Friday, June 23, 2017 12:12 PM<br>
To: Patch Management Mailing List <<a \
href="mailto:patchmanagement@listserv.patchmanagement.org">patchmanagement@listserv.<wbr>patchmanagement.org</a>><br>
Subject: [patchmanagement] Required Updates<br>
<br>
Hi Everyone<br>
<br>
We have a patching life cycle that follows:<br>
<br>
Example: June's Patch Tuesday (13th June) > Deployed to Pilot collection<br>
June's Last Friday (30th June) > Deployed to \
Test-Ring collection<br>
July's Last Friday (28th July) > Deployed to \
Fast-Ring collection<br>
August's Last Friday (25th August) > \
Deployed to Production collection<br> <br>
However Junes updates will no longer been seen when it reaches August because it has \
been superseded twice.<br> <br>
We have a dilemma here where computers are no longer seen as required for these \
patches when or life cycle goes into production.<br> <br>
It be good to know from everyone here:<br>
. Does everyone deploy out patches to their whole estate before it is 60 days or \
older or superseded twice?<br>
. Is it possible to tweak the required numbers so all machines can been seen as \
required again?<br> <br>
Any response will be appreciated!<br>
<br>
<br>
Leon Lecky<br>
Workstation Analyst, Global IT<br>
<br>
<br>
---<br>
PatchManagement.org is hosted by Shavlik<br>
<br>
The content on the email list is intended for assisting administrators. If you \
would like to use any of this content in a blog or media publication, please contact \
the owners of the list for approval.<br> <br>
To unsubscribe send a blank email to <a \
href="mailto:leave-patchmanagement@patchmanagement.org">leave-patchmanagement@<wbr>patchmanagement.org</a><br>
If you are unable to unsubscribe via this email address, please email <a \
href="mailto:owner-patchmanagement@patchmanagement.org">owner-patchmanagement@<wbr>patchmanagement.org</a><br>
<br>
<br>
---<br>
PatchManagement.org is hosted by Shavlik<br>
<br>
The content on the email list is intended for assisting administrators. If you \
would like to use any of this content in a blog or media publication, please contact \
the owners of the list for approval.<br> <br>
To unsubscribe send a blank email to <a \
href="mailto:leave-patchmanagement@patchmanagement.org">leave-patchmanagement@<wbr>patchmanagement.org</a><br>
If you are unable to unsubscribe via this email address, please email <a \
href="mailto:owner-patchmanagement@patchmanagement.org">owner-patchmanagement@<wbr>patchmanagement.org</a><br>
<br>
<br>
---<br>
PatchManagement.org is hosted by Shavlik<br>
<br>
The content on the email list is intended for assisting administrators. If you \
would like to use any of this content in a blog or media publication, please contact \
the owners of the list for approval.<br> <br>
To unsubscribe send a blank email to <a \
href="mailto:leave-patchmanagement@patchmanagement.org">leave-patchmanagement@<wbr>patchmanagement.org</a><br>
If you are unable to unsubscribe via this email address, please email <a \
href="mailto:owner-patchmanagement@patchmanagement.org">owner-patchmanagement@<wbr>patchmanagement.org</a><br>
<br>
</div></div>______________________________<wbr>__<br>
<br>
<br>
This electronic mail transmission is intended for the named recipients only. It may \
contain private and confidential information. If this has come to you in error you \
must take no action based upon it, nor must you copy it or show it to anyone; please \
telephone or email the sender at Wintec immediately and return the original email. We \
cannot accept any liability for any loss or damage sustained as a result of software \
viruses. It is your responsibility to carry out such virus checking as is necessary \
before opening any attachment which may be included with this message.<br> <div \
class="HOEnZb"><div class="h5"><br>
---<br>
PatchManagement.org is hosted by Shavlik<br>
<br>
The content on the email list is intended for assisting administrators. If you \
would like to use any of this content in a blog or media publication, please contact \
the owners of the list for approval.<br> <br>
To unsubscribe send a blank email to <a \
href="mailto:leave-patchmanagement@patchmanagement.org">leave-patchmanagement@<wbr>patchmanagement.org</a><br>
If you are unable to unsubscribe via this email address, please email<br>
<a href="mailto:owner-patchmanagement@patchmanagement.org">owner-patchmanagement@<wbr>patchmanagement.org</a><br>
<br>
</div></div></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic