SQL Server PCI DSS Security Patching Checklist

By: Tibor Nagy   |   Comments   |   Related: > Security

Problem

PCI DSS has strict requirements about implementing security updates and using only applications which are supported by the vendors. Could you please help me to create a patching policy for our SQL Servers?

Solution

1. A process to identify security vulnerabilities and assign a risk ranking
2. A process to install vendor-supplied security patches
3. Change control procedures for the implementation of security patches and software modifications must include the following:
1. Documentation of impact.
2. Documented change approval by authorized parties.
3. Functionality testing to verify that the change does not adversely impact the security of the system.
4. Back-out procedures.
   

A patching policy for your SQL Server under PCI DSS should address all of the above points.

How to identify SQL Server security vulnerabilities for PCI

There are several ways to get information about SQL Server and other Microsoft product security vulnerabilities. You can check the Microsoft Technet Security Advisories and Bulletins, subscribe to the Microsoft Technical Security Notifications or browse the vendor and product specific vulnerability database at CVE Details. You can get a quick check on the latest service packs, cumulative updates and security fixes at the Update Center for SQL Server.

Once you learn about a security risk that can affect your environment, you have to assign a risk ranking. The ranking can be a simple scale of high, medium and low risk or a score between 1 and 10 as an example. You can use the previously mentioned sources to find the details of the vulnerabilities as well as the likelihood that they will be exploited. You have to adjust the general scoring to generate a ranking for your specific environment. This classification helps you to prioritize the risks and identify the critical issues which should be fixed immediately.

When to install SQL Server security patches related to PCI

First of all, critical security patches should be installed within one month of release, but I recommend installing as soon as possible. All the other, non-critical security fixes should be installed within 3 months of release, but it is recommended installing them within one month. It is a best practice to perform regular checks on your system to validate that all of the known security patches have been installed on all of your servers.

Another question is the case of cumulative updates (CU). There is ongoing debate in the SQL Server community if you should install the CUs or not. Some say that these fixes are not fully tested, so it is better not to install them if you do not face any particular issues with your SQL Server (If it ain't broke, don't fix it.) Others say it is always better to keep your system updated. The consensus is that you should apply the CUs if they fix something that is wrong in your shop. For sure, Microsoft recommends that you test CUs before you deploy them in a production environment.

How to establish a change control process for security fixes for SQL Server

PCI DSS requires the impacted organizations to document all of the changes to the production environment. The documentation should include the impact of the change (the security fix in our case) and the change should have an approval from the authorized parties. Functionality testing should be performed to verify that the change fixes the issue, but in certain cases it is difficult to simulate the security issue. Additionally, regression testing should be performed to verify that the fix does not adversely impact the system. I recommend checking the following items during testing:

• Does the patch install without any errors?
• Do you have to follow any specific implementation steps?
• Does the patch require a system reboot?
• Do all of the SQL Server services start properly after the installation?
• Does the SQL Server work correctly after the installation?
• Do all of your applications work correctly after the installation?
• Does the patch correctly uninstall if you try to remove it?

It is important to test the back-out process to verify that the patch can be rolled back in case of any issues. Finally, I recommend the use of a rolling patch process for failover cluster instances and document it in the patching policy.

What about service packs?

PCI DSS requires reviewing your software at least annually to confirm that it continues to be supported by the vendor and can meet the security requirements. Microsoft provides 12 months of support for the previous service pack when a new service pack is released. This means that you can use the previous service pack of your SQL Server stack for a maximum of one year, then you will have to upgrade to the latest service pack. Due to Microsoft's support lifecycle policy, you will have to regularly upgrade to new SQL Server versions. For example, extended support for SQL Server 2005 will end on April 12, 2016, so this is the deadline to upgrade your systems to a more recent version of SQL Server.

SQL Server PCI Patching Summary

Your PCI DSS compliant patching policy should include the following items as a minimum:

1. Process to identify and rank the security vulnerabilities
2. Install critical security patches within one month of release
3. Install non-critical security fixes within 3 months of release
4. Change documentation
5. Testing requirements
6. Approval process
7. Installation process to minimize downtime
8. Service pack and version upgrade policy

Next Steps

• Use the above information to create a PCI DSS compliant patching policy for your SQL Servers.
• Check the Microsoft Support Lifecycle page for SQL Server.
• You can find more articles in the Security category.
• Read more tips by the author here

About the author

Tibor Nagy is a SQL Server professional in the financial industry with experience in SQL 2000-2012, DB2 and MySQL.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips