Prevx 3.0: delayed detection

Antivir, among others, dis not detect it either ...

But Geswall and Defencewall blocked it easily, of course.

 

Out of curiosity - did Geswall/Defensewall use signatures to block them or do they have some other technology in place?

 

Joe,
Thank you for your detailed and thorough response. This topic is extremely interesting and important to us, because your answer mirrors the Symantec response was when we presented them with our concerns. As I mentioned provately, we're using SEP as an endpoint protection and Symantec's stance on the topic is very close to yors: do not scan the file until it executes and minimize potential false positives as much as possible. While on paper it looks acceptable, in real life it plain doesn't work.
Now, I'm not saying PrevX doesn't work, but I would prefer my anti-virus/spyware program to alert me of a suspicious site, and scan file as it was being downloaded and then upon execution. I would also want it to alert me (at the minimum) if the file I just downloaded and executed has some characteristics of being a malware, like registry AutoRun access, service installation and startup, Explorer/shell integration, etc.
Maybe I'm old-fashioned, but I will take a false positive ANY DAY over an infection that bypassed signature and behavior-based detection. Am I alone in this?

P.S. My scope and requirements are for the enterprise, obviously for the home user different rules apply.

 

so surely symantec should have a webscanner to prevent the file ever getting on your HD?
as long as the file doesnt do any damage whats the harm?

 

We have a large number of Enterprise customers and they all, without an exception, have a completely different opinion than what you have been describing. Rather than trying to guess the behavior of a program before it executes (which in many cases is not technically feasible without massive amounts of overhead), Enterprises tend to block the installation of untrusted programs entirely.

If an Enterprise wants to be secure, they really should not allow their users to install arbitrary programs within the network and it should be made very obvious to their users what restrictions are in place, rather than using a solution which is going to show a warning popup on every bootup entry which is created that will not only confuse users but also massively increase support costs.

I suspect if you were to roll out a "conventional" behavior blocker which warns when system modifications are made, your job may be at risk We had this happen a while back in one of our previous products - an enterprise rolled out our product with the most advanced settings enabled (which is essentially what you are describing: show a warning if it creates a boot entry, modifies a system component, etc.) and he called us frantically because of the massive implications it had on the usability of the employee's systems and the fear it generated across the network when a simple software update was distributed.

From what I've seen, it is generally not a good idea to impede on the work being done in a large enterprise and security should be as silent and transparent as possible. While no security product is impenetrable, you need to weigh out the potential support nightmare with strong security.

Therefore, for an enterprise, I think that focusing on whitelisting/"Draconian" application control as well as an intelligent antimalware application is a more viable technology than trying to only block specific behaviors.

Just my $0.02

 

That is great! But I just checked and it is still not detected.

TH

EDIT: I did a deep scan and is now detected!

 

Joe,
Your approach is understandable and I agree to what you're saying, to some point. However, from my point of view, it's difficult to explain to an end-user (and my management) that despite having two anti-virus/spyware programs installed, blatantly rogue program got installed and active, and the only reason either product didn't detect it was because they didn't want to cause a potentially false-positive alarm, or while the the program in question is definitely unwanted, it is not malicious enough to be blocked upon execution.
What I'm saying is that there's another side of the coin, it's not as clear cut as it seems.

 

I suspect they didn't miss the file because they didn't want to cause a false positive - they probably missed it because it didn't really do anything malicious. Could you let me know what the "blatantly rogue program" was trying to do on the system?

Although a lot of malware does register itself to start on bootup, that is not a panacea either. Determining if a non-malicious program is unwanted after the user has installed it is not a trivial task and really the only way to accomplish it is to write signatures to block the malicious programs (and we have thousands of such signatures in place).

Therein lies the problem of what defines malicious. As you described, a program installing a shell extension/toolbar, loading on bootup, and detecting files as threats is really not enough physical evidence to block the program - there simply isn't a way to do it automatically. In this case, we would block any AV which packages a toolbar component

The line which separates some of the new rogue antimalware products from legitimate software is just the number of false positives produced. Other than that, everything else looks legitimate (and in many cases, the GUIs of the programs look better than some legitimate software )

It may be worth assessing exactly how your users are coming across these rogue products and blocking them at that level. Rogue products are only a subset of all of the threats and do need to be handled differently from the rest of malware (and virtually always require manual, human interaction to decide the determination).

 

Joe,
I totally agree and understand, and we are blocking malware on different levels, such as proxy, Web filtering, domain blacklisting and NIPS and firewall. But at the same time, our user base is extremely dynamic and a lot of people travel and work from home, where the endpoint itself is the only point we have control over.
Now, we're blocking a lot of stuff with SEP's application control, the really nasty stuff like hacking tools, password crackers, etc., using both filename and checksum options. However, our help desk is struggling with a lot of tickets about poor machine performance, where it's riddled with these "borderline" malicious rogue products. Now, from your (anti-virus/malware maker) point of view, they're not malicious enough to justifiy detection, leave alone alert and quarantine/removal. From my point of view, they exhibit all the characteristics of malware (registry, BHO, local rogue proxy install, HOSTS file modification, etc.) and I need to be able to detect and remove them before they get on the machine.
I understand the delicate balance between breaking end-user workflow with endless alerts and false-positives, but feel there's a protection drawback with all this.
I wonder, does PrevX has an ability control intensity/paranoia of the scan? A2 has "paranoid" mode that seems to be blocking (or at least alerting me) almost everything I can throw at it. Does PrevX has something similar that can be customized? I messed around with heuristics settings, but didn't seem to make any difference.

 

