JFS_-_Supplement_N__Contract_Addendum_1.7 - Final 5-16-2025.docx

JFS – Supplemental Contract Addendum revision 1.7 JFS -Supplemental Contract Addendum IOP – Innovate Ohio Platform Requirements In accordance with Executive Order 2019-15D and State IT Policy outlined in Supplement A (State IT Policy, Standard, and Service Requirements), the Ohio Department of Job and Family Services (ODJFS) requires contractor solutions accessing State Data (as defined in Supplement 1 ) to integrate with the InnovateOhio Platform (IOP).

Contractor solutions must adhere to the following IOP integration requirements:

1. IOP - Identity & Access Management Requirements

· Federated Single Sign-On (SSO): Applications must support federated SSO using either SAML 2.0 or OpenID Connect (OIDC) for Identity and Authentication via IOP.

· User Provisioning/De-provisioning: Applications must support one of the following automated methods integrated with IOP for authorizations and application enablement:

· Authorization-Based Assertion Attributes: Utilize token assertions upon sign-in to determine user authorizations (roles/permissions) based on supplied attributes (e.g., group membership).

· API Integration: Provide SOAP or REST web service endpoints for automated provisioning and de-provisioning tasks for authorizations

· SCIM: Provide a SCIM (System for Cross-Domain Identity Management) endpoint for automated user and group provisioning/de-provisioning between the application and IOP.

2. IOP - User Experience Requirements

· User Interface (UI): To the extent possible, application UIs should align with State standards for look, navigation, and presentation as guided by IOP principles for consistency. See: IT-08 Website Standardization - Ohio Department of Administrative Services

· User-Centric Design: Applications should employ user-centric design principles to ensure processes and tasks are efficient and secure for end-users.

· ADA compliant: Applications should ensure that their content meets current Federal and State ADA requirements, see: IT-09 Digital Accessibility

3. IOP - Data Analytics Requirements

· Data Availability: Applications must be capable of making data available to the IOP platform for secure storage, reporting, analytics, and potential sharing upon request, adhering to relevant data sharing protocols and privacy requirements under ORC 125.32.

Data Security Requirements

4. Data Encryption: Personally identifiable information (PII), or confidential personal information (CPI - as defined in Ohio Revised Code §1347), is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. One of the key security controls to protecting PII/CPI is encryption. The contractor’s solution shall ensure new cryptographic solutions comply with FIPS 140-3 for new validations and shall implement as appropriate cryptographic solutions that comply with the standards for post-quantum cryptography (PQC) established by NIST, as published in the NIST PQC Standardization Project by end of calendar year 2027.

Encryption, for PII/CPI data in all three states of existence and encryption requirements are listed below:

Data at Rest: Data at rest refers to inactive data which is stored physically in any digital form. This refers to both structured (databases) and unstructured Data (files).

PII/CPI data at rest must be protected in one of the following methods:

· Encrypt the Entire Database with Transparent Data Encryption (TDE)

· Table/ Column or Field Level Encryption can be used within the Database Tables to encrypt just the PII/CPI Any temporary representations (temp files or folders/ exports/ backups / reports, etc.) of PII/CPI must be encrypted in that current state.

· Applying newer encryption technologies and techniques, such as “homomorphic encryption” can be used to meet this requirement.

Data in Motion: Data in motion, also known as data in transit or data in flight, refers to information that is actively traveling from one place to another, like when an email is being sent or user interacting with a webpage and the transfer of data back and forth between client and server. In addition to the minimum encryption requirements noted above, PII/CPI data in motion must be protected in one of the following methods:

· Encrypt the entire transmission using HTTPS or IPSEC (or equivalent protocols) between all devices and tiers (such as UI > APP > DB Tiers)

· Encrypt the PII/CPI data only in transmission (Example: SOAP message using WS-Security)

· When using the Transport Layer Security (TLS), TLS version 1.3 or higher must be enforced.

Data in Use: Data in use refers to data actively being used across the network or temporarily residing in memory, or any data not currently “inactive”.

PII/CPI Data in Use must be protected in the following methods:

· At a minimum, hardware and/or software must be protected with Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR). Cloud based hyperscale environments must use secure enclaves.

· Sessions must be unique to each authenticated user and be protected in a way that meets the Open Web Application Security Project (OWASP)’s Application Security Verification Standard (ASVS).

· Application will use per user or session indirect object references where possible. All direct object references from an untrusted source must include an access control check to ensure the user is authorized for the requested object.

· Ensure that authentication /authorization checks are performed at each object at the controller and business logic levels, and not just at the presentation layer.

· Prevent injection attacks by using a parameterized API or escape special characters using the specific escape syntax for that interpreter. In addition, positive or “allow-list” input validation must also be used.

· Device configurations must conform to industry best practices for hardening (CIS Benchmarks, IRS SCSEMs, etc.).

· At the conclusion of a project, components such as libraries, frameworks, or other software modules used in development must be identified, listed, and provided to ODJFS. A supported version of these components must be used at time of the contract.

· Disable autocomplete on forms collecting PII/CPI and disable caching for pages that contain PII/CPI.

· Avoid the use of redirects and forwards as much as possible. When used, ensure destination parameters are a mapped value, and that server-side code translates this mapping to the target URL.

Audit Logging Federal and State Laws, codes, standards, and guidelines require ODJFS’ information systems to have compliant audit logging as well as compliant audit log management procedures in place.

5. Audit Logging Requirements The information system/application must record the following events in its audit log(s).

Required Audit Events

1. User account management activities (user creation, deletion, modification),

2. Application shutdown,

3. Application restart,

4. Application errors,

5. Failed and successful log-on(s),

6. Security policy modifications,

7. Use of administrator privileges,

8. All changes to logical access control authorities (e.g., rights, permissions, role assignment),

9. All system changes with the potential to compromise the integrity of audit policy configurations, security policy configurations and audit record generation services,

10. Access to Personally Identifiable Information (PII – Also known as Confidential Personal Information (CPI) by Ohio Law),

11. Modification to Personally Identifiable Information (PII) - Also known as Confidential Personal Information (CPI) by Ohio Law),

12. File creation, deletion, or modification by the application (PDF, CSV, etc. -).

Minimum Logging Requirements for Each Event The following are the minimum required details that must be captured with each recorded event:

1. Identity of any user/subjects associated with the event.

2. Event information,

3. What time the event occurred,

4. Subsystem or application the event occurred in,

5. And, if applicable, the success or failure of the event Audit Record Generation Services All Applications shall notify appropriate personnel of an audit log processing failure, and:

a. stop all processing of further requests until the audit log processing is restored, or

b. queue all events to disk, until such time as the audit log processing is restored.

Audit Retention, Aggregation, and Analysis Applications are required to send audit event log information through standard processes (such as SYSLOG,) or through add-ons to the Log and Event Management (LEM) Tool, and Enterprise Security Information and Event Management (SIEM) (i.e., security log ingestion/collection).

It is the contractor’s responsibility to acquire, purchase, and set up any required third-party tools or services to achieve this requirement.

Audit log information must be sent securely to ODJFS LEM and/or SIEM tools, and, when applicable, to the CPI Log repository using encryption methods described in Section 2, Data Encryption above.

When applicable, the contractor shall comply with requirements of Ohio Revised Code (ORC) §1347 regarding the access, use and protection of Confidential Personal Information (CPI), including implementing and maintaining logging mechanisms to record access to CPI as detailed in ORC §1347. Audit log information must be sent securely to an agreed-upon ODJFS CPI log repository using encryption methods described in “Data Security Requirements” above.

Governance, Risk, and Compliance

6. Auditing and Accountability If the service is cloud based, or contractor hosted, the contractor must obtain and provide annual American Institute of Certified Public Accountants (AICPA) Statements on Standards for Attestation Engagements (“SSAE”) No. 18, Service Organization Control (SOC) 1 Type 2 and SOC 2 Type 2 reports. Additionally, if the solution will process financial transactions the contractor must also obtain and provide an annual AICPA SSAE - SOC 1 Type 1 report.

These audits must be completed annually and must cover the entire solution noted in the contract, including but not limited to, operations, applications, processes, and procedures. The contractor is responsible for all audit costs including the costs for third party certified public accountant services. The contractor must provide results to the State within 30 days of completion.

The State may audit the controls and security measures in effect for the cloud based or hosted service without notice. The contractor must be cooperative and provide requested information as is reasonably necessary for an audit. Should the State determine the contractor’s controls or security measures are not consistent with State policies, or are otherwise inadequate, the State may terminate or suspend the contractor’s service immediately.

Development, Release, and Change Management

7. Data Set Used in Development ODJFS prohibits the use of production data in non-production environments (development, quality testing, user acceptance testing, etc.). Non-production data must be generated or masked except when approved by the ODJFS Chief Security Officer or designee. In instances where approval is given, ODJFS requires the same set of security controls be in place for the non-production environment as the production environment.

8. DevOps Vulnerability Scanning Applications being developed for hosting by the State (on-premises) must adhere to ODJFS DevOps pipeline AppSec tools and processes. This includes both static (code or white-box scanning) and dynamic (application or black-box scanning) vulnerability scanning. Additionally, any libraries or components used in the contractor’s solution must be free of known critical or severe vulnerabilities and must be scanned by ODJFS’ Software Composition Analysis (SCA) tool.

In hosted solutions or Software as a Service (SaaS) Applications or Services the contractor must provide proof that these scans are being performed and evaluated internally as part of their SDLC/DevOps processes, or by third party compliance assessment certification/attestation (FedRAMP, SOC 2, ISO 27001, OWASP ASVS, CSA STAR, etc.).

9. Penetration Testing

The contractor shall (at its own expense) engage an independent, qualified third-party security firm to conduct penetration testing on all internal ODJFS applications developed, maintained, or hosted as part of the contract. The scope of the penetration testing shall include assessing vulnerabilities relating to authentication and authorization mechanisms, input validation and injection attacks, session management and security controls, data encryption at rest, in motion and in use, and compliance with applicable industry and regulatory standards.

10. Release and Change Management The contractor will accept and comply with all ODJFS release management and change management process requirements and standards, as outlined by the state of Ohio and/ or the Office of Information Systems (OIS) policies and standards in their entirety. Contractors are responsible for maintaining appropriate controls and documentation of their applications, systems, and environments in accordance with State IT policies and standards outlined in this document, DAS Supplement A – State IT Policy Standard and Service Requirements, and Data Security and Privacy Terms.

This scope shall specifically apply to:

· Major and minor projects, upgrades, updates, fixes, patches, and other software and systems inclusive of all State elements or elements under the contractor's responsibility utilized by the State.

· Any systems development, integration, operations, and maintenance activities performed by the contractor.

· Any authorized change orders, change requests, statements of work, extensions, or amendments to the contract.

· Contractor locations, equipment, and personnel that access State systems, networks or data directly or indirectly.

· Any contractor personnel or sub-contracted personnel that have access to State confidential, personal, financial, infrastructure details or sensitive data.

.NET Development:

ODJFS leverages the GIT Repository for code, and Azure DevOps Build Pipeline and Azure DevOps Release Tasks for Release management.

Java Development:

ODJFS leverages the GIT repository for code, and Jenkins for Continuous Integration and Continuous Delivery and XL Release for Release Management.

Salesforce Development:

ODJFS utilizes the GIT repository for code and the Copado tool for build and release management for Salesforce applications.

Change Management ODJFS uses the ServiceNow Change Management Module to submit change requests to be reviewed and approved by the Change Advisory Board (CAB).

Database Read Replicas and Data Dictionary Database Read Replicas provide enhanced performance, scalability, and durability for database (DB) instances. They make it easy to elastically scale out beyond the capacity constraints of a single DB instance. Read Replicas can also be leveraged to share data with other state and federal agencies as well as for analytics and reporting needs. Based on that, ODJFS requires contractors to enable read replica & data dictionary for contractor hosted public cloud, and contractor managed public cloud solutions.

Cloud Vendor Agnostic Products and Services ODJFS requires contractors to use cloud-agnostic products and services to ensure ODJFS IT systems do not rely on one cloud provider's proprietary services, which allows the State to easily migrate to a different provider should the State decide to do so.

Infrastructure as Code (IaC) Contractors must employ IaC to manage and provision stable environments consistently, reliably, rapidly at scale and on demand.

ODJFS prefers contractors use declarative definition files where possible when managing IaC. This abstraction allows for greater flexibility in the middle. It also helps reduce the technical debt of maintaining imperative code, such as deployment scripts, that can accrue over time.

6 | Page image1.gif