Request to share SSM knowledge

Hi guys,

I noticed that a two poster are asking about SSM (Edie TH, William P). Surely there must be a lot pf people using SSM. The nice thing about SSM is granular control you have. Down side it asks a lot of user intervention and knowledge to configurate.

So I was wondering, would experience users of SSM be willing to share their settings. For instance starting with the application/process list.

In this way this forum will evaluate from sharing experience to sharing knowledge. The idea would be to share your settings (memory, parent-child control, modification, etc) to discover the set which has a tight setting and is still usable without intervention in steady state (thus not installing new programs).

Regards Kees

 

Kees ,I certainly would appreciate any shared knowledge that we could get on SSM. It may be that SSM doesn't need any tweeking?

 

Sharing settings isn't as straightforward as it would be with firewall rules or filtering software like Proxomitron. The operating system verion and software being used greatly affect the settings. I'm using Win98 and the free version of SSM. The paid version doesn't work on the older systems. My settings won't do an XP user much good. Mine has a different set of options on the applications tab than the ones shown in the image WilliamP posted. More than anything else, the users level of skill and system knowlege come into play, more so than with any other security app I've seen. I use the "Block everything" setting, not a setting I'd recommend to anyone who doesn't know their system very well. Using the "block everything" setting will greatly increase the number of alerts the user gets, many of which the average user won't really understand.
I'm out of time this morning, on my way to work. I'll try to give you something more detailed tonite.
Rick

 

SSM needs tweaking to match both the operating system/software and the user. There is no single best way to approach setting it up that's ideal for every user. An experienced user who knows their system can choose to make the ruleset manually. An average to inexperienced user would be better off using the learning mode initially. For anyone who wants to use the learning mode, make absolutely certain that your system clean, completely free of viruses, malware, etc. The ideal method would be to start with a fresh formatting. The next best thing is to use every scanning tool and site you can get. If there's any malware running on your system while learning mode is in use, rules will be automatically made that will permit it, and under certain circumstances, SSM could end up protecting it.
My ruleset was made on a much earlier version of SSM, when it didn't have a learning mode. I used Process Explorer to help get all the parent-child dependencies set. It's "process tree" view makes it easy to see what everything's parent and child processes are. I started SSM in the "block process creation" mode, no password (just gets in the way this early in the setup), UI set to connect automatically. Once my system was running, I started SSM, opened the process monitor screen, then clicked on "trust all". I then opened each rules advanced properties screen separately, and changed the default actions for both parent and child to "Ask" on all of them. At this point, each rule in the ruleset was a running process that had its parent process displayed in Process Explorer, along with any child process that each one parented. I edited the advanced properties for each to match what was displayed by Process Explorer. Then I enabled the "start automatically" option and rebooted. Had to edit rules to accomodate the shutdown process From this point on, any new process was allowed only for the parent process that was launching it. Rebooted again. Repeated this until a full shutdown/restart could complete with no prompts. Switched to paranoid mode (block everything) and repeated. Went back thru the existing rules, changing any "allow" settings I found on the advanced properties screens to "Ask". Rebooted. Once I could reboot in the "block everything" setting with no prompts, I disconnected the UI, disabled the "connect UI at startup" option and rebooted. This covered the basic system processes. After this, it was a matter of launching each process, permitting it for that parent only, then editing its advanced options to ask. I went thru all tha apps I used, launching each one using whatever would normally be used to launch it. Windows Explorer launches most apps, but so do other processes. The browser can launch a media player, IM program, download manager, etc. The IM software and download manager can launch the AV scanner. The different AV components launch each other, depending on just what your doing. In each instance, I permitted only what parent-child was asked for, no more. Office software, CD/DVD burning, AVs, and other software that uses multiple executables need extra work. make sure you use each function from every location it can be used from. With CD burning software for example, different executables may be used for data and music burning. Ripping may use separate ones. Rules for DOS apps and command line can get interesting to put it mildly. Some apps can be both the parent and child of another instance of the same application.
Any time I received an alert about a hook, I used the "block this time" option to see how the app behaved without the hook. If it worked properly, I blocked the hook permanently. On the modules, I changed the default actions for the start menu and Internet Explorer modules to "Block changes".
This took the better part of a day to complete on my 98 box. I left the UI connected for the next week or so. Prompts were few but there were parent-child combinations I didn't think of that I eventually ran accross. When I didn't see any alerts for several days, I disconnected the UI.
Compared to using the learning mode or just the "block process creation" mode, this is a slower process. The ruleset that results permits only those processes you allowed to be started by processes that you already used to start them during the setup. Everythings allowed parent processes are specified, as are all the processes that each one is allowed to start. Depending on whether you run SSM with the UI connected, you'll either be prompted when anything more than what you permitted is attempted, or it'll be blocked if you leave the UI disconnected.
There's lots more that could be covered, like permissions for library files and drivers, services, other process options like blocking termination, keeping process in memory, etc. Without knowing specifically what operating system and software are in use, plus what the individual users preferences and skill level are, I can't really be any more specific. I can say this much though. You'll make your strongest and most secure ruleset by permitting only what each process actually needs and no more. Just because a process asks for something, such as a hook, doesn't necessarilymean that it won't function without it. When it doubt, use the "Block this time" or "allow this time" as see what happens. You can always edit a rule to tighten it even more later.
Rick

 

Herb you might consider breaking that all into more readable chunks.

 

Herbalist,

Thanks for you effort.

The reason for asking was when I tried SSM. I first used it in learning mode. For some reason all processes picked up in learning mode, got very 'wide' rights (memory, parent-child, ect).

Next I started to restrict rights by tracking the processes individually (your tip of using a process explorer would have saved time). After two hours I thought hell with it, the sun is shining I am going to ride on my bike.

I still like SSM much, so the request was also for my convienance.

Regards

 

I'll see if I can edit it and clean it up some.