1 cip-007-1 systems security management a compliance perspective lew folkerth cip compliance...

1

CIP-007-1Systems Security Management

A Compliance Perspective

Lew Folkerth

CIP Compliance Workshop

Baltimore, MD

August 19-20, 2009

© ReliabilityFirst Corporation

2

Governance Annotated Text of the Standard

• Annotations are NOT authoritative, they are commentary only Pre-audit questions

• Are intended to streamline the audit process• Some go beyond what is required by the standard for informational

purposes• Are intended to help organize information used for compliance• Are intended as a starting point for review of the compliance

documentation The “plain language” of the standard will govern The only authoritative text in this presentation is that of the language of the

standard. All else is opinion and intended practice and is subject to change. This presentation is for use by ReliabilityFirst Corporation and its member

organizations only. Any other use requires the prior permission of ReliabilityFirst Corporation.


3

CIP-007-1 R1Annotated Text

R1. Test Procedures — The Responsible Entity shall ensure that new Cyber Assets1 and significant changes to existing Cyber Assets within the Electronic Security Perimeter do not adversely affect existing cyber security controls2. For purposes of Standard CIP-007, a significant change shall, at a minimum, include implementation of security patches, cumulative service packs, vendor releases, and version upgrades3 of operating systems, applications, database platforms, or other third-party software or firmware.

1Note that this requirement applies to all Cyber Assets within an ESP, not just the Critical Cyber Assets.

2The purpose of this requirement is to ensure that significant changes to the Cyber Assets do not cause problems with the cyber security controls. Testing for functionality of these changes is good business practice but is beyond the defined scope of this requirement.


4

CIP-007-1 R1Annotated Text (cont’d)

R1. Test Procedures — The Responsible Entity shall ensure that new Cyber Assets1 and significant changes to existing Cyber Assets within the Electronic Security Perimeter do not adversely affect existing cyber security controls2. For purposes of Standard CIP-007, a significant change shall, at a minimum, include implementation of security patches, cumulative service packs, vendor releases, and version upgrades3 of operating systems, applications, database platforms, or other third-party software or firmware.

3A version upgrade can mean different things on different platforms. For the purposes of this requirement, a version upgrade can be taken to mean a change in software which adds to or changes the functionality of the software being updated. As such, minor bug fixes and other minor changes may fall outside the scope of this requirement.


5


R1.1. The Responsible Entity shall create, implement, and maintain cyber security test procedures in a manner that minimizes adverse effects4 on the production system or its operation.

R1.2. The Responsible Entity shall document that testing is performed in a manner that reflects the production environment5.

R1.3. The Responsible Entity shall document test results.

4This language gives the entity some flexibility in performing its tests. Note that a separate test environment is not explicitly required. For example, a GO or GOP could use the production plant control system to conduct the required testing during a plant outage where any adverse impact on the system could be repaired before the system is needed to again control the plant.

5The method of testing must have some applicability to the production environment.


6

CIP-007-1 R1Items for Consideration – Pre-audit

1. How are the cyber security controls that must be verified through testing identified?

2. How are significant changes to existing Cyber Assets within the Electronic Security Perimeter identified to assure that all significant changes are tested to confirm the changes to not affect existing cyber security controls?

3. How are new Cyber Assets being installed within the Electronic Security Perimeter identified to assure cyber security controls are tested?


7

CIP-007-1 R1Items for Consideration – Pre-audit (cont’d)

4. How is the required testing conducted to minimize adverse effects on the production system or its operation?

5. How are differences between the test and productions environments identified, documented, and accounted for by the test procedures?

6. To what extent do the test procedures require pre- or post-implementation testing in the production environment to verify cyber security controls are still operating properly in the production environment?


8

CIP-007-1 R1Possible Audit Approach

• For each Cyber Asset within each Electronic Security Perimeter, identify the corresponding cyber security test procedure.


9

CIP-007-1 R1Possible Audit Approach (cont’d)

• For a sample of the cyber security test procedures thus identified, ensure each procedure:

• Specifies the types of changes requiring activation of the procedure. Such changes shall include at least:• implementation of security patches;• implementation of cumulative service packs;• implementation of vendor releases;• version upgrades of operating systems;• version upgrades of applications;• version upgrades of database platforms;• version upgrades of third-party software;• version upgrades of firmware; or• other significant changes as determined by the Responsible

Entity.


10


• For a sample of the cyber security test procedures thus identified, ensure each procedure:• Ensures that such changes do not adversely affect existing cyber

security controls.• Ensures that testing is performed in a manner that minimizes

adverse effects on the production environment.• Documents that the test environment reflects the production

environment. Note that a test environment is not specifically required by the standard. If a test environment is not used, the procedure must document how the test reflects the production environment.

• Requires documentation of test results.• Is reviewed and updated annually per Requirement R9.


11

CIP-007-1 R1Possible Audit Criteria (cont’d)

• For a sample set of changes to Cyber Assets within an Electronic Security Perimeter, ensure the cyber security test procedure was followed for each change.

• Examine evidence to verify changes to the cyber security test procedures resulting from modifications to the production or test environments are reflected in the procedures within 90 calendar days of the change (per Requirement R9).


12


R2. Ports and Services — The Responsible Entity shall establish and document a process to ensure that only those ports and services1 required for normal and emergency operations2 are enabled.

1There is an ongoing issue with the meaning of the phrase “ports and services” which appears here and in CIP-005-1 R2.2. In NERC’s CIP Auditor Training, the auditors were instructed to read this as meaning “hardware ports and network and software services.” This led to a Request for Interpretation (Project 2009-16) for which a ballot window is now open. This RFI interprets the standard as follows: “The drafting team interprets the term “ports” used as part of the phrase “ports and services” to refer to logical ports, e.g., Transmission Control Protocol (TCP) ports, where interface with communication services occurs.”

2The entity must allow for emergency operations when determining which ports to leave open and which services will stay enabled. For example, a failover service that is used only to activate a backup facility should remain enabled even though it is never used in normal operations.


13


R2.1. The Responsible Entity shall enable3 only those ports and services required for normal and emergency operations.

R2.2. The Responsible Entity shall disable4 other ports and services, including those used for testing purposes5, prior to production use of all Cyber Assets inside6 the Electronic Security Perimeter(s).

3The main body of R2 requires a process to control the ports and services in use on a system. R2.1 requires the actual implementation of said program.

4R2.2 further supports the enabling of only those ports and services needed by explicitly stating that all other ports and services must be disabled.

5R2.2 also makes clear that ports and services used exclusively for testing must also be disabled in production use. Ports and services used for both testing and normal or emergency operations would remain enabled.

6This requirement applies to all Cyber Assets inside an ESP. For control of ports and services on devices bordering the ESP see CIP-005-1 R2.


14


R2.3. In the case where unused ports and services cannot be disabled due to technical limitations7, the Responsible Entity shall document compensating measure(s) applied to mitigate risk exposure8 or an acceptance of risk9.

7This is taken as triggering language to invoke the Technical Feasibility Exception process. See the section on Technical Feasibility Exceptions for more information.

8The language of the standard requires documentation of the compensating measures actually taken to mitigate the risk of leaving unneeded ports and services enabled.

9While an acceptance of risk is valid under the jurisdiction of the Version 1 standards, Version 2 removes this language.


15


1. How are all enabled ports and services identified for all Critical Cyber Assets and other Cyber Assets within the Electronic Security Perimeter?

2. How are ports and services required for normal and emergency operations identified?

3. What is the process for confirming all ports and services not required for normal and emergency operations have been disabled? How often is this reconfirmed?


16


For each Cyber Asset within each Electronic Security Perimeter, identify the process used to control ports (hardware interfaces) and services (programs serving network connections) on that Cyber Asset.

