MESC Conference Security and Privacy for Medicaid Information Systems. Scott Glover Deloitte & Touche, LLP

Transcription

1 MESC Conference Security and Privacy for Medicaid Information Systems Scott Glover Deloitte & Touche, LLP

2 Agenda Security and privacy requirements for Medicaid systems Implementing or applying a security framework for the solution Developing the security plan for implementation, ongoing maintenance and compliance Privacy Identity and access management Auditing, logging, monitoring, and reporting Database security Encryption of sensitive data Data leakage prevention Business continuity Vulnerability management Risk assessments Summary Q&A 2

3 Security and Privacy Requirements for Medicaid Systems Medicaid information systems are subject to numerous Federal and State security and privacy requirements and industry standards. Securing systems with appropriate levels of security and privacy safeguards is a daunting challenge given the number of regulations and standards to comply with, several of which overlap in their requirements. Compliance Challenges Federal/State Regula7ons Healthcare Informa7on Technology for Economic and Clinical Health Act (HITECH) IRS 1075/SSA HIPAA Security & Privacy Rules Pa7ent Protec7on and Affordable Care Act (PPACA) Privacy Act 1974 State Breach No7fica7on Laws Compliance with regula3on and legisla3ve requirements and industry standards (e.g. HITECH, HIPAA, PPACA, IRS 1075, SSA, PCI DSS, etc.)1, Demonstra3ng adop3on of common prac3ces (e.g. ISO, NIST, HITSP, etc.) 2 Security & Privacy Standards Providing the minimum safeguards necessary given the mul3tude of security and privacy regula3ons/ standards HITRUST* ISO/IEC 27001/2 NIST SP800 Healthcare IT Standards Panel (HITSP/TN900) Tackling a variety of internal prac3ces (e.g. policies, procedures, standards, etc.) OASIS PCI DSS COBIT Interac3ng with internal compliance and assurance func3ons Interac3ng with third party assurance providers HITRUST is a security framework based upon standards such as COBIT, NIST, ISO and others. 3

4 Implementing a Security Framework An end to end security and privacy framework can reduce the challenge of applying controls to secure Medicaid enterprise systems. Industry and Regulatory Requirements HIPAA PPACA ISO/IEC 27001/2 and NIST IRS 1075/SSA Privacy Act 1974 Federal Regula3ons State Breach No3fica3on Laws Security Layers Presenta3on Applica3on Data Audit & Monitoring Infrastructure Security Solu3ons Iden3ty Management Access Management Profile or Role (Single Sign- On, Management Fine/Coarse Grained Access) Data Encryp3on (Rest, Transit, Use) Data Loss Preven3on 4 Applica3on Security Tes3ng Infrastructure Security (IDS, IPS, Firewalls) Security Informa3on and Event Management Security Management Security Governance ARRA HITECH

5 Developing the Security Plan Developing a System Security Plan (SSP) is a Centers for Medicare and Medicaid Systems (CMS) requirement for Medicaid information systems.3 The SSP is critical in the solution development lifecycle as it is used to determine, implement and document the current level of information security (IS) controls throughout the life-cycle of the system. System Security Plan inputs and outputs NIST NIST FIPS 199 FIPS 200 Cer3fica3on and Accredita3on Process (C&A) Plan of Ac3on and Milestones (POA&Ms) Risk Assessments Configura3on Management Ongoing Monitoring 5 Security Plan

6 Privacy FISMA requirements indicate that a Privacy Impact Assessment (PIA) should be conducted to evaluate possible privacy risks and the mitigation of those risks at the beginning of and throughout the development life cycle of a program or system. A PIA is an analysis of how sensitive information: Personally identifiable information (PII), protected health information (PHI), Federal tax information (FTI), and Payment Card Industry (PCI) data is collected, used, disseminated, and maintained Policies and procedures serve as the foundation to protect sensitive information Security controls should be designed and implemented to comply with applicable privacy requirements based on the results of the PIA A risk assessment assesses the design and operating effectiveness of the controls in place to comply with privacy requirements (outlined in the Security and Privacy Framework) 6

7 Identity and Access Management A business case for using Identity and Access Management (IAM) for Medicaid information system solutions already exists with the growing regulatory focus on protecting sensitive data from unauthorized use and exposure. Health & Human Services (HHS) Self Service Solu3on State Employees And Contractors Access Review and Approval Customers/ Consumers TANF Role-Based Access Control Single Sign-On Self-Service Features (Password Reset, Forgot Password) IAM Fine Grained Access Authorization Existing New 7 Exchange Health Plan Delegated Administration Medicaid/CHIP Account Administration Child Care Self-Registration (Citizen, Community Partners) SNAP Business Partners Health Insurance Exchange System Administrators Access Reporting Policy Administration End-user support Customer Service and Operations

8 Auditing, Logging, Monitoring, and Reporting In recent years, highly noticeable information breaches and cyber crimes have shown that capabilities such as implementing a security information and event monitoring (SIEM) solution, to timely and properly detect and defend against cyber threats can mitigate security and privacy risks. Native Logs Security Perimeter Logs External Cyber Threat Intelligence Feeds Internal Cyber Threat Intelligence Feeds Security Information and Event Management Periodic Reporting (SIEM) Operating System Logs Referential IT Source Logs Cyber Threat Management (Real Time Monitoring and Alerting of Security Events from Correlated Logs) Application Event Logs Real Time Monitoring Security Incident Response Forensics Risk Assessment Proac3ve Surveillance 8

