Attachment 03- Application Security Baseline Requirements.pdf

06/01/2023 Version 2.2

RD Cybersecurity

RD Application Security Baseline Requirements

Rural Development Business Center

USDA RD

WASHINGTON, D.C.

RD Application Security Baseline Requirements

Office of the Chief Information Officer Page 2 of 58

Revision History Version

Implemented By Revision Date Approved By Approval Date Description of Change

1.0 RD Cybersecurity 02/12/2019 Original Draft based on NIST 800-53 Rev 4 and Fed RAMP

2.1 RD Cybersecurity 03/12/2019 Updates for RD

2.2 RD Cybersecurity 06/01/2023 Updates to Appendix F-References

Office of the Chief Information Officer Page 3 of 58

Table of Contents

1. INTRODUCTION

2. AUTHORITY

3. SCOPE

4. TARGET AUDIENCE

5. ASSUMPTIONS

6. BACKGROUND

6.1. Cloud Concepts

7. APPLICABILITY

8. SECURITY CONTROL ORGANIZATION AND STRUCTURE

9. HOW TO USE THE APPENDICES

APPENDIX A: GLOSSARY OF TERMS AND ACRONYMS

A1. Acronyms A2. Terms and Definitions

APPENDIX B: BASELINE PROGRAMMATIC SECURITY REQUIREMENTS FOR PROJECT TEAM

(MODERATE FIPS-199 CLASSIFICATION)

APPENDIX C: BASELINE TECHNICAL REQUIREMENTS FOR APPLICATION WITH FIPS-199

MODERATE CLASSIFICATION)

APPENDIX D: BASELINE PROGRAMMATIC SECURITY REQUIREMENTS FOR PROJECT TEAM

(LOW FIPS-199 CLASSIFICATION)

APPENDIX E: BASELINE TECHNICAL CONTROLS FOR APPLICATION WITH FIPS-199 LOW

CLASSIFICATION

APPENDIX F: REFERENCES

Office of the Chief Information Officer Page 4 of 58

Table of Tables

Table 1: Security Controls Table 2: Residual Security Controls for Applications

Table of Figures

Figure 1: Example Services Available to a Cloud Consumer Figure 2: Scope of Controls Between Cloud Provider and Consumer

Office of the Chief Information Officer Page 5 of 58

1. Introduction All Federal information systems must comply with the Federal Information Security Management Act (FISMA) of 2002. This law empowers the National Institute of Standards and Technology (NIST) to develop mandatory security controls and reporting requirements.

NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations, provides a more holistic approach to information security and risk management by providing organizations with the breadth and depth of security controls necessary to fundamentally strengthen their information systems and the environments in which those systems operate. This contributes to systems that are more resilient in the face of cyberattacks and other threats.

