Are you looking for a healthcare compliance audit solution?  Has someone asked your organization to demonstrate that you are HIPAA certified? Are you confused by what “HIPAA certified” even means?

KirkpatrickPrice offers SOC 2 audits with a HITRUST CSF (common security framework) component designed to take the confusion and guesswork out of HIPAA compliance assessments.

The difference between SOC 2 vs. HIPAA is that they are audits over two different areas. A SOC 2 audit tests service organizations’  controls as they relate to the security, confidentiality, availability, processing integrity, and privacy. A HIPAA audit evaluates business associates’ and covered entities’ controls for safeguarding protected health information (PHI).

What is HITRUST?  

The HITRUST framework is a healthcare industry-created compliance protocol designed to resolve the complexities of HIPAA’s Security Rule, variations in business practices, and third-party assurance expectations.  Specifically, the HITRUST CSF addresses compliance and risk expectations under two key components:

  1. Information Security Manual
  2. Standards and Regulations Mapping

The Information Security Manual provides a framework for evaluating HIPAA’s Security Rule requirements for technical, administrative and physical controls related to topics like access control, asset management, business continuity and physical and environmental security.

The Standards and Regulations Mapping portion of the HITRUST framework is a tool HITRUST uses to “normalize” HIPAA Security Rule requirements with other information security standards and regulations like PCI DSS 3.1, ISO 27001, NIST, IRS Pub. 1075, 201 CMR 17.00, and FTC Red Flags.  So, in addition to addressing HIPAA compliance with a SOC 2 with HITRUST, you can use the same audit to evaluate your organization’s risk and compliance with other critical information security and regulatory standards which saves you time, stress, and money.

Finally, while the federal government and HIPAA assessors cannot offer an official “HIPAA certification” to demonstrate HIPAA compliance, the HITRUST Alliance does provide a certification for organizations that successfully undergo HITRUST assessments.  The HITRUST certification can be a powerful marketing tool to demonstrate your organization’s HIPAA compliance activities.

How does the SOC 2 work with HITRUST?

The Service Organization Control (SOC) report complements the HITRUST framework exceptionally well because the SOC 2 audit is designed to address an organization’s security, availability, processing integrity, confidentiality, and privacy of information – concepts inherent within HIPAA’s Security Rule requirements and HITRUST framework.

The SOC 2 report is an effective report because it’s an independent attestation by a CPA. Further, the SOC 2 report is an incredibly common and well-understood audit report type which means your organization will get significant internal and external value when providing the report for business and marketing purposes.

Contact us today to find out how we can assist your organization resolve your HIPAA compliance concerns with a SOC 2 HITRUST audit.

More Compliance Resources

Just an ordinary day in the IT Department

Molly walked in to the IT department at the regional hospital where she’s worked for the last four years. Some mornings are more hectic than others. She could tell it was going to be “one of those days” as the help desk buzzed with activity – users locked out, systems down, Internet outages – but today, these conversations seemed a bit more urgent that usual.

“Molly, come here,” said the IT Director before she could even open her laptop bag at her cubicle. Jerry was a good leader of the IT department. He was the one always appealing to management for the resources they needed for the never-ending expectations on system performance in the hospital. “We’re dealing with something major today. Our EMR system has lost access to the database. Everybody is calling in about it. Gary and Margaret are troubleshooting now, but I need you to get the backups ready,” Jerry instructed as he was heading out to give an update to the management team.

Attack of the Ransomware

Michael had delivered a well-placed phishing email to someone in accounts payable at the regional hospital the day before. Disguised as an invoice, the attachment contained malware. This type is known as ransomware, meant to encrypt files, rendering them inaccessible until the hospital pays a fee for the decryption key. Overnight, the infected computer became the launching point for Michael’s plot to search out the hospital’s network for critical files. The more pervasive the impact, the more likely Michael can collect the ransom.

