Summarized changes to Section 308 of HIPAA Security

Yesterday, I gave you the side-by-side comparison of changes to Section 308 in the new HIPAA Security rule.  Today, I will summarize these changes below.

Section 308 added a lot of new material, retaining most of the old with greater detail, especially with respect to implementation specifications.  Procedures within this section now need to more than just implemented, they must be written (documented), tested/verified and maintained. Maintenance is a new implementation specification that applies to almost everything and means that the material must be updated at least annually, as well as when needed due to changes.

In addition to risk assessment, 164.308(a)(1) [formerly 308(a)(1)(i)] now requires a technology asset inventory, network map and maintenance. This is a normal part of risk analysis best practice, but HIPAA now requires it of covered entities and their business associates.

The risk analysis is now in 164.308(a)(2) [formerly risk assessment at 308(a)(1)(ii)(A)], and now includes "Implementation specifications" which require covered entities and business associates again to follow risk assessment best practices with respect to an asset inventory, list of threads, potential vulnerabilities, likelihoods, impacts, and risk levels, including risks associated with business associates, and it further clarifies the maintenance requirements, with a minimum of at least annual, or after any change in environment.

Instead of their being a singular section for implementation specifications, there is a separate implementation section for each standard.

New standards have been added at 164.308(a)(3) for evaluation of changes to a covered entity or business associates environment, and at 164.308(a)(4) for patch management.  Personally, I'd change the name of (a)(3) from Evaluation to Change Management to more closely reflect its intent. Both of these are application of existing technology risk management best practices.

On the (a)(4) patch management side, the proposed rule expects remediation of critical risks in 15 days, and high risks in 30 days of any patch or upgrade becoming available. They do suggest that alternative methods can be used to reduce risk when patches are not available.  

Nowhere in the patch management section do they use the term risk mitigation, or remediation, and I wish they would.

308(a)(5) Risk Management [formerly 308(a)(1)(ii)(B)] adds a whole section on implementation specifications.  You need a written risk management plan, it has to be maintained, risks must be prioritized, and security measures must be implemented in a timely measure in accordance with the priorities.

308(a)(6) Sanction Policy [formerly 308(a)(1)(ii)(C)] again adds a whole section on implementation specifications. Again, these must be established, written, reviewed at least annually or on significant changes, and applied, with applications documented.

308(a)(7) Information Systems Activity Review [formerly 308(a)(1)(ii)(D)] again adds a whole section on implementation specifications. The scope is defined to include at a minimum: audit trail, event logs, firewall logs, data backup logs, access reports, anti-malware logs, security incident tracking reports, et cetera.  Includes topics such as records retention, incident response and records thereof, and the required maintenance of process.

308(a)(8) Assigned Security Responsibility [formerly 308(a)(2)] clarifies to ensure that process is written/documented

308(a)(9) Workforce Security [formerly 308(a)(3)] was modestly updated clarifying that the process is written/documented.

The Termination procedure was updated to indicate minimum time before termination of access (one hour from termination time).

The Notification procedure was updated to indicate minimum time before notification of others (e.g., BAs) of rescinded access of 24 hours. The usual annual maintenance requirement was added.

308(a)(10) Information Access Standards [formerly 308(a)(4)] adds implementation specifications for (9)(ii)(C) Authentication Management, (E) Network segmentation, and (F) Maintenance.

308(a)(11) Security Awareness Training was updated [formerly 308(a)(5)] and provides significantly more guidance on the timing, content and documentation of training activities.

308(a)(12) Security Incident Procedures [formerly 308(a)(6)] was updated to add implementation specifications requiring written incident response plans, written procedures for testing and revising plans, and annual (or more frequent) testing and documentation.

308(a)(13) Contingency Plan [formerly 308(a)(7)] was updated.  Again, it was clarified that plans need to be written, assessments need to be documented, backups need to be verified, and contingency plans and emergency mode operation plans need to be tested at least annually.

308(1)(14) Compliance Audit [formerly Evaluation at 308(a)(8)] was renamed and the text (but not the intent) simplified.

