A while back, Greg Young blogged on the variety of security threat meters out there. Most of those are based on the known vulnerabilities out there and the attacks being blocked by AV clients and intrusion prevention systems. But the real danger level is related to what isn’t getting blocked. Counting the raindrops your roof repels is less important than finding leaks.
That’s why I like one particular part of Microsoft’s Security Intelligence Report. You have to get past the front section that spends a lot of time showing how the total number of vulnerabilities in the world are mostly in applications not operating systems, which isn’t surprising since there are a lot more applications than there are operating systems… A bit after that, they show some interesting data from Microsoft’s Malicious Software Removal Tool.
Since MSRT runs on many millions of PCs as part of the auto-update process, it provides a broad look at what malware is being found on PCs. The MSRT stats represent malware being removed - ie, it got on the PC and was doing its thing until removed. That represents real risk, and is a much more important indicator to watch than what malware is being blocked.
If you look at the latest chart, you see that viruses and spyware are slightly declining. Remember, this does not mean there are fewer viruses and spyware, it means that anti-viral and anti-spyware programs are pretty effective at blocking these well understood threats.
But look at the top two lines – Trojans and Potentially Unwanted Software. More than 50% of the PCs out there have these on them – desktop programs are not effective at stopping these. Throw in the password stealers and monitoring tools, and you have a lot of PCs that are dangerously compromised – this shows how frequently botnets and the like are getting past endpoint protection platforms.
Now, the MSRT stats represent a lot of consumer machines, many of which may not have up to date signatures or even have AV installed – but the fact that viruses and spyware counts are low means that probably isn’t a significant factor. But, even so – I bet your employees are accessing business systems from home PCs pretty often. PC security has a long way to go.
Category: Uncategorized Tags:

John Pescatore





































































































9 responses so far ↓
1 Ilya Rabinovich November 7, 2008 at 7:43 am
Hi John!
Things are even worser- MSRT can’t visualize LdPinch-like malware as, right after passwords hijacking, most cases, they remove itself from a hard drive.
2 John Pescatore November 7, 2008 at 8:51 am
Yes, good point – that type of “smash and grab” malware makes the disk scrubbing approach harder to depend on. It always tends to come back to using software on top of software to protect software always has its limits – If i were to look at the logs of network devices, I should be able to find when LdPinch came in and where it went. If the PCs are outside the perimeter, we will need security as a service proxy type offerings to have that capability.
3 Ilya Rabinovich November 7, 2008 at 9:57 am
Well, it’s reactive again, the main protection against such a software is local resource association and separation.
4 Rob Lewis November 7, 2008 at 11:34 am
The next step would have to be trusted (MAC/MLS) systems to provide a least privilege, default-deny environment that would prevent malware that slipped by filters from executing, whether they were removed or not.
5 Ilya Rabinovich November 7, 2008 at 11:47 am
Hi Rob!
>to provide a least privilege default-deny environment
You mean sandboxing? Yes, it’s obviously the next step ahaid, sandboxing is highly effective against any kind of malware. Unfortunately, AV people are very inert with their “detection” approach.
6 Rob Lewis November 7, 2008 at 1:15 pm
Hey Ilya,
Sandboxing, or compartmentalization is also a defense, but may us really a containment strategy. I was thinking more of a kernel level behavior enforcer that prevented anonomous funtional execution using whitelisting technology at the service call level.
7 Rob Lewis November 7, 2008 at 1:17 pm
Sorry, got distracted and did not notice the typo. Should say:
Sandboxing, or compartmentalization is also a defense, but as a containment strategy. I was thinking more of a kernel level behavior enforcer that prevented anonomous funtional execution using whitelisting technology at the service call level.
8 Ilya Rabinovich November 7, 2008 at 1:53 pm
Ah, you mean a tool something like Anti-Executable or Bit9 Parity? Well, whitelisting is good, but as a helping solution. As a standalone defense, it’s too frustrating for end-users/SOHO and increase IT department resources usage for Enterprise.
9 Rob Lewis November 7, 2008 at 2:50 pm
The concepts of trusted computing (aka orange book standards) are sound, the previous implementations were poor, mostly due to huge administrative overhead due to massive labelling and rule creation.
Through an innovative new implementation, we have removed the frustrating barriers and made this grade of security cost effective and manageable. One of our first customers converted their environment into a scalable multi-level secure shop run by in-house IT staff without previous specialized security skills or training. It actually freed up time for them. The way we do it is to use the language of the business rules for the security policies, using an intuitive framework that even non-technical managers can understand, and the labelling is performed automatically and implicitly, based on relative trust relationships within, and between, user groups.
Going back to my original post, I was simply trying to make the point that this is the level of protection that is required to protect against previously unseen attacks.
Leave a Comment