HALO Networking and Data Flow [Legal and Compliance]

This section covers the networking and data flow for all HALO products. We revisit this section upon any network changes or product introductions.

1.1 DATA FLOW:

The HALO application is a JavaScript widget that is embedded on a webpage. The source webpage and origin must be safelisted as a trusted source to enable API usage. The form is CSRF-protected and prevents all forms of XSS. Upon completion, data is encrypted over HTTPS (SSL/TLS TCP connection) via API to our servers. All APIs have been certified to prevent SQL injection and other malicious attacks via external penetration testing. Our servers are hosted on Amazon Web Services (AWS) using their auto-scalable and geo-redundant web app services and are placed behind a firewall and load balancer.

While the server runs, it is inaccessible behind AWS security measures, and SSH access is disabled. When the HALO data reaches our servers, the HALO algorithm executes. This produces output data that is partially sent back to the client browser and encrypted over HTTPS (SSL/TLS TCP connection). The output data also generates a PDF, which is emailed to the advisor. The email is encrypted in transit, provided the recipient’s email provider supports encryption.

DATA ACCESS:

We follow AWS’s best practices for using their PaaS applications, which cover server and database access. 

Only authorized HALO employees are given access to the resources required for their role, following the principle of least privilege. Authentication to access these resources is always password-based, and login credentials are always transmitted encrypted over HTTPS.

NO PHYSICAL/REMOVABLE MEDIA STORAGE DEVICES ARE ALLOWED TO CARRY SENSITIVE INFORMATION.

1.2 INFORMATION STORAGE AND CLASSIFICATION:

The only personally identifiable information maintained is the first name, last name, and email address. A coded numerical ID reference to the privacy data is stored in the Lumiant Database. This data set is stored on the AWS Aurora MySQL database service (RDS). RDS’ services have a tradition of data security that AWS Aurora MySQL database service, which upholds robust data security practices(SSL certificate connection for end-to-end encryption), including access restrictions, data protection at rest and in transit, and activity monitoring (cloud watch), with features that limit access, protect data at rest and in motion, and help monitor activity. Visit the AWS Security Documentation page for information about AWS’s platform security.

The AWS Aurora MySQL database service uses storage encryption for data at rest. This includes encryption of data, backups, logs, and snapshots. The service uses an AES 256-bit cipher for encryption, and the encryption keys are managed by the AWS Key Management System (KMS). Storage encryption is always enabled and cannot be disabled. The AWS Aurora MySQL database service is configured to require SSL/TLS connection security for data in motion across the network.

Unidentifiable HALO assessment data is retained indefinitely, while personally identifiable data is stored separately and can be purged at the customer’s request. Compliance with the General Data  Protection Regulation (GDPR) is maintained.

1.3 DISASTER RECOVERY, BACKUP AND DATA RETENTION POLICY

AWS Aurora MySQL database service (RDS) leverages AWS Storage replication to ensure durability and high availability. We perform a snapshot of the RDS database daily, which we can export to an S3 bucket or restore a database at a particular time.

To ensure business continuity, We perform daily database snapshots. We can either restore the database or export the data to an S3 bucket. Typically, these snapshots are retained for slightly more than 35 days. For more information, please visit Amazon RDS Backup & Restore | Cloud Relational Database | Amazon Web Services.

Our servers are hosted on Amazon Web Services using their web app services. Utilizing AWS’s web app services takes advantage of flexible scalability and guaranteed availability, allowing our server application to be instantiated on the fly for recovery or scalability purposes.

Our database's primary location is AWS's US East region (N. Virginia).