PCI Application Security Requirements
Currently, there are requirements for custom in-house or out-sourced applications and software that are not commercially re-sold to comply with all relevant requirements of PCI DSS, All custom applications must be developed, deployed, supported and refreshed according to these requirements.
They include the following:
1. Applications must be developed as a part of a well-defined Software Development Life Cycle (SDLC) with security principles incorporated into the development process.
2. Applications should reside on hardened operating systems and with discrete and well defined limitations on unnecessary functionality.
3. Applications should never store sensitive authentication data (card magnetic stripe, security codes, PINs, etc.)
4. Applications should not interfere with cyber-security controls such as antivirus, firewalls, cryptographic protections, secure authentication schemes, IDS/IPS, etc.
5. Web based applications must be developed in accordance with the Open Web Application Security Project (OWASP) guidelines for secure coding.
6. Web-facing applications (i.e.-Internet facing) must be protected either with a source code review by an authorized entity or be protected by application firewalls.
7. Applications should be tested for security vulnerabilities in addition to functionality testing by someone other than the authors of the actual code.
Application Security Action Items
Some business and IT leaders may be just starting to consider the security implications of their banking or commerce applications. There may be lingering uncertainty on what to do first. The following 5 steps are a great first start:
1. Update POS Applications. Visa maintains a list of Payment Application Best Practices compliant POS applications. Ensure that you are running a compliant version of POS.
2. Identify Poorly Coded Web Apps. Perform a code review for known coding flaws. Then follow-up with a vulnerability scan and an application-layer penetration test to ensure application code is PCI complaint and secure.
3. Perform Quarterly Vulnerability Scans. As detailed in DSS section 11.2, run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
4. Perform Annual Penetration Testing. Both internal and external (public facing) applications that process "sensitive" data should be penetration tested at least annually and whenever they undergo significant revision.
5. Create Formal SDLC Processes. Microsoft understood this via Trustworthy Computing. Make sure you formalize a Software Development Life Cycle that incorporates security analysis throughout that life cycle.
Note that these five steps will keep your development teams busy for a while. And make sure you have a good project manager to keep all of the tasks and teams in sync.