Tag Archives: pci

Cheat Sheet: Virtual Web Application Patching

cloud, pci dss, penetration testing, security, ,

IMG_0794-smallDo 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.

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.

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.

SAQ Eligibility Guide

pci dss, , , , , ,

Choosing the right Self Assessment Questionnaire (‘SAQ’) can be a very tricky task, especially for merchants with multiple payment channels. The PCI SSC introduced five different SAQs:

  1. SAQ A – Card-not-present Merchants, All Cardholder Data Functions Outsourced.
  2. SAQ B – Merchants with Only Imprint Machines or Only Standalone, Dial-Out Terminals. No Electronic Cardholder Data Storage.
  3. SAQ C – Merchants with Payment Application Systems Connected to the Internet, No Electronic Cardholder Data Storage.
  4. SAQ C-VT – Merchants with Web-Based Virtual Terminals, No Electronic Cardholder Data Storage.
  5. SAQ D – All Other Merchants and All Service Providers Defined by a Payment Brand as Eligible to Complete an SAQ.

Merchants are eligible to complete only one SAQ covering the entire payment system. So, lets have a look at the following scenarios:

Scenario 1

  • Merchant A has outsourced its E-commerce payment channel to a Service Provider B.
  • Merchant A does not operate any other payment channels.

This model fits an SAQ A. An E-commerce system classifies as Card-not-present transaction and it is outsourced to the Service Provider B. Simple!

Scenario 2

  • Merchant B has outsourced its E-commerce payment channel to a Service Provider C.
  • Merchant B also accept in-house MOTO (Mail Order/Telephone Order) transactions via a virtual-terminal provided by the Service Provider C.

This scenario is more complex. Based on the first statement, Merchant B fits an SAQ A. Based on the second statement, Merchant B fits an SAQ C-VT. So, which SAQ Merchant B should complete; SAQ A, C-VT or both?

The correct answer is SAQ D. SAQ A, B, C and C-VT along with the corresponding Attestation of Compliance (‘AOC’) were designed for merchants operating a single payment channel type. If a merchant operates multiple payment channel types, the only option is to follow the SAQ D.

Download our free guide to SAQ Eligibility Criteria.

The Cloud & PCI – Propagating Failure?

cloud, pci dss, security, ,

The cloud may be nebulous, but the security of your valuable data assets should be clearly defined.

We’re all seeing a continued movement of services in to the cloud, especially in the Infrastructure-as-a-Service (IaaS) arena. The security issues around cloud computing seem, to us at least, to be similar to the traditional issues – hardening, secure access, patching, vulnerability management, protecting data assets and so on.

The difference in the cloud is the speed and ease with which new server instances can be provisioned, and the level of expertise needed to do so.

If you fail to securely configure and manage your template images (AMIs, in Amazon-speak), expect these failures to be propagated throughout your infrastructure; rapidly, and by people who have no idea why this could be a problem. Look out too, for a new take on an old problem. If you own physical storage media, you can physically destroy it. What about cloud storage? How can you be sure that your data has been removed when your virtual servers are no longer needed?

The PCI compliance impact here is obvious – security failures at the template level will:

  • Extend the scope of your CDE
  • Expose the business to increased risk of data loss (be it card data or any other valuable data)
  • Increase the costs of remediation as the number of insecure or non-compliant images proliferate

As has always been the case in security, prevention is better (and cheaper) than cure.

Cloud IaaS providers need to provide appropriate tools, documentation and training in these areas. Consumers need to translate existing security processes, roles and know-how and apply these to the cloud environment. At a high level, this needs to include:

  • Definition of secure/compliant base images
  • Fit-for-purpose hardening of instances based upon those images
  • Ongoing maintenance of active instances
  • Maintaining an inventory of active instances
  • Secure and verifiable removal of instances when no longer needed

In many ways, the cloud is new, powerful and provides consumers with unprecedented levels of control and flexibility. It may hide physical detail from the consumer, but it is still real infrastructure; quick and easy to deploy, with the same underlying security concerns that we had before.

References/Further Reading:

http://blog.ambersail.com/security/video-penetration-testing-the-cloud/

http://en.wikipedia.org/wiki/Infrastructure_as_a_service#Infrastructure
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?AESDG-chapter-sharingamis.html
http://akamai.infoworld.com/t/cloud-computing/sloppy-use-amazon-cloud-can-expose-users-hacking-178575?source=rss_security
http://www.networkworld.com/supp/2011/enterprise3/060611-ecs-iaas-provders.html