1915 System and Services Acquisition Policy

Georgia State Seal

Department of Human Services
Online Directives Information System

Index:

POL1915

Revised:

06/02/2025

Next Review:

06/02/2027

Subject: DHS Information Security Policies

Policy

This policy establishes the Enterprise System and Services Acquisition Policy, for managing risks from third party products and services’ providers, through the establishment of an effective third-party risk management program. The third-party risk assessment program helps DHS implement security best practices with regard to Systems and Services Acquisition.

Authority

  1. United States Department of Commerce National Institute for Standards and Technology (NIST)

  2. United States Internal Revenue Service

  3. United States Department of Health & Human Services – Administration of Children and Families (ACF), Office of Child Support Services (OCSS)

  4. United States Department of Health & Human Services - Centers for Medicare & Medicaid Services (CMS)

  5. Georgia Technology Authority

  6. Social Security Administration

  7. Federal Bureau Investigation (Criminal Justice Information Services)

References

Applicability

The scope of this policy is applicable to all Information Technology (IT) resources owned or operated by DHS. Any information, not specifically identified as the property of other parties, that is transmitted or stored on DHS IT resources (including email, messages, and files) is the property of DHS. All users (DHS employees, contractors, vendors, or others) of IT resources are responsible for adhering to this policy.

Definitions

System maintenance

System Maintenance is a catchall term used to describe various forms of computer or server maintenance required to keep a computer system running properly. It can describe network maintenance, which could mean that servers are being physically repaired, replaced, or moved. Network maintenance can also mean that the software for a server is being updated, changed, or repaired. This sort of maintenance is typically performed on a regular or semi-regular schedule, often during non-peak usage hours, and keeps servers running smoothly.

Responsibilities

DHS shall adopt the System and Services Acquisition principles established in NIST SP 800-53 “System and Services Acquisition,” Control Family guidelines, as the official policy for this domain. The following subsections outline the System and Services Acquisition standards that constitute DHS policy. Each DHS Business System is then bound to this policy, and shall develop or adhere to a program plan which demonstrates compliance with the policy related the standards documented.

SA-1 System and Services Acquisition Policy and Procedures

  1. Develop, document, and disseminate to designated agency personnel:

    1. All organizational level system and services acquisition policy that:

      1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

      2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

    2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated controls.

  2. Designate an agency official to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and

  3. Review and update the current system and services acquisition control:

    1. Policy every one (1) year (or if there is a significant change); and

    2. Procedures every one (1) year, (or when there is a significant change).

SA-2 Allocation of Resources

  1. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;

  2. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and

  3. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.

SA-3 System Development Life Cycle

  1. Acquire, develop, and manage the system using an agency or organization-level system development life cycle that incorporates information security and privacy considerations;

  2. Define and document information security and privacy roles and responsibilities throughout the systems development lifecycle (SDLC);

  3. Identify individuals having information security and privacy roles and responsibilities; and

  4. Integrate the organizational information security and privacy risk management process into SDLC activities.

SA-3 (1) Manage Preproduction Environment:

Protect system preproduction environments commensurate with risk throughout the system development life cycle (SDLC) for the system, system component, or system service.

SA-3 (2) Use of Live Data:

  1. Approve, document, and control the use of live data in preproduction environments for the system, system component, or system service; and

  2. Protect preproduction environments for the system, system component, or system service at the same impact or classification level as any live data in use within the preproduction environments.

SA-4 Acquisition Process

Include the following requirements, descriptions, and criteria, explicitly or by reference, using organization-defined contract language in the acquisition contract for the system, system component, or system service:

  1. Security and privacy functional requirements;

  2. Strength of mechanism requirements;

  3. Security and privacy assurance requirements;

  4. Controls needed to satisfy the security and privacy requirements;

  5. Security and privacy documentation requirements;

  6. Requirements for protecting security and privacy documentation;

  7. Description of the system development environment and environment in which the system is intended to operate;

  8. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and

  9. Acceptance criteria.

SA-4 (1) Functional Properties of Controls:

Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.

SA-4 (2) Design and Implementation Information for Controls:

Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; organization-defined design and implementation information for the security controls to be employed at sufficient level of detail to permit analysis and testing of controls.

SA-4 (8) Continuous Monitoring Plan for Controls:

Require the developer of the system, system component, or system service to produce a plan for continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization.

