One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 619458 |
| Date de publication | 2018-04-30 13:00:00 (vue: 2018-04-30 19:11:02) |
| Titre | Patching Frequency Best Practices |
| Texte |
A client asked the other day for guidance on best practices regarding how often they ought to patch their systems. My immediate thought was “continuously.” However, most small to mid-sized enterprises don’t have the resources for that.
If you go to a source such as the Center for Internet Security they talk about patching as a critical security control and say you need a formalized program of patch management to “regularly update all apps, software, and operating systems.” But they don’t say much about how or how often this should be done.
Patching Frequency Best Practices from DoD
So, I hearkened back to the days when I was performing security audits for the Army. I probably did more than 500 of these on every type of system – from a small, rack-mounted tactical command & control server in the back of a Humvee to a 350,000-user wide area network in all 50 states. I started in the 1990s with the Department of Defense (DoD) Information Technology Security Certification & Accreditation Process (DITSCAP), and then moved to the DoD Information Assurance Certification and Accreditation Process (DIACAP), and finally the Risk Management Framework (RMF) that is in use today.
Typically, whenever we assessed those Army systems, if they had any missing patches or antivirus updates for more than a week, we would fail them. But when I researched this recently, I couldn’t find an Army or DoD reference to support this timeframe. You would think the DoD would have a best practice in place for that!
The Defense Information Systems Agency (DISA) publishes Security Technical Implementation Guides (STIGs), which are checklists for security hardening of information systems/software “that might otherwise be vulnerable to a malicious computer attacks.” These outline security best practices for a variety of technologies – e.g., Windows OS, networking devices, database, Web, etc.
The STIGs serve as the reference guides for all of DoD and represent what I would call “high assurance” best practices. In fact, we used to joke that if you followed all of the STIG guidance, you would “brick” your system! There is, of course, always a tradeoff between system security and usability.
There is also doctrine on security controls (including patching /updates) in various guides such as the NIST SP 800-53 Risk Management Framework the DoD Cybersecurity Discipline Implementation Plan.
Upon examining all of these, I found that they actually provide varying advice on patching/update frequency – based on the criticality of the system, level of data being processed, or criticality/impact of the patches to be implemented.
The current objective for all patching in the DoD, according the Cybersecurity Discipline Implementation Plan, dated February 2016 is: “All DoD information systems have current patches within 21 days of IAVA patch release.” In addition: “Systems with high risk security weaknesses that are over 120 days overdue will be removed from the network.”
Note that an IAVA is an Information Management Vulnerabil |
| Envoyé | Oui |
| Condensat | “all “continuously “high “regularly “systems “that my /updates 000 120 1990s 2016 350 500 800 abacode about accordance according accreditation actually addition: addressed advice advice on agency alert alienvault all also always and/or antivirus any anyone anything anywhere applications applied apply apps are area army asked assessed assurance assurance” attacks audits automated average back bandwidth based basis before being besides best between branches break bugtraq built bulletins but call can center cert certification check checklists classic client cloud code command commands commercial comprehensive computer continuous control controls couldn’t course critical criticality criticality/impact current current objective for cyber cybersecurity cycle cycle data database dated daunting day days deal defense department depending deploying desktop devices diacap did disa discipline distribution ditscap doctrine dod does don’t done down download duties emergency engage enterprise enterprises environment establish etc every examining exchange expertise exploit fact fail february feed finally find folks followed following formalized forth found framework frequency frequency: from general generally given good government guidance guides had handle hardening has have hearkened high highest hours how however humvee hybrid iava iavas iavbs iavm immediate immediately implementation implemented including information install installed internet is: joke just keep know latest least level list mailing make makes malicious manage managed management management manner may mechanism methods mid might military misconfigurations missing monthly more most mounted moved mssp much must national need network networking nist not note often one open operating organizations other otherwise otx ought outline over overdue patch patched patches patching patching/update performing place plan practice practices practices: premises probably process process: processed program promulgated provide varying provider published publishes pulse quarterly rack recently reference regarding regression release removed report reports represent require research researched resources response risk rmf run running say scan scanner scans scheduled security sense serve server service services severity short should sized small software someone sounds source staging started starts states stay stig stigs such summarize support sure system systems systems/software tactical talk team technical technologies technology test testing than them then these think those thought threat threats timeframe timely today top tradeoff type typically unified update updates upon usability use used user using usm utilizing varies variety various vulnerabilities vulnerability vulnerable waiting want weaknesses web week weekly weighting what when whenever which who wide will windows within would your |
| Tags | |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.