Information Security Policies (Clause A.5)

This clause provides management guidance and support according to business requirements and applicable laws and regulations where the organization’s management must define and approve their information security policies. These policies must be published and disclosed to the organization’s employees and significant third parties (clause A.5.1.1).

These policies must be frequently reviewed according to established intervals or to ensure the policies’ effectiveness and suitability after major changes (clause A.5.1.2).

Organization of Information Security (Clause A.6)

The organization must also secure all remote access (telework) and mobile devices through the definition of a policy and the appropriate controls to protect the stored and processed information remotely accessed by their employees.

Human Resource Security (Clause A.7)

Organizations must implement appropriate processes to ensure the suitability of their employees and contractors to the roles before they are hired, during their engagement with the organization, and upon termination.

Asset Management (Clause A.8)

The purpose of this clause is to implement a suitable asset management system by identifying and classifying the organization’s assets, assigning responsibilities over those assets, and defining media handling procedures.

First, each organization must identify its assets and define and assign ownership and responsibilities by creating and maintaining an inventory of assets with the relevant information.

According to each asset classification, information and related assets’ acceptable use rules must be defined, documented, implemented, and disclosed across the organization. If applicable, employees and contractors must return the asset in their possession upon termination of their relationship with the organization.

Another important part of asset management is information classification . Organizations must classify and label their information, and the assets that process and store this information according to legal requirements and its value, criticality, and sensitivity. Organizations must also apply the security controls accordingly, including media handling controls and procedures like media transfer or disposal procedures.

Access Control (Clause A.9)

Organizations must implement physical and logical access controls to limit access to their information.

Primarily, organizations must establish an access control policy based on their specific context. This policy must be documented and frequently reviewed, considering the organization’s business and information security requirements.

All access to corporate resources like networks, systems, and applications must be granted on a “need to have” basis. Therefore, organizations must control access to networks and network services so their users can only access the resources they were explicitly authorized to use through user access management. To ensure the proper access rights assignment and revocation to all systems and services, these users must be formally onboarded and decommissioned through a user access provisioning process.

The assignment of privileged access to users must be restricted, monitored, and controlled.

User secret authentication information like passwords and soft and hard tokens must be controlled through a formal management process.

All user access rights must be periodically reviewed and removed upon termination or adjusted upon reassignment.

During the onboarding or reassignment process, users must acknowledge their responsibilities and be responsible for their authentication information according to the organization’s practices in using secret authentication information.

The organization’s access control policy must define how a secure logon procedure controls systems and applications.

Likewise, the organization must also define a password policy and implement a password management system to enforce the policy. The password policy must define password complexity, length, maximum age, minimum age, and reusability.

The use of programs that can override the systems and application controls must be limited and its use controlled.

Finally, organizations must also restrict and control access to their source code of programs.

Cryptography (Clause A.10)

Key management standards and procedures must also be defined to process cryptographic keys during their life.

Physical and Environmental Security (Clause A.11)

Organizations must implement several controls to avoid unauthorized physical access, deliberate or unintentional damage, or destruction of information and systems.

Physical security perimeters must be established to secure areas with critical and sensitive information and implement access control mechanisms and procedures to ensure that only authorized staff is allowed access. These perimeters must also be protected against other external threats like natural disasters, fire, floods, or power supply problems, among others.

In the same way, the remaining facilities must also be secured.

Exterior access points where external persons might enter the organization facilities, like delivery and loading areas, also have the appropriate access controls and, whenever possible, be separated from the processing facilities.

Access points such as delivery and loading areas and other points where unauthorized persons could enter the premises should be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access.

Similar controls must also be implemented to protect equipment and assets and avoid operations disruptions. Access to equipment must be controlled to prevent unauthorized access. Well-maintained equipment must be protected from environmental threats, supported by well-designed power and data cabling protected against interception, interferences, and destruction. These assets cannot leave the organization’s facilities without previous authorization. When that happens, the organizations must also ensure that those assets are protected.

The organization must also implement controls and procedures to ensure that sensitive information and licensed software are not present when the assets are disposed of or reused.

