Support Site

NERC-CIP

Grid Operations & ConsoleWorks

by

Let’s face it – Maintaining a large, complex IT/OT infrastructure can quickly become a drain on any company’s resources. This is especially true when it comes to Grid Operations for energy providers, whose critical systems must be closely monitored to maintain an uninterrupted flow of energy to customers. The good news is that utility providers can leverage the ConsoleWorks Cybersecurity Operations Platform to manage their infrastructure in a very efficient way.

One of the largest energy providers in the western United States needed a solution that could monitor and manage all of their hardware and software systems, old and new, and provide remote access to servers located in multiple states. ConsoleWorks manages their entire EMS system from a single screen, virtually eliminating the need to staff remote sites. They are also able to improve the efficiency of personnel by automating many of the daily functions which were previously performed manually.

Do you have a challenge? We can help!

NERC-CIP Compliance – Audit versus Intent

by

NERC-CIP compliance is an integral part of the conversation in the Utility industry. Management practices are being continually refined and deployed against it, technology is being implemented because of it, and gaps identified by NERC-CIP audit experiences are driving compliance efforts. Many Utility companies have successfully reached the stage where they can confidently state that they are NERC-CIP compliant. But what does that mean?

First let’s review the difference between audit and intent. An audit is a review process intended to determine if appropriate policies, procedures, and controls are in place as defined by the NERC-CIP compliance regulations. Each Utility company approaches these elements of compliance in their own way because the regulations are a guide, not a prescription.

Intent is a different story all together. We can pass our audits, we can rightfully claim we are NERC-CIP compliant, but that does not mean we are meeting the intent of the NERC-CIP regulations. The intent is that we are supposed to protect our vital electrical power infrastructure so that we all have the electricity we always need and that we have the mechanisms in place to stop potentially disruptive events from occurring. Intent covers both service loss and exposure to service loss. For example, losing generation capability due to generation systems being compromised is a service loss, and a clear NERC-CIP violation. Allowing a security risk to occur that makes the generation system vulnerable to exploitation is also a clear NERC-CIP violation. Both compromise the intent of NERC-CIP. Both cases, should either occur, would take a company that can rightfully claim to be NERC-CIP compliant into being out-of-compliance.

For example, let’s say we have strong physical security in place at a given location where a Cyber Asset exists. There could be a building that has a locked door or a fence with a locked gate. There could also be a cabinet or interlock device that has another lock on it, to ensure only those authorized to access that Cyber Asset can do so. These examples would meet NERC-CIP requirements from an audit perspective and the claim of being NERC-CIP compliant in many cases.

But what if the authorized person who accesses the Cyber Asset fails to follow the procedure for changing, configuring, updating, patching, modifying, etc. the Cyber Asset? What is done could directly lead to a service loss but more likely it would create a threat or vulnerability that we simply do not know about (until something bad happens). Transparency and oversight depend on knowing what each person who touches a Cyber Asset does to it. A procedure for getting approval for, and documenting, all changes will satisfy auditors but any exceptions or deviations from the procedure are a violation of the NERC-CIP and compromise its intent.

The challenge for many Utility companies is now focused on ways to gain oversight and control over NERC-CIP policies. We all know that procedures that people must follow will result in exceptions and errors sooner or later.
So while many Utility companies have solved the challenge of being NERC-CIP compliant, the NERC-CIP challenge has only begun to be addressed. The focus is shifting now to looking for ways to move policies into systems for oversight, simplification, elimination of human error, and proactive response to potential threats.

See Resources for more information on how ConsoleWorks tackles NERC-CIP Challenges.

Let’s Talk about Compliance & Change Management

by

Compliance is one of those subjects that keeps a lot of people up at night. It doesn’t matter what the compliance driver is, whether it’s SOX, PCI, NERC-CIP, HIPAA, etc. Or even if it’s some form of internal compliance policy. Compliance always means the same thing, more demands on us to follow rules and then prove that we have, indeed, followed them.

For both IT/OT operations, the biggest compliance challenge is documenting what privileged users do. Often, this falls into the Change Management bucket. Traditionally there are two things we can do to document what Privileged Users do. The first is to pull information from log files which include information about logins, logoffs, and whatever else is written to a log file while a privileged user is actively logged-on. In years past this information was “good enough” but that has changed, and the implications can be – painful.

The change I am referencing is the requirement to document all activities of privileged users. Gathering log file data only tells us system-generated messages in response to a privileged user’s actions, not what they ‘actually did’. In most cases that information is insufficient to really know what actions the privileged user performed (what commands they executed). This takes us to the traditional change management practice, requiring Privileged Users to manually document all their activities.

How well do you think that works from a compliance perspective? Right, not very good at all. Missing records, inaccuracies, and inconsistencies will happen. Typically, Privileged Users prefer not to produce manual documentation and the time spent doing so takes away from other IT/OT business projects. So, the situation creates poor record keeping, and frustrated Privileged Users.

ConsoleWorks solves this problem. The Platform sits between Privileged Users and privileged interfaces, ConsoleWorks can capture every Privileged Users’ keystroke activity. Digitally signed records are automatically produced, eliminating the need to manually document anything – meeting the needs of the most stringent compliance or auditor requirements.  Happy auditor, and happy users.

