Home | Projects | Library | Blog

Posts Tagged ‘whitelisting’

custom malware and antivirus

Thursday, July 29th, 2010

In the Verizon DBIR report they have an interesting graph on page 26. It shows the percentage of malware infections that have been customized. (That is to say that the malware itself is customized). In 2005-2007 the percentage held steady between 21%-28%. In 2008 is jumped to 59% and in 2010 is it still high at 54%. Perhaps not surprisingly, even though only half of the malware is customized, that half is responsible for 97% of the stolen records. Presumably non-customized malware and all other methods are responsible for the remaining 3%. Why the huge discrepancy? It’s easy – antivirus. Non-customized malware gets detected, customized doesn’t. This just goes back to something many people have started to feel in the last few years – antivirus is inherently flawed, and we’re starting to see it’s flaws. Blacklisting is inherent a losing battle, because there will always be new bad things, and there will always be something you didn’t think of. Whitelisting may seem like a pain at first, but in the long run it’s almost always easier and more efective.

RAM Skimmers part II

Tuesday, December 15th, 2009

I was thinking some more about the RAM skimmers mentioned in the last post. I wasn’t really paying attention the first time I read the report, but I later noticed that Verizon mentions that the RAM scraper was found on a P.O.S.  (point of sale – the system a cashier will use to check out a customer in a store) system. A P.O.S. system would seem to be a system which could be very well defined in terms of what should be running on it, and would seem to be an ideal candidate for whitelisting software. Getting rid of the AV on P.O.S. systems and replacing them with whitelisting software which only allows specific applications to run would seem to be an ideal way to greatly increase the security of these systems, and make them future-proof against whatever the next generation of malware is.

more malware signatures needed than before

Thursday, June 26th, 2008

In the “duh” reporting on the moment, securityfocus reports that:

The number of signatures required to detect malicious code skyrocketed in the first half of 2008.

While I may mock them (gently of course) for reporting something which is obvious, the growth curve is impressive:

The data — part of the F-Secure’s IT Security Threat Summary — showed that the company currently requires nearly 900,000 different signatures, also referred to as “definitions” or “detections,” in its product to catch current threats, up from 500,000 signatures at the end of 2007.

The solution of course, is to stop writing signatures. There are a virtually infinite number of pieces of malware that can be written, and trying to write a signature for each and every one is an exercise in futility. We’ve seen it time and again – blacklisting does not work in the long run, it is not scalable, and is inherently reactive rather than proactive.

 
Pi is exactly 3!