RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Tag: EHRs

Security Logging and Monitoring for EHRs

If you are like most medium or large healthcare providers these days, your Electronic Health Record (EHR) environment is likely a very complex one. Such complexity brings with it a fair amount of difficulty in monitoring the environments for security incidents.

Monitoring for security incidents is different from privacy monitoring

Many such healthcare providers have also likely invested in privacy monitoring solutions over the last few years. These investments have been driven largely by the HIPAA Security/Privacy rule or Meaningful Use mandates as well as the  need to be able to identify and respond effectively to privacy incidents or complaints.

Privacy monitoring use cases fall into a fairly limited set of categories – e.g. snooping of neighbor, workforce member or celebrity records. Given the nature and the somewhat narrow definition of these use cases, many organizations appear to be doing a good job in this respect. This is especially the case when organizations have implemented one of the leading privacy monitoring solutions.

While such organizations have notable success with monitoring for privacy incidents,  the same can’t be said for monitoring of security incidents. This is so despite the fact that most of these organizations have invested substantively in security – be it security monitoring solutions such as Security Information and Event Management (SIEM)  orservices such as third party managed security services.

Where is the problem and what might we do about it?

In our experience, the lack of effective security monitoring capabilities across EHR environments can be usually attributed to the lack of appropriate security logs to begin with. And, it is usually not a straightforward problem to solve for more than one reason. The most common reason is the complex nature of the applications and their diverse sets of components or modules. Many of the EHRs were not designed with good security monitoring, in our view.  One can also point to the rather complex and custom workflows at each organization that these EHRs support.

Solving this problem usually requires a specialist effort by personnel who have a strong background in security (and security monitoring). We also need who have specialist knowledge and experience with the respective EHR applications. After all, each EHR application is unique in how the vendors have implemented their security and security logging features.

How could we help?

Our RiskLCM services can help develop a strategy and assist with implementing a sustainable security monitoring program for your EHR(s). We have experience doing this for Epic and Cerner among others and can help you leverage your existing security/privacy monitoring technologies or managed services investments.

Please leave us a message at +1 312-544-9625 or send us a note to RiskLCM@rnc2.com if you would like to discuss further.

You may also be interested in a case study.

Thank you!

Docs turn up the heat on ONC! – Security Commentary

HealthcareITNews reported yesterday on this letter that was written by several physician organizations to the ONC.

I wanted to write a couple of quick thoughts on the security aspects raised in the letter. I highlighted relevant parts on pages 1 and 2 of the letter with annotations #1, #2 and #3.

Here then are my thoughts on the three items…

#1

#1

We agree with this point. We have talked about our security related concerns around the EHR Certification process and the Meaningful Use program previously. Here and here are a couple of posts for example.

The first link has our commentary we published on the OIG report being referred to in the letter.

The second linked post on Patient Portals has specific details of our thoughts on the security criteria in the MU and Certification programs. We also discussed specific due diligence recommendations for providers. These recommendations should also apply to Electronic Health Records (EHRs) for the most part.

 

#2 and #3

#2

#3

These two paragraphs in the letter speak to the Identity and Access Management (IAM) related concerns, in particular around stronger authentication and usability.

We couldn’t agree more on these points. I am also glad the letter highlights the need for strong authentication.

It is no secret that IAM programs in general haven’t lived up to the promise and expectations. Healthcare provider settings in particular provide specific challenges, primarily because of the need for IAM to really be “transparent” and support clinical workflows seamlessly. We know this continues to be a challenge at most healthcare provider organizations. The point being made in the letter should come as no surprise to anyone.

In our view, an effective solution to this problem requires the IAM/HealthIT product vendors as well as IAM/Security consultants to “up” the game.

And then,  healthcare providers (especially the larger ones who have the power and influence to move their vendors to act) have an important role to play in bringing the IAM and HealthIT vendors to the table so we have viable technology options available to us. We first talked about it  at this webinar back in 2013, but I don’t think we are anywhere close to seeing viable technology options yet in leading vendor solutions.

 

In summary, I think these security related arguments being made in the letter are very valid. However, I am not sure how much ONC can do to move us forward. At best, I think the ONC can only “take the horse to the water” as it were. I really think we need both the IAM and HealthIT vendors to step up and collaborate actively to deliver viable solutions. And the healthcare providers need to push the vendors to do it.