Users have an important role in protecting the organization’s assets by ensuring that the assets are protected before leaving them unattended (e.g., log out or lock screen before leaving their workstations) and removing all items from their desks. These measures must be defined by a “clear screen and clear desk policy” that all employees and contractors must acknowledge.

Operations Security (Clause A.12)

To ensure reliable and secure operations of information processing facilities, organizations must document their operating procedures and ensure that users have access to them if they need to.

Business process, system, and facility changes must be approved, documented, and controlled. Resources must be monitored and their usage forecasted to adjust their capacity to maintain the desired performance.

The organizations must also have distinct development, test, and production environments to prevent unauthorized access, modification of the production environment, and disclosure of production data. Development and test environments should not be populated with production data.

Systems must be protected against malware by implementing several combined anti-malware controls in conjunction with adequate user awareness programs.

Communications Security (Clause A.13)

To ensure the security of data in transit, the organization’s networks must be managed and controlled. The necessary security mechanisms must be identified and implemented and service levels and management requirements regardless of whether these services are assured by organization resources or by third parties.

Networks should be segregated, and information exchange between the organization and third parties must be regulated by established agreements between the parties and in compliance with the organization-related policies and procedures. These agreements must address the organization’s confidentiality and nondisclosure requirements.

System Acquisition, Development, and Maintenance (Clause A.14)

Organizations must ensure that their security requirements are met by the acquisition, development, and maintenance processes. Information security is a core part of information systems during their life cycle, including systems or services provided over public networks.

These information security requirements must be considered in all new information systems and major changes to existing systems.

When the organization’s services or applications use public networks, the organization must implement the appropriate security controls against fraudulent activity, unauthorized access, disclosure of information, and conflicting situations with the service provider.

The organization must take the appropriate measures to avoid their applications or services transactions being illegitimately or accidentally misrouted, changed, disclosed, duplicated, or replayed.

Information security requirements must be integrated into the development process (security by design) by defining a software and system secure development and change policy (and security baselines) applied across the organization. This is done by implementing change control procedures to ensure that all changes are reviewed and tested before going live.

Acceptance criteria must be defined, and new systems or applications, new versions, and major changes must be tested before going live. Security functionalities must be tested during the development process.

Test data must be carefully prepared, and development systems should not be populated with production data.

Software package changes should be avoided or limited to strictly necessary and be formally approved and documented.

Outsourced development must be managed and monitored.

Supplier Relationships (Clause A.15)

Information accessed by suppliers must be protected through the definition and implementation of information security requirements that should be documented in an agreement with the supplier that must clearly state what can be accessed, processed, stored, and communicated by the supplier. The supplier service delivery must be monitored and frequently reviewed, and audited.

Any changes to supplier services must be managed and the risks re-assessed considering the information criticality and the related systems and processes.

Incident Management (Clause A.16)

Organizations must implement information security incident management processes and procedures and establish responsibilities for a fast and effective response to those incidents that should include their expedited reporting through the appropriate channels.

All the organization users, including external parties, must report any potentially suspect action or weakness through the appropriate channels. All information security events (reported or automatically generated) should be evaluated and eventually classified as information security incidents according to the organization’s criteria. Documented procedures, such as incident playbooks, must be established to effectively respond to information security incidents.

The information security management procedures must ensure that any information that might be used as evidence is identified, acquired, collected, and preserved.

The “lesson learned” during the resolution of each information security incident should be used by the organization to decrease the probability and effect of similar future incidents.

Business Continuity Management (Clause A.17)

Organizations must ensure their information security in any adverse situation where the organization’s information is kept secure during a contingency. Therefore, the organization’s business continuity management process must include information security requirements through established, documented, and maintained processes, procedures, and redundant controls, and their effectiveness frequently verified.

Compliance (Clause A.18)

To ensure compliance with legal and contractual requirements, organizations must conform to all matters related to information security with their legal and contractual obligations. To do that, organizations must identify all applicable legislative and contractual requirements, including intellectual rights, and define and document the best approach to meet those requirements for each system and software product.

