Best Practices For Security Patch Management - WECC

2y ago
758.03 KB
46 Pages
Last View : 9d ago
Last Download : 3m ago
Upload by : Abby Duckworth

Tyson JarrettCIP Enforcement AnalystBest Practices for Security Patch ManagementOctober 24, 2013Anaheim, CA

A little about me Graduated from the University of Utah witha Masters in Information Systems Have been with WECC for 2 years 11months Reviewed 1,407 CIP items Ran my first Marathon this Month2

Wrong reasons to Patch

Why Patch Management Cyber Security Patches are key to avertmany known vulnerabilities to Cyber Assetsand the environment Identified by ICS – Cert as one of the topsecurity challenges within Industrial ControlSystems Most importantly Requested by YOU!!4

Intent of CIP 007 R3 The intent of R3 is to know, track, andmitigate known software vulnerabilitiesassociated with BPS Cyber Assets. It is notintended as an “install every security patch”requirement; instead it should beconsidered more of a “be aware of in atimely manner, and manage all knownvulnerabilities” requirement.5

CIP 007-3 R3 Security Patch Management — The Responsible Entity, eitherseparately or as a component of the documented configurationmanagement process specified in CIP-003-3 Requirement R6,shall establish, document and implement a security patchmanagement program for tracking, evaluating, testing, andinstalling applicable cyber security software patches for allCyber Assets within the Electronic Security Perimeter(s).o R3.1. The Responsible Entity shall document the assessment ofsecurity patches and security upgrades for applicability within thirtycalendar days of availability of the patches or upgrades.o R3.2. The Responsible Entity shall document the implementation ofsecurity patches. In any case where the patch is not installed, theResponsible Entity shall document compensating measure(s) appliedto mitigate risk exposure.6

Agenda Tracking, Evaluating, Testing, and Installingapplicable cyber security software patcheso Common Pitfallso Best Practiceso Audit/Enforcement Approach7


Tracking – Common Pitfall #1Only tracking patches available at theOperating System level Entity only tracks patches with Windows ServerUpdate Service (WSUS)o WSUS does not actively identify or track otherapplications and/or software running on the Windowsboxo Thus all third-party applications on the device are notbeing actively tracked9

Tracking – Common Pitfall #2Not maintaining appropriate documentation Including:o Incomplete or inaccurate list of devices andapplications running on those deviceso Not knowing or documenting where patchreleases are located. Leads to systems not getting patched for knownsecurity vulnerabilities10

Tracking – Best PracticesPatch h andUpgradesourceidentificationPatch Tracking Process

Tracking – Best Practices Asset Identificationo Ensure all applicable cyber assetsare documented Leverage other CIP requirements(CIP 002 R3 and CIP 005 R1.6) whenidentifying assets. Include step to periodically verifyaccuracy of list12o Use combination of automated toolsand manual walkthroughs/verifications to ensure list isaccuratePaPatcha tc ideenntificationioonPatPatchPPaatctch anandandUpgradesourceidentification

Tracking – Best Practices Patch/Upgrade Identificationo Identify and document allapplications, Operating Systems,sand firmware on cyber assets Minimize applications on CIP 007applicable devices to only what isnecessary Include steps to periodically verifyaccuracy of list13AssetAsset Patch andIdentificaentifica Upgradetiontion identificationtiPatPatchPPaatctch antchandandUpgradesourceidentification

Tracking – Best Practices Patch/Upgrade Source identification andnotificationo Where are the patches located?o How will you get notified of a new patch?Patch andAssetAsset Upgradeentific sourceIdentificattionidentificationaationidonn Vendor email Manually visiting webpage Automated scanner (WSUS, patch managementsoftware)o Implement periodic manual checks to verifyautomated solutions are functioning properly14Patch andUpgradeidentification

Tracking – Best Practices Patch Management toolsooooo15Commercial SoftwareDatabaseSpreadsheetPaper Don’t do this!!Brain Don’t do this!!

Tracking – Best Practices Commercial VendorProsConsBuilt with the intent to trackand manage patches andupgradesEvidence presentation andretention may need additionalplanningVendor support can reduceneed for in-house expertiseResearch needs to be done aheadof time to ensure the right productis chosenCan come with usefulfeatures Asset identification, automatednotifications, baseline creation andupdate, vulnerability scanning See SANS – “A Practical Methodology forImplementing a Patch managementProcess” for 9 items to consider whenpicking an automated solution. (PG. 7)