The Federal Risk and Authorization Management Program (Fed RAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. For Cloud based applications, Fed RAMP mandates a set of security controls in addition to those mandated by NIST SP 800-53 Revision 4.

Compliance with these requirements is not only mandated by Federal law, but also by the Office of Management and Budget (OMB) and United States Department of Agriculture (USDA) policies. This Baseline Security Requirement (BSR) document is based on NIST SP 800-53 Revision 4 and Fed RAMP.

This BSR document is intended to provide RD application owners, project managers, and developers the core list of security requirements needed to:

• Enhance the security posture of their application(s),

• Meet statutory compliance requirements,

• Provide clear and consistent guidance on applicable security control requirements, and

• Provide a standardized approach to securing applications.

This document is intended to assist the USDA-Natural Resources Conservation Service (RD) application teams in determining the requisite security controls to build security mechanisms into the application.

Therefore, by integrating these security control requirements from the BSR into the Requirements Traceability Matrix (RTM) of an application ensures that the application team would benefit from reduced security risk, increased software assurance, and a reduced level of effort for Accreditation. In our SDLC process, the security mechanisms and controls are assessed by security architectural & design review, security code review, and penetration testing, and through the RD Security Assessment and Authorization (A&A) process.

2. Authority This document will be implemented and enforced by RD IT Security under the authority, direction, and control of the RD Chief Information Officer (CIO). The RD Security team will develop, maintain and ensure

Office of the Chief Information Officer Page 6 of 58 that the BSR is consistent with USDA cybersecurity policies, standards, architectures, security controls and validation procedures.

3. Scope The Scope of this document includes NIST controls that can be implemented as security mechanisms within the application or by the project team. Any controls that might be shared by the application and its underlying infrastructure will also be included in this document. All controls that will be implemented at an organization level will be exempt from this document.

For non-cloud applications, all NIST controls that apply to anything above the OS (Operating System) layer are in scope

For Cloud applications, all NIST and Fed Ramp controls that apply to anything above the Platform as a Service (PAAS) layer are in scope.

4. Target Audience This BSR document is intended to provide RD application owners, project managers, and developers an understanding and agree upon the security requirements that will be implemented by the project team and application.

5. Assumptions This BSR operates on the following assumptions:

• All RD applications have a Federal Information Processing Standard (FIPS) 199 classification level of either Low or Moderate. Security Requirements for all non-cloud based RD applications will be evaluated against the NITC GSS Inheritance Matrix.

• Security Requirements for all cloud-based RD application be evaluated against the System Security Plan of the Salesforce Cloud ATO package.

6. Background The current approved RD Baseline Security Requirements document, version 1.10, is based on NIST 800- 53 Rev3.

In the past, the request for the ATO to operate in RD production environment would come to the RD Security team after the application development has been completed. This request for ATO was processed by the RD Security team and identified security gaps within the application, causing bolting in security at that point causing delays in obtaining the ATO and in effect delays the application delivery. The lack of comprehensive and standards-based set of security requirements to the application development

Office of the Chief Information Officer Page 7 of 58 project teams caused the delay in obtaining an ATO from the RD Security team at a later stage The RD BSR version 1.10 was created to address the need for standards-based security requirements that would be applicable to all RD web applications hosted in USDA. The BSR 1.10 was written into the procurement contracts to ensure that security requirements were considered upfront in the acquisition and delivery of the application. The BSR subsequently has been updated to address the ever-evolving needs of applications technologies, new hosting environments, regulations, and security threat landscape.

This BSR document supersedes all previous versions and has been updated to reflect the evolving technology, regulations, and threat space. Key Terms and Concepts

This section outlines several key concepts, terms, and supporting processes, providing a primer for the remainder of this document.

6.1. Cloud Concepts

Cloud computing enables the Department to consolidate infrastructure, leverage commodity IT functions, and eliminate functional redundancies while improving continuity of operations. The overall success of these initiatives depends upon well-executed security requirements that are defined and understood by all components of USDA-RD. Consistent implementation and operation of these requirements assures mission execution, provides sensitive data protection, increases mission effectiveness, and ultimately results in the outcomes and operational efficiencies that the USDA-RD seeks.

The NIST SP 800-145, NIST Definition of Cloud Computing, defines cloud computing, five essential characteristics, three service models, and four deployment models. The RD Baseline Security Requirements adheres to these NIST definitions to characterize and standardize the discussion of Cloud Computing.

Cloud service models include Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The components offered in IaaS form the basis for PaaS, while the components offered in PaaS form the basis of SaaS. Cloud deployment models include Public, Private, Community, and Hybrid.

Office of the Chief Information Officer Page 8 of 58

Figure 1: Example Services Available to a Cloud Consumer

The consumers of SaaS can be organizations that provide their members with access to software applications, end users who directly use software applications, or software application administrators who configure applications for end users. SaaS consumers can be billed based on the number of end users, the time of use, the network bandwidth consumed, and the amount of data stored or duration of stored data.

Cloud consumers of PaaS can employ the tools and execution resources provided by cloud providers to develop, test, deploy, and manage the applications hosted in a cloud environment. PaaS consumers can be application developers who design and implement application software; application testers who run and test applications in cloud-based environments; application deployers who publish applications into the cloud; and application administrators who configure and monitor application performance on a platform. PaaS consumers can be billed according to processing, database storage, and network resources consumed by the PaaS application, and the duration of the platform usage.

Consumers of IaaS have access to virtual computers, network-accessible storage, network infrastructure components, and other fundamental computing resources on which they can deploy and run arbitrary software. The consumers of IaaS can be system developers, system administrators, and IT managers who are interested in creating, installing, managing, and monitoring services for IT infrastructure operations.

IaaS consumers are provisioned with the capabilities to access these computing resources and are billed according to the amount or duration of the resources consumed, such as Central Processing Unit (CPU)

Office of the Chief Information Officer Page 9 of 58 hours used by virtual computers, volume and duration of data stored, network bandwidth consumed, and number of Internet Protocol (IP) addresses used for certain intervals.

The Cloud Provider and Cloud Consumer share the responsibility for resources in a cloud system. As illustrated in Figure 2, different service models affect an organization’s control over the computational resources and thus what can be done in a cloud system. The figure shows these differences using a classic software stack notation comprised of the application, middleware, and Operating System (OS) layers. This analysis of delineation of controls over the application stack helps clarify the responsibilities of parties involved in managing the cloud application.

Figure 2: Scope of Controls between Cloud Provider and Consumer

• The application layer includes software applications targeted at end users or programs. The applications are used by SaaS consumers, or installed/managed/ maintained by PaaS consumers, IaaS consumers, and SaaS providers.

• The middleware layer provides software building blocks (e.g., libraries, database, and Java virtual machine) for developing application software in the cloud. The middleware is used by PaaS consumers, installed/managed/maintained by IaaS consumers or PaaS providers, and hidden from SaaS consumers.

• The OS layer includes operating system and drivers, and is hidden from SaaS consumers and PaaS consumers. An IaaS cloud allows one or multiple guest OSs to run virtualized on a single physical host. Generally, consumers have broad freedom to choose which OS to be hosted among all the OSs that could be supported by the cloud provider. The IaaS consumers should assume full responsibility for the guest OSs, while the IaaS provider controls the host OS.

7. Applicability The BSRs are applicable to all RD applications residing in both certified USDA non-cloud and USDA or Fed RAMP certified cloud environments.

Office of the Chief Information Officer Page 10 of 58

For a non-cloud application, the term “application” in this document encompasses anything above the OS, including the applications and all of their supporting components.

For a cloud application, the term “application” in this document includes all the application components that reside on top of a PaaS cloud.

8. Security Control Organization and Structure The security controls described in this document originated in NIST’s Special Publication 800-53 Revision 4 “Recommended Security Controls for Federal Information Systems and Organizations.” These controls have a well-defined organization and structure. For ease of use, these controls are organized into eighteen “families” based on common functionality and approach (see Table 1). For example, “Media Protection” and “Access Control” are two such control families.

Table 1: Security Controls Identifier Family Class

AC Access Control Technical AT Awareness and Training Operational

AU Audit and Accountability Technical CA Security Assessment and Authorization Management CM Configuration Management Operational CP Contingency Planning Operational IA Identification and Authentication Technical IR Incident Response Operational

MA Maintenance Operational MP Media Protection Operational PE Physical and Environmental Protection Operational PL Planning Management PS Personnel Security Operational RA Risk Assessment Management SA System and Services Acquisition Management SC System and Communications Protection Technical

SI System and Information Integrity Operational PM Program Management Management

These control families are further categorized into 3 classes based on how they apply within an organizational structure. These classes are:

1) Technical