I hope this has been a helpful read. Please don’t hesitate to leave your thoughts below, good or bad.

Patient Portals – Make or Break

Like many other Health IT initiatives today, the primary driver for patient portals is regulatory in nature. Specifically, it is the Meaningful Use requirements related to view,  download or transmit and secure messaging. However, the biggest long term benefit of the portals might be what they can do for patient engagement and as a result, to the providers’ business in the increasingly competitive and complex healthcare marketplace in the United States.

The objective of this post is to discuss the security aspects of patient portals, specifically, why the current practices in implementing these portals could pose a big problem for many providers. More importantly, we’ll discuss specific recommendations for due diligence actions that the providers should take immediately as well as in the longer term.

Before we get to discuss the security aspects, I think it is important to “set the stage” by discussing some background on patient portals. Accordingly, this post covers the following areas in the indicated sequence:

1. What are patient portals and what features do they (or could) provide?

2. Importance of patient engagement and the role of patient portals in patient engagement

3. The problem with the current state in Health IT and hence the risks that the portals bring

4. Why relying on regulations or vendors is a recipe for certain failure?

5. What can/should we do (right now and in the future) –  Our recommendations

1. What are Patient Portals and what features do they (or could) provide?

I would draw on information from the ONC site for this section. Here is the pertinent content, to quote from the ONC site:

A patient portal is a secure online website that gives patients convenient 24-hour access to personal health information from anywhere with an Internet connection. Using a secure username and password, patients can view health information such as:

• Recent doctor visits

• Discharge summaries

• Medications

• Immunizations

• Allergies

• Lab results

Some patient portals also allow patients to:

• Exchange secure e-mail with their health care teams

• Request prescription refills

• Schedule non-urgent appointments

• Check benefits and coverage

• Update contact information

• Make payments

• Download and complete forms

• View educational materials

The bottom-line is that patient portals provide means for patients to access or post sensitive health or payment information. In the future, their use could expand further to include integration with mobile health applications (mHealth) and wearables. Last week’s news from EPIC should provide a sense for things to come.

2. Importance of patient engagement and the role of patient portals in patient engagement

As we said above, the primary driver for patient portals so far has been the Meaningful Use requirements related to view,  download or transmit and secure messaging. However, the biggest long term benefit of the portals might be what they can do for patient engagement and becoming a key business enabler for providers.

The portals are indeed a leading way for providers to engage with patients, as can be seen in this graphic from the 2014 Healthcare IT Priorities published by InformationWeek1.

image

Effective patient engagement of course can bring tremendous business benefits, efficiencies and competitive edge to providers.

From a patient’s perspective, the portals can offer a easier method for interacting with their providers which in turn has its own benefits for patients. To quote from the recently released HIMSS report titled “The State of Patient Engagement and Health IT”2

A patient’s greater engagement in health care contributes to improved health outcomes, and information technologies can support engagement.

In essence, the importance of patient portals as a strategic business and technology solution for healthcare providers doesn’t need too much emphasis.

3. The problem with the current state in Health IT and hence the risks that the portals bring

In my view, the below quote from the cover page of the 2014 Healthcare IT Priorities Report published by InformationWeek1 pretty much sums it up for this section.

Regulatory requirements have gone from high priority to the only priority for healthcare IT.

We all know what happens when security or privacy programs are built and operated purely to meet regulatory or compliance objectives. It is a shaky ground at best. We talked about it in one of our blog posts last year when we called for a change in tone and approaches to healthcare security and privacy.

4. Why relying on regulators or vendors is a recipe for certain failure of your security program?

It is probably safe to say that security in design and implementation is perhaps not the uppermost concern that HealthIT vendors have (certainly not the patient portal vendors in my opinion) today. To make it easy for them, we have lackluster security/privacy requirements in the regulation for certifying Electronic Health Records.

Consider the security and privacy requirements (yellow in this pdf) that vendors have to meet in order to obtain EHR certification today. You will see that the certification criteria are nearly not enough to assure the products are indeed secure enough before the vendors can start selling them to providers. And then, the administration or enforcement of the EHR certification program has been lacking as well in the past.

If you consider a risk relevant set of controls such as the Critical Security Controls for Effective Cyber Defense, you will see that the certification criteria are missing the following key requirements in order to be effective in today’s security threat landscape:

· Vulnerability assessments and remediation

· Application Security Testing (Including Static and Dynamic Testing)

