You are here

Requirement 6: Develop and maintain secure systems and applications

Subscribe to Syndicate
Develop and maintain secure systems and applications

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
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.

 
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:
  • checking daily for updates to TM processes and/or
  • automatically update affected components (optional).
You may need to enable a specific outbound ports for update checking to www2.artsman.com.

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.

6.3 Develop internal and external software application (including web-based administrative access to applications) securely, as follows:
  • in accordance with PCI DSS (for example, secure authentication and logging)
  • based on industry standard and/or best practices.
  • Incorporating information security throughout the software development life cycle.

Note: this applies to all software developed internaly as well as bespoke or custom software developed by a third party.

 
6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.  
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:
  • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices
  • Code reviews ensure code is developed according to secure coding guidelines
  • Appropriate corrections are implemented prior to release
  • Code-review results are reviewed and approved by management prior to release
 
6.4 Follow change control procedures for all changes to system components. The procedures must include the following:  
6.4.1 Separate development/test and production environments and enforce the separaton 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:
  • Train developers in secure coding techniquies, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory
  • Develop applications based on secure coding guidelines

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
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:
  • Reviewing public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
  • Installing an automated technical solution that detects and prevents web-based attacks (for example web-application firewall) in front of public-facing web applications, to continually check traffic

AMS updates NGINX builds as needed (and config settings) to respond to newly reported threats.

AMS uses SPI for all web traffic internally.

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.