Quote from: Keyur on June 29, 2011, 06:07:53 PM

Quote from: error on June 29, 2011, 05:26:59 PM

I've done PCI compliance stuff for Free Talk Live; I'd be happy to review your report in strict confidence and offer my opinion.

The Gods have spoken to us! Thank you error - PMing you.

OK, my opinion is as follows. If you find it too long, there's a brief summary at the end. In the interest of full disclosure I must say that I signed up for Camp BX today, just like many of you, though I have yet to make any trades there.

Keyur sent me a copy of a McAfee security report dated June 30, 2011, for review. McAfee generates several types of reports after each scan. The report provided was the "Executive Report." This report states whether the site scan passed or failed and gives an explanation and summary of the results. This comprised the first four pages. The next 726 pages of the 730-page document listed all of the tests that McAfee may perform on a server, though without specific results. In short, this version of the report was designed to beat clueless CIOs over the head with and to keep the company lawyers quiet.

The results showed that the site passed scanning, with 29 severity 1 issues, and no issues of severity 2, 3, 4 or 5. An explanation within the report states that in order to maintain PCI compliance, the site must have no issues of severity 3 or higher. (Severity 1 issues are typically pointless blather; some examples I have seen elsewhere are: "Your site has a DNS server," "Your site is running Drupal" etc.)

The report provided did not give specific information as to the issues identified. This information is in a separate technical report. I asked Keyur for a copy of this report, explaining that my opinion would be limited without it. Today he contacted me and stated that he would not provide a copy of the technical report as it contains server information that he did not want to be available outside his organization, even under a confidentiality agreement. This is quite understandable.

Now for some background.

When one of these security scans identifies an issue, this is what happens. Let's say for instance that you have an SSH daemon running on your server. You almost certainly will, since this is how your administrators will make a remote connection to do normal system administration stuff. McAfee or whoever will connect to the SSH daemon and check its version, and then check the version number against known vulnerabilities. If the version number is one that's known to be vulnerable, then you get an issue. Depending on the specific vulnerability it could be anywhere from severity 2 to 5, where 2 is not very serious and 5 is fix this yesterday or you're going to be pwn3d.

So this issue pops into your next report and you have to deal with it immediately or lose your certification. In the case of the SSH daemon, the original authors of the daemon patched the issue and released a new version. Now if you were smart and bought an off the shelf Linux distribution like Red Hat Enterprise, then you are mostly guaranteed that versions of various critical software on your system won't change for the lifetime of the distribution. It will always have the specific version number of the SSH daemon (and anything else on the system). Enterprise distributions lock versions in this way to guarantee that various APIs and ABIs don't change and break the applications you deploy. So Red Hat will take the security patch from the SSH daemon, leave the rest, and give you a patched SSH daemon with the same version number, and only the security patch applied.

But this is a problem for McAfee since they really don't know you've applied such an update (known as a backported patch) unless you tell them. So one of the ways you can resolve that issue and keep your compliance is to tell them you upgraded your SSH daemon to the patched version that Red Hat provided you. The trick here is that this may or may not be true and McAfee has no way of knowing from an external scan, without actually attempting to exploit the vulnerability! I don't believe that any of the security scanning services go this far with system daemons (though they do with web app security such as SQL injection), as attempting to exploit some vulnerabilities can disrupt production servers.

TL;DR:

It appears that Camp BX is being responsible with server security. The report provided to me showed that it passed McAfee SECURE and PCI compliance. Keyur has also told me that his team responds to anything of severity 2 or higher within 72 hours. (Severity 1 "issues" typically are merely informational.) However, the external security scan services themselves have limitations, in that some of the information necessary to determine whether site services are vulnerable is self-reported rather than being scanned. This is a limitation of all such services. I can offer no informed opinion on whether Camp BX's system administrators are actually applying system updates from the operating system vendor, or on what schedule, as this information was not provided to me.

This actually took some time and a bit of work. If you found it helpful, feel free to send some BTC or fractions thereof to 15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W .