2) Operational

3) Management

Office of the Chief Information Officer Page 11 of 58

Most of the controls identified in this document are Technical, with only some crossover into Operational and Management. The controls listed in the document are most restrictive between NIST 800-53 Rev 4 and Fed RAMP guidelines. Since most of the Operational and Management controls are handled by USDA and RD at an organizational level (e.g., Department level), the project team will benefit substantially by deploying their application within such an environment.

Since it is assumed that the applications/systems are hosted within either USDA or a previously accredited environment, the applications/systems will “inherit” many security controls from the hosting environment. This will substantially reduce the level of effort to ensure full compliance.

Table 2 below summarizes the residual security controls for which the application team is directly responsible. The rest of the controls are “inherited” from the host environment. The customized control requirements that are recorded in the RTM must be consistent with the SSP developed for the system.

The security mechanisms will be built based on the customized security requirements captured in the RTM. Therefore, the requirements in the RTM should be reflected in the SSP of the ATO package for testability of compliance.

Table 2: Residual Security Controls for Applications Identifier Family Class

AC Access Control Technical AU Audit and Accountability Technical CM Configuration Management Operational IA Identification and Authentication Technical SC System and Communications Protection Technical SI System and Information Integrity Operational

The application team is typically not responsible for maintaining the network, switches, hubs, and core system devices. Within USDA, these infrastructure systems have been assessed and authorized independently. As the application resides on /or within the infrastructure, it “inherit”’ the security controls that are in use by the host environment.

9. How to Use the Appendices While the controls listed in the Appendices are designed to be technical, and as such can be given directly to developers as stand-alone requirements, there are some controls which require oversight and input from the project team. These controls are called out within a separate Appendix for ease of use. These controls will typically require an organization specific process or requirements. For example:

SYSTEM AND INFORMATION INTEGRITY - (SI-2) Flaw Remediation “The project team shall test software updates related to flaw remediation for effectiveness and potential side effects on organizational information systems before installation.”

Office of the Chief Information Officer Page 12 of 58

The above control is an example of a programmatic process, which is different than a solely technical requirement.