SA-4 (9) Functions, Ports, Protocols and Services in Use:

Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.

SA-4 (12) Data Ownership:

  1. Include organizational data ownership requirements in the acquisition contract; and

  2. Require all data to be removed from the contractor’s system and returned to the organization within 7 calendar days prior to contract termination.

IRS.1:

Information systems that receive, process, store, access, protect and/or transmit FTI must be located, operated, and accessed within the United States. When a contract developer is used, agencies must document, through contract requirements, that all FTI systems (i.e., beyond commercial products used as components) are located within the United States and are developed physically within the United States by United States citizens or those with lawful resident status.

IRS.2:

In acquiring information technology, agencies must use common security configurations, when applicable, by (a) requiring vendors to configure IT with common security configurations (when available and applicable, e.g., Center for Internet Security benchmarks) prior to delivery or (b) configuring acquired IT to meet agency-tailored, secure parameters (e.g., configurations that meet Publication 1075 and applicable SCSEM requirements) after delivery but prior to deployment.

SA-5 Information System Documentation

  1. Obtain or develop administrator documentation for the system, system component, or system service that describes:

    1. Secure configuration, installation, and operation of the system, component, or service;

    2. Effective use and maintenance of security and privacy functions and mechanisms; and

    3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;

  2. Obtain or develop user documentation for the system, system component, or system service that describes:

    1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;

    2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and

    3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;

  3. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take agency-defined actions (e.g., recreates documentation that is essential to the effective implementation or operation of security controls) in response; and

  4. Distribute documentation to designated agency officials.

SA-8 Security Engineering Principles

Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: agency-defined systems security and privacy engineering principles.

SA-08 (14) Least Privilege:

Implement the security design principle of least privilege in organization-defined systems or system components

SA-08 (18) Trusted Communications Channel:_

Implement the security design principle of trusted communications channels in organization-defined systems or system components.

SA-08 (22) Accountability and Traceability:

Implement the security design principle of accountability and traceability in organization-defined systems or system components.

SA-08 (23) SECURE DEFAULTS:

Implement the security design principle of secure defaults in organization-defined systems or system components.

SA-08 (31) SECURE SYSTEM MODIFICATION:

Implement the security design principle of secure system modification in organization-defined systems or system components

SA-08 (32) SUFFICIENT DOCUMENTATION:

Implement the security design principle of sufficient documentation in organization-defined system or system components.

SA-08 (33) MINIMIZATION:

Implement the privacy principle of minimization using organization-defined processes.

SA-9 External System Services

  1. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: the security and privacy requirements contained within the IRS Publication 1075, the SSA TSSR, applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidance, and established service-level agreements;

  2. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and

  3. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: continuous monitoring activities (e.g., perform internal inspections, complete self-assessments using SCSEM, perform automated configuration compliance scans, etc.)

SSA.1:

The state organization will provide its contractors and agents with copies of the Agreement, related IEAs, and all related attachments before initial disclosure of SSA data to such contractors and agents. Prior to signing the Agreement, and thereafter at SSA’s request, the state organization will obtain from its contractors and agents a current list of the employees of such contractors and agents with access to SSA data and provide such lists to SSA.

SA-9 (1) Risk Assessments and Organizational Approvals:

  1. Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and

  2. Verify that the acquisition or outsourcing of dedicated information security services is approved by a designated agency official.

SA-9 (2) Identification of Functions, Ports, Protocols and Services:

Require providers of external information system services that process, store, or transmit CUI to identify the functions, ports, protocols, and other services required for the use of such services.

SA-9 (3) Establish and Maintain Trust Relationship with Providers:

Establish, document, and maintain trust relationships with external service providers based on the following requirements, properties, factors, or conditions: IRS Publication 1075 requirements for information systems that process, store, or transmit CUI.

SA-9 (5) Processing, Storage and Service Location:

Restrict the location of accessing, processing, storage, transmission of CUI to the U.S. and territories mandated by state regulation, federal law, Executive Order, or other authoritative direction.

SA-9 (6) Organization-Controlled Cryptographic Keys:

Maintain exclusive control of cryptographic keys for encrypted material stored or transmitted through an external system.

SA-9 (8) Processing and Storage Location – U.S. Jurisdiction:

Restrict the geographic location of information processing and data storage to facilities located within in the legal jurisdictional boundary of the United States.

SA-10 Developer Configuration Management