· Security training for developers

· Penetration tests and remediation

· Strong Authentication

Think about using these applications to run your patient portals!

If you are a diligent provider, you will want to make sure that the vendor has met the above requirements even though the certification criteria do not include them. The reality though may be different. In my experience, providers often do not perform all the necessary due diligence before purchasing the products.

And then, when providers implement these products and attest to Meaningful Use, they are expected to do a security risk analysis (see the green highlighted requirement in the pdf). In my experience again, risk analysis is not performed in all cases. Of those that perform them, many are not really risk assessments.

The bottom-line? … Many providers take huge risks in going live with their patient portals that are neither secure nor compliant (Not compliant because they didn’t perform a true risk analysis and mitigate the risks appropriately).

If you look again (in 1 above) at the types of information patient portals handle, it is not far-fetched to say that many providers may have security breaches waiting to happen. It is even possible that some have already been breached but they don’t know yet.

Considering that patient portals are often gateways to the more lucrative (from a hacker’s standpoint) EHR systems, intruders may be taking their time to escalate their privileges and move laterally to other systems once they have a foothold in the patient portals. Considering that detecting intrusions is very often the achilles heel of even the most well-funded and sophisticated organizations,  it should be a cause for concern at many providers.

5. What can/should we do (right now and in the future) –  Our recommendations

It is time to talk about what really matters and some tangible next steps …

What can or must we do immediately and in the future?

Below are our recommendations for immediate action:

a) If you didn’t do the due diligence during procurement of your patient portal product, you may want to ask the vendor for the following:

· Application security testing (static and dynamic) and remediation reports of the product version you are using

· Penetration testing results and remediation status

· If the portal doesn’t provide risk based strong (or adaptive) authentication for patient and provider access, you may insist on the vendor committing to include that as a feature in the next release.

b) If you didn’t perform a true security risk analysis (assessment), please perform one immediately. Watch out for the pitfalls as you plan and perform the risk assessment. Make sure the risk assessment includes (among other things) running your own vulnerability scans and penetration tests both at network and application layers.

c) Make sure you have a prioritized plan to mitigate the discovered risks and of course, follow through and execute the plan in a timely manner.

Once you get through the immediate action steps above, we recommend the below action items to be included in your security program for the longer term:

a) Implement appropriate due diligence security measures in your procurement process or vendor management program.

b) Have your patient portal vendor provide you the detailed test results of the security requirements (highlighted yellow in the attachment) from the EHR certifying body. You may like to start here (Excel download from ONC) for information on the current certification status of your patient portal vendors and the requirements they are certified for.

c) Ask the vendor for application security (static and dynamic) and pen test results for every release.

d) Segment the patient portal appropriately from the rest of your environment (also a foundational prerequisite for PCI DSS scope reduction if you are processing payments with credit/debit cards).

e) Perform your own external/internal pen tests every year and scans every quarter (Note : If you are processing payments with your payment portal,  the portal is likely in scope for PCI DSS. PCI DSS requires you to do this anyway).

f) Conduct security risk assessments every year or upon a major change (This also happens to be a compliance requirement from three different regulations that will apply to the patient portal –  HIPAA Security Rule, Meaningful Use and PCI DSS, if processing payments using credit/debit cards).

g) If you use any open source modules either by yourself or within the vendor product,  make sure to apply timely patches on them as they are released.

h) Make sure all open source binaries are security tested before they are used to begin with.

i) If the vendor can’t provide support for strong authentication,  look at your own options for proving risk based authentication to consumers. In the meanwhile, review your password (including password creation, reset steps etc.) to make sure they are not too burdensome on consumers and yet are secure enough.

j) Another recommended option is to allow users to authenticate using an external identity (e.g. Google, Facebook etc. using OpenID Connect or similar mechanisms) which may actually be preferable from the user’s standpoint as they don’t have to remember a separate log-in credential for access to the portal. Just make sure to strongly recommend that they use 2 step verification that almost all of these social media sites provide today.

k) Implement robust logging and monitoring in the patient portal environment (Hint : Logging and Monitoring is not necessarily about implementing just a “fancy” technology solution. There is more to it that we’ll cover in a future post)

In summary, there is just too much at stake for providers and patients alike to let the status quo of security in patient portals continue the way it is. We recommend all providers take priority action considering the lasting and serious business consequences that could result from a potential breach.

