Tag Archives: pci dss

Barclaycard Risk Reduction Programme Position Statement

risk, , , , , ,

Barclaycard has issued the following positioning statement regarding the Barclaycard Risk Reduction Programme and it’s relationship with the PCI DSS and participating card schemes (Visa, Mastercard, Amex).

If you’re a Barclaycard merchant participating in the BRRP, this positioning statement may be of interest to you. If you’d like to find our more about the BRRP, you should contact Barclaycard directly. Further information from www.barclaycard.co.uk/pcidss

Here’s the statement in full.

The Barclaycard Risk Reduction Programme (BRRP) is a prioritised risk-based based methodology designed to assist merchants in attaining or maintaining PCI DSS compliance within the context of their wider risk mitigation and governance requirements. All Card Scheme requirements and reporting needs with regard to PCI DSS compliance remain a stipulated requirement of all merchants participating in the programme.

The BRRP enforces the full intent of each PCI DSS requirements as there is a desired goal to have consistent implementation of PCI standards across the globe. The BRRP is aimed at merchants as a means of reducing risk in the quickest manner when on their journey towards full compliance. This approach can be used to aid the completion of the PCI SSC Prioritized Approach, as required by the Card Schemes and relevant mandates and continues to require quarterly progress according to existing card scheme requirements.

The BRRP does not remove the obligation of merchants to ensure that particular PCI DSS requirements will be eventually “in place”. In addition, the BRRP methodology is in line with the recent PCI SSC guidelines on Risk Assessment https://www.pcisecuritystandards.org/documents/PCI_DSS_Risk_Assmt_Guidelines_v1.pdf.

Therefore merchants on the BRRP that are multi-acquired/ multi-scheme will continue to report according to existing requirements (milestone approach, as delivered by the GRC tool), and in addition, for Barclaycard only, will also report quarterly on risk reduction activities.

As ever, please contact us if you have any questions regarding the above.

Mastercard Best Practices for Mobile POS Acceptance

mobile, p2pe, pci dss, risk, smartphone, , , , ,

Mastercard has released “Mastercard Best Practices for Mobile Point of Sale Acceptance”.

If you’re a POS solution developer, you’ll be interested in this document as it provides guidance on how to develop your solution, and if you’re a merchant, it provides you with guidance on the kinds of features your intended mobile POS implementation should support.

Solution developers are strongly advised to adhere to the P2PE (point to point encryption) standard – a message that comes as no surprise given the cross-brand endorsement of the P2PE standard. Read the P2PE FAQ for more information about the standard.

Download the Mastercard PDF document here.

 

Approved Scanning Vendor

ASV Scan Interference

Just a reminder of a regular observation we make when conducting ASV scans. It’s the issue of interference from an IDS or IPS system. Whilst such systems are useful in normal production situations, they must not interfere in any way with the ASV scan. If interference is detected by the ASV scan – we have no choice but to issue a failing scan report.

This mandatory requirement is documented in the ASV Program Guide v1.0 on page 14 in the section entitled “Perform a Scan without Interference from IDS/IPS” as follows:

In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from intrusion detection systems (IDSs) or intrusion prevention systems (IPSs). Such active protection systems may react differently to an automated scanning solution than they would react to a targeted hacker attack, which could cause inaccuracies in the scan report.

This is part of the defense-in-depth approach of PCI DSS. If the scan cannot detect vulnerabilities on Internet-facing systems because the scan is blocked by an IDS/IPS, those vulnerabilities will remain uncorrected and may be exploited if the IDS/IPS changes or fails. If an ASV detects that an IDS/IPS has blocked or filtered a scan, then the ASV is required to fail the scan as inconclusive. All ASV scans must be validated by the ASV to ensure they have not been blocked or filtered by an IDS/IPS.

The upshot is that if you have an IDS/IPS system in place, you are required to grant full access for the ASV scanner.

The full ASV program guide is available here.

PCI E-Learning Courses

pci dss, training, ,

Announcing the availability of PCI Tutor – comprehensive e-learning for PCI DSS. It consists of a number of courses and is ideal for all levels of interest in the subject. This ranges from technical training for database and system administrators, project driven considerations for managers and non-technical, practical advice for payment operators.

The creation of these courses has been driven entirely by customer demand, and we believe they’re unique in how they cater for the wide range of expectations and skills required by staff needing to understand and comply with PCI DSS.

You can find out all the details at www.pcitutor.com

GWBHFX6BAWSN

Risk Assessment Guidelines Information Supplement

pci dss, risk, ,

You might be interested to read the recently published output from the PCI Risk Assessment SIG (Special Interest Group). There’s guidance in there on what constitutes a risk assessment process, and what it should cover. The document makes specific reference to PCI DSS requirement 12.1.2:

“12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)”

You can get a copy from here.

If you’re interested in contributing to a PCI SSC SIG in the future, then you can do so as a Participating Organisation (PO). More information on becoming a PO is available here.

Credit Cards

Cut-off dates for Visa Europe web listing

pci dss, , ,

This update concerns Level 1 Service Providers (member agents).

We just had an update from Visa Europe regarding the final cut-off dates for the December web listing. Normally, this is the 15th of the month (for listing during the same month).

