SOL FINAL - Attachment 3 - OCIO-PRC-8 - IT Security Handbook.pdf

UNITED STATES

PATENT AND TRADEMARK OFFICE (USPTO)

IT SECURITY HANDBOOK

August 18, 2025

Version 6.1.1

USPTO IT Security Handbook August 2025

Office of the Chief Information Officer ii

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

2.4 USPTO GENERATIVE ARTIFICIAL INTELLIGENCE (AI)

3 IT SECURITY ROLES AND RESPONSIBILITIES

3.1 ROLES AND RESPONSIBILITIES

3.1.1 USPTO Chief Information Officer (CIO)/Authorizing Official (AO)

3.1.2 Co-Authorizing Official (Co-AO)

3.1.3 Authorizing Official Designated Representative (AODR)

3.1.4 USPTO Chief Information Security Officer (CISO)

3.1.5 USPTO Risk Executive Function

3.1.6 USPTO Security Authorization and Compliance Manager

3.1.7 USPTO System Owner (SO)/Product Owner (PO)

3.1.8 Information Owner/Steward

3.1.9 USPTO Common Control Provider

3.1.10 USPTO Information System Security Manager (ISSM)

3.1.11 USPTO Information System Security Officer (ISSO)

3.1.12 USPTO Risk Management Framework (RMF) Analyst

3.1.13 USPTO System and Network Administrators/Product Technical Lead (PTL)

3.1.14 USPTO Security Control Assessor

3.1.15 USPTO Computer Incident Response Team (PTOCIRT)

3.1.16 Key Contingency Roles

3.1.17 USPTO Chief Privacy Officer/Senior Agency Official for Privacy (CPO/SAOP)

3.2 ADDITIONAL ROLES

3.2.1 Contracting Officer (CO)

3.2.2 Contracting Officer’s Representative (COR)

3.3 USPTO OFFICES

3.3.1 Office of the Chief Information Officer (OCIO)

Office of the Chief Information Officer iii

3.3.2 Office of the Chief Information Security Officer (OCISO)

3.3.3 Emerging Technologies & Innovation Division (ET&I)

3.3.4 Office of Information Technology Transformation Office (ITTO)

3.3.4.1 Policy, Process and Performance Division (PPPD)

3.3.5 USPTO Office of Security

3.3.6 Office of Inspector General (OIG)

4 BASELINE 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)

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 PROGRAM MANAGEMENT (PM)

4.14 PERSONNEL SECURITY (PS)

4.15 PII PROCESSING AND TRANSPARENCY (PT)

4.16 RISK ASSESSMENT (RA)

4.17 SYSTEM AND SERVICES ACQUISITION (SA)

4.18 SYSTEM AND COMMUNICATIONS PROTECTION (SC)

4.19 SYSTEM AND INFORMATION INTEGRITY (SI)

4.20 SUPPLY CHAIN RISK MANAGEMENT (SR)

5 FEDRAMP CONTROLS AND HVA OVERLAY

5.1 FEDRAMP BASELINES

5.2 FEDRAMP MODERATE SECURITY CONTROLS

5.3 HVA OVERLAY WITH SPECIFIC HVA CONTROL REQUIREMENTS

Office of the Chief Information Officer 1

1 Introduction

