Secure System Review Process

PURPOSESCOPEROLES AND RESPONSIBILITIESPROCESSSUPPORTING DOCUMENTATIONREVISION HISTORY

Process Owner: Manager, Solutions Development and Support

Note: An owner must be a PCES-level manager.

PURPOSE

The purpose of this document is to define the Secure System Review Process; this process is part of the Technology Solution Life Cycle (TSLC).

The Payment Card Industry Data Security Standard (PCI DSS) requires review of all custom code (any code not directly supplied by a vendor) to identify potential vulnerabilities and correct them before the code is released into a production environment. Discovery and mitigation of vulnerabilities in custom source code will limit the attack surface of the Postal Service as well as satisfy PCI compliance.

SCOPE

This document is used in conjunction with all IT and Security Policies, Processes, and Standards, including those listed in the Supporting Documentation section.

This process applies to all:

ROLES AND RESPONSIBILITIES

The following list describes the roles and responsibilities of those involved in this process.

Subject Matter Experts (SMEs)

Review Team

Emergency Approvers (Includes One or More of the Following)

PROCESS

A combination of automated and manual methods may be necessary to perform an effective review. Acceptable methods are described below.

Scans of custom code must be performed by delegated personnel who are either employed or contracted by USPS and are knowledgeable in configuring the scan tools and producing reports to be reviewed.

All findings are considered sensitive information and will be made available to the Information Systems Security Officer (ISSO) and the responsible Project Manager by uploading them to the program’s Security Certification and Accreditation (C and A) Documents (C&A) folder in the TSLC Artifact Library. Distribution of any findings outside of the Postal Service is strictly prohibited unless approved by the Manager, Solutions Development and Support; Manager, Corporate Information Security Office (CISO); VP of the functional business area (business owner); and VP, Information Technology. Uploading all reports to the C&A folder eliminates the need to email and encrypt these sensitive files.

Secure Code Review

  1. Application SMEs:
    1. Populate the source control system with the code to be scanned. If a web application will be scanned, identify all of the URLs to be scanned.
    2. Request access to the scanning tool.
    3. Remediate internal findings and document false positives.
  2. Code scanning SMEs:
    1. Prepare for the scan.
      1. Configure the scanning tool to produce the desired output. For example, AppScan is configured to produce an OWASP Top Ten report and a PCI detailed report. The reports that are available vary by tool.
      2. Review the results of previous scans performed on the application. This SME must also be aware of new threat vectors that have arisen since the last scan and determine if they are relevant for the application. Particular areas of concern must be documented in the test notes.
      3. Ensure that the latest updates have been applied to the scanning tool.
    2. Perform the scan.
      1. Obtain the code to be scanned from the source control system or, in the case of web applications, obtain the URLs to be scanned from the CR.
      2. Scan the code to identify vulnerabilities and produce the reports.
      3. Save the reports and any other necessary artifacts in the program’s Security C and A Documents (C&A) folder in the TSLC Artifact Library.
  3. The review team performs the assessment on the files that were uploaded to the C&A folder.
    1. Evaluate the materials, ensuring that all vulnerabilities have been remediated or are documented as false positives.
    2. If medium- or high-severity vulnerabilities will remain in the code, a Security Exception Letter (SEL) must be approved. This includes an action plan for future remediation, a timeline for remediation, and protection measures to use in the meantime to minimize the risk. Contact CISO for the SEL template.
    3. Determine whether:
      • Vulnerabilities exist and must be remediated. Repeat step 2.b. through 3.a.
      • No vulnerabilities exist, and the code review materials can be submitted for approval. Continue with step 4.
  4. Continue with the Change Management process for approvals. The code promotion CR is:
  5. The code scanning SME ensures that:
  6. Continue with the TSLC process, per the TSLC Policy, to release the code to production.

SUPPORTING DOCUMENTATION

Access Supporting Documentation from ITWEB (Internal)

Access Supporting Documentation from USPS.com (External)

REVISION HISTORY

Version
Date
Description of Change
1.0 05.10.2013 Initial release.
2.0 12.19.2013
  • Added RTM, scan results, justification of false positives, and “any other materials” to the Inputs.
  • Added roles: Assessor and Emergency Approvers.
  • Added standard Supporting Documentation section.
  • Added Change Management Policy as a supporting document.
2.1 03.18.2014 Replaced "customer" with "business owner (customer)" to define the customer as the business owner.
2.2 06.23.2015 Consolidated steps from the Secure Code Review Procedure into this process to reduce redundancy. Retired Secure Code Review Procedure.

Clarified roles, approvals, and artifacts.

Annual review: The annual review for functional accuracy and current PCI DSS requirements has been completed. CR 83903.
2.3 11.13.2015 Updated to clarify roles and align with PCI DSS requirements.
2.3.1 03.14.2016 Annual Review: No changes. The annual review for functional accuracy and current PCI requirements has been completed. CR 154951
2.3.2 10.31.2016 Supporting Documentation section: Updated hyperlink to IBM Rational AppScan Source Code Edition v8r5 Documentation.

Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 223948
2.4 05.03.2017 The Requirements Traceability Matrix (RTM) is no longer a required artifact. Customer business requirements with approval replace the RTM and eliminate the need to upload redundant information. Removed references to Waterfall methodology. CR 269601
2.4.1 10.04.2017 Annual Review: No changes. The annual review for functional accuracy and current PCI requirements has been completed. CR 311546
2.4.2 10.22.2018 Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 407156
Powered By OneLink