For each such process identified:•Ensure the process requires that only those ports and services required for normal and emergency operations are enabled.•Ensure the process requires those ports and services not required for normal or emergency operations to be disabled. If this is not possible due to technical limitations, ensure the process requires:

• adoption and documentation of compensating measures; or• a statement accepting risk.

•Ensure the process requires those ports and services used for testing to be disabled before the Cyber Asset is used for production purposes within the Electronic Security Perimeter.


17


For a sample set of Cyber Assets in a sample of Electronic Security Perimeters:•Determine the ports accessible from outside the case or chassis of the cyber asset. Determine whether each port is electrically active. For each active port, examine documentation of its use for normal or emergency operations.•Determine the network ports open on the Cyber Asset. For each open port, examine documentation of its use for normal or emergency operations.•For those enabled ports or services not used for normal or emergency operations, examine documentation of the compensating measures employed. If feasible, examine the compensating measures directly.•For those enabled ports or services not used for normal or emergency operations that do not have compensating measures, examine the statement accepting risk.


18


Examine evidence to verify each process to control ports and services is reviewed and updated annually (per Requirement R9).

Examine evidence to verify changes to the ports and services control processes resulting from modifications to the production or test environments are reflected in the processes within 90 calendar days of the change (per Requirement R9).


19


R3. Security Patch Management — The Responsible Entity, either separately or as a component of the documented configuration management process specified in CIP-003 Requirement R61, shall establish and document a security patch management program for tracking2, evaluating3, testing4, and installing applicable cyber security software patches for all Cyber Assets within the Electronic Security Perimeter(s).

1Given the specific reference to CIP-003 R6, the standard is obviously encouraging the entity to incorporate its patch management process into its overall change management process.

2Tracking will be the key to evaluating compliance to this requirement. Items that should be tracked will include: identification of an individual patch, the date the patch became available, the date the entity’s assessment or evaluation of the patch was complete, the results of the evaluation, the date the patch was tested and the results of such testing, the date the patch was installed and, if necessary, the date the patch was backed out.


20


R3. Security Patch Management — The Responsible Entity, either separately or as a component of the documented configuration management process specified in CIP-003 Requirement R61, shall establish and document a security patch management program for tracking2, evaluating3, testing4, and installing applicable cyber security software patches for all Cyber Assets within the Electronic Security Perimeter(s).

3Evaluation of a patch should include an assessment of the applicability of the patch per R3.1.

4Here “testing” is used without qualification. While R1 will apply as to the impact of a patch on the security controls, the functionality of a patch should also be tested per this requirement.


21


R3.1. The Responsible Entity shall document the assessment of security patches and security upgrades for applicability within thirty calendar days of availability5 of the patches or upgrades.

5Some systems vendors either discourage or prohibit their customers from applying operating system or other software patches until they are approved or released by said vendor. In such case, the patch should not be considered “available” until it is approved or released by the vendor. The 30 day clock for assessment of a patch should not start until the patch is available to the entity in a form or under circumstances that will not violate the entity’s warranty or service contract with its vendor.


22


R3.2. The Responsible Entity shall document the implementation of security patches. In any case where the patch is not installed, the Responsible Entity shall document compensating measure(s)6 applied to mitigate risk exposure or an acceptance of risk7.

6While this wording is commonly used in conjunction with the “technical feasibility” language, that is not the case in this instance.



23


1. How does the Responsible Entity ensure that all cyber security patches and upgrades for software installed on a Cyber Asset within the Electronic Security Perimeter have been identified and assessed for applicability?


24


For each Cyber Asset within each Electronic Security Perimeter, identify the associated patch management program.For each patch management program thus identified, ensure the program:•Identifies security patches that may be applicable including the date such patch becomes available. Note that a system’s vendor may require that patches for the operating system or other system component be evaluated and re-issued or approved by said vendor. In such case it is proper that patches issued by the manufacturer of the operating system or other system component will not be identified by this process.•Tracks the status of each identified security patch.•Evaluates or assesses each identified security patch for applicability. Such evaluation or assessment must occur within 30 calendar days of the availability of the patch.


