HIPS Independent Testing?

Does anybody have a link to independent testing results on HIPS tools?

I'm thinking of a testing source such as AV-Comparatives for AV tools.

FWIW, I have used ThreatFire (TF) and now use OA 2 which has a HIPS feature in combo with it's FW.

We know that 2 real time AV's are not recommended, if the same rule true for HIPS what is the reason for that?

Can I have TF and OA 2 running properly at the same time?

This thread is not looking for "my HIPS is better than yours" posts.

FYI, here is a link to some data on HIPS :

http://wiki.castlecops.com/Lists_of_...avior_blockers

 

There are a series of hips tests here:
http://techsupportalert.com/security_HIPS.htm

and here for sandboxes:
http://techsupportalert.com/security_virtualization.htm

also look here:
http://www.av-comparatives.org/seiten/ergebnisse/HIPS-BB-SB.pdf

 

HIPS tests are in plans of AV-test for 2008, but, as I know, it will be almost impossible to get reviewed here for an "independent" tool.

 

Most recent test that i know of is this by nicM, Although it could be that it's not what you're looking for. Kareldjag had a website with individual tests, but i don't think it's updated, not sure.

 

HIPS usually hook the kernel. Too many HIPS cpould cause too many hooks. Too many hooks can cause instability, slow-down, & the heartbreak of psoriasis.

Yes. TF is a behavior blocker whereas OA more of a classic HIPS. TF doesn't hook the kernel much (if at all) -- hence it doesn't even need a restart when installed. Ergo, TF gets along fine with SSM, ProSec, & OA. Haven't tried it with Comodo's Defense+, however.

My HIPS is better than nothing. Shalom

 

Would you say this also holds true for the combo Mamutu and OA? Testing both together atm.

 

I can't answer your question regarding independent testing. If you find such a site, I hope they're more useful than the firewall tests that use the same old leaktests.

It's almost the same reason as with AVs. You'll have 2 apps trying to perform the same function, each wanting the "final say", but at a kernel level. In conventional terms, HIPS function by inserting themselves into the command paths via the hooks they set. The HIPS processes the intercepted commands according to the ruleset. They also detect other software that tries to set similar hooks, and block the activity unless you've permitted it. It doesn't matter if it's a system component, user software, another HIPS, or malware. It gets treated the same. When you have 2 HIPS, each will want to block the others hooks, which can lead to crashes and BSODs. They can interfere with each others ability to protect your system. The other issue is in each HIPS configuration. Does each let you allow hooks for just the other HIPS without allowing them globally? Both will want to hook the same command paths, and you won't be able to say which loads first. If they're well coded, both will try to load first.

Unless each HIPS performs some function that the other cannot be configured to do, there's very little to be gained with 2 HIPS. Even if they do get along and are configured to accomodate each other, all bets are off when one of them gets updated. If that update process is done automatically, you could wake up one day and find your PC hopelessly locked up because the updated version sets some new hooks that weren't allowed by the other or the digital signature changes and the other HIPS no longer recognizes it. Remember when AntiVir added that rootkit module to their AV? The initial install was OK, but when it updated, it conflicted with SSM.

In several threads here, HIPS was said to use "malware methods" to protect the system. It would have been more accurate to say that both use the same methods (the hooks). With 2 HIPS, each has to allow hooks by the other. If auto-updating is allowed, each must allow the others signature and possibly its behavior to change (new features). Those 2 put together opens the door for the possibility, albeit remote, of one being exploited and the other allowing it. Then again, the more popular they get, the more they'll be targeted.

IMO, a user is far better off spending the time learning to configure one HIPS well than spending it trying to make 2 get along and work together. One HIPS, tightly configured will stop most anything provided the user doesn't allow it. HIPS will seldom fail but the user will. Running 2 doesn't fix that problem. It just makes the user allow it twice.

Rick

 

Thanks! The 1st and 3rd references are a bit over 12 months ago, but I'm very glad to have them!

Maybe they will update their reviews in 2008

 

Hi Rick:

Ty! Another great post!

I have limited myself to 1 HIPS.

Is it possible to have a HIPS that doesn't operate at a kernel level?

Is the term behavior blocker meaningful in your view?

 

Also Comparative Features Table (HIPS - Behavior blockers)
http://wiki.castlecops.com/HIPS/IDP_programs/services
Didn't see it listed above

 

I have no experience with Beeg Mamu. Ugly name. Me no likee.

 

Ty! a great post! Your HIPS is better than nil

I have limited myself to 1 HIPS.

I'm wondering if is possible to have a HIPS that doesn't operate at a kernel level?

The terms term behavior blocker function /HIPS seem to be interchangeable?

 

TY, I have read part of this (it's deep!) so I've bookmarked the link.

Looks like recommended reading for me!

 

That would depend on how you define HIPS. It's entirely possible to prevent user applications from being launched from a higher level. The old windows 98 policy editor would do that. Without hooking at a kernel level, HIPS could be easily defeated by anything running at a kernel level, which would include rootkits. A HIPS that didn't run at a kernel level would work for user control but wouldn't be very effective against malware.

On the Mamatu link earlier in the post, they had this on their site:
Monitors live all active programs for dangerous behavior (Behavior Blocking).
If DSA qualifies as a behavior blocker, I've just started looking at it on my 2K box. If it's not, I haven't tried any of them. Blocking malicious behavior is a nice concept, but I question how possible that really is. So many single behaviors can be both malicious and useful, deleting or modifying a file, starting or killing a process, setting a hook. More often than not, it's a string of behaviors that would point to a malicious intent. Other than catching commonly used behavior combinations, calls to critical system processes, etc, I'd question just how effective it can really be. I'm probably the wrong person to ask as I'm not comfortable with the idea of software being able to determine what is and isn't malicious. It's too much like heuristic detection for my liking.
Rick

 

"Behavior Blocker" is a subset of HIPS. "Classical HIPS" is another subset of HIPS. These titles are not rigorous -- they have been coined & generally accepted by various users. They aren't well defined. What I call a "classical" might not be considered as such by someone else. (Of course, my opinion is the correct one because... well, just because I get reeeelly upset if people disagree with me.)

By my definitions...

A) A classical HIPS enables detailed management of many process/file actions, and asks the user "what should I do" whenever it encounters just about anything new or unexpected. Examples of questions that might confront a classic's user:

