Ah. I see. I was thinking only of one part of this argument (the application trying to spawn new rouge processes), not the idea of the application becoming rouge itself.
The first comment of the blog post[0] is excellent. And pretty much answers my main questions: "First, you have to pay attention to exploits that inject code into running processes. Since these processes are already running in memory, the whitelister will not pick up on the overflow. So, patching of those high risk network services still needs to be a priority. However, you will see if the exploit is blocked while attempting to create new files or processes, which helps in determining if you are infected. Second, never ever never ever put the whitelist on unless you are absolutely sure you are finished with the box. Otherwise, you will have to back out and reapply, which can take a good deal of time. Lack of proper planning will hurt you with whitelisting. Since most owners are concerned about time spent on security controls, they should be requiring a detailed game plan when implementing and managing a whitelisted set of systems. And “reapply whitelist” should always be the very last step. Third, unintended consequences. I’ve personally had an experience where we set up a trusted account to apply patches, and the whitelister flaked. It refused to apply the patches because of the way the patches invoked permissions from other (non protected) accounts. Very annoying, and since we didn’t want to add those accounts to the ‘allowed’ list, we had to back out of the whitelist, patch, regenerate, and reapply. Proper testing should pick out this issue before it hits production, but there are many ways to install a patch that could cause this type of situation. Fourth, in order to run certain kinds of vulnerability assessments, especially third party ones with custom tools, the whitelister must be disabled to allow tools to be loaded on the machine. This means that you are opening the system up to an outside party, so make absolutely sure they aren’t infected. With the whitelister turned off, owners need to realize they are at the mercy of the 3rd party’s security. And when the 3rd party is finished, you may have to regenerate a whitelist, bringing the newly loaded viruses into the ‘allowed’ list. So, owners should put procedures in place for 3rd party interaction with the system to minimize this very real risk. Michael Toecker Burns & McDonnell" [0]: http://www.digitalbond.com/index.php/2009/09/21/another-look-at-application-whitelisting-in-control-systems/ On Fri, Oct 9, 2009 at 2:25 AM, <da...@lang.hm> wrote: > On Thu, 8 Oct 2009, Joseph Kern wrote: > > On Thu, Oct 8, 2009 at 12:48 AM, <da...@lang.hm> wrote: >> >>> On Wed, 7 Oct 2009, Joseph Kern wrote: >>> >>> Does anyone have experience with using application whitelisting on >>>> user workstations? This would be used instead of anti-virus. >>>> >>> >>> the problem with doing this _instead_ of AV is that many vunerabilities >>> come >>> through 'data' files, and then go on to infect legitimate files. >>> >> >> *narrows eyes* are you sure about this? I thought the execution of all >> code had to be "vetted". This would include even errant chunks of >> overflows ... I thought. >> > > possibly we are using different defintions for whitelisting. > > I am thinking that you would whitelist particular binaries (say firefox or > acroread) and then allow those to execute (doing whatever it is that they > do) > > since both of these apps have had vunerabilities that will let the attacker > execute arbatrary code by feeding them invalid files you hve not solved the > problem yet. > > if you re using whitelisting to mean 'firefox is allowed to read these > files, and write to those files' or something like this you may have a > chance, but that's a lot further than I would have thought the term would > mean. If that is what you mean, then you need to write a custom SELinux (or > equivalent) policy for every application on your system. It will need to be > significantly tighter than what any linux distro currently uses. > > David Lang > > > so just whitelisting isn't going to be enough, you are going to also need >>> to >>> do tamper detection (tripwire or equivalent) >>> >>> >>> you also are going to have to figure out how to deal with users wanting >>> to >>> install things like browser toolbars and plugins. >>> >> >> Users aren't allowed to anyway. So this isn't a problem. >> >> >>> David Lang >>> >>> Any help or opinions will be most welcome. I am interested in doing a >>>> few experiments, and comparing different products. I want to test the >>>> complexity and viability of using a whitelist on a single workstation >>>> instead of an AV product that needs updating. >>>> >>>> It seems to be hard even locating free demos of any software. I've >>>> been googling around a bit, but real opinions are more valuable than >>>> white papers. >>>> >>>> 1. What whitelisting applications have you tried? >>>> 2. What did you like? >>>> 3. What did you dislike? >>>> >>>> Thanks. >>>> >>>> -- Joseph Kern >>>> _______________________________________________ >>>> Discuss mailing list >>>> Discuss@lopsa.org >>>> http://lopsa.org/cgi-bin/mailman/listinfo/discuss >>>> This list provided by the League of Professional System Administrators >>>> http://lopsa.org/ >>>> >>>> >>> >>
_______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
