Tripwire Compliance
Reduce Costs and Maintain IT Regulatory Compliance with Automation

1. Control Centers and backup Control Centers;
2. Transmission stations and substations;
3. Generation resources;
4. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements;
5. Special Protection Systems that support the reliable operation of the Bulk Electric System; and
6. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above.

• R1.1. Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset;
• R1.2. Identify each of the medium impact BES Cyber Systems according to Attachment 1, Section 2, if any, at each asset; and
• R1.3. Identify each asset that contains a low impact BES Cyber System according to Attachment 1, Section 3, if any (a discrete list of low impact BES Cyber Systems is not required).

Tripwire IP360 can discover all assets in assigned IP scope using TCP and UDP protocols. Discovery of all assets allows for further classification and interegation.

• R2.1. Review the identifications in Requirement R1 and its parts (and update them if there are changes identified) at least once every 15 calendar months, even if it has no identified items in Requirement R1, and
• R2.2. Have its CIP Senior Manager or delegate approve the identifications required by Requirement R1 at least once every 15 calendar months, even if it has no identified items in Requirement R1.

• R1.1. Personnel & training (CIP-004);
• R1.2. Electronic Security Perimeters (CIP-005) including Interactive Remote Access;
• R1.3. Physical security of BES Cyber Systems (CIP-006);
• R1.4. System security management (CIP-007);
• R1.5. Incident reporting and response planning (CIP-008);
• R1.6. Recovery plans for BES Cyber Systems (CIP-009);
• R1.7. Configuration change management and vulnerability assessments (CIP-010);
• R1.8. Information protection (CIP-011); and
• R1.9. Declaring and responding to CIP Exceptional Circumstances.

• R2.1. Cyber security awareness;
• R2.2. Physical security controls;
• R2.3. Electronic access controls for external routable protocol connections and Dial-up Connectivity; and
• R2.4. Incident response to a Cyber Security Incident.

Tripwire reports can provide excellent forensic details to assist in the investigation/analysis of an Incident or in the preparation/evaluation of an IOC report.

R1.1. Security awareness that, at least once each calendar quarter, reinforces cyber security practices (which may include associated physical security practices) for the Responsible Entity’s personnel who have authorized electronic or authorized unescorted physical access to BES Cyber Systems.

R2.1. Training content on:

• 2.1.1. Cyber security policies;
• 2.1.2. Physical access controls;
• 2.1.3. Electronic access controls;
• 2.1.4. The visitor control program;
• 2.1.5. Handling of BES Cyber System Information and its storage;
• 2.1.6. Identification of a Cyber Security Incident and initial notifications in accordance with the entity’s incident response plan;
• 2.1.7. Recovery plans for BES Cyber Systems;
• 2.1.8. Response to Cyber Security Incidents; and
• 2.1.9. Cyber security risks associated with a BES Cyber System’s electronic interconnectivity and interoperability with other Cyber Assets.

R2.2. Require completion of the training specified in Part 2.1 prior to granting authorized electronic access and authorized unescorted physical access to applicable Cyber Assets, except during CIP Exceptional Circumstances.
R2.2. Require completion of the training specified in Part 2.1 at least once every 15 calendar months.

R3.1. Process to confirm identity.

• R3.2. Process to perform a seven year criminal history records check as part of each personnel risk assessment that includes:
• 3.2.1. current residence, regardless of duration; and
• 3.2.2. other locations where, during the seven years immediately prior to the date of the criminal history records check, the subject has resided for six consecutive months or more. If it is not possible to perform a full seven year criminal history records check, conduct as much of the seven year criminal history records check as possible and document the reason the full seven year criminal history records check could not be performed.
• R3.3. Criteria or process to evaluate criminal history records checks for authorizing access.
• R3.4. Criteria or process for verifying that personnel risk assessments performed for contractors or service vendors are conducted according to Parts 3.1 through 3.3.
• R3.5. Process to ensure that individuals with authorized electronic or authorized unescorted physical access have had a personnel risk assessment completed according to Parts 3.1 to 3.4 within the last seven years.