Within the controls, however, there is some overlap between a control which is purely technical in nature, and controls which are program management or process based. These controls may require the use of manual and/or automated processes that are not specifically built into the system itself. It is still the responsibility of the system owner to ensure that these controls are properly implemented.

Appendix A of this document contains the glossary of terms and acronyms.

Appendices B and D contain the baseline programmatic security requirements for which the application project teams are responsible for application categorized as FIPS Moderate and Low systems respectively.

While the majority of the NIST 800-53 Rev 4 controls are “inherited,” there are still many which require unique and specific implementations.

Appendices C and E of this document contains the technical security controls required for applications which have been categorized as FIPS 199 Moderate and Low.

Appendices C and E are testable technical requirements intended to be shared with the architects, developers, and implementers in order to be implemented in the application. Appendices B and D are programmatic controls intended to be shared with the project team in order to be implemented as programmatic processes.

If a system has a FIPS-199 accreditation level of Moderate, owners will need to comply with the requirements listed in Appendices B and C, whereas if a system has been designated Low, owners will follow Appendix D and E.

Office of the Chief Information Officer Page 13 of 58

Appendix A: Glossary of Terms and Acronyms

A1. Acronyms

Acronyms Definitions

ATO Authority to Operate CSP Cloud Service Provider JAB Joint Authorization Board A&A Assessment and Authorization PA Provisional Authorization

A2. Terms and Definitions Application is a set of information systems that operate “above” the Operating System layer, such as an accounting program or a database.

• For a non-cloud application, the term application in the context of the security control requirements refers to application container and the application sitting on top of it.

• For a cloud application, the term application in the context of the security control requirements refers to application sitting on top of a PaaS.

Project team comprises of the Project Manager, Business Analysts, Application Architects. Developers, Testers, Configuration Managers, and Production Operations.

Authorization to Operate (ATO) is the formal written declaration by the Designated Approving Authority that the information system is operating as an acceptable level of risk. This approval is required for all federal information systems.

Accreditation Boundary includes all components of an information system to be accredited by an authorizing official and excludes separately accredited systems, to which the information system is connected.

Security Authorization is a process for implementing information security. It is a systematic procedure for evaluating, describing, testing and authorizing systems prior to or after a system is in operation. The SA process is used extensively in the U.S. Federal Government. NIST Special Publication 800-37, "Guide for Applying the Risk Management Framework to Federal Information Systems," transforms the traditional Assessment and Authorization (A&A) process into a six-step Risk management framework.

Designated Approving Authority is the official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. This term is synonymous with authorizing official, Office of the Chief Information Officer Page 14 of 58 designated accrediting authority, and delegated accrediting authority. This person must be a federal employee.

Federal Information System is an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency.

FIPS 199 FIPS Publication 199 addresses standards for categorizing information and information systems based on the risk and impact levels associated with the sensitivity of the information.

Hosting Environment refers to the set of infrastructures where the application resides. For example:

network routers, firewalls, servers and operating systems.

Low Classification is defined as when the loss of confidentiality, integrity, or availability could be expected to have little or no adverse effects on organizational operations, organizational assets, or individuals. This definition conforms to FIPS-199 standard.

Moderate Classification is defined as when the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. This definition conforms to FIPS-199 standard.

Office of the Chief Information Officer Page 15 of 58

Appendix B: Baseline Programmatic Security Requirements for Project Team (Moderate FIPS-199 Classification)

Control Name Control Derived Control Requirement

Applicable to non-cloud applications

Applicable to cloud (PaaS) based applications

Account Management

AC-2

a) The project team shall identify and select the following types of information system accounts to support organizational missions/business functions user, group, system, guest and temporary account types

Yes Yes

AC-2

c) The project team shall establish conditions for group and role membership that follow least privilege and need-to-know principles.

Yes Yes

AC-2

d) The project team shall specify authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account.

Yes Yes

Access Control AC-2(7) The project team shall take privileged access away when privileged role assignments are no longer appropriate.

NA Yes

Restrictions on use of shared Groups/ Accounts

AC-2(9)

The application shall only permit the use of shared/group accounts that meet specific conditions or circumstances under which information system accounts can be used, for example, by restricting usage to certain days of the week, time of day, or specific durations of time.

NA Yes

Shared Group Account Credential Termination

AC-2(10)

The application shall terminate shared/group account credentials when members leave the group.

NA Yes

Separation of Duties

AC-5

a) The project team shall document separation of duties of individuals

Example: A development team should not have access to production environment or security personnel administering access control

Yes Yes

Office of the Chief Information Officer Page 16 of 58 functions do not also administer audit functions.

b) The project team shall define the information system access authorizations to support separation of duties

