The Middle East has been affected by a fourth underseas cable being cut.  I don’t think this has had any impact on the state of PCI compliance, but it could have a minor impact on any e-commerce fraud that occurred over these pipes.  No Internet = No shopping-cart hacks.

Sadly, I suppose it also affects acceptance in those areas.  All those outsourced call centers and IT departments may have a hard time accepting payments or fixing your servers remotely.

In the mean time, make sure you have your third-party contracts updated (PCI DSS requirement 12.8) and, if you are a processor or service provider, that you have all connected entities accounted for (PCI DSS requirement 12.10.)

Popularity: 13% [?]

It has come to my attention that software vendors do not fully understand their responsibilities regarding Payment Application Best Practices (PABP) compliance and their customers’ PCI Data Security Standard (DSS) compliance. PABP compliance does not automatically imply PCI DSS compliance and visa versa. What follows is a recent real-life example of how a major vendor handled this situation and how it adversely impacted their customer.

One of my clients is implementing a new point-of-sale (POS) system in one of their operations so that this operation will be PCI DSS compliant. This POS vendor is not only providing the software solution but is also providing remote management and support of the solution.

The first problem my client ran into was their demand that the contract with the vendor contain language to ensure that the vendor’s services being provided were PCI DSS compliant. The vendor explained that their software was PABP compliant and that they were therefore PCI DSS compliant. We explained that the software was only part of the equation because the vendor would be remotely administering the system and that those services needed to be PCI DSS compliant. The vendor continued to argue that their PABP compliance was all that was needed but finally relented to the PCI DSS compliance provision.

We are now assessing the implementation of the vendor’s software for revising their PCI Report On Compliance (ROC). While the software is definitely PABP compliant, we have consistently had difficulty getting information out of the vendor regarding how to assess my client’s implementation of the solution. They have finally, and very reluctantly, admitted that cardholder data (CHD) is stored encrypted on the server at each location. In very tense discussions, they have also finally relented and released the process for managing the encryption keys to my client for their management. My client was relying on the fact that since the software was PABP compliant, they would not have to worry about additional controls. However, my client now has to rapidly make implementation changes to make sure that they meet the PCI DSS requirements for data center monitoring and controls because the new solution stores CHD locally on each server.

All through this process, the vendor has been arrogant and indignant. They have repeatedly stated that as they understood the process, PABP compliance was all they needed to be compliant with all PCI processes.

This has been meant to give software vendors a relevant example of why it is so important for them to be forthcoming with all information regarding their solutions with their customers. There is important information regarding the solution that the customer needs to know so that their implementation will be PCI DSS compliant. PABP compliance means that an application properly protects, manages and controls CHD. It does not mean that your customers will not have to implement their own management procedures and controls at their end to ensure their PCI DSS compliance.

If a vendor is providing management or other services to their customers that are covered by the PCI DSS, vendors need to understand that those services are not covered by any PABP compliance process and that these services need to comply with the PCI DSS.

And this situation will not change with the introduction of the PA-DSS.

Popularity: 47% [?]

NIST released 800-48-Rev1 on 2007.08.02. Given events some recent events, the relevance of wireless security to PCI is unquestionable.

If you’d like to submit comments on 800-48, they’re due by 2007.09.14. Simply send an e-mail to 800-48comments@nist.gov with “Comments SP 800-48″ in the subject line.

Read the rest of this entry »

Popularity: 29% [?]

According to Digital Transaction News, Visa USA is ready to introduce account-level processing (ALP).

“Visa claims ALP will allow smoother transitions to new cards for cardholders, and will let merchants, in partnership with issuers, design more effective rewards programs.”

Sounds good so far, but wait there is more.

“The key change is the switch from managing transactions through the six-digit bank identification number (BIN) within a card’s 16-digit number and instead using the full account number.”

Wait a minute, did we read that right? Did they say what we thought they said? Yes they did. To paraphrase, the key change is the switch from using the six-digit BIN (3.3 compliant) and instead using the full PAN. This will just add fuel to the fire over storing the full PAN.

And it just keeps getting better.

“The new process affecting Visa-branded consumer cards will allow a credit cardholder to keep the same account number even if his issuer upgrades his card”

Yes, that is right, not only do we now encourage storing the PAN, but we are going to allow the PAN to remain the same even when the card changes. This just sounds like a way to generate even more replacement card numbers.

