PCI DSS Cloud Computing Guidelines

cloud, pci dss, penetration testing, ,

A new guidance document from the PCI SSC provides useful information about the use of Cloud Service Providers (CSPs) and how this may affect PCI compliance.

Although cloud computing feels like a new thing, the issues about responsibility for cardholder data are certainly not new. Related issues, such as nebulous (pun intended) statements about PCI compliance from a CSP need to be qualified, and mutual responsibilities clearly established.

Actually, this new document echoes some guidance that we’ve been publishing for a while now. Have a look at PCI Compliance Claims: 3 Questions You Must Ask for example. More recently, we published a 10 minute video entitled Penetration Testing & The Cloud, which is an ideal management introduction to the subject, even if PCI DSS isn’t on your radar.

The SSC document is available here.

ATM & E-Commerce Security Guidelines

pci dss, security, , , ,

A couple of new information supplements have been released by the PCI SSC, covering E-commerce and ATM PIN security.

“PCI DSS E-commerce Guidelines”  contains a nice summary of common E-commerce models, vulnerabilities and some recommendations too.

From the intro:

“This Information Supplement is intended for merchants who use or are considering the use of e-commerce technologies in their cardholder data environment (CDE) as well as any third-party service providers that provide e-commerce services, e-commerce products, or hosting/cloud services for merchants”

Download it from here.

If you’re developing or implementing applications for the ATM environment, you’ll be interested in this next information supplement, entitled “PCI PIN Transaction Security Point of Interaction Security Requirements”.

From the intro:

“This document proposes guidelines to mitigate the effect of attacks to ATM aimed at stealing PIN and account data. These guidelines are neither definitive nor exhaustive and are not intended to be used as requirements for a validation program at the PCI SSC.”

Download the document from here.

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.

Which Visa Europe Agent Are You?

pci dss, , ,

Or, where do I register with Visa Europe once I’ve received my completed ROC?

So you’re a service provider, you’ve been assessed by a QSA, and now you want some recognition in the form of a public listing on Visa Europe’s list of compliant service providers, or on the new Visa merchant agent listing web site.

But which route is appropriate?

The first thing to know is that Visa Europe classifies service providers as “agents”. An agent is further classified as follows:

  1. A member agent, providing services directly to a Visa Europe Member (who would be an acquiring bank or other payment processor, for example). Such services might include statement printing, card personalisation, or payment acquiring.
  2. A merchant agent, providing services directly to merchants. These services might include payment page hosting, web hosting or call centre services.

Most service providers will fit broadly in to one of the above categories. However, if you’re offering both member and merchant services, then you’re both a member agent and a merchant agent. All of your services will have been assessed, and you can therefore register as both a member and a merchant agent.

A reminder too, that this discussion relates to Visa Europe only. The same may apply to other Visa organisations, but I can’t confirm that. Secondly, other card brands such as Mastercard have different terminology and registration processes.

Now you know what kind of agent you are, how do you register?

  1. Member agents. To register, speak with your client and get in touch with the person responsible for card brand liaison. Your client should be able to sponsor you as a member agent by submittring a form to Visa Europe. Once sponsorship is in place, ask your QSA to submit your ROC, AOC and Attestation of Scope (the QSA will have this) to Visa Europe. Once the documents are accepted, you’ll be included within the PDF on the Visa Europe web site.
  2. Merchant agents. Register your details at the merchant agents registration web site. You’ll need your ROC, your signed AOC and a signed Attestation of Scope document from your QSA. Complete the on-line registration details, accept the T & C’s, and upload your documents. All being well, your details will appear on the merchant agent listing web site shortly thereafter. Note that Visa Europe may charge you for listing.

I hope that’s clarified things for you as a service provider. In the past, with only one way for service providers to be listed (on the Visa Europe PDF document), there was confusion when attempting to find a Visa Member to sponsor merchant agent service providers. In these cases, no member/agent relationship was in place, making it difficult if not impossible for many organisations to make themselves known to Visa Europe.

8 Recurring Themes Within The PCI DSS

pci dss, security, ,

The PCI DSS is a security standard that embodies a number of underlying principles. What are these principles?