Example: The project team defines different system roles to support different duties.

Yes Yes

Permitted Actions without Identification or Authentication

AC-14

a) The project team shall identify no actions that can be performed on the application without identification or authentication

The project team may allow a limited number of user actions without identification or authentication including, for example, when individuals access public websites or other publicly accessible federal information systems

Yes Yes

AC-14

b) The project team shall document and provide supporting rationale in the security plan for the information system, user actions not requiring identification or authentication

Yes Yes

Remote Access AC-17 (4)

a) The project team shall document the rationale for remote access in the security plan for the information system.

Yes Yes

b) The project team shall authorize the execution of privileged commands and access to security-relevant information via remote access only for maintenance, forensics, mission essential and/or other functions needed to achieve mission function.

Yes Yes

Access Control For Mobile Devices

AC-19

a) If required, the project team shall establish unique usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices as appropriate.

Yes Yes

Use of External Information Systems

AC-20

a) The project team shall establish unique terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to access the information system from external

Office of the Chief Information Officer Page 17 of 58 information systems. The terms and conditions need to be approved by RD Security.

b) The project team shall establish unique terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to process, store, or transmit organization-controlled information using external information systems. The terms and conditions need to be approved by RD Security.

Example: If a project team requires and interface between itself and another external agency, the project team will work with RD Security team to create the Interconnection Security Agreement (ISA).

Yes Yes

Use of External Information Systems

AC-20(1)

With approval of RD Security, a project team can permit authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization:

a) Verifies the implementation of required security controls on the external system as specified in the organization’s information security policy and security plan; or

b) Retains approved information system connection or processing agreements with the organizational entity hosting the external information system.

Yes Yes

Publicly Accessible Content

AC-22

a) The project team shall designate individuals authorized to post information onto a publicly accessible information system;

Yes Yes

b) The project team shall train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;

Yes Yes

c) The project team shall review the proposed content of information prior to posting

Office of the Chief Information Officer Page 18 of 58 onto the publicly accessible system to ensure that nonpublic information is not included;

d) The project team shall review the content on the publicly accessible system for nonpublic information at a minimum quarterly and removes such information, if discovered.

AUDIT AND ACCOUNTABILITY

Control Name Control Derived Control Requirement

Applicable to non-cloud applications

Applicable to cloud (PaaS) based applications

Audit Events

AU-2

a) The project team shall determine that the information system is capable of auditing the following events:

At a minimum: Successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events.

For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes

Yes Yes

AU-2(3)

The project team shall review and update the audited events at a minimum annually or upon a significant event.

Guidance: Annually or whenever changes in the threat environment are communicated to the service provider by the Authorizing Official.

Yes Yes

Audit Storage Capacity

AU-4

The project team shall allocate audit record storage capacity.

Yes Yes

Audit, Review, Analysis and Reporting

AU-6

a) The project team shall review and analyze information system audit records at a minimum weekly for indications of unusual or suspicious activity.

Office of the Chief Information Officer Page 19 of 58

b) The project team shall report suspicious findings to security administrators and/or, ISSOs, ISSPMs

Yes Yes

Synchronization With Authoritative Time Source

AU-8(1)

The Project Team shall ensure that OS service provider shall:

a) Compare the internal system clocks at a minimum daily with USDA or Agency authoritative time source (i.e. network time protocol-NTP server); and

b) Synchronize the internal system clocks to the authoritative time source when the time difference is greater 300 milliseconds.

Requirement: The service provider selects primary and secondary time servers used by the NIST Internet time service. The secondary server is selected from a different geographic region than the primary server.

Requirement: The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.

Yes No

Office of the Chief Information Officer Page 20 of 58

CONFIGURATION MANAGEMENT

Control Name Control Derived Control Requirement

Applicable to non-cloud applications

Applicable to cloud (PaaS) based applications

Baseline Configuration

CM-2

The project team shall develop, document, and maintain under configuration control, a current baseline configuration of the system.

Yes Yes

CM-2 (1)

a) The project team shall review and update the baseline configuration of the system at a minimum annually.

Yes Yes

b) The project team shall review and update the baseline configuration of the system when required due to changes to the information system that affect the baseline; and

Yes Yes

c) The project team shall review and update the baseline configuration of the system as an integral part of information system component installations and upgrades.

Yes Yes

CM-2 (2)

The project team shall employ automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system.

Automated mechanisms that help organizations maintain consistent baseline configurations for information systems include, for example, hardware and software inventory tools, configuration management tools, and network management tools.

NA Yes

CM-2 (3)

