Rebranding HIPS & Behavior Blocker

Comodo Internet Security - CIS Added/Rejected Wishes - CIS
1

The current way in which CIS has chosen to organize it’s system protection and sandbox components is opaque, less intuitive than it can be, and snubs those of us who prefer using “HIPS” outside the sandbox.

Problems…

  • HIPS functionality by itself has been buried.
  • Even when HIPS is disabled, it is running as part of the sandbox.
  • HIPS is an opaque acronym, yet it is best described, concisely, as a behavior blocker.
  • The sandbox is not a behavior blocker, especially in light of HIPS being exactly that. The sandbox is a vritual-izer.
  • The behavior blocker, under advanced settings, is represented as a component separate from the sandbox and HIPS, when it is actually comprised of both.
  • Defense+ is represented as being comprised of HIPS, Behavior Blocker, and Sandbox, in the advanced settings window, yet it is the Behavior Blocker that gets precedent on the main GUI.

Solution…

  • Rebrand HIPS as the Behavior Blocker.
  • Rebrand the sandbox as the Behavior Virtualizer.
  • Represent both as independent and equally prominent components of CIS in both the main GUI and advanced settings.

So, after some discussion of HIPS vs Behavior blocker, I feel compelled to make the follow points…

  1. Some have made the case that the distinction is that: A HIPS allows for more granular control than a Behavior Blocker.

Well. Ok. It’s right there in the sentence. This doesn’t justify splitting them into separate components. It creates a demand for a more versatile implementation of controls for a single component. Allow the HIPS to function at varying levels of granularity.

  1. Some have made the case that the distinction is that: A HIPS is for more advanced users than a Behavior Blocker.

This is a side effect of being more granular. Allow the HIPS to function at varying levels of granularity and you allow the HIPS to be accessible to both novice and advanced users.

  1. Some have made the case that the distinction is that: A HIPS is less automated than a Behavior Blocker.

Another side effect of granularity, and something solved, in part, by allowing varying levels of granularity. Good design for settings, alerts, and complementary services like File Ratings solve the rest of that issue.

  1. Some have made the case that the distinction is that: A HIPS blocks specific behavior where as a Behavior Blocker blocks an entire application.

Broken record. Granularity. But seriously. Look at that sentence. Which one blocks specific behavior? The Behavior Blocker ofcour- oh wait.

  1. Some have made the case that the distinction is that: A HIPS relies on the user to determine whether an application is good or bad where as a Behavior Blocker determines this for the user according to specific combinations of behaviors.

So… you could have two separate components, blocking the same program from performing the same behaviors, one that’s naggy and one that’s smart. Or… have one component and allow for the ability to tailor just how smart or naggy it will be.

  1. This juxtaposition I just love: “The biggest downside to behavior blocking is that it requires higher level of experience on the part of the user, who must individually make decisions about what is - or is not - allowed,” where as,“While HIPS […] is best suited for experienced users who have both the knowledge and the patience to answer the prompts and make the proper configuration choices. […] behavior blockers help with much of the decision making. [ Behavior Blockers ] can be far simpler [ than HIPS ] for users to understand.”

Complete 180 between two articles both linked to from this thread. Behavior blockers are hard! No wait! They’re easy! HIPS is hard! 88)

Have I missed any key distinctions that supposedly justify keeping these components separate?

A footnote in this absurdity: Let’s call one component… a firewall. This will be more granular, naggy, and just for advanced users. Let’s call this other component… a connection blocker. It will block whole programs from the internet with little to no user input. Now, since these two components actually do the same job, let’s recommend that only one be active at a time. Genius idea right? (… end scene.)

Login to view the mockups…

  • Apply button.
  • Removal of double negative style check boxes.
  • “Behavior Blocker” refers to HIPS, and contains all appropriate settings.
  • Groups section for quick access to file, registry, com, zone, and port groups.
  • Apply button.
  • Removal of double negative style check boxes.
  • “Behavior Virtualizer” refers to the sandbox, and contains all appropriate settings.
  • Application list and shared spaces are separated into two panels.

[attachment deleted by admin]

2

The HIPS isn’t really a behavior blocker, as they are traditionally understood. A HIPS will monitor all processes, and ask the user how they wish to proceed.

A traditional behavior blocker will monitor all processes, but will only react when an application triggers a certain number of “suspicious” activities.

So the current incarnation of the HIPS is really a HIPS, not a behavior blocker.

You are correct that the current incarnation of the BB in CIS 6, isn’t really a behavior blocker. It’s actually more of a sandbox/automatic HIPS. The idea is that within a few release versions, the BB is to become more like a traditional BB. It is currently called the BB because that is what it is slated to become, and the developers felt it less confusing to start calling it that with the release of CIS 6, instead of changing the name of the module after people have become familiar with the new version.

