Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
Section | PCI Requirement | Comments | Provided by Artsman Cloud |
6.1 |
Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as 'high', 'medium', or 'low') to newly discovered security vulnerabilities.
Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected. Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization's environment and risk- assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a "high risk" to the environment. In addition to the risk ranking, vulnerabilities may be considered "critical" if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data. |
SPLIT
|
|
6.2 | Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.
Note: Critical security patches should be identifies according to the risk ranking process defined in requirement 6.1 |
There are two settings in Company Preferences Other Tab that enable:
Refer to the list of past and present issues to assist you updating your own vulnerability assessment. We regularly review Postgres, NGINX & OpenSSL to provide the latest patches in each version our installers. |
SPLIT
|
6.3 | Develop internal and external software application (including web-based administrative access to applications) securely, as follows:
Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party. |
SPLIT
|
|
6.3.1 | Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. | N/A | |
6.3.2 | Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
|
N/A | |
6.4 | Follow change control procedures for all changes to system components. The procedures must include the following: |
SPLIT
|
|
6.4.1 | Separate development/test and production environments and enforce the separation with access controls | ||
6.4.2 | Separation of duties between development/test and production environments | ||
6.4.3 | Production data (live PANs) are not used for testing or development | Only specified test cards are used | |
6.4.4 | Removal of test data and accounts before production systems become active | ||
6.4.5 | Change control procedures for the implementation of security patches and software modifications. Procedures must include the following: | ||
6.4.5.1 | Documentation of impact | ||
6.4.5.2 | Documented change approval by authorized parties. | ||
6.4.5.3 | Functionality testing to verify that the change does not adversely impact the security of the system. | ||
6.4.5.4 | Back-out procedures. | Development uses git and branches so that changes can be reverted. | |
6.5 | Address common coding vulnerabilities in software development process as follows:
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements. |
Refer to Current OWASP Top 10 |
SPLIT
|
6.5.1 | Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws | ||
6.5.2 | Buffer overflow | ||
6.5.3 | Insecure cryptographic storage | ||
6.5.4 | Insecure communications | ||
6.5.5 | Improper error handling | ||
6.5.6 | All 'high risk' vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). | ||
6.5.7 | Cross-site scripting (XSS) | ||
6.5.8 | Improper Access Control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions) | ||
6.5.9 | Cross-site request forgery (CSRF) | TM server ensures all <form> have CSRF token for prevention. | |
6.5.10 | Broken authentication and session management | Theatre Manager web services uses encrypted secure cookies that are httpd-only. | |
6.6 | For public-facing Web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
|
AMS updates NGINX builds as needed (and config settings) to respond to newly reported threats. AMS uses SPI for all web traffic internally. |
YES |
6.7 | Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. |
SPLIT
|