Classical HIPS and policy based HIPS discussion

@wat0114
On systems that change a lot, classic HIPS are very talkative and probably aren't a good choice. The rapid update policies of certain user software have made that issue much worse. IMO, creating rules that can accommodate auto-updating makes the HIPS less able to defend against malicious file replacement or modification. Shortly after I started testing the advanced options in SSM Pro (which are very similar to the options you posted for Jetico), I disabled all auto-updating. IMO, the tradeoff is too great. For myself, updating is now a manual process allowed for the administrator only. With auto-updating disabled, it doesn't take that long to finish configuring those options.

 

Your question was answered in the above article you quoted:

Advantages and disadvantages of a HIPS are clear – maximum control of your system for experienced users who know how to evaluate arising alerts. If you prefer concrete decisions and as few alerts as possible, though, you had better opt for behavior analysis.

If you know what you are doing, you can completely lock down your system with a HIPS. However, doing so will most likely effect other benign activity such as application installations and the like. For the experienced tech savvy user, that is not a problem. For the normal user, it can create havoc.

The downside of behavior blocking is by definition it is based on behavior. For example, Windows OSes have less than secure features that have been left in place to accommodate "legacy" applications. Malware has exploited those features to disguise its activities. As such, it is difficult for behavior blockers to detect those activities since they a being masked under a legitimate OS feature.

Bottom line - it is a matter of convenience with pretty good protection using behavior blocking versus inconvenience with absolute protection with a tightly configured HIPS. In reality, an inexperienced user configuring a HIPS usually results in the least secure protection option.

 

That is not correct. To the degree the classic HIPS model has declined was much more closely related to Microsoft's decision to block Kernel patching.

It's much harder to program a HIPS without patching the Kernel. Just about every hips on NT 5.x used a kernel patch and most just didn't/couldn't make the transition.

 

Agreed. Classic HIPS can't give the user the same degree of control on these systems. MS can claim it improves security but the fact remains that their built in security is being attacked and defeated on a regular basis. Interesting that this so-called improvement comes after MS gets help from the NSA. IMO, this is more about taking control away from the user than it is for securing the system. I'll stay with operating systems where classic HIPS can give the user the final say.

 

Lol, don't you guys had discussed the chattiness of a CHIPS in the past a lot? Not enough?

Using CHIPS is like having a lion as your pet. That is why I love to use the term "taming" when referring to my achievement in making a CHIPS software to be usable IRL scenarios. True, it is not everyone's choice. But once I have my own whitelist with custom policies, the popups are greatly reduced. Guys you don't have to use it in all-ask mode. If you know that your web browser doesn't need to install kernel-level drivers, give it a deny permission. =V

I would say that Comodo and Emsisoft need to be highly appreciated for the information they provide in their websites, explaining what do things do.

 

In addition to Comodo and Private Firewall, Outpost also has an excellent HIPS.

 

MS it seems with trying to implement security into their OS have taken more control out
of the hands of the user. Controlling a 9X or XP system is much more attainable even for a
novice user than using for example Windows 8.1 IMO. HIPS as mentioned does require a
learning curve and user input, but I like the idea of the user being in control rather than
OS. IF setup properly a HIPS with firewall monitoring control is a good combination to
keep your system secure. Whitelists have grown (look at Comodo as example) so I don't
favor such long lists and don't always trust what they deem safe.

 

It depends on how paranoid one feels they need to be with autoupdating and so forth, especially in user space directories. IMO, it's going to take a fairly targeted attack or an attacker going beyond the mainstream approach to breech the rule example below...

C:\ProgramData\NVIDIA\Updatus\Packages\*eaf\drsupdate.*_RUNASUSER.exe

I just don't worry about it that much to get so overly restrictive with rules. I'm always a recent image away from recovering, if needed, and I've never yet had to resort to such a trivial recovery method due to malware. BTW, I don't use Windows much anymore, so I'm getting a bit rusty on this stuff

 

Totally agree, especially at a service level. On systems newer than XP, the services are interdependent to the point that the user can't control them.

The combination of a good firewall and classic HIPS is very effective. They don't need to be a combined package. I prefer them to be separate so that the HIPS isn't exposed to the internet but can still protect the firewall.

Regarding whitelists, ideally the user should build their own. Classic HIPS were originally designed to eliminate the dependence on vendor maintained white or black lists and the internet that delivers them. Using vendor supplied whitelists reintroduces the weaknesses they were designed to eliminate. I lost all trust in vendor whitelists back when adware/spyware removers were becoming popular. Vendors were being threatened or coerced into removing detections. With government agencies in the malware business, it's only got worse and harder to prove.

 

Isnt Outpost more a behaviour blocker/limited HIPS?

I like outpost as it provides a good balance IMO

 

I always thought Outpost was a full HIPS with firewall filtering.