25


For each patch management program thus identified, ensure the program:•Requires that each applicable security patch is tested prior to use in a production system.•Requires that each applicable security patch that passes testing is installed in the production system.•Requires that the assessment of each patch is documented.•Requires that, if implemented, the implementation of each patch is documented.•Requires that, if a patch is not implemented, appropriate compensating measures to mitigate risk exposure be implemented and documented.•Requires that, if a patch is not implemented and compensating measures not applied, that a statement accepting risk be documented.


26


For a sample set of Cyber Assets within a sample of Electronic Security Perimeters:•Ensure applicable patches are tracked, evaluated, tested and, if applicable, installed within a reasonable time frame.•Ensure security patches were assessed for applicability within 30 days of their availability.•For those security patches that were installed, examine the documentation of said installation.•For those security patches not installed, examine the compensating measures used to mitigate risk or the statement accepting risk.


27


Examine evidence to verify each patch management program is reviewed and updated annually (per Requirement R9).

Examine evidence to verify changes to the patch management programs resulting from modifications to the production or test environments are reflected in the procedures within 90 calendar days of the change (per Requirement R9).


28


R4. Malicious Software Prevention — The Responsible Entity shall use anti-virus software and other malicious software (“malware”) prevention tools, where technically feasible1, to detect, prevent, deter, and mitigate the introduction, exposure, and propagation of malware on all Cyber Assets2 within the Electronic Security Perimeter(s).

1See the presentation on Technical Feasibility Exceptions for more information.2As with the other requirements in this standard, this requirement applies to all

Cyber Assets within an ESP.


29


R4.1. The Responsible Entity shall document and implement anti-virus and malware prevention tools3. In the case where anti-virus software and malware prevention tools are not installed, the Responsible Entity shall document compensating measure(s) applied to mitigate risk exposure or an acceptance of risk4.

3The “tools” used to prevent malware need not be simply host-based anti-virus programs. The tools used may include network based programs and other types of host-based preventive measures such as “whitelist” programs. While anti-virus programs should be used where possible, the other alternatives are also acceptable if they adequately protect the systems.



30


R4.2. The Responsible Entity shall document and implement a process for the update of anti-virus and malware prevention “signatures5.” The process must address testing and installing the signatures.

5This requirement will apply to any program with a set of malware detection rules, whether those rules are called a signature file, rule base or other term. If a malware prevention tool is not rule based, this requirement would not apply.


31


1. How are anti-virus and malware prevention signatures tested prior to updating the production environment?


32


• For a sample set of cyber assets within a sample of Electronic Security Perimeters:• Examine the documentation of the anti-virus and

malware prevention tools.• If anti-virus and malware prevention tools are

installed, examine the signature update process. Ensure the process addresses testing and installation of the anti-virus and malware prevention signatures.

• If anti-virus and malware prevention tools are not installed, examine the documentation of the compensating measures used to mitigate risk or the statement accepting risk.


33


• For a sample set of cyber assets within a sample of Electronic Security Perimeters:• Examine evidence to verify documentation of the anti-

virus and malware prevention tools is reviewed and updated annually (per Requirement R9).

• Examine evidence to verify changes to the anti-virus and malware prevention tools resulting from modifications to the production or test environments are reflected within 90 calendar days of the change (per Requirement R9).


34


R5. Account Management — The Responsible Entity shall establish, implement, and document technical and procedural controls that enforce access authentication1 of, and accountability2 for, all user activity, and that minimize the risk of unauthorized system access3.

1Authentication is the process of validating the identity of a user of a system.2Accountability means that activity is attributable to a particular person.3Unauthorized access is any access to a system, authenticated or not, which has