Does anyone think that encryption will not be critical to managing this situation? How many organizations are handling encryption properly right now? Some, but not enough. Think this will just make things worse? Probably, at least in the near term. Think the “bad guys” will take advantage of this new capability? Without a doubt.

The article goes on to say that this new approach will likely cause merchants a POS software upgrade headache to support ALP. POS software will have to be able to insert a field code, known as 62.23, in the authorization message. This field code will be a single alphabetic code that indicates the card product that was presented for the transaction.

As of October 2007, Visa will require all acquirers to be able to receive the new field code in the authorization message. Acquirers will use the code to determine the correct interchange, chargeback rights and other characteristics such as loyalty points to be accrued for each individual transaction.

Popularity: 61% [?]

The newest revision to NIST 800-44 was released on June 1st. While it’s not the complete answer, it’s certainly a useful document in the battle for web-application security.

Popularity: 36% [?]

The WSJ reports:

“The biggest known theft of credit-card numbers in history began two summers ago outside a Marshalls discount clothing store near St. Paul, Minn.

There, investigators now believe, hackers pointed a telescope-shaped antenna toward the store and used a laptop computer to decode data streaming through the air between hand-held price-checking devices, cash registers and the store’s computers. That helped them hack into the central database of Marshalls’ parent, TJX Cos. in Framingham, Mass., to repeatedly purloin information about customers.

The $17.4-billion retailer’s wireless network had less security than many people have on their home networks, and for 18 months the …”

More information here and here.

Popularity: 35% [?]

Some people have asked (and others added to the confusion) about what is required by PCI DSS regarding requirement 11.3 requiring an annual penetration test. Here are some answers to those questions?

Who?

The requirement does not specify who must perform the penetration test, but much like other requirements it can be done by virtually any party. The penetration test is typically performed by a third-party with experience in offering these services. There is NO requirement that it must be performed by the QSA or ASV. In fact, it can be performed by the entity themselves as long as they have the necessary skills and cover the appropriate areas (but this is rare.)

The responsibility of the QSA or auditor is to make sure the scope (both depth and breath) is appropriate, the methodology is in line with industry best practices, and that all high and medium risk vulnerabilities have been remediated and re-checked.

What type?

People ask what needs to be included in the penetration test and some even say that it should include things such as: war-dialing, physical security testing, social engineering (pretexting), and many other things.

PCI DSS v1.1 clearly states that it should address the following areas:

1. Network-layer penetration tests
2. Application-layer penetration tests

This means the testing should address all electronic network attacks and electronic application attacks of public facing applications. It does NOT include physical security testing or social engineering (pretexting). One thing it should include is war-dailing (checking modems) because these are methods of electronic remote access.

When?

The requirements call for an annual penetration test. This means that a report on compliance (ROC) cannot be submitted until the testing has been performed, vulnerabilities remediated, and re-checked to make sure they are no longer an issue.

It is not acceptable to include in the report that the penetration test “will be completed within one year.” It needs to be performed and the results addressed before submission of the report.

Popularity: 24% [?]

Many people have asked “Do you need to audit third-parties?”, “Where does the audit end?”, “Does a connected entity, not able to access credit card data, need to be PCI compliant?”

In a prior post we explained what a “connected entity” was; now let’s get into some of the details. When we ask questions such as those listed above, we are really asking about project scope. You need to understand that in each project the extent to which you measure any of the requirements depends mainly on how you have scoped the project initially.

Do we need to audit third-parties?

It all depends on what services they provide. For example there are two different types of third-parties: (1) those you provide data to, and (2) those you provide access to your data.

• An example in the first category would be an offsite tape backup facility (i.e. Iron Mountain). Requirement 9.5 (v1.0) state, “the off-site storage facility to determine that backup media are [securely] stored” insinuating that the off-site storage facility needed auditing, but the same requirement in v1.1 states, “Verify that offsite storage is visited periodically”. In this case we can see that it is not necessary to audit third parties such as this, but only to verify that they are conforming with the requirement.
• An example of the second category would be if a company outsourced their entire server environment to IBM global services. In this instance, you would need to interview and audit IBM staff and systems to confirm they conform to the PCI DSS compliance standards.

Where does the audit end?

The audit should be properly scoped to only include those systems that store, process, or transmit cardholder data. The scope should also include any connected entities or third-parties, but you can reduce this by firewalling off and restricting access to these companies.

If proper access controls and restrictions are put in place then they can be removed from the majority of the scope (they still need to be addressed in v1.1 requirements 2.4, 12.8, and any requirement designating Service Providers.)

