Skip to content ↓ | Skip to navigation ↓

There are roughly 200 requirements and sub-requirements in NERC CIP, and to satisfy each one requires performance-based compliance evidence that produces the comprehensive documentation that proves each requirement and sub-requirement was met for all activities that fall under it.

That by itself is no mean feat. Of those 200 requirements, baseline configuration management and monitoring is one of the most daunting. It’s easy to understand when we look under the covers.

First, there are the baselines themselves. In NERC CIP, the mandatory baseline items for protected cyber assets include security patches, ports and services, and software (including version). In this blog post, I will focus on security patches.

At a high level, NERC CIP requires we know our patch sources and the tools used to monitor for new security patches. The patch sources that are monitored must cover all of the software, operating system and firmware in use in the protected environment.

These patch sources must be monitored at least every 35 days and any new security patches must be documented. Both patch sources and the new security patches list are NERC CIP evidence.

All of the new security patches must be evaluated to determine if the patches are applicable to one or more cyber assets. The patches should also be evaluated based on their severity and /or risk levels. The resulting list of new applicable patches is the list of security patches that must be installed within the next 35 days.

Many of the applicable patches will apply to multiple cyber assets, so there is also the challenge of maintaining the perspective of “n” applicable patches to “n” cyber assets. This is best managed through an intermediary binder called “Patch Baselines” – a many-to-many binder for applicable patches and cyber assets. This is important because the security patches must be installed through a change management process that is also NERC CIP compliant.

The other big challenge is validating baselines, which requires one or more tools that can collect this information directly from the cyber assets. That data must be both collected and normalized before it can be validated against the approved baselines for the protected cyber assets.

Although this data can also be collected through administrator commands and scripts, the task of building these tools is too onerous for most organizations, and ongoing maintenance can quickly turn into a nightmare.

Finally, there is the issue of mitigation. In many production environments, energy entities cannot install patches on critical operations systems. Electricity generation, transmission and distribution is a 24/7/365 operation and there are many systems that can only be updated during planned maintenance windows.

In this case, a mitigation plan is required, with compensating measures and a planned mitigation completion date (when the mitigation issue will be resolved).

All this may not sound that daunting, but when you think about the fact that new security patches are likely to be available every time patch sources are checked (not more than every 35 days), things start to really hit home.

What would it be like if every month we were battling a poorly designed solution involving multiple requirements/sub-requirements, each of which required specific performance-based evidence? Ahhh, now the lights go on!

So, take the time to do it right, and get an effective patch management and change management program in place early. It will take a good bit of effort, but it’s far better to design the program right once then to have to try and make a broken program work every 35 days.

 

Terry SchurterAbout the Author: Terry Schurter is co-author of the book Protecting Critical Infrastructure which will be released in April 2016 – click here to sign up to receive a 20% off discount.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.

Title image courtesy of ShutterStock