Introduction

Security is an essential part of infrastructure design, application development processes, and support. This document provides an overview of our 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

The application 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. Further information regarding our approach to business continuity and disaster recovery are in this article:

Business Continuity and Disaster Recovery

Access Controls

All customer PROD MAIN superadmin support accounts are protected via MFA. Reviews of superadmin support accounts across all customer PROD MAIN instances are conducted on a quarterly basis.

Engineering access to hosting infrastructure requires MFA. Access for individuals is continuously monitored by our compliance monitoring platform (Drata) which is linked to IQVIA Human Resources and authorisation systems to verify that access is restricted to current team members.

Security Testing

Application Security Scanning

We use Detectify to perform OWASP 10 security scanning against each functional release build. The results of these scans are recorded and made available in the release Technical File.

Vulnerability scanning

We use intruder.io to perform monthly scheduled vulnerability scans on a representative set of application instances. The application engineering team receives notifications on any findings for follow up. intruder.io also performs proactive scans for emerging threat scans’ on an ad-hoc basis, and sends summaries to the engineering team for review. Scans of this tooling on specific PROD MAIN customer environments are only available upon request, coordinated via service desk ticket.

Manual Penetration Testing

On a yearly basis the ClinSpark web application, supporting applications (such as SparkPlug), and certain infrastructure components are subjected to manual penetration testing , conducted by an external vendor. The testing takes place in a controlled environment setting created specifically for purpose. Penetration testing is not performed on any customer environments or environments that contain sensitive data.

A summary of findings from the pentest vendor is produced and reviewed by the product team. Findings are summarized into four classifications that are aligned with the OWASP Risk Rating Methodology. We take review and action based on the classifications.

...

Security Code Reviews - SDLC

Application 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 release Technical File.

Secure Coding Practices Best Practices

Application development 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.

Security Incident Customer Notification Policy

In the event of a security breach, prompt corrective action is taken 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 application instances are hosted within an IQVIA AWS account.

Infrastructure as Code

Infrastructure as Code is used for build-outs of PROD Main 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

Datadog is our primary observability platform, providing security monitoring and investigation capabilities. In addition, 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 internal communication tooling for real-time notifications of security events.

Logging

Application Logs are centrally stored in AWS CloudWatch Datadog . VPC Flow Logs are stored in S3 to support investigation of security incidents as required.

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 Managerour Infrastructure as Code platforms.

Malware

The application 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.

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 Defense

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 defense 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 Defense

The second line of defense 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.

In the event that both the Primary and Secondary databases go down, RDS will automatically provision replacements and swap them in within 15 minutes.  In addition, new instances could be manually created anywhere in the AWS cloud. These instances can be loaded with the snapshots stored in S3. This scenario does cause an interruption in service, and manual intervention. It is highly unlikely, given the high platform availability of a Multi Availability Zone deployment. However should it occur, IQVIA would follow the procedure for building an environment in another region or Availability Zone, restore the data using the previously referenced procedure, and restore service using the new instances.Due to the backup processes described above, the Engineering team does not formally test restore procedures.

Application Development and Support Staff

User Workstations

User workstations are provided by 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

Support ('superadministratorSuperadmin') access to customer environments is reviewed and documented quarterly.

Engineering access to the hosting infrastructure is reviewed periodically by management.

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

Our core workgroup business systems are externally hosted SaaS applications, managed by the respective vendor. Our corporate network, mail and file services are provided by IQVIA, and require VPN access, or similarly secure managed access, when remote working.