Tracking – Best Practices Some Commercial Vendors17

Tracking – Best Practices DatabaseProsReduces redundancyReporting features allow forevidence retrievalCan reduce data entry,storage, and retrieval costsConsCan be complex and difficult toimplementNot always practical to buildfrom scratchMay need new personnelfamiliar with creating andmaintaining a database Personnel may need additionaltraining

Tracking – Best Practices SpreadsheetProsEasy to implementLow costConsUpdating data can be difficult and often requirescreating a new spreadsheet to maintain historicalevidenceCan require repetition with other processes forupdating data Current patch version, work orders, etcUseful information usually needs to be storedon another spreadsheet. What devices have what applications/OS/firmware Where patches are located How are notifications being received

Tracking – Audit Approach Maintain documented procedures fortracking patches and updates Evidence of actively monitoring all availablesoftware and firmwareo Develop a list of all monitored applications/OS/firmwareo Identify and document process and location fornotifications of updateso All applications/Operating Systems/firmware thatMAY receive security patches must be accounted forin Patch Management tracking procedures.200


Evaluating – Common Pitfall #1 Relying on Industrial Control System (ICS)vendor to evaluate applicability of patcheso Due to fear of voiding warranty with ICS vendorentity leaves all patch managementresponsibilities to the ICS vendoro Entity does not have procedures or timeline inplace for evaluating patch applicability22

Evaluating – Common Pitfall #2 Not consistently evaluating patches within30 days of availabilityo Entity tracks patches once a month Thus entity continuously misses 30 day deadline asit does not have enough time to evaluate patcheso SMEs mis-read documentation and didn’t verifyif all software had patches available23

Evaluating – Best Practice Identifyo How assessment will bedocumentedo Specific personnelresponsible forassessing the patchesand upgrades Should have collaborationwith both IT andoperations staff244

Evaluating – Best Practice Implement a peer review process to verifyevaluations are done correctly andnecessary documentation is maintained Conduct periodic training on evaluationprocedures and required documentation25

Evaluating – Best Practice Plan aheado Track patches at least every two weeks toensure enough time is available to evaluatepatches within the required 30 days ofavailability26

Evaluating – Best Practice Don’t rely on ICS vendor to evaluatepatcheso Determining a patch is applicable will not voida warranty Entity’s may still elect to wait for ICS vendorapproval prior to installing a patcho ICS vendors are not required by CIP to assesspatches immediately, YOU are!27

Evaluating – Audit Approach Documented process for determining ifpatches and upgrades are applicableo An assessment should consist of determinationof the applicability of each patch to the entity’sspecific environment and systems. Applicabilitydetermination is based primarily on whether thepatch applies to a specific software or hardwarecomponent that the entity does have installed inan applicable Cyber Asset.28

Evaluating – Audit Approach Must maintain evidence of identification andevaluation of applicability within 30 days ofavailabilityo Evidence should include date patch or upgradewas made available, date it was evaluated, andevidence the documented evaluation processwas followed29


Testing – Common Pitfall #1 Patches areautomatically installed,and thus not tested priorto installationo Entity was unawaredevice was configured forautomated updating31

Testing – Common Pitfall #2 Conducted functional testing onlyo Entity’s testing procedures required securitypatches be installed in test system for 1 weekthen deployed to production if nothing broke Entity does not identify or documentsecurity controls impacted by the patchbeing installed32

Testing – Best Practices Use existing CIP 007-3 R1 Test Procedureso Don’t re-invent the wheel!! Specific Documentationo Identify what tests are performed when and why?o Who is responsible for conducting the testing? Who is responsible for approving the test?o What do the results of the testing mean? What is a pass or fail?33

Testing – Best Practices Implement peer review process to verifytesting was done per procedures Implement periodic follow-up testing tovalidate current testing procedures arecapturing data needed to make installationdecision34

Testing – Best Practice Disable automaticupdateso Configure software tonotify but not installo Implement verificationprocess to periodicallycheck for any caseswhere patches aren’tbeing tested35

Testing – Audit Approach At minimum must be compliant with CIP007 R1 testing procedureso From CIP 007-3 R1 “a significant change shall,at minimum, include implementation of securitypatches”o Technical narrative describing testingenvironment(s) Include how is test environment similar/ dissimilar toproduction environment36