The project team shall retain at least 3 most recent previous versions of rollbacks that ensures reconstitution of prior version(s) of the system to support rollback.

Retaining previous versions of baseline configurations to support rollback may include, Office of the Chief Information Officer Page 21 of 58 for example, hardware, software, firmware, configuration files, and configuration records.

Configuration Change Control

CM-3

a) The project team shall determine the types of changes to the system that are configuration-controlled

Requirement: The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the Authorizing Official.

Yes Yes

b) The project team shall propose configuration-controlled changes to the system and Change Control Board (CCB) approves or disapproves such changes with explicit consideration for security impact analyses;

Yes Yes

c) The project team shall document configuration change decisions associated with the system.

Yes Yes

d) The project team shall implement approved configuration-controlled changes to the system

Yes Yes

f) The project team shall audit and review activities associated with configuration-controlled changes to the system; and

Yes Yes

g) The CCB shall coordinate and provide oversight for configuration change control activities through the organization/agency CCB that convenes periodically as defined in the organization/agency CCB charter and or when a change requires CCB approval.

Yes Yes

CM-3 (2)

The project team shall test, validate, and document changes to the system before implementing the changes on the operational system.

Yes Yes

Security Impact Analysis

CM-4

The project team shall analyze changes to the system to determine potential security impacts prior to change implementation

Office of the Chief Information Officer Page 22 of 58

Access Restrictions For Change

CM-5

The project team shall define, document, approve, and enforce physical and logical access restrictions associated with changes to the information system.

Yes Yes

CM-5(3)

The project team shall prevent the installation of software and firmware version updates, patches, service packs, device drivers, and basic input output system (BIOS) without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.

FedRAMP Guidance: If digital signatures/certificates are unavailable, alternative cryptographic integrity checks (hashes, self-signed certs, etc.) can be utilized.

NA Yes

CM-5(5)

a) The project team shall limit privileges to change information system components and system-related information within a production or operational environment;

and

NA Yes

b) The post deployment project team shall review and reevaluate privileges at least quarterly

Example: Role and privilege membership as maintained in RD authorization management systems is reviewed periodically by the post deployment project team

Yes Yes

Configuration Settings

CM-6

a) The project team shall establish and document configuration settings for information technology products employed within the system using the NIST USGCB Checklists with agency modifications by the Department that reflects the most restrictive mode consistent with operational requirements;

Yes Yes

b) The project team shall implement the configuration settings

Yes Yes

c) The project team shall identify, document, and approve any deviations from established configuration settings for individual components within the information system based on explicit operational requirements.

Office of the Chief Information Officer Page 23 of 58

d) The project team shall monitor and control changes to the configuration settings in accordance with the policies and procedures, defined by the CCB and approved by Security

Yes Yes

Least Functionality

CM-7

a) The project team shall configure the system to provide only essential capabilities; and

Yes Yes

b) The project team shall prohibit or restrict the use of functions, ports, protocols, and/or services as defined by the USDA/RD Security.

Yes No

CM-7 (1)

a) The project team shall review the system at least monthly to identify unnecessary and/or non-secure functions, ports, protocols, and services; and

Yes Yes

b) The project team shall disable functions, ports, protocols and services determined during the review to be unnecessary and/or insecure.

Yes Yes

CM-7 (4)

a) The project team shall identify software programs not authorized to execute on the system, and report to RD Security.

Yes Yes

Information System Component Inventory

CM-8

a) The project team shall develop and document an inventory of application/system components that:

1. Accurately reflects the current application/system;

2. Includes all components within the authorization boundary of the application/system;

3. Is at the level of granularity deemed necessary for tracking and reporting; and

4. Includes Information defined in the technical narrative contained in the SSP appendices for software and hardware contained within the system boundary;

and

Yes Yes

b) The project team shall review and update the application/system component inventory at a minimum annually.

Yes Yes

CM-8(1)

The project team shall update the inventory of information system components as an integral part of component installations, removals, and information system updates.

Office of the Chief Information Officer Page 24 of 58

CM-8(3)

a) The project team shall take the following actions when unauthorized components are detected; disables network access by such components; isolates the components; notifies alerts and/or reports to the security/system administrator who will take appropriate action(s).

Yes No

CM-8(5)

The project team shall verify that all components within the authorization boundary of the information system are not duplicated in other information system inventories.

Yes Yes

Configuration Management Plan

CM-9

a) The project team shall develop, document, and implement a configuration management plan for the system that addresses roles, responsibilities, and configuration management processes and procedures.

Yes Yes

b) The project team shall develop, document, and implement a configuration management plan for the system that establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;