As always, we welcome your thoughts, comments or critique. Please post them below.

References

1 2014 Healthcare IT Priorities published by InformationWeek
2 The State of Patient Engagement and Health IT(pdf download)

 Recommended further reading

Patient engagement – The holy grail of meaningful use
Patient portal mandate triggers anxiety
MU Stage 2 sparks patient portal market

PCI Breaches – Can we at least detect them?

Almost all Payment Card Industry (PCI) breaches over the past year, including the most recent one at Supervalu appear to have the following aspects in common:

1. They involved some compromise of Point of Sale (POS) systems.

2. The compromise and breaches continued for several weeks or months before being detected.

3. The breaches were detected not by the retailer but by some external entity – FBI, the US Secret Service, Payment processor, card brands, issuing bank etc.

4. At the time the breach was disclosed, the retailers appear to have had a passing PCI DSS certification.

Anyone that has a reasonable understanding of the current Information Security landscape should know that it is not a matter of “if” but “when” an organization will get compromised. Given this humbling reality, it only makes sense that we must be able to detect a compromise in a “timely” manner and hopefully contain the magnitude of the breach before it gets much worse.

Let’s consider the following aspects as well:

  1. PCI has one of the more prescriptive regulations in the form of PCI DSS and PA DSS than any other industry. As a case in point, consider the equivalent regulations for Electronic Health Records systems (EHRs) in the United States – the EHR Certification regulation (PA DSS equivalent) requirements highlighted yellow in this document and the Meaningful Use regulation (PCI DSS equivalent) requirements highlighted green. You will see that the PCI regulations are a lot more comprehensive both in breadth and depth.
  1. PCI DSS requires merchants and service providers to validate and document their compliance status every year. For the large retailers that have been in the news for the wrong reasons, this probably meant having a external Qualified Security Assessor (QSA)  performing a on-site security assessment and providing them with a passing Report on Compliance (ROC) every year.
  1. As for logging and monitoring requirements that should help with detection of a potential compromise,  both PCI DSS (Requirement 10)  and PA DSS (Requirement 4) are as detailed as they get in any security framework or regulation I am aware of.
  1. Even if you think requirement #10 can’t help detect POS malware activity, there is PCI DSS requirement 12.2 that requires a security risk assessment to be performed at least once a year. The risk assessment must consider the current threats and vulnerabilities. Given the constant stream of breaches, one would think that the POS malware threats are accounted for in these risk assessments.
  1. These large merchants have been around for a while and are supposed to have been PCI DSS compliant for several years. And so, one would think they have appropriate technologies and processes to at least detect a security compromise that results in the scale of breaches they have had.

So, what do you think may be the reasons why the retailers or the PCI regulations are not effective in at least detecting the breaches? More importantly, what changes would you suggest, both to the regulations and also to how the retailers plan and execute their security programs? Or perhaps even to how the QSAs perform their assessments in providing passing ROCs to the retailers?

I’m keen to hear your thoughts and comments.

How useful is the HHS OIG report published this week?

I am sure some of you saw this news report about HHS OIG finding some security related deficiencies in the EHR certification program.

I was keen to read the full OIG report (pdf) which I did get a chance to do this evening. I know HHS OIG does great work overall but I must say I didn’t come away feeling very good about the quality or usefulness of this particular report, for the following couple of reasons:

  1. The report was really of an audit performed in 2012 of the 2011 EHR certification program which doesn’t even exist in 2014. What value does it provide if OIG has ONC providing responses to this audit report in 2014? Shouldn’t OIG have sent this report to ONC soon after they did the audit in 2012 so the report could have led to changes in the program when it still existed? It appears this OIG audit and the report could have been a better use of taxpayer dollars had it been timely.
  2. I am not sure OIG has done a good job of substantiating why they don’t agree that the 2014 certification criteria addresses their concerns. They provide an example of multi-factor authentication not being included in the 2014 criteria. While multi-factor authentication would obviously provide for better security, does OIG think all access to EHRs must be protected by multi-factor? Or is it perhaps only remote access (meaning access from outside the trusted network say a hospital facility)? Security in healthcare can’t come at the expense of user experience of providers and clinicians. Requiring multi-factor at all times is going to impact clinician productivity and hence patient care. Also, OIG should have known that multi-factor technologies are still not (or at least were not when ONC finalized the 2014 criteria) at a point where they can be used as the mandatory baseline authentication mechanism in EHRs without compromising user experience. If I remember correctly, the HealthIT Standards Committee (HITSC) did consider 2 factor authentication for inclusion in the 2014 criteria but decided to exclude it for “practicality” reasons. To sum up on this point, I think OIG could have been more objective in their opinions on 2014 criteria.