308(b)(1) Business Associate Contracts standards is largely unchanged, but 308(b)(2) Implementation Specifications adds a requirement for annual written verification that a Business Associate is in compliance with 164.312 through a written analysis and certification.

Thinking?

The title  of this post is a response to a question in my household when someone says "What were you thinking?" when after due consideration the recipient realizes, Oh yeah, that was probably not so smart.

It's the question I had on receipt of a "secure email" the other day, coming from a healthcare institution.  I won't name the institution because the solution is a commercial one from crafted by an Internet security provider (Proofpoint) that apparently thinks it is a good idea.  Let me explain how it works to you:

When someone sends an e-mail that this software thinks needs to be protected, the software takes the body of the e-mail, encrypts it in some form, base-64 encodes the content of an e-mail into an XML payload, then base-64 encodes that into an HTML form.  It then sends that HTML page in an e-mail as an attachment to the original recipient.  In the body of the e-mail is an official looking page containing the sender logo, a lock icon, and text which explains that you have received a secure e-mail and that in order to access it, you either need to open the attachment, or click on a link.

I'd love to do a video that shows how this system works, and compare it to a phishing attack.

Consider that you have just received an e-mail that appears to be from an institution that you have a relationship with.  It looks official, and bears the correct logo [highlight the institution logo on both the phishing and secure e-mail].  When you click on the "more information" link, it clearly goes the institution's web site, which you can quite readily verify.  The email asks you to Open the attached file to obtain your secure message.  Feeling secured by all that you have done to ensure you security, you now open the attachment.  Once again, it looks very good and official, bears the right logos, and even bears a copyright from a trusted security provider.  It asks you to click a button to retrieve your message.

You do so.  At this stage you are now taken to an HTTPS page on the web which has a long URL which looks right on quick glance, and that asks you, since this is your first time to create a user name and password to access your message.  So far, both systems appear to work in nearly the same way.  So, you create your account.

One of these systems will then decrypt the packet sent to you and the other will send your username and password to pirate bay, where someone will then drain all your bank accounts.

The question is, should you open this attachment?  The answer in both cases is, for most people.  Hell no.

1. You don't have the training to distinguish the attached file (which may contain a zero day exploit) from any other attached file which could infect your computer.
2. You shouldn't expose your password management procedures to others whose security you cannot verify.  Many of you have pretty poor ones to begin with (like I use the same username and password for everything).
3. Any of the italicized items in the scenario above are things that ANY competent software engineer or hacker can do.  In fact, if it can be done, a hacker doesn't need to do it him or herself, they can very likely simply steal it.

Why does an internet security provider believe that encouraging people to engage in behavior that security experts advise against, and other security products protect against, would be a good idea? Well, that goes back to another common response in my family to the "What were you thinking?" question:

It seemed like a good idea at the time?

-- Keith