Three years ago, Michael became part of an organization that regularly orchestrates this type of attack. Back then, they used CryptoLocker and generated millions of dollars in payments. That paled in comparison to what they did with CryptoWall, which netted hundreds of millions of dollars, mostly from U.S. companies. Now, he mostly uses Locky ransomware to stay ahead of anti-virus detection. The group that pays Michael very handsomely has grown tenfold and has lately turned their focus to hospitals. “They have money,” Michael’s handler had said, “and their technology is weak.”

Trouble with the Backups? Let’s not lose our composure…

It had just become apparent to Molly that something was wrong with the backup on the SAN when Gary shared the news.

“The database has been encrypted,” he stated in a defeated tone. “There’s a message on the server demanding that we pay in bitcoin in order to get our files back.”

Molly’s instincts immediately told her this was the reason she was having trouble with the backup files. Through their collaboration, they discovered that the Locky ransomware had found and encrypted the network-accessible backup storage location.

While discussing whether or not they had complete backups in an offsite location, Jerry was ready for an update. After a full debrief, Jerry knew that their options were dwindling. The hospital had upgraded to an expensive SAN last year to provide a networked storage option for the terabytes of data needed by the EMR system. Restoring that volume of data from their offsite media would take days. Although no one said it, everyone knew that they had not performed a full restore test in a long time due to being overworked in the IT department. Margaret volunteered Steve from the help desk to assist in containing the infection. Identifying and disconnecting the affected system would take some time.

Gone Phishing

Michael usually has dozens of targets on the line simultaneously. He uses a variety of delivery mechanisms for the ransomware. Sometimes it’s a phishing email but often it’s an infected website or a poisoned online advertisement. He enjoys the variety to keep the victims’ defenses off-balance. The splash page that he deploys on the infected system gives them a countdown clock to show them that they have 15 days to pay up. If they pay during the first 3 days, the fee is around $500, but every few days the ransom increases. It’s designed to put more pressure on the hospital to consider the cost in time and IT resources versus simply paying for a quick resolution. He recently was successful in his demand for $17,000 worth of bitcoin, where he had crippled a hospital’s operation. The proliferation of bitcoin has enabled their criminal network to anonymize the payment channel and avoid detection. He chuckles every time a target pays and he collects his share. The media says not many pay the ransom, but he knows better because in most cases, they are never publicly identified as victims. They don’t want the attention, so they pay the ransom to make the crisis go away.

Practice Makes Perfect. Initiate Incident Response Plan.

Jerry activated the Incident Response Plan. Never had they known so much about their backup software, disaster recovery procedures, and system redundancy. Everyone in the department couldn’t help but think they should have practiced these steps before today. Most stayed as late as they could the night before, working through the recovery plan. Some stayed all night. The countdown from the ransomware screen taunted them. Once the infected systems had been isolated, some members of the incident response team were tasked with determining what other systems had potential access to the affected hosts. This was an inventory job like no other. Others performed research to determine if this particular strain could be decrypted by any third-party utilities. No luck. Someone in finance researched how to set up a bitcoin wallet, just in case, and was ready to purchase the amount necessary from the localbitcoins.com broker site.

Jerry then advised management that they were down to two options…spend days restoring all critical systems to normal operation or pay the ransom. That decision was above his pay grade. But as his team was deciding to wipe and rebuild the affected machines, rather than try to remove the malware, Jerry was determined more than ever to get the time and funding allotted to his department for hardening the systems according to the NIST standards that he had previously recommended. Security awareness would also be one of his next steps, too. He had seen a Tripwire survey that said the #1 step to prevent ransomware attacks is for users to not click suspicious links. He knows that the hospital could be doing a lot more to educate employees about this threat.

Molly asked Jerry what would happen next. Would public relations go to the media? Would this incident qualify as a data breach and be reported to the regulators? Jerry just shrugged and said, “It’s in the lawyers’ hands now”.

More Resources

What is the Difference Between Phishing and Spear-Phishing?

