Threatfire's near-fatal flaw

[bellgamin]

TF's custom rules are an excellent capability EXCEPT that the only allowed actions are "Allow" & "Quarantine." There is no option to simply "Deny" a given action by an otherwise safe process.

If a process is quarantined, it ceases to function. Thus, the mere act of trying to block an outgoing connection by (for example) explorer.exe will cause explorer.exe to be quarantined, thereby causing bad things to happen.

Thus, a "safe process" cannot be limited as to its actions. Any & all actions must be allowed BECAUSE the only other option is "Quarantine" -- which will "break" the process.

It's an absurd limitation for an otherwise superb security app. Oddly enough, TF's proponents have long been aware of this fault, but user complaints have not yet resulted in a fix being made.

I am posting this issue here at Wilders with the positive goal of perhaps motivating TF's programmers to give timely attention to this issue.

[trjam]

that one issue is what keeps me from buying it.

[AKAJohnDoe]

That, and I simply don't see any advantage to running it.

[solcroft]

I agree.

The lack of a Deny function makes the Advanced Rules feature virtually useless.

However, some of you may also know what I think about the necessity for Advanced Rules, and that's that...

[aigle]

Let me say it might be because the company behind id PC Tools now( not Novatix).

[Diver]

Describing this "feature" as near fatal is a gross overstatement. Threatfire's real value is as a set it and forget it behavior detection system. You don't have to be an expert to use it. Not everyone wants to spend their time tinkering with security software.

[trjam]

It would be nice to hear from Cyberhawk Support as to if this is a possibility for the future.;)

[Espresso]

http://www.wilderssecurity.com/showpost.php?p=1061692&postcount=33

-{ Quote: "--------------------------------------------------------------------------------

Hi Espresso--

Currently the only choices when ThreatFire enforces a Custom Rule you have created is Allow or Quarantine.

However, you'll notice that the Threat Control Center still includes a "Denied" bin. This bin is actually not used for anything in this release, but the plan for a future update (v. 3.1) would be to modify the alert dialogs for Custom Rules to show the choice of Allow or Deny, rather than Allow or Quarantine. You would also have the opportunity to check the "Remember this answer" box to always allow or always deny that action. In many cases for custom rules it just makes more sense to only "Deny" the action rather than "Quarantine" it.

In most other cases with the ThreatFire alerts (all non-custom rule alerts), Allow or Quarantine should suffice.

Kind regards,

Becky Dubrow
__________________
PC Tools ThreatFire Team
5777 Central Ave., Ste. 130
Boulder, CO 80301
USA
http://www.threatfire.com
http://www.pctools.com " }-

[Cyberhawk Support]

baited ;-)

It is on the wish list.

Processes like explorer.exe will not get quarantined. It will get killed, but like ie, and other system critical processes will not get quarantined. It must be noted, that the "Deny" feature would also stop explorer.exe much the same way the quarantine is doing now. So explorer will get killed in the scenario that a custom rule makes it pop an alert, but get restarted by the system.

Making a Custom Rule assumes that you know what your are targeting. If a process pops an alert that you know and trust, it should be "always" allowed, and "teach" ThreatFire what to ignore.
Saying this, I too would like the Deny feature back, not just for Custom Rules.

Happy New year to you all!
djames

[trjam]

thank you. You are off the "hook" now.;)

[Espresso]

Why not have an option to deny an action, but not shut down the app entirely?

[Cyberhawk Support]

The idea is being thrown around here. How to implement it alongside other/new features.
Also one must take into consideration the target audience for this. Stopping malware from one action might lead to many other pop ups, this is confusing to some, and can lead to lazy clicking (just clicking ok).
The action of stopping the process's event will probably lead to the app being killed anyway, but still might be handy.

[Diver]