Then again it all depends on your descriptive definitions of what a BB or HIPS is considering the case has been made elsewhere on Wilders that Defencewall is more a policy restriction sandbox than a HIPS if so then is this the same for Geswall ? Or what about Comodo`s auto-sandbox being called a BB ?

The best of all possible worlds in my view is running a "proper" HIPS with a "proper" BB for full security.Hence my use of Spyware Terminator HIPS plus Private Firewall`s BB on Win7 64 bit and XP 32 bit systems.

Before anybody jumps in and and claims ST hasn`t been been in development for years..yes I know but what I would like to know is, what`s the big deal if it hasn`t been ?

So for the sake of argument would the latest Comodo HIPS really fare any better than Malware Defenders on a 32 bit sysem ?

And if so why ?

Regards Eck

 

What questions? It's the titles of the article........

 

Oops. Sorry about that.

 

Your comment about Private Firewall having a behavior blocker tweaked my interest since I used it a couple of years ago and became quite proficient with it. I checked out the PF web page and indeed it's now labeled a BB. Then I check out the current user documentation. Appears to me nothing has changed with the product since I used it other than to make it WIN 8 compatible. It uses a HIPS and a good one at that but the same one it has had for years. The HIPS has to be "trained" like most HIPS have to be. Then the user has to configure all their Internet accessing applications to limited privileges.

 

It's not just firewall filtering. It's a very robust application firewall with enhanced filtering capabilities.

 

I'm not sure what you are talking about. You don't have to use any whitelisting with Online Armor if you don't want to. Just untick the two boxes in the settings shown in the pic below. My own preference is not to be bothered with prompts about safe actions.

 

Online Armor HIPS does most of the work for you. You really don't have to spend time configuring rules. It also uses whitelisting just like their BB. The only thing I have not liked about the behavior blocker in the past was I got more prompts with it than I did with OA (this was several years ago). Do the prompts give specific information about the attempted execution in question now? I use to get a lot of prompts stating an application was exhibiting backdoor like activity, but it did not explain exactly what the application did that was considered backdoor like activity. I have not used the BB for any significant amount of time in the past 4 years. Also, how often do you get prompted by the BB?

 

If you uncheck "Automatically trust programs that Emsisoft deems trustworthy" you'll get a popup warning.
You'll also be prompted for any program that tries to run that you have not already allowed.
Be prepared for many prompts to answer.
Wouldn't recommend this if your a novice user. Also not recommended by Emsisoft to disable this.

 

I was responding to Yuki which stated in his post that he stopped using Online Armor because he did not want to be forced to use it's whitelisting. I was just showing him that you don't have to use any whitelist at all with OA if you don't want to. I would never recommend it either, but we all have our own preferences.

 

Once in a blue moon do I get an alert. Appears any unsigned app will trigger a dial-out to their cloud for verification. Also very sensitive to anything that appears to be keylogging activity. It always quarantines ALKT tool for example. Overall, far less chatty than any HIPS I have use in the past.

Also a "middle ground" approach to the EAM behavior blocker is to increase the default confidence level of 90%. You will start getting alerts but nothing in comparison to running in paranoid mode.

A good description on EAM behavior blocker is here: http://blog.emsisoft.com/2012/10/16/tec121016/.

Also note than EAM BB in its present state does not have anti-exploit protection although they are working on upgrading it to do so: http://support.emsisoft.com/topic/16251-does-behavior-blocker-protect-against-file-less-infections/. I use EMET 5.1 with a custom configuration to due that. I also use EMET certificate pinning to protect me against man-in-the-middle attacks.

 

Not so pessimistic OA still has some companions: Spyshelter = HIPS + FW, Outpost and Comodo (allthough Comodo seems more like an ever morphing colossal collection of code depending on the hype of the year IMO)

 

OA always flagged my browser as a keylogger. Emsisoft dev said basically normal behavior and allow it.

 

Also, a few conventional AV solutions have user configurable HIPS protection; ESET's NOD32 and Smart Security for example: http://kb.eset.com/esetkb/index?page=content&id=SOLN2950.

 

Absolutely. It's what I used before I went with Ad-Aware's Pro Security. I started the mostly ignored "Spyware Terminator Redux: HIPS" here.

Anyhow, now that the topic has expanded to HIPS/BB/sm'other, I'll jump in and add what has been mostly dismissed or backhanded in other threads over the years here: Zemana's IntelliGuard Cloud. It's exactly why AntiLogger Pro is such an interesting advancement in the breed. Suspected system intrusion and logging activities are submitted for realtime analysis first using the frequently updated local threats.zdb store and then the cloud IntelliGuard and VirusTotal services. The results are integrated into the ZAL Security Alert for a more informed user determined action or an auto-allow/block outcome and popup/none level as set in options under the Security Settings and IntelliGuard Cloud tabs in the UI.

Check out one of the screen shots I took yesterday on my test system for an alert evoked by SurfRight's updated Exploit Test Tool 1.5 released here by Erik… yesterday. The Company and "View more details" items are clickable and open additional information panels.



Cheers.

 

Throughout the entire life of mine I've only ever known 3 names of policy-restriction HIPS. OTOH a lot more names I've heard from the CHIPS department. Seems odd to me since this type of HIPS should've had better prospect than those of its classical ancestor.