Why is Ransomware Successful?

Security Awareness Training Tools You Need

The OCR has just announced that the Phase 2 HIPAA Audits have officially begun. The OCR is currently gathering information to determine which covered entities and business associates will be included in the auditee pool. If you haven’t already prepared for Phase 2 HIPAA Compliance, knowing where to begin may seem a bit overwhelming. Understanding the background of the OCR’s supervision of HIPAA Compliance is a good place to start to determine what steps to take to ensure that your organization will be prepared for a potential onsite audit.

Supervision Background

Supervision originally began in 2009 with HITECH Section 13411, which declared that Covered Entities (CE) and Business Associates (BA) would be subject to periodic audits. The OCR then had the authority to supervise both CEs and BAs, and as a result, in 2011/2012, the OCR began conducting Phase 1 Audits. Once the results were evaluated, the Phase 2 audits were scheduled to begin in 2014. After a brief delay, the Phase 2 audit program is now officially underway.

Evaluation of Phase 1 – Lessons Learned

Let’s take a look at the lessons learned from the findings of Phase 1 to see the most common shortcomings in organizations’ HIPAA compliance. During Phase 1, 115 entities were audited. The results of the audit period show that of those entities, 65% of the findings were in violation of the HIPAA Security Rule, 81% were from healthcare providers, and 66% were from level 4 entities (smaller than $50 million in revenue). 42% of the issues with the Security Rule related to Administrative Safeguards, 40.50% related to Technical Safeguards, and 16.76% related to Physical Safeguards. (Linda Sanches, OCR 2012).

Administrative Safeguards help manage security measures taken to protect PHI. These safeguards include things like policies and procedures, risk analysis, risk management, and proper documentation of those things.

Technical Safeguards are for governing who has access to electronic PHI. Technical Safeguards include patching services, firewall configurations, antivirus, network monitoring, etc.

Physical Safeguards protect electronic information systems, buildings, and equipment from natural and environmental disasters, as well as unauthorized intrusion. Physical Safeguards refer to things like locks on doors, securing sensitive areas, and securing PHI.

Focusing on the results of Phase 1, and focusing on the Security Rule, should be your starting point in preparing for Phase 2 HIPAA Compliance.

Following the Trends

Looking at the trends that we have seen with HIPAA enforcement actions and settlements leading into Phase 2 HIPAA Audits, there’s an obvious emphasis on Risk Analysis. As noted from the Phase 1 Audit results, most organizations struggled with the Security Rule, and that begins with a Risk Analysis. To perform a Risk Analysis, you must ask yourself, what are the assets we need to protect? Where do we hold PHI? What are our handling processes when dealing with PHI? What are the risks to the PHI in our possession? Is this a high risk or a low risk? Once you understand the answers to these questions, you can then prioritize and properly manage these risks.

The second trend is data breaches. We still constantly see data breaches in the headlines, and when you look at the breaches that are happening in the healthcare industry, the common cause is theft of electronic media. This could be a lost laptop, thumb drive, tape backup, or off-site media storage that was lost with unencrypted data. The most important thing to take away from this trend would be to encrypt everything, including removable media and mobile devices.

The final trend to takeaway from the Phase 1 HIPAA Audits is actions by the Attorney’s General. The Department of Health and Human Services (HHS) conducted trainings for the AG’s offices across the U.S. and the HITECH Act gave some enforcement action to the states. It may be helpful to be aware that state authorities can and may get involved in the event of an incident or consumer complaints.

What to Expect with Phase 2 HIPAA Compliance Audits

There are three major changes to expect with the upcoming Phase 2 HIPAA Audits, which are a Protocol Update, Online Portal, and Desk Audits. So far, the updated protocol has not been published. The current HHS protocol is on the HHS’s website, and is a good place to start when considering what we need to do to prepare. The Auditor column shows exactly what the OCR will be looking for and how they will follow certain procedures in determining your compliance with HIPAA.

There will be an Online Portal that will be used for data collection. Each entity will be given access to this portal where they will then upload documentation and answer questions that will be delivered to the OCR audit team. The evidence that you provide will be used to validate and determine whether or not you are in compliance with HIPAA.

Another difference with this phase of audits is the Desk Audit. The Desk Audit will be the remote audit submitted through the online portal of questionnaires and requests for information. This doesn’t include an onsite component but it’s important to keep in mind the kinds of questions the auditors will be asking themselves while reviewing your documentation. How did they answer the questions? What documents did they submit? This aspect of Phase 2 will be led by the OCR with contracted support from KirkpatrickPrice among a few other firms.

Phase 2 Desk Audits

500 questionnaires will be sent out to a group of Covered Entities. Of those 500, 200 Covered Entities will be selected and 40 Business Associates (which is determined based on the selected CEs). It is important to answer the questionnaires as thorough as possible because there will be no interaction between you and your auditor during this phase. Your documentation needs to be clear and concise so they can review and make their findings. After the findings have been drafted, they are issued and sent to the entity to perform a management review of the report. Lastly, the final report will be issued, and is where settlements and enforcement actions can occur depending on the outcome of the audit.

What Covered Entities Should Know

As a Covered Entity, three areas that will be reviewed during a Phase 2 Desk Audit are the Security Rule, identifying and notifying patients of data breaches, and the Privacy Rule. The questionnaires relating to the Security Rule will focus on things like device and media control. How do you control the transport of media throughout your organization? How do you control and secure devices? Another thing to focus on is the transmission of data and transmission security. How are you securing the electronic sending of data across the internet or across different systems in your organization? They will also focus on your Risk Analysis and Risk Management. Are you performing a formalized analysis on the risks posed to the PHI you handle? Do you understand what your risks are? What is your Risk Management plan? How are you assessing and managing those risks?

What Business Associates Should Know

For business Associates, the Security Rule should be the main focus. Organizations like managed IT vendors, records storage facilities, and application service providers should focus on Risk Analysis, Risk Management, and data breach notification to Covered Entities.

Phase 2 Onsite Audits

The Phase 2 HIPAA Audits will include both Covered Entities and Business Associates and will consist of 24 onsites, 3 to 5 days in length. These will be more comprehensive than the Desk Audits and will be conducted, in person, by an officer of the OCR. The types of things that will occur during the audit are interviews of personnel to corroborate information and obtain an understanding of how the employees operate, an examination of operations and how data flows through the entity, a review of policies and procedures, and observation of processes for compliance.

How To Prepare

  1. Conduct a Security Rule risk assessment and implement a risk management plan.
    • Evaluate your policies and procedures related to PHI vulnerability, accessibility, and integrity. Are they adequate and cover all necessary areas? After all risk are identified, what needs to be adjusted?
    • Identify all systems that include PHI by doing a data flow walkthrough. How does PHI enter your environment? Where does it go? What are the risks?
    • Evaluate security measures to reduce risk as part of your risk management plan. Now that you’ve identified the risks, what are you, as an organization, going to put in place to address those risk. Be sure to document your risk management plan.
  1. Breach Reporting (impermissible acquisition, use, access, or disclosure of PHI)
    • Evaluate your policies and procedures for providing notice and follow-up.
    • Evaluate your breach notice content and timeliness.
  2. Privacy Notice and Access
    • Evaluate your policies and procedures.
    • Evaluate privacy notice practices.
    • Evaluate Business Associate Agreements.

 

For more information regarding the Phase 2 HIPAA Audits, contact us today. To view the press release issued by the Office for Civil Rights, click here.

 

Last month, an audit of HealthCare.gov uncovered some basic flaws in the security of the government’s healthcare website. The Personally Identifiable Information (PII) of millions of health insurance customers was being stored in a database that, fortunately, was never compromised by way of cyberattack.

