Hot answers tagged

37

Cardholder name, 4 last digits of CC number and its expiration date are all NOT sensitive data. The cardholder name and expiration date only require protection if you are storing them with the full primary account number, not the truncated 4 digit number. If you are storing, processing, or transmitting cardholder data then you must meet all of the other PCI ...


33

Yes, this is wrong, and here is why. As you mentioned, PCI-DSS requires that communication containing sensitive data be handled over a secure channel. As a part of this process, certificate validation ensures that the certificate in question is in good order and belongs to the party that you intend to talk to. If you do not validate the certificate, the ...


30

Storing card numbers means you must comply with the requirements of PCI-DSS, or you risk fines and breach of your merchant account contract. PCI-DSS has an enormous set of requirements - some sensible, some onerous, some of questionable usefulness - and the cost of complying with it, and certifying that you've complied with it, can be very high. Download ...


28

A good question, but perhaps you should phrase it "Does PCI harm security". To answer both questions, I would differentiate very roughly between two types of organizations (even though most fall in between these two extremes): Security-conscious organizations, that routinely perform business-risk based analysis, have a comprehensive SDL in place, ...


27

Ivan, this is an absolutely huge topic. And you have a bunch of questions here. I'll try to help but this will likely be closed as too broad. I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how ...


25

"None of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner" are completely valid arguments. From a technical perspective (on the merits), they ought to end the discussion. But if you're arguing with folks who are not security experts, they may not be in a position to recognize good ...


22

"Best" is rather subjective - it depends on your requirements. That said, I'll give you a general overview of each mode. ECB - Electronic Code Book. This mode is the simplest, and transforms each block separately. It just needs a key and some data, with no added extras. Unfortunately it sucks - for a start, identical plaintext blocks get encrypted into ...


22

Typically, it's just the last 4 that are shown to the customer, sometimes the first 6. From the PCI DSS 3.4 Standards Never store the personal identification number (PIN) or PIN Block. Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed. This requirement does not ...


20

Well, first, what is written is the following: payment card companies are requiring merchants to be PCI-DSS compliant. PCI-DSS does not apply to anybody who doesn't process credit card transactions. The DSS requirements specify access control, logging, etc. None of this is applicable to a cardholder. Clients do not have the same contracts as merchants. ...


20

There are lots of different ways in which PCI impacts what you do; I'd point out the data security standards (PCI-DSS). Among many other things, they require strong authentication for anyone accessing the system remotely, and have a wide variety of restrictions on what kind of data you can keep. Don't even think about storing credit cards without ...


20

Short version: TLS 1.0 is on notice as of PCI DSS 3.1 TrustWave is carping, but you may be able to continue using TLS 1.0 if it's not a "new application" Long version: PCI DSS 3.1 was released two weeks ago, on 14 April 2015. It lays out that SSL and early TLS are not considered strong cryptography and cannot be used as a security control after ...


18

First, IANAL. Secondly, this is entirely dependant on your local laws and regulations. PCI-DSS is a guideline, but adherence to the guideline may be a requirement as part of certain laws. I'm not aware of any countries that do this, but in such a case you could be prosecuted if you violate a law that makes PCI-DSS adherence mandatory. The more common case ...


17

Yes. I would argue HTTPS is equivalent or better than SFTP. HTTPS uses a central certificate authority where SFTP does not. There is a risk the first time you authenticate with SFTP. HTTPS' use of the trusted third party prevents that risk. It is important to note that (assuming a secure channel is established) SFTP and HTTPS are equally secure.


16

Taking into consideration the fact that you are doing these scans in the context of PCI-DSS compliance, your value-add in relation to compliance can be summed up by my personal favorite saying: AviD's Law of Regulatory Compliance: "PCI compliance reduces the risk of the penalties of non-compliance". In other words - the value-add of having an ...


16

Generally, the most conservative answer comes in the form of something easily understood, and approachable by the general populous. Ignoring the hyperbole of that kind of response, there are two things you must really take into account. What logs should I retain How long should I retain said logs Log Retention The answer to 2 is simple and well ...


16

