8-2.1
Life-Cycle Approach
Security must be addressed throughout the information resource life-cycle process, from requirements, design, build, system integration testing (SIT), customer acceptance testing (CAT), release (and production) and retirement. All development, acquisition, or integration projects for information
resources, whether performed in house or by a business partner, must follow the TSLC process or other approved systems development life-cycle methodology. All systems development must follow secure coding best practices.
8-2.2
Risk Management
A risk-based approach must be applied to information security that uses limited resources wisely to protect an information resource in a cost-effective manner throughout its life cycle. The security controls applied to information resources must be commensurate with the magnitude of harm that would result from loss, misuse, unavailability, unauthorized access, or unauthorized modification of the information resources (see 4-3, Information Resource Risk Management).
8-2.3
Quality Assurance
Information resource development must include quality assurance (QA) and security-specific testing to ensure that security controls have been
implemented and are functioning correctly. Transactions failing edit and validation routines must be subject to appropriate follow-up until errors are remediated. Information processing failures discovered as the result of remediation must be used for root cause analysis and to adjust procedures and automated controls to improve quality.
8-2.4
Configuration and Change Management
All information resources, whether developed in house, outsourced, or acquired must be developed under standard configuration and change management procedures to reduce the risk introduced by undocumented and untested changes in accordance with the Postal Service change management policy/procedure. Postal Service information resources must not be developed or deployed unless a change and configuration
management process is in place.
Configuration and change control involve the systematic proposal,
justification, test/evaluation, review, and disposition of proposed changes. Appropriate organizational officials approve information system changes in accordance with this process. Emergency changes are also included in the configuration and change control process.
8-2.4.1
Configuration Component Inventory
To effectively manage information resources, the information system components must be inventoried and the initial or baseline configuration of the information resources must be documented in the corporate
Configuration Management Database (CMDB) prior to deployment. The inventory of information system components must include manufacturer, type, serial number, version number, information system/component owner, and location (i.e., physical location and logical position within the information system architecture). The inventory must also designate those information system components required to implement and/or conduct contingency planning operations.
Configurations of information resources must be reviewed at least annually to ensure the documented configuration in the appropriate inventory application matches the current components.
Development and Operations Security 8-2.4.4
8-2.4.2
Configuration Hardening Standards
Hardware and system software must be hardened to Postal Service information security requirements. Configuration hardening standards must be used to maintain a high level of information security, enable cost-effective and timely maintenance and repair, and protect Postal Service information resources against unexpected vulnerabilities. Critical security patches for PCI-related information resources, including applications and infrastructure, must be installed within 30 days of release. See the manager, Corporate Information Security Office (CISO) Information Security Services (ISS), to request access to a specific Postal Service configuration hardening standard.
8-2.4.3
Change and Version Control
Changes to information resources and configurations must be managed to ensure that Postal Service information resources are not inadvertently exposed to unnecessary risks and vulnerabilities and that only qualified and authorized individuals initiate changes, upgrades, and modifications. Individual access privileges must be approved by appropriate management officials.
All changes must be appropriately approved and documented. Application code changes are managed using version control software. Change control records must be maintained to support and document system software maintenance, software and hardware upgrades, and any local system modifications.
8-2.4.4
Patch Management
An effective patch management process must be implemented to
investigate, prioritize, test, track, control the deployment and maintenance of software releases, and resolve known security vulnerabilities. The patch management process must address all information resources installed in the Postal Service computing environment. Security patches must be installed in accordance with the agreed upon schedule and following established evaluation and implementation processes. Critical security patches for PCI- related information resources, including applications and infrastructure, must be installed within 30 days of release. Software security patches must be evaluated on a regular basis. The evaluation period varies by platform and is defined in the applicable hardening standard. If the patch is appropriate for the Postal Service environment, the patch must be tested and approved by Postal Service management prior to implementation. Software patch evaluations must be properly documented and retained in the appropriate repository. Personnel involved in the patch management process must be appropriately trained to ensure a viable vulnerability mediation process. Patch management involves acquiring, testing, and installing multiple patches (code changes) to software systems, including operating system software, supporting software and packages, firmware, and application software. Patch management tasks include the following:
b. Deciding what patches are appropriate for particular information resources.
c. Prioritizing the patches to be installed.
d. Testing patches in a nonproduction environment first in order to check for unwanted or unforeseen side effects.
e. Developing a back-out plan which includes backing up the systems about to be patched to be sure that it is possible to return to a working configuration.
f. Securing management approval.
g. Ensuring that patches are installed properly. h. Testing information resources after installation.
i. Documenting all associated procedures, such as specific configurations required.
Patch management is critical to ensure the integrity and reliability of information resources. Patch management should be capable of: a. Highly granular patch update and installation administration (i.e.,
treating patches and mainframes, servers, desktops, and laptops separately).
b. Tracking machines, and updating and enforcing patches centrally. c. Verifying successful deployment on each machine.
d. Deploying client settings, service packs, patches, hot fixes, and similar items network-wide in a timely manner in order to address immediate threats. Critical security patches for PCI-related information resources, including applications and infrastructure, must be installed within 30 days of release.
e. Initiating from a central management console.
f. Providing scheduling, desktop management, and standardization tools to reduce the costs associated with distribution and management. g. Providing ongoing deployment for both new and legacy systems in
mixed hardware and operating system environments.
h. Automating the repetitive activity associated with rolling out patches. i. Analyzing the operating system and applications to identify possible
security holes.
j. Scanning the entire network (IP address by IP address) and providing information such as service pack level of the machine, missing security patches, key registry entries, weak passwords, users and groups, and more.
k. Analyzing scan results using filters and reports to proactively secure information resources (e.g., installing service packs and hotfixes).
Development and Operations Security 8-2.6
8-2.4.5
Security Testing of the Configuration
After the information system is changed, the security controls must be checked to ensure the security features are still functioning properly. Periodically (at a minimum annually), the security controls must be tested to ensure the information security controls are functioning as designed and documented.
Significant changes will cause the re-initiation of the C&A process. The criteria for initiating a recertification are defined in Handbook AS-805-A, Information Resource Certification and Accreditation (C&A) Process, Section 6-2.
8-2.5
Separation of Duties
An individual or organization must not be assigned duties that could cause a conflict of interest or present an undetectable opportunity for accidental or malicious wrongdoing, fraud, or collusion. When it is not possible for duties to be assigned to separate individuals, the roles and functions performed must be clearly defined, associated activities logged, security-related functions audited, and compensating controls identified and implemented. The CISO reserves the right to validate the effectiveness of the
compensating controls.
8-2.6
Application Source Code
Application source code is considered business proprietary information by the Postal Service and is expected to be handled and stored in a secure manner. When source code is consolidated and stored in a repository/vault, that repository/vault is considered sensitive and must adhere to the following controls:
a. The repository/vault must be in a controlled area and physical access to the repository/vault will be controlled through an access control system.
b. Electronic access to the repository/vault will be controlled through eAccess.
c. A fully accountable check-in/check-out process must be operational. d. Code may not be removed from the vault without using the approved
check-in/check-out process.
e. Any code that is removed from the vault must be protected from unauthorized access or usage.
f. Business partners having access to code must have a valid Postal Service nondisclosure agreement (NDA) on file with the Postal Service. Business partner NDAs will be filed with the contracting officer.
g. A defined process of separation of duties must be implemented to support code propagation through the environments (e.g. developers will not have the ability to place code directly into the production environment).
h. A versioning system must be in-place to ensure that proper version control is maintained.
8-2.7
Developers
A developer is an employee or contractor with the development-related responsibilities (e.g., the ability to check-in code or make changes to source code, scripts, or configuration files) and as such must be included in the Postal Service Corporate Developer Registry (CDR).
The following restrictions apply to all developers:
a. Developers are not authorized to be production application/platform administrators.
b. Developers are not authorized to copy production data.
c. Developers are not authorized to have greater than read access to the underlying operating system.
d. Developers are not authorized to have greater than read access to the underlying database.
e. Developers are not authorized to have greater than read access to the application (i.e., under no circumstances are developers ever allowed to have privileged or administrative access to the application).
f. Developers are not authorized to promote code to the production environment.
g. The definition of developer is global in scope, and these restrictions apply across all applications and platforms.