NERC CIP and Application Whitelisting Redux
My recent blog post on application whitelisting, and specifically the Bouncer solution, sparked a lot of offline discussion. One of those conversations was with someone who has a significant stake in NERC CIP and agreed to let me post his comments. I try not to get too involved in hair-splitting discussions about standards compliance but I thought this was well said. It is also potentially useful information for organizations working on CIP and interested in whitelisting.
He writes this regarding CIP 007-R4 (Malicious Software Prevention):
I would agree that Bouncer could be viewed as an anti-virus solution. It will certainly prevent an installed virus (either new executable or medication of an existing executable) from running as long as no one added it to the white list. That would allow the entity to be compliant with R4 and R4.1. There may be an issue with R4.2 depending on how “signatures” are viewed. If the signature is the white list, then R4.2 would require testing before installing on the Cyber Assets in the Electronic Security Perimeter. And, of course, there is always the issues of inadvertent white listing of malware, either because a system is re-baselined or an injection attack as mentioned by a commenter in the blog. Bouncer may prevent malware from executing, but it does not as far as I know prevent the malware executable files from being installed onto disk.
Regarding CIP-007 R3, he continues:
“Bouncer will not result, in and of itself, in an entity being compliant with R3. The entity is still required to assess patches within 30 days of their availability. Just because you are running Bouncer on a Windows platform does not mean the entity no longer has to assess the monthly Microsoft patches as required by R3.1. For each patch not applied, the entity will have to document Bouncer as the compensating measure (remember, the acceptance of risk goes away with Version 2 of the standards which become effective and enforceable April 1, 2010). Same goes for patches from other vendors. If the entity simply blows off a patch management program because they have installed Bouncer, they will find themselves in violation of the standards with a financial penalty. And, I would offer that the entity will likely want to go ahead and patch anyhow for two reasons. First, as any good defense in depth strategy does, you want to layer your defenses. In the unlikely (or maybe likely given a comment to your blog) event that you have to turn off Bouncer or malware is inadvertently white-listed, you do not want to leave your system exposed. Secondly, patches sometimes include desirable features, or provide the ability to install a desired or required feature (we are talking interdependencies here.)”
This is sound reasoning and I had no quarrel with it. I did, however, state my opinion that doing something (application whitelisting) might be better than doing nothing (no patching, no AV). His response:
Doing something may be better than nothing, but from a compliance perspective, not strictly complying will result in a potentially significant violation and financial penalty.
And that’s where security and compliance become two different games…
Author: Jason Holcomb
Posted: October 23rd, 2009 under Anti-Virus, NERC CIP.
Comments: 9
Comments
Comment from Michael Toecker
Time: October 23, 2009, 12:59 pm
Which is why I am surprised that no asset owners using or contemplating using whitelisting have submitted an interpretation request to NERC. Having NERC clarify a functional definition of Anti-Virus would be beneficial, as it would potentially include OTHER types of malware prevention.
Vendors of application whitelisting, if they believe their product meets the intent of NERC standard, should be actively petitioning their users and OEMs to get this taken care of. Potential customers are literally waiting for a someone to initiate a ruling on whitelisting so they can use it on their systems.
Mike Toecker
Burns & McDonnell
Comment from Jake Brodsky
Time: October 23, 2009, 9:36 pm
I agree with Mike’s comment above. This is the hazard to writing excessively prescriptive standards instead of writing about philosophies and models of design.
Comment from Rob Lewis
Time: October 24, 2009, 9:33 am
Compliance can become a barrier to innovation if it does not keep up with the curve. It does so when it goes beyond “what” must be done and prescribes “how” it must be done.
The notion that malware that breaches the filters but that can’t execute, is a threat, makes no sense, since the value of the threat variable, and hence overall risk, in the risk equation becomes zero. The problem is that the compliance focus is solely on vulnerabilities to reduce the risk, leaving no room for other approaches. A whitelisting technology can provide core protection until an old school technology like AV signatures will eventually catch up and remove the neutralized malware with a disk clean-up.
Comment from Daniel M Teal
Time: October 26, 2009, 12:16 pm
Compliance does not mean secure.
We are familiar with the above statement. We all know that security compliance may increase security, but not completely provide it. A great example of this occurred last fall within the DOD. Systems running in the DOD networks were compliant with FIPS 140-2, common criteria, and other standards. The systems and networks were operated by a staff of trained professionals. Even with all of the compliant security measures in place, conficker still propagated throughout the DOD networks causing over $100 million in cleanup costs. A similar problem occurred at Heartland Payment Systems. Even though Heartland was fully PCI compliant, hackers still stole information on the 100 million credit card transactions that are processed each month.
Compliance is important, but we must remember that compliance standards may take years to create and are never updated fast enough to stay current with today’s threats. Organizations must protect against the threats of the past by being compliant. They must also defend against the threats of today by being proactive. Application whitelisting is the proactive solution against today’s threats and must become the cornerstone of any security strategy.
Disclaimer: I am the CTO and Founder of CoreTrace Corporation, an application whitelisting vendor
Comment from Tim Anderson
Time: October 26, 2009, 11:40 pm
Anti-virus software was designed for Windows user systems which surf the Internet. And we know that CIP regulated control systems are not connected to the Internet and are ideally not implemented on Windows.
And we know that the anti-virus app just introduces a new attack vector that if too often exploited. So by following the letter of the law, we can make the system more vulnerable. So how does this requirement make any sense as it written?
If an entity is trying to follow the spirit of CIP, this is one case where the proper action seems to be to ignore the poorly stated language of the requirement and just provide a rational solution that protects control systems from malware. Why would NERC cite or fine an entity for taking this approach? Why should this even have to be a TFE?
A network based solution makes a lot more sense for a LAN with a solid ESP perimeter and strong routing restrictions. Forcing host based agents on every host system is a wasteful use of processor and too much overhead to manage all those signatures on all those machines. Whitelisting is makes more sense than antivirus, but it still requires agent software to manage on each host. And in a CIP regulated world, who needs more stuff to keep track of and test?
Comment from Rob Casey
Time: October 27, 2009, 7:53 am
“Compliance can become a barrier to innovation if it does not keep up with the curve. It does so when it goes beyond “what” must be done and prescribes “how” it must be done.”
This is an interesting comment which goes to the very heart of the interplay between compliance and innovation. Typically where an issue is presented with cross-disciplinary impacts, all stakeholders seek to address this with whatever tools they have available to them. For legislators this is through regulation and compliance measures, for engineers this is through technical innovation and architects through definitions of scope and interface. It is however only in the balance of these items that a workable solution for all stakeholders can be achieved and to this end, that there can be gaps found in the extent of the solution components proposed by the various stakeholders.
Comment from Ken Posey
Time: October 28, 2009, 5:06 pm
Although the original post sites “Bouncer may prevent malware from executing, but it does not as far as I know prevent the malware executable files from being installed onto disk.” This is technically true (although “written to the disk” is more accurate than “installed onto disk”), but BOUNCER also allows for a scheduled “scrub” of machines. The scrubbing process allows for a comparison of the executables on the machine to the executables on the Whitelist (including those added through the Trusted Change mechanism). Anything not on the Whitelist can either 1) Be reported on and investigated, then manually deleted or 2) Automatically deleted, taking the system back to it’s “Whitelisted-only” executable state immediately.
This process, much like the AV process, looks at the “known signatures” (in this case known-good rather than known-bad) and uses those signatures to eliminate unwanted, unapproved or potentially dangerous executables. In this way, signatures ARE regularly updated when Trusted Changes are made to the system (not necessary to update known-good signatures, unless the known-good changes), and a regular “scan” is conducted to ensure that only the desired and required files are on the system at any given time. Is this not the point of Anti-Virus, even though it cannot ever achieve this result using only the “known-bad” concept?
DISCLAIMER: I also work for CoreTrace, maker of the BOUNCER by CoreTrace Application Whitelisting solution
Comment from Charisse Castagnoli
Time: October 29, 2009, 9:30 am
Regarding CIP 007-R3
In the discussion of patching I don’t often see the risk of applying the patch included in the calculus. According to the standard “Responsible Entities should interpret and apply Standards CIP-002 through CIP-009 using
reasonable business judgment.”
Due to the complexity and interdependency of depoloyments, it is not unheard of for a patch to cause catastrophic failure – hopefully caught in testing.
If the purpose of patching is to eliminate a vulnerability and decrease the attach surface, and white listing provides a compensating control by reducing (substantially if not completely) the risk of exploiting said vulnerability – then why should I risk my system stability with unnecessary change?
So long as the assurance and “security” risk are unaffected by not patching I personally wouldn’t want to do it – if for no other reason than configuration drift and management.
Remember – configuration changes (installing new patches) have implications on policy management as well since configuration changes to be re-incorporated in the policy.
Charisse Castagnoli
Disclaimer – I am a part time contractor at CoreTrace.
Comment from Dale Peterson
Time: October 29, 2009, 10:31 am
FYI – Industrial Defender performed an independent analysis of a number of white listing solutions. They have analyzed if and where it is appropriate in control systems and what are the pro’s and con’s of the more popular offerings. They will be presenting this paper at S4 in January.
I don’t know the results, but am looking forward to the paper and preso.
See the S4 Agenda at: http://www.digitalbond.com/wp-content/uploads/s4/S4_2010_Agenda.pdf
Also I may need to put a cap on number of different comments, but kudo’s to CoreTrace commenters for disclaimer and avoiding hype.
Write a comment