The Federal Information Security Modernization Act (FISMA)1 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) Information Technology (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 Systems2, 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 § 35573. This handbook describes how the United States Patent and Trademark Office

(USPTO) shall 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 FISMA. It also encompasses minimum security controls as required by the FIPS

200, Minimum Security Requirements for Federal Information and Information Systems; and defined by the current NIST Special Publication (SP) 800-53 Revision 5, 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 systems, subsystems, or data processed, transmitted, and/or stored on USPTO information systems and/or subsystems; and to contractor employees providing services to the USPTO who use USPTO information systems, 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, 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 information, classified or agency-sensitive information and PII. Furthermore, all USPTO information, applications, systems, networks, and IT infrastructure and resources must be protected from loss, misuse, and unauthorized modification, disclosure, or access.

1 Federal Information Security Modernization Act

2 NIST FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems

3 44 USC Ch. 35 – Coordination of Federal Information Policy https://www.congress.gov/bill/113th-congress/senate-bill/2521 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf https://uscode.house.gov/view.xhtml?path=/prelim@title44/chapter35&edition=prelim

Office of the Chief Information Officer 2

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 carry out the

USPTO mission, whether 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.

For clarification, review the definition of USPTO Information System in the Glossary.

1.4 Update and Review

This Handbook shall be reviewed, at minimum on an annual basis and updated as needed. Handbooks may be reviewed more frequently as necessary (e.g., due to new Federal or USPTO mandates updates and changes).

1.5 Authority

This Handbook is issued under the authority of the USPTO Chief Information Security Officer (CISO). The most critical Federal laws, regulations, Executive Orders, policies, standards, and directives followed are indicated below. A specific list of references can be found in Appendix C.

• 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 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

• Department of Commerce Enterprise Cybersecurity Policy (ECP)

1.6 Compliance

Compliance with this Handbook is mandatory. It is USPTO policy that personnel and information system owners/ product owners abide by or exceed the requirements outlined in this Handbook and the associated procedures for each NIST SP 800-53 Rev. 5 family of controls. The CISO shall periodically assess USPTO’s adherence with this Handbook through various oversight and compliance measures.

In cases where an information system 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/Product Owner, and submitted to the Chief Information Officer (CIO) via the CISO. The Risk Acceptance process is officially documented in the USPTO IT Policy on Security Risk Acceptance, OCIO-POL-35, and further outlined in Section

2 of this Handbook.

1.7 USPTO IT Security Program Documentation

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

Office of the Chief Information Officer 3

• 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 – Baseline Security Controls: Contain a complete list of security controls with USPTO specific criteria;

• Section 5 – FedRAMP controls and High Value Asset (HVA) Overlay.

The following USPTO Office of the Chief Information Officer (OCIO) policies and procedures have been grouped into the associated NIST family-based set of procedures:

• Access Control (AC) Access Rights o OCIO-POL-12: Password Protected Inactivity Timeout o OCIO-POL-15: Remote Access o OCIO-POL-48: IT Separation of Duties o OCIO-POL-41: User Account Deactivation o OCIO: POL-34: Mobile Device Management o OCIO-PRC-20: Access Control Procedures

• Audit and Accountability (AU) Procedures o OCIO-POL-20: Audit, Logging, and Monitoring o OCIO-PRC-28: Audit and Accountability Procedures

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

• 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, File Sharing and Proxy or Identity Masking o OCIO-POL-52: Configuration Management Security Controls Policy

• Contingency Planning (CP) Procedures o OCIO-PRC-22: Contingency Planning 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: Enterprise Operations Command Center o OCIO-POL-17: Breach Notification

Office of the Chief Information Officer 4 o Incident Response Control Family Procedures o OCIO-PRC-33: USPTO Incident Response Plan

• Maintenance (MA) Procedures o OCIO-PRC-18: USPTO Maintenance Procedures

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

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

• Physical and Environmental Protection (PE) Procedures o OCIO-POL-6: Information Security Foreign Travel o OCIO-PRC-6: Physical and Environmental Protection Procedures

• 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 o OCIO-PRC-23: Security Planning Procedures

• Program Management (PM) Procedures o OCIO-POL-XX: Program Management Security Control Policy (In Process: Q4 FY25) o OCIO-PRC-XX: Program Management Procedures (In Process: Q4 FY25)

• Risk Assessment (RA) Procedures o OCIO-POL-35: IT Policy on Security Risk Acceptance o OCIO-PRC-24: Risk Assessment Procedures

• Security Assessment and Authorization (CA) Procedures o OCIO-PRC-003: Information Security Continuous Monitoring Strategy

• System and Services Acquisition (SA) Procedures o OCIO-POL-29: Vendor Performance Information Policy o OCIO-POL-39: IT Desktop Hardware Acquisition Management o OCIO-PRC-27: System and Service Acquisition Procedures

• System and Information Integrity (SI) Procedures o OCIO-POL-16: Endpoint Detection Response

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

Office of the Chief Information Officer 5 o OCIO-PRC-25: System and Communication Protection Procedures

• Supply Chain Risk Management (SR) Procedures o OCIO-POL-XX: Supply Chain Risk Management Policy (In Process: Q4 FY25) o OCIO-PRC-XX: Supply Chain Risk Management Procedures (In Process: Q4 FY25)

For information about these OCIO Policies, visit the OCIO Policies and Process Library intranet site:

Policies & Processes (sharepoint.com)

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

https://usptogov.sharepoint.com/sites/a142efd3/SitePages/Policies-Processes.aspx

Office of the Chief Information Officer 6

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 FISMA.

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 the current NIST

SP 800-53, based on the system’s impact level, and tailor, supplement, and implement the baseline according to

NIST 800-53A. The USPTO shall use current NIST SP 800-53A, Revision 5, 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 2, Risk Management Framework for Information Systems and Organizations: A System Life

Cycle Approach for Security and Privacy. 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 upon final approval and issuance by the CIO; all previous versions of this document are obsolete. System Owners are required to comply with this Handbook within 120 days of its effective date. Noncompliance with this Handbook beyond the specified timeframe shall be managed through the creation of Plan of Action and Milestones (POA&Ms).

The USPTO IT Security Handbook shall be reviewed at least annually or more often if needed and incorporate updates as necessary including new federal requirements. The USPTO Cybersecurity Privacy, Authorizations and Engagement Division shall incorporate the updates into this Handbook and the revision shall be reviewed by, and meet the concurrence of USPTO stakeholders before presentation for signature. The USPTO IT Security

Handbook and shall be reviewed and approved through the CISO, by the USPTO CIO.

2.2 Risk Acceptance

The USPTO Authorizing Official(s) (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/AO and Co-

AO, through the CISO, as appropriate based on the specific system requesting risk acceptance. 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&M Module within the Cyber Security Assessment and

Management (CSAM) application to track and manage progress towards compliance.

A risk acceptance should only be sought if one or more of the following criteria are met:

• The implementation of the control adversely impacts operations and impairs the Agency’s/information system’s ability to meet its mission and objectives

• The technology does not currently exist or is not feasible to provide an effective solution to satisfy the control requirements

• The cost of implementing the control outweighs the benefits as a result of a cost-benefit analysis

Product Teams may not utilize a risk acceptance for outstanding risks which would result in USPTO or

Department of Commerce’s (DOC) non-compliance with a legal requirement or an independent audit finding

(i.e., Office of Inspector General (OIG), the Government Accountability Office (GAO), and Cybersecurity and

Infrastructure Security Agency (CISA)).

Product Teams must review risk acceptances annually to determine applicability and address changes to the evolving information system’s environment. The expiration date must not extend beyond the expiration date

Office of the Chief Information Officer 7 of the information system’s Authorization to Operate (ATO). At a minimum, risk acceptance memos require formal documentation of the following information:

• Reference to the policy statement, enhancement, and excerpt of the description

• Compensating security or privacy controls implemented to mitigate the deficiency or vulnerability including the source of the weakness

• Risk level of deficiency or vulnerability from risk assessment

• Potential impact on information and IT system if exploitation of weakness occurs

• Comprehensive rationale and justification for risk acceptance

• Mitigation strategy describing actions or decisions that would change the risks and weaknesses identified, such as technology refresh, analysis of alternatives, modernization initiatives, or resource allocation

• Date of expiration for the request4

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 memo shall be drafted by the Product Team (SO, Information System Security Officer

(ISSO), Product Technical Lead (PTL), etc.).

• Risk Acceptance memo shall be addressed from the System Owner to the CIO/Authorizing Official (AO) and if necessary, the Co-Authorizing Official (Co-AO).

• Risk acceptance requests shall justify and describe the vulnerability or control(s) that cannot be fully implemented and the compensating controls that are in-place;

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

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

• Risk Acceptance requests shall be submitted to the CIO, via the CISO.

• 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.

• 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 legal action in accordance with the Office of Human Resources (OHR) Discipline and Penalties Policy. Perceived threats to system integrity, confidentiality, or availability shall result in suspension of system access as necessary to contain the perceived threat.

4 Department of Commerce - Security and Privacy Assessment & Authorization Handbook v. 1.0 March 2023 https://ptoweb.uspto.gov/ptointranet/ohr/policies_and_procedures/policies/discipline_penalties.htm

Office of the Chief Information Officer 8

An offense that is in violation of local, state, or Federal laws shall 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 Representative (COR) has contract oversight security responsibility and shall ensure that contractor-related security requirements are followed throughout the contract life-cycle.

2.4 USPTO Generative Artificial Intelligence (AI)

Pursuant to existing agency and Department5 policies, (Rules of the Road) the agency is prohibiting the use of

Generative AI tools on USPTO IT systems for any purpose that is not approved by the agency, and on any personal

(BYOD/UFE) and contractor IT equipment for USPTO business purposes. This includes sending business-related

USPTO information to Generative AI programs and using the output from Generative AI in agency-related business. This does not pertain to the use of Generative AI on solely personally owned devices for personal, non-agency related business or information.

Generative AI tools are defined as software tools that can programmatically generate novel content. This includes, but is not limited to text, images, and video. Some examples include: GPT, ChatGPT, Bing Chat, Bard, Cohere, Claude, Character.AI, Jasper, Stable Diffusion, DALL-E, Midjourney, and DeepSeek.

Users may continue to use the agency’s own approved AI tools, such as the AI capabilities in PE2E Search and

Microsoft Office Suite, for all authorized use cases. Using non-USPTO approved Generative AI tools for any official business violates current policy in our Rules of the Road. All staff must comply with this policy, including rules on the use of authorized software for official business. OCIO has blocked its use in the workplace effective immediately. Please reach out to GenerativeAIQuestions@uspto.gov with questions you have.

5 DOC OCIO Memorandum Prohibiting use of DeepSeek https://usptogov.sharepoint.com/:b:/r/sites/a142efd3/Documents/OCIO-POL-36%20-%20Rules%20of%20the%20Road%20(USPTO).pdf?csf=1&web=1&e=8frddm https://usptogov.sharepoint.com/:b:/r/sites/a142efd3/Documents/OCIO-POL-36%20-%20Rules%20of%20the%20Road%20(USPTO).pdf?csf=1&web=1&e=8frddm mailto:GenerativeAIQuestions@uspto.gov?subject=Generative%20AI%20Questions https://connection.commerce.gov/sites/default/files/media/files/2025/cio_memorandum-prohibiting_the_use_of_deepseek_ic_final.pdf

Office of the Chief Information Officer 9

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 Roles and Responsibilities

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

3.1.1 USPTO Chief Information Officer (CIO)/Authorizing Official (AO)

Within the USPTO, the role of the AO is generally assigned to the CIO. The CIO manages USPTO’s 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 Chief Information Security Officer (CISO) to implement the IT Security Program within USPTO as required by FISMA.

• 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 and Privacy Plans (SSPPs).

• 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 information systems/subsystems and if information systems/subsystems shall adequately protect sensitive USPTO information.

• Approve SSPPs.

• 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 shall be granted when all 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.

Office of the Chief Information Officer 10 o Authorization To Operate (ATO) with Conditions – If the Authorizing Official, after reviewing deems that there are still risks present in the organizational operational assets that need to be remediated, then an ATO with conditions can be granted to allow the system to complete those actions. This type of authorization shall be given only when a system needs to be put in production to support continuity of organizational mission and business requirements. The system shall be authorized to operate for a specified time period in accordance with the terms and conditions established by the authorizing officials. This limited authorization shall be granted when all the following apply:

• Vulnerability scans have been performed on the system and there are no major high-risk vulnerabilities discovered. Corrective actions (POA&Ms) are identified for any other vulnerabilities discovered in accordance with the USPTO Vulnerability Management Policy.

• Core 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 Common Control Authorization – A common control authorization is like an authorization to operate for systems. If the authorizing official, after reviewing the authorization package submitted by the common control provider, determines that the risk to organizational operations and assets, individuals, other organizations, and the Nation is acceptable, a common control authorization is issued. Common controls are authorized for a specific time period in accordance with the terms and conditions established by the authorizing official and the organization. An authorization termination date is established by the authorizing official as a condition of the initial common control authorization. The termination date can be adjusted at any time to reflect the level of concern by the authorizing official regarding the security and privacy posture of the common controls that are available for inheritance. If the controls are under ongoing authorization, a time-driven authorization frequency is specified. Within any authorization type, an adverse event could trigger the need to review the common control authorization. Common controls that are implemented in a system do not require a separate common control authorization because the controls receive an authorization to operate as part of the system authorization to operate.6 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 risks present in the organizational operations and/or assets, that need to be remediated, is not acceptable, then an authorization cannot be granted. The system may not be placed into operation until at least an ATO with Conditions is granted. Or when the risk is no longer acceptable (e.g., when there are deficiencies in controls or when there is a violation of policy and/or terms and conditions), then in some cases, the authorization decision is rescinded. For previously authorized systems in operation, all activity is halted if a denial of authorization is issued.

• 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 USPTO Computer Incident Response Team (CIRT) is staffed, trained, and maintained in a state of readiness.

6 NIST SP 800-37, Rev 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle

Approach for Security and Privacy – Appendix F: Authorization Decisions

Office of the Chief Information Officer 11

• 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.

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

3.1.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 (CAO), Chief Financial Officer (CFO), Equal Employment Opportunity and

Diversity (EEOD), etc. The Co-AOs roles are documented in the respective system SSPP. The Co-AO approves system security requirements including SSPPs, ATO letters, etc.

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.

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

3.1.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 regarding the planning and resourcing of the security authorization process, approval of the

SSPP, approval and monitoring the implementation of plans of action and milestones, and the assessment and/or determination of risk. The designated representative may also be called upon to prepare the final authorization package, obtain the authorizing official’s signature on the authorization decision document, and transmit the authorization package to appropriate organizational officials. The only activity that cannot be delegated to the designated representative by the authorizing official is the authorization decision and signing of the associated authorization decision document (i.e., the acceptance of risk to organizational operations and assets, individuals, other organizations, and the Nation).

3.1.4 USPTO Chief Information Security Officer (CISO)

At the USPTO, the CISO has assessing responsibilities. The CISO is the agency official responsible for: (i) carrying out the security executive role under FISMA; (ii) possessing professional qualifications, including training and experience, required to administer the information security program functions; (iii) having information security duties as that official’s primary duty; and, (iv) heading an office with the mission and resources to assist in ensuring agency compliance with FISMA.

The CISO is responsible for determining the level of effort and resources required for information systems (IS) and information subsystems (ISS) security authorization; reviewing the IS/ISS security categorization; and, performing analysis and accepting the IS/ISS SSPP. The CISO (or supporting staff member) may also serve as the AODR responsible for providing authorization recommendations to the AO. The CISO serves as the CIO’s primary liaison to the Agency’s AOs, SOs, and ISSO. Additionally, the CISO has the following responsibilities for IT Security:

Office of the Chief Information Officer 12

• Identify resource requirements, including funds, personnel and contractors, needed to manage the USPTO

IT Security Program.

• Develop and maintain USPTO IT security policy, procedures, standards, and guidance consistent with

Federal requirements and provide protection for the electronic information and information systems that support the operations and assets of the agency including those provided or managed by another agency or contractor.

• Develop, document, and implement subordinate plans for providing adequate security for networks, facilities, and systems or groups of information systems.

• Coordinate matters of physical security for IT resources with the USPTO Security Office.

• Ensure that all systems have current and effective IT security plans that accurately reflect system status.

• Ensure that appropriate security features are implemented in new systems and that they at least meet the minimum-security requirements defined in this Handbook.

• Ensure the security of an information system throughout its life cycle and that IT security is integrated in the USPTO strategic IT planning and enterprise architecture (EA) efforts.

• Ensure that periodic assessments are performed of the risk and magnitude of harm that could result from unauthorized access, use, disclosure, or disruption of information and information systems that support the operations and assets of the Agency.

• Ensure that an AO, SO, and ISSO have been appointed for each information subsystems within the USPTO and maintain up-to-date records of these assignments.

• Ensure that SSPPs are properly prepared for all IT systems owned and operated by the USPTO.

• Coordinate the development, review, and acceptance of SSPPs with the SO, ISSO, and the AO.

• Review SSPPs, as submitted, making appropriate written comments that shall be sent to the originator for corrective action.

• Ensure ISSO review and update all SSPPs, at least annually, and incorporate changes or completed milestone actions.

• Ensure that periodic Security Test and Assessment (ST&A) plans are developed, documented, and implemented, no less than annually, to assess the effectiveness of information security policies, procedures, and practices.

• Coordinate the identification, implementation and assessment of common security controls.

• Establish a process to track remedial actions to mitigate risks in accordance with POA&M to address any deficiencies in the information security policies, procedures and practices of the Agency.

• Review proposed system changes and act as approval authority for changes that impact system security.

• Lead development, implementation and enforcement of USPTO IT Security policies and procedures.

• Manage and oversee internal and external reviews and inspections to ensure compliance with established policies and procedures.

• Serve as the principal Point of Contact (POC) on IT security activities within USPTO.

• Ensure appropriate IT Security Awareness Training is provided.

• Advise the SO of security features and procedures for systems.

• Ensure the OCIO CM process and DevSecOps Change Management policy and procedures are used to maintain IT Security documentation.

Office of the Chief Information Officer 13

• Identify and recommend security and privacy controls improvements to management.

• Ensure appropriate incident response capabilities.

• Interface and coordinate with the OIG on IT Security reviews and issues.

• Assign each USPTO system a unique identification number that shall identify the Agency and the specific system.

• Ensure that IT systems are categorized, in conjunction with other staff.

• Maintain a tracking system for implementation of the required controls and authorization status for all

USPTO systems.

• Ensure that all systems have effective, quality security documentation in place, including:

o Security assessment reports (SAR) o Current and effective IT security plans that accurately reflect system status, or continuous monitoring o Current and tested CPs o Current security authorization (ATO)

• Maintain the major application and general support system inventory.

• Provide information to systems administrators and others concerning risks and potential risks to systems.

• Notify SOs and ISSO of user infractions identified during routine compliance assessments and any required actions.

• Advise the CIO and unit area heads of technological IT security advances that can be used on an agency-wide scale.

• Report to the CIO and external entities such as OMB, GAO, and Congress, on IT Security Program status.

• Ensure that all users and managers have an effective way to provide feedback on the quality and quantity of IT Security awareness and training material and its presentation.

• Ensure that IT Security awareness and training material is reviewed annually and updated when necessary.

3.1.5 USPTO Risk Executive Function

The risk executive (function) is an individual or group that helps to ensure that: (i) risk-related considerations for individual information systems, to include authorization decisions, are viewed from an organization-wide perspective with regard to the overall strategic goals and objectives of the USPTO in carrying out its core missions and business functions; and (ii) managing information system-related security risks is consistent across the USPTO, reflects organizational risk tolerance, and is considered along with other types of risks in order to ensure mission/business success. The risk executive (function) coordinates with the senior leadership of USPTO to:

• Provide a comprehensive, organization-wide, holistic approach for addressing risk—an approach that provides a greater understanding of the integrated operations of USPTO.

• Develop a risk management strategy for USPTO providing a strategic view of information security-related risks with regard to USPTO as a whole.

• Facilitate the sharing of risk-related information among authorizing officials and other senior leaders within the USPTO.

• Provide oversight for all risk management-related activities across USPTO (e.g., security categorizations) to help ensure consistent and effective risk acceptance decisions.

• Ensure that authorization decisions consider all factors necessary for mission and business success.

Office of the Chief Information Officer 14

• Provide an USPTO-wide forum to consider all sources of risk (including aggregated risk) to organizational operations and assets, individuals, other organizations, and the Nation.

• Promote cooperation and collaboration among authorizing officials to include authorization actions requiring shared responsibility.

• Ensure that the shared responsibility for supporting organizational mission/business functions using external providers of information and services receives the needed visibility and is elevated to the appropriate decision-making authorities.

• Identify the USPTO risk posture based on the aggregated risk to information from the operation and use of the information systems for which USPTO is responsible.

The risk executive function at the USPTO consists of USPTO Cybersecurity management personnel.

3.1.6 USPTO Security Authorization and Compliance Manager

The Security Authorization and Compliance Manager is responsible for managing the security authorization process for all information subsystems. The security authorization and compliance manager plays an essential role in security and is, ideally, intimately aware of functional system requirements. The security authorization and compliance manager builds the business case for the acquisition of appropriate security solutions that help ensure mission accomplishment in the face of real-world threats. Additionally, the security authorization and compliance manager has the following IT Security responsibilities:

• Possess the knowledge and skills to appropriately incorporate IT security throughout a system’s DevSecOps process to protect the business operations and information the system supports.

• Work with the SO, ISSO and CISO to meet shared IT security responsibilities.

• Ensure system development and operations staff is knowledgeable of the security authorization requirements and processes for their systems and are provided related training.

3.1.7 USPTO System Owner (SO)/Product Owner (PO)

The SO/Product Owner (PO) has responsibility for the Parent System (a grouping of multiple subsystems into

FISMA reportable system), while the role of managing individual systems within the parent system is typically assigned to the ISSO. The SO/PO has the following responsibilities for IT Security:

• The overall procurement, development, integration, modification, operation, maintenance and implementation of an information systems and subsystems.

• Ensuring that compliance with cybersecurity/information technology security requirements and the appropriate operational security posture of an information system are maintained throughout the system life cycle.

• Ensuring that system security requirements are incorporated in acquisition processes, to include resourcing requirements for system security.

• Ensuring that the planning and execution of all Risk Management Framework (RMF) activities are aligned and integrated with system acquisition and deployment planning processes.

• Designating, in writing, an ISSO for an information system (to include subsystems) to serve as the principal advisor to the SO on all security matters for that information system, to play an active role in developing and updating the SSPP, to ensure that changes to the system are managed and controlled, and to assess the security impact of those changes, and ensure that vulnerability management requirements are met.

• Ensuring that other system personnel are properly designated, monitored, and trained, including appointment in writing of an individual to serve as the TL, if appropriate.

• Determining and implementing an appropriate level of security commensurate with the system sensitivity level and FIPS 199 Categorization.

Office of the Chief Information Officer 15

• Reviewing the FIPS 199 Categorization of the information system annually and maintaining documentation of the review with the SSPP.

• Developing and maintaining SSPP documentation and ensuring that the system is deployed and operated according to the agreed-upon security requirements.

• Assisting in the identification, implementation, and assessment of common security controls specific to the information system.

• Conducting Continuous Monitoring activities including configuration management, security and privacy control self-assessments, and POA&M reviews.

• Reviewing SSPPs annually for accuracy and documenting any changes/updates based upon the outcome of

Continuous Monitoring activities, as well as any changes to the security controls employed within or inherited by the information system, and documenting and maintaining results of the of annual SSPP reviews as an artifact with the SSPP.

• Informing key agency officials of the need to conduct a system security and privacy control assessment and authorization of the information system, ensuring that appropriate resources are available for the effort.

• Providing the necessary system-related documentation to Security Control Assessors (SCA)s.

• Ensuring that system weaknesses are remediated within time frames established in USPTO policies and procedures.

• Ensuring the development, implementation, and completion of POA&Ms for system weaknesses that cannot be remediated within required time frames.

• Assembling and submitting the SAP for AO review and adjudication.

• Notifying the AO of changes that might affect information system authorization.

• In coordination with the ISSO, creating and maintaining the Information System Contingency Plan (ISCP) for the information system.

• Conducting and documenting annual ISCP Tests and maintaining copies of ISCP documentation with the

SSPP.

• In coordination with the ISSO, creating and maintaining the Incident Response Plan (IRP) for the information system.

• Develop, document, sign, and implement a configuration management plan. The plan must be reviewed annually and updated as needed.

• Attending DOC Change Review Board (CRB) meetings to provide responses to security and privacy questions for assigned systems (that either have or require a Privacy Impact Assessment (PIA)).

• Ensuring that all system decommissioning, retirement, and disposition activities are completed.

• Reviewing and approving all requests for privileged accounts on the information system and ensuring that system users and support personnel receive the requisite role-based security training and complete an

Administrative Rights Access Form (ARAF) prior to being granted privileged access.

• Ensuring the creation, security, and maintenance of an inventory of all privileged accounts for the information system.

• Reviewing the inventory of existing privileged accounts and the business need that warrants their continued existence at least twice a year, and authorizing them for continued use.

• Ensuring that all personnel managing, administering, or having access to the information system have read, understand, and agree to abide by the USPTO Rules of Behavior before authorizing access to information and the information system.

• Working with the USPTO CIO and CISO to meet shared IT security responsibilities.

Office of the Chief Information Officer 16

• Coordinating with the Office of the Chief Information Security Officer (OCISO) to provide support for activities (i.e., vulnerability scanning, security and privacy assessment and authorization activities, POA&M closures, continuous monitoring, etc.) necessary to meet FISMA compliance requirements.

USPTO addresses the security requirements for SO through assignment of Federal employees from the business unit coupled with full time contractor Security Subject Matter Expert support to meet FISMA compliance requirements. This approach ensures business representation as well as expert security support in meeting FISMA requirements.

3.1.8 Information Owner/Steward

The information owner/steward is an organizational official with statutory, management, or operational authority for specified information and the responsibility for establishing the policies and procedures governing its generation, collection, processing, dissemination, and disposal. In information-sharing environments, the information owner/steward is responsible for establishing the rules for appropriate use and protection of the subject information (e.g., rules of behavior) and retains that responsibility even when the information is shared with or provided to other organizations. The owner/steward of the information processed, stored, or transmitted by an information system may or may not be the same as the system owner.