3

According to this distinction, wouldn’t it then follow that behavior blocking, i.e. blocking of those things that are suspicious, is a subsequent function of a Host Intrusion Prevention System?

Isn’t “intrusion,” in the label Host Intrusion Prevention System, begging the notion that it is protecting the system from (via blocking) suspicious behavior, despite this apparent distinction that HIPS does not necessarily react only to suspicious behavior?

Straight out of wiki: Host-based intrusion prevention system (HIPS): an installed software package which monitors a single host for suspicious activity by analyzing events occurring within that host.

And there’s nothing official that I can find outside of Comodo for “Behavior Blocker,” which I always took as a lay-term - certainly not something apart from a HIPS.

How would one make the sandbox/(automatic)HIPS more like a behavior blocker?

4

A behavior blocker is very similar to a HIPS, yes.

I don’t know if there is any “official” distinction between the two. I just know how “traditional” behavior blockers work, and that is generally what people tend to think of when they hear the term behavior blocker. ESET and Symantec discuss what they feel a behavior blocker is, and it is a system that monitors processes for suspicious behavior, and blocks that process. Which goes along with what I’ve already stated.

I have no idea. That’s just what the developers have said. We’ll just need to wait and see.

They’re also going to add the ability of the BB to undo any changes made by malware. I have no idea how they will do this either, but I think it will be fun to find out. :slight_smile:

Edit: Reworded a sentence to hopefully make more sense. :embarassed:

5

So where exactly, in Symantec’s and ESET’s description of a Behavior Blocker, does it stray from the scope of a HIPS? I don’t think it does.

The ability to undo changes made by malware specifically, would make most sense as part of the antivirus component. The ability to undo changes made by any application that fall under the scope of the HIPS, would make most sense as part of the HIPS component, particularly when there doesn’t seem to be a difference between the behavior that either the HIPS or the Behavior Blocker actually monitor.

So there’s HIPS, of which a Behavior Blocking is a part, or which could very well be referred to as a Behavior Blocker, but Comodo segregates the HIPS and Behavior Blocker. Then there’s the sandbox, which is not a Behavior Blocker, yet it’s buried under that very title, and peppered with its own inaccessible version of HIPS. And this component, which is primarily a sandbox, is going to get the ability to undo changes made by malware… not just within the sandbox, but on the actual system.

Am I exaggerating how ridiculous that sounds?

6

OK.

7

I realize I’m a little curt. I’m sorry. But that question wasn’t entirely rhetorical. Neither were.

Your reaction is abstract and dismissive. This is usually the response one gets when the other is fed up trying to get the one to hear what’s being said. Now, I may disagree with you, but I don’t think I’ve been particularly unreceptive or un-hearing to the points you’ve brought up. Is there something essential to my understanding of the relationship between HIPS, Behavior Blocker, and sandbox, that you’ve presented, that I have ignored or glossed over?

8

Sorry Glifford, my intention wasn’t to be abstract or dismissive, and I’m definitely not fed up. Far from it! :slight_smile:

There’s really nothing to read into my reply, and I’m sorry if you did. I tend to take things at face value. You said you didn’t think the description of a behavior blocker strayed from the scope of a HIPS, and I said OK.

To me the distinction of a module that requires user input for everything, versus a module that requires very little user input is fairly significant. If you don’t see it as being a significant difference, I’m fine with that. No need to split hairs. I made my statement, you didn’t agree, and that was that fine as far as I was concerned. :smiley:

Version 6 is different enough that we’re all trying to come to terms with how it operates, as well as looking at ways to improve it. Maybe the way I think of a behavior blocker isn’t the way the majority of the users see it. As such, if it makes sense to you to lump a behavior blocker under the HIPS umbrella, maybe that makes more sense to the average user. I have no idea.

So, in a nutshell. OK. :stuck_out_tongue:

9

I’m glad to hear there’s no hurt between us.

However, it does seem I did miss something essential to your distinction. If I’m understanding correctly now… the HIPS and the Behavior Blocker share performance of the same tasks, and where the major distinction lies is not in the inclusion of a sandbox nor the focus on suspiciousness, but in the level of automation and subsequent user involvement?

This strikes me as a horrible way to organize the various components of CIS. Mind you I’m not putting this on you, but the devs, assuming they share this distinction. As a comparison, we may as well have a Firewall, and a separate Network Blocker. Or an Antivirus and a separate Virus Blocker. One that requires more user input, and one that requires less.

10

I agree completely. The current BB uses HIPS features but silently and selectively contrary to classic HIPS behavior which is noisy and non-selective. The BB only triggers for unknown things where a HIPS is like a blanket covering everything and often smothering usability in the process.

