Category 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.

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.

 

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.

Taming The BEAST

ASV, penetration testing, risk, security

This is a follow-up post to our previous article on the subject.

Here we offer technical assistance to those of you trying to fix the BEAST vulnerability, and offer some mitigation practices.

The problem revolves around a vulnerability identified years ago in TLSv1 and SSLv3 protocol CBC mode ciphers (the stronger ciphers). This issue was fixed in TLSv1.1 (2006) and TLSv1.2, however, adoption of these versions has been slow due to lack of any real incentive. Up until now the attack was considered unfeasible, but recent developments have made it viable and it is now a real threat. Please see the whitepaper at http://blog.tempest.com.br/static/attachments/marco-carnut/driblando-ataque-beast-com-pasme-rc4/ssl_jun21.pdf for a deatiled technical analysis of the issue.

The following articles are very useful in understanding and taming the BEAST:

https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls
http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html
http://vnhacker.blogspot.co.uk/2011/09/beast.html
https://blog.torproject.org/blog/tor-and-beast-ssl-attack
https://blogs.akamai.com/2012/05/what-you-need-to-know-about-beast.html

The current simplest way to mitigate the risk associated with this vulnerability in a secure manner and maintain compatibility between servers and clients is to prioritise TLSv1.1/TLSv1.2 CBC mode ciphers and then TLSv1.0/SSLv3 RC4 ciphers over the deprecated TLSv1.0/SSLv3 CBC mode ciphers. This should catch the majority of sessions before the minority of clients fall back to the vulnerable ciphers, thereby decreasing the likelihood of a successful attack.

The following remediation notes and references may be of use:

Apache
(taken from https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls)

SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

Windows (not including 2003 or XP)
Prioritising Schannel cipher suites is possible, please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

Windows (Older Flavours)
See the following to control which ciphers are supported:
http://support.microsoft.com/kb/245030

Windows (Recent Versions)
A patch is available:
http://technet.microsoft.com/en-us/security/bulletin/ms12-006
However, problems have arisen from this so the prioritising method may be preferred. See:
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx

OpenSSL
OpenSSL has addressed the issue, however, as the feature was found to cause problems with some SSL implementations it is disabled by default. It is also known that Tomcat, Apache mod_ssl and Exim disable the feature by default. The fix is also claimed not to work by some. (https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls). Again, prioritising ciphers therefore seems to be the only workable route.

Other Systems
Please check for vendor specific patches. Failing that, and if the prioritisation of ciphers is not an existing function, then disabling unwanted ciphers may be the only option in the short term. For a complete list of ciphers and other details, please see: http://www.openssl.org/docs/apps/ciphers.html

Utilities
For an effective way of determining supported SSL ciphers, see the following:

The online Qualys SSL test application:
https://www.ssllabs.com/ssltest

sslscan, a useful tool, can be downloaded from:
http://sourceforge.net/projects/sslscan/