Standards Dog Chases Tail While Reliability/Security Rabbit Races Ahead

With the news of FERC ordering a Supply Chain Management Standard to be enforced upon NERC-Registered Entities, I wanted to offer up a few thoughts:

Better Late Than Never

While there have been several use-cases in recent years for the need of expanding awareness around supply chain management vulnerabilities, the impetus for formalizing a new regulation came from the highly publicized introduction of the Stuxnet vulnerability into the Iranian Nuclear Program. If you’ll recall, this was where the Siemens Programable Logic Controllers (PLC) were intercepted mid-shipment to Iran and had the Stuxnet virus installed before the shipment continued to its destination. When the PLCs were deployed and configured to manage the centrifuges within the Iranian nuclear reactors without testing them for any malware on vulnerabilities, the outcome was what we’ve all seen- the centrifuges spun out of control and self-destructed. This was 2012 people! Time sure does fly. Four years gone and our regulators are just now ordering a standard be developed? Let me be clear. I’m not criticizing FERC/NERC for wanting to implement a Standard. My concern is, and has always been, that the pace at which our regulatory process and standards development process moves is far too slow to keep up with current threats.

2. We already have a Supply Chain Management Standard- NIST SP 800-161 “Supply Chain Risk Management Practices for Federal Information Systems and Organizations”

You’ve all heard me bang this drum for years. From a security best practices perspective, we should all be implementing as much of this NIST program as possible. My hope is that the Standards Drafting Team that NERC stands up to develop this new standard will leverage as much of NIST SP 800-161 as it can and doesn’t try to reinvent the wheel. The push back I hear all the time is “But Chris, it’s not feasible to expect electric utilities to have the knowledge or resources to implement NIST.” I have always respectfully disagreed with that position and with tools like the SANS Top 20 Critical Controls, which I refer to as the “Cliffs Notes” for NIST, utilities have more than a manageable and practical starting point to look at NIST as their organization’s security framework. The bottom line is that if your security and operations team doesn’t have the expertise to even spell NIST, that’s a huge problem. By implementing a security-focused program of processes, controls, and technologies through NIST, your organization will produce the natural byproducts to satisfy any regulatory mandate- including NERC. Simply having a compliance-focused security program will always keep you chasing your tail to the next outdated regulation and you’ll never be secure, efficient, or reliable even though they are called the NERC Reliability Standards. Aren’t they?

3. Does your organization really need a formal standard to tell you that you should be testing any/all third party software/hardware before deploying it within your operational environment? 

This is the most alarming concern I have. If you answered “yes” to the above question, the state of security within our industry is in horrible shape. Nothing gets me more fired up than when I speak to a security “expert” at a utility he says: “There’s no NERC requirement for me to do that.” I’m sure that’s exactly what the Iranians said before they installed those PLCs in their nuclear reactor.

Chris new


Chris Humphreys, CEO & Director

 / No Comments  / in General

Post a Comment

Your email address will not be published. Required fields are marked *