Les Mikesell wrote: > On 6/30/2010 4:02 PM, m.roth at 5-cent.us wrote: >> >> Frank, I'm not sure of the object of your part of the conversation, me, >> or the security team that I have to deal with. I'm also feeling as though >> we're talking past each other. They ran the scan. My manager handed the >> response handling of it to me. As part of what I did, I had to turn off >> the laser printers access to their own h/d/ramdisk, thus afflicting the >> printers. I did not turn the access back on, so some of the capabilities >> and speed of these printerSSS is utterly wasted, and for what? Someone >> might get through the gov't firewall, and fill up the h/d on the >> printer? >> Someone might run the trays out of paper? > > Actually the problem with hd's on printer/scanner/fax machines is that > when you scrap the device, someone can pull the drives and easily > recover all the confidential info that has been through them that no one > thought about securing. You probably do have a policy about not > scrapping computers without removing or securely wiping the hard disks - > but all the same stuff ends up on the printers too. We haven't retired a printer since I've been here (only since last Aug), but I suspect there is such a policy. When we "surplus" a system, we either sanitze it to DoD standards (thanks, Darik's boot 'n' nuke), or we have it degaussed. Tapes, too, so I'd be surprised if we don't do something like that for printers. (Btw, I am only speaking for myself, not for my employer or the US gov't agency that I work at, but this *is* a US federal gov't agency.) > >> But then, they also had problems with several servers that another admin >> takes care of, complaining that they could allow certain kinds of >> access, which would be true of any *Nix variant... but don't exactly work in >> VMS. One size of security does *not* fit all. > > True, but how would you do it better from a very high level - where you > want to end up with an unbiased audit that shows best practices are > being followed? We should probably know better by now than to let You need a different scan for each kind of thing you're scanning. What's valid in one arena is *not* valid in another; either it's moot, or non-existant, or cannot occur for good and sufficient reasons. Trying one size fits all gives meaningless results if you've only built your scanner for two or three basic things. > companies/business units/administrators police themselves so you need > metrics for someone else to test with. And even internally you need to > document why the failure of any standard check should be overlooked. No, the security people should have defined requirements specifically for our environment, rather than using something that's designed, say, for a std. corporate IT dept. mark