not been approved by someone responsible for controlling access to the system in question.


35


R5.1. The Responsible Entity shall ensure that individual4 and shared system accounts5 and authorized access permissions are consistent with the concept of “need to know6” with respect to work functions performed.

4Individual user accounts are those accounts that may only be accessed by one user. This is the most common type of account.

5Shared system accounts are accounts shared by more than one individual. Such accounts are used where it is not necessary and/or appropriate to track activity at an individual user level. For example, a shared operator account at a console staffed 24x7 may be needed to prevent loss of service inherent in switching accounts at shift change. Per the language in R5, “authentication of, and accountability for, all user activity” some means of identifying which user performed an action must be established.

6”Need to know” in this context is also understood as the “principle of least privilege.” A given user must only have the permissions necessary to perform the required tasks, under both normal and emergency conditions.


36


R5.1.1. The Responsible Entity shall ensure that user accounts are implemented as approved by designated personnel. Refer to Standard CIP-003 Requirement R5.

R5.1.2. The Responsible Entity shall establish methods, processes, and procedures that generate logs of sufficient detail to create historical audit trails of individual user account access activity7 for a minimum of ninety days.

R5.1.3. The Responsible Entity shall review, at least annually8, user accounts to verify access privileges are in accordance with Standard CIP-003 Requirement R5 and Standard CIP-004 Requirement R4.

7In other words, keep track of user login activity.8See the separate discussion of time-based terminology above.


37


R5.2. The Responsible Entity shall implement a policy to minimize and manage the scope and acceptable use of administrator9, shared10, and other generic account privileges including factory default accounts11.

9Administrator accounts are those accounts that are not identified with an individual but which have administrative privileges. The Windows “Administrator” account, the Unix/Linux “root” account and Oracle’s “sys” and “system” accounts are all examples of administrator accounts.

10See the discussion of shared system accounts in (5) above.11Factory default accounts include any account that is created by an equipment or

software vendor. These accounts frequently have default factory passwords so it is particularly important to manage these accounts. An example of a factory default account is the field service account created by default for Vax VMS systems. The username for this account was “field” and the default password was always “service”. As this account was assigned all possible privileges it has been a target for generations of attackers.


38


R5.2.1. The policy shall include the removal, disabling, or renaming of such accounts where possible. For such accounts that must remain enabled, passwords shall be changed12 prior to putting any system into service.

R5.2.2. The Responsible Entity shall identify those individuals with access13 to shared accounts.

12Not an option, no technical feasibility exception. Factory default passwords must be changed prior to the initial compliance date or the date the system is placed into service, whichever is later.

13Effectively, those individuals who know the account’s password.


39


R5.2.3. Where such accounts must be shared, the Responsible Entity shall have a policy for managing the use of such accounts that limits access to only those with authorization14, an audit trail of the account use15 (automated or manual), and steps for securing the account16 in the event of personnel changes (for example, change in assignment or termination).

14The authorization for access to a shared account should follow the same or a similar authorization process as any other account, including annual review of the need for access.

15The audit trail of account use should be matched against the access logs required by R5.1.2 to ensure that all accesses have been accounted for.

16Securing a shared account generally means changing the password.


40


R5.3. At a minimum, the Responsible Entity shall require and use passwords, subject to the following, as technically feasible17:

R5.3.1. Each password shall be a minimum of six characters.

R5.3.2. Each password shall consist of a combination of alpha, numeric, and “special” characters.

R5.3.3. Each password shall be changed at least annually18, or more frequently based on risk.

17See the section on Technical Feasibility Exceptions for more information.18This requirement implies the need to keep track of the date a password is

changed for each account on each device. See the separate discussion of time-based terminology above.


41


1. Under the “need to know” concept, how are access permissions for individual and shared system accounts determined?

2. How are personnel authorized to approve user accounts and access permissions designated

3. Please describe the annual process for reviewing user accounts and verifying access privileges.

