Does NERC Have the Resolve to Protect the Grid from Cyber Attack?

The North American Electric Reliability Corporation (NERC), whose mission is to assure the reliability of the bulk power system in North America, has proposed a surprisingly lax interpretation of its own regulations regarding  malicious code detection for  computer systems that may have a significant impact on the Bulk Electric System (“BES”).

At issue is a rather obscure regulation referred to as Part 3.2 of CIP-007-5.   This regulation is part of the CIP Version 5 standards which NERC developed to enhance the cyber security of the BES.    Part 3.2 requires owners and operators of computer systems that may have a significant impact on the BES to “Mitigate the threat of detected malicious code.”   Measures of compliance may include, but are not limited to:

  • Records of response processes for malicious code detection
  • Records of the performance of these processes when malicious code is detected.

Apparently, NERC has been presented with the following questions owing to an interpretive controversy that has arisen under Part 3.2:

For the implementation of malicious code prevention, should entities choose to deter, detect, or prevent malicious code? If an entity chooses to deter, how should they plan on complying with CIP-007-5, R3, Part 3.2 since there would be no mechanism to detect? Is there an implicit requirement in Part 3.2 to deploy detective controls?

On November 20, 2014, NERC posted for industry comment the following answer :

Part 3.2, in and of itself, does not have an implicit requirement to deploy detective controls; rather, Part 3.2 works in concert with other CIP requirements, such as CIP-007-5, R4, Part 4.1.3 which requires logging for malicious code. Under Part 3.2, Responsible Entities have an obligation to mitigate malicious code whenever it is detected through any means. Responsible Entities have asked what the relationship is between Part 3.1 and Part 3.2. Whereas Part 3.1 gives Responsible Entities the choice of deploying deterrence, detective, or preventive controls, Part 3.2 simply states detected malicious code must be mitigated. Posted: November 20, 2014.

Surprisingly, NERC takes the position that “Part 3.2, in and of itself, does not have an implicit requirement to deploy detective controls.” While certainly not a silver bullet, malicious code detection is considered a basic and essential aspect of the cyber security controls typically deployed to protect critical infrastructures. Leaving an entire BES Cyber System without a means for detecting malicious code is clearly inconsistent with best practices followed by the industry. [Refer to NIST Special Publication 800-82 Revision 2, Guide to Industrial Control Systems (ICS) Security, page 6-11.] Malcious code detection technologies are varied, and are the subject of an excellent whitepaper by Alisa Shevchenko from Kasperky Lab.  Malicious code detection software has two components: (a)  a collection of program functions and algorithms that select data and (b) an  analytical component that examines collected data which may be anything from text strings within a file, to a specific action the program performs, to a full sequence of actions that the program performs, and more.

The CIP v5 drafting team declined to prescribe a particular technical method for detecting malicious code, and they further declined to prescribe that malicious code detection must be used on every Cyber Asset. But it is a contorted and distorted interpretation of Part 3.2 to suggest that the Federal Energy Regulatory Commission (“FERC”) or the CIP v5 drafting team would approve of leaving a BES Cyber System within an electronic security perimeter without a means for detecting malicious code. In its original order approving the CIP standards, FERC emphatically states, “[W]e believe it is in the public interest to protect all cyber assets within an electronic security perimeter, regardless of the operating system being used…[FERC Order 706, par. 620.] While we agree that no safeguard will protect against all malicious or unintentional acts, this does not mean that systems should not be protected against such acts.” [FERC Order 706, par. 621.]

Historically, NERC has repeatedly asserted that its cyber security regulations are intended to address cybersecurity threats that are increasing in number and sophistication.  Making the use of malcious code detection technology optional does not appear consistent with the intent of its cyber security regulatory scheme. In fact, if we delve into the finer details of the parent of Part 3.2, which is CIP-007-5 Requirement R3, the rationale for the parent regulation emphasizes that the purpose of the requirement is to both limit and detect malicious code from adversely affecting the Cyber Assets of a BES [Bulk Electric System] Cyber System.

Rationale for R3: Malicious code prevention has the purpose of limiting and detecting the addition of malicious code onto the applicable Cyber Assets of a BES Cyber System. Malicious code (viruses, worms, botnets, targeted code such as Stuxnet, etc.) may compromise the availability or integrity of the BES Cyber System.

NERC’s contorted interpretation of the Part 3.2 regulation – that the use of malcious code detection technology should be considered optional – is devoid of any meaningful discussion of the cybersecurity defense concerns expressed in the rationale for CIP-007-5 Requirement R3. The absense of such a discussion calls into question whether NERC really has its eye on the ball – the cyber security of the grid.

I would answer the question concerning how entities should interpret Part R3.2 as follows:

There is an implicit requirement in Part 3.2 to deploy detective controls. The rationale for CIP-007-5 R3 emphasizes that the purpose of the requirement is to both limit and detect malicious code from adversely affecting the Cyber Assets of a BES Cyber System. The express language used in Part 3.2, which refers to the mitigation of “detected malicious code,” inherently requires the deployment of detective controls. When malicious code is detected on a Cyber Asset within the applicability of this requirement, the threat posed by that code must be mitigated. While Part 3.2 does not prescribe or require a single method for protecting against the introduction of viruses or malicious software to a cyber asset, there must be one or more methods that collectively limit and detect malicious code.

Enhancing Cyber Security for Critical Infrastructures

Solely relying on patching, using anti-virus software and protecting systems behind firewalls is not going to be an effective cyber defense strategy, so say experts quoted in a New York Times article by Nicole Perloth published December 3, 2014.

“[A]t every level, there has been an awakening that the threats are real and growing worse, and that the prevailing ‘patch and pray’ approach to computer security simply will not do… Companies that continue to rely on prevention and detection technologies like firewalls and antivirus products are considered sitting ducks.”

The better strategy is to take a layered, “defense-in-depth” approach to data protection.  This approach requires the identification of an organization’s most valuable information assets.  The systems that create, store and transmit these high-valued information assets are then isolated from less trusted networks, and other  enhanced security control messures are applied.   The “defense-in-depth” strategy is the de facto standard for protecting critical infratructures, and is described in the Department of Homeland Security publication, “Recommended Practice: Improving Industrial Control Systems Cybersecurity with Defense-In-Depth Strategies.”

Key elements of cyber security inevitably boil down to five  categories of controls: (1) security policies; (2) blocking unauthorized access to resources and services; (3) detecting malicious activity; (4) mitigating possible attacks; and (5) fixing  problems.  Any strategy that does not effectively address all five of these key elements is unlikely to provide reasonable assurance that an organization has properly addressed its cyber security risks.