9 Database Security Sensitive data most often resides in a database as part of the Medicaid enterprise system solution. Protection of sensitive data that resides in databases is necessary to comply with several Federal and State security and privacy requirements. Encryp3on Access Control Monitoring System Database Logging Repor3ng Threat Protec3on 9

10 Encryption of Sensitive Data Encryption of sensitive data at rest and in transit is required by several states and by some Federal regulations. Qualifying for the Safe Harbor provisions of the HITECH act and protecting Federal Tax Information (FTI) require encryption according to the standards defined in FIPS Highlights of guidance for encryption are as follows: Encryption of electronic protected health information (ephi) in transit should be encrypted end to end PII should be encrypted at rest and in motion to adhere to many State security and privacy policies FTI needs to be encrypted both at rest and in motion to comply with IRS 1075 requirements HHS deems that any data at rest that meets the NIST Publication , Guide to Storage Encryption Technologies for end user devices will render stored electronic information secure Cryptographic modules should be on the FIPS validated list 10

11 Data Leakage Prevention Data leakage prevention requirements are not grouped together in Federal and Sate requirements but need to be addressed as part of the security solution to mitigate the risk of unauthorized disclosure of sensitive data. Map sensitive data flows through the relevant control environments and develop leakage controls using a combination of processes and technology. Transac7on and Ac7vity Monitoring Third Party Communica7on Database Sensi7ve Data Developer Access to Produc7on Mobile Media Archival and Disposal 11

12 Data Leakage Prevention Guidance Examples E- mail/im, HTTP/S, SMTP, FTP, TCP 1 2 Data in Use Monitor user interac3ons with data to iden3fy, for example, acempts to transfer sensi3ve content to a USB drive and apply policy Common controls include disabling Copy, Print, Print Screen, Open, Paste, Save, Save As, and sending No3fica3on 3 Data in Mo3on Data at Rest Analyze data traffic over the network to iden3fy sensi3ve content being sent via e- mail, IM, HTTP, or file transfer and apply policy Scan and inspect enterprise data repositories to iden3fy sensi3ve content and apply policy accordingly Common controls include Allow, Audit, Quaran3ne, Blocking, Encryp3on, and No3fica3on 12 Common controls include Encryp3on, Obfusca3on, Quaran3ne, Dele3on, and No3fica3on

13 Business Continuity Developing and testing a Business Continuity/Disaster Recovery plan is required for Medicaid information systems. Below is a framework for a BCP/DR plan: Analyze Develop Implement Current State Assessment Governance Resource Acquisi3on & Implementa3on Risk Assessment Availability/ Recoverability Strategies Training Business Impact Analysis Plans & Documenta3on Tes3ng Con3nuous Improvement & Quality Assurance 13

14 Vulnerability Management A vulnerability management program must be established for implementing and maintaining Medicaid information systems. A Vulnerability Management program ordinarily contains the following elements: Secure Code Review External Vulnerability Scanning External Penetration Testing Application Vulnerability Scanning Internal Vulnerability Scanning Remediation Treatment Plan Re-Testing Schedule Tools are available to automate some of the vulnerability management tasks listed above. Guidance on developing a vulnerability management program can be found in NIST Special Publication Creating a Patch and Vulnerability Management Program. 5 14

15 Risk Assessment CMS and Federal Information Security Management Act (FISMA) requirements dictate that a Risk Assessment must be performed against Medicaid information systems prior to going into production and at least once per year after the system is in production. A risk management framework should be used to conduct the assessment. A risk assessment of Medicaid information systems will generally contain the following steps: Categorize the information system break down into assets to be assessed Identify a list of rationalized controls and apply against assets Determine inherent risk level for each control area applied against assets Determine desired maturity level for each control area Assess design effectiveness and if in production, operational effectiveness Recommend controls to remediate gaps Calculate inherent risk for each control Develop risk treatment plan 15

16 Summary Providing appropriate security and privacy controls to comply with Federal and State requirements and mitigating security and privacy breaches is a challenging task and should be built into the Medicaid enterprise system solution from the planning stages of the project to Production deployment and ongoing operations. A solid security and Privacy framework is needed to address the numerous security and privacy requirements and standards The Security organization needs to be formed/organized to support the Medicaid enterprise system solution Implementation and Operations A detailed system security plan is needed to form a blueprint of the Medicaid enterprise system security solution Assessments (PIA, BIA, Risk, and Vulnerability) need to be conducted prior to going into Production and periodically after the solution is in Production operations Continuous monitoring is required to address compliance requirements and mitigate security and privacy risks 16

17 Q&A For further questions, Scott can be contacted at 17

18 References 1 Details for the HITECH Act can be found at hitechenforcementifr.html. Details for HIPAA Security and Privacy Requirements can be found at PCI DSS requirements can be found at Details on Patient Protection and Affordable Care Act (PPACA) the can be found at Details for NIST Standards can be found at Details for IRS 1075 requirements can be found at Details on ISO standards can be found at Details on the Healthcare Information Technology Standards Panel can be found at The Centers for Medicare and Medicaid Services (CMS) provide guidance on Privacy Impact Assessments at Privacy/Privacy-Impact-Assessment.html Details on FIPS Standards can be found at Details on NIST standards can be found at

19 About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting. Copyright 2012 Deloitte Development LLC. All rights reserved. Member of Deloitte Touche Tohmatsu Limited