Last month I ran across the CoreTrace booth at the ISA Expo. Ever since that happenstance introduction, their name and the concept behind their Bouncer product keep popping up in conversations, news feeds, and even Google advertising — mostly in the context of solving SCADA security and compliance issues. Control system server and workstation security has become my passion here lately, so I suppose it’s time to weigh in on the issue of application whitelisting.
I read Marcus Ranum’s “Six Dumbest Ideas in Computer Security” several years back (see dumb idea #2) and it piqued my interest in enumerating the known good (whitelisting) versus enumerating the known bad (signature-based solutions). We’ve even used the terminology a bit when describing the Bandolier security audit files since we are auditing for a secure configuration (known good), as opposed to the traditional Nessus function of identifying vulnerabilities (known bad).
A compelling idea, but there are always concerns about the headache of managing a whitelisting product. Based on what I saw at the ISA Expo, some of these concerns may have been addressed. I don’t have enough exposure to other products like bit9 to know if this is a trend across the various solutions, but CoreTrace seems to have made some advances and they made Network World’s list of “10 IT security companies to watch“.
Digital Bond alum, Matt Franz, questions whether whitelisting is as lame as this blog post (in his opinion) makes it out to be. At least in its modern iteration, let’s hope it is not.
There are sub-issues that we’ll save for later discussion but here’s the point I want to make for now: if the control system application vendors support and adopt application whitelisting, it may have a chance. I had a conversation with one of the major control system vendors who is looking to integrate and support the CoreTrace product. And then I saw this Wonderware partnership. Not sure if two instances are enough to constitute a trend, but I will definitely be watching to see what happens.
What was interesting (but I’m not sure whether it is true or not) about the ESET blog was the proposition that application whitelists were primarily generated by signatures.
Jason, why not go all the way to HID?
Matt: I was confused by the ESET blog. I don’t understand how that could be the case for most whitelisting apps when it is usually the customer that defines the list based on site requirements.
Ralph: Good question — one of the many sub-issues to which I alluded. Asset owners here in North America are dealing with NERC CIP and one of the requirements has to do with malware prevention. The application whitelisting products probably come closer to meeting that requirement (at least according to their claims) than intrusion detection but I’m sure you could make a good case for it as well. [ Assuming by HID you meant host-based intrusion detection. If not, please correct me. ] So for now, if application whitelisting is sold as a replacement for AV and has control vendor support, the market here may be receptive. I’d be curious to know what your observation has been on host security products in Europe…
http://anti-virus-rants.blogspot.com/2008/11/whitelist-opinion-smackdown.html has a better summary of the issues and there might be some responses to my blog in the works ;)
Matt – Thanks for that link. I’m understanding the issue a little better now but still have some questions. It may be a matter of terminology. The ESET blog, for example, says this: “If you white list a program with a remotely exploitable vulnerability, it will be allowed to run.” But the Bouncer product does claim to prevent the exploitable vulnerabilities (e.g., MS08-067) and I saw a good demonstration of that feature in Houston. So maybe what they’re doing and what I’m talking about is more “end point security” than pure whitelisting. From the pure whitelisting perspective, the ESET blog does make more since. I’ve got a call set up with CoreTrace so I’ll follow up with some more information.
Jason, while I know several shops that use HID, I don’t know any that would use whitelisting. There was one case in the German dairy industry in 2007 where a cyber sabotage extortion attempt was successfully countered using a HIDS (see the discussion in Langner & Singer, SCADA threat modeling using attack scenarios, S4 2008).
Ralph – It’s hard to talk about one host-based security technology without looking at its relation to others so I appreciate you bringing up HIDS and sharing your experience. I think there is room for a lot more discussion here and I intend to further explore the application whitelisting products so stay tuned…
regarding the confusion over who creates whitelists and where: some application whitelist vendors actually supply a list (bit9 is one such vendor) while others may not…
regarding the confusion over vulnerabilities: it depends a great deal on the nature of the whitelist… if it is simply controlling which applications get to execute then there will be no protection against the exploitation of vulnerabilities in applications on the whitelist (except where those exploits try to execute secondary non-whitelisted programs)… if the whitelist is applied against a broader range of behaviours in addition to simple execution then it may be possible for the whitelist to stop exploitation in it’s tracks, however such whitelists are not generally referred to as application whitelists…
I believe that the Bouncer product acts like a real time version of programs like Tripwire. You install Bouncer on a system you believe to be free of exploits. It determines and catalogs a signature for every executable on your system. Any time that the OS calls for an executable, a program that resides in the kernel verifies the signature of the called executable before handing it off to the kernel for execution. Thus there is really no need to have a predefined whitelist – the whitelist is created in the same way that Tripwire creates its database. If you can stand the overhead of having every executable get this scrutiny as it is called into the kernel for execution, it appears to do exactly what it advertises – prevents the execution of malware without the use of an AV product.
There was an interesting test of this at a recent conference in which participants were given the challenge to modify an existing virus to create a new exploit that would fool all of the current AV products. Sorry I misplaced the link. Only a whitelisting product was able to prevent the success of the new exploit.
al, that may prevent malware in the form of traditional executable files, but if that’s how bouncer actually works then it’s identical to a feature that appeared in thunderbyte anti-virus in the early 90′s, and it will not stop malware in the form of non-traditional programs (like script malware, office malware, exploit code, etc) because they aren’t executed by the kernel in the first place (but instead interpreted by whitelisted applications)…
Kudos to Kurt for adding some definitional clarity to the app whitelisting discussion, but more is needed. He brings up a very key point:
“if the whitelist is applied against a broader range of behaviours in addition to simple execution then it may be possible for the whitelist to stop exploitation in it’s tracks, however such whitelists are not generally referred to as application whitelists…”
If a technology is finer-grained than the application level, governing behaviors at the data file level or the system call level, then at a coarser level, it might appear to be application whitelisting that is going on, when it fact that some exploit will either not have the system call privilege to execute, or the system library it operates through violates a pre-determined (deterministic) range of acceptable behaviors defined by business/security rules to give context for an allow/deny decision.
al sudduth said: “There was an interesting test of this at a recent conference in which participants were given the challenge to modify an existing virus to create a new exploit that would fool all of the current AV products.” I presume that refers to the Race to Zero fiasco. In fact, as a point of information rather than a direct comment on the whitelisting controversy, my recollection is that the only reason those modifications had any impact on detection is that only passive (static) scanning was used to evaluate the success of the modification. If the judges had known enough to allow the mods to attempt to execute, the results would have been rather different. The better modern scanners use some form of behavior analysis to bolster signatures and passive heuristics, but if there’s no attempt to execute, there’s no behavior to analyse.