Saturday, 7 June 2008

"PCI compliance only covers in-scope systems which handle, store, or process CC# data."

True in a way, but not really. Remember that these have to be isolated in PCI. The problem is that people take the points in PCI in isolation to the requirements statement. This is a bad approach. The points are designed to support the requirement, not the other way around.

"This isn't a failure of being compliant but a failure of the compliance scope itself."

Again, it is a failure in testing and understanding. In an attempt to meet the "points" in PCI, people miss the aim of the requirements. This includes most parties who are testing it.

This is a serious problem. If the example is taken where the failure occurred due to client system breaches, remember the first requirement of PCI:

"Firewalls are computer devices that control computer traffic allowed into and out of a company’s network, as well as traffic into more sensitive areas within a company’s internal network. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.

All systems must be protected from unauthorized access from the Internet, whether entering the system as e-commerce, employees’ Internet-based access through desktop browsers, or employees’ e-mail access. Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network."

First compliance is a legal term of art that has been bastardised into normal parlance. Think as a lawyer when reading compliance statements as it is a lawyer who will run the case when a breach occurs.

The statement needs to be the first and foremost goal. To be compliant, you need to ensure that " All systems must be protected from unauthorized access from the Internet, whether entering the system as e-commerce, employees’ Internet-based access through desktop browsers, or employees’ e-mail access."

Clearly, when a breach occurs as an employee opened a link to a malware site, the system is NOT compliant. To have been compliant, the system would have needed controls. PCI systems would have needed to have been on a separate network to the user, or controls to stop this being possible needed to be in place.

Where people go wrong is that they assume that because the tick off the points one by one (in this case 1.1 to 1.5) that this in itself makes them compliant.

This may have you pass an audit, but passing an audit is not compliance. The initial requirement statement is exponentially more critical then the sub-points and I think this is where people go wrong. They believe that ticking the boxes is compliant and not needing the main goal.

I can configure systems that will meet all of the sub-points in the PCI requirements. I can also do this in a manner that make not a one of the Requirement statements.

Too often people seek the easiest manner to tick the boxes, but this is rarely a way to have any hope at being compliant.

Truthfully, PCI-DSS is the LEAST of the requirements that people need to be concerned about. In Australia, Canada, UK, US and several other countries there is legislation about the integrity and confidentiality of financial data.

As an example, in Australia, the Privacy Commissioner has issued Tax File Number Guidelines under s.17 of the Privacy Act. The Guidelines are legally binding. A breach amounts to an interference with the privacy of an individual, who may complain to the Privacy Commissioner and, where appropriate, seek compensation. There are also possible criminal sanctions for company directors and these are strict liability.

In particular, taken from the attached Tax File Guidelines:

"6. Storage, security and disposal of tax file number information
6.1 Tax file number recipients shall ensure:
(a) that tax file number information is protected, by such security safeguards as it is reasonable in the circumstances to take, to prevent loss, unauthorised access, use, modification or disclosure, and other misuse; and

Commissioner’s note: Tax file number recipients need to be aware that tax file number information handling procedures and safeguards should anticipate all reasonably foreseeable risks to security. Some examples of tax file number security are physical and logical barriers such as building security, locked filing cabinets, user identity checks and password controls for computer systems."


This is "all reasonably foreseeable risks to security". This covers most of the means stated to make a breach. These days it is even arguable that some defence against zero day attacks is necessary. These are after all becoming more and more common- making them "reasonably foreseeable".

PCI is only a fine. There are criminal offences for not protecting data in ALL of the above (and many other) countries.

As I have stated, the best thing companies have going for them is a lake of understanding of IT by prosecuting attorneys at the moment, but this is changing.

1 comment:

pci compliance said...

"PCI compliance only covers in-scope systems which handle, store, or process CC# data.""