• R4.1. Process to authorize based on need, as determined by the Responsible Entity, except for CIP Exceptional Circumstances:
• 4.1.1. Electronic access;
• 4.1.2. Unescorted physical access into a Physical Security Perimeter; and
• 4.1.3. Access to designated storage locations, whether physical or electronic, for BES Cyber System Information.
• R4.2. Verify at least once each calendar quarter that individuals with active electronic access or unescorted physical access have authorization records.
• R4.3. For electronic access, verify at least once every 15 calendar months that all user accounts, user account groups, or user role categories, and their specific, associated privileges are correct and are those that the Responsible Entity determines are necessary.
• R4.4. Verify at least once every 15 calendar months that access to the designated storage locations for BES Cyber System Information, whether physical or electronic, are correct and are those that the Responsible Entity determines are necessary for performing assigned work functions.

Tripwire's FIM whitelist profiler extension can verify only approved accounts exist on systems, as codified in an authorized user whitelist.

• R5.1. A process to initiate removal of an individual’s ability for unescorted physical access and Interactive Remote Access upon a termination action, and complete the removals within 24 hours of the termination action (Removal of the ability for access may be different than deletion, disabling, revocation, or removal of all access rights).
• R5.2. For reassignments or transfers, revoke the individual’s authorized electronic access to individual accounts and authorized unescorted physical access that the Responsible Entity determines are not necessary by the end of the next calendar day following the date that the Responsible Entity determines that the individual no longer requires retention of that access.
• R5.3. For termination actions, revoke the individual’s access to the designated storage locations for BES Cyber System Information, whether physical or electronic (unless already revoked according to Requirement R5.1), by the end of the next calendar day following the effective date of the termination action.
• R5.4. For termination actions, revoke the individual’s non?shared user accounts (unless already revoked according to Parts 5.1 or 5.3) within 30 calendar days of the effective date of the termination action.
• R5.5. For termination actions, change passwords for shared account(s) known to the user within 30 calendar days of the termination action. For reassignments or transfers, change passwords for shared account(s) known to the user within 30 calendar days following the date that the Responsible Entity determines that the individual no longer requires retention of that access.
  If the Responsible Entity determines and documents that extenuating operating circumstances require a longer time period, change the password(s) within 10 calendar days following the end of the operating circumstances.

Tripwire's FIM whitelist profiler extension can verify only approved accounts exist on systems, as codified in an authorized user whitelist.

• R1.1. Electronic Security Perimeter - All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP. Tripwire IP360 combined with professional services use of Tripwire discovery tools can help identify and track the cyber assets that are in scope.
• R1.2. All External Routable Connectivity must be through an identified Electronic Access Point (EAP).
• R1.3. Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default.
• R1.4. Where technically feasible, perform authentication when establishing Dial-up Connectivity with applicable Cyber Assets.
• R1.5. Have one or more methods for detecting known or suspected malicious communications for both inbound and outbound communications.

• R2.1. Interactive Remote Access Management- Utilize an Intermediate System such that the Cyber Asset initiating Interactive Remote Access does not directly access an applicable Cyber Asset.
• R2.2. For all Interactive Remote Access sessions, utilize encryption that terminates at an Intermediate System.
• R2.3. Require multi-factor authentication for all Interactive Remote Access sessions.

Tripwire validates and monitors security settings and configurations made to ensure strong authentication by external interactive users.

