Attachment 38 - IT Security Requirements - 2018-09.docx

The vendor shall comply with The Federal Information Security Management Act (FISMA 2002) and now Federal Information Security Modernization Act (FISMA) 2014, Public Law 113-283.

In order to comply with FISMA, Risk Management Framework process must be followed that is described in NIST SP 800-37, Rev 1 (always follow the current revision) https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-37r1.pdf

1. Categorize the system by following FIPS 199 and NIST SP 800-60 https://csrc.nist.gov/publications/detail/fips/199/final https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v1r1.pdf https://csrc.nist.gov/publications/detail/sp/800-60/vol-2-rev-1/final

2. Select Security controls https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final

3. Implement Security Controls using the above (current version) publication

4. Assess Security Controls in accordance with below publication https://csrc.nist.gov/publications/detail/sp/800-53a/rev-4/final

5. Authorize the system (requires CISO and CIO signatures) NOTE: If a systems stores PII data, Privacy Impact Analysis (PIA) shall be conducted and approved prior to obtaining an authorization to operate, otherwise ATO will not be considered valid. A PIA shall be reviewed and approved by the DOC Chief Privacy Officer 60 days prior to ATO date.

6. Monitor the security controls on an ongoing basis for effectiveness, conducting security impact analysis for changes.

(NOTE: Annual re-authorization is required on all USPTO systems that process USPTO data) If the data is stored in the cloud, it must be a FedRAMP approved cloud service provider. https://marketplace.fedramp.gov/#/products?sort=productName Depending on the requirement, it must have IaaS, PaaS, SaaS, etc. Depending on the Cloud Service Model (i.e. IaaS, PaaS, and SaaS) selected by the Vendor it is the Vendor’s responsibility to implement security controls that are deemed Customer’s responsibility. For an example, if the Vendor selects IaaS to host the system then the Vendor is responsible for implementing Security Controls applicable to the platform and the application.

For additional information, see the below policies and IT security handbook.

All cybersecurity related policies and procedures are located here:* *Link will be provided at contract award.

image1.emf

OCIO-POL-63_CloudServicesUsage - RD 2018-0626.pdf

OFFICE OF THE CHIEF INFORMATION OFFICER

Cloud Services Usage Policy Version 1.0 1

CLOUD SERVICES USAGE POLICY

OCIO-POL-63

Date of Issuance: February 14, 2017

Effective Date: February 14, 2017

Version: 1.0

TABLE OF CONTENTS

Section

I. PURPOSE

II. AUTHORITY

III. SCOPE

IV. DEFINITIONS

V. POLICY

VI. GUIDANCE

VII. EXCEPTIONS

VIII. REFERENCES

IX. EFFECT ON OTHER POLICIES

I. PURPOSE

This policy establishes guidelines for the selection and use of cloud-based information systems by the

United States Patent and Trademark Office (USPTO). This policy is intended to supplement cloud usage policies established by the Office of Management and Budget (OMB), the Department of Commerce

(DOC), and other federal agencies.

II. AUTHORITY

This policy is issued pursuant to:

Federal Information Security Management Act of 2002 (FISMA)

Federal Information Security Modernization Act of 2014

Federal Cloud Computing Strategy

National Institute of Standards & Technology (NIST) SP 800-145

National Institute of Standards & Technology SP 800-53 Rev 4

U.S. Department of Commerce Cloud Computing Policy

U.S. Department of Commerce CITR-024

Cloud Services Usage Policy

Cloud Services Usage Policy Version 1.0 2

U.S. Patent and Trademark Office IT Security Handbook

III. SCOPE

This policy applies to any USPTO acquisition of cloud computing services. The product owner and/or project manager must coordinate planning with the OCIO early in the planning process to avoid unnecessary problems later in the planning and acquisition lifecycle.

This policy pertains to the acquisition of services from a cloud service provider outside of the US Patent and Trademark Office. Internal cloud computing services are already covered by existing requirements.

This policy also applies to information systems owned or operated by contractors on behalf of the

USPTO.

IV. DEFINITIONS

Cloud Computing: Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud Computing services may be offered as an Infrastructure-as-a-Service, Platform-as-a-Service, or Software-as-a-Service.

Federal Risk Assessment and Management Program (FedRAMP): A government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.

Joint Authorization Board (JAB): The primary governance and decision-making body for the FedRAMP program. The JAB reviews and provides joint provisional security authorizations of cloud solutions using a standardized baseline approach. Chief Information Officers from the Department of Defense, the

Department of Homeland Security, and the General Services Administration serve on the Joint

Authorization Board (JAB).

Security Assessment and Authorization: Security control assessments provide a line of defense in knowing the strengths and weaknesses of an organization’s information system. Security controls assessment determines whether security controls in an information system are operating as intended.

Security authorization is the official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.

Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components.

Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure

Cloud Services Usage Policy Version 1.0 3 including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

Software as a Service (SaaS): The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

System Owner: An individual with day-to-day management and operational control over the system and direct oversight of the system/network administrators and operations staff. Although the Federal

Government has ultimate ownership of all USPTO data, systems and equipment, “owner” is the term commonly used by the National Institute of Standards and Technology (NIST) to refer to individuals with specific systems oversight responsibilities.

Authorizing Official: Official with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals.

