On 4/24/09 8:05 AM, "NM" <nico at altiva.fr> wrote: > On Thu, 23 Apr 2009 18:10:38 -0400, Ross Walker wrote: > >> How about running it as the untrusted user 'clamav'? > > How's that user going to check anything that's not o+r? How about selinux? You could make a context that allows clamav read rights to everything, and write to none. You could even develop your own PCI compliant selinux security framework that can be applied to all PCI hosts. >> I know there is a lot of boilerplate regulation out there, I have my >> fair share to deal with myself. Often hidden in the BS there is a good >> intention it just requires a little give and take. Give in to a little >> BS here to get a little break on the BS there. >> >> What the consultant should be working off of is an accurate risk >> assessment of the OS and the applications installed on it, not some dumb >> checklist. > > Yeah, well, problem is, you don't get to choose who's going to assess you. Well you can either go with the compliance flow, or you can let the compliance flow take you kicking and screaming. Either way your regulated now and there isn't anything you can do about it. It's the world we live in today I'm afraid. If you don't like the way the consultant is doing things, then after this cycle is complete, take control of the process. Do your own risk assessments on the hardware and software and develop your own PCI compliant controls that more accurately reflects the true threats and vulnerabilities of your environment instead of the "perceived" threats and vulnerabilities being used now. Having your own regular in-house risk assessment performed can only help you in both developing and supporting your decisions for which controls are applied to which systems. And even if you need a token install of anti-virus everywhere to appease the regulator gods, it isn't the end of the world. If your risk analysis of the software determines it poses a great enough risk, you can impose controls on it like I mentioned above. -Ross