With proper scoping, network architecture, and access controls there should be no need to visit third-party companies and audit them.

Does a connected entity, not able to access credit card data, need to be PCI compliant?

It all depends on how the network architecture and access controls are applied.

Let’s assume a connected entity (third-party) connects to you via a VPN and the policy on the VPN permits them access to only one system, which is does not store any credit card information.

• The problem here is that you have now extended the third-party’s network into yours. In other words, you need to treat the computer that company has access to as if it is an extension of their network. If you cannot do this then you have put a hole in your carefully secured and scoped access controls — which could expand the audit.
• A good solution would be to allow the third-party only access to one application within the computer or only access to a single directory on the computer. This will limit their access within the system and (with constant monitoring and logging of their access) you can limit the scope of the audit.

The rule of thumb is to eliminate business processes that expand the scope of the audit and the cost of compliance. If you can do this your clients/management will be happy and your job will be easier.

Popularity: 18% [?]

Many people have asked if the QSA can rely on third-party audits when performing their audit.  For example, when traversing Requirement 9 (physical security) auditors have asked if they can use a SAS-70 report instead of auditing the environment themselves.

The argument makes sense from both a business and operational perspective.  Companies want to leverage the audits they have performed in order to reduce overall costs.  If a company has a SAS-70 review of the physical security of their datacenter, they want to use that report to address all auditor’s concerns about physical security.

If the same company that performs the SAS-70 audit also performs the PCI DSS audit then it makes perfect sense to rely on those results (because the PCI auditor can review the work papers of the SAS-70 audit.)  The problem arises when two different companies perform the audits.

Company 1 performs a SAS-70 audit and Company 2 wants to rely on that audit.  This practice is discouraged, but not prohibited, because Company 2 is now stating as fact items that it has only read in a report.  Although it saves the client money, it puts the Company 2 auditors at risk due to their reliance on audit third-party audit results they have not themselves verified.

Audit companies can rely on third party audits, but should be cautious because they will be held responsible for the items they write in a report.  The moral of the story is that you should always have some work papers or evidence to back up all statements you make in the audit report (or report on compliance.)

Popularity: 14% [?]

The requirements (12.8.x) in the PCI DSS v1.0 were rather stringent for third-party contracts. They included the following requirements that were rather difficult to negotiate into contracts:

• Contract provisions include acknowledgement by the third party of their responsibility for securing cardholder data.
• Contract provisions include ownership and acceptable uses of cardholder data.
• Contract provisions include appropriate business continuity provided by the third party such that the third party’s services will be available in the event of a major disruption or failure.
• Contract provisions allow for audits by Visa or Visa-approved entities in the event of a cardholder data compromise.
• Contract provisions require continued security of cardholder data during and after contract terminations.

The revised PCI DSS v1.1 (Requirement 12.8.x) clarifies and simplifies these requirements into the following:

• Verify that the contract contains provisions requiring adherence to the PCI DSS requirements. (This is independent of their compliance status.)
• Verify that the contract contains provisions for acknowledgement by the third party of their responsibility for securing cardholder data.

Another requirement in the v1.1 has additional requirements for Processors and Service Providers. Requirement 12.10 mandates standards for managing “connected entities”.

• Maintain list of connected entities.
• Ensure proper due diligence is conducted prior to connecting an entity
• Ensure the entity is PCI DSS compliant
• Connect and disconnect entities by following an established process

Some people have asked what constitutes a “connected entity”? Why not just say “third-party”? What types of connections? What types of entities? Connected to where?

The definition of “connected entity” is exactly that; any foreign entity that is connected to the cardholder environment. In most instances a connected entity will be a connected third party, but this will vary depending on how the company has segmented their environment.

• Connected Entity as Third-Party: In most cases the reference is to third-parties such as VPN connections to acquirers/processors, network connection to vendor or client, external dedicated network connections (i.e. VPN, frame-relay, etc.)
• Connected Entity as Corporate Network: If a company segments their network such that they require 2-factor authentication from the corporate network to the cardholder data network, they are choosing to exclude the corporate network from the PCI DSS scope entirely. The assumption is made that we consider the corporate network on par with the Internet as an untrusted entity. In this case, connections from the corporate network may be considered “connected entities”.
• Connected Entity as anything else: You can see from the last example that a connected entity can be just about any “directly connected entity” and not just a third-party (although in most cases that is what it will be.)

Popularity: 26% [?]