Hips question and recommendations

Greg,

Could you give me a comparative experiences regarding RTD and PG ?

 

Yes, I know that a virtual machine with vmware or virtualbox, will be a good way, but I don't plan to install it on my laptop, not enough space.

What do you mean by that ? I don't really understand, not good, my english.

Thanks a lot for your sharing. Yes, that's what I heard about Avira, so many falses detection, Eset are less but is more effective.

 

Classic HIPS like Process Guard and System Safety Monitor are rule based enforcement tools. Except for a couple of core processes, they begin with no rules. They trust and assume nothing. Their basic design premise is "block everything that the user doesn't allow" so they prompt for each process, and with ones like SSM, prompt regarding many activities for each process. Unless one uses the learning mode (risky on an existing system), the user will be prompted for every process that's running and starts. That's the way classic HIPS are. Provided that you aren't using an "allow once" option, your response to each prompt sets a rule or permission. Once that response is made, it won't ask you about that specific activity again. This process will be repeated for every executable that tries to start on your PC. When the rules and permissions for the processes on your PC are all specified, classic HIPS get silent until it sees something new. It takes time to completely configure a classic HIPS. If you don't know your system and have to research how to answer specific prompts, it will take a very long time to finish.

In order to make effective rules governing the actions of specific processes, the user needs to understand what those processes are and what they do. There's no way around it. If you don't know what a process does, how can you make intelligent rules for it? Classic HIPS are only as good as the user that configures it. They will allow or block exactly what you tell them to. In the hands of a knowledgeable user, they're the ultimate enforcement tools. They're able to protect against most anything, except for bad decisions by the user.

Most of these involve specific activities that classic HIPS will detect or require a running process to execute, which they'd also detect. SSM pro does most of this. Most of the activities you list can be malicious or part of the normal operations for an application. Most of the better HIPS will detect/intercept a new driver, system hook, and physical memory access. With classic HIPS, you have to determine if it should be allowed, which means that you have to understand the needs of the process, application, or Windows component that's requesting that access. You also have to decide whether that app is legitimate or a fake with the name of a legitimate process. A wrong decision can either break a legitimate application or allow a malicious process to function. Rootkits are another example. They don't just appear on your system. They're installed by a process that has to execute and be able to perform certain tasks in order to work. Classic HIPS will detect and intercept several of these steps. Whether or not it blocks the rootkit depends on your answers to its alerts.

The term "HIPS" is quite misleading. IMO it should be done away with entirely and the applications given names that accurately describe them. SandBoxie for instance is not a HIPS in the true sense of the word. It isolates whatever is running in its sandbox from the rest of the operating system and from applications that are not running in its sandboxes. It's purpose is to isolate the attack surface (applications exposed to web traffic and those that can potentially open malicious and unknown files/content, anything that comes from an outside source that you can't guarantee is clean). Isolating the attack surface is a very sound security practice. Its main weakness is the user again. Sandboxie can't protect you from items you recover and execute out of the sandbox. SandBoxie combined with a classic HIPS protected OS is a very well protected system.