Medical records are not stored in the system, however, names, Social Security numbers, birth dates, addresses, and phone numbers of customers were left vulnerable to attacks. Among the vulnerabilities found by the ethical hacker were information security control issues, as well as 135 database vulnerabilities in which 22 were classified as severe or catastrophic.

The major vulnerabilities that were found have led us to a few key takeaways that are important to be aware of when securing your own PII for which you are responsible:

1. Unencrypted user sessions

Not encrypting user sessions goes against standard practices. If your Session ID allows access to PII, it should never be left unencrypted. This can lead to a session being hijacked by an attacker, compromising the confidentiality of PII.

2. Shared read-only account for access to the database that contained PII

This is a MAJOR vulnerability. If any data was stolen, it would be impossible to determine who was accessing what information at what time. Shared accounts are typically reserved for a “guest” or “temporary” account, one that does not have access to a database containing PII. These accounts should be privileged, secured with strong passwords and/or two-factor authentication.

3. Failure to disable “generic accounts”

These are the types of accounts that are anonymous and used for maintenance during testing. After the testing phase is over, generic accounts should be disabled and default passwords changed. This eliminates vulnerabilities by using the principle of least privilege. If it’s not needed for securing the data, it should be disabled or removed.

4. Failure to conduct regular vulnerability scans

We are learning quickly that performing regular Penetration Tests and Vulnerability Scans is a great way to prevent against a data breach. It’s the most consistent and efficient way to learn about the holes in your security before someone else does. The process uncovers and exploits vulnerabilities, giving you a chance for remediation.

There are certainly lessons to be learned from the vulnerabilities found in HealthCare.gov’s security. You will never know what gaps lie in your security unless you test it. Train your employees to be aware of the importance of security in the workplace. Don’t let a data breach be a surprise to you – be proactive about your security.

As a PCI Qualified Security Assessor (QSA), we receive a lot of questions and concerns from clients who are just stepping into their first PCI assessment, particularly around PCI Requirements 5 and 6; maintaining a vulnerability management program.

We have recently sat down with one of our own QSA’s, Steve McEnroe, QSA, CISA, to answer some of the major questions we commonly hear. Here are the highlights from the interview:

Q: In regards to Requirement 5, do you recommend having the “periodic evaluations to identify and evaluate evolving malware threats” performed by a third party? Or should they be done internally?

A: This is something that is typically done internally and should be part of your ongoing Risk Assessment process. Keep up with evolving threats and be aware of industry developments and the potential threats your business may face. A lot of this information is distributed through various vendor websites and even mainstream media. Threats will also be identified through your ongoing scanning and penetration testing, which falls under Requirement 11 of the DSS, but certainly applies here.

Q: At a minimum, how often would you recommend periodic scans be performed? Why?

A: A full server scan is typically performed once a week, during off-business hours. Scanning of any work stations that are in scope should be done more frequently, and typically on a nightly basis. A lot of anti-virus and malware systems now have live, real-time scanning where workstations are being constantly evaluated. Why? Workstations are inherently a weak point because people are using them, and people are the weakest link in your security.

Q: What are some examples of instances where it may be okay to temporarily disable your anti-virus solution?

A: Occasionally it may be necessary if you need to install a particular software package. That should be a very temporary situation, and you should re-engage anti-virus software as soon as you’re finished with the installation.

Q: What are your thoughts on how often these “security policies and operational procedures for protecting systems against malware” should be updated?

A: All policies and procedures should be reviewed and updated at least annually. All documentation should contain a revision history so that your QSA can see the different phases the document has gone through. Anytime there is any significant change to the environment, at a technical or business level, your documented procedures should be updated. This is applicable to PCI Requirements 5 and 6.

Q: How often should organizations be checking to identify security vulnerabilities?

A: It’s really an ongoing process, but you want to be subscribed to any information coming out from your vendors (Microsoft or any other big software packages you have). Third-party websites (www.securitytracker.com) and mainstream media will address some of these issues as well. Do necessary investigations, relate any vulnerabilities to your environment, and take steps to keep your environment patched and secure.