4. How are individuals requiring access to administrative, shared, and generic accounts identified and documented?


42

CIP-007-1 R5Items for Consideration – Pre-audit (cont’d)

4. How is the administrative, shared or generic account secured upon personnel changes?

5. How does the Responsible Entity ensure all administrator, shared, and generic accounts are removed, disabled, renamed, or password-changed prior to placing the Cyber Asset into service?

6. How does the Responsible Entity ensure all passwords conform to the length, complexity, and periodic change requirements?


43


For a sample of Electronic Security Perimeters, select a sample of Critical Cyber Assets and a sample of non-critical Cyber Assets. For each Cyber Asset in each sample:•Examine documentation of the technical and procedural controls that enforce access authentication. During this examination:

• Ensure access permissions are required to be limited to the least level of access needed to perform the functions required.

• Ensure processes and procedures are in place to track individual user account access activity.

• Ensure an annual review of accounts to verify access privileges is required.


44


For each Cyber Asset in each sample:•Examine documentation of the technical and procedural controls that enforce access authentication. During this examination:

• Ensure a policy is in place to manage administrator, shared and other generic account privileges. Ensure the policy includes the following provisions:• Such accounts are removed, disabled or renamed where

possible.• Individuals with access to shared accounts are identified.


45



46


For each Cyber Asset in each sample:•Examine documentation of the technical and procedural controls that enforce access authentication. During this examination:

• Ensure a policy is in place to require password protection of all accounts. If one or more Technical Feasibility Exceptions have been taken to R5.3, examine those exceptions at this point. This policy must further require:• Passwords of six characters or more.• Passwords consisting of alpha, numeric and “special”

characters.• Changing passwords at least annually.

• Ensure steps are taken to minimize the risk of unauthorized access


47


For each Cyber Asset in each sample:•Examine evidence to verify the access controls are reviewed and updated annually (per Requirement R9).•Examine evidence to verify changes to the access controls resulting from modifications to the production environment are reflected in the controls within 90 calendar days of the change (per Requirement R9).


48


R6. Security Status Monitoring — The Responsible Entity shall ensure that all Cyber Assets within the Electronic Security Perimeter, as technically feasible1, implement automated tools or organizational process controls to monitor system events2 that are related to cyber security3.

1See the section on Technical Feasibility Exceptions for more information.2Computer systems generate events that can be saved (logged) and analyzed.

Most events are of a routine nature such as a successful login or a permitted file access. Some events may indicate security problems such as a login failure or a denied file access. An incident (see R6.2) is made up of one or more events. The Windows Event Log and the Unix/Linux syslog are examples of facilities used to log events. Note that “system” is not capitalized and hence does not refer to the NERC Glossary.

3This requirement pertains only to cyber security related events. Other events may be included in the events monitored.


49


R6.1. The Responsible Entity shall implement and document the organizational processes and technical and procedural mechanisms for monitoring for security events on all Cyber Assets within the Electronic Security Perimeter.

R6.2. The security monitoring controls shall issue automated or manual alerts for detected Cyber Security Incidents.

R6.3. The Responsible Entity shall maintain logs of system events related to cyber security, where technically feasible1, to support incident response as required in Standard CIP-008.

Cyber Security Incident – Any malicious act or suspicious event that:•Compromises, or was an attempt to compromise, the Electronic Security Perimeter or Physical Security Perimeter of a Critical Cyber Asset, or,•Disrupts, or was an attempt to disrupt, the operation of a Critical Cyber Asset.


50


R6.4. The Responsible Entity shall retain all logs specified in Requirement R6 for ninety calendar days.

R6.5. The Responsible Entity shall review logs4 of system events related to cyber security and maintain records documenting review of logs.

4The review of logs may be manual or automatic. If a manual process is used, the logs must be reviewed before the log entries expire from the log.


51


1. How are security events monitored for all Cyber Assets within the Electronic Security Perimeter?