ConsoleWorks | Automated Patch Analysis Process

by

Available Q2 2018

The new, Automated Patch Analysis Process from ConsoleWorks will be applicable to various IT/OT patching processes including, PCI-DSS, NIST 800-53, HIPAA, NERC CIP and others.

Automated Patch Analysis Process Use Case: NERC CIP-007-6/R2

NERC CIP-007-6 / R2 requires a patch management process for tracking, evaluating, and installing cybersecurity patches for applicable Cyber Assets, including device drivers. Many utilities see this is a grueling task, requiring many, many man-hours to meet the “every 35-day analysis” required by NERC CIP.

Many utilities are in various stages of implementation of an effective solution with most relying on a manual update of a database, or spreadsheet, that contains the latest patch versions entered for each asset. Traditionally, the asset information has been manually gathered and manually entered since these approaches are disconnected from the assets. These and other manual approaches not only result in inconsistencies and errors, but are enormously labor intensive.

The ConsoleWorks Automated Patch Analysis solution greatly simplifies the process of gathering the information required for patching IT and OT devices – beyond the HMI.

For meeting NERC CIP compliance, ConsoleWorks establishes a secure access to access all devices and then is configured via a schedule to perform the patch analysis every 35 days, keeping a log, for audit purposes, of when the analysis was run. Once the current patch state is gathered by ConsoleWorks, ConsoleWorks can integrate with industry or custom solutions to assist in automating the patch gap analysis. In these cases, ConsoleWorks sanitizes, anonymizes, and encrypts the data before initiating the secure transfer of the collected device information.

After the initial collection is sent, ConsoleWorks can be configured to continually monitor for the patch gap analysis results. When available, ConsoleWorks automatically downloads and processes the results, using ConsoleWorks Events as an indication to the user when patches are available. Event Severities further indicate whether an available patch is a security patch.

Finally, ConsoleWorks produces dashboard report views to organize and communicate the current patch state. ConsoleWorks presents a summary report containing information on patch gaps that may exist for each asset, including links to any available patch for downloading directly from the vendor site.

At this point, a utility will evaluate the available security patch for applicability and make the decision to install the patch or initiate a mitigation plan. ConsoleWorks’ integration with workflow management solutions enables utilities to further automate the patching and mitigation processes as required by NERC.

 

 

The patch analysis features will be available in ConsoleWorks in Q2, 2018, and are part of a larger cybersecurity and operations platform solution addressing IT/OT patching processes for PCI-DSS, NIST-800-53, HIPAA, NERC CIP V6 ( CIP-005, CIP-007, CIP-010, and CIP-013) requirements for Secure Remote Access, Asset and Configuration Monitoring, Endpoint Password Management, Logging and Situational Awareness and Supply Chain.

 

Per CIP-007-5, all ports should be secured or disabled

by

Per CIP-007-5, all ports should be either secured or disabled. This obviously includes configuration ports. However, most substation devices do not allow the disabling of these ports nor should these ports be disabled as they serve important purposes, including being the primary configuration or emergency access port.

Instead, these ports must be secured.

Virtually all electronic devices with communication capability have configuration ports. For modern servers, baseboard management controllers that are networkable are the common configuration port technology. Older servers, routers, switches, firewalls, IED’s, RTU’s, etc. have serial privileged configuration ports, often network-enabled with terminal servers.

Configuration ports exist on almost every device used in Utility operations.  Control systems and control devices have configuration ports. Virtually every PLC, RTU, and IED has a configuration port (usually a privileged serial port with command and control access to the device‘s core program and operating system functions). In remote locations, such as substations and endpoints (poles), there are found many devices that have configuration ports.

From the control room to the sub-station to the pole, these physical ports provide a special level of privileged access that can be used to:

  1. Change Configuration
  2. Upgrade Firmware or BIOS
  3. Build-out devices that have components (like servers)
  4. Perform a variety of Administrative functions
  5. Perform emergency repair or failure recovery when no other port is accessible

Consistent Monitoring and Logging When Nothing Can Be Lost

by

Organizations that must meet stringent compliance standards like NERC-CIP, SOX, HIPAA, and PCI DSS may be subject to fines or even criminal actions if they don’t meet the requirements. In order to be compliant, logging and monitoring must be configured such that they are always running and monitoring everything possible, even in the case of hardware or software failure. Unlike most technology approaches, ConsoleWorks remains fully functional in all modes, including single user, standby, and failure modes enabling consistent monitoring and logging, not just under normal operating conditions, ConsoleWorks meets the most stringent of compliance practices.

Additionally, for organizations with a fault tolerant environment, one with redundancy built into the infrastructure, ConsoleWorks can be used to strengthen that redundancy.

This Redundant Automatic Failover configuration consists of two ConsoleWorks invocations, which under normal operating conditions are simultaneously connected to each managed device in the environment, making the solution fully redundant with no single point of failure. If the primary invocation fails, the secondary invocation continues to monitor and manage the enterprise.

View Datasheets in Resources

We can help

Reach out today, and we'll talk through how we might be able to help!

Contact us