In Part 1 of this series, I walked through the background of the NERC CIP version 5 controls and outlined what needs to be monitored for NERC CIP software requirements. In this second half of the series, we’ll take what we’ve learned and explore approaches for meeting the requirements while considering security value. NERC CIP is supposed to be for security, after all!

NERC CIP Tools

At a high level, Tripwire’s Whitelist Profiler, a Tripwire Enterprise product extension, has many of the features needed for meeting the software monitoring requirements. But process is important, as well. Additionally, in some cases, there are multiple approaches to a requirement, so the entity gets to choose what fits best for their interpretation and process.

OS and Firmware Version Monitoring

OS version is generally tracked one of two ways, but both are easy. With a strict change management approach, Tripwire Enterprise can read the OS version and show if there are changes, which of course are very rare. A more scalable approach with policy is to also test the OS version, so the result flows into a unified view of compliance.

Probably the slickest approach is to monitor the OS version with Tripwire Whitelist Profiler’s so-called “additional software” feature. The OS version will be reported right along with other software, or the implementation can even be broken out to show OS version per its CIP part number.

Firmware

Firmware version is similarly monitored by reading it from the device. Add to that a test in Tripwire Enterprise, and the control can be represented in a graphical summary red/green compliance view. The main variance customers ask to accommodate is during firmware updates across a fleet of devices where more than one version would be considered acceptable. This use case, however, is easily accommodated (Read more...)