Using Monitoring to Help with PCI Compliance

If your website is taking online payments then PCI Compliance is something which I am sure you will have had to deal with, and probably with a level of confusion with conflicting messages everywhere!

As a former PCI Qualified Security Assessor (QSA), I have had first-hand experience in helping companies understand and comply with the regulations.

In this blog post, I am going to look at how you can utilise monitoring systems such as RapidSpike to prevent an instant fail against the PCI regulations by implementing some very simple monitoring controls.PCI DSS

Within the PCI regulations, there are some items that are classed as an instant fail. One of these instant fail situations is if you have a database that is in the Cardholder Data Environment publically available to the Internet. As well as being a PCI fail, this is also considered bad practice for any database, whether governed by PCI or not.

Let’s look at the specific issues this causes within PCI Compliance:

Under PCI section 11.2, every merchant must run quarterly external vulnerability scans that are performed by an Approved Scanning Vendor (ASV). The latest ASV guidelines cover external access to databases servers and report the following:

The ASV scanning solution must be able to detect open access to databases from the Internet. This configuration is a violation of PCI DSS section 1.3.7, and must be marked as an automatic failure by the ASV.

Section 1.3.7 of the PCI regulations states the following:

Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

You can clearly see from the above excerpts that to avoid an instant fail, it is imperative that no database is available from the public Internet.

So, how would an ASV check for the existence of a database from the public Internet? Having built and ran an ASV for a number of years, I know that the way these are identified is by checking the externally available ports that are presented to the ASV. Each database communicates over certain TCP Ports. For example, the management port used by Microsoft SQL Server is TCP/1434 by default. It is possible to change this default port although this is normally outside the scope of what the ASV would identify as part of their initial scan.

So, using the above information, creating a Service Monitor with RapidSpike to monitor for the existence of TCP/1434 would instantly notify you if this port ever comes open on the specified IP address.

It would be good practice to configure this type of port monitoring for all of your external IP addresses.

Lets now look at how we can set this up in the RapidSpike dashboard:

If you are using the recently released Add New functionality then this monitor, as well as other database monitors are automatically configured as part of the Add New functionality when you are adding a Web Site, Web Server, or Network Device.

SQL Management

The image above shows the monitor that would be created. It is important to understand that the monitor is checking that this port is closed or offline. With this logic, the monitor is expecting the port to be closed and it will only trigger a notification if this changes, meaning that the port becomes open or online.

You can configure these Closed monitors for any network port and the Add New feature currently configures various Closed port monitors, checking that all of the following ports are closed:

  • FTP (TCP/21)
  • SSH (TCP/22)
  • SFTP (TCP/15)
  • MS SQL-M (TCP/1434)
  • MYSQL (TCP/3306)
  • POSTGRESQL (TCP/5432)

As with all of our monitors, these can be changed to your requirements if you have a valid business case to keep any of the above ports publically open.

I hope you have found this post informative and don’t hesitate to contact us on info@rapidspike.com if you have any comments or questions.