• R1.1. Define operational or procedural controls to restrict physical access.
• R1.2. Utilize at least one physical access control to allow unescorted physical access into each applicable Physical Security Perimeter to only those individuals who have authorized unescorted physical access.
• R1.3. Where technically feasible, utilize two or more different physical access controls (this does not require two completely independent physical access control systems) to collectively allow unescorted physical access into Physical Security Perimeters to only those individuals who have authorized unescorted physical access.
• R1.4. Monitor for unauthorized access through a physical access point into a Physical Security Perimeter.
• R1.5. Issue an alarm or alert in response to detected unauthorized access through a physical access point into a Physical Security Perimeter to the personnel identified in the BES Cyber Security Incident response plan within 15 minutes of detection.
• R1.6. Monitor each Physical Access Control System for unauthorized physical access to a Physical Access Control System.
• R1.7. Issue an alarm or alert in response to detected unauthorized physical access to a Physical Access Control System to the personnel identified in the BES Cyber Security Incident response plan within 15 minutes of the detection.
• R1.8. Log (through automated means or by personnel who control entry) entry of each individual with authorized unescorted physical access into each Physical Security Perimeter, with information to identify the individual and date and time of entry.
• R1.9. Retain physical access logs of entry of individuals with authorized unescorted physical access into each Physical Security Perimeter for at least ninety calendar days.

Tripwire can facilitate monitoring of physical access and other environmental monitoring systems by analyzing the logs collected, utilizing custom correlation rules to alert on unauthorized access attempts.

Tripwire can facilitate monitoring of physical access and other environmental monitoring systems by analyzing the logs collected, utilizing custom correlation rules to alert on unauthorized access attempts.

• R2.1. Require continuous escorted access of visitors (individuals who are provided access but are not authorized for unescorted physical access) within each Physical Security Perimeter, except during CIP Exceptional Circumstances.
• R2.2. Require manual or automated logging of visitor entry into and exit from the Physical Security Perimeter that includes date and time of the initial entry and last exit, the visitor’s name, and the name of an individual point of contact responsible for the visitor, except during CIP Exceptional Circumstances.
• R2.3. Retain visitor logs for at least ninety calendar days.

R3.1. Maintenance and testing of each Physical Access Control System and locally mounted hardware or devices at the Physical Security Perimeter at least once every 24 calendar months to ensure they function properly.

• R1.1. Where technically feasible, enable only logical network accessible ports that have been determined to be needed by the Responsible Entity, including port ranges or services where needed to handle dynamic ports. If a device has no provision for disabling or restricting logical ports on the device then those ports that are open are deemed needed.
• R1.2. Protect against the use of unnecessary physical input/output ports used for network connectivity, console commands, or removable media.

Tripwire's FIM whitelist profiler extension can monitor ports and services and compare current state against a tailored set of customer-specific approved port and services, alerting when monitoring detects a variance.

• R2.1. A patch management process for tracking, evaluating, and installing cyber security patches for applicable Cyber Assets. The tracking portion shall include the identification of a source or sources that the Responsible Entity tracks for the release of cyber security patches for applicable Cyber Assets that are updateable and for which a patching source exists.
• R2.2. At least once every 35 calendar days, evaluate security patches for applicability that have been released since the last evaluation from the source or sources identified in Part 2.1.
• R2.3. For applicable patches identified in Part 2.2, within 35 calendar days of the evaluation completion, take one of the following actions:
  • Apply the applicable patches; or
  • Create a dated mitigation plan; or
  • Revise an existing mitigation plan.
• Mitigation plans shall include the Responsible Entity’s planned actions to mitigate the vulnerabilities addressed by each security patch and a timeframe to complete these mitigations.
• R2.4. For each mitigation plan created or revised in Part 2.3, implement the plan within the timeframe specified in the plan, unless a revision to the plan or an extension to the timeframe specified in Part 2.3 is approved by the CIP Senior Manager or delegate.

IP360's vulnerability assessment capabilities can identify any necessary patches that should be installed on a broad range of BCA systems based on vendor recommendations. The vulnerability database is typically updated every week.

• R3.1. Deploy method(s) to deter, detect, or prevent malicious code.
• R3.2. Mitigate the threat of detected malicious code.
• R3.3. For those methods identified in Part 3.1 that use signatures or patterns, have a process for the update of the signatures or patterns. The process must address testing and installing the signatures or patterns.

