DATA SECURITY POLICY IN BRIEF
Curitics Health Solutions Inc (“Curitics”) offers a healthcare workflow automation platform that is transforming population health and patient engagement space. We are committed to safeguarding the confidential information we receive from our clients by utilizing strict standards and policies.
DEFINITION OF ROLES
- Client — A customer of Curitics
- User — An individual with access to the Curitics Health platform
- Data Providers — A vendor that provides data sets (Clinical and Non-Clinical in scope)
- Software Developer — An individual who engages in identifying, designing, installing and testing any of Curitics’s software and applications
- Staff – any individual who is an employee or contractor of Curitics
CLOUD ACCESS CONTROL ENTITY
When electronically accessing Curitics resources, authorized personnel are required to use two-factor authentication for identity verification.
DATA ACCESS AND SERVER MANAGEMENT SECURITY
Curitics follows a principle of least privilege policy when granting electronic access to Curitics resources. When electronically accessing the data center, authorized personnel are required to use two-factor authentication for identity verification.
DATA STORAGE AND BACKUPS
Curitics safeguards all customer data using encryption at rest. Curitics cloud services use AWS (Amazon Web Services) Managed Disks with Storage Service Encryption (SSE) to store all customer text, video and audio. Customer metadata, such as licensing information, user accounts, etc., are stored in SQL & Redshift Server databases utilizing AWS encryption. These AWS services implement AES 256-bit encryption to ensure the highest level of protection for data at rest. Back-ups are made daily and stored indefinitely. Back-ups can be restored on demand to aid in any disaster recovery scenario.
CLIENT DATA POLICIES
Client data includes data stored by Clients in Curitics platforms, information about a client’s usage of the application, data instances in the Customer Relationship Management system to which we have access, or data that the Client has supplied to us for support or implementation. When managing Client Data, we take into account the following considerations:
- Client Data is not to be disclosed outside of Curitics, except to the Client who owns the data or to a partner who has been contracted by the Client to manage or support their account
- Client Data should only be accessed on a need-to-know basis. Specifically, a client’s account should only be accessed to provide support, troubleshoot a problem with that account, or for supporting the system as a whole
- Client Data should never be changed without the explicit permission of the Client, except for the need to address and repair data quality issues
DISPOSAL OF COMPUTERS AND OTHER DATA
Old computers and servers are decommissioned following Curitics’s System decommissioning and destruction policy. Paper information in the office is discarded using a document shredder or a commercial secure document shredding service. Curitics also adheres to a clear desk/clear screen policy.
INCIDENT RESPONSE
Curitics maintains an incident response policy that covers detection, containment, remediation recovery and closeout of an incident.
Once an incident is reported, security administrators will immediately begin verifying that an incident occurred and the nature of the incident with the following goals:
- Maintain or restore business continuity
- Reduce the incident impact
- Determine how the attack was performed or the incident happened
- Develop a plan to improve security and prevent future attacks or incidents
- Keep management informed of the situation and prosecute any illegal activity
APPLICATION SECURITY
All data transfer and access to Curitics applications will occur only on Port 443 over an HTTPS connection using at least TLSv1.2 cryptographic protocols with AES-256 encryption. Additionally, Curitics products support the ability to be “white-listed” whereby access to the software may only occur over pre-configured IP addresses.
SYSTEM UPDATES AND SECURITY PATCHES
As a hosted SaaS solution, we regularly improve our system and update security patches. No Client resources are needed to perform these updates. Non-critical system updates will be installed at predetermined times. Critical application updates are performed ad hoc using rolling deployment to maximize system performance and minimize disruption. All updates and patches will be evaluated in a virtual production environment before implementing.
VULNERABILITY AND SECURITY TESTING
Curitics’s Security Managed Services Provider, Hosted Scan, provides regularly scheduled vulnerability scans and assessments to ensure the Curitics Applications and Production environment is free of vulnerabilities. Vulnerability scanning occurs on a monthly basis or more frequently as determined by release cadence.
USERS LOGIN AND SESSION SECURITY
Users will be provisioned into security user groups for access to the application. All user provisioned Curitics applications utilize an automated session expiration feature if the application is idle for a given period of time. For HIPAA security purposes, this timeout is defaulted to 15 minutes.
PASSWORD MANAGEMENT
All Curitics’s passwords must have at least eight (8) characters with at least one number, one lowercase letter, one uppercase letter and one special character.
PHI HANDLING POLICY
All Curitics staff are made aware of relevant external regulations as part of their onboarding and training process, and all staff who may encounter PHI are trained on our PHI handling processes.
Curitics ingests data sets from Data Providers and anonymizes PHI automatically as part of the ingestion process where de-identified data is ultimately stored for application use. As part of the ingestion process Identified data is stored in a separate database (in line with Curitics’s Data retention and access policy as allowed by the Data Providers contract) for use in authorized purposes. Under no circumstances should identified data be added to the company dataset library. Any identifiable data within the Curitics system is stored in a separate and secured database. All PHI data is encrypted at rest and in transit.
Curitics expects professional integrity of our collaborators, Clients and partners providing PHI to us and will assume that they have obtained the client or data provider’s consent to use their data in this way.
Where a Business Associate Agreement or similar contract relating to PHI is in place, Curitics staff work under the terms of that agreement. Where no such agreement exists, the Curitics PHI handling policy and process are followed.
Curitics conducts periodic internal audits on compliance with this policy.
ANSWERS TO COMMON SECURITY QUESTIONS
| Category | Question | Answer |
| Security | Can the solution support management of encryption keys for data? (Commonly referred to Bring Your Own Key (BYOK)) | Yes, our preferred approach is to leverage PGP keys such that data is encrypted using the clients key and decrypted using a provided public key |
| Application | Are you sharing the run-time version of the solution with other clients? If yes please describe the approach. | No |
| Application | Does the solution leverage any shared software components based on service-oriented architecture principles? | No, each client instance of Curitics is on separate infrastructure |
| Application | Does the solution use any reusable software libraries and frameworks (commercial, open-source, custom)? | Yes |
| Application | Please provide details. | Application front-end leverages Angular, API layer and backend leverages .NET Framework additionally several serverless technologies are used to support Curitics microservices |
| Interfaces (user) | What is the solutions minimum Internet browser requirements? | Edge Browser, Chrome 80+ |
| Application | Does your solution provide a mechanism to prevent co-mingling of data with other client data? | Yes |
| Application | Please describe mechanism(s) utilized to prevent co-mingling of data with other client data | Data from each client is loaded to a unique database instance with client-level identification |
| Security | Are IDS signatures kept current with manufacturer releases? | Yes |
| Security | What encryption methods do you support for protecting data at rest (e.g. PGP, disk level, file level, or database level encryption etc.)? Please describe all that apply including algorithms and key length. | System utilized TLS 1.2 for data in transit. PGP Private/Public keys employed for data submissions (SHA512). Database servers encrypted, AES-256 encryption utilized. Backups also encrypted using AES-256 |
| Security | Are all encryption methods used in the solution FIPS 140-2 compliant? | Yes |
| Security | Please describe authentication data repository used by the solution (e.g. LDAP directory, Active Directory, relational database, flat file, proprietary)? | Application access utilizes two-factor auth with OTP code. Can also be configured to utilize client IDP via SSO. Database endpoint access restricted utilizing VPN and IP based whitelisting |
| Open Source | Does the solution utilize any Open Source Software (OSS) products? | Yes |
| Development Process | Please describe how you test solution enhancements prior to release to production. | Curitics Health is dedicated to providing security both at an infrastructure level as well as through programming best practices within our front-end applications. As part of our standard enhancement and version release process, the code base undergoes rigorous scrutiny including but not limited to: • Peer review of code additions • Merge control whereby only senior technical resources within the organization have the ability to merge code to production instances – and only once an additional round of code review has taken place. As an organization, Curitics has adopted the OWASP Code Review Guide for best practices during all code reviews. These guidelines set forth standards around code management, review and release to ensure common vulnerabilities are not inadvertently added to the code base. |
| Development Process | Is input validation performed using a whitelist approach? | Yes |
| Development Process | Are uploaded files validated for the expected type by checking file headers? | Yes |
| Security | Do you conduct penetration testing on the solution? | Yes, vulnerability scanning is conducted monthly |
| Security | Are penetration testing efforts completed by an accredited 3rd party? | Yes |
| Security | Are penetration testing efforts completed on a minimum of yearly basis? | Yes |
| Security | Please provide status on remediation efforts for high and medium level findings from latest penetration testing completed. | No current high or medium level findings |