Risk Acceptance Memorandum: A memorandum that documents known security risks which impacts the confidentiality, integrity, and availability of the information system. In addition to documenting the risk, the memorandum details any business justification to support the acceptance of risk in addition to any compensating security controls in place for risk mitigation. This memorandum is acknowledged and signed by the System Owner and Authorization Official.

Confidentiality: The property, that information is not made available or disclosed to unauthorized individuals, entities, or processes.

Integrity: Maintaining and assuring the accuracy and completeness of data over its entire life-cycle.

Availability: Ensuring that authorized parties are able to access the information or system when needed.

V. POLICY

Use of Cloud Computing services must be formally authorized in accordance with the NIST Risk

Management Framework and the USPTO assessment and authorization processes. Specifically:

Use of Cloud Computing services must comply with all current laws, IT security, and risk management policies.

Use of Cloud Computing services must comply with all privacy laws and regulations, and appropriate language must be included in the contract vehicle defining the Cloud Computing source responsibilities for maintaining privacy requirements.

Cloud Computing services must have an existing Agency or JAB Federal Risk and Authorization

Management Program (FedRAMP) authorization to be considered for use at USPTO. However, FedRAMP authorization alone is not sufficient to meet the requirement of authorization for

USPTO use of a particular service for a particular purpose. An appropriate Authorizing Official, sufficiently familiar with the context of the use of the service (including the mission requirements and associated Federal Information Processing Standard (FIPS) 199 impact level), and adequately

Cloud Services Usage Policy Version 1.0 4 informed of the associated risks through a risk assessment, must document an acceptance of risk and formal authorization of the use of the Cloud Computing service.

All use of Cloud Computing services must be approved in writing by the USPTO CIO and, when applicable, a designated Co-Authorizing Official. The Authorizing Official(s) will certify that security, privacy, and other IT management requirements have been adequately addressed prior to approving use of

Cloud Computing services.

The Cloud Computing service must meet all criteria documented in the DOC-CITR-024, “FedRAMP Applicability” policy before the Authorizing Official(s) provide written approval.

The Cloud Computing service may not be put into production use until written approval has been provided by the Authorizing Official(s).

The product owner and/or project manager must retain the CIO’s approval along with other investment documentation.

VI. GUIDANCE

In accordance with the DOC Cloud Computing Policy, the following issues should be considered carefully before adopting a Cloud Computing solution. The list below features some of the more important issues to consider, and to address in contract language, when appropriate:

Identify and consider appropriate existing contracts and Cloud Computing solutions already in use at the Department of Commerce or USPTO before acquiring new services.

When acquiring new services, consider how services can be architected and agreements written in a way that would enable broader use/adoption of the service across the rest of the organization.

IT Security:

o Match IT security requirements (including FIPS 199 impact level) and the security capabilities of the Cloud Computing implementation to those of the mission/business needs being supported.

o Weigh the security threats and opportunities that are present for public, private, and community Clouds.

o Consider how issues of logging, incident reporting, response, forensics, and other security-related functions should be addressed with respect to the Cloud Computing service provider.

o Consider how disaster recovery and continuity of operations planning will be addressed.

Privacy Impact:

o If Personally Identifiable Information (PII) or other sensitive information is involved, document how it will be protected and who is allowed access to it.

o If the Cloud Computing source is keeping user usage statistics, consider the privacy implications involved and define appropriate safeguards to assure user privacy is maintained. This would include session logs and security access logs, among others.

o Define how all relevant provisions of the Privacy Act will be enforced, and identify responsible parties.

Records Management:

o Identify all systems of records to be hosted in the cloud.

Cloud Services Usage Policy Version 1.0 5 o Identify the schedules for all records and include the information on retention as part of the agreement with the vendor.

o Specify the retention time for all system backups.

o Consider how records management and electronic discovery will be managed in the cloud environment.

Consider implications of using a service model that is different from the traditional use of

Government-owned and -operated infrastructure.

Identify which issues should be explicitly documented in service level agreements.

Consider issues of interoperability with existing systems.

Consider issues of data ownership and portability. How would you migrate from a given Cloud

Computing infrastructure to another one at some point in the future?

Examine the need for additional training for Departmental staff.

Focus on the requirement driving the need, not the technology used to implement it.

Determine how mature the industry offerings are for the implementation under consideration.

VII. EXCEPTIONS

Exceptions to this policy shall be determined on a case-by-case basis using the process as defined in the

USPTO IT Security Handbook and the IT Policy on Security Risk Acceptance (OCIO-POL-35). In some cases, a Risk Acceptance Memorandum may need to be issued to accept any residual security risk in order to operate the information system. Some Cloud Computing services may have security assessment and risk reports available, but not yet have FedRAMP authorization. Such services may be considered for conditional adoption following a complete risk assessment by USPTO.

VIII. REFERENCES

E-Government Act (Public Law 107-347), Title III - Federal Information Security

Management Act (FISMA), December 2002.

FIPS Publication 199, Standards for Security Categorization of Federal Information and

Information Systems, February 2004.

FIPS Publication 200, Minimum Security Requirements for Federal Information and

Information Systems, March 2006.

Office of Management and Budget (OMB) Circular A-130, Management of Federal

Information Resources, Appendix III, Revised November 2000.

OMB Memorandum M-03-22 Guidance for implementing the Privacy Provisions of the E-

Government Act of 2002.

OMB M-06-15, Safeguarding Personally Identifiable Information, May 2006.

OMB M-06-16, Protection of Sensitive Agency Information, June 2006.

OMB M-06-19, Reporting Incidents Involving Personally Identifiable Information and

