Overview We will cover: The information required for the: CRITERIA - PowerPoint PPT Presentation

Overview We will cover: • The information required for the:  CRITERIA (requirement in violation)  CONDITION (description of noncompliance)  CAUSE (cause of the finding)  DESCRIPTION (description and status of mitigating activity)  EFFECT/POTENTIAL EFFECT (risk determination) • Examples will be CIP issues – also applies to Ops/Planning CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 2

Overview Self-reports and self-logs are: • Handled by the Risk Assessment and Mitigation (RAM) department directly (as opposed to Audit Findings, Self Certifications and Spot Checks, which start with the Compliance department) • Differences between self-logs and self-reports:  Self-logs are presumed to be minimal risk  Self-reports are required for moderate and serious risk issues CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 3

Motivation Having a complete and well documented self-report will: • Provide increased assurance that this issue was well understood and managed • Help expedite processing time • Help focus mitigating activities • For minimal risk items (Compliance Exceptions), following these guidelines may reduce or eliminate the need for SME discussions or additional data requests  There is a balance between speed of reporting and completeness of the self-report  Alternative evidence can always be discussed CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 4

Description of Noncompliance Description of the noncompliance (CONDITION) should include: • Requirement(s) impacted by the noncompliance (CRITERIA)  The enforceable version at the start date of the noncompliance • Description of Applicable Systems  Impact rating of the applicable BES Cyber System  For access removal, indicate if the access included Control Center (for example)  Detailed descriptions of the impacted Cyber Assets (as appropriate):  Control Center, Substation, Generation Facility, etc.  BCA, EACMS, PCA, or PACS  If External Routable Connectivity was present  The number of impacted assets and total number of similar assets (person or cyber)  Documentation only or performance related CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 5

Description of Noncompliance Description of noncompliance (CONDITION) should include: • Date the noncompliance was identified (discovery date) • How the noncompliance was identified (take credit for internal controls!!!) • Start date of noncompliance  How the date was determined (evidence if applicable) • Date the noncompliance was corrected (does not have to include mitigation for reoccurrence, include evidence if applicable) • If MRRE, indicate impacted region(s) CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 6

Description of the Cause Description of the cause of the noncompliance (CAUSE): • Describe the root cause that resulted in the condition • Typically, this is a process (or process implementation) deficiency  Try not to simply restate the condition  Bad example: “Failed to remove an individual’s ability for unescorted access within 24 hours of termination action.” This example largely restates the condition – and may result in missing required mitigation.  Better example: “The employee’s manager failed to submit the Personnel Change Form within the time frame indicated in the revocation process.” CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 7

Description of the Cause Description of the cause of the noncompliance (CAUSE): • Additional information relating to the specific circumstances will help to ensure mitigation was complete  Example: “The manager was on vacation and did not delegate the responsibility.” • Documented mitigating activities need to include steps which address the root cause  In our example above, mitigating activities might include training or changes to the process • More about this example in the Mitigation section CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 8

Description and Status of Mitigating Activities Description and status of mitigating activities (DESCRIPTION): • Example: “The manager was on vacation and did not delegate the responsibility.” • Key topics to address:  Stopping the identified noncompliance (in our example, removing unescorted access). Provide evidence if applicable – this should be a high-priority task  P erform an “extent of condition” analysis  May not be required if identified using internal control (e.g., unrequired quarterly review of all access privileges)  Always required if the issue was identified in an “ad hoc” manner (e.g., employee “tested” access to door and it worked, then reported issue)  Look for other requirements which may have been impacted  Provide evidence if applicable CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 9

Description and Status of Mitigating Activities Description and status of mitigating activities (DESCRIPTION): • Key topics to address:  Mitigation for other noncompliance identified during extent of condition  Mitigation to prevent reoccurrence (if not required, explain)  In our example, emphasize delegation requirement training for all managers  Must have mitigation which directly addresses the root cause  Provide evidence on activities that have been completed  Provide planned completion dates of future steps  webCDMS mitigation plans  Not required for minimal risk items (but always an option)  Helpful for longer-duration mitigating activities  Once started, must finish process in webCDMS CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 10

Risk Determination Key factors in Risk Determination (EFFECT/POTENTIAL EFFECT): • Identify any actual impact which has occurred as a result of the noncompliance • If applicable, describe in detail any internal control(s) that identified and reduced the duration of the noncompliance • Describe any characteristics of your system which limit the risk  Should be applicable to the noncompliance and not required A few examples:  24/7 security guard at control center  No Interactive Remote Access allowed at your Control Center (if electronic access applies)  Provide evidence as applicable • Contact MRO RAM to discuss if you are not confident of minimal risk for self-logs (or with any other questions) CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 11

Additional Information For additional information, please see the NERC documen t: ERO Self-Report User Guide CLARITY ▪ ASSURANCE ▪ RESULTS 12/05/2017 12

Questions For additional questions, contact: heros@midwestrelibility.org CLARITY ▪ ASSURANCE ▪ RESULTS 13 12/05/2017