For an antiquated look at HIPs (and for those who may not have seen them), here is PFs answer to HIPs rules:
Well, to examine this list, "Copy screen content" sounds good, along with "Read Keyboard State (protect against this)", until one realizes that this might normally not be a problem with an application (and could be allowed), but then might in a specific set of circumstances be one (i.e. a certain MS Office file might cause a problem if I blanket allow). By the time all of these PF HIPs rules are analyzed, there is almost nothing left of any of them, except that they buy the user time to think. We can't forget, though, that every approved alert allows changes. By the time a user decides to terminate an executable from an alert, damage may have already occurred. This I feel cannot be overlooked with HIPs.
Some of the PF rules could be useful as a general setting in any state I suppose, such as the "Debug processes" rule (monitor for such), which can be a danger, or "Physical memory operations". Others would be good, but there is no way to apply the rule to a specific action of an executable. These rules simply lead to too many prompts. Program ultimately either is allowed to perform an action for everything associated with a rule or then for nothing. For nothing usually should mean to a user terminate the process and uninstall the program, because it isn't going to work anyway. Of course it doesn't mean this to them, so they get into the routine of barging through the rules to get what they want. Who can blame them with a list like this? Yes, it might give them pause sometimes. Not likely very oftenly though.
So why discuss antiquated PF rules? Weeell, for me, I guess because very similar rules are still around, even in good programs like Comodo. I think ESET has a similar type of HIPs available (though maybe it's paranoid setting?) also. Not sure about this. Clearly, noone has ever defined HIPs as they should be defined. I think we can say this for certain. Or at least if they have been defined, I haven't seen the definition (list).
So next I get to smart HIPs as only a theory. I am thinking more of a describable conflagration of monitored activities that add up to possible danger->HIPs rule. Wave described this very well. But can we actually harden a list of these for users and make them real (or can developers) for user to understand? I think so...honestly I really do. I would love to see this. They would have to fit into the overall scheme of protection somehow, though.
At any rate, maybe using the terminology "smart HIPs" could lead to an open door to a new set of rules that could be considered standard. Seriously, I would like a set of rules that could be applied similarly to PFs rules. OK, maybe some exclusions would be in order or some location inclusion/exclusion choices or exceptions of some kind, but what would this kind of list look like? I promise, I am CHOMPING to get into this topic after 4-5 years of NO Trusted Publishers and all rules set to generate a pop up from Private Firewall.
BTW, I think we are seeing "smart HIPs" already in security applications. Maybe some of these for a list could be picked from specific apps that already exist. Endeavoring to redefine HIPs, however, I suspect would require a tremendous amount of creativity and focused energy when actually seeking to complete this type of list. Also, building a list of this sort would ultimately be focused by the concept of "protection". This means a new set of HIPs rules should be derived with this goal in mind.
When I fully break this down, I think I end up with the idea that HIPs monitoring and HIPs alerts should be two different things. Maybe it's really "smart alerts" that would be what I would like to see. Well, avast seems headed down this road with its analyzer that pops up for sketchy software. I just want to define what the HIPs rules are->be they used for monitoring or for alerts. I don't care which. Just want to be able to talk about them and know what's happening underneath.
