Common use of Security Testing Recommendations Clause in Contracts

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted code created by the web development team) • The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • Any separate backend application servers that process information from the web application • The backend database systems that house information associated with the web application. • Infrastructure diagrams. • Configuration host review of settings and patch versions, etc. • Full code review. • Identification and remediation of well-known web server, code engine, and database vulnerabilities. • Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • Analysis of data communications between the application and databases or other backend systems. • Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • Identification of areas where error handling is insufficient or reveals too much sensitive information. • Identification of opportunities to write to the host file system or execute uploaded files. • Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • Determination as to whether or not fraudulent transactions or access can be performed. • Attempts to view unauthorized data, especially data that should be confidential. • Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted customcrafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • Any separate backend application servers that process information from the web application • The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • ▪ Any separate backend application servers that process information from the web application • ▪ The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- custom crafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via DocuSign Envelope ID: 2464DB96-258B-4365-A0E3-C78AF6EEDFF7 HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • § Any separate backend application servers that process information from the web application • § The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. • . A. Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. • . B. Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • : A. The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted code created by the web development team) • ) B. The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • ) C. Any separate backend application servers that process information from the web application • application D. The backend database systems that house information associated with the web application. • . E. Infrastructure diagrams. • . F. Configuration host review of settings and patch versions, etc. • . G. Full code review. • . H. Identification and remediation of well-known web server, code engine, and database vulnerabilities. • . I. Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • . J. Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • . K. Analysis of data communications between the application and databases or other backend systems. • . L. Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • Identification of areas where error handling is insufficient or reveals too much sensitive information. • Identification of opportunities to write to the host file system or execute uploaded files. • Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • Determination as to whether or not fraudulent transactions or access can be performed. • Attempts to view unauthorized data, especially data that should be confidential. • Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- custom-crafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-open- source Apache software) • ▪ Any separate backend application servers that process information from the web application • ▪ The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor Contractor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor Contractor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendorContractor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate a dequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor Contractor should include but not be limited to: •  The web application (i.e., the software that interacts with users at their web browsers; typically custom- custom-crafted code created by the web development team) •  The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-open- source Apache software) •  Any separate backend application servers that process information from the web application •  The backend database systems that house information associated with the web application. •  Infrastructure diagrams. •  Configuration host review of settings and patch versions, etc. •  Full code review. •  Identification and remediation of well-known web server, code engine, and database vulnerabilities. •  Identification and remediation of any server and application administration flaws and an exploitation attempt of same. •  Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. •  Analysis of data communications between the application and databases or other backend systems. •  Manual analyses of all input facilities for unexpected behavior such as SQL injectioninje ction, arbitrary command execution, and unauthorized data access. •  Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. •  Identification of information leakage across application boundaries, including includ ing the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. •  Identification of areas where error handling is insufficient or reveals too much sensitive information. •  Identification of opportunities to write to the host file system or execute uploaded files. •  Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. •  Determination as to whether or not fraudulent transactions or access can be performed. •  Attempts to view unauthorized data, especially data that should be confidential. •  Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. •  Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- custom crafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • § Any separate backend application servers that process information from the web application • § The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor Contractor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor Contractor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendorContractor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor Contractor should include but not be limited to: •  The web application (i.e., the software that interacts with users at their web browsers; typically custom- custom-crafted code created by the web development team) •  The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-open- source Apache software) •  Any separate backend application servers that process information from the web application •  The backend database systems that house information associated with the web application. •  Infrastructure diagrams. •  Configuration host review of settings and patch versions, etc. •  Full code review. •  Identification and remediation of well-known web server, code engine, and database vulnerabilities. •  Identification and remediation of any server and application administration flaws and an exploitation attempt of same. •  Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. •  Analysis of data communications between the application and databases or other backend systems. •  Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. •  Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. •  Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. •  Identification of areas where error handling is insufficient or reveals too much sensitive information. •  Identification of opportunities to write to the host file system or execute uploaded files. •  Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. •  Determination as to whether or not fraudulent transactions or access can be performed. •  Attempts to view unauthorized data, especially data that should be confidential. •  Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. •  Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted customcrafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-open- source Apache software) • ▪ Any separate backend application servers that process information from the web application • ▪ The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted customcrafted code created by the web development team) • The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • Any separate backend application servers that process information from the web application • The backend database systems that house information associated with the web application. • Infrastructure diagrams. • Configuration host review of settings and patch versions, etc. • Full code review. • Identification and remediation of well-known web server, code engine, and database vulnerabilities. • Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • Analysis of data communications between the application and databases or other backend systems. • Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • Identification of areas where error handling is insufficient or reveals too much sensitive information. • Identification of opportunities to write to the host file system or execute uploaded files. • Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • Determination as to whether or not fraudulent transactions or access can be performed. • Attempts to view unauthorized data, especially data that should be confidential. • Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.. 19Vendor Deliverables The following items are to be provided by the vendor: • OCHCA Security Requirements and Guidelines for Application Vendors and Application Service Providers - Questionnaire • Business Continuity Plan Summary (as related to service provided) • SSAE 18 SOC 2 Type 2 or SOC 3 compliance certificate • Network Diagram that demonstrates vendor network and application segmentation including the security controls in place to protect HCA data • IT Security Staff Usage Policy • IT Security Policies and Procedures • IT Operations Security Policy • Data Management Security Policy • Security Incident Notification and Management Process • Security Contact Identification (24x7x365) • Staff Related Items • o Pre-Employment Screening Policy/Procedure • o Background Checking Procedure • o Ongoing Employment Status Validation Process • oStaff Roster and Duties

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- custom-crafted code created by the web development team) • DocuSign Envelope ID: 32AC7F38-40B4-4FD7-9103-57D01A9AA5C7 ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-open- source Apache software) • ▪ Any separate backend application servers that process information from the web application • ▪ The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • DocuSign Envelope ID: 32AC7F38-40B4-4FD7-9103-57D01A9AA5C7 ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • ▪ Any separate backend application servers that process information from the web application • ▪ The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • County of Orange Page 51 of 53 MA-042-19011809 Health Care Agency File Folder No. C018820 ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • ▪ The web application (i.e., the software that interacts with users at their web County of Orange MA-042-20012181 Health Care Agency Page 57 of 65 Folder No. C025988 browsers; typically custom- crafted code created by the web development team) • ▪ The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • ▪ Any separate backend application servers that process information from the web application • ▪ The backend database systems that house information associated with the web application. • ▪ Infrastructure diagrams. • ▪ Configuration host review of settings and patch versions, etc. • ▪ Full code review. • ▪ Identification and remediation of well-known web server, code engine, and database vulnerabilities. • ▪ Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • ▪ Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • ▪ Analysis of data communications between the application and databases or other backend systems. • ▪ Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • ▪ Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • ▪ Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • ▪ Identification of areas where error handling is insufficient or reveals too much sensitive information. • County of Orange MA-042-20012181 Health Care Agency Page 58 of 65 Folder No. C025988 ▪ Identification of opportunities to write to the host file system or execute uploaded files. • ▪ Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • ▪ Determination as to whether or not fraudulent transactions or access can be performed. • ▪ Attempts to view unauthorized data, especially data that should be confidential. • ▪ Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • ▪ Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered. 19Vendor Deliverables The following items are to be provided by the vendor: ▪ OCHCA Security Requirements and Guidelines for Application Vendors and Application Service Providers - Questionnaire ▪ Business Continuity Plan Summary (as related to service provided) ▪ SSAE 18 SOC 2 Type 2 or SOC 3 compliance certificate • Network Diagram that demonstrates vendor network and application segmentation including the security controls in place to protect HCA data • IT Security Staff Usage Policy • IT Security Policies and Procedures • IT Operations Security Policy • Data Management Security Policy • Security Incident Notification and Management Process • Security Contact Identification (24x7x365) ▪ Staff Related Items County of Orange MA-042-20012181 Health Care Agency Page 59 of 65 Folder No. C025988 o Pre-Employment Screening Policy/Procedure o Background Checking Procedure o Ongoing Employment Status Validation Process o Staff Roster and Duties County of Orange MA-042-20012181 Health Care Agency Page 60 of 65 Folder No. C025988 Program Start Items Define Project Team - Exchange Information Between Teams Project managers for Contractor set expectations for tasks and timelines Identify Program area decision- makers and subject-matter experts, and make them available for the project. Review and Refine Goals of the Program Set up Lead the review, per tasks/ plans for the program Program team members engaged and participating. Provide All Forms Related to Program Incorporate into requirements Provide forms to Contractor Provide Data for Import Review and generate data map from legacy database to Contractor database Provide knowledge and documentation of, and exports of, data from current solution to provide data for conversion/import. Requirements Analysis Sessions (preferably onsite) Lead Participate Initial HS Gap Analysis and Early Requirements Documentation Document and identify proposed resolution Participate Review of Initial Analysis and Requirements Lead Participate Full Analysis and Detailed Requirements Documentation, including: • Data elements (fields) • Business rules/workflows Document Review and approve Finalization of Requirements Lead Review and approve; Serves as scope definition for final deliverable. County of Orange MA-042-20012181 Health Care Agency Page 61 of 65 Folder No. C025988 Data Dictionary - Full Set Up Responsible Review and approve Rules and Logic Additions Responsible Review and approve Printable (forms) Set Up Responsible Confirm what needs to be printed from the system at different points in the workflow. Needed Development Items (if applicable) Responsible Define, review, and approve Data Scripting and Import Responsible Review and approve, as applicable Scripted Testing of Data Dictionary/ Rules & Logic/Printed Output/ Conversion Testing covers ability to get all required elements in and out (in required formats – permits, invoices, inspections, reports), as required by County business rules/workflows Support Program Managers and subject matter experts most knowledgeable on the business processes and requirements of the program to drive test requirements. Testing scope ties back to previously approved requirements. Needed Bug Fixes/Changes Responsible Finalization of Test Scripts Lead Support Generalized Testing Support Lead Generalized Updates Responsible System Finalization Lead Support End User Training Lead All program staff, program managers and subject matter experts to attend/participate.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. • . A. Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. • . B. Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: • : A. The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted code created by the web development team) • ) B. The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) • ) C. Any separate backend application servers that process information from the web application • application D. The backend database systems that house information associated with the web application. • . E. Infrastructure diagrams. • . F. Configuration host review of settings and patch versions, etc. • . G. Full code review. • . H. Identification and remediation of well-known web server, code engine, and database vulnerabilities. • . I. Identification and remediation of any server and application administration flaws and an exploitation attempt of same. • . J. Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. • . K. Analysis of data communications between the application and databases or other backend systems. • . L. Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. • . M. Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. • . N. Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. • . O. Identification of areas where error handling is insufficient or reveals too much sensitive information. • . P. Identification of opportunities to write to the host file system or execute uploaded files. • . Q. Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. • . R. Determination as to whether or not fraudulent transactions or access can be performed. • S. Attempts to view unauthorized data, especially data that should be confidential. • T. Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. • Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.