Q: How do you go about finding out what security patches you need?

A: Vendors have made this much easier now and there’s a lot of great software out there for managing vendor patches. Most people will configure workstations to auto-install Microsoft patches on the workstation level. For servers, you let those download but you never let those go into production unattended because they can cause resets or other issues. Vendors will be one of the first levels of notifications, as well as your regular vulnerability scans, to help keep you on top of the security patches you may need.

Q: Are there any guidelines on how to incorporate information security into your software development?

A: Yes, there are a lot of good whitepapers out there that are good resources, particularly www.SANS.org. When developing an application, or making major changes to one, you want to think about security from the very beginning. Companies are moving fast, often with a limited budget and time to give to application development, resulting in security being left out. Keep in mind to bake it in from the beginning rather than tacking it on at the end. Make proper planning decisions to ensure you’re protecting cardholder data appropriately.

Q: Would you recommend an automated or manual process when it comes to code review? Why?

A: I would say a hybrid of the two. Code review applications can be a bit pricy, and there are other open source type solutions that can be useful, however, a peer should also be looking at your code. A set of human eyes is very beneficial to make sure developers are staying aligned with development best practices. Also, when undergoing a PCI assessment, your QSA is going to want to see documentation that this is taking place. Is there a checklist being used? If you’re using an automated tool is there a report that’s produced? These artifacts will be what your QSA will be looking for.

Q: Why is it important to separate development/test environments from production environments?

A: Development/test environments can be less secure in some cases. Sometimes you’re working with hardcoded elements in the software or information in the database as well that could be a weakness. You don’t want that information tied to your production environment. Typically, developers shouldn’t have access to the production environment. There should be some kind of admin role for the cardholder data environment (CDE) to do the actual deployments to the production environment. In a smaller organization, the developer is doing deployments, however, a proper level of oversight, and separate and unique user credentials to the system should be used. There are different security levels for these two different environments.

Q: How do you recommend training developers in secure coding techniques?

A: There is a lot of computer based training for this. OWASP is a great place to go for web based coding best practices and content on how to code in defense of a lot of web based vulnerabilities that are out there. Some organizations host internal training based on OWASP or various other material. The main thing we want to stress is that there needs to be a clear, documented process for training in place that can be demonstrated to your QSA.

Q: Are there any other coding vulnerabilities that need to be addressed?

A: When you analyze the information you get from the outside world, vendors, third-party websites (www.securitytracker.com), and your own vulnerability scanning results, you think about how those vulnerabilities could be related to a coding vulnerability.

Q: I know it’s recommended to review public-facing web applications for vulnerabilities at least annually, but how often would you recommend performing a review?

A: Any time you make a change to your web application you’ll want to test it, either using tools internally or through a third party to ensure that you have not introduced a vulnerability through this change that was just implemented.

Q: How frequently should your policies and procedures be reviewed?

A: Your policies and procedures should be reviewed at least annually. Any time a major change occurs, those should be documented immediately. The big thing to take away from this is that all policies and procedures should be clearly documented at all times. This is stressed in both PCI requirements 5 and 6 as well as the entire DSS. Relevant personnel should have this communicated to them, and acknowledge the receipt and review of that document.

Q: At what point in the process of preparing for a PCI audit should a company engage a QSA?

A: As soon as you know you need to go through the process, you should start looking for a QSA and get an agreement in place. You should consider doing a Gap Assessment so you can become familiar with the DSS, your QSA can become familiar with your company, and your QSA can help you understand any gaps in your processes.

Preparing for and undergoing a PCI assessment doesn’t have to be overwhelming. If you are in need of a Gap Assessment or a free consultation to see if you’re ready for your PCI audit, contact us today.

More Resources

Beginner’s Guide to PCI Compliance

Guide to PCI Policy Requirements

6 Steps of a PCI Audit