Whether you are aware of it or not, hackers can exploit your network’s vulnerabilities and gain access to your sensitive data.
Web server shortcomings, e-mail clients, POS applications, and operating systems can allow attackers to access your systems. Installing security updates and patches for cardholder systems or sensitive data environments will help fix many of the newly found bugs and vulnerabilities before attackers have a chance to exploit them.
But to fix these vulnerabilities, you need to find them first. For this, you need to scan your systems by testing for vulnerabilities.
An essential requirement of the Payment Card Industry Data Security Standard (PCI DSS) is 11.2, also known as the PCI vulnerability scanning requirement. This requirement requires companies to perform internal and external vulnerability scans four times a year in three months and after any significant network changes, irrespective of its size.
But PCI DSS requirement 11.2 is not just about scanning network components and servers to identify vulnerabilities before attackers. It is also about improving and improving processes to stop vulnerabilities from reappearing.
It takes more effort than most people realize to meet PCI DSS requirement 11.2. Here are helpful hints as you can apply it to meet PCI DSS vulnerability scanning requirements.
How Vulnerability Scanners Work
An internal or external PCI DSS vulnerability scan checks the configuration of specific devices and software through internal or external IP addresses, such as ports and services, to check for vulnerabilities.
PCI vulnerability scanners provide different tools and scripts designed for vulnerability testing. Such tools vary but may include software operated by the Certified Scan Provider (ASV), command-line files, GUI interfaces, and open source technologies.
Scan tools run a series of control scenarios on your networks, commonly known as a vulnerability scan, which can take 1-3 hours for a quick scan or over 10 hours for a more extensive scan. Scan times may differ depending on your environment.
Control scenarios are designed to define device settings, configurations and behaviors that can lead to exploitable vulnerabilities. For example, if your scan examines operating system versions and finds an outdated Windows XP operating system, that operating system will be marked as vulnerable.
Vulnerability scanning is designed to be non-intrusive. It scans merely alerts and gives you a logged overview of suspected vulnerabilities for you to take action. Vulnerability scanning, unlike penetration testing, does not exploit vulnerabilities in your network and does not take testing further.
As you check your scan results, you will most likely find CVE (common vulnerability and exposure) numbers in your notifications. If not provided to you by the scanning provider, it will be easier for you to become familiar with the National Vulnerability Database to examine CVE records to identify and prioritize risks.
What are the Differences Between Internal and External Vulnerability Scans?
PCI DSS requires two independent PCI vulnerability scanning methods, internal and external. Because internal and external scans evaluate a network by scanning it from different perspectives.
An external PCI vulnerability scan checks for vulnerabilities at the end of your network or website. An internal vulnerability scan looks for network vulnerabilities by simply scanning local resources within your network.
Generally, only ASV scans are considered sufficient for PCI DSS compliance concerning internal and external vulnerability scanning. Still, both external ASV scans and local vulnerability scans are required for PCI compliance.
Your ASV will not perform your quarterly internal PCI vulnerability scanning. ASVs only perform external security scans. Your ASV may also install an internal vulnerability scanning tool on your network, but this does not eliminate the need for internal and external scanning.
Therefore, it is best to double-check that you have performed your internal scanning and followed your vulnerability management procedures.
You can choose from the following options to meet internal vulnerability scanning requirements:
- Select your ASV or another service provider for a built-in vulnerability scanning tool.
- Download and use an open-source internal vulnerability scanning tool from the internet.
- Purchase Nessus or Qualys and use.
Remember that the device you will use must be installed and used by a professional even after you purchase or update it.
Your company is fully responsible for the vulnerability scanning process, even if the security scans are outsourced. In short, it is your job to ensure compliance with PCI DSS.
What Does It Mean to Use ASV for External Network Scans?
An ASV company certified by PCI must perform external network scans, and there are no exceptions to this. You can find the list of more than 100 ASVs on the PCI SSC website and work with the ASV company suitable for your company, among many options.
Approved Scan Vendors (ASV) are authorized companies that provide security scanning services approved by PCI SSC to perform external network tests. ASV companies enter the certificate renewal process every year.
During the annual recertification process, each ASV must run the PCI scan tool on sites full of vulnerabilities approved by the PCI Council to check for vulnerabilities. The tool has identified an overlooked and to pass the test successfully.
You can view the authorized ASV list here.
After your scan is completed, ASV provides you with the result report. What happens after the scan and report are complete is entirely up to you. You are responsible for correcting any errors that may be found. ASV will not provide you with an approved and valid report without correcting the weaknesses in the report.
What is a Qualified Internal Source for Vulnerability Scanning?
PCI DSS states that a qualified person should perform internal vulnerability scanners and be partially independent of the scanned system. For example, if the browser is the same person as the person who fixes the discovered vulnerabilities, a conflict of interest is likely to occur at this point.
For example, choose to perform an internal scan of your firewalls. You can run the scans from a qualified security professional, your ASV, or a professional employee who is not subject to firewall management.
Having only one staff member is not a valid reason. If the working device is in control of it, it should not manage scans.
How Should Many Security Scans Be Performed to Meet PCI DSS Requirements?
PCI DSS requires three types of network scanning. PCI DSS Requirement 11.2 covers security scans in general. It states that you should run internal and external network vulnerability scans every three months and after any significant network changes. Qualified internal or external parties must conduct security scans.
Testing procedures for internal security scans should verify that internal scans have been performed every four months in the last 12 months and that rescans have occurred until all “high risk” vulnerabilities identified in PCI DSS requirement 6.1 are resolved.
External scans must be done through an Approved Scan Vendor (ASV)
According to PCI DSS requirements, every company must perform internal and external scans every three months regardless of size. In other words, you need to do a total of eight scans per year for external and internal scans.
Many organizations perform four external vulnerability scans each year but often cannot perform any internal vulnerability scans because they forget. Some treat vulnerability scanning as an occasional, isolated point check process that relies heavily on resolving urgent problems.
Remember, you cannot comply with PCI DSS requirement 11.2 until you have performed at least four external network vulnerability scans per year, one per quarter, and once per quarter, for a total of four internal network vulnerability scans per year.
- Quarterly External Vulnerability Scans (PCI DSS Requirement 11.2.2) – These scans must be performed at least every three months by an external scanning company certified as an Approved Scan Vendor (ASV) by the PCI council. An internal employee of your organization cannot perform ASV scans. All external IP addresses within your PCI DSS scope must be included in these scan reports. The purpose of this requirement is to identify all vulnerabilities in your systems that may be present and exploited by an attacker over the Internet.
- Quarterly Internal Vulnerability Scans (PCI DSS Requirement 11.2.1) – As the name suggests, internal vulnerability scans must be performed within your networks at least every three months. Internal network vulnerability scans can be performed by anyone experienced in vulnerability scanning. Most organizations use an internal worker to perform these scans with an automated vulnerability scanning solution such as Nessus, Qualys or OpenVAS. The purpose of this requirement is to identify any vulnerabilities within your network that could be exploited by an attacker. All “critical” or “high” vulnerabilities detected as a result of the scan must be resolved and verified with rescanning reports.
- Annual Penetration Testing (PCI DSS Requirement 11.3) – A qualified penetration tester should carry out penetration testing at least once a year to verify that these complex manual methods can not be used to gain unauthorized access to your systems. Penetration tests are usually performed by a third party but can also be done by a qualified in-house person with organizational independence. The person performing the penetration test should not be the same person responsible for configuring or managing the systems under test. The penetration test should be done over the Internet to external networks and from an internal perspective to your internal network.
- Segmentation Test (PCI DSS Requirement 11.3.4) – Segmentation Tests are special internal penetration tests required for organizations using segmentation to isolate cardholder data environment networks from other internal networks completely. Segmentation tests verify that access to in-scope networks is not allowed from out-of-scope networks. Segmentation tests should be conducted annually for merchants and every six months for service providers. If you are not implementing any segmentation in your PCI environment, you do not need to perform segmentation testing.
All the above scanning requirements should be repeated frequently. Additionally, each of these scans should be repeated after significant changes that could introduce new vulnerabilities in your environment.
Rescans are required to ensure that the changes do not introduce new vulnerabilities in your environment. Keeping the reports of the above scan types for a few years will help you check in case of any problems. You can also provide them as proof of your PCI DSS compliance if desired.
Which Systems Should Be Scanned?
Technically, PCI DSS only requires you to perform vulnerability scans on covered networks, processes, and systems. It is, therefore, crucial that you understand and determine your PCI scope.
At this point, if you have any doubts, you may need someone to help determine your PCI and scanning scope. Otherwise, your scans may miss essential networks. If you want to validate PCI compliance and your scan, you need to know what needs to be scanned and produce results accordingly.
Suppose you have a flat network without segmentation. In that case, you don’t have to worry about PCI coverage because flat networks do not have segmentation capability, which means scanning the entire network, and scanning must be done for all network components as the entire network will be included in PCI scope.
In this context, it is necessary to pay attention to how complex networks that benefit from segmentation changes throughout the year and adapt vulnerability scans accordingly.
Should You Perform a Security Scan Again After Network Changes?
PCI DSS requires you to perform vulnerability scans annually and after every significant change. So what does a big difference mean, and what does it mean?
PCI DSS states that a significant change depends on how you configure the system. In general, however, if an update or change may require access to cardholder data or affect the cardholder’s data environment protection, this can be considered a significant change.
A new security scan is required in the following situations:
- When you add or change something that could introduce new vulnerabilities in your environment
- If high-risk findings are reported in your risk analysis
- If you are unsure or undecided about the effects of change
Below are a few key examples of changes:
- Adding new servers or system components to the CDE
- Changing interfaces
- Move cardholder data to a new server
- Upgrading or updating products
- Changing your firewall device or software
- Adding new or different middleware
- Removing systems that store cardholder data
- Adding encryption implementations or new methods
- Changing the network topology
- Changing firewall rules
You don’t have to worry about small changes. Your eight internal and external scans during the year will include minor changes.
Below are a few examples of non-significant changes:
- Replacing file integrity monitoring (FIM) software
- Replacing antivirus products
- Removing dismissed administrative personnel from the records
Security scans should be carried out within a reasonable time after significant changes. For example, if you make significant changes to your system after your quarterly external scan, you should not wait for your next quarterly external scan. You should test changes and perform vulnerability scans as soon as possible.
What are the differences between PCI DSS penetration tests and PCI DSS vulnerability scans?
Penetration experts observe your network environment like a hacker. After finding possible vulnerabilities, it tries to hijack systems using vulnerabilities. In simple terms, pentesters try to break into your company’s network to find gaps in the defense.
In vulnerability scans, security weaknesses are tried to be detected by using automated tools. When security vulnerabilities are detected, the test is not taken to the advanced stage; only the findings found are reported.
PCI DSS Requirement 11.3, which applies to SAQ C and SAQ D, requires internal and external penetration testing at both the CDE network and application layers. However, PCI DSS is not limited to penetration testing. Any organization wishing to take an honest look at information security environments should conduct a penetration test.
In summary, both internal and external vulnerability scanning is not the same as penetration testing.
To understand the difference more clearly, we can look at the following two main variations:
- While vulnerability scanning is done with automated tools, penetration testing requires a live person to investigate the network’s complexity actively.
- A vulnerability scan only reveals potential vulnerabilities. During a penetration test, the tester should check the vulnerability and find the vulnerability’s root cause providing access to protected networks or stored sensitive data.
Practically, PCI DSS vulnerability scans and penetration tests must be implemented to ensure maximum network protection. Vulnerability scans provide information about your network security weekly, monthly or quarterly, while penetration tests are a more detailed assessment of your overall cybersecurity posture.
Vulnerability scans should be ongoing.
Vulnerability scanning is probably necessary, even if your business doesn’t process, store, or transfer credit card data. Whether you are processing credit card data or not, if you have any public assets connected to the internet, you must scan your environment.
If you have significant weaknesses in your systems, you need to be aware of it. Otherwise, a hacker could potentially bypass your protections and endanger your systems.
Vulnerability scans are one of the easiest ways for any organization to identify vulnerabilities in their network. The main thing to consider is how you can increase your vulnerability management process’s effectiveness based on the effort, time, and money you put into it.