Minimum Security Standards: NYP-Supported Platforms
The NewYork-Presbyterian (NYP) Minimum Security Standards have been designed to outline information security requirements that all devices must adhere to in order to be onboarded at the hospital. Compliance with these standards must be validated before any contract can be signed between a vendor and NYP.
NYP-Supported platforms consist of any offering that involves hardware, infrastructure, or networks that are deployed in NYP-managed environments and supported by NYP. Examples include servers, routers, workstations, and cloud systems administered by NYP.
If a vendor cannot adhere to the below standards, InfoSec reserves the right to review on a case by case basis. Please note: Most submissions will be rejected if they cannot comply with the minimum security standards.
| System Inventory | All devices must be entered into the CMDB with the appropriate information so that the 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: a) Port and protocol list And at least one of the following documents: a) Software-Bill-of-Materials (SBOM), or MDS2 data sheet |
| 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 NYP 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 less than 32 characters. |
| 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, SOX, etc |
| Authentication | Internal systems must use federation for authentication and be joined to the NYP directory. If this cannot be done, account passwords must comply with NYP 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 NYP standards (see User Accounts). 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 NYP-provided termination list. |
| 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 have an NYP vulnerability scan every two weeks. Alternatively, a vendor may provide a vulnerability report to this end. |
| Patching | All systems must have updates applied to them based on CVSS score. It is prohibited to disable patching for NYP-managed systems. For biomedical devices, vendor 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 NYP-hosted platforms shall be delivered via the NYP Privileged Remote Access (PRA) 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 PRA cannot be supported, the only acceptable method for remote access is an on-site field engineer (vendor provided) and/or NYP managed screen sharing using NYP-managed, PAM protected accounts. |
| Security Testing | All externally-facing systems must have either a third-party penetration test or an NYP-provided CEVA analysis. Any required corrective actions must be completed before the system goes into production. It is recommended to regularly schedule penetration tests or CEVA analyses for all systems that host sensitive 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 NYP usage and/or NYP data for any purpose whatsoever. The use of a tracker is only permitted with the express written consent of the NYP Privacy Team. |
*This control is only applicable to vendor managed user accounts and vendor defined but NYP managed local accounts, frontend or backend. Federated user accounts managed by NYP are not applicable.
**Provided by NYP
Minimum Security Standards: IoT Device
The NewYork-Presbyterian (NYP) IoT Minimum Security Standards have been designed to outline information security requirements that all devices defined as “IoT” must adhere to in order to be added to an NYP-managed environment. Compliance with these standards is a requirement before any contract can be signed between NYP and the vendor.
IoT devices are defined as systems that have a limited operating system that does not support the use of agents, firewalls, or other protection mechanisms. Examples may include printers, smart speakers, cameras, smart TVs, conference room systems, network devices, or select mobile devices.
If a vendor cannot adhere to the below standards, InfoSec reserves the right to review on a case by case basis. Please note: Most submissions will be rejected if they cannot comply with the minimum security standards.
| System Inventory | All IoT devices must be enrolled in NYP's MDM solution if supported. Unsupported devices may have additional hardening requirmeents. All IoT devices not enrolled in NYP's MDM solution must be entered into the CMDB with accurate owner information. |
| Asset Security Posture | Security documentation for the device, system, or service must include: At least one of the following descriptors: a) Port and protocol list And at least one of the following documents: a) Software-Bill-of-Materials (SBOM), or MDS2 data sheet |
| 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 NYP 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 less than 32 characters. |
| 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, SOX, etc |
| 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 | It must be possible to scan the device for vulnerabilities if it is accessible on the NYP network. All systems must have a vulnerability scan every two weeks. Alternatively, a vendor may provide a vulnerability report to this end. |
| Patching | All systems must have updates applied to them based on CVSS score. It is prohibited to disable patching for NYP-managed systems. For biomedical devices, vendor 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 NYP-hosted platforms shall be delivered via the NYP Privileged Remote Access (PRA) 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 PRA cannot be supported, the only acceptable method for remote access is an on-site field engineer (vendor provided) and/or NYP managed screen sharing using NYP-managed, PAM protected accounts. |
| Security Testing*** | All externally-facing systems must have either a third-party penetration test or an NYP-provided CEVA analysis. Any required corrective actions must be completed before the system goes into production. It is recommended to regularly schedule penetration tests or CEVA analyses for all systems that host sensitive 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 NYP usage and/or NYP data for any purpose whatsoever. The use of a tracker is only permitted with the express written consent of the NYP Privacy Team. |
*This control is only applicable to vendor managed user accounts and vendor defined but NYP managed local accounts, frontend or backend. Federated user accounts managed by NYP are not applicable.
**Provided by NYP
***It is understood that most IoT devices will not be externally facing. However, in cases where they are a penetration test must be scheduled.
Minimum Security Standards: Vendor-Supported Platforms
The NewYork-Presbyterian (NYP) Minimum Security Standards have been designed to outline information security requirements that all devices must adhere to in order to be onboarded at the hospital. Compliance with these standards must be validated before any contract can be signed between a vendor and NYP.
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 NYP-managed environment. This may include medical devices, workstations, servers, network components, and IoT devices (see IoT standards).
If a vendor cannot adhere to the below standards, Infosec reserves the right to review on a case by case basis. Please note: Most submissions will be rejected if they cannot comply with the minimum security standards.
| System Inventory | All devices must be entered into the CMDB 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: a) Port and protocol list And at least one of the following documents: a) Software-Bill-of-Materials (SBOM), or MDS2 data sheet |
| 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 NYP 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 less than 32 characters. |
| 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, SOX, etc |
| Authentication | Internal systems must use federation for authentication and be joined to the NYP directory. If this cannot be done, account passwords must comply with NYP 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 NYP standards (see User Accounts). 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 NYP-provided termination list. |
| 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 have an NYP vulnerability scan every two weeks. Alternatively, a vendor may provide a vulnerability report to this end. |
| 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, vendor 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 NYP-hosted platforms shall be delivered via the NYP Privileged Remote Access (PRA) 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 PRA cannot be supported, the only acceptable method for remote access is an on-site field engineer (vendor provided) and/or NYP managed screen sharing using NYP-managed, PAM protected accounts. |
| Isolation | Placing vendor systems on separate networks logically separated from NYP is not permitted. |
| Security Testing | All externally-facing systems must have either a third-party penetration test or an NYP-provided CEVA analysis. Any required corrective actions must be completed before the system goes into production. It is recommended to regularly schedule penetration tests or CEVA analyses for all systems that host sensitive 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 NYP usage and/or NYP data for any purpose whatsoever. The use of a tracker is only permitted with the express written consent of the NYP Privacy Team. |
*This control is only applicable to vendor managed user accounts and vendor defined but NYP managed local accounts, frontend or backend. Federated user accounts managed by NYP are not applicable.
**Provided by NYP
Minimum Security Standards: SaaS Services
The NewYork-Presbyterian (NYP) Minimum Security Standards have been designed to outline information security requirements that all devices must adhere to in order to be onboarded at the hospital. Compliance with these standards must be validated before any contract can be signed between a vendor and NYP.
SaaS offerings are defined as any service that is being hosted on infrastructure and networks not managed by NYP personnel.
If a vendor cannot adhere to the below standards, Infosec reserves the right to review on a case by case basis. Please note: Most submissions will be rejected if they cannot comply with the minimum security standards.
| Asset Security Posture | Security documentation for the device, system, or service must include: At least one of the following descriptors: a) Port and protocol list And at least one of the following documents: a) Software-Bill-of-Materials (SBOM), or MDS2 data sheet |
| 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 NYP 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 less than 32 characters. |
| 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, SOX, etc |
| Authentication** | Internal systems must use federation for authentication and be joined to the NYP directory. If this cannot be done, account passwords must comply with NYP 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 NYP standards (see User Accounts). 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 NYP-provided termination list. |
| 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 scanned at a minimum of two weeks intervals. When systems cannot be scanned at two week intervals, one of the following must be provided: a) Attestation showing completion of annual penetration test, redactions as required |
| Patching | All systems must have updates applied to them based on CVSS score. |
| 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. |
| Security Testing | NYP requires an annual third-party penetration test report for all SaaS services. The report may be from a third-party firm of the vendor's choosing. Alternatively, NYP can perform a CEVA analysis on the service. CEVA analyses are limited in scope and subject to strict rules of engagement. |
| 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 NYP usage and/or NYP data for any purpose whatsoever. The use of a tracker is only permitted with the express written consent of the NYP Privacy Team. |
*This control is only applicable to vendor managed user accounts and vendor defined but NYP managed local accounts, frontend or backend. Federated user accounts managed by NYP are not applicable.
**Not applicable to backend system management