The organization must protect all records from being lost, destroyed, falsified, accessed, or released without authorization, in compliance with the law, agreements with third parties, and business requirements. The organization must also enforce privacy and protect all personally identifiable information.

Cryptographic controls must be used in accordance with the law and other obligations, and all information security policies, controls, processes, and procedures must be subject to internal compliance reviews. Additionally, independent compliance reviews must be conducted regularly or after major changes.

Information systems compliance with the organization’s policies and standards must also be regularly attested.

ISO 27002

ISO/IEC 27002 provides additional guidance for ISO 27001 relevant controls implementation by helping organizations select and implement adequate security controls and develop their information security management guidelines.

Goal 1: Build and Maintain a Secure Network

The purpose of this main goal is the protection of your outer perimeter. It contains requirements about firewall and router configuration (backups, having only stateful firewalls and anti-spoofing measures, NATing, etc.) and the proper change management mechanism of rules. It also contains requirements about the accuracy of your network diagram and all the data flows in the PCI DSS scope. You must know your environment well enough to ensure its safety and security.

Firewalls must be in place between any untrusted zones (including wireless networks) and cardholder data environment, and they should only allow business-need traffic to ensure a “layered defense” mechanism.

This requirement also mandates the presence of personal firewalls in portable computing devices (personal or company-owned) with connectivity to the Internet when outside the corporate network.

The second objective is to ensure the security of the system components (such as servers, databases, workstations, network devices, et al.). Apart from the mandate to change the vendor-defaults on the systems and applying hardening to the components, the standard also accepts that the organization may use an insecure implementation, such as having a legacy system that, if patched, the “nuke codes” will be revealed, or an ancient Java implementation that cannot establish a secure channel between two peers. However, in this case, the organization needs to implement “additional security features” to any insecure required service, such as encrypting the data itself while transferring it in a cleartext channel or implementing a network access control (NAC) solution that prevents an unauthorized device that may sniff the environment. It should be noted that this latter example is not valid for external networks but only internal networks that you have control over.

The second part of “know your environment well” refers to the inventory of the devices in the PCI DSS scope. The organization needs to maintain an up-to-date asset inventory. It would be very useful to keep track of the hardware and software, as the organization needs to take action on any end-of-life/end-of-support hardware and software.

It should also be noted that this requirement aims to minimize the risks and effects of compromise by instructing to only enable the necessary services, protocols, daemons and implementing one primary function per server. For example, consider a server that hosts both web applications and the database. If somehow the web server is compromised, it will be only a matter of minutes, if not seconds, to infiltrate the database. Whereas in a three-layered structure (e.g., front webserver, application server, database server), it may not be so easy to gain access to the data itself, if you have implemented additional security features, of course.

Goal 2: Protect Cardholder Data

Data-at-rest and data-in-transit protection are mentioned in this goal. The main objective of this goal is to safeguard the cardholder data, wherever it is stored or transferred to any untrusted location. The easiest method you may think of should be straightforward. Do not store cardholder data unless it is a must for you or your business.

Organizations that do not store cardholder data often get “not applicable” or “not tested” in many assessments, which is perfectly fine at the end of the day. However, if you are not sure if you are storing card data received from a defined or an unintended channel,⁶ you can use various tools to discover cleartext card data in many formats.

According to requirement 3.1, you should use these tools to perform discovery checks every quarter to make sure that no cardholder data is stored beyond its retention period. However, it is up to the organization to define a retention period based on business or legal requirements. Most financial institutions, such as banks, have five to ten years’ retention periods legally defined by their primary regulator. Whereas some service providers can choose to have card data not be stored in any of their systems so that related requirements become “not applicable.”

Most of the solutions can discover card data stored in a large number of different storage formats, including office documents, email clients, zip files, databases, file servers, shadow volumes, memory, audio files, and scanned files using optical character recognition (OCR).

The long string starting with f3ee23 can be cracked quickly, even with a home PC, if you have the rainbow table for SHA512 for all possible values. The preparation of the rainbow table would be pretty easy, considering that the original PAN is a 16-digit phrase. Whereas, if you add a “salt” to the PAN, it would take one octillion (10⁴⁸) years to brute force this hash.

