How To Write A Cyber Security Checkout On A Nerc Webinar

Transcription

1 AS WE PREPARE FOR OUR WEBINAR Thanks to each of you for taking the time to participate in our Webinar today, which will provide extensive insight into what is required to address the Version 5 NERC Cyber Security Standards that focus on configuration change management and cyber vulnerability assessments. Our two hosts during the Webinar today at 11:30 AM Eastern Time: Wes Stewart: Before joining Encari as a Sr. NERC CIP Compliance Consultant last year, Wes worked with Southern Company for 14 years. After starting out as a systems analyst supporting computer systems used by the EMS department, Wes' career with Southern Company culminated with his fulfilling the Cyber Security Team Lead role for Southern Company's entire EMS environment. While with Encari, Wes has been assisting electric utilities address complex and diverse compliance issues primarily pertaining to the CIP-005 and CIP-00 7 through CIP-009 NERC Reliability Standards. Lenny Mansell: Lenny is Encari's Director of Consulting Services. Lenny has worked with numerous generation and transmission utilities to develop and apply methodologies to identify and document Critical Cyber Assets. Lenny also has extensive experience in designing, architecting and documenting ESPs, as well as in performing NERC CIP compliance gap assessments, focusing on NERC CIP Reliability Standards CIP-002 and CIP-005 thru CIP-007, and developing and executing accompanying NERC CIP compliance remediation strategies consisting of process, procedural, policy, and technological enhancements and refinements. Three administrative items: 1. If you have a question you would like to have addressed while the Webinar is underway, please type the question and send it to me using the "Question" feature within our Webinar interface. If we are unable to address your question during this Webinar, we will make sure to respond to the question soon thereafter. 2. You may need to transition to full-screen mode within the Webinar interface in order to see the entire contents of the slides that will be presented. 3. We will notify each of you via where you may download a copy of the presentation materials and transcribed questions raised during this Webinar along with Encari's responses to the questions from our Web site.

2 NERC CIP VERSION 5: NEW TECHNICAL CONSIDERATIONS Configuration Change Management Active Vulnerability Assessments Wes Stewart, CISSP Senior NERC CIP Compliance Consultant Lenny Mansell, CISSP Director, Consulting Services February 27, 2014

3 BASELINE CONFIGURATION CHANGE MANAGEMENT R1.1 (HIGH AND MED IMPACT) YOU VE GOT TO HAVE A BASELINE" CIP-010-1, R1.1 baseline configuration, individually or by group, which shall include the following items: Baseline Configurations now require us to record the following information elements at a minimum: OS w/ version software packages intentionally installed with versions any custom software installed any logical network accessible ports 2 any security patches applied

4 BASELINE CONFIGURATION CHANGE MANAGEMENT R1.2 AND R1.3 (HIGH AND MED IMPACT) DOCUMENT AND APPROVE CHANGES, UPDATE BASELINE" R 1.2 Authorize, document [changes which deviate from existing baseline configuration] Document Identify the proposed change from the baseline. Authorize Record the authorization to perform the change. R1.3 Update baseline within 30 days, completing change [for changes which deviate from existing baseline configuration] Baselines. The baseline needs to be updated within 30 days to account for the authorized, current state. NOTE: Completing the change does not mean you can open a 6-month, catch-all change ticket hoping to avoid having to update the documentation within 30 days 3

5 BASELINE CONFIGURATION CHANGE MANAGEMENT R1.4 (HIGH AND MED IMPACT) WHICH CONTROLS? VERIFY CONTROLS PRE AND POST ARE A MATCH R Prior[to change], determine controls could be impacted, [for changes which deviate from existing baseline configuration] Write down which of the baseline controls specifically are expected to be, OR could conceivably be, affected by the change. Consider using select all that apply. R & R1.4.3 Following [change], verify security controls not adversely affected and document verification results. Save the results of a side-by-side comparison of a pre-change vs. a post-change data collection which addresses all security configuration baseline minimum requirements 4

