Exhibit A - Information Technology Requirements_Attachments 1-6.xlsx

Version Log

(1) IT Requirements - Attach. 1

REQUEST FOR PROPOSALS (RFP) 13259

Assessor and Auditor and Controller Document Management System

Information Technology Requirements Business Critical

The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.

1. Client to server communications

2. Server to server communications

3. Database communications

4. API communications

5. List any unencrypted data-in-transit instances the solution requires MR-7 The solution shall support data encryption for all data at rest including:

1. Disk level encryption

2. Database/Storage/Share Encryption

3. File level encryption

a. Application Service to Application Service credentials

b. Application Service to Database credentials

c. API credentials MR-13 The solution must prevent the following items from being stored/hardcoded within the source code:

1. Passwords

2. API keys

3. Certificates

4. Tokens

5. Hashes

6. Anything considered secret

A trusted document management system ensures that all electronically stored information can be considered to be a true and accurate copy of the original information received regardless of the original format. The trusted document management system must ensure that at least two (2) separate copies of the electronically stored information are created meeting, at a minimum, all the following conditions:

(a) The trusted document management system must utilize both hardware and media storage methodologies to prevent unauthorized additions, modifications or deletions during the approved lifecycle of the stored information

(b) The trusted document management system must be verifiable through independent audit processes ensuring that there is no plausible way for electronically stored information to be modified, altered, or deleted during the approved information lifecycle

(c) The trusted document management system must write at least one copy of the electronic document or record into electronic media that does not permit unauthorized additions, deletions, or changes to the original document and that is to be stored and maintained in a safe and separate location. (d) The trusted document management systems incorporate not only technology, but also require adherence to organizational policies ensuring proper electronic document or record handling, processing as required by the organization (typically documented in the record retention policy and schedule) and electronic document management software or application components MR-18 All reporting or application systems that generate electronic documents for public use shall ensure the content is accessible. Vendors must consider HTML or other web-based formats as the default. If PDFs are necessary, they must meet WCAG 2.1 Level AA standards and comply with Title II of the ADA.

(2) IT Requirements - Attach. 2

Assessor and Auditor and Controller Document Management System

Information Technology Requirements Detailed Technical

The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.

2. Log on attempt and failed data access attempts

3. System and application file access

4. System change attempts

5. User and Service account changes, including

a. Account creation

b. Account role changes/modification

c. Deletion

6. Use of privileged user account

7. All changes to security configuration, including:

a. User access changes

b. Deletion of audit logs DR-15 The solution shall retain audit logs within the server or application as appropriate for data classification and special mandates imposed by state and federal laws:

- County policy: retention minimum of 180 days

a. Performance Target = Response Time 24/7, <2 seconds

b. SL Performance (%) = Aggregate 99.0%

Please describe how this can be accomplished.

DR-28 The solution must meet the following service level for application availability:

a. Performance Target = Available 24/7

b. SL Performance (%) = 99.90%

Please describe how this can be accomplished.

DR-29 Solution must have a Recovery Time Objective (RTO) within 48 hours.

Please explain how this is accomplished.

(3) IT Requirements - Attach 3

Assessor and Auditor and Controller Document Management System

Information Technology Requirements CoSD Sensitive Personally Identifiable Information (PII) Security Attachment 3 - Statement of Work The following are Sensitive PII Security requirements that proposer must respond to. All Information Technology Requirements shall be incorporated as an Attachment to Exhibit A - Statement of Work. State Yes or No to indicate whether or not your solution will meet the requirement. If No, state what work is necessary to meet the requirement or how your solution will meet the requirements and the work necessary to meet the requirements - indicate costs if needed. Applicable product literature or technical documentation can be provided to support your response.

The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.

(4) IT Requirements - Attach 4

Assessor and Auditor and Controller Document Management System

Information Technology Requirements CoSD Health Insurance Portability and Accountability Act (HIPPA) Security Attachment 4 - Statement of Work The following are HIPPA Security requirements that proposer must respond to. All Information Technology Requirements shall be incorporated as an Attachment to Exhibit A - Statement of Work. State Yes or No to indicate whether or not your solution will meet the requirement. If No, state what work is necessary to meet the requirement or how your solution will meet the requirements and the work necessary to meet the requirements - indicate costs if needed. Applicable product literature or technical documentation can be provided to support your response.

The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.

1. System and application file access.

2. System change attempts.

3. User and Service account changes, including:

a. Account creation.

b. Account role changes/modification.

c. Deletion.

4. Use of privileged user account.

5. The application logs activities of privileged users.

6. Changes to the security configuration (e.g. change of user(s) privileges, deletion of audit log, etc.) of the solution logged.

* Identify and respond to suspected or known security incidents

* Mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity

* Documents security incidents and their outcomes

(5) IT Requirements - Attach 5

Assessor and Auditor and Controller Document Management System

Information Technology Requirements CoSD Federal Tax Information (FTI) Security Attachment 5 - Statement of Work The following are FTI Security requirements that proposer must respond to. All Information Technology Requirements shall be incorporated as an Attachment to Exhibit A - Statement of Work. State Yes or No to indicate whether or not your solution will meet the requirement. If No, state what work is necessary to meet the requirement or how your solution will meet the requirements and the work necessary to meet the requirements - indicate costs if needed. Applicable product literature or technical documentation can be provided to support your response.

The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.

a. Define and document the types of accounts allowed and specifically prohibited for use within the system;

b. Assign account managers;

c. Require conditions for group and role membership;

d. Specify:

1. Authorized users of the system;

2. Group and role membership; and

3. Access authorizations (i.e., privileges) and other attributes (as required) for each account.

e. Require approvals by the system owner or designated representative for requests to create accounts;

f. Create, enable, modify, disable and remove accounts in accordance with agency account management procedures prerequisites;

g. Monitor the use of accounts;

h. Notify account managers and designated agency official within:

1. 24 hours when accounts are no longer required;

2. 24 hours when users are terminated or transferred; and

3. 24 hours when system usage or need-to-know changes for an individual;

i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. Under the authority to re-disclosed FTI under the provisions of IRC § 6103;

j. Review accounts for compliance with account management requirements annually for user account and semi-annually for privileged accounts;

k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

l. Align account management processes with personnel termination and transfer processes.

4.1 AC - Access Control AC-3 Access Enforcement

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

(IRS-Defined): Users having accounts with administrator access privileges may access those accounts only from agency-owned or authorized contractor systems.

Supplemental Guidance: A key intent is to prohibit personally-owned or public kiosk (e.g., library) systems from being used for remote administrator access. If individuals with administrator rights require email or Internet access beyond local boundaries, one alternative would be to issue separate, non-privileged accounts (one per affected individual) for that purpose. For the considerations of this section, administrator accounts/rights are those that allow for the installation or configuration of software on agency assets receiving, processing, storing, accessing, protecting and/or transmitting FTI.

4.1 AC - Access Control AC-4 Information Flow Enforcement

Enforce approved authorization for controlling the flow of information within the system and between interconnected systems based on the technical safeguards in place to protect FTI

4.1 AC - Access Control AC-5 Separation of Duties

a. Identify and document separate duties of individuals to prevent harmful activity without collusion; and

b. Define system access authorizations to support separation of duties.

4.1 AC - Access Control AC-6 Least Privilege

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

4.1 AC - Access Control AC-7: Unsuccessful Logon Attempts

a. Enforce a limit of three (3) consecutive invalid logon attempts by a user during a 120-minute period; and

b. Automatically lock the account for 15 minutes or until released by an administrator when the maximum number of unsuccessful attempts is exceeded.

4.1 AC - Access Control AC-8: System Use Notification

a. Display a warning banner to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state 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;

b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and

c. For publicly accessible systems:

1. Display system use information warning banner before granting further access to the publicly accessible system;

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

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

Supplemental Guidance: The warning banner must be applied at the application, database, operating system, and network device levels for all systems that receive, process, store, or transmit FTI.

4.1 AC - Access Control AC-11: Device Lock

a. Prevent further access to the system by initiating a device lock after 15 minutes of inactivity; requiring the user to initiate a device lock before leaving the system unattended; and

b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.

Supplemental Guidance: Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks are implemented where session activities can be determined. This is typically at the operating system level but can also be at the application level. Device locks are not an acceptable substitute for logging out of systems, for example, if organizations require users to log out at the end of workdays.

4.1 AC - Access Control AC-12: Session Termination

Automatically terminate a user session after 30 minutes of inactivity.

Supplemental Guidance: This control addresses the termination of user-initiated logical sessions in contrast to SC-10 which addresses the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an agency system. Such user sessions can be terminated without terminating network sessions. Session termination terminates all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, time-ofday restrictions on system use.

4.1 AC - Access Control AC-14: Permitted Actions Without Identification or Authentication

a. Identify specific user actions that can be performed on the system without identification or authentication consistent with organizational mission and business functions and

b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.

Supplemental Guidance: This control addresses situations in which agencies determine that no identification or authentication is required in agency systems. Agencies may allow a limited number of user actions without identification or authentication including, for example, when individuals access public websites. Access to FTI without identification and authentication is strictly prohibited.

4.1 AC - Access Control AC-17: Remote Access

a. Establish and document usage restrictions, configuration/connection requirements and implementation guidance for each type of remote access allowed; and

b. Authorize each type of remote access to the system prior to allowing such connections.

Supplemental Guidance: Remote access is access to agency systems (or processes acting on behalf of users) communicating through external networks such as the Internet. Remote access methods include, for example, dial-up, broadband, and wireless. Remote access controls apply to systems other than public web servers or systems designed for public access. Any remote access where (i) FTI is accessed or (ii) an FTI environment is administered over the remote connection must be performed using multifactor authentication. Requirements of multifactor authentication are provided in NIST Control IA-2: Identification and Authentication (Organizational Users).

4.1 AC - Access Control AC-18: Wireless Access

1. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and

2. Authorize each type of wireless access to the system prior to allowing such connections

4.1 AC - Access Control AC-19: Access Control for Mobile Devices

a. Establish configuration requirements, connection requirements and implementation guidance for organization-controlled mobile devices to include when such devices are outside of controlled areas; and

b. Authorize the connection of mobile devices to organizational systems.

Supplemental Guidance: A mobile device is considered a computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile device requirements are not applicable to laptop computers.

4.1 AC - Access Control AC-20: Use of External Systems

a. Establish terms and conditions, consistent with the trust relationships established with other organizations owning, operating and/or maintaining external systems, allowing authorized individuals to:

1. Access the system from external systems; and

2. Process, store, or transmit organization-controlled information using external systems; or

b. Prohibit the use of non-agency managed external systems.

Supplemental Guidance: External information systems, or non-agency-owned equipment, include any technology used to receive, process, store, access, protect and/or transmit FTI that is not owned and managed by 1) the agency or the agency-run mobile device management system, 2) a state's consolidated IT office, 3) one of the agency's approved contractors or sub-contractors (e.g., print vendors, collections agencies, application development contractors, network engineers at a state consolidated IT office, etc.) or 4) one of the agency's constituent counties. To ensure a third-party contractor system is not considered an external information system, the agency must include Exhibit 7 language in its contract with the service provider. Examples of external information systems include but are not limited to: 1) personally-owned devices, which includes any device owned by an individual employee, rather than the agency itself; and 2) devices owned and managed by agency stakeholders that do not have proper approvals to receive, process, store, access, protect and/or transmit FTI.

4.1 AC - Access Control AC-21: Information Sharing

a. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information’s access and use restrictions for information sharing circumstances where user discretion is required and permitted by IRC § 6103; and

b. Employ automated mechanisms or manual processes compliant with IRC § 6103 to assist users in making information sharing and collaboration decisions.

Supplemental Guidance: The agency must restrict the sharing/re-disclosure of FTI to only those authorized in IRC § 6103 and as approved by the Office of Safeguards.

4.1 AC - Access Control AC-22: Publicly Accessible Content

a. Designate individuals authorized to make information publicly accessible;

b. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;

c. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and

d. Review the content on the publicly accessible system for nonpublic information at a minimum quarterly and remove such information, if discovered.

Supplemental Guidance: FTI is considered nonpublic information and may never be posted or shared on a publicly accessible system.

4.1 AC - Access Control AC-23: Data Mining Protection

Employ agency-defined data mining prevention and detection techniques for agency-defined data storage objects to detect and protect against unauthorized data mining.

4.2 AT - Awareness and Training AT-2: Awareness Training

a. Provide security and privacy literacy training to system users (including managers, senior executives, and contractors):

1. As part of initial training for new users and annually thereafter; and

2. When required by system changes or following assessment or audit findings, security or privacy incidents, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines;

b. Employ the following techniques to increase the security and privacy awareness of system users by providing one or more short ad hoc sessions and include topical information on recent attack schemes, changes to organizational security and privacy policies, revised security and privacy expectations, or a subset of topics from the initial training.

c. Update literacy training and awareness content annually and following system changes and

d. Incorporate lessons learned from internal or external security or privacy incidents into literacy training and awareness techniques.

4.2 AT - Awareness and Training AT-3: Role-Based Training

a. Provide role-based security and privacy training to personnel with the following roles and responsibilities: information system security manager (ISSM); information system security officer (ISSO); security specialist; system and software developers; system, network and database administrators; programmer/systems analyst; and personnel having access to FTI

1. Before authorizing access to the system, information, or performing assigned duties, and annually thereafter; and

2. When required by system changes;

b. Update role-based training content annually and following system changes and Update literacy training and awareness content annually and following system changes; and

c. Incorporate lessons learned from internal or external security or privacy incidents into role-based training.

Supplemental Guidance: Agencies may determine the appropriate content of security and privacy training based on the assigned roles and responsibilities of individuals and the specific security and privacy requirements of organizations and the systems to which personnel have authorized access, including security-related technical training specifically tailored for assigned duties. Additional roles that may require role-based security and privacy training include, for example, system owners; authorizing officials; system security officers; privacy officers; enterprise architects; acquisition and procurement officials; systems engineers; personnel conducting configuration management activities; personnel performing verification and validation activities; auditors; personnel having access to system-level software; security and privacy control assessors; personnel with contingency planning and incident response duties; and personnel with privacy management responsibilities.

4.2 AT - Awareness and Training AT-4: Training Records

a. Document and monitor information security and privacy training activities, including security and privacy awareness training and specific role-based security and privacy training; and

b. Retain individual training records for a period of five (5) years

4.2 AT - Awareness and Training AT-6: Training Feedback

Provide feedback on organizational training results to the following personnel: Agency Senior Management and Agency Disclosure Personnel on an annual basis.

4.3 AU - Audit and Accountability AU-2: Audit Events

a. Identify the types of events that the system is capable…