Security Standards

Table of Contents

Office of Health Insurance Programs (OHIP) Moderate-Plus Security Controls Baseline

OHIP has defined a Moderate-Plus Security Controls Baseline based on, and consistent with, the security provisions described in the Centers for Medicare and Medicaid Services (CMS) Acceptable Risk Safeguards (ARS) and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 at the Moderate level. Additionally, OHIP has augmented these federal standards with New York State Policies and Standards. The Moderate-Plus Security Controls Baseline includes a System Overview document and the eighteen security control families as set forth in CMS ARS and NIST 800-53.

|top of page|

Sharing OHIP MCD

OHIP makes Medicaid Confidential Data (MCD) available to certain MCD requestors to administer the Medicaid Program. Prior to OHIP releasing MCD, the MCD requestor must describe its use-case and data requirements and apply for a Data Use Agreement (DUA). The DUA is a legally binding agreement between the MCD requestor and OHIP and must be executed by both parties before MCD is accessed or used by the MCD requestor. The MCD requestor must also demonstrate to OHIP´s satisfaction that the requestor will secure the MCD commensurate with all federal and state requirements, as measured by the Moderate-Plus Security Controls Baseline. OHIP employs several methods by which MCD requestor compliance with the Moderate-Plus Baseline may be measured. OHIP will determine the approach that the MCD requestor will use, depending on the use-case presented and the data set requested. OHIP employs three models for performing these security assessments: Restricted Access Model for small, non-production environments, Attestation Model, for small to moderately sized production environments, and Full System Security Plan (SSP) Workbook Model, which is required of all vendors under contract to OHIP. For additional details regarding the security assessment models, please see below.

|top of page|

Restricted Access Model (RAM)

OHIP has defined a RAM for some requestors to receive MCD. While the RAM has the least demanding security and compliance requirements, it is also the least flexible for data analysis and processing. In the RAM, the MCD must remain in a secure, physically isolated space that contains all system components that comprise the solution that will store, process, connect to, or provide access to MCD. RAM security control requirements are described in detail in the RAM request form. As part of the RAM application process, the MCD requestor will attest to compliance with the RAM Security requirements. The RAM request form requires notarization and constitutes a legally binding agreement between the MCD requestor and OHIP. The request, review, and approval process for a RAM may take between 30 to 60 days from the time the request is first submitted to OHIP.

For any questions regarding the RAM please contact the OHIP Security and Privacy Bureau at: doh.sm.Medicaid.Data.Exchange@health.ny.gov.

|top of page|

RAM Security Requirements

Restricted Environment

  • Each Data Use Agreement (DUA) with the Department shall have one RAM.
  • One RAM is allowed per secured room/space. If more than one is required, a formal request to the Department must first be made explaining why and how it will be managed. Department review and approval is required.
  • The data in a RAM cannot be shared between projects on separate DUAs with DOH.
  • Data at rest in the RAM must be encrypted using FIPS140-2 compliant encryption.
  • The room must have strong physical access security that includes a documented log of persons accessing the room or logical system, with date and times of entry and exit.

Network

  • Physically or Logically isolated from the organization’s LAN (“air gapped”).
  • Use of Wi-Fi and other wireless technologies within the RAM must be prohibited and if devices are capable, disabled and locked down.
  • The RAM network shall not permit any form of access from outside of the RAM’s room/logical space, such as local network, wireless, and so forth.

If remote access is required for the RAM solution, Multi-factor Authentication is required.

  • The RAM shall not access any network or service outside of its room or Logical space, including the Internet, cloud, organization data center services, and so forth.
  • The use of virtualization is permitted within the RAM; however, the hypervisor and host for virtual machines must be isolated from all other virtual production systems. Virtual machines on the host shall not be used for any purposes external to the RAM.

Users and Support Personnel

  • A RAM may have up to twelve authorized personnel, including business users, security administrators, and maintenance personnel. Acception requests can be made with justification for Bureau review and approval.
  • Authorized personnel may consist of employees, contracted staff, or authorized personnel from partner organizations, and/or vendors. If the authorized personnel are from an organization other than the primary RAM holder, a Business Associate Agreement (BAA) must be on file and acknowledged by the Security and Privacy Bureau prior to the individual obtaining access to the RAM.
  • All RAM personnel must be properly vetted and undergo appropriate background checks, commensurate with the NYS-P03-002 NYS Information Security Policy, Section 4.7 - Personnel Security.
  • All access to Restricted Environment and data will be restricted to minimum necessary.
  • All personnel authorized to access the RAM must be listed on the DUA names list, submitted to DOH and resubmitted at least quarterly or when changes need to be made.
  • All personnel are assumed to have the same access to data and equipment within the RAM, although the business role for each may vary based on business need.
  • All user and administrator actions on the restricted system and network shall be logged and periodically reviewed for inappropriate or unauthorized activity. Review must include the physical access logs for the rooms that comprise the RAM. At minimum, monthly reviews should be performed.
  • All users permitted to access the RAM must have their own unique login account.
  • The System logs must also be configured to track logins/log offs and when actions were taken (e.g., Copied the MCD to USB drive or CD ROM).
  • By default, the RAM equipment Secure configuration should include disabling the use of CD/DVD and USB port to minimize risk of insider threat and/or unauthorized use.

Printers and connected equipment

  • Any connected devices, such as workstations, servers, printers, storage arrays and archive media, must reside within the RAM, and only devices within the RAM are permitted to attach to the restricted LAN / VLAN.
  • Any equipment removed from the RAM must be sanitized commensurate with the NYS-S13-003 Sanitization / Secure Disposal Standard, to remove any sensitive information from storage drives, imaging surfaces, and so forth, prior to removal.