They are both policy-based sandboxes - ideal compliments for any AM.

 

The heuristic settings apply primarily to programs as they try to execute (but before any code is actually executed).

If you have specific samples which you think we should be detecting, feel free to email them to me at the address I PM'd you and I'll see why we're missing them.

 

It's not that I think PrevX is not detecting particular file or application, it's the behavior detection that is not working to the level I thought it would be.
Spycar is a good example in my book: something so blatantly and obviously malicious should be warned about, at the minimum, or blocked, if application is set to highest protection level. For the record, Symantec SEP -- which I hate with the passion and will knock on every chance I get -- detected every single one of Spycar's attempts. Now, they've done it with signatures and not behavior, and I understand your point about Spycar earlier in this thread, but I personally think that this behavior should be logged and/or blocked by ANY anti-virus/malware program on the market today.
Again, this my personal opinion.

 

A good example is what one System Administrator implemented:

http://isc.sans.org/diary.html?storyid=6529

A more draconian approach, where the entire systems are completely locked down:

http://www.faronics.com/whitepapers/CaseStudy_LAPD.pdf

There are various methods/software available to keep systems clean. It's just a matter of commitment on the part of company CEOs to instruct their support personnel to do it.

----
rich

 

Unfortunately, restricting user account is a lost battle with us. All users are local admins.
I know, I know..

 

Are these local admins regular employees or company officers?

----
rich

 

Regular company users.

 

You wrote earlier,

Actually, it's not difficult to explain to management, that as long as employees are able to install anything not specifically related to work, not authorized by Management, there will continue to be problems.

As I said above, until Management decides "enough is enough" you are fighting a losing battle, as you just wrote.

----
rich

 

This sounds to me more like you want a HIPS or restriction policies. Would an average user make the right decisions? I feel hopeless lost with HIPS-like alerts (even if I understand them). Is this particular action now legimit or not? How should I know? And even experienced users may have difficulties to recognize rogue software just by this alerts.

The decisions of Prevx 3.0 are made by an automated analysis - and it does it *much* better then I (or maybe your customers) ever could. I feel much safer with Prevx than with a HIPS - and I appriciate its silence.

 

On a company-owned computer, there should be no user decisions to make.

• All installed software should be job-related
  
  
• Any additional software a user requires should be submitted to Management for checking and approval, to be installed by Support personnel.

Under these conditions no unwanted programs or malware can intrude.

----
rich

 

You guys must be living in a perferct world! Unfortunately, it is what it is, and we have to deal with it.
My original post wasn't as much about standard security practices in the enterprise; instead I asked about behavioral detection with PrevX and why it didn't catch certain actions. I am curious how many of current PrevX users deployed it in the enterprise and what are the results?

 

@Joe
My prevx V2 set-up does this (blocks installs) as per rules I have used.
Isnt this the 'lost' function of V3 ??
Depending on hueristics has it's limits as noted ??
Isnt this also a 'hole' for the zero day ?

Of course there are other options as noted.

That actually sounds like admin failure in the roll out process ??

 

What's version 2? Is it different then v3?

 

Seriously, I don't have time to go through all that stuff, but that question would almost be considered an insult for some people I believe. I'm sure Joe will be more than happy to explain the hundred points - maybe he even has a book stored on his system somewhere that he can copy from.

 

V2 is not for sale anymore, V2 = Behaviour Blocker + In the Cloud Tech, V3 = Heuristics + Clouds

 

This is the functionality which we've automated in v3 - the number of user complaints and volume of confusion far outweighed the benefits. We've since offered free upgrades to existing Prevx 2 users and have had nearly 100% convert up to it with only a handful of people still use it just for the behavior blocker aspects.

There really is no way to explain behavior blocking to the average user who doesn't/shouldn't care about security. Rolling out a behavior blocker in an enterprise is going to cause users a flood of complaints and confusion. The reason why we don't catch certain actions is that certain actions aren't malicious by themselves. For instance, we don't flag Windows Explorer because it has the ability to delete files and format drives and we don't flag your email client because it sends out emails Detection of malware is the result of a complex harmony of rules and logic rather than detecting a single action as a threat.

It wasn't, he just deployed it in "Expert" mode which intentionally creates quite a lot of interaction with the user as it functions as a standard behavior blocker.

I'm not sure of the exact count but we've been focusing on enterprises with ~500-2000 employees and we're now going to be moving to larger enterprises with our new agreement with Unisys: http://www.scmagazineuk.com/Prevx-s...ent-with-IT-solutions-company/article/138350/