Do you operate public-facing web applications in your card data environment? Here’s a pointer to a great source of information from the Open Web Application Security Project (OWASP) on the subject of virtual patching.
What is virtual patching? Within the context of web vulnerabilities, this refers to the practice of applying a defensive layer to intercept potentially malicious traffic destined for your web applications. Of course, the very best defence against these attacks is to write secure code to begin with, however there are a number of circumstances in which this isn’t achievable.
For example, where you’re running a 3rd party web application, or if you simply don’t have the resources available to make the code changes.
Highly recommended reading for all developers and development managers.
Read it here.
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.
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.
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.
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.
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:
- 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.
- 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?
- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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
We’ve just been reading the monthly assessor newsletter as sent from the PCI SSC, and there’s an update in there that will affect a number of our PA DSS clients.
It’s a process change relating to payment of the SSC’s invoice. To quote:
“As soon as a ROV is submitted, we will invoice the application vendor and the ROV will not be reviewed until payment is received.”
Therefore, please be aware that the SSC will invoice you directly once we submit your ROV, but they will not review it until their invoice is paid.
This change is effective immediately.