Tag Archives: risk

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.

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.

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.