Requirement 6 of PCI DSS v1.2 states that in order to be compliant, an organization must:
“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 critical systems must have the most recently released, appropriate software patches to protect against 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.”
Most of Requirement 6 is outside the scope of MySQL directly and covers things like:
- Validation of all input
- Validation of proper error handling
- Validation of secure cryptographic storage (although you’ll want to validate MySQL’s at-rest encryption as part of your validation processes)
- Validation of secure communications
- Separate development/test and production environments
- Separation of duties between development/test and production environments
- Production data (live PANs) are not used for testing or development
- Web Application Security (XSS, CSRF, etc)
- Formalizing the process for security updates
The parts that specifically apply to MySQL are as follows:
6.2 Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues.
Personally, I like a formalized subscription to BugTraq and MySQL’s Announce List, where each relevant bug and announcement are formally evaluated against your target environment. In the event that there is something applicable to your environment, you can begin the (formally documented) process of introducing the mitigation, upgrade, or other required change(s).
6.4 – Follow change control procedures for all changes to system components
The procedures must include the following:
- Documentation of impact
- Management sign-off by appropriate parties
- Testing of operational functionality
- Back-out procedures
Unfortunately, Change Control for databases is not nearly as widely practiced as for code. We, as a community of database administrators, need to make a greater effort to make this a de facto standard for organizations. In the interest of the greater good, I wanted to call out this requirement directly and provide some relevant links: