how do you defend the use of blacklists in the face of seemingly stronger defensive mechanisms like whitelists?
no matter what defensive technology you use there will always be some holes in those defenses... there will always be exceptional cases that your defenses don't currently handle and/or are unsuitable for handling... what's the fastest/easiest way to deal with exceptional cases you want to avoid? yeah, you guessed it, with a blacklist...
let me give you an example: lets say that we have an application whitelist... application whitelists control the execution of some subset of known program types... they're limited to the known types because, well, how do you intercept a kind of execution that's never been seen before?... they're also usually limited to a subset of the known types because developing the technology to intercept and block programs of an arbitrary type (such as script programs for a particular interpreter, or the unanticipated programs that exploit code represents) is not necessarily easy or cheap and for the more obscure types it's often just not worth the investment...
now lets say that a piece of malware is created that exploits this partial coverage of the set of program types... when there's only one such piece of malware, or even just a handful, the benefits of re-engineering the application whitelisting software to be able to cope with this additional type don't justify the costs in terms of time, money, and effort required to do it... when there are so few instances (relative to the billions of programs out there) it is faster, easier, and cheaper to just look for those particular instances (via a blacklist) than to re-engineer the whitelist to handle them... it won't be until the program type in question becomes mainstream that it becomes worth it to add capabilities for it to an application whitelist...
similar scenarios can be constructed for any other type of preventative measure... as such there will always be a need for blacklisting regardless of what other defenses are in play because there will always be a need to deal with emergent exceptional cases as fast and cheaply as possible... even malware blacklists (ie. known malware scanners) themselves have exceptional cases that they can't deal with - that being new/unknown malware... however, as i've stated in the past, novelty is an advantage that wears off, and as far as i can tell it's the only one that does...
5 comments:
Kurt,
I didn't know whether to comment here or in your whitelist smackdown post. I think I am straddling the two.
You commented on Digital Bond, "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".
I have followed-up there and on Randy Abrams blog with comments about behavior whitelisting, which is of course much more granular than app whitelisting and impacts this discussion.
Your comment describes what Trustifier technology does. If you think back to some of our past discussions (both here and at other blogs) then you may better now understand my position at the time, which I attempted to continue to express until I reached my non-technical limit of understanding. (Hey, I'm only a biz dev guy).
yes, i recall our discussions about trustifier and behavioural whitelists... i recall that it is much more fine-grained than an application whitelist, but i also understand that the question of what is a program is itself even more fine-grained than that...
since it's still coarser-grained than the problem it's attempting to address (control what programs do) there is still room for malware to get through (a lot less room, but room none-the-less)...
Sure malware may get "through"; it's getting through now. Trustifier is not about filtering or patching;it is a kernel level behavior enforcer that is deterministic in setting execution privileges. There are a few ways that it prevents malware execution:
1) Security policies are ownership-centric using users, user-roles or groups and the language of trust relationships and data flows, to allow intuitive rule setting and reduce complexity. Note, that this is the language of business rules. This provides context for allow/deny decisions.
2) Persons, code, apps or devices can all be defined as users and easily ranked for secrecy or integrity.
3) Trustifier has special handling of root privileges, with the ability to give (or take away) partial root privileges when required and to set limits for their use. Thus an application may be given the right to execute a system call or network protocol only once, preventing embedded or rogue malware from executing in a second attempt. (This is also handy in protecting web servers-by allowing netbind a single time only)
4) Trustifier prevents privilege escalation.
5) Trustifier controls the release and flow of business data. If malware attempts to send home a payload that is say a trade secret from the R&D user group, Trustifier will not allow the release of that data to anyone who does not have privileges outside of that user group.
The thing to remember is that it is not necessary to protect everything in the enterprise, but one can start with the crown jewels and work down as necessary.
"Sure malware may get "through"; it's getting through now."
good of you to admit that... there is no panacea, malware will always find a way...
"Trustifier is not about filtering or patching;it is a kernel level behavior enforcer "
you may not realize it but you're contradicting yourself here... trustifier IS about filtering - it's about filtering behaviours...
and since it's looking at the kernel, things that are executed through other components can only be controlled by controlling the components that execute them (ie. indirect control), which is inherently coarse-grained...
You are right, and that has been a shortcoming of OS security in the past. We evaluate and govern the entire user space including system libraries, and monitor right into the application stack if so required.
Post a Comment