Yes Yes

c) The project team shall develop, document, and implement a configuration management plan for the system that defines the configuration items for the system and places the configuration items under configuration management.

Yes Yes

d) The project team shall develop, document, and implement a configuration management plan for the system that protects the configuration management plan from unauthorized disclosure and modification.

Yes Yes

User Installed Software

CM-11

c) The PSO shall monitor policy compliance on user installed software at a minimum quarterly.

Office of the Chief Information Officer Page 25 of 58

IDENTIFICATION AND AUTHENTICATION

Control Name Control Derived Control Requirement

Applicable to non-cloud applications

Applicable to cloud (PaaS) based applications

Identification and Authentication

IA-8(3)

The project team shall employ only FICAM-approved information system components in publicly-accessible information systems to accept third-party credentials.

FICAM-approved information system components include, for example, information technology products and software libraries that have been approved by the Federal Identity, Credential, and Access Management conformance program.

Yes Yes

IA-8(4)

The application, including SOA services, shall conform to FICAM-issued profiles.

See http://www.idmanagement.gov/

The use of eAuth system in conjunction with RD authorization management systems may be FICAM compliant.

SYSTEM AND INFORMATION INTEGRITY

Control Name Control Derived Control Requirement

Applicable to non-cloud applications

Applicable to cloud (PaaS) based applications

Flaw Remediation

SI-2

a) The project team shall identify, report, and correct system flaws.

Yes Yes

b) The project team shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation.

Yes No

c) The project team shall install security-relevant software and firmware updates within 30 days of release of updates.

Office of the Chief Information Officer Page 26 of 58

d) The project team shall incorporate flaw remediation into the organizational configuration management process.

Yes Yes

SI-2 (2)

The NRC Security & Service Providers shall employ automated mechanisms at a minimum monthly to determine the state of system components with regard to flaw remediation.

Yes Yes

SI-2(3)

a) The RD Security and Service Providers shall measure the time between flaw identification and flaw remediation.

NA Yes

b) The project team shall establish the current time it takes on average to correct information system/application flaws after such flaws have been identified, report the results to RD Security, and subsequently establish organizational benchmarks for taking corrective actions.

Benchmarks can be established by type of flaw and/or severity of the potential vulnerability if the flaw can be exploited.

Office of the Chief Information Officer Page 27 of 58

Appendix C: Baseline Technical Requirements for Application with FIPS-199 Moderate Classification)

ACCESS CONTROL

Control Name Control Derived Control Requirement

Applicable to non-cloud applications

Applicable to cloud (PaaS) based applications

AC-2

The application shall enforce access, based on a valid access authorization, intended system usage, and other attributes as defined by the project team and consistent with USDA/RD Access Control Policy.

Example: An account created in eAuth, and that eAuth ID is associated with a pre-defined role and privileges in RD authorization management systems. The application must enforce the privileges taken from RD authorization management systems.

Yes Yes

AC-2(1)

The application shall provide automated mechanisms to support the management of information system accounts.

The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage;

and using telephonic notification to report atypical system account usage.

Yes Yes

AC-2(2)

The application shall provide capability to automatically disable, revoke and/or remove temporary and emergency accounts after the established end date when the account was created or maximum of 48 hours.

Yes Yes

AC-2(5)

The application shall require that users log out when a maximum of 15 minutes of inactivity has elapsed or when leaving the immediate area where the computer resides.

Example: Even session timeout would come from eAuth the application will still need to enforce the session timeout.

Office of the Chief Information Officer Page 28 of 58

AC-2(7)

a) The application shall provide capability to establish and administer privileged user accounts in accordance with a role-based access scheme with rights and privileges, approved by the Access Control Team.

NA Yes

b) The application shall provide capability to monitor privileged role assignments.

NA Yes

Access Enforcement

AC-3

The application shall enforce approved authorizations for logical access to information and system resources in accordance with and consistent with USDA/RD Access Control Policy.

Yes Yes

Access Enforcement/Role Based Access Control

AC-3(7)

The application shall enforce role based access policy over the defined subjects and objects and controls access based on USDA/RD Access Control Policy.

Role-based access control (RBAC) is an access control policy that restricts information system access to authorized users. Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organization-defined roles. RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every user but are instead acquired through role assignments.

Yes Yes

Information Flow Enforcement

AC-4

The application shall enforce approved authorizations for controlling the flow of information within the system and between interconnected systems based on the Department/agency policy for information flow and as defined in the security plan/ interconnection agreement for flow to other systems.

Yes Yes

AC-4(21)

