Re: Question about HIPAA Compliance in application development

["Wall, Kevin" <Kevin.Wall () qwest com>]

Jim Manico wrote...
> The most cost-effective way to handle these requirements is to get
> your HIPPA auditor drunk nightly.

Uh..., the old bribery and extortion approach. ;-)

> I'm being partially serious here because these and other HIPPA
> requirements are:
>
> (1) Technically ambiguous
> (2) Often in conflict with other HIPPA requirements
> (3) Impossible to achieve cost effectively

That's what happens when you let a bunch of politicians and
lobbyists mandate security & privacy regulations.

Seriously, PCI DSS started much the same way (and still is to
a degree, but not nearly as bad as DSS 1.0). I recall asking a
PCI auditor for clarification of section 3.6.4 of DSS 1.0, which
merely said (regarding encryption keys)

    3.6.4. Periodic key changes

So, I naturally asked the auditor "how often do we have to change the
encryption keys"? He replied, "It doesn't say...just every so often."
So I said, "OK, we'll change ours every 1000 years." He then said he
needed to get clarification from his management and he eventually came
back a few weeks later and said that we at least need to change them yearly.

Later, PCI DSS 1.1 later revised this particular section to say:

    3.6.4 Periodic changing of keys
    + As deemed necessary and recommended by the associated application
      (for example, re-keying); preferably automatically
    + At least annually.

So, pushing back on the auditors does work if you know how to push their
buttons to get clarity.

Of course, I'd also say, if one's whole point to HIPPA is merely in
passing the HIPPA auditor's inspection, then you're missing the whole
point of HIPPA. Sometimes we need to remind *our management* of that
as sometimes passing the audit supersedes all other needs including
providing actual security and privacy.

> For example, there are HIPPA access control requirements that demand
> that you only give doctors access to transmit patient data in a minimal
> way; only transmitting data needed for a diagnosis. Good luck coding that.
> It's also bad medicine.

What? You're not comfortable letting some obscure developer make
decisions about what information your doctor needs to make a proper
diagnosis??? Why not? What could *possibly* go wrong? :-p

Of course, as developers and/or security consultants, it's important that
we point out such absurdities to our HIPPA auditors. Eventually when
they slowly see a pattern developing, we can only hope a light bulb
goes on and the appropriate parties decide we need v2.0 thus keeping all
of us employed for yet another 3 or 4 years. ;-)

-kevin
--
Kevin W. Wall           CenturyLink / Risk Mgmt / Information Security
Kevin.Wall () qwest com    Phone: 614.215.4788
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME




This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________