• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

PCI Compliance - Hackersafe keeps finding problems

A

adamluz

Guest
I am attemping to make my website PCI compliant so a customer can run credit cards with out being charged an extra fee for PCI compliancy. Most credit card providers are going to start charging a fee if the site doesn't meet certain security rules. I have updated all my server hosting side software like PHP, but I think plesk use's another version of php. How do I upgrade this? Its also reporting my apache on port 80/443 is out dated.

Is there a server I can add to plesk update. Or a rpm site with recent rpms for fedora core 4?
 
Is your server in a shared hosting? if yes it will be extrememly hard to meet compliance.

Have you tried atomic secured linux or mod-security you may want to give those a shot. without setting up the fundamentals a php upgrade doesnt mean compliance and definetly not immune to exploits
 
We meet the PCI compliance (according to ScanAlert.com) on every server with ASL (Atomic Secure Linux) on it, also the shared servers... most important that you are behind a hardware firewall with IPS (Intrusion Prevention System), that’s where most fail already...
 
you need PCI compliance only if credit card numbers are stored on the server only, isn't it? If you use a service like worldpay as example, since the transactions runs on their server they must comply to PCI
 
Incorrect. You need to be PCI client when your client reaches a level four in sales. Reguardless if you store the information, since the credit card company has no way of knowing if you do or not, they require you to have a secure server. You are still storing good amounts of customer data. Address and what not. But until you are warned about it, its not really an issue (I guess)
 
Incorrect. You need to be PCI client when your client reaches a level four in sales. Reguardless if you store the information, since the credit card company has no way of knowing if you do or not, they require you to have a secure server. You are still storing good amounts of customer data. Address and what not. But until you are warned about it, its not really an issue (I guess)

As the Director of IT for a Credit Card processing company i'll try and give a quick answer on this.

When it comes to Internet Accounts and e-commerce if your website is'nt retaining Credit Card data and is using a SSL during the Check out process and your not retaining or storing data PCI Compliance does not apply Unless their is a major Known exploit to the portion of the Checkout process or the secured connection from cart to gateway.

Since most Shopping carts don't retain data and it's passed thru to your Gateway provider thru a secured connection already it's the Gateway that must comply since they are getting the full CC data and the cart is only passing the data and truncating the CC portion of data that applys to the customers inside the cart and most carts don't keep that portion anyways now.

Since most carts now follow PCI Compliance standards on Data retension it does'nt apply in 99% of the e-commerce shopping carts or software.
 
PCI Compliance

Well after talking people like secpay, and netbanx, our server needs to be PCI compliant as we will be transmitting credit card details etc.

But we have found that our server with plesk 8.4.0 has php 5.2.5 installed for the websites, but Plesk is running on PHP Version 5.2.3. And this is failing the PCI compliancy checks (as done through hackerguardian.com

Any ideas on either how to update the PHP (to 5.2.6) that plesk is sat on? Or to rectify the issue of Security hole found on port/service "pcsync-https (8443/tcp)"
 
Greetings:

Thanks to God, this is our 13th year in business.

From experience, all PCI Compliance scans I've ever seen are mostly wrong out of the box.

The software they use, across the board, is incorrect, often times more than half of their reports are filled with false positives that you need to spend time explaining rather than correcting.

People laugh about weather forecaster jobs as the only job you can be wrong most of the time, and still keep your job... well, they don't know about PCI Compliance Scan software and those companies that offer the service.

Hosting providers do need to take care to have there applications up to date, along with having an inventory of what they have at what version / patch level.

And customers who need PCI Compliance will rely on you to be able to explain the false positives (there are often many) or make corrections as applicable.

As the provider, just don't panic over a PCI Compliance Report as almost every single one contains one or more false positives.

Take the report seriously as a double check of your own security, but don't panic or fret about it.

Thank you.
 
For those of you running ASL out there, if you ever run into this situation with your PCI QSA's, we would be happy to respond to your auditors on your behalf to contest their findings. You are absolutely correct that automated vulnerability assessment tools like they are using (typically nessus, which is fantastic tool) are prone to a very high rate of false positives. In regular auditing environments these are usually filtered out by a qualified operator.
 
well i've locked the server down a bit more, and only specified IP Addresses. last thing now is to upgrade MySQL from 5.0.26 to 5.0.51a (any one care to offer advice on this... it's SUSE 10.2)
 
actually i use neither, as i'm on the SUSE 10.2 server with RPM installations... i've just denied access to the servers MySQL setup via IP address... seems to work quite nicely
 
Back
Top