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.