-{ Quote: "The idea is being thrown around here. How to implement it alongside other/new features.
Also one must take into consideration the target audience for this. Stopping malware from one action might lead to many other pop ups, this is confusing to some, and can lead to lazy clicking (just clicking ok).
The action of stopping the process's event will probably lead to the app being killed anyway, but still might be handy." }-

The "lazy clicking" concept is unfortunately something a lot of folks around here ignore when choosing their security software. Of course we also have a contingent here that think false positives are proof of a great AV.

[Kerodo]

-{ Quote: "The idea is being thrown around here. How to implement it alongside other/new features.
Also one must take into consideration the target audience for this. Stopping malware from one action might lead to many other pop ups, this is confusing to some, and can lead to lazy clicking (just clicking ok).
The action of stopping the process's event will probably lead to the app being killed anyway, but still might be handy." }-
Whatever is done in the future, please make it configurable with options. For me, one of the best selling points of TF is that it doesn't bother me at all.. Hopefully it will stay that way.....

[bellgamin]

-{ Quote: "It must be noted, that the "Deny" feature would also stop explorer.exe much the same way the quarantine is doing now." }-System Safety Monitor & Prosecurity can be set to block a process (including explorer.exe) from connecting out, but without causing that process (including explorer.exe) to otherwise cease functioning. Why not TF?

[solcroft]

-{ Quote: "For me, one of the best selling points of TF is that it doesn't bother me at all.. Hopefully it will stay that way....." }-
Seconded.

I have no need for Advanced Rules, and I like TF the way exactly it is. In particular, please do not remove the ability to instantly terminate any offending processes right from the alert window.

[aigle]

-{ Quote: "Seconded.

I have no need for Advanced Rules, and I like TF the way exactly it is. In particular, please do not remove the ability to instantly terminate any offending processes right from the alert window." }-
I agree as well. TF must be a bit different from classical HIPS>

[aigle]

-{ Quote: "The idea is being thrown around here. How to implement it alongside other/new features.
Also one must take into consideration the target audience for this. Stopping malware from one action might lead to many other pop ups, this is confusing to some, and can lead to lazy clicking (just clicking ok).
The action of stopping the process's event will probably lead to the app being killed anyway, but still might be handy." }-
I totally agree with this.

We should keep in mind that TF is basically a HIPS for nivice so don,t expect it to behave exacttly same as a classical HIPS.
To me default rules/ working of TF are much more important than advanced rules.

[Fuzzfas]

-{ Quote: "
To me default rules/ working of TF are much more important than advanced rules." }-

Exactly. Threatfire is made for a broader audience, not just for Wilders' HIPS addicts. I tried to make some friends use HIPS many times, i failed because they couldn't understand the pop ups. Threatfire is the answer for such audience.

My only wish for Threatfire is to make it possible to disable the NET MODULE. Without it, it runs MUCH lighter.

[Kees1958]

Hi,

I agree with Bellgamin. I want to bring acrross two points:

(addtional) Custom rules for protection areas which should be static, won't generate pop-ups

Other posters claim that custom rules will always create extra pop-ups, this is not true. I for instance am dragging along a registry and file protection set, which I developed using SSM, later on EQSecure. I also ported them to WinPooch, ThreatFire and Comodo V3 with D+ enabled. On Comodo this meant a few extra entries and the trimming down of a lot of others. D+ actually got quiet.

Custom rules and protection level slider need to be aligned for usage
When you look at TF they have included a security level slider. This to facilitate users who are more into classical intrusion detection (setting protection level to 4 or 5). The point is when you facilitate this usage (let the user decide), you should also allow a deny functionality for custom rules to tweak the protection yourself.

Regards Kees

[solcroft]

I say abolish Advanced Rules altogether. Those who want that feature can use a program that actually caters for that purpose. Problem solved. -.-

[Perman]

Hi, folks:

Facing such pressures from both sides; pro-advanced, pro-basic folks.

IMO,TF has arrived at a crossroad.

Forgetting that Pro version, smart people would not touch it for mere AV scanner addition (they could use PCTools AV, free and freely) and $$$ extra ( I have called it a marketing blunder, right from the day one, and its marketing gurus had a very different views).

If PCTools has a same vision and mission as Comodo does, then it should, at least in my view to make this long-waited, finally polished gem to be as simple and user-friendly as possible. Adding complexity to TF of present form is a suicidal mistake, unless it wishes to please those advanced players, then again, there are tons of others (HIPS) at their disposal at this moment. TF with those extra features is just another me-too copy.

Take care.

[LUSHER]

-{ Quote: "The "lazy clicking" concept is unfortunately something a lot of folks around here ignore when choosing their security software. Of course we also have a contingent here that think false positives are proof of a great AV." }-

That's why we like HIPS, after all there is no such thing as a "false positive" in a HIPS.

In fact, for HIPS the aim is to generate as much prompts as possible, generating prompts for actions that are harmless in 99.9999% of cases are the proof of a great HIPS.

[solcroft]

-{ Quote: "Hi, folks:

Facing such pressures from both sides; pro-advanced, pro-basic folks.

IMO,TF has arrived at a crossroad.

Forgetting that Pro version, smart people would not touch it for mere AV scanner addition (they could use PCTools AV, free and freely) and $$$ extra ( I have called it a marketing blunder, right from the day one, and its marketing gurus had a very different views).

If PCTools has a same vision and mission as Comodo does, then it should, at least in my view to make this long-waited, finally polished gem to be as simple and user-friendly as possible. Adding complexity to TF of present form is a suicidal mistake, unless it wishes to please those advanced players, then again, there are tons of others (HIPS) at their disposal at this moment. TF with those extra features is just another me-too copy.

Take care." }-
So sad, yet so true.

Personally I wonder how they can afford to give out this great app for free. Something tells me it won't be forever.

[Kees1958]

-{ Quote: "I say abolish Advanced Rules altogether. Those who want that feature can use a program that actually caters for that purpose. Problem solved. -.-" }-

Point I am making is that they should also get rid of the sensitivity level (erroniously called protection level), to facilitate more conventional HIPS users. So it is either way.

Mamuto although less strong in self protection has a more straight forward approach. No custom rules, but exceptions managed on application level. Mamuto works like TF on level 4. It is a clear setup.

[Kees1958]

-{ Quote: "That's why we like HIPS, after all there is no such thing as a "false positive" in a HIPS.." }-

That is the problem with TF's custom rules. The lack of a deny option is the equivalent of a FP. Choose Quarantaine when IEframe gets hooked, and you are really hooked with TF. So they must choose a market positioning for TF, being either a "no configuration needed behavior blocker" or a swiss army knife boasted with intelligence and traditional HIPS features.

[solcroft]

-{ Quote: "Point I am making is that they should also get rid of the sensitivity level (erroniously called protection level), to facilitate more conventional HIPS users. So it is either way." }-
I'd agree. I haven't touched it it all, except for some testing purposes. Setting it any lower reduces the protection capabilities, any higher and it loses its design purpose of an intelligent behavior blocker.

-{ Quote: "Mamuto although less strong in self protection has a more straight forward approach. No custom rules, but exceptions managed on application level. Mamuto works like TF on level 4. It is a clear setup." }-
How's Mamutu lately. I haven't been keeping up with it all that much thanks to a whole load of FPs when I last tried it. If it really does behave like TF level 4, I'd say a2 has yet to fix this issue...

[Kees1958]

-{ Quote: "How's Mamutu lately. I haven't been keeping up with it all that much thanks to a whole load of FPs when I last tried it. If it really does behave like TF level 4, I'd say a2 has yet to fix this issue..." }-

Deselect the protect Internet Explorer settings option when deselecting the Intelligent False Positive Reduction. This brings Mamuto on Par with TF on level 4. TF Level 3 lets the TrojDemo pass, TF on level 4 not. In terms of CPU cycles needed the TF developers can learn something of the Mamuto guys.

This may be exemplary: Internet for 1 hour browsing Wilders forum:
- TF Service used 18 seconds CPU time
- same with Mamuto used only 1 second!

K

[solcroft]

-{ Quote: "Deselect the protect Internet Explorer settings option when deselecting the Intelligent False Positive Reduction. This brings Mamuto on Par with TF on level 4." }-
Is there a way to configure Mamutu so that it behaves equivalently to TF level 3?

Level 4 is still a mishmash of FPs, a.k.a. no good.

Thanks.

[Kees1958]

Sorry may be this is more clear

Protection level strength of TF on 4 with FP on Level 3: For the protection you need to deselect the Intellgent FP reduction of Mamuto, to reduce FP to Level 3 of TF, you need to deleselect the protect internet explorer settings in the IDS of Mamuto.

[solcroft]

-{ Quote: "Sorry may be this is more clear

Protection level strength of TF on 4 with FP on Level 3: For the protection you need to deselect the Intellgent FP reduction of Mamuto, to reduce FP to Level 3 of TF, you need to deleselect the protect internet explorer settings in the IDS of Mamuto." }-
Wouldn't that just eliminate the FPs (and protection!!! :o) for IE alone, while retaining the FPs for other programs?

[Fuzzfas]

-{ Quote: " In terms of CPU cycles needed the TF developers can learn something of the Mamuto guys.

This may be exemplary: Internet for 1 hour browsing Wilders forum:
- TF Service used 18 seconds CPU time
- same with Mamuto used only 1 second!

K" }-

That's why i ve been asking for months for the ability to deactivate TF's Net Module. :blink:

[mswannie]

-{ Quote: "I say abolish Advanced Rules altogether. Those who want that feature can use a program that actually caters for that purpose. Problem solved. -.-" }-

Agree 100%. Haven't touched them (Advanced Rules) and probably never will. TF works great as is.

[HAN]

Interesting reading throughout this entire thread!

My opinion is that while it would be nice to have a Deny option for Advanced Rule creation, I would NOT like to see TF turned into a more mainstream HIPS.

I've been running TF for a few weeks as a test to replace BOClean (which I feel may have outlived it's usefulness. Not to mention the somewhat painful FPs it has about every 2 months or so.) So far I've been pleased. With the exceptions of when I purposely tried to trigger an alarm, TF has been blissfully silent. With the knowledge that I am looking for something that can (with minimal help from me) be ran by users who have NO clue about PC security, the current version of TF seems to be what I've been looking for. (It even runs under a Limited User account!)

I understand that no one product can be all things to all users. IMO, the current version of TF fills an important role... as is.

[Cerxes]

-{ Quote: "...something that can (with minimal help from me) be ran by users who have NO clue about PC security, the current version of TF seems to be what I've been looking for..." }-
I´m uncertain if TF will suite novices since you have to do a choice: allow/quarantine (+ remember).

/C.

[HAN]

-{ Quote: "I´m uncertain if TF will suite novices since you have to do a choice: allow/quarantine (+ remember).
/C." }-

Your point is well taken. That's where the "help from me" comes in. They are to check with me on alerts. (Surprisingly, they do quite well in this regard. Typically, I only have a couple of "rogues" I have to deal with.) In this regard, my feelings are that I'll have it easier than when I had to deal with a BOC FP, which affected everyone...

[solcroft]

-{ Quote: "I´m uncertain if TF will suite novices since you have to do a choice: allow/quarantine (+ remember).

/C." }-
By that extension, any antivirus product that prompts the user whenever it detects a virus is also unsuitable for novices.

Perhaps we should let novices run naked with no security at all. ???

[EASTER]

-{ Quote: "That's why we like HIPS, after all there is no such thing as a "false positive" in a HIPS.

In fact, for HIPS the aim is to generate as much prompts as possible, generating prompts for actions that are harmless in 99.9999% of cases are the proof of a great HIPS." }-

I side wholeheartily with LUSHER on this, HIPS when well coded covers "signals","commands", originating from a source file, and passes that important data to the user at the screen FIRST!

That makes all the difference in the world. I just don't subscribe, in all honesty, to lazy manners that HIPS are too complicated and make too much noise, thats nothing but pure irresponsibility if you care enough to learn at least a little of what is going on behind your back in the system.

For those users, theres AV's, resident AS's, and Prevx + ThreatFire apps that they have to GAMBLE on their results. Not to take anything at all away from their useful purpose, but their percentages are not even close to the level of a true, user interactive HIPS in my opinion. It either is or isn't, theres no middle ground for FP's or blind trust in True HIPS, and why i take great stock in their development, because there are no comparisons in the real results of best protections. Plus no conflicts, issues, or unexpected surprises like we read about all the time with these other apps.

After you taKe the patience and forethought to fine-tune = LEARN to make rules, you've jumped eons ahead of old technology and better secured both your conscience & data from forced mistreatment.

[solcroft]

EASTER, you never fail to crack me up.

[EASTER]

-{ Quote: "EASTER, you never fail to crack me up." }-

I'll save another one just for your amusement as soon as you can latch on on and share the latest EQSecure HIPS, provided they have another one waiting in the wings. LoL

[solcroft]

-{ Quote: "I'll save another one just for your amusement as soon as you can latch on on and share the latest EQSecure HIPS, provided they have another one waiting in the wings. LoL" }-
Skinning functions have been added. Users will be able to design and submit their own custom skins for EQSecure. By default EQSecure will come with 3 skins: WinXP, MacOS and Vista.

And oh, OLE and interprocess messages control are expected to be included in the next release.

[EASTER]

-{ Quote: "Skinning functions have been added. Users will be able to design and submit their own custom skins for EQSecure. By default EQSecure will come with 3 skins: WinXP, MacOS and Vista.

And oh, OLE and interprocess messages control are expected to be included in the next release." }-

Thanks for that heads up what to expect. I'm completely sold on EQS, in spite of Online Armor + SSM no matter their own useful improvements. I've taken an uncanny loyalty to EQS bar none for many reasons but most of all because it's a proven performer for me.

[Rasheed187]

On topic: it´s perhaps not a flaw, but absence of the deny option makes TF useless to me.

-{ Quote: "Deselect the protect Internet Explorer settings option when deselecting the Intelligent False Positive Reduction. This brings Mamuto on Par with TF on level 4. TF Level 3 lets the TrojDemo pass, TF on level 4 not. In terms of CPU cycles needed the TF developers can learn something of the Mamuto guys. " }-

You know, I don´t get it, so now we have this "Levels" feature, where you will be warned about stuff only when in a certain level, shouldn´t HIPS always warn you when it thinks something fishy is going on? @ Kees1958, it´s Mamutu not Mamuto, yeah there was some discussion going on about the name, but I kind of like it. And I´m sure it´s the number one selling tool on the African markets. ;D

[Cerxes]

As a reply to solcroft's earlier post #37:

The source:
-{ Quote: "...something that can (with minimal help from me) be ran by users who have NO clue about PC security, the current version of TF seems to be what I've been looking for..." }-

My reply:
-{ Quote: "I´m uncertain if TF will suite novices since you have to do a choice: allow/quarantine (+ remember)." }-

solcroft's reply:
-{ Quote: "By that extension, any antivirus product that prompts the user whenever it detects a virus is also unsuitable for novices. Perhaps we should let novices run naked with no security at all." }-
My reply to HAN was based on two things: security applications that prompts you for an answer and the knowledge of skill of the target group. In my reply I´m not claiming that we should let novices "run naked with no security at all", I´m more questioning the suitability of using that category of applications that force novices to make a decision, where they in most cases don´t know which alternative to choose.

What kind of users then do this group of "novices" consist of? I would like to simply classify them as:

-{ Quote: "1. Novices that have no clue about PC security, but are willing to learn.

2. Novices that have no clue about PC security, and are not either interested or willing to learn." }-
My assumption was that the target group HAN mentioned belonged to category 2.

Then one may ask what are the alternatives of security applications for novices belonging to category 2?

If they are lucky enough to have someone that can help them with the preconfiguration and installation, then IMO using the inbuilt/free tools of Windows as for example LUA, SRP, FW, DEP, SteadyState and other way of harden the system would be a convenient way for this group of users. The alternatives of third part security applications would be Returnil, ShadowUser, Anti-Executable etc.

The deny-by-default approach is what I therefore refer to as a suitable way for novices belonging to category 2 for avoiding the necessity to choose when prompted.

-{ Quote: "By that extension, any antivirus product that prompts the user whenever it detects a virus is also unsuitable for novices..." }-
Thankfully enough there´s a setting among most AV's (I think), that doesn´t prompts the user about an eventual detection. It simply automatically carry outs what you have preconfigured it to do.

For example, my parents definitely belongs to group 2, and the only way in how they use their computer is to check their mail and browsing after news, the weather etc. They are not interested in getting prompts that they do not know how to answer. So accordingly to their skill and habits, I´ve harden their system and also added Anti-Executable and Avast Home where I´ve checked the silent setting, deny-by-default.

Sorry for this long-winded answer.

/C.

[Cerxes]

-{ Quote: "...shouldn´t HIPS always warn you when it thinks something fishy is going on?..." }-
It depends if you have enabled/disabled the specific monitoring features in the application. I havn´t yet tested Mephisto but I look forward to compare it with TF.

/C.

[EASTER]

Malware/Rootkit and even proof-of-concept developers tap into undocumented grounds of windows O/S, and so IMO, HIPS developers are equal to their tasks & ideas.

The more a true HIPS code specialist maps, the less chance for surprise compromise that those malware authors have to work with, and that spells more wasted time & effort for them, not us. Only complete results/confidence on our end and happily, only disappointment for them. A noble goal.

EASTER

[Wordward]

Here's a reply from djames in the PC Tools Threatfire Forum to my question about Quarantine. It should give some TF users more confidence in using it. http://www.pctools.com/forum/showthread.php?t=50121

[solcroft]

Cerxes,

In effect the solutions you suggest are an improvement over TF only in the sense that the answer is always "no". Regardless of whether it's the correct answer or not, that's what you're going to get every time.

I don't see how this is necessarily better, for newbies and/or otherwise. In fact, it's worse. Benign programs will fail with no indication or error messages whatsoever. In contrast, TF provides a clear explanation that whatever is causing the popup is likely to be dangerous, and should be blocked unless the user is absolutely certain.

I'm not saying LUA, SRP etc is ineffective or a bad idea. Far from it. However, saying that a solution that says "no" to everything is better than a solution that allows benign behavior and notifies one only on malware-like behavior is not necessarily true.

[SMPRICESOLUTIONS]

-{ Quote: "I´m uncertain if TF will suite novices since you have to do a choice: allow/quarantine (+ remember).

/C." }-

This is the exact seem reason why I like Prevx running In ABC mode. The application/process is either good, bad or unknown. If it is bad, Prevx quarantines the application/process so the it can no longer harm the system and gives you the option to clean up the infection right a way or later. if is unknown, then Prevx watches it like a hawk and if it determines what it is doing is bad and locks it down. Don't get me wrong threatfire is a great appliction but in my mind it is not suited well for novice computer users.

[EASTER]

-{ Quote: "Don't get me wrong threatfire is a great appliction but in my mind it is not suited well for novice computer users." }-

For that matter neither is a HIPS. They require some fine tuning to settings for maximum coverage + protection.

You make a very valid point, i just finished cleaning some client computers (i'm freelance btw), they offer me money but i suggest computer components in return when possible if available because i pride myself on restoring many such items to a working condition again as backup components i keep when they might be needed.

Thr majority of users, specifically XP mostly, blindly trust Nortons etc. and although relatively useful, they just remain in no way adequate enough for safest protections against severe interruptions to their good machnes.

These are smply just not enough to maintain the freedom a user expects.

Novice users are vulnerable no matter what license they hold and from my experience they still continue to suffer interruptions if not worse distortions which vandalize their internet service investments.

[solcroft]

-{ Quote: "if is unknown, then Prevx watches it like a hawk and if it determines what it is doing is bad and locks it down." }-
Sounds exactly like what ThreatFire does to me. So unless you think Prevx in ABC mode is not good for novices as well...

[Kees1958]

-{ Quote: "Wouldn't that just eliminate the FPs (and protection!!! :o) for IE alone, while retaining the FPs for other programs?" }-

TF also has a lot of FP on this area. Protection for any browser is irrelevant when using a policy sandbox like GesWall or DefenseWall.

I am not using TF or Mamuto anymore (got both lisences of TF Pro and Mamuto), behind DefenseWall now using Comodo with a trimmed down D+
- removed general file protection based on suffix and directory, replaced with specific files
- removed Internet Explorer Registry Protecton, added others (the same static registry rules as I used to add in SSM, EQS, WinPooch and TF)
- D+ only looks at new arrivals (executables) on hard disk and fires a pop-up when intruding specificly at Memory/Process tampering, Driver installation, Protected COM-, File- and Registry-settings and low level Harddisk access.

Mind you this is on the stable PC, the gamer PC (Vista64) still has a behavior blocker( PRSC). Comodo was a pop-up generator on the gaming PC, on the stable home PC it is quiet. I never was a Comodo fan, but what I could not accomplish with SSM and EQS has been realised with Comodo and D+

Funny thing is that D+ talkativeness in this setup really is not bad at all. TrojDemo for instance (TF fails on Level 3, passes on Level 4), generates in this setting 4 oranje alerts. Told my wife, well you can allow one orange alert, two becomes suspicious - allow but never choose remember, three stinks and please choose block. Never allow red alerts. Because of its dumb character, D+ has to make some differentiation in categorising threats.

[solcroft]

-{ Quote: "TF also has a lot of FP on this area. Protection for any browser is irrelevant when using a policy sandbox like GesWall or DefenseWall." }-
The original question was, I believe, how to set Mamutu to behave equivalently to ThreatFire level 3. You responded that Mamutu could provide level 4 protection with level 3 FPs by setting paranoid mode and turning off protection for IE. Unfortunately this sounds to me like zero protection for IE, and level 4 protection + FPs for everything else.

A policy sandbox for the browser may make behavioral protection for the browser irrelevant, but it sounds like you need them not because they're superior to behavioral protection for the browser, but because you have NO behavioral protection for the browser (by turning off IE protection in Mamutu because it'd produce too many FPs otherwise).

Good luck with Comodo. It's not my cup of tea, though. It seems the developers just focused on writing something that flags on as many actions as possible; they still have a long way to go before they catch up with the design elegance of, say, SSM and EQSecure.

[Kees1958]

Ah you are up for playing time, so let's play then:

-{ Quote: "
The original question was, I believe, how to set Mamutu to behave equivalently to ThreatFire level 3. You responded that Mamutu could provide level 4 protection with level 3 FPs by setting paranoid mode and turning off protection for IE. Unfortunately this sounds to me like zero protection for IE, and level 4 protection + FPs for everything else.
" }-

ad Bold 1:
Yep it leaves IE7's registry unprotected. We are using Opera and a Policy sandbox, so yes it is true, but not relevant (IE's registry settings not being ptotected).

ad Bold 2:
I have not encountered much FP's, as said no more than TF. May be it is the limited test set I am using. Bellgamin once dared you to publish this large collection of tests you had performed. You more or less admitted that would be a great idea. I think that would be a great idea also, so I rest my case.



Regards Kees

[Kees1958]

-{ Quote: "
Good luck with Comodo. It's not my cup of tea, though. It seems the developers just focused on writing something that flags on as many actions as possible; they still have a long way to go before they catch up with the design elegance of, say, SSM and EQSecure." }-

Not quite true, considering existing applications as safe is a nice idea. Not for a first line of defense, but for a second line (after a policy sandbox) it will do fine on a stable PC. In this context it is more an IDS than a HIPS which only evaluates newly arrived executables. I also outlined that I reduced the attack vectors which D+ monitors. This inevitably reduces the number of pop-ups for NEW applications.

Compared to Online Armor, Comodo still has a way to go. A few things really do not work smoothly at the moment (at least the individual parts of Pending files, Security Policy and Image Execution control work okay, but they should be integrated, so in this context I agree with you in regard to design elegance). Still I think it is a great feat to be the first to provide a Vista64 bits HIPS like functionality.

I am still a long way from being a Comodo fan, but you can not (at least I) deny the facts. They did an astonishing job with V3 in facilitating all XP and Vista platforms,

[Kees1958]

-{ Quote: "
A policy sandbox for the browser may make behavioral protection for the browser irrelevant, but it sounds like you need them not because they're superior to behavioral protection for the browser, but because you have NO behavioral protection for the browser (by turning off IE protection in Mamutu because it'd produce too many FPs otherwise). " }-

What security is superior is still an open discussion. When browsing Wilders it seems there as many opinios as there are members.

In terms of risk management, the ranking order is:
1. Stay out of risky situations, you won't need a defense when you are not attacked (e.g. site advisor)

2. Reduce the vulnarable spot/attack surface (e.g. UAC and Policy sandbox)
Reason why a lot of old fortresses are build in the loop of a river/hill top with only one or two access roads.

3. Control the attack vectors (traditional HIPS monitoring hooks/SDT), so you won't get hit. Normally a talkative and more user intervention required solution. Prevention is better than to cure will all the SSM, EQS, NG etc fans argue. In this category the FW and Traditional HIPS will merge into one solution (Online Armor, Comodo, Look & Stop)

4. Limit the damage/damage containment. In this category are Antivirus (although AV's providing Network and HTTP scanning are really ahead of things), Policy Sandboxes (because they remember the untrusted status of a downloaded file) and yes Behavior Blockers.

Using this scheme it is obvious that Policy Sandboxes like GeSWall and DefenseWall reduce the attack surface and limit the damage, while behavior blockers only limit the damage. That said Policy Sandbox do not need user interaction, Behavior blockers do need user interaction. So in this context a policy sandbox is superior to a behavioral blocker.

Do you mean this with you need them (sandbox) not because they're superior to behavioral protection for the browser, otherwise I do not get where you are pointing at, but feel free to explain

[solcroft]

-{ Quote: "Yep it leaves IE7's registry unprotected. We are using Opera and a Policy sandbox, so yes it is true, but not relevant (IE's registry settings not being ptotected)." }-
It is relevant as long as you're trying to answer my question, since that's what I asked. But if what you're aiming to do is to ignore that and just rant on about your setup, no, I guess it's not.

-{ Quote: "I have not encountered much FP's, as said no more than TF. May be it is the limited test set I am using. Bellgamin once dared you to publish this large collection of tests. So I rest my case." }-
Not really sure what you're talking about. FPs have nothing to do with how much malware one sees. I don't like the amount of FPs TF has on level 4, but if you're comfortable with that ("not encounted much FPs, no more than TF"), hey, whatever rocks your boat, I'm cool with that.

-{ Quote: "I am still a long way from being a Comodo fan, but you can not (at least I) deny the facts. They did an astonishing job with V3 in regard to also facilitating Vista64 bits." }-
Don't really follow you again; what am I denying, exactly?

As for astonishing, that can be interpreted both ways. As far as the Defense+ module is concerned, I can safely tell you I'm not impressed by it in a positive way. It's one of the least well thought-out HIPS at the moment IMO, but again, to each his own.

-{ Quote: "2. Reduce the vulnarable spot/attack surface (e.g. UAC and Policy sandbox)
3. Control the attack vectors (traditional HIPS monitoring hooks/SDT)
4. Limit the damage/damage containment. In this category are (...) Behavior Blockers." }-
Your listing doesn't quite make sense. These three solutions are essentially identical. #2 and #4 are the same as #3, except with hard-coded internal rules.

-{ Quote: "Do you mean this with you need them not because they're superior to behavioral protection for the browser, otherwise I do not know where you are talking about, but feel free to react." }-
You mentioned using Mamutu to protect IE is redundant because you have a sandbox. I'm just pointing out that Mamutu would (presumably) have done sufficiently even in the absence of a sandbox. The reason you need a sandbox is because you turned off your already-existing protection; and then you turned around and claimed that it wasn't relevant.

[Kees1958]

:P -{ Quote: "It is relevant as long as you're trying to answer my question," }-

What is your question then?


-{ Quote: "Not really sure what you're talking about. " }-
You are always claiming things based on tests, but you never publish these tests. Bellgamin asked you once to do so, you said that would be a great idea, so publish them

-{ Quote: "FPs have nothing to do with how much malware one sees." }- I am refering to my limited test set. A decent test set also contains at least all the 'good' paths, not only error situations. So I am not saying anything on FP's and malware.


-{ Quote: "Don't really follow you again; what am I denying, exactly?" }- Nothing, is in regard to appreciation of Comodo

-{ Quote: "
It's one of the least well thought-out HIPS at the moment IMO " }-
Against what criteria is it least well thought-out?

-{ Quote: "
a) Your listing doesn't quite make sense. b)These three solutions are essentially identical. #2 and #4 are the same as #3, except with hard-coded internal rules. " }-
a.) not my listing = general risk/contingency management
b.) a policy sandbox reduces the attack surface, a behavior blocker does not
How can I spell it out to you. When you are a limited user, you are not allowed to go into places. With a behavior blocker you are allowed to go into places. So the domain to be secured/protected is much larger. The hard coded/soft coded difference is really a non-argument. Hard coded to my knowledge means a fixed hard coded condition clause in the program. Soft coded could be an external file (like the XML files of EQS or the custom rules of TF)

-{ Quote: "
You mentioned using Mamutu to protect IE is redundant because you have a sandbox. " }- This is true

-{ Quote: "
The reason you need a sandbox is because you turned off your already-existing protection" }- I think you are putting the horse behind the wagen. Look at the early test of CyberHawk (1 fail) and PrevX (4 fails). Policy sandboxes like GeSWall and DefenseWall (zero fails) clearly scored better in an old AV comparatives test. The simple reason why policy management, wil always outperform attack vector control and attack vector control will always outperform behavior blocker is that either the domain to be protected/guarded is less or the intrusion response is more straight forward. When SSM finds out that a program is a danger by setting a global hook, and it is not in the allowed list it simply says NAH. A Behavior Blocker still has to find out whether this intrusion is serious enough, to trigger a pop-up. When it allows the program to go through the defense is much more complex (should also undo the previos actions of this program). Larger Domain (e.g. User versus Admin) or a larger flow of events (1 intrusion versus two or three intrusions by the same program) will ineventenly lead to more complex coding and to a higher chance of errors.

As a matter of fact you acknoledged this yourself when running into a lsas problem which TF could not handle (DefenseWall does), since then you are running LUA

See these outdated and arbitrary tests http://www.av-comparatives.org/seiten/ergebnisse/HIPS-BB-SB.pdf and http://www.techsupportalert.com/security_HIPS.htm

Regards

[solcroft]

-{ Quote: "What is your question then?" }-
Refer to posts 29 and 31 in this thread.

-{ Quote: "You are always claiming things based on tests, but you never publish these tests. Bellgamin asked you once to do so, you said that would be a great idea, so publish them" }-
In the context of this discussion with you I have not claimed anything based on my tests. You seem to be pulling my tests into this discussion for no discernable reason; might I ask why?

Also, some things happened by surprise, and I'm now an engineering intern who toils away with ANSYS and AutoCAD 8am-6pm on weekdays. Kind of a stressed schedule, to say the least, so I'll have to postpone any plans regarding my tests indefinitely.

-{ Quote: "I am refering to my limited test set. A decent test set also contains at least all the 'good' paths, not only error situations. So I am not saying anything on FP's and malware." }-
Again, you've definitely lost me here. You said that you haven't run into "much" FPs, perhaps based on your limited test set. Since when does one test for FPs using malware?

-{ Quote: "Against what criteria is it least well thought-out?" }-
The grouping and categorization of its alert types and their respective necessities, ease and flexibility of editing or adding new/existing rules, rule creation to globally monitor a single specific process.

-{ Quote: "a.) not my listing = general risk/contingency management
b.) a policy sandbox reduces the attack surface, a behavior blocker does not
How can I spell it out to you.
When you are a limited user, you are not allowed to go into places. With a behavior blocker you are allowed to go into places." }-
Wrong. Just because a specific brand X of behavior blocker doesn't include inbuilt rules to restrict you to "go places", so to speak, doesn't mean other brands won't as well. Nor does it mean that they're incapable of doing so.

Just take the example of loading a driver. A limited user is not allowed to access the OS kernel. A behavior blocker can easily limit you from doing the same, even though some products may not. Or different products might have different criteria to selectively block kernel access.

Keep in mind that the products you have used do not define the product class they belong in; i.e. the way one or two products operate does not represent how all others will, nor the limitations of the capability of all others. A behavior blocker can just as easily block you from kernel access as a limited user account does, if its vendor so wishes to. And therefore, in essence, they're essentially identical in theory.

-{ Quote: "I think you are putting the horse behind the wagen. Look at the early test of CyberHawk (1 fail) and PrevX (4 fails). Policy sandboxes like GeSWall and DefenseWall clearly scored better in this AV comparatives test (zero fails)." }-
I don't think I'm the one guilty of that; after all, you're the one with both products installed. I'm just pointing out where I found your reasoning to be a little odd.

[solcroft]

-{ Quote: "As a matter of fact you acknoledged this yourself when running into a lsas problem which TF could not handle (DefenseWall does), since then you running LUA " }-
Just to answer a point you added into your edited post.

As I mentioned above, ThreatFire and DefenseWall are single products and do not represent what their respective product classes can do. You seem to be implying that TF will never be able to stop this kind of attack even if its developers became interested in adding that functionality to it, while DefenseWall can; and these two single products and this one attack vector are evidence that sandboxes are superior to behavior blockers. Is that what you indeed intend to hint at?

[aigle]

-{ Quote: "
As a matter of fact you acknoledged this yourself when running into a lsas problem which TF could not handle (DefenseWall does), since then you are running LUA " }-Sorry to raise a bit OT, but what was this problem?

Thanks

[Kees1958]

Aigle,

I do not know what malware Solcroft has tested. Some malware is able to exclude/purge the admin by attacking lsass related files. GeSWall also protects against it. Running in Vista with LUA also does the trick.

Maybe Solcroft can PM you the details.

Regards Kees

[Kees1958]

-{ Quote: "Just to answer a point you added into your edited post.

As I mentioned above, ThreatFire and DefenseWall are single products and do not represent what their respective product classes can do. You seem to be implying that TF will never be able to stop this kind of attack even if its developers became interested in adding that functionality to it, while DefenseWall can; and these two single products and this one attack vector are evidence that sandboxes are superior to behavior blockers. Is that what you indeed intend to hint at?" }-

By design a car will handle faster in slow speed corners, because a biker has to counter steer or weigh to the opposite of the corner, before the bike falls in. At a higher speed a two wheel design is superior, because of its reletavie slenderness (opposite of width) it can drive a more ideal curve at the same speed and the leaning angle compensates friction and wheel skid, then a car driving the same track. By design a car will always be able to reach higher speed on straights because 4 wheels will facilitate down force in a more stable way.

Conclusion
An average sandbox will always have the odds to be superior to an average behavior blocker, an excellent sandbox will have the better changes of being superior to an excellent behavior blocker.

It is dead simple a sandbox reduces the attack surface, so it will perform better. A hips reacts after one attack vector being violated, so it will have less trouble of stopping the malware to a halt. A a behavior blocker has to evaluate a sequence of actions, it will therefore will be harder to undo the things done by the malware.

You are dragging me into a discussion in which it seems whether I do not like or think highly of ThreatFire. Th eopposite is the question, that is why I posted the how to. The makers of TF have done an excellent job. Because it is so difficult to create a decent working behavior blocker. Ever wondered why the behavior blockers were the last guys on the block? Because it requires much more coding and knowledge to establish the same protection as for instance a classical vector based HIPS.

Come to think of it: I once posted custom rules for ThreatFire. TF will never be as good a vector control based HIPS as SSM or EQS or PS. Therefore they should abandon the development of custom rules and make it a install and forget HIPS. That would be the most clear and differentiating market position.

[HAN]

-{ Quote: "Come to think of it: I once posted custom rules for ThreatFire. TF will never be as good a vector control based HIPS as SSM or EQS or PS. Therefore they should abandon the development of custom rules and make it a install and forget HIPS. That would be the most clear and differentiating market position." }-
This is what attracted me to TF to begin with. I wanted decent quality behavior-based protection with minimal intervention on my part. I'm not against customization but I would never recommend or use it. If you want that, as you note, you're back to a more traditional HIPS. Which IMO, is not the same thing at all...

[solcroft]

-{ Quote: "By design a car will handle faster in slow speed corners, because a biker has to counter steer or weigh to the opposite of the corner, before the bike falls in. At a higher speed a two wheel design is superior, because of its reletavie slenderness (opposite of width) it can drive a more ideal curve at the same speed and the leaning angle compensates friction and wheel skid, then a car driving the same track. By design a car will always be able to reach higher speed on straights because 4 wheels will facilitate down force in a more stable way." }-
Unfortunately the difference between sandboxes and behavior blockers is not the difference between cars and motorcycles. More like the difference between automatic and manual transmission. I've already explained why this is the case.

-{ Quote: "You are dragging me into a discussion in which it seems whether I do not like or think highly of ThreatFire." }-
Actually, no. I asked a question, which can be found if you refer to posts 29 and 31 in this thread (as I've mentioned).

-{ Quote: "Ever wondered why the behavior blockers were the last guys on the block? Because it requires much more coding and knowledge to establish the same protection as for instance a classical vector based HIPS." }-
Not really. Behavior blockers were the ONE OF THE FIRST guys on the block; this technology existed as early as back in DOS 6.0 as a TSR module in Microsoft Anti-Virus for DOS, and from what I've heard previous tools from before I knew anything about computers precede any known blacklist scanner. It was just that the malware landscape and techniques back then created selection requirements that favored simple blacklist scanners, which then became the mainstream.

[aigle]

-{ Quote: "Aigle,

I do not know what malware Solcroft has tested. Some malware is able to exclude/purge the admin by attacking lsass related files. GeSWall also protects against it. Running in Vista with LUA also does the trick.

Maybe Solcroft can PM you the details.

Regards Kees" }-
Thanks Kees.

[Kees1958]

-{ Quote: "Unfortunately the difference between sandboxes and behavior blockers is not the difference between cars and motorcycles. More like the difference between automatic and manual transmission. I've already explained why this is the case.

" }-

Your missing the point, what I told you that a car has relative advantage on some area's over a motor bike, on other area's the bike has an advantage to the car. Same applies to software set up from a different philosophy or architecture.

Sometimes approach A is better, other instance it is B. Have fun with your transmission.

[solcroft]

-{ Quote: "Your missing the point, what I told you that a car has relative advantage on some area's over a motor bike, on other area's the bike has an advantage to the car. Same applies to software set up from a different philosophy or architecture.

Sometimes approach A is better, other instance it is B. Have fun with your transmission." }-
You continue to ignore my arguments, and repeat that cars and motorbikes are different, as though it is somehow relevant to sandboxes and behavior blockers. I see no way to respond to that without stepping onto a wildly off-topic tangent.

So, er, have fun with your motorcycles?

[Kees1958]

-{ Quote: "So, er, have fun with your motorcycles?" }-

Actually I do (occasionally race with a new one and am restoring a 25 year old motor bike). Are you enjoying the drawing/engineering? What is the company engineering if I may ask (transmissions :D )?

Regards Kees

[solcroft]

-{ Quote: "Actually I do (occasionally race with a new one and am restoring a 25 year old motor bike). Are you enjoying the drawing/engineering? What is the company engineering if I may ask (transmissions :D )?

Regards Kees" }-
It's always fun to be able to tell people someday later: "Hey, I was one of the guys who drew the site plans for that building." ;D The work is enjoyable, the working hours not...

As for which company, it's just a local private company that does civil engineering work. The boss turned out to be the father of one of my high-school classmates, which I found out only one week into the job.

[Rasheed187]

Can someone perhaps tell me what the discussion between Kees1958 and Solcroft was all about? I really don´t have a clue. Or is it something like Mamutu vs TF? :blink:

-{ Quote: "It depends if you have enabled/disabled the specific monitoring features in the application. I havn´t yet tested Mephisto but I look forward to compare it with TF." }-

@Cerxes, can you perhaps give me a link to this Mephisto app, is it a new HIPS? ;D

[Kees1958]

Rasheed,

Difference between security application which reduce
1) the attach surface (e.g. DefenseWall and GeSWall),
2) applications that control the attack vectors (e.g. SSM, D+, EQS) and
3) behavioral blockers (TF, PRSC, Mamuto).

Socroft and I had a different oponion on those three, my point of view
1) Attack surface reduction (less complex software, easy to use, very secure)
2) Attack vector control (average complex software - what to protect in the SDT, require user intervention, very secure)
3) Behavior blockers (very complex software - looks at a sequence of actions, easy to use, secure, but by nature less secure than the above)

Regards