As the section title implies, requirement 6 is a hodgepodge of different but related requirements for securing systems and applications. Let's look at the 3 important subgroups: Vulnerability Management, Change control, and Software Development Requirements.
First, PCI DSS mandates the creation of a process to identify vulnerabilities using reputable outside sources. For organizations that use mostly components (hardware and software) from very few vendors, this may mean subscribing to mailing lists, newsgroups or RSS feeds (for example, from vendors such Microsoft, Cisco, etc.). Then, we must assign a risk ranking to all vulnerabilities (from a vendor list, external or internal testing). The latter part of this requirement will also apply to vulnerabilities identified in internally developed software (see 6.3, described shortly). The risk ranking methodology should be based on industry standards and must include a risk level consisting of, at a minimum, high, medium and low rankings. Any vulnerability with a risk level of 'high' or above, should be remediated within one month. Unless you are an experienced risk professional, please do not create your own methodology but adopt an existing one. There are many industry standards, from CVSS (Common Vulnerability Scoring System), to those provided by SANS, OWASP and others. Whichever methodology you use, make sure that your methodology is properly documented and used consistently.
Now that you have identified vulnerabilities, you need to address (or remediate) them. PCI DSS mandates installation of critical patches within one month.
Any change to any component must go through a formal change process regardless of whether the change is a patch identified during the vulnerability identification process, a configuration or software change, or the testing of systems. The change control process serves as a check against both insider threats as well as the law of unintended consequences, and must as of PCI DSS 3.2 validate impact of changes on the PCI DSS environment. The law of unintended consequences can be compared to the adage that "the road to hell is paved with good intentions". Separation of duties between test and production system and personnel roles are paramount. In no case should production data which contains CHD and full PANs be used in testing or development environments.
Often emergency change control processes exist which may allow for a verbal authorization first, but mandate proper documentation following the standard/regular process within a very short timeframe (days, not weeks).
Software Development Requirements
In an information world, custom developed software is often a business differentiator for organizations. But the focus is generally on functionality and often does not take into account security until much later in the process. If organizations the size of Microsoft and Adobe end up with vulnerabilities, how improbable is it that smaller organizations will not face the same issues? Most pentesters will attest that insecurely coded applications (as well as misconfigured systems) are often the way we manage to penetrate networks and systems. So how does the PCI SSC recommend we address this?
First, an organization must have a Software Development Life Cycle policy and process that is based on industry best practices. This can include the standard waterfall process where each phase (requirements analysis, design, implementation, testing, promotion to production) must be finished and approved before moving on to the next one, or even agile development processes (which release to production much faster and often) such as Extreme Programming (XP), Scrum, etc. Information security should be included in all phases of the process (requirements analysis, design, implementation, testing and promotion to production). Note that this applies to all organizations whose software (purchased or internally developed) is used in a PCI DSS environment. All such applications must also meet other PCI DSS requirements such logging, authentication, etc. Many sub-requirements must be in-place that are further covered in section 3.7.6 of volume 3.
This is where buying PA-DSS certified software can help reduce some of those controls. PCI PA-DSS software is software that has gone through an evaluation by a PA-QSA. A PA-QSA is a like a QSA for Software Applications used in a PCI DSS environment. The organization implementing a PA-DSS validated application must follow the implementation guide that comes with the application and place it in a PCI DSS compliant environment. All other 6.3. and 6.5. requirements (and possibly 6.6) are taken care of by the PA-DSS certification, simplifying the organization's compliance efforts.
PCI DSS covers basic common web-application coding vulnerabilities. It mandates the development of secure coding guidelines and the training of developers on those topics. Sub-requirements closely align to the OWASP top 10 (updated in 2013, just prior to the release of PCI DSS 3.0) and one could say they were at the very least inspired by that list. Other industry standards could be used for the organization guidelines, such as the SANS/CWE top 25 (Common Weakness Enumeration, the top 25 software errors list produced conjunctly between the SANS institute and MITRE Corporation, a not-for-profit company that operates multiple federally funded research and development centers). These requirements cover typical mistakes made by developers that cause easily exploitable vulnerabilities such as injection flaws (including SQL injection), buffer overflows, etc.
Broken authentication and session management (6.5.10) is a new requirement introduced in PCI DSS 3.0 that must be in place as of July 1, 2015. This requirement was added to the OWASP Top 10 2013. This requirement just means that the authentication and session system can be easily targeted by an attacker. Attacks of this type can include:
brute-force guessing of credentials if no account locking is present (8.1.6, 8.1.7).
capture (eavesdropping) of credentials not protected by encryption (6.5.4, 8.2.1).
capture of leaked session identifiers (6.5.4) often included in the URL, reused or never timed-out.
other> attacks are also likely possible.
As you can probably see, improper validation of input values is one source that leads to many of these issues.
PCI DSS covers the minimal required checks to be performed. An organization should review the current threat landscape and identify whether other types of vulnerabilities should be covered within its secure coding guidelines and training.
Since externally-facing web-applications are more and more targeted by attackers, any public-facing (externally outside the organization, connected to the full Internet or just to a limited subset through a network not fully controlled by the organization) are especially at risk. PCI DSS asks us to protect these through either performing an annual security assessment of the web applications (which I call web application penetration testing) or to install some form of automated solution that detects and prevents web-attacks (for example Web-Application Firewalls, reverse proxies, or other such tools). In volume 1 (section 1.10.7), I argued that organizations should probably be using both approaches, and not just one of the two. This is still my personal recommendation.