August 7th, 2011 by peter.bassill

Compliance does not equal security.

September 22nd, 2009 by peter.bassill

Does it really matter how you record the results of your monthly checks as long as you can prove they have been carried out, and exactly what is the usefullness of keeping the raw data from your wireless scan reports when it shows over 190 access points that are triangulated outside of your buildings?

These questionsare an example of a number of other very similar questions posed to a QSA who was of the opinion that if you can only show that you have carried out the tests but not show the full output of the tests then that QSA deemed the test to have not been run to the intent of the PCI standard and failes the requirements. Looking within my own environment, and taking into account just one site, a single days full report output equates to 21MB. Not much I know, but then multiplied by the days in the year and then again for the number of sites that is a lof of data which is of use to no-one.

Oddly, a lot of questions in this post revolved around wireless. In the QSA’s opinion, we have to scan every site that has a network for rouge wireless access points. Now I dont know how the retail stores are going to do this, but is there any point in doing this when the ports on your switches are administratively down? The auditors responce, which made me grin, was: Well, what if someone cut the copper, put on new ends and introduced a new switch into the environment which supported wireless? This seems to me to be a little far fetched.

September 10th, 2009 by peter.bassill

Its been a long long night and a very early morning, my mind is still racing and very baffled. It would seem, to a lowly infosec guy like me, that the people who write the PCI-DSS standards need to be clearer.  The problem all comes down to interpretation of the standard against the intent of the standard. While it is understandable that the intent of the standards can be interpreteted slightly differently depending on the view point of the person reading them, at the end of the day an audit standard should be consistant and when you are being audited you should expect to have a consistant approach taken by auditors.

For example, if you have two audits back to back, you would realistically expect both reports on compliance to be very similar and the auditors to broadly agree on the findings.

Scope is another area where there is lots of confusion. One example of scope confusion I came across recently was during one of my peers PCI-DSS audit where a Police Officer called a fraud team to discuss a series of related card frauds. Because the audit happened to be in the fraud department at the time of the call and hear the card numbers being discussed, he deamed the enterprise VOIP to be in scope despite this being an exceptional circumstance. Now, this would seem rather pointless if the intent here is to protect the phone line from intercepted then all that can be done is to protect it from the ingress point within the network. It would still be possible to intercept the call from external to the business. A great question my peer asked the auditor which I did smile at was “Do you really think the Police are PCI compliant?”

September 9th, 2009 by peter.bassill

Over the next couple of weeks I will be keeping a diary of a PCI audit. I am sure it will raise many topics of debate…

Day 1, Lesson 1:

Make sure your staff are using the same song sheet and keep the auditor away from staff who many be a little nervous in thier presences. It seems that as human as many auditors are, many people on your team and in your business may feel intimidated by an auditor, and more so by a PCI auditor. Remember, you are paying these auditors so at the end of the day, you should have the last say in who they speak to.

Day 1, Lesson 2:

Scope, Scope, Scope and scope. Need I say anymore?

Day 1, Lesson 3:

PCI auditor firms make up their own standards around virtualisation.

- The issue seems very very vague and the core argument appears to be around segmentation. Now, req 2.2.1 states that you must implement only one primary function per server but the intent of this standard can not be held up here as virtualisation failing PCI otherwise every Checkpoint VSX firewall cluster would fail PCI, as would every Crossbeam firewall chassis. The standards document itself shows that this can not be true as it clearly allows shared hosting providers to host multiple custoemrs environments on a single single. This is stated in req 2.4, shared hosting providers must protect each entities hosted environment and card data.

So, in my rather straight thinking, utilising a fully collapsed trust zone with network routing provided by a firewall such as a Cisco PIX and all DMZ’s using a vSwitch, all the network traffic would be fully isolated. Now, would the  auditor disagree?

An excellent document on Network Segmentation in Virutalized Environments is available here

July 24th, 2009 by peter.bassill

Probably the most useful tool available to the security teams out there right now is Nessus Professional Feed. At just under £800 for the year it is exceptionally good value for month and provides the flexibility to cover the vast majority of security auditing requirements you could want from a scanner. Recently I have been using it extensively for PCI scanning within our networks both internally and externally and found that the only thing that could do with further work is the reporting engine.

For in depth information on how to configure Nessus for PCI scanning, visit the tenable security blog here.