Options

Patch Management Policy

4_lom4_lom Member Posts: 485
I have to create a patch management policy for our clients. Just wondering if you guys have any general ideas or advice?
Goals for 2018: MCSA: Cloud Platform, AWS Solutions Architect, MCSA : Server 2016, MCSE: Messaging

Comments

  • Options
    N2ITN2IT Inactive Imported Users Posts: 7,483 ■■■■■■■■■■
    Was it a proposal or you just flat out created it? I would think you would/should discuss this with your clients before it "goes live".

    Just my thoughts. I created a patch management release plan for the Linux/Unix boxes at my last position. It was high-level and needed their sign off before we started to discuss the fine details about the plan.
  • Options
    paul78paul78 Member Posts: 3,016 ■■■■■■■■■■
    A couple of things to also think about in the policy:

    1) who approves
    2) how often patches must be deployed I.e - patch cycle
    3) are there different classifications of patches (emergency patches, compliance patches) - for example - if a patch is for a invulnerability with exploits-in-the-wild with high impact - does it go in mid-cycle.
    4) what level of testing is required prior to deployment
    5) Monitoring for new patches - who does it
    6) Release communications - what stakeholders need to be notified.
    7) Maintainence windows - for example - if a patch requires a reboot, will it be deployed diffirently.
    icon_cool.gif Compliance monitoring - how do you track that patches are deployed - is there an automated scanner that will be used to do out-of-band validation
    9) Post-deployment testing - what testing is done after a patch is deployed.
  • Options
    4_lom4_lom Member Posts: 485
    4_lom wrote: »
    I have to create a patch management policy for our clients. Just wondering if you guys have any general ideas or advice?

    I was assigned the task of creating it. My current proposal does heavily involve client decisions. I was just asking for general ideas regarding patching schedules, guidelines, etc. Just general ideas...
    Goals for 2018: MCSA: Cloud Platform, AWS Solutions Architect, MCSA : Server 2016, MCSE: Messaging

  • Options
    ChooseLifeChooseLife Member Posts: 941 ■■■■■■■□□□
    paul's got pretty much all of it covered. One more point (sort of combining #3 and #8 from this list) is that patches of different criticality may have varying, but mandatory deadlines. E.g.
    "Critical patches must be installed within 30 days of their release"
    "Non-crititical patches must be installed within 90 days of their release"
    “You don’t become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process.” (c) xkcd #896

    GetCertified4Less
    - discounted vouchers for certs
  • Options
    afcyungafcyung Member Posts: 212
    NIST does a great job of putting out pubs for various INFOSEC topics. The below is patch/vulnerability management.
    Paul hit the major points.



    http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf
  • Options
    paul78paul78 Member Posts: 3,016 ■■■■■■■■■■
    4_lom wrote: »
    My current proposal does heavily involve client decisions.
    You may want to reconsider having customers involved in the decisioning process for patching. What type of business you are in can also influence the level of involvement that customers can play.

    For example, if your business is providing an ASP solution, I recommend not involving any customer. Customers should be "inform" only for emergency patches that occur outside a standard maintainence window or if patch review has high risk of adverse impact. All other patches can be standard operating procedure. You can have a policy item that states that customerr contracts have provisions for standard maintainence which include patching. This limits issues with competing customer requirements on patch scheduling.

    If your business is to provide managed infrastructure at customer sites, you can include the customer in decisioning but just be sure that your contracts allow for liabilty waivers if customers are not responsive to security patching requests.
Sign In or Register to comment.