The application shall separate information flows logically or physically to accomplish separation of user traffic and admin traffic.

NA Yes

Separation of Duties

AC-5

The application shall implement the separation of the duties of the roles as defined by the application team which adhere to USDA/RD Access Control Policy.

Yes Yes http://directives.sc.egov.usda.gov/viewerFS.aspx?hid=28650 http://directives.sc.egov.usda.gov/viewerFS.aspx?hid=28650 http://directives.sc.egov.usda.gov/viewerFS.aspx?hid=28650 http://directives.sc.egov.usda.gov/viewerFS.aspx?hid=28650

Office of the Chief Information Officer Page 29 of 58

Least Privilege

AC-6

The application shall implement the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.

Yes Yes

AC-6(1)

The application shall provide capability that explicitly authorizes access to the list of Security functions include, For example:

• Establishing system accounts.

• Configuring access authorizations (i.e., permissions, privileges.

• Setting events to be audited, and setting intrusion detection parameters.

Security-relevant information includes For example:

• Filtering rules for routers/firewalls.

• Cryptographic key management information.

• Configuration parameters for security services, and access control lists.

Explicitly authorized personnel include

For example:

• Security administrators

• System and network administrators

• System security officers

• System maintenance personnel, system programmers, and other privileged users.

Yes Yes

AC-6(2)

The application shall provide a capability that requires users of system accounts, or roles, with access to all security functions, use non-privileged accounts or roles, when accessing non-security functions.

Yes Yes

AC-6(5)

The application shall provide capability that restricts privileged accounts including super user accounts on the system.

Yes Yes

AC-6(9)

The application shall audit the execution of privileged functions.

Office of the Chief Information Officer Page 30 of 58

Privileged functions include, for example, establishing information system accounts, changing security rules, or administering cryptographic key management activities.

AC-6(10)

The application shall prevent non-privileged users from executing privileged functions including disabling, circumventing, or altering implemented security safeguards/countermeasures.

For e.g. This control would be implemented through privileges granted to particular roles provided by RD authorization management systems, and the application would enforce those privileged functions associated with a particular role.

Yes Yes

Unsuccessful Login Attempts

AC-7

a) The application shall enforce a limit of not more than three consecutive invalid logon attempts by a user during a maximum of 15 minutes.

Example: Even session timeout would come from eAuth the application will still need to enforce the session timeout.

Yes Yes

AC-7

b) The application shall lock the account/node for thirty minutes, when the maximum number of unsuccessful attempts is exceeded

Yes Yes

System Use Notification

AC-8

a) The application shall display to users the Department and, if defined, agency system use notification banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that:

1. Users are accessing a U.S. Government system;

2. System usage may be monitored, recorded, and subject to audit;

3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and

4. Use of the system indicates consent to monitoring and recording

Yes Yes

AC-8 b) The application shall retain the notification message or banner on the screen until users

Office of the Chief Information Officer Page 31 of 58 acknowledge the usage conditions and take explicit actions to log on to or further access the system.

AC-8

c) The application shall for publicly accessible systems:

1. displays system use information specific to this system in compliance with Department policy until accepted by the user before granting further access;

2. displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and

3. includes a description of the authorized uses of the system

Yes Yes

AC-10

The application shall limit the number of concurrent sessions for each login to for compelling operational needs.

NA Yes

Session Lock

AC-11

The application shall prevent further access to the system by initiating a session lock after 15 minutes of inactivity or upon receiving a request from a user.

Yes Yes

AC-11

The application shall retain the session lock until the user reestablishes access using established identification and authentication procedures.

Yes Yes

AC-11(1)

During a session lock, the application shall conceal information previously visible on the display with a publicly viewable image.

Yes Yes

Session Termination

AC-12

The application shall automatically terminate a user session after a maximum of 30 minutes of inactivity.

Wireless Access AC-18

a) Usage restrictions and implementation guidance for wireless access shall be established.

Yes Yes

b) The application shall monitor for unauthorized wireless access to the information system.

Office of the Chief Information Officer Page 32 of 58

Access Control For Mobile Devices

AC-18 (1)

The application shall protect wireless access to the system using authentication of users and/or devices according to USDA Wireless Policy and encryption

Yes Yes

AC-19 (5)

The application shall employ full device encryption or container encryption to protect the confidentiality and integrity of information on all mobile devices accessing the USDA network and/or RD data.

Yes No

Information Sharing

AC-21

a) The application shall provide capability to ensure sufficient access privileges are assigned to an authorized party and to ensure that access authorizations assigned to the sharing party match the access restrictions implemented on the information system where user…