The correct security approach?

Discussion in 'other anti-malware software' started by ssj100, Aug 28, 2009.

Thread Status:
Not open for further replies.
  1. danny9

    danny9 Departed Friend

    Joined:
    Feb 18, 2004
    Posts:
    678
    Location:
    Clinton Twp. Mi
    Thanks for your input Kees.
    As usual you bring up some valid points. :thumb:

    I agree with you on low level intrusions, stack/buffer overflow and protocol errors.
    I didn't mean to come across that some common sense is a cure-all for all the ills of the internet. It's not, but can save users from some needless problems and ills.
     
  2. Osaban

    Osaban Registered Member

    Joined:
    Apr 11, 2005
    Posts:
    5,614
    Location:
    Milan and Seoul
    A very informative post particularly for people who are developing an interest in computer security. It's funny to read how many members began the security melodrama with a Norton suite (I will never forget NIS 2004)!

    When one mentions 'security' it isn't just what is blatantly destructive as a virus or a worm can be. What seems to be happening to me every other month are either configurations mistakes or conflicts which often end up crashing the system.

    Yesterday, for example, I was trying out an online storage software on my new netbook. The damn software completely paralyzed the machine and I could barely shut down and reboot in the same conditions, no way to uninstall the offending application. I'm not kidding, it took me 2 minutes to start the ShadowProtect recovery CD and 4 minutes to restore my system (XP + programs are about 10GB).

    There are things that can be prevented, but situations as the one that I've just described can only be resolved either with a complete reinstall (time consuming), an image (6 minutes), or a great knowledge in computer diagnostics (which I certainly don't have).

    I also agree there are different strategies in keeping computers in tip-top condition, it is a matter for users to choose the one most appropriate for their habits and environments.
     
  3. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    Started (wrt Windows) with ZoneAlarm Pro firewall with A/S & adblocker - the most important aspect was always "being careful" - and I never saw the need for an AV..

    Then, on a new machine, used also for business and with "a need to be able to demonstrate that I was properly securing", I also tried running with an AV and some other bits and pieces - and promptly learnt all about FP's..

    Finally, through reading more at Wilders etc than I should ever have had time for, I think I have finally properly understood the holy grail of not allowing malware (or anything unknown for that matter) to run, and understanding more clearly the means by which it might try to run..

    Hence, I now try to follow the sound advice of those on here who advocate whitelisting (ie an anti-executable or "default deny" approach rather than the "default allow / blacklist deny" of the AV world) to deny the likely points of attack from the likely sources of attack, as best as I understand them - as follows:

    1) Firewall
    2) Browser initially in default deny (Javascript, i-frames, Java, plug-ins etc), adblock, autorun disabled, macros restricted, etc..
    - [..1) and 2) should be enough most of the time]
    3) LUA / SRP / DEP etc - Provided that the admin password is not entered: Then unless it is already installed, it cannot run...
    4) Sandboxie - Just in case it does!
    5) A blacklist (AV etc), for which the best value to me is the additional opinion etc as regards something that I have already decided to trust and install, but for which an upload facility can perform equally well..

    I am sure you guys understand all this far better than me, but if whitelisting does become more "main stream" on OOTB set ups, then do blacklist products going forwards, to protect their substantial revenue streams, increasingly also act as whitelisters (or even simple HIPs), ie like an Online Armour Oasis equivalent concept alongside the existing blacklist. You might then have say four settings, if ever any program or executable tries at all to run (or download):

    1) Known malware - Deny
    2) Heuristic malware - Most likely to be bad - strongly suggest deny unless known (ie by the user) to be good
    3) Unknown - Only if you are sure?
    4) Known good program - Allow

    along with user policies available to determine whether 1) to 4) are questions for the user, predetermined allow / disallow or whatever. Hence, 3) on routine browsing could be default configured to be "prompt" blocked (or even simply auto-blocked)..

    Because of the "Known good program" list, this might even have value over the combination of "SRP (or other anti-executable) plus blacklist A/V", especially for "the practical home user" or equivalent looking for an all in one and not wanting to understand too much..?? Is this already happening with the AV (or cloud) feedback options - by collating information about what their users are running, are they effectively generating whitelists for ongoing products..??

    Peter
     
  4. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    They have been to a degree. For vendors, whitelisting has many of the same problems as blacklisting, mainly keeping that list up to date and complete. Whitelisting has to include some form of integrity checking or it's worthless. The problem arises with new versions, especially new system components introduced by Windows Update. The vendors don't get to see these files any earlier than the users do. When for example the digital signature of explorer.exe doesn't match any of the known ones, there's 2 possible reasons:
    1, It's a new version that's just been released or one that was missed.
    2, It's a malicious file with the same name that replaces the legitimate file.
    Does the vendor allow it to run?

    With the addition of some form of authentication, it would be possible to create a commercial whitelisting based security package. It would require a lot of cooperation between all software vendors to be good. Verification thhat they are clean would be another huge problem. For that reason, strong whitelist based security setups aren't likely to be mainstream. Keeping tract of all the good files is just as bad as keeping up with all of the malicious ones. Fortunately, that isn't necessary for your own system. All you have to keep tract of is the known good ones on your system, a few hundred executables or so, a very small workload in comparison.

    Whitelisting the executables is not the whole story. It's only the starting point. Legitimate files can be used maliciously. You wouldn't want your instant messaging program editing your configuration files or your browser adding/removing registry autostart keys. I wouldn't want a PDF reader launching my mail handler. All the files may be legitimate, but I don't want one routinely running the other. That's one of the primary reasons I prefer HIPS over the built in restriction tools. IMO, the ability to control what processes each one can start or be started by (parent-child settings) is important. The downside is the same as before. The user has to know or be able to determine what other executables each process needs to be able to launch in order to work properly. Rules this specific take time to create properly. Specific parent-child settings can prevent a lot of new/unknown exploit code from working properly. While most exploits will eventually want to download some type of executable payload (which can be blocked as an unknown) they often involve getting the targeted application to perform some task they wouldn't normally do. Quite often, the official patch is nothing more than a blacklisting of that specific activity. That can get almost as unlimited as the malicious files themselves. Killbits are examples of this. I'd rather whitelist the activities I need to allow than to try to keep up with what shouldn't be allowed. I should mention that I'm using unsupported operating systems and systems that are at the end of their support cycle. These require a default-deny policy in order to be used securely as conventional security applications dropped or are dropping support for them. That said, a default-deny policy will work on new systems just as well, within the limits of what the OS will allow you to control.
     
  5. wat0114

    wat0114 Guest

    Just my opinion but an approach I've fondly taken to recently:

    1. The router should always be a staple for the perimeter, even just a basic home NAT unit.
    2. Some form of application network access control: A software firewall or something like Sandboxie to restrict Internet access to selected sandboxed programs.
    3. Virtualization/sandboxing; Either a virtual guest such as Virtualbox or another or sandboxing such as Sandboxie. Better yet, combine the two which I have recently done.
    4. Use a limited account whenever possible
    5. SRP or maybe Surun to restrict software installation, especially unexpected running of executables.

    IMO it's tough to get much more bullet proof than this without sacrificing excessive system resources or usability.

    I have run some malware samples recently in the virtualbox guest and they just don't seem to have any real impact whatsoever. Maybe they don't like the combination of the virtual environment running in limited accounts on top of the host limited account, no less? Who knows, but they have not been at all successful at inflicting noticeable damage. Besides, when I'm done and just to be safe, all I have to do is revert to the current snapshot and I'm right back to a perfectly clean slate again. So easy :)
     
    Last edited by a moderator: Aug 30, 2009
  6. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    This depends on what you consider to be "sacrificing usability". On my system, SSM normally runs with the user interface (UI) disconnected. This setting corresponds to a limited user mode in which default-deny is strictly enforced. In this mode, SSM will deny anything not whitelisted and will not prompt the user. The user can't install or update anything, but everything already installed will function normally, within the restrictions set by the rest of the security policy.

    In order to install new software or to update existing software, the UI of SSM has to be connected, which requires a password. In this setting which corresponds to an administrator mode, the user is prompted for new and unknown items. Switching from one mode to the other is quick and easy (for the administrator) and can be done from each users account or profile. For users without the administrative password, it's impossible.

    On my system, I consider updating and installing software to be administrative tasks, not to be performed by the users. In other environments, this policy would be unacceptable depending on who actually owns the PC. Depending on how your system is equipped, variations of this policy are possible, such as new installs are only permitted in virtual environments, not on the host system. That would allow whoever maintains the system to evaluate the new software before installing it on the host system. This should all be part of your base security policy.

    IMO, most people approach PC security from the wrong direction. The user/administrator should first take the time to lay out that security policy and work out the details for different situations. The PCs primary role is specified. This should include separating user and administrator privilege, specific policies for installing and updating, what the default applications for different file types will be, how much (if any) access users have to the configuration of the system, software, and security package, etc. Once the policy is ironed out, then security and user software is selected that can best enforce that policy. When approached from this direction, the user is less likely to leave gaps and vulnerabilities in their security package and will cover scenarios they might not have accounted for otherwise. When the security policy is well thought out and the security software, operating system, and user software are all selected/configured to enforce it, you'll have achieved the balance between security and usability that matches your needs.
     
  7. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I wonder, if there are so many ways that make a system much more secure, as Wilders is all about, why the OS does not utilize them more? Ever thought that? I mean, I know full well that M$ 'could' roll out an OS that was rigidly secure. But then WHO would buy it? IT/Corporate only? Certainly not most of the users I help.

    I think because windows is geared towards the masses, and the masses are basic users majorily, the almighty $$ says make it as easy to use, and as easy to use with all the things the users want to use it with, aka internet gambling and flash movies/games. Don't restrict them too much or they won't spend thier $$. And then the flip side, make sure it is capable of becoming secure enough for IT but be sure to make it or it's sibling products in a way that 'encourages' staying on the windows platform.

    Maybe we should stop using money and go to the barter system with M$. Yeah, you give me Windows 7 Ultimate, and I will use it AND tell my mom and dad to barter thier favorite goat for a copy of it. And when I want to become a haxor, I will trade my favorite Bunny Wabbit for a keygen with a virii in it. But I won't have to worry about the virii because since we are bartering the windows is now as easy to use as *nix and just as safe. lol.

    Sul.
     
  8. wat0114

    wat0114 Guest

    I mean that even though I'm running primarily on a limited account, my programs work fine on it so I'm not having to constantly jump over to my admin account other than for installing software or updates or a few other occasional miscellaneous tasks.

    Sure, and I've used SSM extensively. It's a great product, low resource usage and one of my all time favourites, but it is quite possible to achieve the same restrictions you mention using SRP or Surun. Also, and unfortunately, SSM is no longer updated. However, this latter caveat is inconsequential if you don't install a patch that conflicts with it.
     
  9. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Sorry Danny I know you know, just read to many common sense replies, should have made it a seperate post.

    I also disagree that there is no correct approach, there is a common approach with different implementations. There are only two variables risk (management) and impact (or damage control) which have to be tuned to the user's knowledge and wallet.

    Regards
     
  10. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    YEP,

    I am always surprised by the limited set of options mentioned on wilders: some of the easyones are pretty much neglected in favour of the more 'shootthem/nuke them' options.

    Hardening,
    Rights restriction
    Staying out of risky area's/community watch (like WOT)
    Black listing
    Heuristics
    Anamoly or behavior analysis
    Intrusion vector control (classic HIPS)
    White listing
    Virtualisation

    Also you will see more vendors including more options in their solutions, so these discussion become less relevant anyway.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.