Require the developer of the system, system component, or system service to:

  1. Perform configuration management during system, component, or service: design, development, implementation, and operation and disposal;

  2. Document, manage, and control the integrity of changes to configuration items under configuration management;

  3. Implement only organization-approved changes to the system, component, or service;

  4. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and

  5. Track security flaws and flaw resolution within the system, component, or service and report findings to the designated agency official.

SA-10 (1) Software and Firmware Integrity Verification:

Require the developer of the system, system component, or system service to enable integrity verification of software and firmware components.

SA-10 (3) Hardware Integrity Verification:

Require the developer of the system, system component, or system service to enable integrity verification of hardware components.

SA-10 (7) Security and Privacy Representatives:

Require agency designated security and privacy representatives to be included in the configuration change management and control process.

SA-11 Developer Testing and Evaluation

Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:

  1. Develop and implement a plan for ongoing security and privacy assessments;

  2. Perform system testing/evaluation at the depth of one or more of the following: security-related functional properties, security-related externally visible interfaces, high-level design, low-level design and/or implementation representation (i.e., source code and hardware schematics) at all post-design phases of the SDLC;

  3. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;

  4. Implement a verifiable flaw remediation process; and

  5. Correct flaws identified during testing and evaluation.

SA-11 (1) Static Code Analysis:

Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.

SA-11 (2) Threat Modeling and Vulnerability Analysis:

Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and subsequent testing and evaluation of the system, component, or service that:

  1. Uses the following contextual information: organization-defined information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels;

  2. Employs organization-defined tools and methods;

  3. Conducts the modeling and analyses at the following level of rigor: organization-defined breadth and depth of modeling and analyses; and

  4. Produces evidence that meets organization-defined acceptance criteria.

SA-11 (4)Manual Code Reviews:

Require the developer of the system, system component, or system service to perform a manual code review of CUI related applications using the following processes, procedures, and/or techniques: agency-defined manual review process.

SA-11 (5) Penetration Testing:_

Require the developer of the system, system component, or system service to perform penetration testing:

  1. At the following level of rigor: at a minimum Whitebox testing; and

  2. Under the following constraints: where CUI is processed, stored, or transmitted.

SA-11 (6) Attack Surface Reviews:

Require the developer of the system, system component, or system service to perform attack surface reviews.

SA-11 (8) Dynamic Code Analysis:

Require the developer of the system, system component, or system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis.

SA-15: Development Process, Standards and Tools

  1. Require the developer of the system, system component, or system service to follow a documented development process that:

    1. Explicitly addresses security and privacy requirements;

    2. Identifies the standards and tools used in the development process;

    3. Documents the specific tool options and tool configurations used in the development process; and

    4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and

  2. Review the development process, standards, tools, tool options, and tool configurations at a minimum annually to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: organization-defined security and privacy requirements.

SA-15 (3) Criticality Analysis:

Require the developer of the system, system component, or system service to perform a criticality analysis:

  1. At the following decision points in the system development life cycle: the agency-defined breadth/depth; and

  2. At the following level of rigor: post-design phases of the SDLC.

SA-15 (12) Minimize Personally Identifiable information:

Require the developer of the system or system component to minimize the use of Personally Identifiable Information (PII) in development and test environments.

SA-17 Developer Security Architecture and Design

Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:

  1. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;

  2. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and

  3. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.

SA-21 Developer Screening

Require that the developer of systems, system components, or system services:

  1. Has appropriate access authorizations as determined by the assigned Authorizing Official (AO) or Designee; and;

  2. Satisfies personnel screening criteria consistent with PS-3.

SA-22 Unsupported System Components

  1. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or

  2. Provide the following options for alternative sources for continued support for unsupported components: Extended security support agreement that include security software patches and firmware updates from an external source for each unsupported component. Provide justification and document the approval for the continued use of unsupported system components required to satisfy mission/business needs.

History

Date Change User Version

Evaluation

The Office of Information Technology (OIT), upon recommendation of the DHS Chief Information Security Officer (CISO), evaluates this policy annually by:

  1. Comparing its content and intent to evolving regulatory compliance standards imposed upon the Agency, such as, IRS 1075, NIST 800-53, and CMS MARS-E.

  2. Addressing any deficiencies or gaps discovered during periodic audits conducted by Georgia DOAA or other regulatory bodies, such as, IRS, CMS, SSA, FBI, etc.