Effective December 2018, the Postal Service™ revised Handbook AS-805, Information Security, to update policy and procedures related to continuous improvement of governance, compliance, and the cybersecurity posture of the organization.
Handbook AS-805, Information Security
* * * * *
1 Introduction: Corporate Information Security
1-1 Purpose
[Revise the second paragraph of 1-1 to read as follows:]
Adherence to information security policies enables compliance with regulations to which USPS is subject, including Sarbanes-Oxley (SOX) and Payment Card Industry Data Security Standards (PCI-DSS). This policy reflects standards and guidelines suggested by industry organizations such as the Public Company Accounting Oversight Board (PCAOB), American Institute of Certified Public Accountants (AICPA), Committee of Sponsoring Organizations (COSO), and National Institute of Standards and Technology (NIST).
* * * * *
3 Information Designation and Control
* * * * *
3-5 Protection of Postal Service Information and Media
* * * * *
3-5.4 Encryption of Information
* * * * *
[Revise the text of item g. to read as follows:]
g. For portable Public Key Infrastructure (PKI) backup media, see 9-7.1 for encryption compliance methods.
* * * * *
[Add new section 3-7 to read as follows:]
3-7 Cyber Threat Information
Cyber threat information is any information that can assist in identifying, assessing, monitoring, and responding to cyber threats. Organizations can gain a more complete understanding of threats by analyzing information from multiple sources and by exchanging threat information within vetted sharing communities.
Threat is any circumstance or event (human, physical, or environmental) with the potential to cause harm to an information resource in the form of destruction, disclosure, adverse modification of data, and/or denial of service by exploiting a vulnerability.
The objective of sharing is to support the overall CISO strategy and all information sharing agreements, which must be approved by CISO leadership. The agreements must be coordinated with CISO units with a role in the collection, processing, storage, and protection of threat information. Insider threat information is as follows:
a. Insider threat information is collected or produced as a product of cybersecurity operations by internal tools, sensors, and repositories. To identify what threat information may be shared, the scope of information-sharing activities must be defined and rules put in place to control the flow of information.
b. All threat information sharing must be managed within a Threat Intelligence Platform (TIP). The threat information-sharing process includes engaging in ongoing communication with partners, consuming security alerts and indicators, organizing and storing information, and producing and publishing information for sharing with partners.
Threat information sharing must comply with Postal Service legal restrictions on the type of information that may be shared, including the requirement that shared threat information must not be attributable to the Postal Service.
Information types, such as Personally Identifiable Information (PII), classified information, and Postal Service proprietary information, may not be shared and must be protected. Adequate security and privacy controls must be implemented to protect this information from unauthorized disclosure or modification.
* * * * *
6 Personnel Security
* * * * *
6-4 Background Investigations and Clearances
* * * * *
6-4.2 Access Privileges
* * * * *
6-4.2.3 Controlled Areas
[Revise the text of 6-4.2.3 to read as follows:]
All personnel, whose duties require unescorted access to controlled areas, whether located at a Postal or non-Postal Service facility, must have an appropriate clearance or background investigation as determined by the Inspection Service before being granted unescorted access privileges. For further information, refer to the USPS Administrative Support Manual (ASM), Section 272, Personnel Security Clearances.
* * * * *
6-5 Information Security Awareness Training
* * * * *
6-5.3 Training Requirements
[Revise the text of 6-5.3 to read as follows:]
Exhibit 6-5.3
Training Requirements
Training Type
|
Requirement(s)
|
Annual Training
|
Based on requirements defined by the CISO at the beginning of the fiscal year (see the Information Security Training Matrix on the CISO Website), all personnel with an ACE ID or access to the Postal Service intranet must participate in information security training and data protection requirement training annually. Information security training is recommended for all other non-bargaining personnel
|
Information Resource Operational Security Training
|
All personnel with access to the Postal Service network must be trained to handle and report information security breaches and incidents.
All PCI developers and administrators must complete formal training [1] in general secure coding techniques, [2] in developing secure code in the programming language(s) they use, and [3] and must maintain evidence of successful completion.
For information resources processing sensitive-enhanced, sensitive, or critical information, operational security training must be developed and conducted that is appropriate for job responsibilities, and role-based activities.
All privileged users possessing access to any sensitive-enhanced, sensitive, or critical information or systems supporting information must undergo security awareness training and records are maintained within the Learning Management System (LMS). If training does not occur, the role cannot be fulfilled. For privileged account holders who have not received annual refresher training, access is disabled until required training has been completed, unless the CISO grants a waiver.
The training should explain how to protect information throughout its life cycle and report incidents.
All C&A stakeholders, including Business Relationship Management portfolio managers, Solution Development Teams, and their staff
|
New Personnel Training
|
All new personnel must receive information security training and be issued a copy of Handbook AS-805-C, Information Security for General Users.
|
* * * * *
8 Development and Operations Security
* * * * *
8-3 Operations Security
* * * * *
8-3.2 Environment Restrictions
* * * * *
8-3.2.1 Development Environment
[Revise the text of 8-3.2.1 to read as follows:]
Developers get full access (e.g., read, write, execute, allocate, and delete) in this environment to application software. Restrictions for the development environment include the following:
a. Developers are restricted to read and execute privileges for database and operating system software.
b. Personally identifiable information (PII), which is defined in 3-2.3.2, and payment card industry (PCI) primary account number (PAN) must not be used in this environment.
c. No access to production systems is allowed from this environment.
d. Development environment is an isolated infrastructure (DEVSUB) or enclaved.
e. Use of nonsensitive production information in this environment requires the creation of a generic production data usage letter (PDUL). This letter approves the use of nonsensitive production data until the end of the current fiscal year. The PDUL is needed only for the application to be tested not for every system the application touches.
f. Use of sensitive or sensitive-enhanced production information in this environment requires:
1. A specific PDUL that approves the use of this data until the end of the current fiscal for 1 year from the time of the request at which time another PDUL will be required. The PDUL is needed only for the application to be tested, not for every system the application touches.
2. The development environment must implement the same controls as the production environment or the PII or PCI PANs, and sensitive information must be de-identified in the production environment before data is transferred to the development environment. The project manager must validate (and attest in a letter to the CISO and the privacy office) that all PII and PCI PANs, and sensitive information have been de-identified.
g. All connection of developer workstations to databases in all environments must be added as a temporary request for no more than 6 months with the option to renew when the NCRB team (coordinating with the ISSO) contacts the requester prior to expiration; contact the users listed in the database connections in the general tab of ServiceNow. This fits the 6-month access review policy.
h. All connections for developers will be from their workstations/laptops and not from a subnet.
8-3.2.2 SIT Environment
[Revise the text of 8-3.2.2 to read as follows:]
Developers have full access (e.g., read, write, execute, allocate, and delete) in this environment to application software. Code is migrated from the SIT environment back to the development environment to apply updates/fixes. Restrictions for the SIT environment include the following:
a. Developers may have access to the SIT environment with documented management approval.
b. Systems moved to the SIT environment are documented and managed by a version control library system.
c. PII and PCI PANs, and sensitive information must not be used in this environment.
d. Use of nonsensitive production information in this environment requires a generic PDUL that approves upfront the use of nonsensitive production data for up to 1 year from the time of the request until the application requires recertification and reaccreditation at which time another PDUL will be required.
e. Use of production PII and PCI PANs, and sensitive information in this environment requires:
1. A specific PDUL that approves the use of this data for 1 year from the time of the request; at which time another PDUL will be required. The PDUL is only needed for the application to be tested not for every system the application touches.
2. The SIT environment must implement the same controls as the production environment or the PII, or PCI PANs, and sensitive information must be de-identified in the production environment before the data is transferred to the SIT environment. The project manager must validate (and attest in a letter to the CISO and the privacy office) that all PII, and PCI PANs, and sensitive information have been de-identified.
f. All connection of developer workstations to databases in all environments should be added as a temporary request for no more than 6 months with the option to renew when the NCRB team (coordinating with the ISSO) contacts the requester prior to expiration; contact the users listed in the database connections in the general tab of ServiceNow. This fits the 6-month access review policy.
g. All connections for developers will be from their workstations/laptops and not from a subnet.
8-3.2.3 CAT Environment
[Revise the text of 8-3.2.3 to read as follows:]
Access is restricted to production operations personnel, executive sponsorship, and developers with proper authorization. The CAT environment must implement the same controls and security requirements as production. Restrictions for the CAT environment include the following:
a. Developers may have access to the CAT environment with documented management approval.
b. Systems moved to the CAT environment are documented and managed by a version control library system.
c. PCI PANs must not be used in this environment.
d. PII and sensitive information must be de-identified prior to use in the CAT environment; any exceptions to the de-identification requirement must be approved by the CIO, CPO, and the executive sponsor. If PII that is not de-identified is approved for use in the CAT environment, the PII and sensitive information must be encrypted.
e. Use of nonsensitive production information in this environment requires a generic PDUL that approves upfront the use of nonsensitive production data for up to 1 year from the time of the request until the application requires recertification and reaccreditation at which time another generic PDUL will be required. See 8-3.2.5, Other Environments.
f. Use of PII, and PCI PANs, and sensitive information in this environment requires:
1. A specific PDUL that approves the use of this data until the end of the current fiscal for 1 year from the time of the request at which time another PDUL will be required. The PDUL is only needed for the application to be tested, not for every system the application touches.
2. The CAT environment must implement the same controls as the production environment or the PII and PCI PANs, and sensitive information must be de-identified in the production environment before data is transferred to the CAT environment. The project manager must validate and attest in a letter to the CISO and the Privacy Office that all PII and PCI PANs, and sensitive information have been de-identified.
g. All connection of developer workstations to databases in all environments should be added as a temporary request for no more than 6 months with the option to renew when the NCRB team (coordinating with the ISSO) contacts the requester prior to expiration; contact the users listed in the database connections in the general tab of ServiceNow. This fits the 6–month access review policy.
h. All connections for developers will be from their workstations/laptops and not from a subnet.
* * * * *
9 Information Security Services
* * * * *
9-4 Accountability
* * * * *
9-4.2 Types of Accounts
* * * * *
9-4.2.4 Shared Accounts
* * * * *
[Revise the text of item a. to read as follows:]
a. Shared accounts (e.g., training accounts) have a single log-on ID and password that is used by more than one individual. A shared account will be used only for qualifying circumstances and deemed necessary by the CISO. This approach to account usage is highly discouraged and requires the appropriate level of management approval via eAccess as well as approval by the CISO. The use of shared accounts must be tracked (e.g., logged) to manage individual accountability. The requesting manager is responsible for undocumented usage of the shared accounts and is responsible for password management. Shared accounts must not include access to any Postal Service production systems, the Internet, or the PCI environment. System operators will not share identification or authentication materials of any kind, nor allow any other person to operate any information systems by employing that user’s identity. Generic accounts must not be used to administer PCI system components.
* * * * *
9-6 Authentication
* * * * *
9-6.4 Digital Certificates and Signatures
[Revise the text of 9-6.4 to read as follows:]
A digital certificate is an X.509 certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer, or service identity contained within the certificate. The certificate’s purpose is to relate a unique name to a specific public key and is used for encryption and decryption of files and the nonrepudiation of messages. USPS sets standards for the properties, utilization, and acceptance of digital certificates in USPS systems and applications where digital certificates are used.
Cryptographically, X.509 is the standard defined by the public key certificate within USPS. As defined in 11-1.1.4, USPS uses X.509 certificates for secure communication, including the TLS and SSL protocols. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual). When signed by a trusted certificate authority, someone holding that certificate can rely on the public key it contains to authenticate the identity presented therein.
An X.509 is defined by the International Telecommunications Union‘s Standardization sector (ITU-T), and is based on ASN.1, another ITU-T standard and contains information about the identity to which a certificate is issued and the identity that issued it. Standard information in an X.509 certificate includes the following:
a. Version — which X.509 version applies to the certificate (which indicates what data the certificate must include).
b. Serial number — the identity creating the certificate must assign it a serial number that distinguishes it from other certificates.
c. Algorithm information — the algorithm used by the issuer to sign the certificate.
d. Issuer distinguished name — the name of the entity issuing the certificate (usually a certificate authority).
e. Validity period of the certificate — start/end date and time.
f. Subject distinguished name — the name of the identity the certificate is issued to.
g. Subject public key information — the public key associated with the identity.
h. Extensions (optional).
Within USPS, the CISO determines the eligibility of each proposed role, group, code signer, system, application, or device to receive one or more certificates. The CISO determines and verifies the identity of the human sponsor for each proposed role, group, code signer, system, application, or device to receive one or more certificates.
9-6.4.1 Digital Certificate
[Revise the text of 9-6.4.1 to read as follows:]
A digital certificate contains a public key and a private key. Digital certificates are used for identity verification prior to performing a separate action [by way of another process entirely, such as the Transport Layer Security (TLS) protocol] to transmit data securely. The Postal Service sets standards for the properties, utilization, and acceptance of digital certificates in Postal Service systems and applications where digital certificates are used.
* * * * *
9-6.4.3 Certificate and Signature Standards
[Revise the text of 9-6.4.3 to read as follows:]
Certificate Authority (CA) operating requirements are defined within this policy, and may also be well-defined within a Certificate Policy (CP) document. This includes digital certificate properties, as well as utilization and acceptance. Certificate Authority server operational practices are defined within the Security Plan document for each Enterprise Information Repository (EIR) at USPS that operates Certificate Authority (CA) servers, and may also be well-defined within Certificate Practice Statement (CPS) documents. If used, CPS documents are required for each CA Server and are used to describe how each of those CA servers are operated in accordance with the relevant CP document under which they must function.
* * * * *
9-6.4.5 Certificate Stores
[Revise the text of 9-6.4.5 to read as follows:]
The certificate store is a permanent storage where a public key infrastructure (PKI) stores its certificates, CRLs, and certificate trust lists. A trusted root certificate is the cornerstone and trust anchor of authentication and security on the Internet. Silently adding a root certificate gives any owner of the private key that goes with that certificate lots of options to perform actions on a computer where that certificate is installed; therefore, anyone who gets ahold of the private key that belongs to a root certificate can generate certificates for their own purposes and sign them with the private key.
Vendors’ products come pre-populated with many root certificates in their trust stores, potentially certificates that USPS does not want to implicitly trust. The CISO sets the direction of what should be included in the trust stores and the PKIMA provides technical assistance to application and system owners with regards to the content of installed product’s trust stores through automated or manual processes, to include the following:
a. Removing all certificates that have passed their expiration date.
b. Removing all certificates that are no longer trusted.
c. Removing all certificates that are no longer required.
9-6.4.6 Naming Constraints
[Revise the text of 9-6.4.6 to read as follows:]
Names for certificate issuers and certificate subjects are of the X.500 Distinguished Name (DN) form. The ""United States Postal Service"" is a registered name in accordance with American National Standards Institute. The U.S. National Name Registration Authority uses of this identifier within USPS are not restrictive because the identifier is unambiguous and may be used in a variety of environments and various encoding methods. To be unambiguous, USPS must establish context and naming hierarchies. A single naming hierarchy is established within the Postal Service as outlined below:
a. Names for certificate issuers (i.e., USPS CA) and certificate subjects (i.e. subscriber or end entity) are of the X.500 DN form. These names are unique and unambiguous within the USPS hierarchy.
b. Certificate issuers have entries at the organization name level. The DNs will use the following form: OU=United States Postal Service, O=U.S. Government, C=US.
c. Certificate subjects have entries at the organizational Unit Name level. The DNs must follow the following form: CN=Subscriber Name, OU=United States Postal Service, O=U.S. Government, C=US.
Certificate subjects choose an optional Alternated Subject Name if marked noncritical. Certificate subjects choose to have additional name forms, such as an email address; however, the DN is the primary name and the one used to populate the subject fields of certificates and CRLs. Additional objects outside the scope of this policy must also be present in the naming hierarchy.
9-6.4.7 Meaningful Names
[Revise the text of 9-6.4.7 to read as follows:]
All names, including machine names and application names, are unique and understandable to humans. The DN must represent the subscriber in a way that is easily interpretable. For people, this is a legal name. For equipment, this is a model name and serial number. Distinguished names must be unique for all end entities of the USPS CA. X.500 DNs are used, and the USPS CAs enforce name uniqueness within the X.500 name space for which they have been authorized. When name forms other than a DN (e.g., email address or DNS name) are used, they too will be allocated to ensure name uniqueness.
The contents of each certificate Subject and Issuer name field have an association with the authenticated name of the Entity. A certificate issued for a device or application must include, within the Directory entry, the name of the person or organization responsible for that device or application. All certificates have name constraints asserted that limit the name space of the CAs to that appropriate for the domain.
9-6.4.8 Rules for Constructing Various Name Forms
[Revise the text of 9-6.4.8 to read as follows:]
Name forms are contained in the applicable certificate profile. As the USPS organization responsible for management and operation of the USPS X.500 directory. The Information Technology Engineering and Architecture (ITEA) group is responsible for the USPS X.500 directory name space and works with the Change Management Process for naming approval prior to final certificate provisioning.
9-6.4.9 Name Claim Dispute Resolution Procedure
[Revise the text of 9-6.4.9 to read as follows:]
Any dispute related to a name claim between USPS and an organization or individual outside of USPS is resolved using the following dispute settlement mechanism:
a. A dispute is resolved by negotiation, if possible.
b. A dispute not settled by negotiation is resolved through arbitration by the USPS PKIPA.
* * * * *
9-6.8 Nonrepudiation
[Revise the text of 9-6.8 to read as follows:]
Nonrepudiation is the security property that ensures that the sender cannot deny sending the message, the recipient cannot deny receiving the message, and actions can be conclusively traced to a specific individual. When required, an information resource must have the capability to support nonrepudiation.
A single public/private key pair and its associated certificate issued to any device may be used for signing (including authentication), key management (for encryption), or both. Device certificates must not assert nonrepudiation as well; all subscriber private keys must not be used by more than one entity.
* * * * *
9-6.9 Remote-Access Authentication
[Revise the text of 9-6.9 to read as follows:]
Postal Service information resource workers must support and maintain access control for personnel using networked and Internet connections to Postal Service information resources. Strong authentication or other stringent access controls must be implemented for personnel entering through the Internet, or other non-Postal Service communication networks. Source restrictions (i.e., destination verification of remote session source address) may be used as a substitution to strong authentication for remote access. Two-factor authentication is required for remote access to PCI cardholder data.
Multifactor authentication is required for remote access to sensitive, sensitive-enhanced, and PCI cardholder data. Application owners centrally manage all remote access connections to their systems and ensure that remote access capabilities provide strong multi-factor authentication, audit capabilities, and protection for sensitive information throughout transmission. All remote access connections must support cryptographic-based, multifactor authentication. Any multifactor authentication is based on USPS-controlled certificates or hardware tokens issued directly to each authorized user. Remote access solutions must comply with the encryption requirements of FIPS 140-2, Level 3, Security Requirements for Cryptographic Modules.
* * * * *
9-7 Confidentiality
* * * * *
9-7.1 Encryption
* * * * *
9-7.1.1 Minimum Encryption Standards
[Revise the first three paragraphs of 9-7.1.1 to read as follows:]
Synchronous encryption: Products using FIPS 197 Advanced Encryption Standard (AES) algorithms with at least 256 bit encryption that has been validated under FIPS 140-2. Legacy systems must have plans for moving to the minimum encryption standard; the associated timeline for this action is based on feasibility (technical capability, business plan for upgrade/retirement, etc.), identification of a published exploit to the implemented encryption algorithm, and associated risk to the Postal Service.
Asynchronous encryption: RSA with a 2048-bit encryption key pair. Elliptic curve algorithms ECDH or ECDSA may be used with key sizes 224-bit or greater. Legacy systems must have plans for moving to the minimum encryption standard; the associated timeline for this action is based on feasibility (technical capability, business plan for upgrade/retirement, etc.), identification of a published exploit to the implemented encryption algorithm, and associated risk to the Postal Service.
PCI systems also require Transport Layer Security (TLS) protocol version 1.2. New implementations must meet the minimum standard. Legacy systems must have plans for moving to the minimum encryption standard; the associated timeline for this action is based on feasibility (technical capability, business plan for upgrade/retirement, etc.), identification of a published exploit to the implemented encryption algorithm, and associated risk to the Postal Service.
* * * * *
9-7.2 Use of Encryption Products
* * * * *
[Revise the text of item c. to read as follows:]
c. Application Owners follow encryption standard operating procedures for their application as documented within their specific EIR deliverables, as required by USPS Handbook AS-805-A (4-4.2 Deliverables, a. Standard operating procedures).
9-7.3 Key Management
* * * * *
9-7.3.3 Key Management Requirements
* * * * *
[Revise the text of items n., o., and p. to read as follows:]
n. Sponsors for nonhuman subscribers (systems, applications, and devices) are responsible for the security of and use of the subscriber’s private keys.
o. All subscribers including human and device private keys are not used by more than one entity.
p. Public keys (Digital Certificates) must be changed at least 30 days prior to the digital certificate’s expiration date.
* * * * *
9-7.3.4 Public and Private Key Management Agreement
[Revise the text of 9-7.3.4 to read as follows:]
The United States Postal Service (USPS) Cryptographic Keys (aka Private Keys) and Digital Certificates (aka Public Keys); including those provided by third-party vendors intended for use by the USPS, must be used only in accordance with this Public and Private Key Management Agreement, including the following:
a. To use your Cryptographic Key(s) and Digital Certificate(s) exclusively for authorized management of a USPS asset, or authorized USPS business partner asset.
b. To take all necessary precautions to protect your Cryptographic Key(s) and Digital Certificate(s) from loss, disclosure, modification, or unauthorized use, as per this policy derivative; as well as USPS Handbook AS-805C, Information Security for General Users.
Every United States Postal Service employee and contractor will maintain control of Cryptographic Keys at all times and abide by the agreements above.
9-7.4 Cryptographic Hash Function
[Revise the text of 9-7.4 to read as follows:]
A cryptographic hash function is an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, hash value, such that an (accidental or intentional) change to the data will (with very high probability) change the hash value. The data to be encoded is often called the “message,” and the hash value is sometimes called the message digest. The ideal cryptographic hash function must have the following significant properties:
a. It is easy to compute the hash value for any given message.
b. It is infeasible to generate a message that has a given hash.
c. It is infeasible to modify a message without changing the hash.
d. It is infeasible to find two different messages with the same hash.
The Postal Service cryptographic hash standard is SHA-2 or SHA 256. Older algorithms (e.g., SHA 1) maintained by commercial products and applications used and developed by the Postal Service may continue to be supported since they may be required to validate digital signatures executed in the past and to decrypt objects encrypted in the past using the older algorithms and key sizes. These cases must show acceptable effort of migration to standard algorithms as identified in this policy and receive an exception waiver by the CISO. In addition it is recommended that:
a. A Salt value is always used with your hash. This is especially important if the sensitive data to be protected is short like a password, social security number, or a payment card number.
b. Always use a Strong Salt value when creating a credential hash. A Salt is a fixed-length cryptographically-strong random value. Follow these practices to properly implement credential-specific salts:
1. Generate a unique salt upon creation of each stored credential (not just per user or system wide.)
2. Use cryptographically-strong random data.
3. As storage permits, use a 32-byte or 64-byte salt.
c. The Salt value should be protected as any other cryptographic value.
* * * * *
9-11 Audit Logging
* * * * *
9-11.1 Audit Logging Functionality Requirements
* * * * *
[Revise the text of item j. to read as follows:]
j. Generating real-time alarms indicating immediate attention is required for operational problems (e.g., running out of storage space) and audit log malfunctions. USPS Authorizing Official(s) (AOs) ensure that reports on information security operations status and incident reporting are provided to the policy authority as required by this policy.
* * * * *
10 Hardware and Software Security
* * * * *
10-4 General Practices for Hardware and Software
* * * * *
10-4.7 Maintaining Inventories
* * * * *
10-4.7.2 Individual Information Resource Inventories
[Revise the text of 10-4.7.2 to read as follows:]
All personnel are responsible for ensuring accurate inventories are maintained of Postal Service information resources assigned to them including hardware, non-ACE software, firmware, and documentation. The inventory management process must ensure accountability and must include current copies of hardware and non-ACE software maintenance agreements, licenses, purchase orders, and serial numbers. The inventory must indicate the individual authorized to use the information resource. The category supports granting access to auditors or other authorized personnel. The business system owner (VP or Mgr) grants access to auditors or other authorized personnel and the FSC (Functional System Coordinator) reviews and provides access. Information resources supporting PCI are labeled with information that can be correlated to the application purpose, owner contact information, and the personnel authorized to use the information resource.
Payment cardholder media must be inventoried and the inventory reconciled semiannually.
* * * * *
11 Network Security
11-1 Policy
* * * * *
11-1.1 Generic Information Security Architectural Standards Network Architecture
* * * * *
11-1.1.4 Externally Facing Websites
[Revise the text of 11-1.1.4 to read as follows:]
An HTTPS-Only standard is used for all external-facing USPS web services browsers and other HTTPS clients are configured to trust a set of certificate authorities that can issue cryptographically signed certificates on behalf of web service owners and communicate to the client that the web service host demonstrates ownership of the domain to the certificate authority at the time of certificate issuance. Internally issued certificates will not be permitted for web services whose users may not always be expected to trust the issuing federal certificate authority. These web services use a certificate issued from a publicly trusted certificate authority. The CISO is responsible for reviewing and approving, where applicable, requests for certificates from an external CA.
* * * * *
11-6 Network Connections
* * * * *
11-6.1 Establishing Network Connections
[Revise the text of 11-6.1 to read as follows:]
The NCRB must approve all system network access before connectivity is established to the USPS network. Systems with high or moderate impact values with respective confidentiality, integrity, or availability security objectives have unique identity and authenticate network devices before establishing a connection to the USPS network. All connectivity to the USPS network must be monitored and audited in advance of the establishment of network connectivity. Any connectivity to the Postal Service network must allow monitoring.
* * * * *
11-11 Wireless Networking Requirements
* * * * *
11-11.3 Standard Wireless Solution
* * * * *
11-11.3.2 Architecture Requirements
* * * * *
[Revise the text of item a4 to read as follows:]
4. Application and Network device owners using PKI-based encryption on any wireless device implement and maintain a key management plan as identified within this policy document and approved by CISO.
* * * * *
[Revise the title and text of Chapter 12 in its entirety.]
12 Service Continuity Management (formerly Business Continuity Management)
12-1 Policy
Service Continuity consists of the alignment of Business Continuity Plans (including Emergency Action Plans) and Disaster Recovery Plans.
The USPS CISO is responsible for the overall coordination of the USPS CIO Service Continuity (SC) which enhances the operational resilience of CIO partner organizations1, their systems and processes.
This policy develops the management and governance framework for USPS CIO SC organizations to prepare for, respond to, and recover from any event that disrupts, or threatens to disrupt, normal operations. This policy is applicable to all CIO Service Partners and Owners (see Chapter 2, Security Roles and Responsibilities).
This policy ensures that within the CIO organization, the creation of missing, review alignment and/or augmentation of existing; USPS Disaster Recovery (DR), Business Continuity (BC), Functional (FF) and Emergency Action (EAP) Plans as defined and mandated elsewhere in this document (Handbook AS-805) and Management Instruction (MI) AS-280-2018-1, Integrated Emergency Management Supporting Field Business Continuity (published January 2018).
This policy, its recommendations, and resulting products (plans) are in compliance with the following:
a. The National Institute of Standards and Technology (NIST) SP 800.34.
b. Homeland Security Exercise and Evaluation Program (HSEEP).
c. USPS Employee Labor Manual (ELM), 810, Occupational Safety and Health Program; 840, Safety Awareness Program; and 850, Emergency Action Plans and Fire Prevention and Control.
d. MI AS-280-2018-1, Integrated Emergency Management Supporting Field Business Continuity.
Specifically, this policy provides for the: identification, prioritization, and vetting of CIO and VP High Value Services (HVS); compliance with Federal and USPS standards and guidelines for recovery plan(s) documentation, maintenance (updating), testing, exercising and evaluation (TT&E); and personnel training.
An Information Security Management System is characterized by (per ISO 27001) the following:
a. Has a centrally managed framework for keeping information safe.
b. Protects the confidentiality, availability, and integrity of information.
c. Consists of a set of policies, procedures, and technical and physical controls.
d. Has a scope that can be applied to the entire organization or only a specific area or department.
e. Is based on an organization-wide risk assessment that considers internal and external risks.
f. Has had all risks assessed, analyzed, and evaluated against a set of predetermined criteria.
g. Has controls that are applied to treat risks based on the likelihood and impact of the risks.
h. Has controls that include technology as well as controls to manage people, resources, assets, and processes.
i. Helps you control risks that are specific to your own business environment.
j. Requires support and involvement from the entire business from the cleaner right up to the CEO.
k. Is not an IT function but a business management process.
l. Requires constant review, monitoring, audits, and continual improvement to be effective.
The CIO Service Continuity (SC) Program Policy develops all USPS CIO organization’s (CISO, EA, ENG, IT, and MEPT) capability to prepare for, respond to, and recover from any event that disrupts, or threatens to disrupt, normal operations which depend on services provided through the CIO organization. The program improves organizational and technical resilience processes and capabilities to ensure critical CIO services continue during and after an incident and applies to all USPS functional organizational elements and personnel.
This is achieved through the establishment and implementation standards and guidelines for CIO Service Continuity, which includes emergency management, service continuity and disaster recovery activities, standards and plans (operational risk). Its focus is based on the identification and prioritization of the CIO’s and VP’s high-value services and their recovery/hardening/resilience through a governance program which ensures maintenance and training on service continuity.
Specifically, through the development, documentation, and implementation of testing, exercising and evaluation processes, and documentation which validate compliance (or noncompliance) to (CIO SC) service continuity standards, guidelines, and processes, and effectively address noncompliance and corrective action.
Service owners develop strategies and plans to sustain functions during a disruption.
Resilience: is the ability to quickly adapt and recover from any known or unknown changes to the environment. Resiliency is not a process, but rather an end-state for organizations. The goal of a resilient organization is to continue mission essential functions at all times during any type of disruption. Resilient organizations continually work to adapt to changes and risks that can affect their ability to continue critical functions. Risk management, contingency, and continuity planning are individual security and emergency management activities that can also be implemented in a holistic manner across an organization as components of a resiliency program.
Contingency planning normally applies to information systems, and provides the steps needed to recover the operation of all or part of designated information systems at an existing or new location in an emergency.
Cyber Incident Response Planning is a type of plan that normally focuses on detection, response, and recovery to a computer security incident or event.
Organizations require a suite of plans to prepare themselves for response, continuity, recovery, and resumption of mission/business processes and information systems in the event of a disruption. Each plan has a specific purpose and scope; however, because of the lack of standard definitions for these types of plans, in some cases, the scope of actual plans developed by organizations may vary from the following basic descriptions.
The goal of a resilient organization is to continue functions at all times during any type of disruption. Resilient organizations continually work to adapt to changes and risks that can affect their ability to sustain operations. Risk management, contingency, and continuity planning are individual security and emergency management activities that can be implemented in a holistic manner across an organization as components of a resiliency program.
12-2 Business Continuity Plan Requirements
The purpose of business continuity plans are to ensure that business processes which rely upon personnel to perform specific functions will continue after an unplanned emergent event. This event may affect the prerequisite or dependent personnel, tools, or facilities and require that the function be relocated or that an alternate process be initiated.
Business Continuity Plans mitigate operational risk by doing the following:
a. Protecting personnel and identifying essential business processes during an incident or disaster.
b. Reducing the impact of an incident or disaster on facilities’ personnel and business processes.
c. Satisfying business continuity needs as defined by USPS management and aligning with industry best practices and United States federal government requirements and guidance.
The minimum requirements for Business Continuity Plans are defined in the following documents:
a. ASM, 28, Emergency Preparedness.
b. Management Instruction (MI) AS-280-2018-1, Integrated Emergency Management Supporting Field Business Continuity (published October 24, 2016).
c. Federal Continuity Directive 1 (FCD 1), “Federal Executive Branch National Continuity Program and Requirements” dated January 2017.
All CIO managed facilities will use the structure, tools, products, and nomenclature of the integrated emergency management (IEMM / IEMP) discipline to include the following:
a. Emergency Management Team (EMT) concept of operations.
b. Integrated Emergency Management Module (IEMM) within the Facilities Database System for data entry.
c. Integrated Emergency Management Plan (IEMP) that consists of emergency action, fire prevention, and continuity of operations (COOP) plans, and emergency response checklists.
d. Business Continuity Preparedness (BCP) cyclical requirements for testing, training, exercise, and review.
e. IEMP update and certification requirements.
12-3 Disaster Recovery Plan Requirements
12-3.1 General
All Application and Infrastructure Service owners must develop Disaster Recovery (DR) plans to provide for the resumption of automated systems in the event that those systems are unable to operate as built. Application teams develop Application Disaster Recovery Plans (ADRP). These plans make a reference to dependent Infrastructure Services but recovery of those services is not in scope for the ADRP. Infrastructure Services develop Infrastructure Disaster Recovery Plans (IDRP) that are designed to achieve the RTO (Recovery Time Objective) of the applications that rely on these services.
Both Applications and Information Technology Infrastructure systems need to be designed to achieve availability targets required to sustain the business functions they support. See 9-9 of this document for Availability requirements.
Application and Infrastructure Service owners may use templates when developing DR plans.
12-3.2 Application Disaster Recovery Plan Requirements
The Application Disaster Recovery Plan (ADRP) Requirements are as follows:
a. Each application that is registered in the Enterprise Information Repository (EIR) must have an ADRP.
b. The requirements for the plan are determined based on the Criticality results of the Business Impact Assessment (BIA). See 3-2.3 of this document for requirements of Criticality determination. The ADRP must be designed to achieve the recovery time objectives (RTO) required to meet the business requirements as specified in the BIA.
c. The ADRP does not include the recovery plans for the infrastructure that it’s dependent upon.
d. The ADRP documentation is stored in the Technical Solution Life Cycle (TSLC) IT Artifact Library systems documentation testing section of the application as Program-Level Artifacts and is considered “Sensitive”.
e. The ADRP must be reviewed, tested, and the results certified by the development organization and the executive sponsor. Evidence of the testing and certification must be kept in the TSLC IT Artifact Library as a Program-Level Artifacts and is considered “Sensitive”. Test results are also recorded in the EIR system.
f. ADRP’s Critical-High and Critical-Moderate applications must be tested within 180 days of the application going into production and within 180 days of changes which would invalidate previous tests.
g. Applications designated as Critical-High must be tested within 18 months of the last successful test.
h. Applications designated as Critical-Moderate must be tested within 36 months of the last successful test and within 12 months of changes which would invalidate previous tests.
i. Non-Critical (Low) applications can conduct a tabletop evaluations of the ADRP or can conduct a test of the ADRP. These tests must be repeated as least once every 5 years.
j. Failed tests must be re-attempted within 90 days of the failed test.
k. All recovery documents must be protected as restricted information.
12-3.3 Infrastructure Disaster Recovery Plan (IDRP)
Infrastructure Disaster Recovery Plan is an internal documented process or set of procedures to recover and protect the Postal Service IT Infrastructure in the event of a disaster as follows:
a. Many applications are dependent on shared information technology infrastructure services. Therefore, these services must be designed to meet the availability requirements of the applications using the service. See 9-9 for availability requirements.
b. The IDRP must support the RTO for the most critical application that uses the Infrastructure Service.
c. The IDRP must be developed and certified by the Infrastructure Service Owner and the executive sponsor (see 2-2.11, Executive Sponsors).
d. The IDRP must be maintained in the designated plan repository. The availability to the repository must not be dependent on any one facility.
e. Infrastructure Services must have contingency plans that address the following:
1. Loss of capacity due to failures of underlying requirements (power, cooling, facilities, servers, network, etc.).
2. Loss of connectivity.
3. Denial of Service attacks.
4. Data corruption.
f. The IDRP must be exercised quarterly to insure DR infrastructure services provide the same functionality as production.
g. Test activities and results are documented as part of the normal change and configuration management services.
The IDRP must include essential personnel to support and validate recovery.
* * * * *
The Postal Service incorporated these revisions into the online Handbook AS-805, Information Security, which is available on the Postal Service PolicyNet website:
n Go to blue.usps.gov.
n In the left-hand column under “Essential Links,” click PolicyNet.
n Go to the right-hand side under “Published Forms and Directives.”
n Click Handbooks.
The direct URL for the Postal Service PolicyNet website is blue.usps.gov/cpim.
— Corporate Information Security Office,
Chief Information Security Officer
and Digital Solutions, 1-3-19