Incorporating the Cost for Security in Agency Information Technology Investments, July 2006.

OMB M-07-16, Safeguarding Against and Responding to the Breach of Personally

Identifiable Information, May 2007.

Cloud Services Usage Policy Version 1.0 6

The Privacy Act of 1974, 5 U.S.C. §552a.

Federal Cloud Computing Strategy, February 8, 2011.

U.S. Department of Commerce, IT Security Program Policy, September 2014.

U.S. Department of Commerce, CITR-024 FedRAMP Applicability, March 29, 2016.

U.S. Department of Commerce, Cloud Computing Policy.

U.S. Patent and Trademark Office, Comprehensive Records Schedule.

U.S. Patent and Trademark Office, IT Policy on Security Risk Acceptance.

U.S. Patent and Trademark Office, IT Security Handbook.

U.S. Patent and Trademark Office, Rules of the Road.

IX. EFFECT ON OTHER POLICIES

This policy does not conflict with any existing OCIO or USPTO policies.

ISSUED BY:

OFFICE OF PRIMARY INTEREST: Office of Organizational Policy and Governance image2.emf

USPTO_IT_Security_Handbook-2018-0628.pdf

For Official Use Only

UNITED STATES

PATENT AND TRADEMARK OFFICE (USPTO)

IT SECURITY HANDBOOK

March 26, 2018

Version 5.3

USPTO IT Security Handbook March 2018 ii

DOCUMENT HISTORY

Change

Number

Date of

Sections

Changed Revision Summary

Person

Approving v0.5 04/26/07 All Initial Submission Quentin

Robinson v0.6 07/18/07 All Revised all sections based on renaming remaining LOE as per USPTO TOM v0.7 8/23/07 All New org structure incorporated more minor edits.

v0.8 10/3/07 All General editing v2.5 12/20/07 All General Editing v2.8.1 6/16/08 Signature Changed Approving Authority Katherine Queen v3.0 12/13/10 All

- Replaced/ removed outdated and superseded references.

- Added references to additional

Federal, DOC, and USPTO policies and procedures.

- Removed processes and procedures contained in, and repetitive of, lower tier documents.

- Revised and added to security controls that were not completely or correctly addressed.

- Reformatted to comply with current

CIO Policy Documents template.

- Updated Acronym and Terms lists.

- Corrected spelling and grammar errors throughout.

Missing Link

Security v3.0.1 4/7/11 All

Revised all sections to make it consistent with the Department of

Commerce IT Security Program Policy

(DOC ITSPP) and NIST 800- 53 Rev

3.

A3IS

v3.1 12/19/11 All

- Replaced/ removed outdated and superseded references.

- Added references to additional

Federal, DOC, and USPTO policies

- Removed processes and procedures contained in, and repetitive of, lower tier documents.

- Revised and added to security iii controls that were not completely or correctly addressed.

- Updated Acronym and Terms lists.

- Corrected spelling and grammar errors throughout.

v3.2 12/23/11 All

- Changes implemented per comments received.

v3.3 1/13/12 All

- Fixed formatting inconsistencies.

- Updated per comments received during review cycle v3.4 2/3/12 All

- Removed all IT Security Handbook

Policy references

- Updated CM-7 requirements v3.5 2/29/2012 All - Update RA-5 requirements v3.6 5/09/2012 All

- Updated per comments received during final review cycle v3.7 8/21/2012 All

- Updated AC-2 requirements

- Changed SAISO to SISO

- Updated roles and responsibilities v3.8 2/08/2013 Role and

Responsibilities

- Added FPOC Role

- Removed SLIC reference v4.0 10/2013 All - Revised to address 800-53 Rev.4 A3IS

V4.1 11/2014 All - Annual review and update A3IS

V4.2 12/30/2014 Section 4.8

- Incident Response Reporting requirements were updated based on new DOC guidance

V 4.3 12/16/2015 Multiple sections

- Annual review and updates – removed reference to management, operational and technical controls throughout the document; updated document with the most recent NIST guidance, USPTO and DOC policy and procedures and updated links;

updated section 2.1; added section

3.2.9: Information Owner/Steward;

added privacy controls under

Appendix A; updated Appendix C and D; updated following security control requirements: all dash 1 security controls, AC-2.11, AC-4, AC-6, AC-7, AC-8, AC-12, AC-14, AC-18.1, AC-19, AC-21, AT-3, iv

AU-2, AU-5.2, AU-6, AU-9.4, AU-

11, CA-5, CM-2.7, CM-3, CM-7.2,

CM-7.4, CM-7.5, CP-4, IA-2.11, IA-

5, IA-5.1, IR-3, MP-5, PE-15, PE-17,

PL-2.3, PS-8, RA-5, SA-3, SA-4,

SC-5, SC-7.3, SC-7.4, SC-13, SC-23

SI-2, SI-7, SI-7.1, SI-16, PM-5, PM-

6, AR-7.

V 4.4 05/09/2016 Section 4.7

- IA-5, IA-5(1) security controls to address public facing systems authenticator requirements

V 4.5 7/11/2016

- AC-8; reference to DOC ITSSP A3IS

V 4.6 8/31/2016

- IA-5, IA-5(1) with further clarification on public facing systems

V. 4.7 9/19/2016

- Section 3.2.16, IR-6 (incident reporting to address new DOC

Incident Response Policy);

v. 4.8 12/31/2016 Annual review and update