However, to accommodate the Christmas holidays, the cut-off for December will be Friday 7th December. So, you’ll need to ensure that your QSA  has submitted your documentation on or before the 7th December.

Terminology & Mastercard Service Provider Registration

pci dss, , , ,

If you’re a service provider, you’ll want to read this information from Mastercard about registering with them as a PCI compliant service provider. But before you read it, it’s worth having a brief tour around some relevant terminology.

If you’re a Merchant, you may find this interesting anyway, especially if the PCI compliance and registration of your service providers is something you need to know more about.

Note that this is information from Mastercard, which is a single global brand, as distinct from Visa, which has numerous regional organisations. Visa has it’s own registration process, which I’ve talked about previously.

Terminology between card brands differs too. For example, when we say “Service Provider”, Visa Europe says “Agent” and Mastercard says “Member Service Provider”. Furthermore, Mastercard MSPs fall in to two categories: Third Party Processors (TPPs) and Data Storage Entities (DSEs).

Just to round things off, you should also know that both Mastercard and Visa have different names for their card data security programmes. Visa Inc. has the “Cardholder Information Security Program” (CIS), Visa Europe has the “Account Information Security Program” (AIS). Mastercard has the “Site Data Protection” program (SDP).

Fortunately, all of these programmes are aligned with the PCI DSS.

One last point before you read the message below; a “member bank” refers to a bank that is a member of a card scheme such as Visa or Mastercard. The bank will often be a card acquirer (“acquiring bank”) or card issuer (“issuing bank”), or both. Other organisations can be scheme members too, but that’s a subject for another day.

I think that’s enough terminology for now.

To summarise, if you’re a service provider, you’ve been assessed by a QSA, and you now want to be listed on the Mastercard list of compliant service providers, here’s what you need to know. This is quoted directly from our conversations with the Mastercard compliance team.

“MasterCard requires that the newly identified entity first register as an MSP (Member Service Provider) with the MSP registration team here at MasterCard (member_service_provider@mastercard.com). Note that only one or more of our member banks can enter them into our system. If they have a direct relationship with one or more of our member banks, they should contact each one for separate registration. If they do not have a direct relationship with one or more of our members, they would need to get sponsorship from their customer’s bank to get set up (this may be either a merchant or another processor, such as a Third Party Processor – many of which have direct relationships with our banks).

Note that the Attestation of Compliance (or Certificate of Validation) is submitted only once annually to satisfy the PCI Compliance side of the process. The team which runs MSP registration is separate from the Site Data Protection Program / PCI Compliance group. They can be contacted at the address noted above. Service Providers fall into one of two categories with MasterCard (TPPs and DSEs). More information can be found here:

Please note: As of October 1, 2010, MasterCard will only list those Service Providers that are also registered and approved as a MSP (Member Service Provider) with the MasterCard Registration Program (MRP) and who have also successfully completed an annual onsite assessment and submitted the AOC.”

Note that Ambersail cannot register you with a member bank – you’re most likely to achieve this by speaking with one of your service customers, and asking them to contact their acquiring bank concerning service provider/agent registration purposes.

New QIR Program for Integrators and Resellers

pa dss, pci dss

If you’re an integrator or reseller of a PA-DSS application or a PA-DSS software vendor implementing PA DSS applications within the merchant environment, then this will be of interest to you.

The PCI SSC has announced the Qualified Integrators and Resellers program. This will train and certify software integrators and resellers on the secure installation and maintenance of validated PA DSS applications.

The program is a response to market demand for guidelines for integrators and resellers, as well as challenges with secure installation and configuration of payment applications.

Training will take place later this summer, and a global list of certified organisations will be available thereafter.

Links:

The QIR Program: https://www.pcisecuritystandards.org/qir
Press Release: https://www.pcisecuritystandards.org/pdfs/pr_120510_qir.pdf

PCI DSS Mandatory Risk Ranking

pci dss, ,

PCI requirement 6.2 “Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities” includes the additional note:

“The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.”

As the summer (at least in the Northern Hemisphere) is almost upon us, this seems like a good time to remind ourselves what this deadline means to your PCI compliance activities.

Here are the details, as supplied by the PCI SSC.

1. After June 30, 2012, organizations will be required to assign risk rankings to newly detected vulnerabilities affecting the CDE as part of the ongoing vulnerability identification process established in Requirement 6.2. Guidelines for classifying risk are provided by the Council as follows:

  • Risk ranking systems should be based upon industry standards or best practices.
  • The risk ranking assignment should classify risk in a manner which facilitates prioritisation for remediation. (Example: High, Medium, Low)

2. When application development is in scope of an entity’s CDE, Requirement 6.5.6 will necessitate testing against the vulnerabilities classified as “high” risk as part of the secure application development process.

3. Additional Testing Procedures are indirectly affected by the cutoff date and include:

2.2.b: Updating of system configuration standards as new vulnerabilities are identified
10.4.a: Vulnerability identification in time synchronization technologies
11.2.1.b: Internal vulnerability scanning relative to vulnerabilities classified as “high”
11.2.3.b: Internal vulnerability scanning relative to vulnerabilities classified as “high”

Bear in mind that if you are undergoing an assessment after June 30th this year, there will be additional requirements to meet regarding the above.