2. How are detected Cyber Security Incidents alerted?

3. How are logs of system events related to cyber security reviewed?


52


For a sample of Electronic Security Perimeters, select a sample of Critical Cyber Assets and a sample of non-critical Cyber Assets. For each Cyber Asset in each sample:•Examine the organizational processes and technical and procedural mechanisms for monitoring for security events on that asset to ensure:

• Automated or manual alerts are to be issued for detected actual or potential Cyber Security Incidents.

• Processes or procedures are in place to forward generated alerts to the procedures required by CIP-008-1 R1.1.

• Cyber security event logs are to be kept to support incident response.

• Cyber security event logs are to be kept for at least 90 days.• Cyber security event logs are to be reviewed before they are

deleted.


53


For a sample of Electronic Security Perimeters, select a sample of Critical Cyber Assets and a sample of non-critical Cyber Assets. For each Cyber Asset in each sample:•Examine a security log to ensure:

• The security log is being created as appropriate.• The security log is being reviewed by either automated or manual

processes.• The security log is retained for at least 90 days.

•Examine a sample of alerts for actual or potential incidents to ensure such alerts are being generated and handled in an appropriate manner.


54


For a sample of Electronic Security Perimeters, select a sample of Critical Cyber Assets and a sample of non-critical Cyber Assets. For each Cyber Asset in each sample:•Examine evidence to verify each organizational process and technical and procedural mechanism for monitoring security events on that asset is reviewed and updated annually (per Requirement R9).•Examine evidence to verify changes to each organizational process and technical and procedural mechanism for monitoring security events on that asset resulting from modifications to the production or test environments are reflected in the process or mechanism within 90 calendar days of the change (per Requirement R9).


55


R7. Disposal or Redeployment — The Responsible Entity shall establish formal1 methods, processes, and procedures for disposal2 or redeployment3 of Cyber Assets within the Electronic Security Perimeter(s) as identified and documented in Standard CIP-005.

1Written, enforceable2Disposal is considered to be sale or destruction of the asset such that it leaves

the Responsible Entity’s control.3Redeployment is the reuse of a Cyber Asset for other purposes within the

Responsible Entity’s control


56


R7.1. Prior to the disposal of such assets, the Responsible Entity shall destroy4 or erase5 the data storage media to prevent unauthorized retrieval of sensitive cyber security or reliability data.

4Shred or otherwise physically render the data on the media unreadable.5Erase is to use magnetic or other appropriate means to render the data on the

media unreadable. Note that file deletion and filesystem formatting do not erase the data.


57


R7.2. Prior to redeployment of such assets6, the Responsible Entity shall, at a minimum, erase the data storage media to prevent unauthorized retrieval of sensitive cyber security or reliability data.

R7.3. The Responsible Entity shall maintain records that such assets were disposed of or redeployed in accordance with documented procedures.

6The language of this sub-requirement requires any device that has been connected within an ESP to be erased. Such devices might include vendor laptops, portable sniffers and other devices connected within an ESP on a temporary basis.


58


1. What is the process for removing or destroying data content prior to disposal of the Cyber Asset or storage media?

2. What is the process for removing or destroying data content prior to redeployment of the Cyber Asset or storage media?

3. Are there any instances where data content cannot be removed or destroyed? For example, a failed disk drive that must be returned to the manufacturer under warranty


59


For a sample of Electronic Security Perimeters examine the methods, processes or procedures for disposal or redeployment of Cyber Assets from within an ESP to ensure:•Prior to disposal or redeployment of with such Cyber Assets, data storage media associated with the Cyber Asset is erased or destroyed. If such media is erased, examine the method prescribed to erase the media to ensure that data which had been stored on such media will not be retrievable. If such media is destroyed, examine the prescribed destruction method to ensure that data which had been stored on such media will not be retrievable.•Record of disposal or redeployment of such Cyber Assets is to be kept.