As with all PCI compliance questions, the answers usually lie in understanding the intent behind the requirements of the standard. Although there are many individual requirements detailed within in the PCI DSS, collectively they are based upon a number of sound security principles. Here are eight of them.

  1. Least privilege. Did you ever delete something by accident? In any secure environment, this principle is as much about restricting access as it is about saving you from yourself. All administrative privileges should be used only for the task in hand, and then relinquished once the task is complete.
  2. Separation of duties. Why is it a bad idea to have a single role with access to everything? The same reason it is a bad idea to put all your eggs in one basket. It may seem convenient, but such systems are error prone and open to fraud and failure. It also violates principles 1, 5 and 8.
  3. Simplicity, or “complexity is the enemy of security”. The malicious exploitation of technical vulnerabilities is possible because of poor technical configuration, implementation or just plain oversight. Unnecessary complexity provides extra opportunity for failure. Keep it simple.
  4. Fail safe, or “default deny”. Implicit access is a poor approach here. Example: If you are putting together a list of users who do not need access to your card data environment, then you need to think again. Whether it is access controls, firewall rules, or any other security restriction; enforce the basic principle that nobody gets any access unless explicitly permitted.
  5. Authorisation, Authentication, Access Control. All secure systems need to support full accountability for their use. This means granting access (authorisation), confirming the identity of the requesting party (authentication) and controlling what that party can do (access control). Just as important is your ability to revoke permission – especially when things go wrong.
  6. Open Standards. This is especially true when it comes to the use of cryptography to protect your cardholder data. Designing your own proprietary encryption is usually a poor idea. It is unlikely that you will have the time or expertise to prove that your design really can keep a secret and is not simply based upon obscuring data.
  7. Re-use. Why re-invent what is already been done, and done well? Just like the example of cryptography above, it is usually best to build on the work of others, not to start from scratch. Existing policies and procedures are also a candidate here – chances are you already have material that could easily be adapted.
  8. Defence in depth. Relying on a single line of defence seems like an obvious strategic oversight. To understand this principle, try to recall how many times you have heard about a data breach occurring via a single, unsecured point of access. Also, have another look at these eight principles, and see how readily they overlap.

This article was originally written by Ambersail for the Worldpay “Safer Business” newsletter published earlier this year.

7 Security Warning Signals

pci dss, security, , , , , ,

2011 featured plenty of news about high-profile data loss and cybercriminal activity. And so did 2012. Any guesses for 2013?

Some common causes emerge in all of these cases. Poorly managed infrastructure, insecure web applications, and a lack of attention to security procedures are often cited.

But how do these conditions arise? How is it possible that otherwise capable and competent organisations fare so badly?

Our work with clients around the World gives us a privileged insight in to the security infrastructure of numerous organisations, from the largest to the smallest, and from the simplest the most complex. In all cases where data loss or compromise has taken place, common themes emerge.

Here then, are 7 significant warning signals to look out for. Why not score yourself?

  1. Management belief that it’s getting harder to defend your data, and the bad guys will get in anyway if they want to. This unfortunate attitude is especially dangerous if it comes from the top of the organisation. It indicates a lack of understanding of security issues as well as a disregard for the information assets of the company.
  2. Internal memos stating that “security is everyone’s responsibility”. Organisations should adopt internal programmes to raise security awareness but this is a different kind of message. It says “Security is nobody’s specific responsibility”. It makes about as much sense as a team where everyone is the manager.
  3. There is no IT executive who can articulate the relationship between the terms “regulatory compliance” and “corporate information security”. If an exec is confused by the difference between an audit standard and the protection of valuable data assets of the Company, then the organisation is already at a disadvantage.
  4. A security team who are so difficult to work with that the business simply ignores them. It is an unfortunate fact that there sometimes exists an “us and them” attitude; and it can emanate from the infosec team. Security has to support the business, rather than be tolerated by it.
  5. A compliance project that only extends to achieving compliance rather than maintaining it. PCI compliance, for example, is re-validated once per year. But PCI DSS requires that a compliant state is maintained at all times, not just on the day of the assessment.
  6. Blind faith in security products. Security products are a useful and often essential part of a secure infrastructure. But it’s vital that organisations have the skills to configure, operate and react to the events that such products detect and disclose. Otherwise, they are a waste of time and money, or worse, a source of false or incomplete information.
  7. The use, in any compliance or security discussion, of the phrase “ticking the boxes” to describe the validation of a compliant or secure environment. This last point is included to underline all of the others. “Box ticking” suggests an attitude to security that takes no account of what is actually going on. It suggests that instead of real, practical implementation of policy, we have a discussion-based activity. A piece of paper rather than observable evidence. It pays lip-service to real security and it is to be avoided.

How did you score?

0 – Congratulations, you’re running a tight ship. In fact you’re so busy you probably haven’t even read this post.

1-4 – Security probably feels like an uphill struggle right now, but it gets easier as you improve.

5-7 – Unfortunate. Even though no box remains un-ticked, there’s still work to do.

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