Data import and export

  • Data extracted/exported from the RAM must be HIPAA de-identified1 and non-business-sensitive. This includes any reports, images, work products, hand-written notes, and so forth. A copy of a certification or letter of de-identification must be provided to the Security and Privacy Bureau. Method of deidentification process must be provided to the Bureau for review.
  • Data extraction/export must only be done by the assigned / trained admins to better control when extraction occurs, reviewed first to ensure data has been de-identified, and that only authorized person(s) with business justification receive these extracts / exports.
  • The use of strong physical security, strong encryption, and a documented process that includes an auditable chain of custody, must be employed, whenever data is transported into and out of the RAM.

    All storage media, including removable, backup, and hard drives of servers, workstations, and other devices, are to use FIPS 140-2 approved algorithms for data encryption, as per the NYS-S14-007 Encryption Standard.
  • Any non-DOH supplied data that is added to the RAM becomes a part of the RAM and export of that data is then subject to the previously-described de-identification . This shall be enforced, regardless if the data is comingled or not with DOH supplied MCD.

_________________________________________

1. Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.  1

|top of page|

SSP Critical Controls Attestation Model

OHIP has defined the SSP Critical Controls Attestation as a way for some MCD requestors to attest to the implementation of Moderate-Plus Critical Controls for the system receiving, storing, processing, transmitting, and accessing OHIP MCD. The SSP Critical Controls Attestation request form requires notarization and constitutes a legally binding agreement between the MCD requestor and OHIP. The Critical Controls are a subset of the Moderate-Plus Baseline controls. These controls align with the Center for Internet Security (CIS) controls, and controls required by the HIPAA Security Rule which are intended specifically to protect data.

The SSP Critical Controls Attestation is a part of the DUA process that MCD requestors must complete to receive MCD from OHIP. The SSP Critical Controls Attestation process, as defined below, may take between 2 to 6 months from the time the DUA and Attestation forms are received and accepted by OHIP.

For any questions regarding the Attestation Model, please contact the OHIP Security and Privacy Bureau at: doh.sm.Medicaid.Data.Exchange@health.ny.gov.

|top of page|

Attestation Process Overview

While the MCD requestor works on executing the DUA, the MCD requestor must also start the process of attesting that the critical security controls are in place to protect the MCD.

  • The MCD requestor begins by filling out the System Overview. The System Overview document is a CMS template used to define what system components make up the scope of the solution. Scope can be defined as any system used for receiving, storing, processing, transmitting, and/or providing access to OHIP MCD. The System Overview must be submitted along with the Critical Security Controls Attestation form. Please note: The System Overview may be submitted before submitting the Attestation.
  • The MCD requestor is responsible for completing the Attestation, and for the accuracy of the implementation status of each of the system´s critical security controls as outlined in the form, even if partners or hosting providers have been employed to manage some or all of those controls.
  • Upon acceptance of the submitted Critical Security Controls Attestation and completion of the DUA process, OHIP will coordinate with the MCD requestor to facilitate the secure delivery of MCD to the MCD requestors production environment.
  • Within six months of OHIP acceptance of the attestation, the MCD requestor shall retain an independent third-party to assess the critical security controls for the entire environment. A report of the findings shall be submitted to OHIP. A Plan of Actions and Milestones (POA&M) must also be submitted for any gaps or deficiencies.
  • Along with the POA&M, the MCD requestor must submit an updated Attestation reflecting the status of each critical control as determined by the independent third-party assessor.
  • MCD requestors shall re-attest that all critical security controls are in place and operating as intended, or when a significant change to the system or its security controls occurs.

For the third-party assessment, OHIP requires that the scope of the audit performed clearly shows coverage of relevant controls, i.e., implementation of the critical controls attested to. While OHIP does not recommend any specific assessment or certification, we offer the following guidance:

The third-party assessor, or the third-party assessor organization, should have one or more of the following industry-recognized security certifications:

  • Certified Information Systems Security Professional (CISSP)
  • Certified Information Systems Auditor (CISA)
  • Certified Information Security Manager (CISM)
  • HITRUST Certified CFS Practitioner (CCSFP)
  • Certified Authorization Professional (CAP)
  • Healthcare Information Security and Privacy Practitioner (HCISPP)
  • CompTIA Security+

In addition to these certifications, the third-party assessor should have experience in the healthcare space.

|top of page|

SSP Workbook Model

OHIP requires its contracted vendors to maintain an SSP that aligns with the Moderate-Plus Security Controls Baseline for any systems that will transfer, process, store, receive, or access MCD. OHIP vendors must have an executed DUA, complete the set of Moderate-Plus security and privacy workbooks, and maintain a Plan of Actions and Milestones (POA&M) which track any control deficiencies. The review and approval process for this model may take between 6 and 12 months from the time the request is first submitted to OHIP.

For any questions regarding the SSP Full Workbooks Model, please contact the OHIP Security and Privacy Bureau at: doh.sm.Medicaid.Data.Exchange@health.ny.gov.

|top of page|

SSP Workbook Process Overview

  • The DUA between the vendor and OHIP is executed and in place;
  • System Overview document has been submitted for review and acceptance;
  • Completed SSP workbooks are submitted, along with supporting artifacts that confirm control existence and the effectiveness of each Moderate-Plus Critical Control. These critical controls must be in place prior to receipt of MCD;
  • Completed SSP workbooks are submitted for the remaining secondary controls .
  • Actively worked Plan of Actions and Milestones (POA&M) for identified control deficiencies are submitted for OHIP DOS review.

OHIP vendors are required to have an executed and acknowledged DUA, complete the set of Moderate-Plus security and privacy workbooks, and maintain a POA&M.

|top of page|