60


Examine evidence to verify each method, process or procedure for disposal or redeployment of Cyber Assets from within an ESP is reviewed and updated annually (per Requirement R9).

Examine evidence to verify changes to each method, process or procedure for disposal or redeployment of Cyber Assets from within an ESP resulting from modifications to the production environment is reflected in the method, process or procedure within 90 calendar days of the change (per Requirement R9).


61


For a sample of Electronic Security Perimeters, determine whether any Cyber Assets have been disposed of or redeployed from within an ESP. If so, examine the records of disposal or redeployment of such Cyber Assets to ensure destruction or erasure was carried out per the appropriate procedure.


62


R8. Cyber Vulnerability Assessment — The Responsible Entity shall perform a cyber vulnerability assessment1 of all Cyber Assets within the Electronic Security Perimeter at least annually2. The vulnerability assessment shall include, at a minimum, the following:

1Note that an active cyber vulnerability assessment (CVA) of Cyber Asset is not specifically required by the language of the standard. If an active CVA is used, the entity must take care not to disrupt the normal operation of the systems being assessed. In a typical passive CVA, the following items should, at minimum, be considered: open ports, active services, patch level of the operating system and applications, applicable cyber security advisories, security configuration of the operating system and applications, unnecessary programs installed or used on the system, generic or factory accounts that have not been disabled.

2See the discussion of time-based terminology in the CIP-002-1 presentation.


63


R8.1. A document identifying the vulnerability assessment process;

R8.2. A review to verify that only ports and services3 required for operation of the Cyber Assets within the Electronic Security Perimeter are enabled;

R8.3. A review of controls for default accounts4; and,

3See the discussion of “ports and services” under R2.4See R5.2


64


R8.4. Documentation of the results of the assessment, the action plan5 to remediate or mitigate vulnerabilities identified in the assessment, and the execution status6 of that action plan.

5An action plan is required if any issues were identified in the cyber vulnerability assessment.

6The action plan is required to be executed in a reasonable time frame.


65


1. How is the annual vulnerability assessment performed?

2. How are identified vulnerabilities documented, incorporated into a remediation or mitigation plan, and resolved per the plan?


66


For a sample of Electronic Security Perimeters, select a sample of Critical Cyber Assets and a sample of non-critical Cyber Assets. For each Cyber Asset in the samples:•Examine the document identifying the cyber vulnerability assessment (CVA) process to ensure:

• The CVA is required to be performed annually.• The CVA includes a review of ports and services

required for operation.• The CVA includes a review of controls for default

accounts.• An action plan is required to be created to address

vulnerabilities found in the assessment, if any.


67


For each Cyber Asset in the samples:•Examine the document identifying the cyber vulnerability assessment (CVA) process to ensure:

• Any resulting action plan is required to be executed and an execution status for that action plan maintained.

• Each CVA process is reviewed and updated annually (per Requirement R9).

• Changes to each CVA process resulting from modifications to the production environments are reflected in the process within 90 calendar days of the change (per Requirement R9).


68


For each Cyber Asset in the samples:

•Examine the results of the most recent CVA to ensure:• The CVA was performed within the last year.• The CVA reviewed at least the ports and services

required for operation and the controls for default accounts.

• If one or more vulnerabilities were identified, an action plan was created to remediate or mitigate said vulnerabilities.

• If an action plan was created that the execution status of that action plan is maintained.


69


R9. Documentation Review and Maintenance — The Responsible Entity shall review and update the documentation specified in Standard CIP-007 at least annually1. Changes resulting from modifications to the systems or controls shall be documented within ninety calendar days of the change.

1See the discussion of time-based terminology in the CIP-002-1 presentation.


70


1. How does the Responsible Entity ensure that changes resulting from modifications to cyber systems or controls are documented within ninety calendar days of the change?


71


Reflected in the Possible Audit Criteria for Requirements R1 through R9
