PCI DSS requirement six deals with regularly upgrading systems and patching any security vulnerabilities that may arise. Even the best and safest software will have errors when it comes to protection.
Hackers have plenty of time to try to find vulnerabilities. Fortunately, software developers will do their best to create security fixes and improvements to combat the vulnerability when a vulnerability is discovered.
But unfortunately, many businesses don’t always upgrade their software and applications when the need arises. So why? Some of the reasons are as follows:
- It takes time to update
- They don’t know how to update
- They don’t see it necessary to update
- The system does not support upgrades.
Regardless of the reason for not upgrading or patching, you must regularly update your software and applications to protect your company as data breaches increase. Below are essential things you should know about system patching and PCI DSS Requirement 6.
What Are Security Patches?
Security patches are software or pieces of code that allow a program or application to fix a security vulnerability.
Patches can be distributed as a source code or as an executable file in two ways. A common way of implementing changes is to use source code. However, source code updates require a recompile. Custom software patches are distributed as executable files. Most systems and applications have a tool that automatically searches for updates and simplifies the update process.
Some companies periodically release security fixes and software updates. Microsoft created the phrase “Patch Tuesday” on the second Tuesday of each month by introducing such updates.
Why am I expected to update the software?
PCI Requirement 6.1 requires you to establish a process using reputable outside resources to identify vulnerabilities and assign a risk ranking to newly discovered vulnerabilities.
The aim of PCI Requirement 6.1 is to keep fresh vulnerabilities that could impact your environment up to date for your organization. PCI QSA auditors will try to see that you have a formal and established process to identify vulnerabilities.
The process you will create to identify security vulnerabilities; reporting security vulnerabilities, determine the vulnerabilities’ risk ranking, and then apply security patches.
Once you’ve identified a vulnerability or vendor’s patch, you need to rate that risk. Classifying risks as ‘high,’ ‘medium’ or ‘low’ allows organizations to prioritize and address the highest risk items faster and reduce the likelihood of exploiting the vulnerabilities that pose the most significant risk.
See Also: What are the Requirements for PCI DSS Vulnerability Scanning?
You can use the Common Vulnerability Rating System (CVSS) for risk ranking. Once vulnerabilities and patches are identified, a score between 1 and 10 is given. One indicates informational vulnerabilities, and 10 shows security vulnerabilities that need immediate attention.
Most of the vulnerabilities are posted with a CVSS score in today’s world. The risk ranking is significant because it gives your organization a chance to evaluate how a vulnerability or security patch will affect your environment.
If the vendor states a critical or urgent vulnerability, you must accept it and fix them immediately. However, there may be situations where a vendor sees a vulnerability or patch as low risk. Still, once you rank that risk in your unique environment, you may find it urgent or high.
Risk ranking vulnerabilities and patches can prevent your organization from believing common misconceptions such as:
- Just because there is a security patch available doesn’t mean I have to install it right away.
- If a vendor says the update is medium risk, it is not critical to my environment.
- If Microsoft, Oracle, or Linux do not report a vulnerability, my organization is not vulnerable.
- Keeping my system patched will keep it out of all security holes.
- Unpatched vulnerabilities can leave your systems unprotected, causing attackers to damage your system.
PCI Requirement 6.2 requires ensuring that all system components and software are protected from known vulnerabilities by installing the vendor’s applicable security patches. Additionally, PCI DSS needs to be implemented within 30 days to identify a critical or urgent security patch.
In today’s threat environment, there is a constant stream of attacks. If the latest security patches are not applied to systems as soon as possible, an attacker could attack, disable, or exploit systems that contain sensitive cardholder data.
PCI DSS prioritizes critical infrastructure fixes, ensuring that as soon as a patch is issued, high-priority networks and devices are protected from vulnerabilities. It would be better if you considered prioritizing patch installs so that security updates are deployed within 30 days and other low-risk patches within 2-3 months for sensitive or at-risk systems.
PCI Requirement 6.2 requires an auditor to review your policies and procedures to verify a built-in patch management process that ensures that all systems and software are protected from known vulnerabilities.
See Also: Change Control Management for PCI DSS
An auditor will also compare the list of security patches installed on each system with the latest list of security patches provided by the vendor to verify that critical security patches are installed within one month and that non-critical security patches are installed within an appropriate timeframe.
With the constant change of technology, data hackers are also developing new methods to manipulate device and software vulnerabilities. No matter how secure your program is, over time, a weakness may arise that could be the key to your company for a cybercriminal.
Software developers are not foolproof, so patches are released regularly to fix security vulnerabilities. When a hacker learns that it can pass through exposure, it gives this information to the hacker community. Many attackers try to exploit the vulnerability before the program is modified.
Updated patches must be applied to all critical components in your PCI scope and card flow process, including:
- Firewalls
- Application software
- Databases
- POS terminals
- Operating systems
Older systems can make it difficult for vendors to stay safe, primarily when they no longer support a particular operating system or version. Updates in operating systems also include security fixes for errors that have been exposed. Your risk also increases exponentially if you’re using an older operating system that doesn’t receive updates and fixes.
Be careful and upgrade system-related applications regularly. Don’t forget to update essential applications like credit card payment apps and mobile devices as well. Ask your software vendors to add them to their patch/upgrade mailing list to help keep you updated and carefully follow up on notices from the lists.
Tips for Patch Management and PCI Requirement 6.1
It can be challenging to track which software needs to be upgraded and what updates have been made. Here are some simple measures you can use to manage patches and as a vulnerability management program.
- Get a Security Patch Update program.
- Receive notifications of new releases and fixes from vendors and third-party organizations.
- Identify vulnerabilities through vulnerability scanning and penetration testing.
- Perform a risk analysis to see if this update applies to your product.
- Review vulnerabilities and adjust CVSS scores for applicability to the organization’s environment.
- Check the patch for security before applying. Make sure the patched device or software is working correctly.
- Deploy the security patch in your corporate environment.
- Make sure the patch is applied correctly, and the devices are working correctly. Often the patches can cause other systems to malfunction, mainly if they are misused.
- Update all your documents to include any installed changes or patches made.
Create processes for software development
When designing in-house payment applications such as e-commerce websites or POS applications, you must use rigorous development processes and secure coding guidelines described in PCI DSS.
Be sure to build and test applications according to industry-accepted guidelines such as OWASP (Open Web Application Security Project).
The guidelines will guide you in implementing secure coding practices in your application development process and protect software code from malicious vulnerabilities such as cross-site scripting, SQL injection, unsafe communications, and CSRF.
Use web application firewalls (WAF)
In addition to upgrading and protecting applications, web application firewalls (WAF) should be used to monitor, identify and prevent web-based attacks in front of public web applications.
Web application firewalls (WAF) can also be used to perform security checks on applications. Although these solutions cannot complete many of the multipurpose network firewall functions, they specialize in web-based traffic monitoring and blocking.
A WAF can include Web applications that can be viewed or used from the internet, including applications that require acceptance of payment cards from outside or from the intranet. According to PCI DSS requirements, WAF must have up-to-date signatures. Also, the WAF should create audit logs and block attacks or generate an alert.
Don’t use SSL and TLSv1.0.
Because data transmitted over public networks is unprotected, vulnerable SSL and TLS 1.0 are no longer considered appropriate encryption types. It is essential to move from SSL and TLS 1.0 versions to more stable versions as quickly as possible.
While working towards this goal, the PCI Council asks you to write a Risk Mitigation / Transition Plan that explains how you will reduce this risk until the transition is complete.
Some additional tips for software updates include:
- Sign up for your supplier’s patch/upgrade list: If you are not aware of the vulnerabilities, you cannot fix them. Most tech vendors have an email list regarding patches/upgrades. Ask them to add you to the list.
- Create a schedule for updates: It may be easier to apply updates daily for specific applications. Create a plan that specifies when and how updates will be added.
- Apply updates to your systems within 24 hours of the patch’s release: The longer you wait to upgrade, the more vulnerable your company will be.
- Perform vulnerability scan to identify vulnerabilities: By periodically reviewing applications, you can identify bugs that need patching.
Can I Apply Compensating Controls for Patches and Vulnerabilities?
Applying critical security patches over 30 days is often a complicated process for most companies, even with automated patching tools. However, the PCI Council felt it was necessary to set a deadline for patches to avoid vulnerabilities caused by loose patch implementations in most organizations.
See Also: PCI Compliance and Virtual Patching
As a result, you can always apply a compensating controls to abide by the 30-day patch rule. But getting and implementing compensating controls is not as easy as it seems.
The PCI SSC essentially requires that the organization’s vulnerability management process be reviewed and the vulnerability management process adequately managed.
PCI SSC also states that an organization may not meet the 30-day patch rule but that the organization should mitigate the risks of not applying patches within 30 days. This is the bulk of managing vulnerabilities that most organizations overlook.
A vulnerability management program consists of the following steps:
- Identify vulnerabilities through vulnerability scanning and penetration testing.
- Identify patches for vulnerabilities from vendor announcements.
- If a patch is not available, develop a mitigation plan to reduce the risk of the vulnerability.
- Examine vulnerabilities and adjust CVSS scores for applicability to the organization’s environment.
- Test patches.
- If a patch fails to test, develop a risk mitigation plan to reduce the risk of not applying the patch.
- Implement risk mitigation plans for patch systems with compatible patches and non-applicable patches.
It is the mitigation part of the impact that typically hinders organizations. First and foremost, once a risk reduction strategy has been developed, it should be implemented as soon as possible.
So what can you do to reduce the risk of security vulnerabilities?
Below are some of the risk mitigation strategies that organizations use to mitigate their vulnerabilities. This is not an exhaustive list, but it should provide some insight into mitigation strategies. The mentioned risk reduction techniques can be used alone or in various combinations.
- Create or edit your log analysis rules to look for any indication of risk abuse.
- Use a whitelist or blacklist app to monitor any changes in the device.
- Use the host intrusion detection system (HIDS) to monitor for exploits.
- Lockdown firewall rules further to restrict access to suspicious IP addresses used by exploit attempts.
Ensure your detection processes are running in near real-time so you can get notifications as soon as possible. It may be too late to wait for a daily or even weekly review of the information generated by risk reduction techniques, as the compromise will likely last until then.
You can review the Payment Data Security Essential Patching infographic or the Patching video for PCI DSS patching requirements.
