System Capacity

Performance Monitoring

Backup Policy

Data Retention

Service Level Agreements / UpTime

Aurora - Amazon Aurora Service Level Agreement - AWS will use commercially reasonable efforts to make each Included Service available for each AWS region with a Monthly Uptime Percentage of at least 99.99%,

Noted Exclusion: The Service Commitment does not apply to any unavailability, suspension or termination of Amazon Aurora, or any other Amazon Aurora performance issues, directly or indirectly : (i) caused by factors outside of our reasonable control, including any force majeure event or Internet access or related problems beyond the demarcation point of Amazon Aurora; (ii) that result from any voluntary actions or inactions from you; (iii) that result from instances belonging to the Micro DB instance class or other instance classes which have similar CPU and memory resource limitations; (iv) that result from you not following the basic operational guidelines described in the Amazon Aurora User Guide (e.g., overloading a database instance to the point it is inoperable, creating an excessively large number of tables that significantly increases the recovery time, etc.); (v) caused by underlying database engine software that leads to repeated database crashes or an inoperable database instance; (vi) that result in long recovery time due to insufficient IO capacity for your database workload; (vii) that result from your equipment, software or other technology; or (viii) arising from our suspension or termination of your right to use Amazon Aurora in accordance with the Agreement (collectively, the "Amazon Aurora SLA Exclusions").

If availability is impacted by factors other than those explicitly used in our Monthly Uptime Percentage or Single-AZ Uptime Percentage calculation, as applicable, then we may issue a Service Credit considering such factors at our discretion.

Elastic Container Service (Fargate) - Amazon Elastic Container Service (Amazon ECS) and AWS Fargate SLA - AWS will use commercially reasonable efforts to make each Included Service available for each AWS region with a Monthly Uptime Percentage of at least 99.99%,

Elastic Load Balancer (ELB) - Amazon Elastic Load Balancing Service Level Agreement - AWS will use commercially reasonable efforts to make each Load Balancer available with a Monthly Uptime Percentage of at least 99.99%,

Noted Exclusions: The Service Commitment does not apply to any unavailability, suspension, or termination of Elastic Load Balancing, or any Load Balancer performance issues: (i) caused by factors outside of our reasonable control, including any force majeure event or Internet access or related problems beyond the demarcation point of Elastic Load Balancing; (ii) that result from any voluntary actions or inactions from you or any third party (e.g. misconfiguring security groups, VPC configurations or credential settings, disabling encryption keys or making the encryption keys inaccessible, etc.); (iii) that result from your equipment, software or other technology and/or third-party equipment, software or other technology (other than third party equipment within our direct control); (iv) that result from you not following the guidelines described in the Elastic Load Balancing User Guide on the AWS Site; or (v) arising from our suspension or termination of your right to use Elastic Load Balancing in accordance with the Agreement (collectively, the “Elastic Load Balancing SLA Exclusions”). If availability is impacted by factors other than those used in our Monthly Uptime Percentage calculation, then we may issue a Service Credit considering such factors at our discretion

Common Vulnerabilities and Exposures (CVE)

Amazon ECR image scanning helps in identifying software vulnerabilities in container images. Amazon ECR provides scanning which uses the Common Vulnerabilities and Exposures (CVEs) database from the open-source Clair project. Scanning will be enabled on the private registry where the GAIHN-HAI image resides. APHL will provide an ongoing scan and report findings to application developers on at least a quarterly basis.

Amazon ECR uses the severity for a CVE from the upstream distribution source if available or uses the Common Vulnerability Scoring System (CVSS) score. The CVSS score can be used to obtain the NVD vulnerability severity rating.

Dynamic Application Security Testing (DAST)

A dynamic analysis security testing tool, or a DAST test, will be performed against the GAIHN-HAI project to find certain vulnerabilities in the web applications while it is running. A DAST test will use the same techniques that an attacker would use to find potential weaknesses in an application.

A DAST test can look for a broad range of vulnerabilities which include input/output validation issues that could leave an application vulnerable to cross-site scripting or SQL injection. A DAST test can also help spot configuration mistakes and errors and identify other specific problems with applications. APHL will provide an ongoing scan and report findings to application developers on at least a quarterly basis.

Data Classification

The GAIHN-HAI data set will be classified as sensitive information; however, is not considered to be protected health information (PHI) as the Health Insurance Portability and Accountability Act does not apply to data sets outside of the United States.

Incident Response

In the event of a security incident, APHL will follow the incident response plan. APHL will act in accordance with the steps of the incident response plan which include:

Alert Phase - The alert phase is the process of learning about a potential security incident and reporting it to generate a helpdesk incident ticket. Alerts may arrive from a variety of sources including monitoring of firewalls and intrusion detection systems, anti-virus software, threats received via e-mail, and media reports about new threats. The AIMS Service Desk may also directly generate incident tracking tickets while managing potential incidents.

Triage Phase - The triage phase involves the process of examining the information available about the situation to determine whether or not a security incident has occurred. If an incident has occurred, the nature of the incident is determined, the initial priority level is assigned and the documentation of all actions taken is initiated. This phase will also involve creating an Incident Response Team (IRT) to work on activities relating to incident handling. A decision to “pursue” or “protect” is made during this phase according to the sensitivity of the data and the criticality of the operational system.

Response (Containment and Eradication) Phase - The response phase is the process of limiting the scope and magnitude of an incident in order to keep the incident from getting worse. Consideration is given to factors such as system backup, the risk of continuing operations, and changing passwords or access control lists on compromised systems and data. This phase also involves determining the cause of the incident, improving system defenses, determining system vulnerabilities, and removing the cause of the incident, using the security operations procedure, to eliminate the possibility of recurrence. It may be necessary to activate the Contingency plan. The AIMS Platform Business Steward would make this determination.

Recovery Phase - The system and business process returns to full and normal operations during this phase. Actions include restoring and validating the system, deciding when to restore operations, and monitoring systems to verify normal operations without further system or data compromise.

Follow-up Phase - This phase involves developing an incident report and disseminating it to appropriate entities according to established policies; identifying lessons learned from the incident handling process including the successful and unsuccessful actions taken in response to an incident; and developing recommendations to prevent future incidents and to improve enterprise security implementation.

Application test completion criteria

Production Integration Testing

User acceptance testing (UAT)

User acceptance testing is performed to assess user interface and user experience (UI/UX), functionality, workflow, data capture, and performance of the application. An initial UAT was performed in August 2023 using scenarios to input responses to each data collection field, including Country, Facility, Ward, and all patient forms. Feedback was also received on the usability and experience of the tester. Testing was performed primarily by the CDC GAIHN-HAI team. Results were captured and collated to address any bugs and suggested changes to the user experience, workflow and performance of the application.

Data structure and confirmation of data captured

do we need documentation of the data structure. data export, CSV, and confirmation of the data captured… example in comparison to Red Cap or paper data collection forms.

Training documentation for users and application support has been completed and distributed per training communication plan

Designated staff has received training and has demonstrated required competency

Helpdesk for application support documentation has been completed and distributed

Helpdesk for application support has received training and has demonstrated required competency

Helpdesk for host support (AIMS) has been completed and distributed

Helpdesk for AIMS support staff has received training and has demonstrated required competency