*Can process A (parent) execute Process B (child)? If so, under what circumstances or for what reasons?

*Should I protect process C from termination?

*Should I allow process D to access the internet, & for what purposes?

*Under what conditions (if any) should process G be allowed to monitor keyboard inputs?

*Should I protect such-and-such file from termination? From being read? From being changed? (Tell me, tell me do)

*Process x is trying to hook the kernel. Is that okay?

*Uh-oh, here's a process trying to execute -- it's one that you have never executed before. Okay to execute or not?

And on-and-on-and-on.

B) A behavior blocker tends to be more *intelligent* than a classical. It uses internal logic-tests so as to identify high risk behavior on its own, & thereby reduce the need for user intervention. It asks fewer questions (fewer pop-ups). It allows a narrower range of configurations.

C) Generalizations (bound to produce controversy)

1) The effectiveness of a classic is 50% dependent on the skill of the programmer, & 50% dependent on the skill of the user. The effectiveness of a behavior blocker is 90% dependent on programmer skill, & 10% dependent on user skill.

2) A classic appeals to a paranoid tweak-freak (like me). A behavior blocker is a security app for use by people who actually have lives beyond fiddling with their computer & visiting Wilders.

3) In the hands of a skilled &/or determined user, a classic offers better protection than a behavior blocker.

4) Threatfire is an example of a special case. TF is a behavior blocker par excellence, but its option to use custom rules enables it to move deeply into classical territory IF the user so desires.

5) OA is yet another example of a special case. OA comes out of the box as a fairly simplistic, fairly powerful HIPS. Beyond that, OA offers optional advanced rule-setting capability for even GREATER protective power.

6) These ***2-way*** HIPS like TF & OA are possibly the wave of the future, whereas Comodo's incredibly convoluted Defense+ is truly a "classic" -- in the sense that its design concepts (like a lady's girdle) are veddy veddy old-fashioned & quite uncomfortable to have on.

 

Nice description. Fits quite well.

That's almost enough to make me try it out, if I didn't have so many other projects going.
Rick

 

Nice post, easy explained

My issue with these Behavior Blockers is that I don't actually know what they do or don't do. In other words, what they are capable of. The sales pitch on their sites is often to shallow imho.

 

About the future of HIPS, as Bellgamin said, my guess would be:
The integration of HIPS functionality into:

A) Firewalls e.g. Comodo (Defense+), ZoneAlarm (OSFirewall), OnlineArmor and Outpost 2008 (Host Protection)

B) Antispyware e.g. Tenebril Spycatcher (Deep Defense), Spyware Terminator (HIPS)

C) Antivirus e.g. Kaspersky AV (Proactive Defense)

D) Other Security Software such as the Norton 360 Suite.

This will result in too much overlap with other security software and make a stand alone HIPS not feasible for the average user. This will result in a reduce in demand for HIPS software and a slow decrease in their numbers due to the very narrow market they appeal to.

So in a couple of years HIPS will be a normal part of your firewall etc and no one will consider having a standalone HIPS application!

 

Yes, this forecast could be right! Time will tell.

For me right now I have a FW which is already integrated with a HIPS.

A feature I have which is handy, is I can uninstall the FW and or the HIPS components at will. So I could turn off OA HIPS and activate TreatFire if I wanted to. May do that anyway as an experiment. It's scan may raise different flags I can then control via OA. ( I must be crazy to try these things )

 

Right But behav. blockers/analyzers aren't restricted by time/resources (like heuristics built into scanning engines), so they can have really complex rulesets and very high detection rates.

 

They work good together. OA takes over the TF handles. Only down side is that TF is less intelligent concerning multiple (build in) rules.

You could do the following, when you do not like the overlap idea
- download WinPooch, search for the WinPooch A2 filter in this forum (I uploaded for registry and file protection)
- uninstall TF
- run the internet facing aps (like LimeWire, e-mail and internet) in safer mode of AO

When you are happy with it, do not change

Regards Kees

 

Sorry Kees1958:

I know zip on Winpooch A2. I'm worried that I may take the thread (my own) OT but I would like to have you tell me (PM?) what it is and what I would achieve if I did follow your advice in your post?

 

The Pooch is nice in its present stage, but it won't progress beyond that stage -- it is *abandonedware*, sad to say. Thus, as the new wave of malware progresses, the Pooch will gradually.. um... go to the dogs.

 

Well to be honest I think the same problem exists for "classic hips" (but perhaps to a lesser degree maybe). It seems when we say we know what classic hips do, it really means "we know it will prompt when we run a known test".

 

The sales pitch is a big part of the problem for typical users. So many advertize their products as "All you'll ever need" when they don't come close. I'm also not convinced that a behavior blockers definition of malicious or unwanted behavior would match my own when it comes to activities such as auto-updating, calling home, nag screens, etc. Too many bad memories of adware removers presuming to tell me what is and isn't acceptable behavior. With classic HIPS, it's all the users choice.
Rick