P.S.  When I first saw this message, I actually thought it had originated from my corporate security folks, who craft similar messages in order to encourage people to take their phishing refresher class, an honor I have thus far managed to safely avoid (it's the reward for clicking on an attachment or link in their generated e-mails).  Yes, I get phished internally as training on what to avoid.

That takes guts

Normally I do this post Wednesday morning, but quite honestly had day job and personal distractions (I'm moving in about a week) this week, so I'm doing it today.  Wednesday morning at the HL7 Plenary the God Father of Health Level 7, Ed Hammond gives out the Ed Hammond awards, and I traditionally also give out an ad hoc award.  I do that not so much to compete with Ed (I hope I can do what he does when I reach that degree of tenure)., but to continue the tradition.

Tuesday morning I saw a combination of ribbons on an HL7 Member's badge that I found stunning. They were "First Time Attendee" and "Co-chair".  When I asked further, I discovered that this person was a new co-chair of perhaps the most technically challenging, and also difficult collection (which is a compliment, not a critique) of people to manage.  The Security Workgroup is relatively small, but contains some of the top names in Health IT Security, and has always been a very challenging place to engage.  I leave that to my colleague John Moehrke, who has much more experience in this area.  I know enough about security to know that I'd rather defer to seasoned experts that to try to do it myself.

So this combination of badges deserves special recognition, because while it takes guts as an HL7 first-timer to join the Security workgroup, it takes even more than that be willing to co-chair the group.  An extra special thanks and here we go ...

This certifies that 

Alexander Mense of HL7 Austria 

Has hereby been recognized for for having the guts to take on a role as cochair of the HL7 Security Workgroup

Security vulnerabilities in C-CDA Display using CDA.xsl

Today, Josh Mandel posted a security report about CDA.xsl which is an example Stylesheet used by HL7 to illustrate how to generate HTML from a CDA document.  The example XSLT has several security holes which can be taken advantage of by an attacker when a system blithely uses it to display a CDA document without first checking to be sure that it is valid according to the CDA standard.

I won't spend to much time on the details since Josh covers them rather well and also did so quite responsibly.  There are two quick fixes against the attacks, an additional attack he didn't mention which is that the referrer attack (his third attack listed) may also be used against the <IFRAME src=''/> content produced by the sample stylesheet.

So let me briefly outline three mitigations, and note that these are not the only ones you might use, and that more analysis is probably needed (the danger of providing a partial solution is that people who have been burned once by using someone else's work can all into that trap again.  Learn your lesson and investigate further):

1. Prevent any output of a src or href attribute in the HTML that doesn't resolve to an http: or https: path. Better yet, don't use IFRAMEs.
2. Validate any CDA document against the CDA schema supplied by HL7 before you display it, and refuse to display an invalid document without first confirming with the end user that this document may result in a system compromise (in case it is really an essential document for patient care).  This has the effect of preventing documents containing the invalid content from being able to generate unexpected attributes.
3. Don't use a browser control you don't have full security control over to display your documents.  Be sure to configure the controls that you do use to NOT generate Referrer headers.  And don't include private state information in your URLs that can be used to attack your system.

And more importantly, the lessons learned from this experience which HL7 or any other SDO should consider:

1. HL7 published code samples should go through the same kind of analysis and testing that real world code goes through because it is likely seen to be authoritative.
2. Any HL7 published code should clearly note that it is the recipient's responsibility to ensure that appropriate security precautions are taken when implementing the code.
3. Someone should be identified as being responsible for identifying and addressing security issues related to the standard, and these should be published in the standard.  IETF and IHE already have procedures that ensure this occurs.  
4. The HL7 TSC should approve some policies in this area and specific guidance on security issues related to these sorts of examples, and the HL7 Security Workgroup should make some recommendations to the TSC for their approval.

And one some additional one for anyone (Vendor or Provider) using SOUP (Software of Unknown Pedigree).  You have a responsibility to your end users to ensure your product is secure.  That means that if you don't understand the security risks associated with SOUP, you need to do the analysis yourself and be sure that appropriate security precautions are taken.  

Thanks Josh for finding this, and for taking a very responsible and difficult route to ensure that everyone was notified.

For those of you readers who need a fix: the analysis above is incomplete.  At best it serves as a quick patch if you are just learning about it which you can use to mitigate the issues until you investigate further.

Keep up with Josh's additional posts because his work will be more complete, and I hesitate to duplicate it^*. I can hardly do better than someone who has been so well recognized for his contributions to standards, twice now.

   Keith

P.S.  Congratulations Josh, you are the first and probably last to receive those two awards (unless John decides to have a different policy).

ABBI Security

Designing for Security is incredibly important.  As John Moehrke will often tell you, you shouldn't be adding it as an afterthought.  The key to securing the ABBI Protocol that I'm proposing are the two URLs it exposed.  These are originally specified by the IHE Mobile Access to Health Documents profile (and will be subtly modified in my proposal):

Search: https://<location>/net.ihe/DocumentDossier/search[.atom|.json]

Document Access: https://<location>/net.ihe/Document/<entryUUID>/

The first is the search URL which returns the atom feed or json representation, and the second is used to access possibly transformed document content.  These two URLs must be secured using SSL (ideally TLS, but I'm not going to require that for other reasons), and the user (the patient) must also somehow "log in" to the application.  

Securing my web application ought to be straighforward.  I'm using Tomcat, JSP and Servlets, and web application security is pretty much built in to the deployment model.  I identify the resources that need to be secured (the two I mentioned above) in a <security-constraint> element in my deployment descriptor:

<security-constraint>

  <web-resource-collection>

    <web-resource-name>SecurePages</web-resource-name>

    <description>Security constraint for ABBI Resources</description>

    <url-pattern>/net.ihe/*</url-pattern>

  </web-resource-collection>

 ...

Indicate the required user role:

 ...

  <auth-constraint>

    <description>only let users login </description>

    <role-name>user</role-name>

  </auth-constraint>

 ...

Specify the degree of content protection needed:

 ...

  <user-data-constraint>

    <description>SSL required (Change to NONE for testing ONLY)</description>

    <transport-guarantee>CONFIDENTIAL</transport-guarantee>

  </user-data-constraint>

 ...

And lastly indicate how the user is to login:

 ...

  <login-config>

    <auth-method>?</auth-method>

  </login-config>

</security-constraint>

Now here is where it gets tricky.  To demonstrate how logins are secured, I want to use OAuth.  I'm not going to use OAuth 2.0 just yet (because it is harder to demonstrate).  My first step will just be to demonstrate secure access via OAuth 1.0, as employed by Twitter.

Unlike common authentication protocols, these don't typically deal with usernames and passwords.  Instead, the OAuth protocol deals with three separate sets of credentials.  The first set belong to the application (e.g., my ABBI Server), and are simply used to request a temporary set of credentials (which are the second set). That second set of credentials are sent by my server to the by the end user's credential holder site (in this case Twitter), to authorize my application.  Twitter returns to my server the final set of credentials, which are what my ABBI server uses to perform requests on the user's behalf.

All I will be doing with those credentials is getting back the user's Twitter handle, and that only to demonstrate that I've successfully authorized my application.

I have four choices for how to enable the user to log in.  These are:

• BASIC: Uses HTTP-Authorization headers and the Basic Authentication method.
• DIGEST: Uses HTTP-Authorization headers and the Digest Authentication method.
• FORM: Uses form based authentication with specified parameters for 
• CLIENT-CERT: Authenticates using a client certificate

None of these is a perfect match for what I want, but of the four, FORM is the closest to what I need. Here's a classic example of a login page:

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Login Test: Login Form</title>

</head>

<h1>Login Form</h1>

  Welcome to the login page.

    <form method="POST" action="j_security_check">

      Username: <input type="text" name="j_username"><br />

      Password: <input type="password" name="j_password"><br />

 <br />

      <input type="submit" value="Login">

      <input type="reset" value="Reset">

    </form>

</html>

Clearly, that isn't the "OAuth" way.  So there's a bunch of stuff I need to do to hack this into what I want. Here's how I think I can make it work: 

1. In my ABBI Server, I'll send a POST Request to Twitter's request_token URL.  It's authorization header will contain my application's "login credentials".  
2. Twitter will respond to my server with three parameters containing the credentials needed to authorize the application.  These will become part of a URL request that will appear within a frame and/or dialog the my server will create in the page and which will be launched for the user. 
3. After the user logs in to Twitter, the Twitter authentication page will redirect the user back to my application (in that frame and/or dialog), passing back appropriate application access credentials.  
4. My server will store the application access credentials, and will send back some sort of fake values for j_username and j_password that will make my web application server happy.

I ought to be able to create a form that will do the necessary, which means I can insert the following for the login-config portion.

  <login-config>
    <auth-method>FORM</auth-method>
    <realm-name>ABBI</realm-name>
    <form-login-config>
        <form-login-page>/login.jsp</form-login-page>
        <form-error-page>/lerror.jsp</form-error-page>
    </form-login-config>
  </login-config>

This step is probably going to take me a bit of time, because I've never done it before, and there are lot of tricky bits.

There's a bunch of easy stuff that follows this step, but I'm taking the approach that I need to work on the hard stuff first.  While OAuth isn't rocket science, it certainly qualifies as the most risky component of my prototype right now.  Everything else is pretty-much "rote" programming that I know can be done, even if I haven't written the code yet.  This is the one part that I'm not so sure about.  Even though it isn't using the same version of OAuth that RHEx has specified, I feel comfortable enough that if I can demonstrate OAuth 1.0, that eventually, I'll be able to plug into 2.0.  That's just an incremental refinement.

For demonstration purposes, I'll need to link the Twitter account to a patient identifier.  In real life, the application would get that via an API call to the service protected by the OAuth access credentials.  This could also be done using PIX/PDQ.  The provider offering the service would request the user to supply a user id (e.g., a Twitter account) that only they had access to.  That service would register that identifier with a master patient index.  When the user "logged-in" to the ABBI service, we'd get the account identifier that they logged in with, and query the master patient index using PIX to get the associated patient identifier that the registry used to provide access to the patient records.

As I finish this, I realize that I need to do a security risk assessment for this application.  Sounds like another blog post.

  -- Keith

ONC releases New Guide on Health Information, Privacy and Security and MeaningfulUse

ONC's New Guide on Health Information, Privacy and Security and Meaningful Use ONC's Office of the Chief Privacy Officer (OCPO) recently released a "Guide to Privacy and Security of Health Information,"* an instructional guide designed to help healthcare practitioners, staff, and other professionals better understand the important role privacy and security play in the use of electronic health records (EHRs) and Meaningful Use. The guide is a comprehensive, and easy-to-understand tool to help providers and professionals integrate privacy and security into their clinical practice and includes sections addressing: ·       Privacy & Security and Meaningful Use ·       Security Risk Analysis and Management Tips ·       Working with EHR and Health IT Vendors ·       A Privacy & Security 10-Step Plan ·       Health IT Privacy and Security Resources Full Guide: Check out the full Guide to Privacy and Security of Health Information: http://www.healthit.gov/sites/default/files/pdf/privacy/privacy-and-security-guide.pdf. Sections of the Guide: You can also download individual sections of the guide. Please visit the privacy and security section under the Providers & Professionals tab on HealthIT.gov: http://www.healthit.gov/providers-professionals/ehr-privacy-security   Together, we can build a culture where privacy and security are respected and valued to inspire confidence and trust in health IT and electronic health information exchange by protecting the confidentiality, integrity, and availability of health information. *OCPO developed this guide with assistance from an ONC cooperative agreement partner, the American Health Information Management Association (AHIMA) Foundation.

Security, Masking, and Legal Signatures in CDA

A while back I made a statement about how "Masking" interferes with the wholeness and legal authenticity of a document that has been signed in CDA.  Someone recently asked for clarification on the point that I made:

The main problem with "MASKING" as it were are that in implementing such an infrastructure you are interfering with the wholeness and legal authenticity of the content being viewed. 

So, to clarify:

1. In CDA, the legal signature attests that the provider has legally signed (and is thereby taking responsibility) for the content in the whole document.
2. That signature does not necessarily apply to the provider taking responsibility for a "MASKED" version of the document, as masking could eliminate critical information.

What the signature means in this case depends on how one interprets the applicable policies. 

Two other questions were also asked:

1. What is the legal authenticity of a CCD?
   
   CDA documents need not be signed, but can be.  A CCD does not require a legal signature, that is up to organizational policies.  A couple of other points: The signature of a CDA document (and thus a CCD) is not a "digital signature".  Instead, it is an "electronic signature".  The latter is merely a mark indicating that a signature has been obtained.  The former is a strong mathematical proof that it was obtained.  For more information on using digital signatures with CDA documents, see two excellent posts from John Moehrke:
1. IHE Privacy and Security Profiles (a detailed Bloginar on several security related topics)
2. Signing CDA Documents
2. Does a CCD have to be diplayed in its entirety?
   
   How the CCD is used depends upon also upon organizational policy.  The advice I give is that if the use case is to "summarize the encounter" to a human, to display the whole content, but there are plenty of other uses that may not have that same requirement, such as medication reconciliation.

In all cases, the actually resolution of these questions would need to be addressed by local policy.  Local policy is a phrase you will frequently hear security geeks use to mean:  Governing laws, regulation and the procedures instituted by organizations to implement them.  Essentially that means that the CDA and CCD specifications do not set forth what is the "legal authenticity".  Those decisions are made in courts.  They do however, support procedures that enable others to establish the "legal authenticity".