Tripwire's FIM monitoring can detect the introduction of unapproved/unauthorized files on a given system.

• R4.1. Log events at the BES Cyber System level (per BES Cyber System capability) or at the Cyber Asset level (per Cyber Asset capability) for identification of, and after-the-fact investigations of, Cyber Security Incidents that includes, as a minimum, each of the following types of events:
• 4.1.1. Detected successful login attempts;
• 4.1.2. Detected failed access attempts and failed login attempts;
• 4.1.3. Detected malicious code.
• R4.2. Generate alerts for security events that the Responsible Entity determines necessitates an alert, that includes, as a minimum, each of the following types of events (per Cyber Asset or BES Cyber System capability):
• 4.2.1. Detected malicious code from Part 4.1; and
• 4.2.2. Detected failure of Part 4.1 event logging.
• R4.3. Where technically feasible, retain applicable event logs identified in Part 4.1 for at least the last 90 consecutive calendar days except under CIP Exceptional Circumstances.
• R4.4. Review a summarization or sampling of logged events as determined by the Responsible Entity at intervals no greater than 15 calendar days to identify undetected Cyber Security Incidents.

Tripwire Log Center rules can capture successful and unsuccessful logins for all monitored hosts, and provide alerting as desired.

Log retention for the required periods can be assured through Tripwire's log management and archiving capabilities.

• R5.1. Have a method(s) to enforce authentication of interactive user access, where technically feasible.
• R5.2. Identify and inventory all known enabled default or other generic account types, either by system, by groups of systems, by location, or by system type(s).
• R5.3. Identify individuals who have authorized access to shared accounts.
• R5.4. Change known default passwords, per Cyber Asset capability.
• R5.5. For password-only authentication for interactive user access, either technically or procedurally enforce the following password parameters:
  • 5.5.1. Password length that is, at least, the lesser of eight characters or the maximum length supported by the Cyber Asset; and
  • 5.5.2. Minimum password complexity that is the lesser of three or more different types of characters (e.g., uppercase alphabetic, lowercase alphabetic, numeric, non-alphanumeric) or the maximum complexity supported by the Cyber Asset.
• R5.6. Where technically feasible, for password-only authentication for interactive user access, either technically or procedurally enforce password changes or an obligation to change the password at least once every 15 calendar months.
• R5.7. Where technically feasible, either:
  • Limit the number of unsuccessful authentication attempts; or
  • Generate alerts after a threshold of unsuccessful authentication attempts.

Tripwire can scan logs for account management activity and configuration settings to ensure authentication is enforced, alerting as appropriate.

Tripwire can ensure that default accounts are disabled and/or passwords are changed where required, and activity logging can provide alerting on inappropriate use of such accounts.

Tripwire can verify configuration settings for passwords and other security settings to meet and maintain compliance requirements.

• R1.1. One or more processes to identify, classify, and respond to Cyber Security Incidents.
• R1.2. One or more processes to determine if an identified Cyber Security Incident is a Reportable Cyber Security Incident and notify the Electricity Sector Information Sharing and Analysis Center (ES-ISAC), unless prohibited by law. Initial notification to the ES-ISAC, which may be only a preliminary notice, shall not exceed one hour from the determination of a Reportable Cyber Security Incident.
• R1.3. The roles and responsibilities of Cyber Security Incident response groups or individuals.
• R1.4. Incident handling procedures for Cyber Security Incidents.

• R2.1. Test each Cyber Security Incident response plan(s) at least once every 15 calendar months:
  • By responding to an actual Reportable Cyber Security Incident;
  • With a paper drill or tabletop exercise of a Reportable Cyber Security Incident; or
  • With an operational exercise of a Reportable Cyber Security Incident.
  • R2.2. Use the Cyber Security Incident response plan(s) under Requirement R1 when responding to a Reportable Cyber Security Incident or performing an exercise of a Reportable Cyber Security Incident. Document deviations from the plan(s) taken during the response to the incident or exercise.
  • R2.3. Retain records related to Reportable Cyber Security Incidents.

• R3.1. No later than 90 calendar days after completion of a Cyber Security Incident response plan(s) test or actual Reportable Cyber Security Incident response:
  • 3.1.1. Document any lessons learned or document the absence of any lessons learned;
  • 3.1.2. Update the Cyber Security Incident response plan based on any documented lessons learned associated with the plan; and
  • 3.1.3. Notify each person or group with a defined role in the Cyber Security Incident response plan of the updates to the Cyber Security Incident response plan based on any documented lessons learned.
• R3.2. No later than 60 calendar days after a change to the roles or responsibilities, Cyber Security Incident response groups or individuals, or technology that the Responsible Entity determines would impact the ability to execute the plan:
  • 3.2.1. Update the Cyber Security Incident response plan(s); and
  • 3.2.2. Notify each person or group with a defined role in the Cyber Security Incident response plan of the updates.

• R1.1. Conditions for activation of the recovery plan(s).
• R1.2. Roles and responsibilities of responders.
• R1.3. One or more processes for the backup and storage of information required to recover BES Cyber System functionality.
• R1.4. One or more processes to verify the successful completion of the backup processes in Part 1.3 and to address any backup failures.
• R1.5. One or more processes to preserve data, per Cyber Asset capability, for determining the cause of a Cyber Security Incident that triggers activation of the recovery plan(s). Data preservation should not impede or restrict recovery.

Tripwire products can be customized to create baselines for products and devices configuration. These may be called for and used for recovery steps taken after incidents of system attack or failure.

R2.1. Test each of the recovery plans referenced in Requirement R1 at least once every 15 calendar months:

• By recovering from an actual incident;
• With a paper drill or tabletop exercise; or
• With an operational exercise.

• R2.2. Test a representative sample of information used to recover BES Cyber System functionality at least once every 15 calendar months to ensure that the information is useable and is compatible with current configurations.
• An actual recovery that incorporates the information used to recover BES Cyber System functionality substitutes for this test.
• R2.3. Test each of the recovery plans referenced in Requirement R1 at least once every 36 calendar months through an operational exercise of the recovery plans in an environment representative of the production environment.

Tripwire products can be used to collect baselines, logs and event information from a variety of sources. This information can be stored and later used for recovery steps taken after incidents of system attack or failure.

• R3.1. No later than 90 calendar days after completion of a recovery plan test or actual recovery:
• 3.1.1. Document any lessons learned associated with a recovery plan test or actual recovery or document the absence of any lessons learned;
• 3.1.2. Update the recovery plan based on any documented lessons learned associated with the plan; and
• 3.1.3. Notify each person or group with a defined role in the recovery plan of the updates to the recovery plan based on any documented lessons learned.
• R3.2. No later than 60 calendar days after a change to the roles or responsibilities, responders, or technology that the Responsible Entity determines would impact the ability to execute the recovery plan:
• 3.2.1. Update the recovery plan; and
• 3.2.2. Notify each person or group with a defined role in the recovery plan of the updates.

• R1.1. Develop a baseline configuration, individually or by group, which shall include the following items:
  • 1.1.1. Operating system(s) (including version) or firmware where no independent operating system exists;
  • 1.1.2. Any commercially available or open-source application software (including version) intentionally installed;
  • 1.1.3. Any custom software installed;
  • 1.1.4. Any logical network accessible ports; and
  • 1.1.5. Any security patches applied.
