The Capital Health Minimum Security Standards have been created and shared to outline information security requirements that all devices, vendors, partners, etc. must adhere to in order to be onboarded at Capital Health. Compliance with these standards must be validated before any contract can be signed between a vendor and Capital Health. If a vendor or partner cannot adhere to the standards below, Capital Health reserves the right to review on a case-by-case basis or reject the submission.
If a vendor cannot adhere to the below standards, Capital Health Information Security reserves the right to review on a case-by-case basis. Most submissions will be rejected if they cannot comply with the minimum-security standards below.
IoT & IoMT Services
OnPrem Services
SaaS Services
Vendor-Supported Platforms
Minimum Security Standards: IoT & IoMT Services
Regulatory
Security documentation for one or more of the following:
At least one of the following 3rd-party attestations of security baselines such as:
- SOC-2 Type 2
- HITRUST
- NIST CSF
- ISO-27001 compliance
All SaaS platforms must abide by the local, state, and federal regulatory controls as dictated by data type they are handling. Ex: HIPAA/HITECH, PCI DSS, SOX, etc.
User Accounts
Default passwords are prohibited. The use of guest accounts, service accounts, or any account type where the password might be shared requires pre-approval from the Capital Health Information Security Team. Administrative (privileged) accounts require protection via the use of a Privileged Account Management (PAM) system. All account passwords must have a minimum of 16 characters. For administrative accounts, password rotation must be enforced for all passwords with less than 32 characters.
PHI Data Protections
PHI/PII/PCI data needs to have the following security measures in place:
- Minimum of TLS 1.2 encryption in transit.
- Minimum of AES-265 encryption at rest.
- Defined and documented data retention and destruction processes.
- Data access tracking enabled with logging.
- Role-based access controls (RBAC) enabled.
- Least-Privilege model enabled.
- Privileged-access logging enabled.
- Minimum of quarterly access reviews.
- Secure encryption key management.
- Logical tenant segregation.
Authentication
Customer-supported Microsoft Azure AD federation and management. The application must also demonstrate strong MFA, as well as vendor-driven account termination for any vendor-managed accounts, processed within 24 hours of receipt of an Capital Health-provided termination list.
Perimeter Defense
All SaaS platforms must be protected by a perimeter defense mechanism, including but not limited to, stateful packet firewall, intrusion detection system (IDS), intrusion prevention system (IPS), web application firewall (WAF), Distributed Denial of Service (DDoS) mitigation appliance/service, et al.
EoL Software Support
End-of-life (EoL) and end-of-support (EoS) operating systems are prohibited. EoL operating systems without appropriate Long Term Support (LTS) are prohibited. Any use of software which does not include a support model is prohibited.
Trusted Certificates
All platforms with exposure to publicly accessible untrusted networks (i.e. the Internet) must use a minimum extended validation (EV) certificate from a publicly trusted certificate authority (CA), which is listed on the CAB Forum at https://cabforum.org/members.
Vulnerability Scanning
All platforms with exposure to publicly accessible untrusted networks (i.e. the Internet) must be scanned at a minimum of two-week intervals. When systems cannot be scanned at two-week intervals, one of the following must be provided:
- Attestation showing completion of annual penetration test, redactions as required.
- Attestation of monthly external scanning
- Pre-production code review for all major updates, static or dynamic code reviews.
Patching
All systems must have regular patching updates applied to them based on CVSS score.
Incident Response & DR/BC
Documented incident response plan must be in place. Breach notification within 24-72 hours agreed upon in contracts. Root cause report provided to Customer upon request. Documented DR/BC plan must be in place. Documented annual DR testing to be conducted.
Security Testing
An annual third-party penetration test report is required for all SaaS service providers. The report may be from a third-party firm of the vendor's choosing.
User Accounts & Log Export
All platforms and their component systems must have the ability to export logs. Including, but not limited to: users accounts including privilege user accounts, authentication, authorization, and access controls.
Third-Party & Contractual Safeguards
Business Associated Agreement (BAA) must be agreed upon and signed for all SaaS vendors that process, store, handle, or transmit PHI, PII, PCI, or other sensitive data. Cyber liability insurance carried. Subprocessor/Subcontractor list maintained. Contractually defined that security obligations flow to subprocessors or subcontractors. Right to audit clause defined. Data return or data destruction upon contract termination defined.
Minimum Security Standards: OnPrem Services
Regulatory
Security documentation for one or more of the following:
At least one of the following 3rd-party attestations of security baselines such as:
- SOC-2 Type 2
- HITRUST
- NIST CSF
- ISO-27001 compliance
All SaaS platforms must abide by the local, state, and federal regulatory controls as dictated by data type they are handling. Ex: HIPAA/HITECH, PCI DSS, SOX, etc.
User Accounts
Default passwords are prohibited. The use of guest accounts, service accounts, or any account type where the password might be shared requires pre-approval from the Capital Health Information Security Team. Administrative (privileged) accounts require protection via the use of a Privileged Account Management (PAM) system. All account passwords must have a minimum of 16 characters. For administrative accounts, password rotation must be enforced for all passwords with less than 32 characters.
PHI Data Protections
PHI/PII/PCI data needs to have the following security measures in place:
- Minimum of TLS 1.2 encryption in transit.
- Minimum of AES-265 encryption at rest.
- Defined and documented data retention and destruction processes.
- Data access tracking enabled with logging.
- Role-based access controls (RBAC) enabled.
- Least-Privilege model enabled.
- Privileged-access logging enabled.
- Minimum of quarterly access reviews.
- Secure encryption key management.
- Logical tenant segregation.
Authentication
Customer-supported Microsoft Azure AD federation and management. The application must also demonstrate strong MFA, as well as vendor-driven account termination for any vendor-managed accounts, processed within 24 hours of receipt of an Capital Health-provided termination list.
Perimeter Defense
All SaaS platforms must be protected by a perimeter defense mechanism, including but not limited to, stateful packet firewall, intrusion detection system (IDS), intrusion prevention system (IPS), web application firewall (WAF), Distributed Denial of Service (DDoS) mitigation appliance/service, et al.
EoL Software Support
End-of-life (EoL) and end-of-support (EoS) operating systems are prohibited. EoL operating systems without appropriate Long Term Support (LTS) are prohibited. Any use of software which does not include a support model is prohibited.
Trusted Certificates
All platforms with exposure to publicly accessible untrusted networks (i.e. the Internet) must use a minimum extended validation (EV) certificate from a publicly trusted certificate authority (CA), which is listed on the CAB Forum at https://cabforum.org/members.
Vulnerability Scanning
All platforms with exposure to publicly accessible untrusted networks (i.e. the Internet) must be scanned at a minimum of two-week intervals. When systems cannot be scanned at two-week intervals, one of the following must be provided:
- Attestation showing completion of annual penetration test, redactions as required.
- Attestation of monthly external scanning.
- Pre-production code review for all major updates, static or dynamic code reviews.
Patching
All systems must have regular patching updates applied to them based on CVSS score.
Incident Response & DR/BC
Documented incident response plan must be in place. Breach notification within 24-72 hours agreed upon in contracts. Root cause report provided to Customer upon request. Documented DR/BC plan must be in place. Documented annual DR testing to be conducted.
Security Testing
An annual third-party penetration test report is required for all SaaS service providers. The report may be from a third-party firm of the vendor's choosing.
User Accounts & Log Export
All platforms and their component systems must have the ability to export logs. Including, but not limited to: users accounts including privilege user accounts, authentication, authorization, and access controls.
Third-Party & Contractual Safeguards
Business Associated Agreement (BAA) must be agreed upon and signed for all SaaS vendors that process, store, handle, or transmit PHI, PII, PCI, or other sensitive data. Cyber liability insurance carried. Subprocessor/Subcontractor list maintained. Contractually defined that security obligations flow to subprocessors or subcontractors. Right to audit clause defined. Data return or data destruction upon contract termination defined.
Minimum Security Standards: SaaS Services
SaaS offerings are defined as any service that is being hosted on infrastructure and networks not managed by Capital Health personnel, including cloud services, etc.
Regulatory
Security documentation for one or more of the following:
At least one of the following 3rd-party attestations of security baselines such as:
- SOC-2 Type 2
- HITRUST
- NIST CSF
- ISO-27001 compliance
All SaaS platforms must abide by the local, state, and federal regulatory controls as dictated by data type they are handling. Ex: HIPAA/HITECH, PCI DSS, SOX, etc.
User Accounts
Default passwords are prohibited. The use of guest accounts, service accounts, or any account type where the password might be shared requires pre-approval from the Capital Health Information Security Team. Administrative (privileged) accounts require protection via the use of a Privileged Account Management (PAM) system. All account passwords must have a minimum of 16 characters. For administrative accounts, password rotation must be enforced for all passwords with less than 32 characters.
PHI Data Protections
PHI/PII/PCI data needs to have the following security measures in place:
- Minimum of TLS 1.2 encryption in transit.
- Minimum of AES-265 encryption at rest.
- Defined and documented data retention and destruction processes.
- Data access tracking enabled with logging.
- Role-based access controls (RBAC) enabled.
- Least-Privilege model enabled.
- Privileged-access logging enabled.
- Minimum of quarterly access reviews.
- Secure encryption key management.
- Logical tenant segregation.
Authentication
Customer-supported Microsoft Azure AD federation and management. The application must also demonstrate strong MFA, as well as vendor-driven account termination for any vendor-managed accounts, processed within 24 hours of receipt of an Capital Health-provided termination list.
Perimeter Defense
All SaaS platforms must be protected by a perimeter defense mechanism, including but not limited to, stateful packet firewall, intrusion detection system (IDS), intrusion prevention system (IPS), web application firewall (WAF), Distributed Denial of Service (DDoS) mitigation appliance/service, et al.
EoL Software Support
End-of-life (EoL) and end-of-support (EoS) operating systems are prohibited. EoL operating systems without appropriate Long Term Support (LTS) are prohibited. Any use of software which does not include a support model is prohibited.
Trusted Certificates
All platforms with exposure to publicly accessible untrusted networks (i.e. the Internet) must use a minimum extended validation (EV) certificate from a publicly trusted certificate authority (CA), which is listed on the CAB Forum at https://cabforum.org/members.
Vulnerability Scanning
All platforms with exposure to publicly accessible untrusted networks (i.e. the Internet) must be scanned at a minimum of two-week intervals. When systems cannot be scanned at two-week intervals, one of the following must be provided:
- Attestation showing completion of annual penetration test, redactions as required.
- Attestation of monthly external scanning
- Pre-production code review for all major updates, static or dynamic code reviews.
Patching
All systems must have regular patching updates applied to them based on CVSS score.
Incident Response & DR/BC
Documented incident response plan must be in place. Breach notification within 24-72 hours agreed upon in contracts. Root cause report provided to Customer upon request. Documented DR/BC plan must be in place. Documented annual DR testing to be conducted.
Security Testing
An annual third-party penetration test report is required for all SaaS service providers. The report may be from a third-party firm of the vendor's choosing.
User Accounts & Log Export
All platforms and their component systems must have the ability to export logs. Including, but not limited to: users accounts including privilege user accounts, authentication, authorization, and access controls.
Third-Party & Contractual Safeguards
Business Associated Agreement (BAA) must be agreed upon and signed for all SaaS vendors that process, store, handle, or transmit PHI, PII, PCI, or other sensitive data. Cyber liability insurance carried. Subprocessor/Subcontractor list maintained. Contractually defined that security obligations flow to subprocessors or subcontractors. Right to audit clause defined. Data return or data destruction upon contract termination defined.
Minimum Security Standards: Vendor-Supported Platforms
Vendor-Supported platforms consist of any devices that the vendor is responsible for configuring, patching, and other security related work, while the device resides in an Capital Health-managed environment. This may include medical devices, workstations, servers, network components, and IoT devices (see IoT standards).
System Inventory
All devices must be entered into a centralized database with the appropriate information so that owner, department and location can be obtained when necessary
Asset Security Posture
Security documentation for the device, system, or service must include:
At least one of the following descriptors:
- Data Flow and Network Topology diagrams
- Ports and protocols list
- Library and services list
And at least one of the following 3rd party attestation of security baseline documents:
- SOC-2 Type 2
- HITRUST
- NIST
- ISO compliance
User Accounts*
Default passwords are prohibited. The use of guest accounts, service accounts, or any account type where the password might be shared requires approval by the Capital Health Information Security Team. Administrative (privileged) accounts require protection via the use of a Privileged Account Management (PAM) system. All account passwords must have a minimum of 16 characters. For administrative accounts, password rotation must be enforced.
Data Security Controls
All platforms must abide by the local, state, and federal regulatory controls as dictated by information type they are handling. Ex: HIPAA/HITECH, PCI-DSS, etc.
Authentication
Internal systems must use federation for authentication and be joined to the Capital Health directory. If this cannot be done, account passwords must comply with Capital Health standards (see User Accounts).
External systems must use federation for authentication via SAML, OAuth, or OpenID. If this cannot be done, account passwords must comply with Capital Health standards (see User Accounts). The application must also demonstrate strong MFA, as well as vendor-driven account termination for any vendor-managed accounts.
Malware Protection
All platforms and their component systems must include one or more of the following, which cannot be disabled for any reason: endpoint protection / anti-virus agent, application allow-listing, read-only mounts.
Perimeter Defense
All platforms must be protected by a perimeter defense mechanism including but not limited to stateful packet firewall, intrusion detection system (IDS), intrusion prevention system (IPS), web application firewall (WAF), distributed denial of service (DDoS) mitigation appliance/service, et al.
Software Support
End-of-life (EoL) and end-of-support (EoS) operating systems are prohibited. EoL operating systems without appropriate Long-Term Support (LTS) are prohibited. Any use of software which does not also include a support model is prohibited.
Certificates
All platforms with exposure to publicly accessible untrusted networks (i.e. the internet) must use a minimum extended validation (EV) certificate from a publicly trusted certificate authority (CA), which is listed on the CAB Forum at https://cabforum.org/members.
Vulnerability Scanning
Systems must be permitted to have a Capital Health vulnerability scan upon demand.
Patching
All systems must have updates applied to them based on CVSS score. Application patching is governed by CVSS score for security related vulnerabilities and is a vendor responsibility. For biomedical devices, vendors must provide a mitigation plan, in line with FDA guidance, for identified vulnerabilities. This also includes firmware updates for devices that do not have a typical operating system.
Encryption
All platforms communicating across untrusted networks must use encryption-in-transit. All platforms storing sensitive data must enforce encryption-at-rest. The AES algorithm with a 256-bit key length is the minimum standard for encryption-at-rest. TLS 1.2 or better, with elliptic curve (EC) ciphers enforcing perfect forward secrecy (PFS) or better is the minimum standard for encryption-in-transit.
Remote Access
All interactive login to Capital Health-hosted platforms shall be delivered via the Capital Health Vendor Privileged Access Management (VPAM) System. This is a publicly accessible web-based gateway supporting federated vendor identity login, self-registration, and privileged account management for RDP, SSH, SCP, VNC, Web, SQL, and other remote interactive login modalities. If VPAM cannot be supported, the only acceptable method for remote access is an on-site field engineer (vendor provided) and/or Capital Health-managed screen sharing using Capital Health-managed, PAM protected accounts.
Isolation
Placing vendor systems on separate networks logically separated from Capital Health is not permitted without prior technical design review.
Security Testing
All externally-facing systems must have a third-party penetration test. Any required corrective actions must be completed before the system goes into production. It is recommended to regularly schedule penetration tests for all systems that host sensitive (PHI/PII/PCI) data.
Log Export
All platforms and their component Systems must have the ability to export logs. Including, but not limited to: authentication, authorization, and access control
Use of Trackers
Licensor software shall not contain any software routine, code, instruction, hardware component or combination of the foregoing (hereunto referred to as "tracker") which tracks or monitors Capital Health usage and/or Capital Health data for any purpose whatsoever. The use of a tracker is only permitted with the express written consent of the Capital Health Compliance and/or Legal teams.
*This control is only applicable to vendor-managed user accounts and vendor defined but Capital Health managed local accounts, frontend or backend. Federated user accounts managed by Capital Health are not applicable.