Security Testing Recommendations. The vendor should perform a series of steps to verify the security of applications, some of which are noted below. This section will not be validated by the County, but reflects best practices that the vendor should consider and follow. 1. • Look for vulnerabilities at various layers of the target environment. In the lowest layer, the vendor’s testing team should look for flaws in the target network environment, including any routers and firewalls designed to control access to the web server and related target components. The team should attempt to determine whether such filters provide adequate protection at the network layer of the target hosts that the team can reach across the Internet. 2. • Look for flaws in the Internet-accessible hosts associated with the target infrastructure, including the web server. This host-based component of the test will analyze which network- network-accessible services are available on the target hosts across the Internet, including the web server process. The testing team should look for incorrect configuration, unpatched or enabled services, and other related problems on the target hosts. This review performed by the vendor should include but not be limited to: •  The web application (i.e., the software that interacts with users at their web browsers; typically custom- crafted code created by the web development team) •  The web server application (the underlying software that sends and receives information via HTTP and HTTPS, typically off-the-shelf software such as Microsoft’s IIS or the open-source Apache software) •  Any separate backend application servers that process information from the web application •  The backend database systems that house information associated with the web application. •  Infrastructure diagrams. •  Configuration host review of settings and patch versions, etc. •  Full code review. •  Identification and remediation of well-known web server, code engine, and database vulnerabilities. •  Identification and remediation of any server and application administration flaws and an exploitation attempt of same. •  Analysis of user interface, normal application behavior, and overall application architecture for potential security vulnerabilities. •  Analysis of data communications between the application and databases or other backend systems. •  Manual analyses of all input facilities for unexpected behavior such as SQL injection, arbitrary command execution, and unauthorized data access. •  Analyses of user and group account authentication and authorization controls to determine if they can be bypassed. •  Identification of information leakage across application boundaries, including the capability to enumerate other users’ data and “show code” weaknesses that reveal internal application logic. •  Identification of areas where error handling is insufficient or reveals too much sensitive information. •  Identification of opportunities to write to the host file system or execute uploaded files. •  Identification of product sample files, application debugging information, developer accounts or other legacy functionality that allows inappropriate access. •  Determination as to whether or not fraudulent transactions or access can be performed. •  Attempts to view unauthorized data, especially data that should be confidential. •  Examination of client-side cached files, temporary files, and other information that can yield sensitive information or be altered and re-submitted. •  Analysis of encoded and encrypted tokens, such as cookies, for weakness or the ability to be reverse engineered.