Testing – Audit Approach Documented testing procedures for each cyberasset (or asset type) within the ESP At minimum testing needs to ensure existingsecurity controls are not adversely affectedo Before and after the test identify and document portsand services, user accounts, Logging/Alertingfunctionality, and anti-virus. Controls should be in place to protect productionenvironmento Separate test environmento Back out plan37


Installing - Common Pitfalls Not updating baseline after the change ismadeo Personnel were unaware who wassupposed to update the baselinedocumentationo Procedures didn’t explicitly call outupdating documentation39

Installing – Best Practice Leverage CIP 003 R6 Change Control andConfiguration Management procedureso When installing a security patcho Following procedures during installo Updating baseline after the change Identify who is responsible for installing thepatch or upgrade and updatingdocumentation afterwards40

Installing – Best Practice Use checklists to help SMEs easily identifyall that is required as part of the installation Procedures should identify an acceptabletime frame to install an applicable patcho Note: Requirement does not specify a requiredtime to install a patch or upgrade Create a “back-out” plano Ensure backups and recovery plan are up todate and tested41

Installing - Audit Approach Documented procedures for installing securitypatches and upgradeso Evidence of installation of patches as defined indocumented procedures Evidence Documentationo Cyber Assets patch/upgrade was installed on Who installed the patcho Updated device baseline after installationo Date of installation42

Installing – Audit Approach If patch or upgrade is applicable butnot installed, must implement anddocument Compensating Measureso Additionally a Technical FeasibilityException (TFE) may need to besubmitted if the device will not beinstalling any new patches.43

Summary Procedures must include methods forTracking, Evaluating, Testing, and Installingsecurity patches Take extra time planning how patches willbe tracked and documented to lessenburden of patch management further downthe road Entity’s are responsible for compliance, notthe entity’s ICS vendor44

References Ben Christensen's “Root Cause Analysis forCommonly Violated Requirements” Sans “Practical Methodology forImplementing a Patch managementProcess” ICS – CERT “Improving Inductrial ControlSystems Cybersecurity with Defense-InDepth Strategies”45

Questions?Tyson JarrettCIP Enforcement

Automated scanner (WSUS, patch management software) o Implement periodic manual checks to verify automated solutions are functioning properly Tracking – Best Practices Patch and Upgrade identification Asset Identific ation Asset entific ation Patch and Upgrade source identification Patch and Upgrade identification Patch id onn

Related Documents:

Best Practices Whitepaper by: Chris Roberge, MCSE; CCNA Product Manager . SQL Server farms. Unfortunately, Slammer took all of nine minutes to spread worldwide. . let alone research and test one.) This event-based patching philosophy is akin to fixing the barn door after the Trojan horse has come home. The time to patch a given .File Size: 484KBPage Count: 22Explore further6 Steps for Effective Patch Management - Verve Industrialverveindustrial.com7 Steps For Proper Patch Management Process - Hacker Combathackercombat.comChapter 2: Patch Management Best Practiceswww.windowsecurity.comThree Principles of Patch Management: Ignore at Your Peril .jetpatch.comA Best Practice Approach to Third Party Patchingvox.veritas.comRecommended to you b

P a t c h M a n a g e m e n t 157 Chapter 5 - Patch Management Sadjadi et al. Chapter 5 - Patch Management 8. Missing Manual: The number of approved patches missing that must be installed manually.These patches cannot be processed by Patch Management Automatic Update, Patch Management Initial Update, Patch Management Machine Update, or Patch Management Patch Update.

Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original

PATCH PANEL LABELS A patch panel is a device or unit featuring a number of jacks, usually of the same or similar type, for the connecting and routing of circuits for monitoring, interconnecting, and testing circuits. Patch panels are commonly used in computer networking, recording studios, radio and television.File Size: 2MBPage Count: 9Explore furtherHow to Troubleshoot Patch Panel Connections?www.fiber-optic-transceiver-mo How to Label Patch Cables - Cable Labeling Guidelines FS Communitycommunity.fs.comWhat's a reliable way to test patch panel . - Server Faultserverfault.comPatch panel and cabling documentation - Cisco to you b

10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan

service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största

Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid

“Accounting is the art of recording, classifying and summarizing in a significant manner and in terms of money, transactions and events which are, in part at least, of a financial character, and interpreting the result thereof”. Definition by the American Accounting Association (Year 1966): “The process of identifying, measuring and communicating economic information to permit informed .