Tag Info

New answers tagged

0

The most common way to prove cardholder data isn't on a system is to use a tool to scan that system for cardholder data such as ccsrch. Acording to the PCI DSS Cardholder Data: At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date ...


1

If desktop computers are within scope of your PCI boundary then they will have to be subject to the same controls as any other device in scope. This means a number of controls on the configuration, AV and malware protection, security policy (password management controls), etc. as well as processes around usage need to be considered. There is nothing specific ...


0

QuaSAr is a "for pay" product designed to do just this. Disclaimer: I do not, nor have ever worked for confide, but have friends in the company.


1

From what I understand, you can find the data you need with tools like grep, but you are finding it difficult to deal with the resulting output because it, too, becomes sensitive data. It appears that you need sed with your grep. Once you find offending data, you can pipe the result through a substitution process to create obfuscated card numbers. But I'm ...


0

Depends on what kind of scan you're looking at. Since you've mentioned that your company is doing an SAQ (https://www.hackerguardian.com/pci-saq.html), I'm guessing it's going to be an internal audit. Like SilverlightFox and gowenfawr have suggested, doing it internally just requires an in-house expert to ensure things are PCI compliant. A company I worked ...


1

In a nutshell, no. Basically, any physical input device that "receives" clear card data (for example, by data entry - typing, swiping or other methods) must appear on the PCI "PTS" certification list. In theory (and very concisely), this certifies that the device uses approved forms of encryption, key management,etc., only outputs safely encypted data, ...


1

Only the external scan requires an ASV: PCI 3.1 states: 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved. It is only on internal scans where you can run a tool such as ...


0

To quote PCI DSS 3.1 section 11.2: There are three types of vulnerability scanning required for PCI DSS: Internal quarterly vulnerability scanning by qualified personnel (use of a PCI SSC Approved Scanning Vendor (ASV) is not required) External quarterly vulnerability scanning, which must be performed by an ASV Internal and external scanning ...


0

PCI standards exist for a reason. While the process of achieving that level of security may be arduous, it is necessary to protect your client's data. Let's be clear about that; it's not just your data, it is data that your clients have entrusted to your care, and if you fail to secure it using reasonable best practice, your company is opening itself to ...


0

You can show the full credit card data as long as user passes the MFA(Multi factor authentication). Also phone number which is used to validate the MFA, should be attached to that user. No links should be available to redisplay the card data again. Also page should never be cashed.


0

Credit card data is not homogeneous. There is some information you can show and others you aren't even allow to store. For instance, you aren't allowed to store the CVV2 code. Yet other credit card data is the cardholder name, the transaction history, etc. So you have to look at it on a field-by-field basis. Generally speaking, best practice is minimization ...


0

All those merchants will ultimately be responsible for their own compliance and this should be enforced and monitored by their acquirer. They will generally have to complete a Self Assessment Questionnaire, my guess being SAQ B-IP which includes a PED with IP connectivity. That SAQ also includes the PCI DSS requirements 9.9 to which you are referring. If you ...


1

Disclaimer: I Am Not A QSA; I Am Not A Lawyer My question is, if I wanted to offer similar service (i.e. make purchases on behalf of consumers with their cc info), must I (/are they?) be PCI compliant? Or, is it simply enough to (1) use SSL on my site and (2) never write CC info to my DB? Yes, you would need to be PCI compliant. You would be ...



Top 50 recent answers are included