HTTPS and SFTP when used properly are equally safe. The underlying encryption algorithms in practice are both functionally equivalent -- neither can be broken in practice by directly attacking the cryptographic protocols. However, in practice with non-tech savvy user, HTTPS is slightly weaker in my opinion. There are attacks on both that can be launched ...


15

You may be getting zero value-add. I suggest finding a new vendor. And when soliciting potential new PCI ASVs, ask them what they do, questions like: Which vulnerability scanners will you use to assess our systems? Do you use the commercial or free versions of the vulnerability scanners? We use Nessus internally, what more will you do to bring ...


15

Amazon does have a Type II SAS 70 report. Requesting a detailed copy of that should show all the controls they have in place. It may that people are asking Amazon the wrong questions. As a quick note, the SAS 70 testing in the future will be referred to as an SOC -- one of those accounting industry quirks. Especially with an Amazon-sized company, one looks ...


14

Nessus is very good at what it does, but a 'proper' security scanning vendor would not just deliver you a Nessus report. At the very least, you need to go through the report and validate to remove false positives - you probably do this internally anyway, but unless you request it a vendor may not. There is a major disconnect in what customers expect and ...


14

Why even store it in a MySQL database when you can be using Authorize.Net's Customer Information Manager API and taking PCI compliance and security issues right out of your hands completely and letting them do all of the heaving lifting for you? CIM let's you create customer payment profiles by storing the customer's credit card information on their end and ...


13

This is a classic scoping problem with compliance standards. Hold the merchant fully accountable -- but completely negate all of their efforts if the merchant's customer didn't protect their browsers. However, what does remain questionable for scoping is if the merchant has CSR reps or employees/contractors/consultants of any kind (back-office, via business ...


13

There are several reasons why wildcard certificates are bad: The same private key has to go on the systems that have different security levels, so your key is only as good as your least-protected system. Giving it out to third-party vendors is a really bad idea, as then it completely escapes your control. You have to keep meticulous records that show ...


12

Here are the basic do's and dont's for PCI-DSS: Regardless of segmentation you are not allowed to store the CVV data. The effectiveness of this code is limited to the ability to keep it out of the hands of criminals, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can ...


11

Merchants can use your card data to review or act on transactions. This includes processing returns, calling up your boarding pass, etc. They can't use it to identify you, only your previous transactions. I'm not sure if that's a law somewhere or because of merchant agreements. Once your purchase is fully settled, the card data does need to be expunged from ...


11

The key regulation you must follow is the Payment Card Industry Data Security Standard (PCI DSS) and of specific interest here is section 3.4 - Protect Stored Cardholder Data Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: One-way hashes based on ...


11

It is, of course, always wisest to accept the judgements of your QSA when making judgement calls, however during your own in-house compliance work I recommend checking out the Navigating PCI-DSS: Understanding the Intent of the Requirements document whenever confused by a requirement. Looking at page 32 of that document we see the following write up ...


11

Short version: The PCI-DSS does not explicitly call out the steps you describe. However, those are common sense steps that are reasonably encompassed by several PCI-DSS requirements. They are not at all uncommon and I have seen them as requirements to non-PCI-DSS contractual agreements by third parties in a card processing environment. Long version: ...


10

PCI DSS v2, Requirement 7: "Implement Strong Access Control Measures" is the pertinent section. This section details access control primarily for non-consumers that will be accessing cardholder data for business purposes, though there are a couple requirements that seem applicable to consumers as well as non-consumers: 8.1 Assign all users a unique ID ...


10

You are expected to log: All individual accesses to cardholder data All actions taken by any individual with root or administrative privileges Access to all audit trails Invalid logical access attempts Use of identification and authentication mechanisms Initialization of the audit logs Creation and deletion of system-level objects These must be logged ...


10

If your compliance or regulatory body is perceived as PCI, you are incorrect. They make the rules and guidelines, but in this situation it is your companies' acquiring bank (the bank that issued your merchant number and processes your payments). What is the volume of cardholder data that is being taken off premises or thrown away without shredding? From ...



Only top voted, non community-wiki answers of a minimum length are eligible