SSM Useage

[Rico]

Hi Guys,

Previously I was using PG & adapted the following strategy for useage, continued with SSM. If I were to launch a trusted application, say M$ Word, I would assume a PG or SSM 'alert' is/was not a threat, but needed for the process. I understand this can be a risky strategy, but improvements can lessen the risks. Note! SSM should include a data base of known threats, & should a SSM alert match the database, easy denial could be done. I guess this would be like adding a 'white or black list' to SSM.

Anyway how do you choose between allow/block & create a permanent rule for SSM. Note I'm aware of Googleing alert message.

Thanks & Take Care
Rico

[tlu]

-{ Quote: "
Previously I was using PG & adapted the following strategy for useage, continued with SSM. If I were to launch a trusted application, say M$ Word, I would assume a PG or SSM 'alert' is/was not a threat, but needed for the process. I understand this can be a risky strategy, but improvements can lessen the risks. Note! SSM should include a data base of known threats, & should a SSM alert match the database, easy denial could be done. I guess this would be like adding a 'white or black list' to SSM.

Anyway how do you choose between allow/block & create a permanent rule for SSM. Note I'm aware of Googleing alert message.
" }-
This is not a specific SSM problem but a problem common to most other HIPS. They require that the user has at least some basic knowledge about what he/she is doing. (I think one of a handful exceptions is Prevx which uses an extensive database).

As for permanent rules: It makes no sense to create them when installing new applications. If you get alerts during the installation process allow them ONCE, finish the installation and start the new application. Now you should create permanant rules if you are comfortable with them.

[Pedro]

-{ Quote: "Hi Guys,
SSM should include a data base of known threats, & should a SSM alert match the database, easy denial could be done. I guess this would be like adding a 'white or black list' to SSM.
" }-

Welcome to Prevx1. SSm is different, what you're saying would defeat the concept behind SSM: control. That said, SSM should know Windows...

[lodore]

well proavtive defence in kaspersky has the same problem.
but they are impumenting a white list for known safe programs soon.
maybe ssm will do the same i dono thou.
lodore

[Rico]

Hi Guys,

Another approach is, deny, then if what you expected to happen does not, do it again & allow. Kind of a left handed approach.

Someone - I do not understand how a white or black list would defeat SSM's purpose, even PG attempted keeping a list for reference. Is there a website that has a comprehensive list?


Take Care
Rico

[screamer]

-{ Quote: "

Anyway how do you choose between allow/block & create a permanent rule for SSM. Note I'm aware of Googleing alert message.

" }-

First off, I never use "Learning Mode". I do however use "Install Mode".

If I get a pop-up when I run the app, I check-off "create permanent rule" (or whatever that dialogue is) and click Allow.

Somehow I think I'm missing your point ???

...screamer

edit: BaMMM!!! You didn't want the procedure, you wanted the theory. Here's mine: If I get a pop-up outa the blue, either I'll block once or if I have time, I'll Google it

[Pedro]

-{ Quote: "
Someone - I do not understand how a white or black list would defeat SSM's purpose, even PG attempted keeping a list for reference. Is there a website that has a comprehensive list?
" }-

White list is ok, if it's meant for Windows at work (...). I think one should have the option to install SSM with rules for Windows. SSM meet Windows, don't scream, he's my guest before you.
Black list, well, no. That's the AV's job. Prevx1 is different because of a great tool: automated research (the heart of Prevx1 actually).

Unless you don't mean black list, but intelligent messages:) , like a good explanation for what does it mean, why would something like that happen, why would it be dangerous if allowed, etc. Maybe the newest version does that already, i don't know.

[herbalist]

-{ Quote: "SSM should include a data base of known threats, & should a SSM alert match the database, easy denial could be done. I guess this would be like adding a 'white or black list' to SSM." }-
Have you looked at the size of an AVs database lately? A database of known threats would at least triple the size of the app, plus add the problem of keeping it up to date. The whole idea behind SSM was to not rely on databases or signature files. A whitelist of "known good" apps has the same problem, keeping it updated, even if it was just windows. If all windows were whitelisted, that would have included things like WGA, which most wouldn't call desirable. Having all windows executables allowed isn't completely desirable either, especially when parent-child dependencies are figured in. Which executables should be given access to regedit.exe, msconfig, or rpcss.exe?

See if these 2 threads help with your rule questions.
http://www.wilderssecurity.com/showthread.php?t=151703
http://www.wilderssecurity.com/showthread.php?t=153560

Rick

[Pedro]

herbalist: i mean normal windows operations. And if it came with the rules set, they had to be a safe approach, coming from SSM themselves. They couldn't put rules that were unsafe. Like explorer opening IE. Yes allow! Just close explorer from being used.

[ogodei]

-{ Quote: "Anyway how do you choose between allow/block & create a permanent rule for SSM." }-

I think that it is easier to know what to do if you gather some intelligence first. You can use Spy-the-spy (http://www.wilderssecurity.com/showthread.php?t=159567) to watch system32 and program files folders and know what executables and DLLs have landed there. With this data you can take the folowing actions:
Did the file landed on system32 or program files folders out of the blue and SSM is asking what to do? -> Block. Are you instaling a software? -> Go to 2. If SSM is asking for rules to run an executable or DLL injection and if the files belongs to the same application -> Allow. If the executables or DLLs do not belong to the same application -> Block. Go to 3. If the software doesn't work as expected, google the alert message.

Concerning hooks, I think that they are acceptable if the application only tries to run their own executables, do not DLL inject foreign DLLs, do not phone home and do not try to do anything nastier.

If I'm overlooking something, please elicit me.

[Paranoid2000]

-{ Quote: "Note! SSM should include a data base of known threats, & should a SSM alert match the database, easy denial could be done. I guess this would be like adding a 'white or black list' to SSM." }-What you're asking for is basically an anti-virus scanner. SSM does not do this but it does provide the option to use a scanner to check any prompted file (under SSM Preferences/Options/Antivirus). This is best used with a backup "on demand" scanner you have installed since your primary one will most likely already have scanned the file triggering the SSM alert the instance it was accessed.-{ Quote: "herbalist: i mean normal windows operations. And if it came with the rules set, they had to be a safe approach, coming from SSM themselves. They couldn't put rules that were unsafe. Like explorer opening IE. Yes allow! Just close explorer from being used." }-The problem here is that it isn't possible in many cases to define "safe" or "unsafe" since it comes down to (a) the version of Windows and other software used and (b) user preferences. RunDLL is a good example - this should only be allowed with the "command parameters" option for legitimate actions (accessing some Control Panel options, removing hardware, etc) but since it can be used to run anything (including installing undesireable software - such as New.Net (http://cexx.org/newnet.htm)) it shouldn't be allowed to run automatically. Network access is another one - user X may be happy to have Internet Explorer given access but for Y, who exclusively uses Opera or Firefox, an IE access prompt would be a good sign of something nefarious going on.

[Pedro]

-{ Quote: "The problem here is that it isn't possible in many cases to define "safe" or "unsafe" since it comes down to (a) the version of Windows and other software used and (b) user preferences. RunDLL is a good example - this should only be allowed with the "command parameters" option for legitimate actions (accessing some Control Panel options, removing hardware, etc) but since it can be used to run anything (including installing undesireable software - such as New.Net (http://cexx.org/newnet.htm)) it shouldn't be allowed to run automatically. Network access is another one - user X may be happy to have Internet Explorer given access but for Y, who exclusively uses Opera or Firefox, an IE access prompt would be a good sign of something nefarious going on." }-

Point taken. But note that what i'm saying would be an option at installation, possibly with a wizard to answer some questions like "do you use IE?".
Hard to do, but...