Section 4.1.4 RA-5 (scanning requirements)

V 4.9 02/10/2017

-Added DOC CITR-024, FedRAMP

Applicability reference to section 2.1

-Added FedRAMP applicable security controls to Section IV along with

FedRAMP requirements

-Updated all dash 1 security controls in section 4 to identify that policy and procedures updates are done as needed and annually

-Added banner note to AC-8

-Added FedRAMP requirements relevant to AC-20

-AU-8- updated to one second requirement for DOC consistency

-IR-6 updated to address OIG requirement to report incidents as necessary to OIG and law enforcement

-Added NIST 800 52 rev 1 TLS requirements to SC-23

V 5.0 4/14/2017 Section 4.1.4 Updated RA-5 scanning requirement to address OIG audit finding

V 5.1 6/12/2017 Section 4.1,

4.5 -Updated CM-7.2, 7.4 and CM-11 with unapproved software removal v information.

-Updated AC-6 and enhancements 1, 2 and 9 with new requirements from

DOC CITR-026.

-Updated AC-2 to address requirement for review of privileged accounts twice a year.

V 5.2 8/22/2017 Section 4.13

Updated PS-4, PS-7 control to address

KPMG audit and clarify employee or contractor termination and account deactivation requirements.

V 5.3 03/26/2018

Updated following:

-All dash 1 security controls to distinguish between review and update requirement.

-AC-2, to address service and non human accounts requirement, including review of privileged account twice a year per DOC CITR-026.

-AC-6, updated to address CITR-026 requirements.

-AC-12, added requirement on termination of remote session and privileged accounts session.

-AU-3, addressed audit requirements for data extracts from database holding sensitive information.

- CA-2, added section on CSP

FedRAMP requirements.

-CP-4, added section on CIO approval for performing tabletop CP exercises for the systems with the low FIPS 199 availability categorization and defined functional and tabletop exercises

-IA-5, added PIV cards usage for initial

PTONet access to Note section.

-IR-6, updated section on external communication associated with incident.

-PE-17, updated ERA portal to Team

Portal.

-PS-4, PS-5 to address A-123 Audit.

-SA-9, added section on CSP vi

FedRAMP requirements references.

-SC-28, added section on allowed mechanisms to achieve confidentiality and integrity of data at rest.

-SI-5, added DOC CIRT, OMB and vendors as external organizations that

USPTO receives security alerts and advisories.

-PM-4, added references to POA&M minimum standards.

vii

Table of Contents

1 INTRODUCTION

1.1 BACKGROUND

1.2 PURPOSE

1.3 SCOPE, MANAGEMENT COMMITMENT AND COORDINATION, AND APPLICABILITY

1.4 UPDATE AND REVIEW

1.5 AUTHORITY

1.6 COMPLIANCE

1.7 USPTO IT SECURITY PROGRAM DOCUMENTATION

2 IT SECURITY HANDBOOK

2.1 EFFECTIVE DATE

2.2 RISK ACCEPTANCE

2.3 ENFORCEMENT

3 IT SECURITY ROLES AND RESPONSIBILITIES

3.1 PERSONNEL

3.2 ROLES AND RESPONSIBILITIES

3.2.1 USPTO Chief Information Officer (CIO)

3.2.2 Co-Authorizing Official (Co-AO)

3.2.3 Authorizing Official Designated Representative (AODR)

3.2.4 USPTO Business Area Heads

3.2.5 USPTO Senior Information Security Officer (SISO)

3.2.6 USPTO Risk Executive Function

3.2.7 USPTO Security Authorization and Compliance Manager

3.2.8 USPTO System Owner

3.2.9 Information Owner/Steward

3.2.10 USPTO Common Control Provider

3.2.11 USPTO Information System Security Manager (ISSM)

3.2.12 USPTO Information System Security Officer (ISSO)

3.2.13 USPTO Facilitation Point of Contact (FPOC)

3.2.14 USPTO System and Network Administrators/Technical Lead (TL)

3.2.15 USPTO Security Control Assessor

3.2.16 USPTO Computer Incident Response Team

3.2.17 Key Contingency Roles

3.2.18 USPTO Senior Agency Official for Privacy

3.3 ADDITIONAL ROLES

3.3.1 Contracting Officer (CO)

3.3.2 Contracting Officer’s Technical Representative (COTR)

3.4 USPTO OFFICES

3.4.1 Office of the Chief Information Officer (OCIO)

3.4.2 Office of Organizational Policy and Governance (OPG)

3.4.3 Office of Infrastructure Engineering and Operations (IEO)

3.4.4 USPTO Office of Security

3.4.5 Office of Inspector General (OIG)

4 IT SECURITY CONTROLS

4.1 ACCESS CONTROL (AC)

4.2 AWARENESS AND TRAINING (AT)

4.3 AUDIT AND ACCOUNTABILITY (AU)

4.4 SECURITY ASSESSMENT AND AUTHORIZATION (CA)

viii

4.5 CONFIGURATION MANAGEMENT (CM)

4.6 CONTINGENCY PLANNING (CP)

4.7 IDENTIFICATION AND AUTHENTICATION (IA)

4.8 INCIDENT RESPONSE (IR)

4.9 MAINTENANCE (MA)

4.10 MEDIA PROTECTION (MP)

4.11 PHYSICAL AND ENVIRONMENTAL PROTECTION (PE)

4.12 PLANNING (PL)