Hashing mechanisms can be used for fraud detection, where the fraud analyzer tool only needs a representation of the cardholder data, not the data itself. In the same way, the hashing can validate if the user has entered the correct PAN. The stored hash value is compared with the hash value of the user input if they match. Voilà.

The first six digits contain the issuing network (a.k.a. payment brand), the Issuer Identification Number (IIN), sometimes referred to as the Bank Identification Number (BIN), and the type of the card (debit, credit, or prepaid). The last four digits give a good idea of who the customer is to the issuer bank. Although mathematically possible, there should not be two different individuals having two different cards with the same bank and same card type and ending with the same last four digits.

It is worth noting that hashed and truncated values should not be in the same environment (as per requirement 3.4.e), as it is quite trivial to find the actual card data even with the first digits of the hash data.¹⁶

Tokenization is substituting a sensitive data element with a non-sensitive equivalent, referred to as a token, which has no meaningful value for attackers. Unlike encryption, the tokenization process is not based on mathematical encryption algorithms with keys and such. It depends on the token vault (or card data vault), where the original card data is stored and mapped to the token. Of course, to secure the data in the token vault, the sensitive card data can be encrypted, but this is apart from the tokenization process.

In most use cases, tokens can be used one-to-one with the card data. Most card data fields accept only 16-digit numerical characters, so the tokens can also be adjusted to be 16 digits. The advantage of tokenization over encryption is that it can be decrypted if you have a large enough set of encrypted data (since it is a mathematical process). Whereas, there is no mathematical connection to the real sensitive data they represent for tokenization.

PCI SSC released an information supplement for tokenization¹⁷ that describes its implementation and security considerations.

Encryption is the process of using a mathematical algorithm to transform plaintext into a non-readable form called ciphertext . An algorithm and at least one key are required to encrypt and decrypt the information. Keys can be for data encryption (DEK) and key encryption (KEK).

The “secret key” is the most crucial element in this process, so it can also be encrypted by a key encrypting key (KEK) to protect it further. A KEK should be at least as strong as the data-encrypting keys they protect. Both data-encrypting keys and key-encrypting keys should only be accessed by individuals having business needs: key custodians. They are responsible for managing the encryption of the environment. They must sign a formal document stating that they fully understand and accept their key management responsibilities. The access to the cryptographic keys must be restricted to reduce the possibility of a compromise. The keys must be stored within a secure cryptographic device, typically a hardware security module (HSM) or PTS-approved point-of-interaction device POS devices. Their distributions need to be secure; they should not be distributed in the clear and should only be distributed to key custodians.

Key management also includes the key management cycle , meaning that every key must have a cryptoperiod . The “life” of a key ends at the end of a cryptoperiod or when it is compromised or suspected of being compromised. In both cases, encrypting data with those keys must be ceased, and new keys must be generated to encrypt new data. The old keys must be securely archived with a KEK to access or verify old data.

In cryptoperiods, the lifespan of a key is typically based on many factors such as key length, block size, algorithm, the volume of data encrypted, and the threat. NIST Special Publication 800-57 has a helpful recommendation document¹⁹ for key management and cryptoperiods. Key custodians (or key managers) should decide on the cryptoperiods based on their needs and the environment.

The second part of the goal is to ensure confidentiality in transit of the card data. When card data is transmitted over open, public networks, secure versions of protocols (i.e., TLSv1.1 or above) with only trusted keys and certificates should be used. This ensures that the card data remains confidential if traffic is intercepted or sniffed. Open networks can be the Internet, any wireless technologies, including 802.11 and Bluetooth, cellular technologies, such as Global System for Mobile communications (GSM), code-division multiple access (CDMA), General Packet Radio Service (GPRS), and satellite communications. For example, if POS devices are connected to the Internet through 4G/5G, either the channel should be TLSv1.1 or above, or the data itself is encrypted per requirement 3. In general, both are applied to POS devices; that is, the data itself is encrypted with trusted acquirer keys, and most of the POS devices, if not all, support TLSv1.1 or above.

