What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
On Tue, Jun 29, 2010 at 5:11 PM, Les Mikesell lesmikesell@gmail.com wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
The upstream vendor backports many fixes. The best thing to do is reference the CVE number in the changelogs. It's still wading through a lot of changelogs, but with the CVE you can find it pretty quickly.
Kwan Lowe wrote:
On Tue, Jun 29, 2010 at 5:11 PM, Les Mikesell lesmikesell@gmail.com wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
The upstream vendor backports many fixes. The best thing to do is reference the CVE number in the changelogs. It's still wading through a lot of changelogs, but with the CVE you can find it pretty quickly.
Googling the CVE # and the vendor will usually turn up the patched version or disposition quickly.
Depending on the assessment tool and how bright it is, you can adjust the settings for a more thorough scan that may reduce false positives.
Others can actually be set up to ssh into the box and verify patches.
On Tue, Jun 29, 2010 at 8:55 PM, John Jasen jjasen@realityfailure.org wrote:
Googling the CVE # and the vendor will usually turn up the patched version or disposition quickly.
An easy way to nail down CVE verifications is via http://www.redhat.com/security/data/cve/
This url allows you to search and verify CVE issues relatively quickly.
On 6/29/2010 5:11 PM, Les Mikesell wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
One of the things to do first is to find out if the client who needs the scan actually does any e-commerce on your server. Otherwise, I have found that the scans can be stopped by having your client contact their CC processing company.
It seems that RHEL is in most of these scanner's systems, however CentOS is not, so they balk at the old versions. It's really all just a big pain.
John Hinton
On Tue, Jun 29, 2010 at 5:11 PM, Les Mikesell lesmikesell@gmail.com wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
-- Les Mikesell lesmikesell@gmail.com
Have them read this: http://www.redhat.com/security/updates/backporting/?sc_cid=3093
If you're dealing with an auditor, that should be all they need as at least they can write down that you've made a conscious decision based on that information.
On Tue, Jun 29, 2010, Brian Mathis wrote:
On Tue, Jun 29, 2010 at 5:11 PM, Les Mikesell lesmikesell@gmail.com wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
-- Les Mikesell lesmikesell@gmail.com
Have them read this: http://www.redhat.com/security/updates/backporting/?sc_cid=3093
If you're dealing with an auditor, that should be all they need as at least they can write down that you've made a conscious decision based on that information.
That's assuming the auditor can read, which seems doubtful considering what I've found with Securityfocus and similar PCI testing outfits.
Bill
On 6/29/2010 4:37 PM, Bill Campbell wrote:
On Tue, Jun 29, 2010, Brian Mathis wrote:
On Tue, Jun 29, 2010 at 5:11 PM, Les Mikeselllesmikesell@gmail.com wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
Have them read this: http://www.redhat.com/security/updates/backporting/?sc_cid=3093
If you're dealing with an auditor, that should be all they need as at least they can write down that you've made a conscious decision based on that information.
That's assuming the auditor can read, which seems doubtful considering what I've found with Securityfocus and similar PCI testing outfits.
It's internal, but requires a formal response - or an application update. The test tool says:
These are the reported vulnerabilities
Apache Server 2.x Prior To 2.2.14 Multiple Vulnerabilities Apache 'mod_proxy_ftp' Wildcard Characters Cross-Site Scripting.
Apache 2.2 prior to 2.2.15 Multiple Vulnerabilities Apache Prior to Version 2.2.8 Multiple Vulnerabilities Apache Prior to Version 2.2.9 Multiple Vulnerabilities Apache Server 2.x Prior To 2.2.12 Multiple Vulnerabilities
On 06/29/2010 03:52 PM, Les Mikesell wrote:
It's internal, but requires a formal response - or an application update. The test tool says:
These are the reported vulnerabilities
Apache Server 2.x Prior To 2.2.14 Multiple Vulnerabilities Apache 'mod_proxy_ftp' Wildcard Characters Cross-Site Scripting.
Apache 2.2 prior to 2.2.15 Multiple Vulnerabilities Apache Prior to Version 2.2.8 Multiple Vulnerabilities Apache Prior to Version 2.2.9 Multiple Vulnerabilities Apache Server 2.x Prior To 2.2.12 Multiple Vulnerabilities
Start with http://httpd.apache.org/security/vulnerabilities_22.html to identify the CVE numbers. You can then match them against the fixes for Apache with rpm -qi --changelog httpd | egrep CVE
Les Mikesell wrote on Tue, 29 Jun 2010 17:52:37 -0500:
Apache Server 2.x Prior To 2.2.14 Multiple Vulnerabilities Apache 'mod_proxy_ftp' Wildcard Characters Cross-Site Scripting.
Remove that module from httpd.conf and try again. If it still gives that warning you've proven the tool is braindead. You could also just tell Apache not to add a server signature. I wonder how the tool will react to that :-) Or is run locally and scans the rpm database?
Kai
Kai Schaetzl wrote:
Les Mikesell wrote on Tue, 29 Jun 2010 17:52:37 -0500:
Apache Server 2.x Prior To 2.2.14 Multiple Vulnerabilities Apache 'mod_proxy_ftp' Wildcard Characters Cross-Site Scripting.
Remove that module from httpd.conf and try again. If it still gives that warning you've proven the tool is braindead. You could also just tell Apache not to add a server signature. I wonder how the tool will react to that :-) Or is run locally and scans the rpm database?
The first probe is remote. The guy doing it also logged into the box and checked something after I told him about the backported fixes but I haven't caught up with him about the specifics yet. He will understand what RH does, but we have to convincingly document the details for less technical folks - or update to something without CVE's. I would expect this to be a fairly common problem, though.
These boxes are running as reverse-proxies with some rewriterules but don't need to handle ftp.
Les Mikesell wrote:
Kai Schaetzl wrote:
Les Mikesell wrote on Tue, 29 Jun 2010 17:52:37 -0500:
Apache Server 2.x Prior To 2.2.14 Multiple Vulnerabilities Apache 'mod_proxy_ftp' Wildcard Characters Cross-Site Scripting.
Remove that module from httpd.conf and try again. If it still gives that warning you've proven the tool is braindead. You could also just tell Apache not to add a server signature. I wonder how the tool will react to that :-) Or is run locally and scans the rpm database?
The first probe is remote. The guy doing it also logged into the box and checked something after I told him about the backported fixes but I haven't caught up with him about the specifics yet. He will understand
what RH
does, but we have to convincingly document the details for less
technical folks
- or update to something without CVE's. I would expect this to be a fairly
common problem, though.
<snip> I understand that. We had a scan a few months ago (and theyre about to do it again), and to satisfy it, I had to turn off the h/d/ramdisks in our laser printers....
mark
On Wed, 2010-06-30 at 10:10 -0400, m.roth@5-cent.us wrote:
I understand that. We had a scan a few months ago (and theyre about to do it again), and to satisfy it, I had to turn off the h/d/ramdisks in our laser printers....
What is the point of doing a security scan under conditions that are not actually "live"?
It sounds like moving the flammable materials out before a fire inspection, then moving them right back in when the inspector leaves.
What is gained? You're no more secure than you were before the inspection, and and you're no longer running what you had running during the inspection.
Frank Cox wrote:
On Wed, 2010-06-30 at 10:10 -0400, m.roth@5-cent.us wrote:
I understand that. We had a scan a few months ago (and they're about to do it again), and to satisfy it, I had to turn off the h/d/ramdisks in our laser printers....
What is the point of doing a security scan under conditions that are not actually "live"?
It sounds like moving the flammable materials out before a fire inspection, then moving them right back in when the inspector leaves.
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
Right.
What is gained? You're no more secure than you were before the inspection, and and you're no longer running what you had running during the inspection.
They're scanning mostly based on WinDoze, and too many of them don't actually understand what they're looking for, and certainly they have *NOT* thought about what they're asking. For that matter, IMO, they didn't even read the results of their scans, just forwarded a large mass of everything that "didn't pass" to the general group responsible (or rather, they didn't even break it up to each group, just a large mess; they didn't even pay attention to what was desktop support, which is closer to being under them, directly).
Mostly for show, on their part, to look like they're Doing Something.
mark
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
The point is that the security scan is supposed to be verifying that your setup is, in fact, secure. If you change your setup before running the scan, and then change it back immediately afterward, how is that verifying that your setup is, in fact, secure? What you scanned != what you are actually using.
If your purpose is simply to check off a box on a form, why not just write the Sooper Dooper Security Scanner yourself?
int main(void) { printf("Sooper Dooper Security Scanner!\n); printf("Starting scan...\nScan completed...\nScan passed.\n" exit 0; }
You would gain just as much from that as what you're gaining right now, and it would take less effort on your part.
On Wed, Jun 30, 2010, Frank Cox wrote:
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
The point is that the security scan is supposed to be verifying that your setup is, in fact, secure. If you change your setup before running the scan, and then change it back immediately afterward, how is that verifying that your setup is, in fact, secure? What you scanned != what you are actually using.
There are fundamental problems with the PCI compliance checking that I've seen. I've had them say that sites accept SSLv2 when they explicitly don't as a real test shows (e.d. use openssl in client mode to attempt to connect using that protocol).
The one that really frosts me is that the systems we support use a combination of tcp_wrappers, swatch, and software I've written that automatically blocks IP addresses which exhibit malicious behaviour, similar to fail2ban, but using a DNSRBL to automatically block sites have been identified as attackers.
The PCI testers get blocked because of what appear to be cracking attempts, then have the gall to say that the site fails because it appears to have active firewalls. Well DUH!
Bill
Frank Cox wrote:
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
The point is that the security scan is supposed to be verifying that your setup is, in fact, secure. If you change your setup before running the scan, and then change it back immediately afterward, how is that verifying that your setup is, in fact, secure? What you scanned != what you are actually using.
If your purpose is simply to check off a box on a form, why not just write the Sooper Dooper Security Scanner yourself?
<snip>
You would gain just as much from that as what you're gaining right now, and it would take less effort on your part.
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?
To me, this indicates that they have *no* concept of what they're requiring, that they've included treating printers as though they were servers or workstations.
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.
mark
m.roth@5-cent.us wrote:
Frank Cox wrote:
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
The point is that the security scan is supposed to be verifying that your setup is, in fact, secure. If you change your setup before running the scan, and then change it back immediately afterward, how is that verifying that your setup is, in fact, secure? What you scanned != what you are actually using.
If your purpose is simply to check off a box on a form, why not just write the Sooper Dooper Security Scanner yourself?
<snip> > You would gain just as much from that as what you're gaining right now, > and it would take less effort on your part.
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?
To me, this indicates that they have *no* concept of what they're requiring, that they've included treating printers as though they were servers or workstations.
Forgive the minor nit, and hopefully not continuing the talking past each other, but modern printers have more computer resources than a smart phone, and the embedded OS is either equally as complex or an embedded braindead version of Windows.
In other words, they are assets worth protecting.
John Jasen wrote:
m.roth@5-cent.us wrote:
Frank Cox wrote:
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
<snip>
Forgive the minor nit, and hopefully not continuing the talking past each other, but modern printers have more computer resources than a smart phone, and the embedded OS is either equally as complex or an embedded braindead version of Windows.
In other words, they are assets worth protecting.
So, you're saying protection is more important than having them usable for the folks whose use they were bought for? You're saying that we should just get rid of them, and buy less capable printers that can't do as much? Even when the only way to get to the existing printers is from a system that's *inside* the firewall, and on our network? Hey, how 'bout I just unplug them from the network altogether? They'll be doorstops, but they'll be "secure".
mark
m.roth@5-cent.us wrote:
John Jasen wrote:
m.roth@5-cent.us wrote:
Frank Cox wrote:
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
<snip> > Forgive the minor nit, and hopefully not continuing the talking past > each other, but modern printers have more computer resources than a > smart phone, and the embedded OS is either equally as complex or an > embedded braindead version of Windows. > > In other words, they are assets worth protecting.
So, you're saying protection is more important than having them usable for the folks whose use they were bought for? You're saying that we should just get rid of them, and buy less capable printers that can't do as much? Even when the only way to get to the existing printers is from a system that's *inside* the firewall, and on our network? Hey, how 'bout I just unplug them from the network altogether? They'll be doorstops, but they'll be "secure".
Well, I'm a security admin, so of course protection is more important than utility! :)
But seriously, the assessment tools provide information on your environment, based on certain standard metrics. Its (HOPEFULLY! PCI compliance notwithstanding ....) up to the people who end up reading them to fix the environment, determine that its not a problem, or accept the risk that was discovered.
On 6/30/2010 8:54 PM, John Jasen wrote:
m.roth@5-cent.us wrote:
John Jasen wrote:
m.roth@5-cent.us wrote:
Frank Cox wrote:
On Wed, 2010-06-30 at 15:14 -0400, m.roth@5-cent.us wrote:
Sorry, you lost me here. I turned off all access to the h/d/ramdisk on the printers, and left it off. This, of course, slows things down a lot, but it's "Secure".
<snip>
Forgive the minor nit, and hopefully not continuing the talking past each other, but modern printers have more computer resources than a smart phone, and the embedded OS is either equally as complex or an embedded braindead version of Windows.
In other words, they are assets worth protecting.
So, you're saying protection is more important than having them usable for the folks whose use they were bought for? You're saying that we should just get rid of them, and buy less capable printers that can't do as much? Even when the only way to get to the existing printers is from a system that's *inside* the firewall, and on our network? Hey, how 'bout I just unplug them from the network altogether? They'll be doorstops, but they'll be "secure".
Well, I'm a security admin, so of course protection is more important than utility! :)
But seriously, the assessment tools provide information on your environment, based on certain standard metrics. Its (HOPEFULLY! PCI compliance notwithstanding ....) up to the people who end up reading them to fix the environment, determine that its not a problem, or accept the risk that was discovered.
Sorry to drag this back out to the front... I've been beyond busy and just now catching up.
One of the things that is blaring to me in these 'security' scans is that there is no check of passwords. We can jump through every hoop in the world to provide a 'secure' environment, yet without 'verifying' with the client a quality password and password policy, this is simply a moot point. Yes, one would hope... but if they don't check this how do they know? I have had requests for password changes to the most ignorant and guessable things. We don't allow any of our users to set their passwords, but I do wonder about these supposedly 'secure' sites.
There are also no checks on the security of the server location. Who has access to the console?
I think this whole business is simply another ploy to cost everyone a lot of money... but the 'form' gets filled out. It is absurdity at its finest! On the most secure systems, they couldn't even run their reports. The companies doing these checks are simply lining their pockets with green.
John Hinton
John Hinton wrote:
On 6/30/2010 8:54 PM, John Jasen wrote:
Well, I'm a security admin, so of course protection is more important than utility! :)
But seriously, the assessment tools provide information on your environment, based on certain standard metrics. Its (HOPEFULLY! PCI compliance notwithstanding ....) up to the people who end up reading them to fix the environment, determine that its not a problem, or accept the risk that was discovered.
Sorry to drag this back out to the front... I've been beyond busy and just now catching up.
One of the things that is blaring to me in these 'security' scans is that there is no check of passwords. We can jump through every hoop in the world to provide a 'secure' environment, yet without 'verifying' with the client a quality password and password policy, this is simply a moot point. Yes, one would hope... but if they don't check this how do they know? I have had requests for password changes to the most ignorant and guessable things. We don't allow any of our users to set their passwords, but I do wonder about these supposedly 'secure' sites.
Well, security assessment tools should just be a part of your holistic security posture. Hopefully, if passwords are a concern, you've set requirements for complex password in your authentication system, and are routinely running password scans against them.
FWIW, nessus does have a check for stupid default passwords for default accounts.
On 7/6/2010 4:49 PM, John Jasen wrote:
John Hinton wrote:
On 6/30/2010 8:54 PM, John Jasen wrote:
Well, I'm a security admin, so of course protection is more important than utility! :)
But seriously, the assessment tools provide information on your environment, based on certain standard metrics. Its (HOPEFULLY! PCI compliance notwithstanding ....) up to the people who end up reading them to fix the environment, determine that its not a problem, or accept the risk that was discovered.
Sorry to drag this back out to the front... I've been beyond busy and just now catching up.
One of the things that is blaring to me in these 'security' scans is that there is no check of passwords. We can jump through every hoop in the world to provide a 'secure' environment, yet without 'verifying' with the client a quality password and password policy, this is simply a moot point. Yes, one would hope... but if they don't check this how do they know? I have had requests for password changes to the most ignorant and guessable things. We don't allow any of our users to set their passwords, but I do wonder about these supposedly 'secure' sites.
Well, security assessment tools should just be a part of your holistic security posture. Hopefully, if passwords are a concern, you've set requirements for complex password in your authentication system, and are routinely running password scans against them.
FWIW, nessus does have a check for stupid default passwords for default accounts.
My point is these 'secuity metrics' businesses that are paid, generally by credit card companies, to do these software scans and don't ever do these most basic checks. Not that my quoted text is the name of one of these companies or anything. ;) I really feel the scans are just scams. Pun intended.
John Hinton
On Tue, Jul 06, 2010 at 05:21:36PM -0400, John Hinton wrote:
My point is these 'security metrics' businesses that are paid, generally by credit card companies, to do these software scans and don't ever do these most basic checks. Not that my quoted text is the name of one of these companies or anything. ;) I really feel the scans are just scams. Pun intended.
As devils' advocate here, yes the scans are far from thorough or complete. But there is a significant number of really insecure sites where they do flag some of that. The credit card companies aren't going for 100% perfection, any more than merchants go for 100% safety from shrinkage. They aren't trying to eliminate sites where credit card data is insecure (or stores that can be shoplifted from), just keep the incidence down to levels where they can afford to write off the losses.
Between finding real security problems sometimes, and scaring sysadmins into at least thinking about it other times, they accomplish that. Meanwhile it's a PITA for competent sysadmins, for all the reasons discussed here, because the scans are worthless against a system with a good security design, giving false positives and not probing deeply enough to improve our occasionally half-assed practices. But we're just collateral damage to them. The main aim is to knock down some portion of the really bad apples, and keep their insurers and the government happy.
Whit
On 7/6/2010 5:34 PM, Whit Blauvelt wrote:
On Tue, Jul 06, 2010 at 05:21:36PM -0400, John Hinton wrote:
My point is these 'security metrics' businesses that are paid, generally by credit card companies, to do these software scans and don't ever do these most basic checks. Not that my quoted text is the name of one of these companies or anything. ;) I really feel the scans are just scams. Pun intended.
As devils' advocate here, yes the scans are far from thorough or complete. But there is a significant number of really insecure sites where they do flag some of that. The credit card companies aren't going for 100% perfection, any more than merchants go for 100% safety from shrinkage. They aren't trying to eliminate sites where credit card data is insecure (or stores that can be shoplifted from), just keep the incidence down to levels where they can afford to write off the losses.
Between finding real security problems sometimes, and scaring sysadmins into at least thinking about it other times, they accomplish that. Meanwhile it's a PITA for competent sysadmins, for all the reasons discussed here, because the scans are worthless against a system with a good security design, giving false positives and not probing deeply enough to improve our occasionally half-assed practices. But we're just collateral damage to them. The main aim is to knock down some portion of the really bad apples, and keep their insurers and the government happy.
Whit
You are right Whit. It makes us think and that is positive.
The only other good thing I can think of in all of this, is apparently someone has figured out a way to get money out of a credit card company and that is a huge feat in itself! :) Unfortunately, we the consumers pay for that, too. :(
OK... I guess my old frustration with this is now vented.
John
On Tue, 2010-07-06 at 17:44 -0400, John Hinton wrote:
On 7/6/2010 5:34 PM, Whit Blauvelt wrote:
On Tue, Jul 06, 2010 at 05:21:36PM -0400, John Hinton wrote:
OK... I guess my old frustration with this is now vented.
John
---
Wow! Look at all the Johns on the list...
John
On Tue, 2010-07-06 at 17:44 -0400, John Hinton wrote:
On 7/6/2010 5:34 PM, Whit Blauvelt wrote: On Tue, Jul 06, 2010 at 05:21:36PM -0400, John Hinton wrote:
OK... I guess my old frustration with this is now vented.
John
---
Wow! Look at all the Johns on the list...
John
Not going there...
I'm glad you aren't all named Richard.
j/k have a nice day ;)
On 6/30/2010 4:02 PM, m.roth@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.
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 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.
Les Mikesell wrote:
On 6/30/2010 4:02 PM, m.roth@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
On 6/30/2010 4:39 PM, m.roth@5-cent.us wrote:
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.
I like the sentiment, but the people making the situation-specific rules would need to know more than the people actually doing the work which doesn't seem likely to happen. And there's some value in making everyone follow the same rules.
On Jun 30, 2010, at 6:03 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 6/30/2010 4:39 PM, m.roth@5-cent.us wrote:
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.
I like the sentiment, but the people making the situation-specific rules would need to know more than the people actually doing the work which doesn't seem likely to happen. And there's some value in making everyone follow the same rules.
Plus, one can also write up a detailed report for any given exception explaining why it is either not applicable for a given platform (including exploit test results) or that there is a definitive business reason why the exception must exist and that there are mitigating controls around it.
-Ross
On Wed, Jun 30, 2010 at 5:02 PM, m.roth@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?
The copy machine requirements are relatively recent, though the problem has been around for years. Apparently the hard drives inside the copiers store faxes and images going back for months (depends on capacity and configuration). Though I usually scoff at the latest "massive problems" that make the news, this one did have me worried. There was a TV expose' that showed how easily one could purchase a used copy machine, disassemble the hard drive, then have access to months of confidential information that got stored on the hard drive. I *never* considered that making a copy at a Kinko's could leave my private information in someone's hands.
To me, this indicates that they have *no* concept of what they're requiring, that they've included treating printers as though they were servers or workstations.
Right, the scanners rarely have any idea of what it is that they're requesting. They've often asked me for screenshots of a Putty session to "verify" that a setting is correct. In essence, they are trusting the person providing the information to comply with the requirement.
And of course the other problem is that the requirements are rather vague.
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.
For many compliance efforts, showing that a problem is mitigated by other controls is sometimes enough for compliance.
But the point is that the original poster is NOT the one running the scan. And the results of the scan (complaining about vulnerabilities based on version numbers) indicates that it is not a true 'security' scan anyway. For (almost) every CVE issued, there is a way to mitigate the risk that does not involve installing "the latest and greatest with all the new fixes". It is at best a superficial scan of the type that is sold to PHB's so they can "check the box".
I've spent a lot of hours trying to educate auditors.
On Wed, 30 Jun 2010, Frank Cox wrote:
The point is that the security scan is supposed to be verifying that your setup is, in fact, secure. If you change your setup before running the scan, and then change it back immediately afterward, how is that verifying that your setup is, in fact, secure? What you scanned != what you are actually using.
If your purpose is simply to check off a box on a form, why not just write the Sooper Dooper Security Scanner yourself?
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
For most (large) organizations, security scans have NOTHING to do with increasing security, and everything with being able to answer "Yes" to a question like "Do you regularly scan for known defects?", probably for a VISA type compliance check.
If you don't already know, you really don't want to know about data security in the medical or banking communities.
On Wed, 30 Jun 2010, Frank Cox wrote:
What is the point of doing a security scan under conditions that are not actually "live"?
It sounds like moving the flammable materials out before a fire inspection, then moving them right back in when the inspector leaves.
What is gained? You're no more secure than you were before the inspection, and and you're no longer running what you had running during the inspection.
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
Jim Wildman wrote:
On Wed, 30 Jun 2010, Frank Cox wrote:
<snip>
What is the point of doing a security scan under conditions that are not actually "live"?
It sounds like moving the flammable materials out before a fire inspection, then moving them right back in when the inspector leaves.
What is gained? You're no more secure than you were before the inspection, and and you're no longer running what you had running during the inspection.
For most (large) organizations, security scans have NOTHING to do with increasing security, and everything with being able to answer "Yes" to a question like "Do you regularly scan for known defects?", probably for a VISA type compliance check.
If you don't already know, you really don't want to know about data security in the medical or banking communities.
Heh. Heh. Heh. And don't forget the credit card community. Or the US gov't (and gov't medical community).
mark
On Tue, 29 Jun 2010, Les Mikesell wrote:
What's the correct response to a security scan that points out that apache versions below 2.2.14 have multiple known vulnerabilities? Is there an official document about what known vulnerabilities have been fixed in the RHEL/CentOS updates or do you have to wade through the changelog to try to find each thing?
I've done one of 1) grep the changelogs 2) hit up my RHT account manager 3) sent the referenced page about backports 4) asked those questioning me to demonstrate the issue 5) complained about my employer spending money on broken tools
Some combination of the above has always worked so far.
---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
-
Alex Palenschat -
Benjamin Franz -
Bill Campbell -
Brian Mathis -
Frank Cox -
Jim Perrin -
Jim Wildman -
John Hinton -
John Jasen -
JohnS -
Kai Schaetzl -
Kwan Lowe -
Les Mikesell -
m.roth＠5-cent.us -
Ross Walker -
Whit Blauvelt