11

i think the top line of the option should still have the text it is confuding to seee the disabled combobox without labels even if its a bit redundant

iirc while searching the web what BB or HIPS, it was that there were 2 types of how HIPS can be implemented

forgot the link but i think its an about.com article or info so not sure if its accurate

one is intrusion prevention and the other was intrusion detection

the intusion prevention is what we have in the CIS V5 as the hips we know in which we define what can and cannot do by an application
ie this application cannot listen to keystroke but can connect outside

the other intrusion detection is kinda like avg identity protection. in which it logs what the process actions are and if it acts like a malware then it will be blocked
ie if a programs logs the keystroke then opens an outband port it wil be tag as keylogger or spyware
but if it just listen for keystroke then its not flag

edit : rephrase some words and added some comment to the wish and so far havent voted yet

12

I agree, in so far as the Behavior Blocker distinguishes itself from the HIPS in the level of autonomy it achieves, the level of selectivity it uses to achieve it, its inclusion of the sandbox, and other minor adoptions of features that were previously dangling under the Defense+ umbrella (like the ability to detect shell code injections).

I’m no enemy to autonomy, and my insistence on HIPS as oppose to the Behavior Blocker, is not an expression at odds with the notion that usability can be improved via autonomy. Do you understand that?

13

Agreed.

iirc while searching the web what BB or HIPS, it was that there were 2 types of how HIPS can be implemented

forgot the link but i think its an about.com article or info so not sure if its accurate

one is intrusion prevention and the other was intrusion detection

the intusion prevention is what we have in the CIS V5 as the hips we know in which we define what can and cannot do by an application
ie this application cannot listen to keystroke but can connect outside

the other intrusion detection is kinda like avg identity protection. in which it logs what the process actions are and if it acts like a malware then it will be blocked
ie if a programs logs the keystroke then opens an outband port it wil be tag as keylogger or spyware
but if it just listen for keystroke then its not flag

edit : rephrase some words and added some comment to the wish and so far havent voted yet

Seeing the latter style implemented in CIS would be pretty cool.

14

Suggest to remove the revert button.
And add a restore to defaults button at the level of Ok, Cancel, Apply which applies to the selected tree node.

15

As much as I share the 3d point in your solution ie make the HIPS as important as the behavior blocker, I’m not sure that the other 2 points won’t bring more confusion than reduce it. Maybe, just rename the HIPS “Manual HIPS” and the Behavior Blocker “Automatic Behavior Blocker” and make it possible to have an Manual HIPS icon which can be pin to the taskbar. Also I wouldn’t mess with the content of the settings of HIPS or Behavior Blocker at this stage, but it is just my opinion.

16

i do agree to Boris

i also like that kind of UI but rebranding one as behavior blocker and behavior virtualizer may confuse it more since they both have the behavior word ( i know this is somewhat more of communication problems )

!ot!

i search the forum for the past discussion over BB and HIPS and found this threads this may interest you a bit
https://forums.comodo.com/empty-t30999.0.html
https://forums.comodo.com/empty-t44375.0.html
https://forums.comodo.com/empty-t36853.0.html

17

I’m not trying to make HIPS as important as the behavior blocker. I’m trying to segregate HIPS functionality, of which behavior blocking is a part, from sandbox functionality, which distinctly virtualizes behavior. Then, once all HIPS functionality is bundled into one component, and all sandbox functionality bundled into one component, each of these two components should be presented as equally important.

The automatic functions of the now branded “behavior blocker,” which fall under the scope of HIPS, would be part of HIPS… and so it’s the HIPS component that would have versatility with respect to how automated and how granular HIPS functionality should be. This would replace the current and needless redundancy between HIPS and Behavior Blocker.

There’s no “manual firewall” and redundant “automatic network traffic blocker” inclusive of things beyond the scope of a firewall. That the Defense+ arm of CIS was given this treatment is plain wrong. The solution is not supposing “well they already did it so don’t change it.”

18

Thank you for the links.

They share the word behavior because there is a synergy between a HIPS and a Sandbox - they are both analyzing the same behavior. It’s what they do with it that’s different. Hiding this relationship to avoid a concurrence of keywords seems excessive - particularly when I’ve never been confused by such concurrence elsewhere in the UI (there are various kinds of “rules”) - and borderline misleading.

Ofcourse, I wouldn’t be averse to Comodo just using the typical industry branding: Antivirus/Firewall/HIPS/Sandbox.

19

I’m in favor of HIPS eventually being fully incorporated into the Behavior Blocker and ceasing to exist as a separate module or option.

20

Well… we agree for once. :stuck_out_tongue: