Compass IT Compliance Blog

This is the sixth blog in a 12-part series addressing each PCI DSS Requirement and the challenges faced by companies going through this process.

To view the previous posts in this series, follow the links below:

PCI Requirement 1 - Defending the Wall

PCI Requirement 2 - Change Your Defaults!

PCI Requirement 3 - Don't Store Cardholder Data!

PCI Requirement 4 - Hide in Plain Sight!

PCI Requirement 5 - Update and Scan

PCI requirement 6: Develop and Maintain Secure Systems and Applications

Requirement 6 joins the previous requirement in and around Anti-virus/Anti-Malware within the Vulnerability Management program section of the PCI requirements. This requirement will help you build a vulnerability management program that will ensure the development and maintenance of secure systems and applications. Patching and vulnerability scanning are critical components to this PCI requirement as it means there are some tools that need to be involved. Below I will discuss some challenges companies face when trying to meet this requirement. If your organization does application development for your PCI environment, there are a number of different pieces requirement 6 will make you comply with. These include formal software development procedures, formal code testing and deployment, as well as ensuring your developers are up-to-date on their secure coding techniques. These pieces of the program are not one and done, these are ongoing and fundamental to the PCI world you may live in.

Compliance and security at times go hand in hand. In most cases, being compliant does not truly ensure you are being secure. I titled this blog “Don’t just check the box!” because the thinking that if your company can check the compliance box it will be secure enough is just not true.

Compliance is usually a point in time or period of time; a specific set of controls are in place and/or operating effectively. When you go through a PCI Report on Compliance, you are looking at a specific period of time, the last 12 months. When you go through a SOC 2 Type 2 report, you are looking at a specific period of time, usually anywhere from 6 to 18 months. Security, or Cybersecurity as they say, is never a point in time approach. Security is and should be an ongoing process that is constantly being assessed and improved. The subset of true security principals within whatever compliance requirements you have, may not meet the best practices or standards of good security. Your company should take a big picture approach and design its security program to exceed what is within your annual compliance requirements.

This is part 4 of our ongoing blog series on the NIST Cybersecurity Framework. To view our previous posts in this series, please see the links below:

NIST Cybersecurity Framework - Overview and Identify

NIST Cybersecurity Framework - Protect

NIST Cybersecurity Framework - Detect

After the countless hours and days that were put into identifying assets within the organization, researching and implementing ways to protect these assets and even going the extra mile by implementing detection mechanisms to alert us in the event of an incident, the stressful day has arrived, and now the fourth function will have to be initiated, which is Respond. The NIST Cybersecurity framework defines the Respond category as; "Develop and implement the appropriate activities to take action regarding a detected cybersecurity event." The Respond function is further broken down into five categories (outlined below) which identify specific areas that organizations should consider in their risk management analysis. Of the 98 subcategories within the NIST Cybersecurity framework, 15 are addressed within the Respond function.

This is the fifth blog in a 12-part series addressing each PCI DSS Requirement and the challenges faced by companies going through this process. To read the previous posts in this series, click on the links below:

PCI Requirement 1

PCI Requirement 2

PCI Requirement 3

PCI Requirement 4

*Requirement 5 – Protect all systems against malware and regularly update anti-virus software or programs*

Requirement 5 is the start of the Vulnerability management program section of the PCI requirements. This requirement used to be known as the “Windows AV” requirement but it has developed into much more. It seems simple enough, put AV on the endpoints in your PCI environment and make sure they scan and update regularly. That should be commonplace this day in age, but I assure you it's still a weak area in some cases. With the number of tools available and the constant reminders in the news and even on your computer itself, this should be an easy requirement to meet. Requirement 5 really pushes to make sure your AV/Malware tools are enabled, configured properly, updating regularly and scanning for the appropriate malware and viruses.

This is the fourth blog in a 12-part series addressing each PCI DSS Requirement and the challenges faced by companies going through this process. To read previous posts in this series, click on the links below:

PCI DSS Requirement 1

PCI DSS Requirement 2

PCI DSS Requirement 3

Requirement 4 – Encrypt Transmission, the SSL/TLS Requirement

Requirement 4 states that sensitive data must be encrypted when traveling over open public networks. If you are sending data, i.e. payment card data, to another entity or a processor through an entity, this data must travel on secured internet connections. There are ways as a user to see if this is happening. Ensuring the site you are on is using HTTPS in the address is one way. Another way is most web browsers will have a warning page if the site does not contain the appropriate certificate or if that certificate is expired. What PCI compliant business entities must do is ensure proper communication channels are secured. In some cases, a payment gateway is used or developed, and secure ports and authentication mechanisms must be in place to the processor. Further steps like ensuring only the gateway’s internal IP can only connect to the processor’s IP addresses will add another layer of protection to the transmission.