Another apparent example would be ecommerce merchants that accept card data. Their secure acceptance page (HTTPS) should be TLSv1.1 or above. To change the registry encryption settings on Windows servers, organizations can use IIS Crypto.²⁰ One popular online tool to analyze the strength of the TLS Certificate is Qualys SSLLabs²¹ (Figure 2-2). For offline needs, Wireshark²² can sniff the network interface and analyze the strength of the certificate. More examples can be found in Chapter 9.

If the organization uses wireless communication in internal networks and is included in the scope, then the same strong cryptography principles must be applied. Weak encryption, such as SSL or WEP, should not be used as a security control for authentication or transmission.

The last part of the requirement disallows sending card data via end-user messaging technologies such as emails, chat, and instant messaging. These technologies are very susceptible to packet sniffing, and therefore card data can be compromised. If a business needs to transmit card data via those channels, card data must be secured (i.e., encrypted, hashed, truncated, or tokenized). In addition, there must be written policies and procedures to prohibit sending data in the clear.

The standard gives flexibility for the users of legacy POS devices, where TLSv1.1 or above is not possible for the channel encryption to use SSL or early TLS if it can be verified that these devices are not susceptible to any known SSL/TLS exploits. Organizations need to fill Appendix A2 of the PCI DSS, in this case.

Goal 3: Maintain a Vulnerability Management Program

This set of requirements is about protecting PCI DSS scope systems against malware and managing antivirus software or programs. The standard requires that antivirus software should be installed and kept updated on all systems that can be commonly affected by malware, viruses, worms, ransomware, Trojans, rootkits, and so forth. The “commonly affected” systems are susceptible to malware. In the past, it was thought that this impacted only Windows devices, however, now that is not the case. Organizations must consider having antivirus or anti-malware solutions for Linux, Mac, Android, and POS devices. There was recently discovered malware that exploits critical vulnerabilities on those devices. Security professionals should perform annual risk evaluations on their environment and systems, whether their systems are susceptible to malicious software or not.

They should also follow vendor security notifications, released CVEs, and security groups to determine whether the systems are at risk. Five to ten years ago, an AV solution would not be required for an Android mobile device. However, currently, there are more than enough evolving threats to these devices to consider installing an antivirus app on your personal mobile device as well.

The standard also considers that antivirus solutions should be capable of detecting, removing, and protecting against malicious software. Antivirus software and its definitions must be kept current and updated and generate logs as per the logging requirements. In addition, it should not be altered or disabled by users. Organizations may consider using endpoint detection and response (EDR) tools to proactively detect and stop malicious behavior. They are not dependent on signatures but behavioral analytics, machine learning, and heuristics. Their primary working mechanism collects data, analyzes processes, detects anomalies, and stops them before they can move horizontally through the network. EDR tools can also be very helpful for forensics and threat hunting purposes. They collect a significant amount of relevant information to detect the anomaly and notify IT security staff to investigate in detail.

Conventional signature-based AV solutions can also be applied to comply with the requirement. However, in that case, signatures need to be kept current to somehow overcome “zero-day” attacks, need to perform periodic scans, and as always, produce logs. The easiest approach to maintain those tools would be through centralized management. Security professionals keep track of the AV versions, signatures, online/offline status of the AV agent, and collect logs.

The second part of the goal is to develop and maintain secure systems and applications, focusing on vulnerability and patch management and secure software development.

Whenever you have sensitive (or valuable) data, you become the target of malicious actors. Those actors always try (and sometimes succeed) to exploit every vulnerability they find to infiltrate into systems, exfiltrate sensitive data or cause a disruption. This is what makes timely patching essential to the overall security posture of the Cardholder data environment. Security vulnerabilities that are not patched in a timely manner can cause ingress points for hackers, or worse, possible paths for lateral movement through the network. The standard mandates that the organization must have an accurate and efficient vulnerability management program that identifies the vulnerability classifies the risk, remediate, or apply patches in appropriate periods of time, having retests for the finding and keeping the systems up-to-date.

The same principle applies to developed software applications. The standard mandates that all internal and external applications be securely developed, following the industry-accepted best practices and security as an indispensable part of the Software Development Life Cycle (SDLC).

Even if the whole process contains security, there are always new threats. The standard also acknowledges that and mandates using a web application firewall or periodically reviews or tests the systems via automated or manual web application vulnerability assessment solutions. Web application vulnerability assessment is different from penetration testing because web application vulnerability is more focused on web application–related attacks, whereas penetration testing can be done on all systems.

Web application firewalls are security devices that filter or block non-essential traffic at the application layer and monitor the actual web traffic for potential application-layer attacks. Regular firewalls typically have rulesets that allow HTTP or HTTPS web traffic to pass through to web servers without any inspection of the request. Conversely, web application firewalls can inspect the request (or payload) and detect if it contains any malicious code such as cross-site scripting (XSS), injection attacks (such as those using SQL), or forged HTTP requests that do not conform with IETF specs.²⁴ Most web applications can also react to certain issues, such as providing a false web server name or hiding it completely to somehow increase the efforts of malicious intent.

Goal 4: Implement Strong Access Control Measures

In this goal, the primary idea is to provide proper identity management for users and ensure that only authorized users with a valid business need are accessing the card data (logically and physically) to minimize the risk of compromise.

As a principle, card data should only be accessed by individuals having a valid and approved business “need to know.” To achieve that, first, we need to properly identify the users by making sure that everyone uses a unique ID and a strong password that is difficult to crack. This also applies to the non-logical world, where we use badges, locks, and keys. Physical access to systems that store, transmit, or process card data should only be allowed to users with a business need by using either CCTV cameras or access control mechanisms (or both). PCI DSS does not disallow visitors, but all visits must be logged with identifiable information, and visitors must be distinguishable from on-site personnel, for example, by wearing a different colored badge, and they have to be escorted.

When assigning privileges to users, the least privilege approach should be used, where only necessary rights should be given, and for others, it should be “deny all.”

In addition, this requirement mandates that user accounts should be immediately revoked for terminated users, and they should be disabled if they are not active for 90 days.

One other highlight of this requirement is multi-factor authentication (MFA). The organization needs at least two of the three proper user-authentication mechanisms for any non-console administrative activity, either remote or on-premises. It should be noted that using one factor twice is not MFA. PCI SSC has comprehensive guidance on MFA³³ published right after version 3.2 introduced a new requirement to use MFA on administrative activities in corporate networks.

The last part of this goal is physical security. It mandates that any physical media containing cardholder data, including backups, must be secured during use, accounted for, and securely destroyed when no longer needed. Protection of devices that capture card data, such as POS devices or PIN PADs, must also be maintained. For example, an accurate inventory must be present and proper training should be given to the users on detecting tampering.

Goal 5: Regularly Monitor and Test Networks

The fifth goal is to make sure that the systems, components, in-house built software are tested and monitored for any malicious activity that would compromise the system. The difference between this goal and goal 3 is the amount of manual work involved.

The first section contains the logging requirements for the environment. Organizations should build up a logging mechanism that would monitor all required activities so that breach attempts can be identified, tracked, notified, analyzed, and, if breached, the root cause can be found. After finding the root cause, appropriate security measures can be set up to prevent further cases.

Organizations are required to ensure the integrity of the logs by using file integrity monitoring (FIM) or a change-detection tool. As mentioned, one of the first things that hackers do is try to cover their trail. This can be effortlessly achieved by erasing or changing the logs in an unprotected environment.

The second part of the goal refers to the analysis of the environment to ensure that possible infiltration points are thoroughly and regularly tested and remediated.