6 BASELINE CONFIGURATION CHANGE MANAGEMENT R1.5 (HIGH IMPACT ONLY) LET S ACTUALLY TRY THE CHANGE OUT IN THE TEST** ENVIRONMENT R1.5.1 and R1.5.2 Technically feasible, prior to production change, test changes [in a] test environment or production w/ minimize adverse effects, document results of testing of security controls Actually perform test changes in a test environment and save the results PRIOR to implementing in production. If test environment used, document how the test environment s security controls (005 and 007 ) differ from the production baseline security controls that are likely to be affected by the change ** One may also test changes in a production environment so long as it is done in a manner that minimizes adverse effects (you have to document how you achieve this) 5

7 BASELINE CONFIGURATION CHANGE MONITORING R2.1 (HIGH IMPACT ONLY) ARE ANY DEVICES RUNNING UNAUTHORIZED CONFIGS? PROVE IT EVERY 35 DAYS Monitor for changes to the baseline configuration for every device at least every 35 days. Document and investigate unauthorized changes that are detected changes to the baseline configuration, as it is used here, refers to the current running configuration of your devices (what it is) as compared to the documented baseline (what it should be). (what it is) vs. (what it should be) = EVIDENCE REs are going to need an easy way to perform this comparison monthly, from cradle to grave (i.e. data collection to annotation of results and finally storage in the evidence locker ). REs are going to perform THIS PROCESS all the time (over and over and over, etc.). 6

8 ACTION PLAN: BASELINE CONFIGURATION CHANGE MANAGEMENT AND MONITORING Develop methods to query your devices for all of the baseline configuration elements. Learn how to measure thyself. Write down specific steps to accomplish. We are striving for data collection methods which are: Repeatable same every time Sufficient demonstrates compliance, hands down Safe Doesn t crash BES Cyber Assets Easy Maintain or increase current levels of employee sanity, decrease job frustration, increase happiness (these things are really valuable to sustainable compliance) Develop methods to compare running configurations against baseline configurations (DIFF running vs. baseline). Include room to annotate acceptable, expected differences on a line item basis. Strive to maximize automation of the process which collects configs and performs two comparisons: pre-change vs. baseline; and post-change vs. baseline Save the side-by-side comparisons as evidence 7

9 V5VULNERABILITY ASSESSMENT When is vulnerability assessment required? Active required every 36 months (High Impact Only); Paper or active required every 15 months (High & Medium impact); New Cyber Assets to production (High Impact). 8

10 PAPER VULNERABILITY ASSESSMENT 1. Network Discovery - paper review to identify all ESP Access Points. Review inventory, etc 2. Network Port and Service Identification - A review to verify that all enabled ports and services have an appropriate business justification. 3. Vulnerability Review - A review of security rule-sets and configurations, including controls for default accounts, passwords, and network management community strings. 4. Wireless Review - Identification of common types of wireless networks (such as a/b/g/n) and a review of their controls if they are in any way used for BES Cyber System communications. 9

11 ACTIVE VULNERABILITY ASSESSMENT Typically, Active Vulnerability testing involves sending numerous probes to devices over the network to look for open ports and known vulnerabilities. Vulnerability scanning 1 device can send ~170,000 separate probes across the network (remember, that is only for scanning one box) Determine SPECIFIC configurations that your devices respond well to. Most scanners have like 1,000 configuration options and many with potentially DANGEROUS consequences. Examples of active tools: Vulnerability scanning Port scanning w/ misc. fingerprinting War dialers Warning: It is relatively easy to break things using active vulnerability assessment tools. 10

12 ACTIVE VULNERABILITY ASSESSMENT BASICALLY CIP V3 CVA WITH WIFI AND PERIODIC ACTIVE Responsible Entities are strongly encouraged to include *at least* the following elements: 1. Network Discovery Use of active discovery tools to discover active devices and identify communication paths in order to verify that the discovered network architecture matches the documented architecture. 2. Network Port and Service Identification Use of active discovery tools (such as Nmap) to discover open ports and services. 3. Vulnerability Scanning Use of a vulnerability scanning tool to identify network accessible ports and services along with the identification of known vulnerabilities associated with services running on those ports. 4. Wireless Scanning Use of a wireless scanning tool to discover wireless signals and networks in the physical perimeter of a BES Cyber System. Serves to identify unauthorized wireless devices within the range of the wireless scanning tool. REs are strongly encouraged to see NIST for vulnerability assessment guidance and best practices. 11

13 DON T SCAN ACROSS WAN 12

14 QUESTIONS/DISCUSSION 13

15 NEXT WEBINAR Got Webinar suggestions? 14