Develop and Maintain Secure PCI In-Scope Systems and Applications
Policy Owner: Manager, Business Relationship Management
Note: An owner must be a PCES-level manager.
Current industry best practices as described in the Payment Card Industry Data Security Standard (PCI DSS) and the current version of Open Web Application Security Project (OWASP) Top Ten must be followed for PCI in-scope systems. These include, but are not limited to, the following requirements.
The Business Relationship Management Program Manager (BRM PM) coordinates these activities.
- Develop software applications (internal and external, including web-based administrative access to applications) in accordance with PCI DSS (e.g., secure authentication and logging) and based on industry best practices.
- Incorporate information security throughout the software development life cycle.
- Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes including:
- Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. Validate input to verify that user data cannot modify meaning of commands and queries, use parameterized queries, etc.
- Buffer overflow. Validate buffer boundaries and truncate input strings.
- Insecure cryptographic storage. Prevent cryptographic flaws.
- Insecure communications. Properly encrypt all authenticated and sensitive communications.
- Improper error handling. Do not leak information via error messages.
- All “High” vulnerabilities as identified in the Risk Ranking Policy.
- Cross-site scripting (XSS). Validate all parameters before inclusion, use context-sensitive escaping, etc.
- Improper Access Control, such as insecure direct object references, failure to restrict URL access, and directory traversal. Properly authenticate users and sanitize input. Do not expose internal object references to users.
- Cross-site request forgery (CSRF). Do not reply on authorization credentials and tokens automatically submitted by browsers.
- Change Management. All changes related to the implementation of security patches and software modifications to IT system components in the USPS cardholder data environment (CDE) require the following:
- Documented impact of change
- Approval by authorized parties
- Functionality testing performed to verify that change does not adversely impact the security of the system
- Documented backout plans
- Production data (live PANs) are not used for testing or development. The PAN (Primary Account Number) is the payment card number (credit or debit) that identifies the issuer and the particular cardholder account.
- Pre-production. Prior to changes going to production, the following activities must take place:
- Remove custom application accounts, user IDs, and/or passwords before system goes into production or is released to customers.
- Remove test data and accounts before production systems become active.
- Custom application-code changes must be reviewed using either manual or automated processes as follows:
- Code changes are reviewed by individuals other than the originating code author and by individuals who are knowledgeable in code review techniques and secure coding practices.
- Code reviews ensure code is developed according to secure coding guidelines. See Secure System Review Process.
- Appropriate corrections are implemented prior to release.
- Code review results are reviewed and approved by management prior to release.
The following requirements apply to web applications and application interfaces (internal or external):
- TSLC Policy
- SIT – CAT Exemption and Post Production Review Process
- Secure System Review Process
- System Retirement Process
- Handbook AS-805 Information Security [PDF] [HTML]
- Handbook AS-805A, Information Resource Certification and Accreditation Process [PDF] [HTML]
- Payment Card Industry Data Security Standard (PCI DSS)
Access supporting documentation from ITWEB (Internal)
Access Supporting Documentation from USPS.com (External)
- TSLC Processes
- For access to the following documents, contact the US Postal Service. See Publication 5, Let's Do Business for further information about local US Postal Service contacts.
- TSLC Templates
- Application Development Standards
- Risk Ranking Policy
Description of Change
Note: This document is Section 508 compliant.
|1.1||11.24.2014||Updated language in Requirements section to clarify that current best practices at this time are PCI DSS 2.0 and OWASP Top Ten 2010.|
|1.2||03.02.2015||Non-substantive revision: Policy Owner changed from Manager, IT Strategy and Compliance, to Manager, Business Relationship Management.|
|1.2.1||07.21.2015||Annual Review: The annual review for functional accuracy and current PCI DSS requirements has been completed. CR 91292|
|1.2.2||03.14.2016||Annual Review: The annual review for functional accuracy
and current PCI requirements has been completed. CR 154951 |
Non-substantive update: Updated references/hyperlinks to Risk Ranking Policy, which replaced Risk Ranking Standards.
|1.2.3||10.31.2016||Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 223948|
|1.2.4||10.04.2017||Removed references to Waterfall methodology.|
Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 311546
|1.2.5||10.22.2018||Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 407156|