• R1.2. Authorize and document changes that deviate from the existing baseline configuration.
• R1.3. For a change that deviates from the existing baseline configuration, update the baseline configuration as necessary within 30 calendar days of completing the change.
• R1.4. For a change that deviates from the existing baseline configuration:
  • 1.4.1. Prior to the change, determine required cyber security controls in CIP-005 and CIP-007 that could be impacted by the change;
  • 1.4.2. Following the change, verify that required cyber security controls determined in 1.4.1 are not adversely affected; and
  • 1.4.3. Document the results of the verification.
• R1.5. Where technically feasible, for each change that deviates from the existing baseline configuration:
• 1.5.1. Prior to implementing any change in the production environment, test the changes in a test environment or test the changes in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration to ensure that required cyber security controls in CIP-005 and CIP-007 are not adversely affected; and
• 1.5.2. Document the results of the testing and, if a test environment was used, the differences between the test environment and the production environment, including a description of the measures used to account for any differences in operation between the test and production environments.

Tripwire Configuration Assessment Policy and Change audit features can address the creation of a baseline configuration of computer systems and alert and report on change - supporting the process of formal change control and testing.

Tripwire supports the tracking and authorization of change to system baseline and configurations - following the process defined by NIST for POA&M reporting

Tripwire baseline comparison operations can verify that a given test environment accurately reflects the production systems.

R2.1. Monitor at least once every 35 calendar days for changes to the baseline configuration (as described in Requirement R1, Part 1.1). Document and investigate detected unauthorized changes.

Tripwire Enterprise's core functionality offers exceptional change detection and investigation capabilities.

• R3.1. At least once every 15 calendar months, conduct a paper or active vulnerability assessment.
• R3.2. Where technically feasible, at least once every 36 calendar months:
• 3.2.1 Perform an active vulnerability assessment in a test environment, or perform an active vulnerability assessment in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration of the BES Cyber System in a production environment; and
• 3.2.2 Document the results of the testing and, if a test environment was used, the differences between the test environment and the production environment, including a description of the measures used to account for any differences in operation between the test and production environments.
• R3.3. Prior to adding a new applicable Cyber Asset to a production environment, perform an active vulnerability assessment of the new Cyber Asset, except for CIP Exceptional Circumstances and like replacements of the same type of Cyber Asset with a baseline configuration that models an existing baseline configuration of the previous or other existing Cyber Asset.
• R3.4. Document the results of the assessments conducted according to Parts 3.1, 3.2, and 3.3 and the action plan to remediate or mitigate vulnerabilities identified in the assessments including the planned date of completing the action plan and the execution status of any remediation or mitigation action items.

Tripwire IP360 offers excellent vulnerability assessment and reporting across a broad variety of asset types.

Tripwire IP360 offers excellent vulnerability assessment and reporting across a broad variety of asset types. Controls exist to minimize the potential for adverse effects during a scan.

SIH reporting can offer very capable analysis and mitigation reports. Can be tailored based on mitigation tools available.

• R1. Each Responsible Entity shall implement, in a manner that identifies, assesses, and corrects deficiencies, one or more documented information protection program(s) that collectively includes each of the applicable requirement parts in CIP-011-1 Table R1 – Information Protection.
• R1.1. Method(s) to identify information that meets the definition of BES Cyber System Information.
• R1.2. Procedure(s) for protecting and securely handling BES Cyber System Information, including storage, transit, and use.

Tripwire Change Auditing feature can be custom configured to assess if an application or operating system is configured for secure data transmission, storage or event logging - itself logging when these settings are changed or suppressed. This feature could support the appropriate management of BES information protection.

• R2.1. Prior to the release for reuse of applicable Cyber Assets that contain BES Cyber System Information (except for reuse within other systems identified in the “Applicable Systems” column), the Responsible Entity shall take action to prevent the unauthorized retrieval of BES Cyber System Information from the Cyber Asset data storage media.
• R2.2. Prior to the disposal of applicable Cyber Assets that contain BES Cyber System Information, the Responsible Entity shall take action to prevent the unauthorized retrieval of BES Cyber System Information from the Cyber Asset or destroy the data storage media.