...
Security is a key part of Foundry Health infrastructure design, application development processes and support. This document provides an overview of Foundry Health security measures and processes.
Data Protection and Privacy
Encryption in Transit and at Rest
Production instances are configured to exclusively use TLS 1.2 SSL security for data in flight. This leverages AWS infrastructure capabilities at the load balancer.
All customer data resides in AWS RDS Aurora configured with AES-256 encryption, with keys managed by AWS KMS. Extensive documentation of RDS encryption at rest can be found on AWS Documentation.
Data Location
All customer data is stored within AWS RDS Aurora Multiple Availability Zone instances in the region hosting the customer instance. Currently supported customer AWS Regions are Virginia and Ireland. Real-time offsite backups are in place, and extensive documentation about this is available via AWS RDS Documentation.
Note that AWS RDS policies and mechanisms for physical and environmental security, media disposal and backup procedures are audited on a periodic basis. AWS SOC audit reports are available for customer review upon request.
Business Continuity
ClinSpark was designed to be inherently resilient and to maximize availability and to minimize downtime. Much of this resilience is owed to the hosting infrastructure, the Amazon Web Services (AWS)cloud. The design requirements that determine this level of resilience are specified in the Infrastructure Architecture document and to a lesser degree in the ClinSpark Application Architecture document. These documents are updated and revised from time to time as required and are available to customers upon request. ClinSpark is designed to:
Maintain high availability –single points of failure are eliminated
Have high fault tolerance –application and database servers fail. Service to the customer must not be interrupted and recovery time must be quick
Survive a full datacenter disaster without data loss or significant inconvenience to a customer
Testing
Recovery following a full data center disaster is designed to be automatic and transparent.
...
To simulate this disaster scenario, each layer of the infrastructure within a single AWS Availability Zone (AZ) (equivalent to a data center) is forcibly brought down. This is done in two separate exercises. The first targets the Elastic Beanstalk application server layer. The second targets the RDS database master. In both cases, the stimulus is a forced failure of all resources within an AZ. The verification is an observation of how the infrastructure responds automatically. The system is expected to recover within the expected timeframe, with no support intervention. See also https://foundryhealth.atlassian.net/wiki/spaces/DOCS/pages/3708420496/ClinSpark+Application+SLA?src=search.
Testing occurs annually.
Access Controls
Starting with ClinSpark 1.5, all customer PROD Main superadmin support accounts are protected via MFA.
Engineering access to hosting infrastructure requires MFA.
Security Testing
Application Security Scanning
We use Detectify to perform OWASP 10 security scanning for each ClinSpark release. The results are available in the Technical File.
Vulnerability scanning
We use intruder.io to perform monthly scheduled vulnerability scans on a representative set of ClinSpark instances. intruder.io also performs proactive scans for emerging threat scans’ on an ad-hoc basis.
Manual Penetration Testing
On a yearly basis ClinSpark is subjected to manual penetration testing. We use industry leading Cobolt.io for this service. A summary of findings is available for customer review upon request.
Security Code Reviews - SDLC
ClinSpark enhancement tickets are categorized by security risk, and appropriate reviews are conducted as part of our SDLC process. Evidence of this is provided in the Technical File.
Secure Coding Practices Best Practices
Foundry Health engineers adhere to actively maintained best practices for secure coding. Details of our standards and our internal review process are available upon request.
Security Incident Response
Infrastructure has been configured to enable automated incident alerting and rapid tool-assisted investigation. A formal policy and set of procedures is in development.
Security Incident Customer Notification Policy
In the event of a security breach, Foundry Health will take prompt corrective action to cure any such deficiencies, and any action pertaining to such unauthorized PHI disclosure required by applicable laws and regulations. We will notify the customer within one business day of our becoming aware of the event.
AWS Hosting Infrastructure
All ClinSpark instances are hosted within Foundry Health’s AWS account.
Infrastructure as Code
Infrastructure as Code is used for build-outs of PROD Main ClinSpark instances. This ensures that key configurations such as TLS levels, load balancer settings, patching configurations and other security-related configurations are applied in a repeatable and secure fashion.
Centralized Security Infrastructure Monitoring
AWS Security Hub is configured to monitor and alert upon a wide variety of infrastructure security aspects. AWS GuardDuty provides active AI-driven real-time intrusion detection. AWS Macie constantly monitors the environment for PHI leaks or unusual privileged activity in AWS CloudTrail, which audits all AWS user activity. AWS Detective provides tool-assisted investigation capabilities for rapid root-cause analysis of potential security issues.
Alerting is configured to the Foundry Health Slack channel for real-time notifications of security events.
Standard Managed Web Application Firewall
Customer PROD Main instances are protected by the AWS Managed Ruleset provided by Fortinet and include the ‘Complete OWASP Top 10’ by default.
Automated Security Patching
All server instances receive regular and automated security and bug-fix patching. This is done using AWS Patch Manager.
Malware
ClinSpark is deployed to an Amazon Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2).
As these Linux images are hardened, continuously and automatically patched, unreachable without an SSH connection and protected by a firewall, no additional anti-malware measures are installed.
Logging
Application Logs are centrally stored in AWS CloudWatch. VPC Flow Logs are stored in S3 to support investigation of security incidents as required.
Backup
All customer data is stored in AWS RDS instances. Application servers do not store any customer data, only configuration. As such this topic is limited in scope to how RDS supports backups and recovery.
First Line of Defence
RDS is by design a service providing the highest level of data backups. All customer PROD instances use RDS instances in a Multiple Availability Zone configuration. The relevant components are shown in this diagram:
...
Application server instances interact with the RDS Master instance at all times. However each transaction synchronously updates the underlying physical storage, which in Aurora is striped across 3 separate physical Availability Zones. This replication forms the primary line of defence for backups. There is always a complete copy of the application database ready in a separate physical location. When a failure of any sort occurs to the Primary database, the infrastructure automatically shifts all application traffic to the Standby, which is now promoted to the role of Master with no loss of data.
Second Line of Defence
The second line of defence is snapshots stored in Amazon S3 storage. Database transactions produce records in logs. These records are comprehensive. These logs are streamed continuously to S3. As documented by Amazon, this stream of backup data is sufficient to restore a completely new replacement instance of the database to a point in time of within 5 minutes of when a disaster occurred. S3 storage is configured to itself be backed up across separate geographic regions.
Collectively, this means that all customer data is backed up in real time to two physically separate databases in 3 physical datacenter locations, with automated failover. In addition, all customer data is stored in separate offsite storage to within a 5 minute window.
Restore
In the event that the Primary database fails, the Standby instance is automatically promoted to Master. This is handled transparently and automatically. There will be an interruption of inflight transactions when the Master goes down. However the system automatically recovers, and the restore procedure is handled without human intervention.
...
Due to the backup processes described above, the Engineering team does not formally test restore procedures.
Foundry Health Staff
User Workstations
User workstations are provided by our parent company, IQVIA. These machines are fully managed and monitored and equipped with regularly updated anti-malware measures.
Bring Your Own Device (BYOD) Policy
Some BYOD workstations may be used for development and support purposes and are monitored by Kolide for endpoint security. This provides visibility into our requirements for security patching, anti-malware measures, use of an approved password manager, hard drive encryption and other security configurations appropriate for the specific workstation. Violation notifications and a review process are in place.
Periodic Review of Access Privileges
Engineering access to the hosting infrastructure is reviewed periodically by management. Support access to customer environments is managed periodically by management as well.
Periodic Security Training
All staff is periodically trained on security policies including data handling, and security topics such as recognizing social engineering. Evidence is available for review upon request.
Corporate Network
Foundry Health’s core business systems are externally hosted SaaS applications, managed by the respective vendor. Our corporate network, mail and file services are provided by our parent company, IQVIA, and require VPN access when remote working.
...