In closing, I am not sure what process or protocols does OIG follow but it appears this audit report could have had better impact if it had been more timely, objective and actionable.

Pay attention to Security Risk Analysis in Meaningful Use Attestation

As is well known, Centers for Medicare & Medicaid Services (CMS) has been conducting pre and post payment audits of healthcare provider organizations attesting to Meaningful Use (MU).  Our experience tells us that providers do not always exercise the necessary due diligence in meeting Stage I MU Core Objective #14 (Eligible Hospitals) and #15 (Eligible Professionals). In our view and as supported by ONC’s 10 Step Plan for Meeting Privacy and Security Portions of Meaningful Use, the MU Security Risk Analysis needs to go well beyond assessing just the technical controls of a EHR system. We believe that the risk analysis should cover the people and process aspects of EHR operations as well as how the EHR interfaces with other systems, organizations, people or processes.

As noted in a previous post, College of Healthcare Information Management Executives (CHIME), a professional organization for chief information officers and other senior healthcare IT leaders seemed to hold the view that the MU Security Risks Analysis scope should be limited. While we do not have a complete insight into CHIME’s viewpoint, we believe that providers need some work to do if they are to meet the requirements effectively. A robust security risks analysis is in any case the right thing to do every time there is a change in the Health IT environment … and implementing a EHR should qualify as a major change in that regard. It is also a mandatory compliance obligation under the HIPAA Security Rule.

So, why not do the “right thing”? We highly recommend that providers avoid “checkbox compliance” tendencies when it comes to meeting MU Core Objective #14/15.

Providers – Is HIPAA Security Risk Analysis in your plan over the next few months?

Security Risk Analysis is something that we recommend all organizations conduct periodically or before a  significant process or technology change. After all, threats, vulnerabilities and impact (three components of risk, see my other post here) often change or evolve over time which means that risk analysis results can soon become outdated.

In the context of Healthcare, Security Risk Analysis is also mandatory for two reasons.

The first reason is that it is required for compliance with HIPAA Security Rule which, by way of the HITECH Act, now applies to Business Associates in addition to Covered Entities.  It is a “Required” Implementation Specification in the “Security Management Process” standard under Administrative Safeguards of the HIPAA Security Rule, as highlighted in the table below.

image

The second (and more urgent) reason to conduct a Security Risk Analysis is that it is a core requirement for providers to achieve Meaningful Use certification of Electronic Health Records (EHRs) and thereby become eligible for Medicare/Medicaid incentives beginning April 2011 or risk Medicare reimbursement penalties beginning 2015 (see below).

image image

clip_image001[3]

Source: Center for Medicare & Medicaid Services (CMS)


So, it is important that providers plan on conducting a security risk analysis within the next few months unless you have conducted one recently. If you have already implemented an EHR system, you will need to ensure that the risk analysis included the EHR system and the related processes or practice workflows. If you plan to implement an EHR system in the next few months, we would recommend conducting risk analysis before the implementation so that any discovered risks can be identified and mitigated by proper design of the system and associated workflows or processes.  Any change to the system or processes after implementation is going to be hard, not to talk of the disruption to the practice and other costs.

The Final Guidance from OCR on Risk Analysis can be a useful reference in planning and conduct of risk analysis efforts.

Finally, I would like to go back to what I said right at the beginning. We recommend that organizations focus on managing all information risks, not just the risk of non-compliance with regulations such as HIPAA.  Therefore, it is critical that personnel performing the risks analysis are up-to-date on the current threat environment. Upon determination of the threats, one must be able to clearly identify the organization’s vulnerabilities to those threats and then the impact resulting from any exploits and various legal or compliance obligations including HIPAA.  Last but not the least, risk analysis must be conducted at appropriate intervals and certainly whenever there is a significant change in processes or technologies.

—————————————-

Important Disclaimer

The guidance and content we provide in our blogs including this one is based on our experience and understanding of best practices. Readers must always exercise due diligence and obtain professional advice before applying the guidance within their environments.