4.13 PERSONNEL SECURITY (PS)

4.14 RISK ASSESSMENT (RA)

4.15 SYSTEM AND SERVICES ACQUISITION (SA)

4.16 SYSTEM AND COMMUNICATIONS PROTECTION (SC)

4.17 SYSTEM AND INFORMATION INTEGRITY (SI)

4.18 PROGRAM MANAGEMENT (PM)

5 PRIVACY CONTROLS

5.1 AUTHORITY AND PURPOSE (AP)

5.2 ACCOUNTABILITY, AUDIT, AND RISK MANAGEMENT (AR)

5.3 DATA QUALITY AND INTEGRITY (DI)

5.4 DATA MINIMIZATION AND RETENTION (DM)

5.5 INDIVIDUAL PARTICIPATION AND REDRESS (IP)

5.6 SECURITY (SE)

5.7 TRANSPARENCY (TR)

5.8 USE LIMITATION (UL) ................................................................................................................................ A-1 APPENDIX A. ACRONYMS AND ABBREVIATIONS ........................................................................ A-2 APPENDIX B. GLOSSARY ....................................................................................................................... B-1 APPENDIX C. REFERENCES ................................................................................................................... C-1 APPENDIX D. ................................................................................................................................................... D-1 IT SECURITY LAWS AND FEDERAL REGULATIONS ............................................................................ D-1

1 Introduction

The Federal Information Security Modernization Act (FISMA) provides a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support

Federal operations and assets, and defines “adequate security” as security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information. This includes ensuring that systems and applications used by the agency operate effectively and provide appropriate confidentiality, integrity, and availability with cost effective security and privacy controls. This document sets forth the United States Patent and Trademark Office (USPTO) IT Security

Handbook.

1.1 Background

The National Institute of Standards and Technology (NIST) Federal Information Processing Standards

(FIPS) Publication 200, Minimum Security Requirements for Federal Information and Information

Systems, directs that all Federal Government agencies ensure that adequate security controls be implemented for their information subsystems. The guidelines provided in FIPS 200 are applicable to all federal information systems other than those systems designated as national security systems as defined in 44 U.S.C., Chapter 35, Coordination of Federal Information Policy § 3542. This handbook describes how the United States Patent and Trademark Office (USPTO) will comply with FISMA and other related directives.

The IT security policies captured in this Handbook were developed to meet the minimum legally and federally mandated requirements for information security and are based on the Federal Government standards and procedures issued by the Office of Management and Budget (OMB), NIST, and the

General Services Administration (GSA). Appendix C of this Handbook provides a list of references used in developing this handbook.

1.2 Purpose

The purpose of this USPTO IT Security Handbook is to document security policies and procedures, in accordance with Federal government mandated requirements. This Handbook addresses requirements and guidance set forth by the Federal Information Security Modernization Act (FISMA). It also encompasses minimum security controls as required by the Federal Information Processing Standard

(FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems; and defined by the current National Institute of Standards and Technology (NIST) Special Publication (SP)

800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, commensurate with security categorization defined by FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.

1.3 Scope, Management Commitment and Coordination, and Applicability

The provisions of this Handbook apply to all USPTO employees and contractor employees accessing or using USPTO information subsystems or data processed, transmitted, and/or stored on USPTO information subsystems; and to contractor employees providing services to the USPTO who use

USPTO information subsystems or data. This Handbook applies to all USPTO information systems and supporting resources, independent of size, location, or interconnection(s). Additionally, this

Handbook applies to all types of media used to store USPTO agency sensitive information and personally identifiable information (PII) which includes, but is not limited to: (i) hard drives, (ii) CDs,

(iii) DVDs, (iv) other magnetic media such as floppy disks, and (v) solid-state media (Universal Serial

Bus (USB) flash drive). Finally, it applies to all media output (to include digital, hard-copy (paper records), and microfilm formats) that contain USPTO classified or agency-sensitive information and

PII.

This Handbook also applies to information subsystems and equipment, including network devices, operated and used by contractor employees, guest researchers, collaborators, and other federal agencies that help to carry out the USPTO mission, whether or not such information subsystems or equipment are owned or leased by the government or on government property. The security policies set forth in this

Handbook apply to all IT procurement activities.

1.4 Update and Review

Policies will be reviewed as needed, and at minimum, on an annual basis. Policies may be reviewed more frequently as necessary (e.g., due to new Federal or USPTO mandates updates and changes Refer to

USPTO OCIO Policy Management (OCIO-1001-09) for further details.

1.5 Authority

This Handbook is issued under the authority of the USPTO Chief Information Officer (CIO). The most critical Federal laws, regulations, Executive Orders, policies, standards, and directives followed are indicated below.

E-Government Act of 2002

The Privacy Act of 1974

Clinger-Cohen Act of 1996

National Technology Transfer and Advancement Act of 1996

Health Insurance Portability and Accountability Act of 1996 (HIPAA)

Federal Information Security Management Act of 2002 (FISMA)

Federal Information Security Modernization Act of 2014 (FISMA)

Federal Financial Management Improvement Act of 1996 (FFMIA)

Federal Acquisition Streamlining Act of 1994 (FASA)

United States Government Accountability Office, Federal Information System Controls Audit

Manual (FISCAM)

OMB Circulars

OMB Memoranda

Federal Information Processing Standards (FIPS)

NIST Special Publications

1.6 Compliance

Compliance with this Handbook is mandatory. It is USPTO policy that personnel and information systems abide by or exceed the requirements outlined in this Handbook and the associated procedures for each NIST SP 800-53 rev 4 family of controls. The Senior Information Security Officer (SISO) will periodically assess USPTO’s adherence with this Handbook through various oversight and compliance measures.

In cases where an information systems cannot comply with this Handbook, for technical or financial reasons, or because it precludes USPTO from supporting mission or business functions, justifications for non-compliance must be documented using the risk acceptance process, addressed by the System Owner, and submitted to the CIO via the SISO. Risk Acceptance process is officially documented in the USPTO

IT Policy on Security Risk Acceptance, OCIO-POL-35.

1.7 USPTO IT Security Program Documentation

This Handbook is organized into five sections to address information security as follows:

Section 1 – Introduction: Describes the background, purpose, scope, and documentation.

Section 2 – IT Security Handbook: Describes the authority, effective date, risk acceptance memos, and enforcement.

Section 3 – IT Security Roles and Responsibilities: Provides an outline of the departmental offices, roles, and IT groups.

Section 4 and 5 – Baseline Security Controls: Contain a complete list of security controls with

USPTO specific criteria including additional FedRAMP controls and program management and privacy controls.

A listing of acronyms, terms, and references can be found in the appendices.

2 IT Security Handbook

USPTO shall develop, document, and implement an IT security program to protect the confidentiality, integrity, and availability of USPTO information and systems in accordance with the

Federal Information Security Modernization Act (FISMA) of 2014.

USPTO shall use FIPS 199 to categorize information systems and determine their appropriate impact levels (Low, Moderate, or High). The USPTO shall select the security controls baseline defined in current NIST SP 800-53, rev 4 based on the system’s impact level, and tailor, supplement, and implement the baseline according to NIST 800-53. The USPTO shall use current NIST SP 800-53A, Revision 4, Guide for Assessing Security and Privacy Controls in Federal Information Systems and

Organizations, Building Effective Assessment Plans, as the basis for assessing information system security controls to determine the extent to which they are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements. The

USPTO shall authorize information systems in accordance with the current NIST SP 800-37 revision

1, Guide for Applying the Risk Management Framework to Federal Information Systems, A Security

Life Cycle Approach. The USPTO shall be compliant with revisions to the aforementioned documents within one year of their issuance.

2.1 Effective Date

The USPTO IT Security Handbook is effective when signed by the CIO, superseding previous versions of this document. This version also incorporates the requirements of the following DOC Commerce

Information Technology Requirements (CITRs), which will remain in effect until superseded by updated

CITRs:

CITR-005: Removable Media Devices

CITR-006: Information System Security Training for Significant Roles

CITR-008: Remote Access

CITR-011: Peer-to-Peer Technology

CITR-014: Wireless Encryption Enhancements Policy

CITR-015: Contingency Plan Testing

CITR-016: Vulnerability Scanning and Patch Management

CITR-017: Security Configuration Checklist Program

CITR-018: IT Security Plan of Action and Milestones (POA&M)

CITR-019: Risk Management Framework

CITR-020: Safeguarding Information while on Foreign Travel

CITR-021: Password Management

CITR-022: Access and Use Policy

CITR-023:Pre-Acquisition Supply Chain Risk Assessment

CITR-024: FedRAMP Applicability

CITR-026: Privileged Accounts Management

For information about all current CITRs, please visit the DOC IT Security Program Policy website:

https://connection.commerce.gov/policy/20140528/it-security-program-policy-and-commerce-information-technology-requirements https://connection.commerce.gov/policy/20140528/it-security-program-policy-and-commerce-information-technology-requirements https://connection.commerce.gov/policy/20140528/it-security-program-policy-and-commerce-information-technology-requirements

The following USPTO OCIO policies and procedures were merged into the associated NIST family-based set of procedures:

Access Control (AC) Procedures o OCIO-5001-09: Administrative Access Rights o OCIO-POL-12: Password Protected Screensaver o OCIO-POL-15: Remote Access o OCIO-POL-48: IT Separation of Duties o OCIO-POL-41: IT User Account Deactivation o OCIO: POL-34: Mobile Device Management

Audit and Accountability (AU) Procedures o OCIO-POL-20: Network and AIS Audit, Logging, and Monitoring

Awareness and Training (AT) Procedures o OCIO-POL-19: IT Security Education Awareness Training

Configuration Management (CM) Procedures o OCIO-POL-31: Enterprise Configuration Management o OCIO-POL-32: Enterprise Change Management o OCIO-POL-6: Information Security Foreign Travel o OCIO-POL-13: Peer To Peer Software and File Sharing

Contingency Planning (CP) Procedures

Identification and Authentication (IA) Procedures o OCIO-POL-21: Password Management o OCIO-POL-49: Personal Identity Verification (PIV) Card Authentication

Incident Response (IR) Procedures o OCIO-POL-45: CIO Command Center (OCIO) o OCIO-POL-17: Breach Notification

Maintenance (MA) Procedures

Media Protection (MP) Procedures o OCIO-POL-23: Personally Identifiable Data Removal o OCIO-PRC-9: Sanitization and Disposal of Mobile Devices

Personnel Security (PS) Procedures o OCIO-POL-41: IT User Account Deactivation

Physical and Environmental Protection (PE) Procedures o OCIO-5012-09: IT Facility Emergency Power Off (EPO) Switches o OCIO-POL-6: Information Security Foreign Travel

Planning (PL) Procedures o OCIO-POL-18: IT Privacy o OCIO-POL-36: Rules of the Road o OCIO-POL-35: IT Policy on Security Risk Acceptance

Program Management (PM) Procedures o OCIO-1001-09: Policy Management

Risk Assessment (RA) Procedures o Vulnerability/Compliance Scanning and Analysis Standard Operating Procedures o OCIO-POL-35: IT Policy on Security Risk Acceptance

Security Assessment and Authorization (CA) Procedures o OCIO-POL-51: OCIO Agreements with US Federal Agencies and International

Organizations o USPTO Continuous Monitoring Procedures

System and Services Acquisition (SA) Procedures o OCIO-1004-10: IT Desktop Hardware Acquisition Management o OCIO-1006-10: Contractor Performance Information o OCIO-POL-24: System Development Life Cycle (SDLC) o OCIO-POL-38: Server and Storage Provisioning

System and Information Integrity (SI) Procedures o OCIO-POL-16: Anti-Virus

System and Communications Protection (SC) Procedures o OCIO-POL-14: Certificate Policy for the USPTO o OCIO-POL-23: Personally Identifiable Data Removal o OCIO-POL-18: IT Privacy

For information about these USPTO Policies, visit the USPTO intranet site:

https://usptogov.sharepoint.com/sites/a142efd3/Documents/Forms/All%20Approved%20Documents

.aspx

System Owners are required to comply with this Handbook within 120 days of its effective date.

Compliance with this Handbook beyond the specified timeframe shall be managed through the Plan of Action and Milestones (POA&Ms).

The USPTO Senior Information Security Officer (SISO) will review the USPTO IT Security

Handbook at least annually or more often if needed and incorporate updates as necessary including new federal requirements. The revised USPTO IT Security Handbook shall be reviewed and approved by the concurrence of the USPTO CIO. Subsequent to this, the USPTO Cybersecurity

Division will incorporate the changes into this Handbook and the revision shall be reviewed by, and meet the concurrence of USPTO stakeholders before presentation to the CIO for signature.

2.2 Risk Acceptance

The USPTO Authorizing Officials (AOs) shall approve the tailoring of security control baselines.

For controls and parameters that require risk acceptance memos, requests shall be submitted to the

USPTO CIO, through the SISO. In addition, the USPTO CIO has the discretion to elevate the risk acceptance approval process to the level of the Office of the Department of Commerce CIO when actions or controls are identified that affect department-wide security. Risk acceptance memo requests shall justify and describe the controls that cannot be fully implemented and the compensating controls in-place. Corrective action items shall be specified in the risk acceptance requests, if appropriate. System Owners (SO) shall use the POA&Ms to track and manage progress towards compliance.

Upon request from the USPTO CIO, each SO shall verify the Department-level risk acceptance requirements and submit copies of risk acceptance memos for performing Department-wide trend analysis and Enterprise risk management.

The risk acceptance process shall be implemented as follows:

Risk Acceptance requests shall be submitted to the CIO, via the SISO;

Risk Acceptance memo shall be addressed from the System Owner;

https://usptogov.sharepoint.com/sites/a142efd3/Documents/Forms/All%20Approved%20Documents.aspx

Risk acceptance requests shall justify and describe the controls that cannot be fully implemented and the compensating controls in-place;

Corrective action items shall be specified in the risk acceptance memo requests, if appropriate;

Risk acceptance requests should include a POA&M describing the plan to come into conformance with policy or the risk accepted control;

The USPTO CIO has the discretion to elevate the risk acceptance approval to the Department

CIO in the event the risk acceptance affects Departmental security; and

The CIO has 30 days to respond to a risk acceptance memo request. This response shall include:

o Approval, and conditions for approval, including expiration date o Denial, or basis for denial, if that is the decision o Additional information on the risk acceptance request as identified by the CIO.

Please refer to the USPTO IT Policy on Security Risk Acceptance, OCIO-POL-35 for more details.

2.3 Enforcement

Failure to comply with any provisions of the Handbook may result in administrative or adverse action in accordance with the Office of Human Resources (OHR) policies. Perceived threats to system integrity, confidentiality, or availability shall result in suspension of system access as necessary to contain the perceived threat. An offense that is in violation of local, state, or Federal laws may result in suspension of system access and shall be reported to the appropriate law enforcement authorities.

USPTO IT security policies shall be enforced through the following:

Oversight

Inspection

Audit

Each USPTO Contracting Officer’s Technical Representative (COTR) has contract oversight security responsibility and shall ensure that contractor-related security requirements are followed throughout the contract life-cycle.

3 IT Security Roles and Responsibilities

The responsibility to protect USPTO information and technological resources extends to all non-public users and requires collaboration across various offices to coordinate activities associated with the USPTO security posture, technological environment, and overall risk management.

3.1 Personnel

All USPTO employees and contractor employees are responsible for carrying out the provisions of this Handbook.

3.2 Roles and Responsibilities

The key roles and responsibilities for carrying out the provisions of this Handbook are outlined below.

3.2.1 USPTO Chief Information Officer (CIO)

Within the USPTO, the role of Authorizing Official (AO) is generally assigned to the CIO. The CIO manages USPTO’s Information Technology (IT) infrastructure and its risk management program.

The CIO has the following IT Security responsibilities:

Develop, maintain, and oversee the USPTO IT Security Program;

Appoint, in writing, a Senior Information Security Officer (SISO) to implement the IT Security

Program within USPTO;

Ensure, in coordination with senior USPTO officials, the implementation of the requirements of a

USPTO-wide IT Security Program (as specified in § 3544, paragraph (b), of the FISMA);

Ensure the USPTO annually performs an independent evaluation of the IT Security Program and its practices (as specified in § 3545 of the FISMA);

Provide overall management of and leadership and direction to the IT Security Program;

Assist and advise senior agency officials regarding their responsibilities for security, including

System Security Plans (SSPs);

Report regularly on the status of the IT Security Program to the Director and advise the Director on Security matters;

Consult with and brief USPTO Executive Management regarding all critical information system security issues;

In coordination with other agency officials, report annually to the agency head on the effectiveness of the agency information security program, including progress of remedial actions;

Assess and advise the USPTO Director of weaknesses In the IT Security Program, as appropriate, for annual accountability reporting;

Ensure managers for all IT resources are identified and that security authorization for those resources are accomplished within the planned timeframe;

Determine the acceptable level of residual risk for an information subsystems and if an information subsystems will adequately protect sensitive USPTO information;

Approve SSPs;

Review the Security Authorization Package (SAP) and sign the Authorization Decision

Document. The following authorization decisions can be made by the AO:

o Authorization To Operate (ATO) – Full authorization will be granted when all of the following apply:

The authorization package is complete.

No corrective actions are required or may require minor corrective actions.

(Note: There may be findings during the authorization effort that are turned into a

POA&M, but do not prevent an ATO).

Residual risks are acceptable to the AO.

o Authorization To Operate (ATO) with Conditions – Special type of authorization allowing an information system to operate in an operational environment by assessing a limited set of controls to include volatile controls as defined by DOC CITR-19. This type of authorization will be given only when system need to be put in production to support continuity of organizational mission and business requirements. The system will be authorized to operate for a specified time period in accordance with the terms and conditions established by the authorizing officials. This limited authorization will be granted when all of the following apply:

Vulnerability scans have been performed on the system and there are no major high risk vulnerabilities discovered. If necessary corrective actions (POA&Ms) are identified.

Volatile controls, as determined by DOC, have been assessed.

Residual risks are accepted for a limited time identified in the ATO letter that also includes all terms and conditions that need to be completed associated with the given ATO termination date.

o Interim Authority to Test (IATT) – The USPTO AO can exercise its authority to grant this special type of authorization decision allowing an information system to operate in an operational environment for the express purpose of testing the system with actual operational (i.e., live) data for a specified time period. An interim authorization to test is granted by an authorizing official only when the operational environment or live data is required to complete specific test objectives.

o Denial of Authorization to Operate (DATO) – If the authorizing official, after reviewing the authorization package and any additional inputs provided by the risk executive

(function), deems that the risk to organizational operations and assets, individuals, other organizations, and the Nation is unacceptable and immediate steps cannot be taken to reduce the risk to an acceptable level, a denial of authorization to operate is issued for the information system or for the common controls inherited by organizational information systems. The system may not be placed into operation until at least an IATT is granted.

Monitor and report IT security program compliance with Federal laws and USPTO IT security policies;

Serve as the IT security liaison to external organizations;

Ensure sufficient resources are available to implement the USPTO IT security program in coordination with the Director and the Heads of USPTO Business Units;

Ensure USPTO IT security planning and execution is practiced throughout the life cycle of each

USPTO system;

Ensure a PTO Computer Incident Response Team (CIRT) is staffed, trained, and maintained in a state of readiness;

Ensure that persons with IT security responsibilities have appropriate role-based training;

Assist oversight groups in compliance reviews and other reporting requirements;

Provide feedback to oversight groups on the status of the program in USPTO and suggest improvements or areas of concern in the USPTO program;

Establish an overall strategy for the IT Security Awareness and Training Program;

Ensure the program is sufficiently staffed and funded to achieve its approved objectives in a timely manner;

Ensure effective tracking and reporting mechanisms are in place to accurately determine course completion, and to evaluate the awareness and training program;

Establish plans, procedures and schedules to correct any IT security awareness and training material weaknesses identified during formal inspections and evaluations; and

Ensure that USPTO IT security policies are developed, approved and maintained in a timely manner.

3.2.2 Co-Authorizing Official (Co-AO)

The role of USPTO Co-AO could be assigned to the chiefs/directors of following USPTO Offices: Patent

Office, Chief Administrative Officer, Chief Financial Officer, Equal Employment Opportunity and

Diversity, etc. The CO-AOs roles are documented in the respective system SSP. The Co-AO approves system security requirements including SSPs, ATO letters, IATT letter, etc.

The Co-AO is responsible for ensuring continued ATOs for systems under their responsibility by reaffirming acceptable Continuous Monitoring results and accepting risks at least annually for systems that fall under their responsibility.

The AO/CO-AO role has inherent U.S. Government authority and is assigned to government personnel only.

3.2.3 Authorizing Official Designated Representative (AODR)

The authorizing official designated representative is an organizational official that acts on behalf of an authorizing official to coordinate and conduct the required day-to-day activities associated with the security authorization process. Authorizing official designated representatives can be empowered by authorizing officials to make certain decisions with regard to the planning and resourcing of the security authorization process, approval of the security plan, approval and monitoring the implementation of plans of action and milestones, and the assessment and/or determination of risk.