HALO Networking and Data Flow [Legal and Compliance]
This section covers the networking and data flow for all HALO products. This section must be revisited 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 whitelisted as a trusted source to enable API usage. The form is CSRF protected and
prevents all forms of XSS. Upon completion, data is sent encrypted over HTTPS (SSL/TLS TCP
connection) via API to our servers. All API’s have been certified to prevent SQL injection and other
malicious attacks via external penetration testing. Our servers are hosted on Microsoft Azure using their
auto-scalable and geo redundant web app services and is placed behind a firewall and load balancer.
While the server is running it is inaccessible behind Microsoft Azure security measures, and SSH access
is disabled. When the HALO data reaches our servers, the HALO algorithm is executed. This produces
output data that is partially sent back to the client browser, encrypted over HTTPS (SSL/TLS TCP
connection). The output data is also used to generate a PDF which is then emailed to the advisor. The
email is encrypted in transit provided the recipient’s email provider supports encryption.
origin must be whitelisted as a trusted source to enable API usage. The form is CSRF protected and
prevents all forms of XSS. Upon completion, data is sent encrypted over HTTPS (SSL/TLS TCP
connection) via API to our servers. All API’s have been certified to prevent SQL injection and other
malicious attacks via external penetration testing. Our servers are hosted on Microsoft Azure using their
auto-scalable and geo redundant web app services and is placed behind a firewall and load balancer.
While the server is running it is inaccessible behind Microsoft Azure security measures, and SSH access
is disabled. When the HALO data reaches our servers, the HALO algorithm is executed. This produces
output data that is partially sent back to the client browser, encrypted over HTTPS (SSL/TLS TCP
connection). The output data is also used to generate a PDF which is then emailed to the advisor. The
email is encrypted in transit provided the recipient’s email provider supports encryption.
Data Access:
We follow Microsoft best practices for usage of their PaaS applications. This covers both server and database access.
We follow Microsoft best practices for usage of their PaaS applications. This covers both server and database access.
We also provide an advisor portal which allows the ability for each advisor to review their own client’s
individual HALO reports and various overall statistics. The advisor portal is accessed via username and password, and follows the same data flow security measures mentioned above where data is encrypted
in flight over HTTPS. Passwords are stored hashed and never logged, stored or transmitted as plain text.
Only authorized HALO employees are given access to the resources that are required for their role,
following the principle of least privilege. Authentication to access these resources is always
passwordbased and login credentials are always transmitted encrypted, over https.
individual HALO reports and various overall statistics. The advisor portal is accessed via username and password, and follows the same data flow security measures mentioned above where data is encrypted
in flight over HTTPS. Passwords are stored hashed and never logged, stored or transmitted as plain text.
Only authorized HALO employees are given access to the resources that are required for their role,
following the principle of least privilege. Authentication to access these resources is always
passwordbased and login credentials are always transmitted encrypted, over https.
NO PHYSICAL/REMOVABLE MEDIASTORAGE DEVICES ARE ALLOWED TO CARRY SENSITIVE
INFORMATION.
1.2 INFORMATION STORAGE AND CLASSIFICATION:
The only personally identifiable information that is maintained is first name, last name and email address.
This information is stored separately in a different database and database server than the rest of the
behavioral and health data obtained (Figure 1 Items 3 and 4). The privacy information per client is stored
in the PII Database shown above. A coded numerical id reference to the privacy data is then stored in the
HALO Database. Storage of both sets of data are on the Azure Database for MySQL service. Azure
database services have a tradition of data security that Azure Database for MySQL upholds, with features
that limit access, protect data at-rest and in-motion, and help you monitor activity. Visit the Azure Trust
Center for information about Azure's platform security.
This information is stored separately in a different database and database server than the rest of the
behavioral and health data obtained (Figure 1 Items 3 and 4). The privacy information per client is stored
in the PII Database shown above. A coded numerical id reference to the privacy data is then stored in the
HALO Database. Storage of both sets of data are on the Azure Database for MySQL service. Azure
database services have a tradition of data security that Azure Database for MySQL upholds, with features
that limit access, protect data at-rest and in-motion, and help you monitor activity. Visit the Azure Trust
Center for information about Azure's platform security.
The Azure Database for MySQL service uses storage encryption for data at-rest. Data, including
backups, are encrypted on disk. The service uses AES 256-bit cipher that is included in Azure storage
encryption, and the keys are system managed. Storage encryption is always on and cannot be disabled.
The Azure Database for MySQL service is configured to require SSL connection security for data
inmotion across the network.
Unidentifiable HALO assessment data is retained indefinitely, while personally identifiable data is stored
separately and can be purged at customer’s request. GDPR compliance is maintained.
1.3 DISASTER RECOVER, BACKUP AND DATA RETENTION POLICY
Azure Database for MySQL leverages Azure Storage replication to ensure durability and high available.
The redundant storage replicates your data three times. A write request returns successfully only once it
has been written to all three replicas. These three replicas each reside in separate fault domains.
The redundant storage replicates your data three times. A write request returns successfully only once it
has been written to all three replicas. These three replicas each reside in separate fault domains.
To ensure business continuity, Azure Database for MySQL automatically performs a combination of full
database backups daily, differential database backups hourly. These backups are stored in georedundant
storage for 35 days. For geo-redundant storage, please refer to
https://docs.microsoft.com/enus/azure/storage/storage-redundancy#read-access-geo-redundant-storage
Our servers are hosted on Microsoft Azure using their web app services. Utilization of Azure 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 the North Central US region of Microsoft Azure, the secondary Geo
redundant backup is in the South Central US region. Our server's primary location is in their US Central
region with the secondary Geo redundant backup in their US East 2 region.