NERC CIP Compliance Gaining Oversight with ConsoleWorks The current challenge for many Utility companies is finding efficient ways to gain oversight and control over NERC CIP regulation compliance. NERC regulations require real-time documentation and reporting on an ongoing basis, with frequent audits. Furthermore, the steep penalties and fines associated with non-compliance emphasize the importance of complying or exceeding these requirements and best practices. TDi Technologies ConsoleWorks approach has the unique benefits of: Achieving security goals without negatively impacting performance Protecting against cyber-based exploits (malware, viruses) Coverage over both in-band and out-of-band networks (both REQUIRE remote and local access) Restricting access and assigning least privilege for all (local and remote) users Recording of user activity (command, control and response) down to the keystroke Automating incident management: alerting, response, best-practice, remediation Bi-directional data capture and logging (all system messages, all user activity) Configurable alerting-alarming for oversight and proactive security event notification Monitoring and alerting on changes to the baseline configurations This document summarizes areas where ConsoleWorks may be effectively utilized to address the intent of the associated NERC CIP requirement. It further distinguishes whether the software helps Meet a specific requirement; Enforce the specifics of a particular requirement or Contributes to addressing a portion of a requirement. The Table below summarizes the specific areas of the NERC CIP requirement where ConsoleWorks adds value to a Utility company s overall security compliance strategy.
Table 1: ConsoleWorks NERC CIP Requirements Map By having ConsoleWorks compliance and security requirements efficiently monitored, a Utility company can focus it s attention to delivering reliable, efficient, cost-effective electricity, and their technology department can focus on solving technical challenges and enhancing customer service to stay ahead of the curve in NERC security and compliance. CIP- 002 R2 Cyber System Categorization CIP-002-4 is focused on Cyber System Categorization. Section R2 is titled Cyber System Categorization and is defined as: Cyber System Categorization To support the proper categorization of BES Subsystems as identified in Requirement R1, and to ensure that Transmission Subsystem owners have accurate information concerning any directly interconnected Generation Subsystem(s) for use in identifying appropriate security controls for their assets, each Responsible Entity that owns any Generation Subsystem categorized as High or Medium BES Impact shall, within 30 calendar days of developing or updating its BES impact categorization of that Generation Subsystem, provide the following information to those Transmission Subsystem owners directly interconnected to that Generation Subsystem: (Violation Risk Factor: High) 2.1. Description of the Generation Subsystem that includes Facility designation(s), or name(s), location, and other identifiers needed to identify the Facility(ies). 2.2. The Responsible Entity name 2.3. The BES impact categorization level CONSOLEWORKS CONTRIBUTES Critical Cyber Asset labels, or tags, can be applied in ConsoleWorks to track asset changes. When labels are changed, assets are dropped, or new assets are brought online, ConsoleWorks can act on these occurrences as events. These events provide notification that Identification records and assets need to be updated or reviewed.
For example, if a Critical Cyber Asset is dropped from the configuration of the ConsoleWorks software, an event can be triggered to notify that this has occurred. Was the asset really decommissioned or removed? Are Identification records updated? Any changes to Identifiers can also trigger events, and can generate notifications for review and oversight. New assets brought online trigger Identification Requirement events if they are not properly identified and Notification events if they are. In a nutshell, changes to the assets that can or could be qualified as Critical Cyber Assets are detected and events are raised to ensure visibility, oversight, and effective management of these assets. While NERC-CIP only requires that these lists be reviewed (and updated) on an annual basis, ConsoleWorks helps to keep records up-to-date at all times and eliminates the vulnerability that comes from periodically reviewing and reconciling changes in our Critical Cyber Asset Identification. It may also ensure the list is reviewed annually to meet the specific requirement. Automatically logging who reviewed the list, when, and include their comments. CIP- 003 R1 Cyber Security Policy CIP-003-4 is focused on Security Management Controls. Section R1 is titled Cyber Security Policy and is defined as: Cyber Security Policy The Responsible Entity shall document and implement a cyber security policy that represents management s commitment and ability to secure its Critical Cyber Assets. The Responsible Entity shall, at minimum, ensure the following: R1.1 The cyber security policy addresses the requirements in Standards CIP- 002-4 through CIP- 009-4, including provision for emergency situations. R1.2 The cyber security policy is readily available to all personnel who have access to, or are responsible for, Critical Cyber Assets. R1.3 Annual review and approval of the cyber security policy by the senior manager assigned pursuant to R2. CONSOLEWORKS ENFORCES Crafting a cyber security policy is one thing but this section reinforces the fact that the cyber security policy must also be implemented. While that may seem obvious, there are a lot more policies that exist in the world than there are policies that are implemented properly and consistently. ConsoleWorks impacts this section of NERC-CIP primarily through its implementation capabilities. Implemented correctly, ConsoleWorks plays an integral part of the overall cyber security policy. The unique capabilities of ConsoleWorks with respect to NERC-CIP, enables it to drive key security policies and practices that otherwise would be difficult to effectively implement if not impossible. A policy that cannot be effectively implemented is certainly not a desirable outcome, and most cyber security policy-makers are looking closely at enabling technologies before crafting their formal cyber security policy. Because many elements of the cyber security policy can be configured directly within ConsoleWorks, it has the ability to programmatically enforce the security policy. For example, ConsoleWorks promotes transparency with the ability to link assets to the appropriate policy
documents. This creates clear visibility to the people that these policies affect with complete logging, auditing, and alarming on the policy and it s violation attempt. A recurring theme in this discussion of ConsoleWorks in the Utility sector is the ability to actually back cyber security policies up programmatically to ensure they are followed. ConsoleWorks plays a fundamental role in the implementation of the cyber security policy, and it helps drive policymaking through the capabilities it provides that directly address multiple NERC-CIP requirements. CIP- 003 R3 - Exceptions CIP-003-4 is focused on Security Management Controls. Section R3 is titled Exceptions and is further defined as: Exceptions Instances where the Responsible Entity cannot conform to its cyber security policy must be documented as exceptions and authorized by the senior manager or delegate(s). R3.1. Exceptions to the Responsible Entity s cyber security policy must be documented within thirty days of being approved by the senior manager or delegate(s). R3.2. Documented exceptions to the cyber security policy must include an explanation as to why the exception is necessary and any compensating measures. R3.3. Authorized exceptions to the cyber security policy must be reviewed and approved annually by the senior manager or delegate(s) to ensure the exceptions are still required and valid. Such review and approval shall be documented. CONSOLEWORKS ENFORCES ConsoleWorks has the ability to document exceptions that occur (by asset) and to report on exceptions as a separate entity in the reporting engine. In many cases, ConsoleWorks can automatically detect and document exceptions to the cyber security policy. The ability to apply business rules that encode the policy into the ConsoleWorks software is an ideal way to address exception management. Time is only spent embedding the rules (once). From there, ConsoleWorks programmatically applies the rules to activities, automatically detecting when an exception occurs and raising an alert to that fact. In addition, ConsoleWorks can automatically record much of the activity associated with an exception including any activity a privileged user takes on a cyber security asset. There is also the ability to force users to provide comments on many actions before they are taken or completed to ensure the proper audit trail is in place. From a compliance perspective, the primary concern with exceptions is that they are properly identified, handled and documented. The primary concern from the business perspective is to minimize the amount of work associated handling exceptions both initially and after-the-fact in order to prove the practice. In both cases ConsoleWorks can programmatically address the majority of exception cases.
CIP- 003 R5 Access Control CIP-003-4 is focused on Security Management Controls. Section R5 is titled Access Control and is further defined as: Access Control The Responsible Entity shall document and implement a program for managing access to protected Critical Cyber Asset information. R5.1.The Responsible Entity shall maintain a list of designated personnel who are responsible for authorizing logical or physical access to protected information. R5.1.1. Personnel shall be identified by name, title, and the information for which they are responsible for authorizing access. R5.1.2.The list of personnel responsible for authorizing access to protected information shall be verified at least annually. R5.2 The Responsible Entity shall review at least annually the access privileges to protected information to confirm that access privileges are correct and that they correspond with the Responsible Entity s needs and appropriate personnel roles and responsibilities. R5.3. The Responsible Entity shall assess and document at least annually the processes for controlling access privileges to protected information. CONSOLEWORKS ENFORCES This is an area where policies often end up being supported in a piecemeal fashion with multiple tools, processes, and practices. That can be a nightmare to oversee and maintain while it injects a significant degree of risk into the practice. This is an important area for ConsoleWorks. ConsoleWorks changes the paradigm with a comprehensive role-based access and control model for all privileged users who are authorized to access the managed devices. The access management program should be directly deployed in the ConsoleWorks software so that it can implement and enforce the policies at a higher level. In all cases, ConsoleWorks maintains a definitive record of personnel who are able to authorize access and personnel who have been granted access to systems managed by the software including which assets they may access and what privileges they have been granted. This information is readily accessible in the ConsoleWorks software for auditing and reporting purposes. Access privileges, access activity (logon, logoff), and activity (commands) performed while accessing assets is all captured automatically with ConsoleWorks and can be used to review and validate that access privileges are appropriate to policy. This is another example of directly implementing policy into supporting technology to ensure policy is executed properly at all times with a comprehensive, and automatically generated, audit trail. While this is a recurring theme in the discussion of ConsoleWorks for the Utility sector, this particular section is comprehensively covered by ConsoleWorks over the entire environment.
CIP- 003 R6 Change Control and Configuration Management CIP-003-4 is focused on Security Management Controls. Section R6 is titled Change Control and Configuration Management and is further defined as: Change Control and Configuration Management The Responsible Entity shall establish and document a process of change control and configuration management for adding, modifying, replacing, or removing Critical Cyber Asset hardware or software, and implement supporting configuration management activities to identify, control and document all entity or vendor- related changes to hardware and software components of Critical Cyber Assets pursuant to the change control process. CONSOLEWORKS CONTRIBUTES This section is one of the most problematic requirements in the entire NERC-CIP specification. While the call to action is relatively easy to understand and build a process for, the implemented process is typically fraught with manual activities that are virtually impossible to implement consistently or manage successfully. These processes are frontloaded with manual activities and back-sided with a lot of manual work to achieve oversight and meet audit requirements. ConsoleWorks can virtually eliminate all manual activity in the implemented processes. No more manual documentation with ConsoleWorks every keystroke over privileged interfaces is recorded in real-time, digitally signed, and reported on. Audit records are automatically generated and oversight is achieved through a single-pane-of-glass. The question still arises as to what we do about build, rebuild, and other configuration activities where an asset has no ability to communicate over normal network ports? Also, what about patching activities and configuration changes to a system in normal operating mode? Capturing the activity of privileged users (not just what log files can generate, based on syslog or SNMP) sounds good, but it s only part of the challenge. ConsoleWorks includes management of normal network ports as well as configuration ports (i.e. out-of-band ports, serial consoles, baseboard management controllers). It also captures information generated by hardware and software for complete closed-loop recording of interactive user sessions. By capturing all information pertinent to privileged user sessions, all log file and message data, and by doing so in all operating conditions (normal ops, standby, singleuser, fault, build, etc.), change management can effectively be controlled and documented automatically across the entire environment. ConsoleWorks solves this problem in a comprehensive and effective manner while reducing the drain (and cost) of the man-hours normally devoted to doing it the hard way.
CIP- 005 R1 Electronic Security Perimeter CIP-005-4 is focused on Electronic Security Perimeter(s). Section R1 is titled Electronic Security Perimeter and is further defined as: Electronic Security Perimeter The Responsible Entity shall ensure that every Critical Cyber Asset resides within an Electronic Security Perimeter. The Responsible Entity shall identify and document the Electronic Security Perimeter(s) and all access points to the perimeter(s). R1.1. Access points to the Electronic Security Perimeter(s) shall include any externally connected communication end point (for example, dial- up modems) terminating at any device within the Electronic Security Perimeter(s). R1.2. For a dial- up accessible Critical Cyber Asset that uses a non- routable protocol, the Responsible Entity shall define an Electronic Security Perimeter for that single access point at the dial- up device. R1.3. Communication links connecting discrete Electronic Security Perimeters shall not be considered part of the Electronic Security Perimeter. However, end points of these communication links within the Electronic Security Perimeter(s) shall be considered access points to the Electronic Security Perimeter(s). R1.4. Any non- critical Cyber Asset within a defined Electronic Security Perimeter shall be identified and protected pursuant to the requirements of Standard CIP- 005-4a. R1.5. Cyber Assets used in the access control and/or monitoring of the Electronic Security Perimeter(s) shall be afforded the protective measures as a specified in Standard CIP- 003-4; Standard CIP- 004-4 Requirement R3; Standard CIP- 005-4a Requirements R2 and R3; Standard CIP- 006-4c Requirement R3; Standard CIP- 007-4 Requirements R1 and R3 through R9; Standard CIP- 008-4; and Standard CIP- 009-4. R1.6. The Responsible Entity shall maintain documentation of Electronic Security Perimeter(s), all interconnected Critical and non- critical Cyber Assets within the Electronic Security Perimeter(s), all electronic access points to the Electronic Security Perimeter(s) and the Cyber Assets deployed for the access control and monitoring of these access points. CONSOLEWORKS ENFORCES ConsoleWorks Remote and local Access Management (RAM) Module is used to consolidate access point security and management. This approach effectively reduces large numbers of access points into a single access point that can be effectively managed. All serial traffic under this approach is captured and monitored by ConsoleWorks while monitoring the serial traffic to the console. It enables companies to consolidate access points that may otherwise be highly distributed. The result is that ConsoleWorks becomes a single access method versus multiple, distributed access points. ConsoleWorks Remote Access Management acts as the Electronic Security Perimeter for the systems that it manages and can include both in-band and out-of-band access points. Capabilities can easily span critical and non-critical cyber assets and apply specific policies to each as well as to selected subgroups in either category. Accurate information is captured and retained at all times, including every access or attempted access, all system messages generated during a session, and all activity by every user down to the keystroke for a comprehensive end-to-end forensic record to support the access control policy. Out-of-band access points are frequently a point of failure for Utility security strategies against NERC-CIP-005-4 R2. Out-of-band access points include baseboard management controllers (i.e. ilo2 (HP), DRAC (DELL), and ALOM, ILOM (SUN/ORACLE) and serial configuration ports. They are privileged interfaces that exist on almost every cyber security and non-cyber security asset in
the Utility infrastructure. ConsoleWorks is a comprehensive solution for out-of-band access point management. They are the vendor s maintenance ports left unaudited or managed, they become the most trusted, most privileged and potentially most risky port in the business. CIP- 005 R2 Electronic Access Controls CIP-005-4 is focused on Electronic Security Perimeter(s). Section R2 is titled Electronic Access Controls and is further defined as: Electronic Access Controls The Responsible Entity shall implement and document the organizational processes and technical and procedural mechanisms for control of electronic access at all electronic access points to the Electronic Security Perimeter(s). R2.1. These processes and mechanisms shall use an access control model that denies access by default, such that explicit access permissions must be specified. R2.2. At all access points to the Electronic Security Perimeter(s), the Responsible Entity shall enable only ports and services required for operations and for monitoring Cyber Assets within the Electronic Security Perimeter, and shall document, individually or by specified grouping, the configuration of those ports and services. R2.3. The Responsible Entity shall implement and maintain a procedure for securing dial- up access to the Electronic Security Perimeter(s). R2.4. Where external interactive access into the Electronic Security Perimeter has been enabled, the Responsible Entity shall implement strong procedural or technical controls at the access points to ensure authenticity of the accessing party, where technically feasible. R2.5. The required documentation shall, at least, identify and describe: R2.5.1. The processes for access request and authorization. R2.5.2. The authentication methods. R2.5.3. The review process for authorization rights, in accordance with Standard CIP- 004-4 Requirement R4. R2.5.4. The controls used to secure dial- up accessible connections. R2.6. Appropriate Use Banner Where technically feasible, electronic access control devices shall display an appropriate use banner on the user screen upon all interactive access attempts. The Responsible Entity shall maintain a document identifying the content of the banner. CONSOLEWORKS MEETS The ConsoleWorks Remote Access Management module approaches access control starting with two baseline assumptions: 1) all access is controlled at all times (gatekeeper) and 2) all access points start with a default of denied. These baseline characteristics are the building blocks of access control. They provide a ground zero footprint where all access points are under control by the gatekeeper and all access is denied. This is like a building with no doors or windows security concept, or a gatekeeper who has padlocked the gate so that no one can enter. Of course denying all access is not practical it is only the default. With role-based access control, permissions are given to authorize access through ConsoleWorks (the gatekeeper). While many access control strategies rely on permissions, ConsoleWorks meets an important security concept in the CIP regulations covering access points. Where we could use asset permissions (like the permissions model built into an operating system) we must first reach that operating system, and that requires establishing a connection through an access point on the security perimeter. This is exactly how ConsoleWorks approaches the problem by controlling, authenticating and authorizing a connection to a target at the access point of the security perimeter. In addition,
ConsoleWorks remains active for the life of the connection (a session), capturing the forensic records of everything that occurs over it. With the role-based access and control model in ConsoleWorks, the user is authenticated and authorized at the security perimeter access point(s). They are then granted the rights (privileges) to connect to ONLY those targets to which they have been granted access. And they can only perform activities that are within their granted privilege level (least privilege). This is a proactive approach to meeting CIP (5) requirements. Additionally, ConsoleWorks can display a customized Appropriate Use Banner to the user with any interactive access attempt. The banner can be customized to require acknowledgement prior to granting access. CIP- 005 R3 Monitoring Electronic Access CIP-005-4 is focused on Electronic Security Perimeter(s). Section R3 is titled Monitoring Electronic Access and is further defined as: Monitoring Electronic Access The Responsible Entity shall implement and document an electronic or manual process(es) for monitoring and logging access at access points to the Electronic Security Perimeter(s) twenty- four hours a day, seven days a week. R3.1. For dial- up accessible Critical Cyber Assets that use non- routable protocols, the Responsible Entity shall implement and document monitoring processes at each access point to the dial- up device, where technically feasible. R3.2. Where technically feasible, the security monitoring processes shall detect and alert for attempts at or actual unauthorized accesses. These alerts shall provide for appropriate notification to designated response personnel. Where alerting is not technically feasible, the Responsible Entity shall review or otherwise assess access logs for attempts at or actual unauthorized accesses at least every ninety- calendar days. CONSOLEWORKS MEETS Essentially this section of CIP defines the need to monitor all local and remote access through the electronic security perimeter for the purpose of detecting, alerting and providing notification on any/all activity that could indicate the attempt (or achievement) of unauthorized access. The purpose is to detect breaches (should they occur) and to proactively detect (and alert on) all attempts to breach the security perimeter. One common pattern that is often a sign of an attempted breach is multiple unsuccessful login attempts, and this is called out specifically in the regulation. However, this section is really focused on the problem of security breaches and attempted breaches which includes (by implication) any activity or pattern related to breaching the security perimeter. ConsoleWorks Remote Access Management manages access points with real-time monitoring, intelligent event detection, and automatically generated notifications. Because ConsoleWorks maintains a persistent monitoring state to all cyber assets, there is a comprehensive record of all activity (not just access logs) that can be scanned for security threat patterns, used to detect events based on those patterns, and leveraged to provide real-time notification of those events.
Unlike most technology approaches to the problem, ConsoleWorks also remains in full operation in all modes. This includes single user mode, standby mode, and failure modes, not just normal operation mode. By retaining full operation in all modes and including all activity in the monitor, detect, alert practice, ConsoleWorks meets not only the explicit requirements of this section of the CIP regulations, it covers the full range of the implied requirements as well. To be completely assured no gap in monitoring and logging, ConsoleWorks supports redundant failover where a pair of ConsoleWorks servers duplicate monitoring in such a way that at least one server is receiving logging information, alarming on important CIP incidents and send notifications to staff in accordance with designated severity levels. The failover process for ConsoleWorks is implemented to maximize availability and eliminate loss of critical cyber asset security status monitoring, event logging, and compliance reporting for strict compliance with CIP-005 R3 and CIP-007 R6. CIP- 005 R5 Documentation Review and Maintenance CIP-005-4 is focused on Electronic Security Perimeter(s). Section R5 is titled Documentation Review and Maintenance and is further defined as: Documentation Review and Maintenance The Responsible Entity shall review, update, and maintain all documentation to support compliance with the requirements of Standard CIP- 005-4a. R5.1. The Responsible Entity shall ensure that all documentation required by Standard CIP- 005-4a reflect current configurations and processes and shall review the documents and procedures referenced in Standard CIP- 005-4a at least annually. R5.2. The responsible Entity shall update the documentation to reflect the modification of the network or controls within ninety calendar days of the change. R5.3. The Responsible Entity shall retain electronic access logs for at least ninety calendar days. Logs related to reportable incidents shall be kept in accordance with the requirements of Standard CIP- 008-4. CONSOLEWORKS MEETS There are really two categories of information this section refers to: 1. Access records 2. Reportable incidents ConsoleWorks automatically captures and generates compliance records for privileged user access over all devices managed by ConsoleWorks. The information ConsoleWorks captures includes each access (what was accessed, who accessed it, when the access occurred) along with the actual, down-to-the-keystroke records of what was actually done in each of these access sessions. This data is digitally signed to meet audit requirements as a true forensic activity log. Of course, ConsoleWorks does not do this for interfaces that are not managed by ConsoleWorks. In addition, if desired, ConsoleWorks can also capture and record any/all data output by the devices that it manages data that resides in log files or that is output as an SNMP trap or SYSLOG message. Because there is no real work involved other than minor configuration, the best practices recommendation is to look at both the output stream (information output by the
hardware/software of a cyber asset) and the input stream (actions taken by privileged users). The capture and reporting by ConsoleWorks is automatic once the system is setup and configured. Reportable incidents are a different story altogether. These are the events as defined by NERC- CIP that must be detected and then the appropriate action taken based on the nature and severity of the incident. ConsoleWorks uses its NERC-CIP IEM (Intelligent Event Module) to detect NERC-CIP incidents in the input/output information streams to identify incidents properly related to the NERC-CIP requirements. Once the NERC-CIP IEM is installed, ConsoleWorks performs detection, analysis, alerting, recording, and report generation automatically. The primary concern in meeting documentation requirements is that they meet internal and external stakeholder requirements with the least amount of effort and the least amount of manual work as possible. ConsoleWorks is directly aligned to this goal, dramatically simplifying the effort behind producing the appropriate NERC-CIP documentation. The information is retained by ConsoleWorks until such time as an administrator archives or deletes it. CIP- 007 R3 Security Patch Management & CIP- 007 R4 Malicious Software Prevention CIP-007 is focused on Systems Security Management. Section R3 is titled Security Patch Management and is further defined as: Security Patch Management The Responsible Entity, either separately or as a component of the documented configuration management process specified in CIP- 003-3 Requirement R6, shall establish, document and implement a security patch management program for tracking, evaluating, testing, and installing applicable cyber security software patches for all Cyber Assets within the Electronic Security Perimeter(s). R3.1. The Responsible Entity shall document the assessment of security patches and security upgrades for applicability within thirty calendar days of availability of the patches or upgrades. 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) applied to mitigate risk exposure. Section R4 is titled Malicious Software Prevention and is further defined as: Malicious Software Prevention The Responsible Entity shall use anti- virus software and other malicious software ( malware ) prevention tools, where technically feasible, to detect, prevent, deter, and mitigate the introduction, exposure, and propagation of malware on all Cyber Assets within the Electronic Security Perimeter(s). R4.1. The Responsible Entity shall document and implement anti- virus and malware prevention tools. 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. R4.2. The Responsible Entity shall document and implement a process for the update of anti- virus and malware prevention signatures. The process must address testing and installing the signatures.
CONSOLEWORKS MEETS & CONTRIBUTES From a management perspective, implementing ConsoleWorks as an Intermediate Device provides comprehensive oversight and transparency. Because ConsoleWorks is effectively a cyber single point of connection (portal) for remote and local users, it has access to all information needed to provide a single source for all access activity. This makes ConsoleWorks the ideal source for single pane-of-glass oversight and situational awareness. Using ConsoleWorks as the Intermediate Device, it can be configured to eliminate the ability to communicate (other than human communication) to the BES through its connections. In other words, no direct, outside protocol is allowed to communicate past the Intermediate Device and ConsoleWorks. ConsoleWorks only allows text to pass through it. In this scenario, ConsoleWorks automatically confirms the user s device has met malware and patch level requirements before allowing the user to connect although this may be instituted as a separate security procedure. CIP- 007 R5 Account Management CIP-007 is focused on Systems Security Management. Section R5 is titled Account Management and is further defined as: Account Management The Responsible Entity shall establish, implement, and document technical and procedural controls that enforce access authentication of, and accountability for, all user activity, and that minimize the risk of unauthorized system access. R5.1. The Responsible Entity shall ensure that individual and shared system accounts and authorized access permissions are consistent with the concept of need to know with respect to work functions performed. R5.1.1. The Responsible Entity shall ensure that user accounts are implemented as approved by designated personnel. Refer to Standard CIP- 003-3 Requirement R5. Standard CIP 007 3 Cyber Security Systems Security Management Approved by Board of Trustees: December 16, 2009 3 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 activity for a minimum of ninety days. R5.1.2. The Responsible Entity shall establish methods, processes, procedures that generate logs of sufficient detail to create historical audit trails of individual user account access activity for a minimum of ninety days. R5.1.3. The Responsible Entity shall review, at least annually; user accounts to verify access privileges are in accordance with Standard CIP- 003-3 Requirement R5 and Standard CIP- 004-3 Requirement R4. The Responsible Entity shall implement a policy to minimize and manage the scope and acceptable use of administrator, shared, and other generic account privileges including factory default accounts. 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 changed prior to putting any system into service. R5.2.2. The Responsible Entity shall identify those individuals with access to shared accounts. 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 authorization, an audit trail of the account use (automated or manual), and steps for securing the account in the event of personnel changes (for example, change in assignment or termination). R5.3. At minimum, the Responsible Entity shall require and use passwords, subject to the following, as technically feasible: 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 annually, or more frequently based on risk.
CONSOLEWORKS ENFORCES & CONTRIBUTES The risk associated with user access to operating systems over the in-band network is compounded by the fact that so many people in the organization require some form of privileged access. Maintaining control over an environment where many people are accessing devices at the operating system level is best achieved through tightly-defined permissions that often include specific set of commands users can execute (and nothing else). The risk associated to configuration port access over the out-of-band network is actually higher than the risk of operating system access because the configuration port has command and control over the operating system and every other component of the server. Configuration ports are the highest privileged interface that exists on every modern server. This makes control (access, permissions, limiting permission to specific commands) over out-of-band interfaces even more important as most organizations have limited controls in place to address this security risk. Several of the more prominent high-risk capabilities provided by out-of-band interfaces are: Mount media devices and copy data Install malware at multiple levels (Bios, Firmware, OS) Add, change or delete user accounts and privileges Change device and component configuration Execute operating system commands without an OS account Open, close or reconfigure network ports Least privilege plays a very important role with in-band access, as the people accessing operating system accounts often touch sensitive data and their activity must be tightly controlled. ConsoleWorks Privileged Access Management module creates and manages an unlimited number of private user sessions to operating system, database or application interfaces. Least privilege remains important with out-of-band access but there are typically more privileges granted for out-of-band access as they are needed for break/fix operations, patching, device configuration, firmware/bios updates, and device build. CIP- 007 R6 Security Status Monitoring CIP-007 is focused on Systems Security Management. Section R6 is titled Security Status Monitoring and is further defined as: Security Status Monitoring The Responsible Entity shall ensure that all Cyber Assets within the Electronic Security Perimeter, as technically feasible, implement automated tools or organizational process controls to monitor system events that are related to cyber security. 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 feasible, to support incident response as required in Standard CIP- 008-3. R6.4. The Responsible Entity shall retain all logs specified in Requirement R6 for ninety calendar days. R6.5. The Responsible Entity shall review logs of system events related to cyber security and maintain records documenting review of logs.
CONSOLEWORKS MEETS ConsoleWorks is unique in that it monitors, logs, remediates, and secures physical, virtual cyber assets in all machine states from power on, single user, maintenance, production and failure. It also is used as a privileged user portal allowing contractors, business partners, service providers, insiders to do their daily activity outside the business application but it still provides the same logging, auditing, monitoring capability for any changes to cyber assets. ConsoleWorks Best Practice Closed Loop Remediation process: Understanding Events Understanding what constitutes an Event by using pre-defined vendor event and failure definitions as well as user defined event definitions, virtually eliminating false positives. Detecting Events - Event detection is accomplished by using the pre-defined event patterns from each asset vendor, and mapping, in real-time, the information received to the vendor messages. Messages may be matched using a number of techniques, including case sensitivity, wildcards, regular expressions and matching across up to five consecutive lines of output. Logging Events Because events are primarily created as a result of output from a managed asset, privileged session, application or log file, the activity leading up to the event pattern match and everything after it is logged. Analyzing Events As an event is detected, it can be checked to see if an event with the same name is already active. It can analyze how many times the same event has already occurred in a particular timeframe. If there is an Action outstanding, ConsoleWorks can generate another event or automatically cancel or acknowledge the event. Notifying of Event Occurrence Notifying when an Event occurs is a core capability of the ConsoleWorks Closed Loop Remediation. Events actually have three distinct states: detected, acknowledged and purged. Each event state has the capability to execute one or more actions that can notify people, integrate with applications such as trouble ticket systems or help desk solutions. Remediating Events Remediating the Event is one of ConsoleWorks core capabilities. When a problem is detected, it provides the user a consistent way to interface with the IT Infrastructure to solve the problem and quickly perform root cause analysis all the while capturing the process, commands and method used by the user to solve the event. Documenting Event Resolution Documenting the resolution of the Event is a natural follow-on to the event resolution. Because ConsoleWorks understands who solved the event, as well as the commands and responses used to solve it, the users session is documented by the product and automatically associated with the event, creating a history of event resolutions, as well as allowing one of the resolutions to be tagged as a Best Practice for the business. Validating the Event Resolution Validating the correct resolution of the Event can be accomplished as part of a role within ConsoleWorks such that only a supervisor or other privileged overseer can validate and ultimately close the event resolution. Resolutions are tagged with the event and are able to be reviewed by specific roles to ensure
compliance with the Best Practice and to make sure that nothing else was done that should not have been. Since everything is logged this is an easy task when someone wants to do it either for Compliance reporting, Audit reporting or simply operational review during a shift change. Purging the Event Purging the event from the set of Active events is effectively closing the event and removing it from the set of active events in the system. Reporting on all Events Reporting on all Events is critical to shift changes, compliance and audit actions. Being able to quick identify what events have occurred, how many times they happened, how log it took to solved the event, who solved it and what they did to correct it makes a sometimes difficult and timely task, simple and quick. ConsoleWorks captures remediation information, character-by-character, response for response, as the remediation occurs. This allows for the institutionalization and consistency of best practices for a particular Event. Not only does this capability allow knowledge to be available for future reference or to be leveraged by a less experience user, but it also ensures knowledge remains as employees leave, dramatically reducing the training and re-training costs associated with new employee orientation. In this way, ConsoleWorks builds the business s data warehouse of intellectual property relating to problem resolution and business operational Best Practices, resulting in consistency of problem resolution and yielding better reliability and availability for the business. CIP- 010 R1 Configuration Change Management (Version 5 DRAFT) CIP-010 is focused on Systems Security Management. Section R1 is titled Configuration and Change Management and is further defined as: Configuration and Change Management Each Responsible Entity shall implement one or more documented processes that collectively include each of the applicable items in CIP- 010-1. R1.1. Develop a baseline configuration of the BES Cyber System, which shall include the following for each BES Cyber Asset identified, individually or by specified grouping. R1.2. Authorization, by the CIP Senior Manager or delegate, and document changes to the BES Cyber System that deviate from the existing baseline configuration. R1.3. Update the baseline configuration and other documentation required by a NERC CIP Standard, including identification and categorization of the BES Cyber Systems, as necessary within 30 calendar days of completing the change. CONSOLEWORKS MEETS ConsoleWorks automated Baseline Configuration Management solution is designed to provide managerial visibility and control over the BCM practice while eliminating the majority of sources where human error can result in unintentional device configuration changes that impact the overall security practice. Without automation, BCM is a costly operations activity that is difficult to manage and prone to mistakes that can leave the Utility provider vulnerable to cyber attack. ConsoleWorks Baseline
Configuration Management solution looks at the problem holistically by taking a device and platform agnostic approach for supporting all routable protocol devices. The Utilities industry, in particular, is required to meet certain NERC-CIP requirements for establishing and retaining a set of secure configuration profiles across hundreds, often thousands, of cyber assets. Manufacturer point solutions exist in a few cases today. However, the limited capabilities vary across manufacturers and the functionality is inadequate for addressing the basic NERC CIP requirements. While the obvious driver behind interest in a comprehensive BCM solution is driven by NERC-CIP regulations the ConsoleWorks BCM solution enables Utility providers to meet NERC-CIP requirements while simplifying operations and reducing manpower requirements it addresses a real business challenge. Baseline Configuration Management requires that we have a known good configuration on a device (the baseline). The configuration for the device is then pulled on a periodic basis and compared to the baseline. If the configurations are the same then the baseline for the device has been validated. If they are not the same then the configuration for the device is invalid and the differences must be looked at to determine what action will be taken. A typical action might be to notify a specific person that a deviation has been detected on a current baseline or to set a new baseline based on the outcome of a configuration review. Most organizations have people pulling these configurations into excel spreadsheets for comparison. Getting the data is a manual activity. Comparing the data is a manual (potentially spreadsheet automated) activity. There are a lot of devices. It takes a lot of time and mistakes are easy to make. CIP- 010 R2 Configuration Monitoring (Version 5 DRAFT) CIP-010 is focused on Systems Security Management. Section R2 is titled Configuration Monitoring and is further defined as: Configuration Monitoring Each Responsible Entity shall implement one or more documented processes that collectively include each of the applicable items in CIP- 010-1. R2.1. Where technically feasible, monitor for changes to the baseline configuration (as defined per CIP- 010 R1, Part 1.1) and document and investigate the detection of any unauthorized changes. CONSOLEWORKS MEETS Configuration data is often not a simple file of data. With ConsoleWorks the entire process of pulling the configuration, comparing against the baseline, alerting on differences, and enunciating where changes have occurred is completely automated. ConsoleWorks automates baseline configuration management of all cyber assets from the control room, to the substation, to the pole. It periodically retrieves the current configuration of each
monitored asset and compares it to the established baseline. If a difference is detected, an Event is created and logged and a notification is sent to a designated person for further assessment. The ConsoleWorks BCM solution offers the following key functions: Configuration Retrieval automatic collection of actual device configurations Baseline Establishment designation of an approved configuration baseline Auto-Comparison comparison of current configuration against the baseline Event Detection generates events (alerts) when a difference is detected from the established baseline configuration and the current device configuration Scheduling frequency that comparisons are run Manual Trigger manual running of comparison Historical Reference the ability to maintain a number of historical baselines including all BCM events detected About This Whitepaper This whitepaper was written to help address security vulnerabilities that are often overlooked and misunderstood in the Utility industry. The recommendations provided are believed to be accurate in their applicability and support for Versions 3, 4 and DRAFT Version 5 of the NERC CIP requirements. Full Disclosure This whitepaper was written and produced by TDi Technologies, a software vendor that provides security, compliance and operations software solutions to the Utility industry and other vertical markets. The information presented here represents our best understanding of the issues associated with Utility companies meeting NERC CIP requirements, which is an area of focus for TDi Technologies. The whitepaper is intended to provide useful and educational content that can assist Utility companies in providing secure, dependable power to our Nation without interruption.