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

CLARITY ▪ ASSURANCE ▪ RESULTS

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

12/05/2017 2

CLARITY ▪ ASSURANCE ▪ RESULTS

Overview

Self-reports and self-logs are:

• Handled by the Risk Assessment and Mitigation (RAM) department directly (as
• pposed 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

12/05/2017 3

CLARITY ▪ ASSURANCE ▪ RESULTS

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
• r 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

12/05/2017 4

CLARITY ▪ ASSURANCE ▪ RESULTS

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

12/05/2017 5

CLARITY ▪ ASSURANCE ▪ RESULTS

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)

12/05/2017 6

CLARITY ▪ ASSURANCE ▪ RESULTS

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.”

12/05/2017 7

CLARITY ▪ ASSURANCE ▪ RESULTS

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

12/05/2017 8

CLARITY ▪ ASSURANCE ▪ RESULTS

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  Perform 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

12/05/2017 9

CLARITY ▪ ASSURANCE ▪ RESULTS

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

12/05/2017 10

CLARITY ▪ ASSURANCE ▪ RESULTS

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)

12/05/2017 11

CLARITY ▪ ASSURANCE ▪ RESULTS

Additional Information

For additional information, please see the NERC document:

12/05/2017 12

ERO Self-Report User Guide

CLARITY ▪ ASSURANCE ▪ RESULTS

Questions

For additional questions, contact: heros@midwestrelibility.org

12/05/2017 13