One infiltration method is to somehow connect or attach an unauthorized wireless access point to the network or the system, so the malicious users gain access to the network. Wireless access points broadcast SSIDs, and it is possible to scan the environment for rogue wireless networks and identify the device’s location by checking the signal strength and noise levels. This manual approach is time-consuming for most organizations, where a person needs to visit every floor of the buildings in scope with a laptop to list the unknown wireless devices. To solve this problem, automated processes can be implemented. Some wireless access point vendors provide rogue wireless network scanning that lists “other” wireless devices detected in the organization’s premises. It is possible to filter out the known ones, which yields only the ones that need investigation. Additionally, to reduce the risk of these attacks, organizations should also install an NAC solution to the environment and disallow any unknown, unauthorized device to be connected to the environment.

Another infiltration threat surface is the external and internal networks. Although goal 3 mandates the implementation of a web application firewall (WAF) or perform web application scans, those scans would not find operating system vulnerabilities, and hackers can easily exploit those weaknesses to gain full control of the system. Hence, it is also crucial to run external and internal vulnerability scans at least quarterly and after any significant change in the network or system.

External vulnerability scans need to be performed by Approved Scanning Vendors (ASV)³⁷ whose scanning solutions are tested and approved by PCI SSC. ASVs are qualified and responsible companies to perform external vulnerability scanning in accordance with PCI DSS requirements and the ASV guide.³⁸ ASV scans are automated scans initiated from the Internet, where some manual review is required for the final quarterly attestation report. ASV scans should not impact the organization’s normal operation, and they should not penetrate the environment or change it intentionally. ASVs are also responsible for getting feedback from the organization on the findings or disputed scan results since the scan can produce false positives or findings that require more evidence from inside the network.

Moreover, although the scanned organization is ultimately responsible for the scope of the scan, ASVs need to consult with the organization if ASV discovers an external component that is not defined as in the scope defined by the organization. ASV scans should be non-intrusive and include host and service discovery with an operating system and service fingerprinting. The scope should be not only the public-facing web applications but also any public-facing system or system components such as firewalls, routers, DNS, and email servers, including their operating systems, POS software, and remote access solutions.

Internal vulnerability scans are important to quickly identify vulnerabilities, as there would be some firewall restrictions to certain ports during external vulnerability scans. In contrast, internal scans should be performed with none or very limited restrictions to the ports, making it easier to detect weaknesses. Many organizations use credentialed (or authenticated) scans to increase the detection rate, where a privileged account is provided to the vulnerability management tool. This tool uses authenticated remote queries (WMI, for example, for Windows machines or remote SSH commands for Linux), and identify exact versions of the services, applications, patches applied can be gathered and compared with the vulnerable versions. Plus, authenticated scans collect more information from the system, such as a list of the processes, users, or listening ports, which provides more information to the tool to detect exposures accurately. This process, however, can be frustrating in large organizations where credentials are mixed and managed by multiple different administrators. Nowadays, with the introduction of host-based vulnerability scanner agents, there is no requirement to enter credentials to address this constraint. It is even possible to scan the systems daily. It should also be noted that most of the vulnerability management vendors now support integration with privileged access management (PAM) tools or password vaults, where only access credentials to the vaults are provided, not the credentials to the actual system.

Internal vulnerability scans must be performed by qualified individuals, internal resources, or external third parties. For internal resources, organizational independence is required. To not violate segregation of duties, scans should not be performed by the individuals managing the systems.

In goal 5, there are also penetration testing requirements. Penetration tests are different from automated scans. It is a very manual process yet a more efficient method to find the actual weaknesses in the systems. Automated scans only report the known vulnerabilities, and most of them are signature-based. Whereas, in penetration tests, following specific methodologies, the tester tries many ways to infiltrate the system and hop to another system to make new attacks or exploit any privilege escalation vulnerability to penetrate further into the environment.

PCI DSS mandates the implementation of a penetration testing methodology that covers both application and network layers in the entire cardholder data environment and other connected critical systems. PCI SSC published comprehensive guidance on penetration testing,³⁹ which can be used as a starting point for creating such a methodology.

Penetration testing methodology should also cover segmentation controls. Although it is not a requirement when isolating cardholder data environment from other non-related networks, it can significantly reduce the PCI DSS scope. Hence, the effort needed to be fully compliant and reduce the risk.

Goal 6: Maintain a Policy That Addresses Information Security

Prioritization