Re: Question about HIPAA Compliance in application development

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

On Tue 4/26/2011 11:13 AM, Rohit Sethi wrote:

> It sounds like people generally deal with this through techniques
> outside of the application logic itself such as checksums and/or
> digital signatures on files / database values that contain protected
> health information.  My initial thought was that databases would offer
> some kind of integrity check feature and that seems to be the feeling
> from people on the list as well.

First, I think that 'checksums' are not going to meet the HIPPA need. They
will allow you to detect ACCIDENTAL data integrity issues such as
detecting typos upon data entry, data corrupted by disk errors, etc.,
but they do NOT allow you to detect DELIBERATE tampering attempts that
would affect data integrity. Chances are that any attacker who has
the ability to change the data can also re-compute and store the
updated checksum.  So you need a cryptographically strong mechanism to
detect such data integrity issues. Generally, that leaves you with
HMACs or digital signatures. (Or store the data encrypted using a
cipher mode that also provides authenticity, such as GCM, CCM, etc.
Shameless plug: Note that the default configuration for symmetric encryption
in ESAPI 2.0 provides authenticity so if you need to encrypt the data
anyway, that might be a valid approach for you.)

However, *in general*, DBs do not offer this type of protection, especially
if there is a concern with a privileged attacker (say a rogue DBA) making
unauthorized changes to the database. (Some of the features with packages
like Oracle's Transparent Data Encryption may provide this, but generally
it is not something that is part of the vanilla DBMS. The data integrity
issues that a DBMS addresses are _referential_ integrity, not *content*
data integrity.)

> Has anyone actually implemented this kind of control *within* custom
> application logic? For example, verifying the integrity of stored
> protected health data by (for example) checking that a digital signature
> is valid before displaying it back to the user?

I was tech lead on a project that we did this, but it was unrelated to
HIPPA. It was a project that dealt with some very sensitive data.
The application associated each DB record with an HMAC.  The HMAC
key was computed by the application, based on a derived key from a Shamir
shared secret calculated by signed Shamir shares entered by at least 2
authorized operations personal when the application cluster was
initialized. This was done to explicitly prevent the threat of rogue DBAs
changing the extremely sensitive data or changing who was authorized to
access to that sensitive data. When the data was retrieved from the DB,
the HMAC was computed from all the other columns and them compared with
the stored HMAC column for that record. If they did not agree, a security
exception was logged and thrown. (HMACs were used instead of dsigs because
they are so much faster in computing and nonrepudiation was not an issue.)

If you are not concerned with rogue DBAs as a threat source, this logic
could be placed in the DB itself using triggers and stored procedures (or
just stored procedures if you don't have an legacy code base and you
somehow prevent direct inserts / updates). If you are interested in
pursuing that angle, you may want to reference Kevin Kenan's
book, _Cryptography in the Database: The Last Line of Defense_.

Finally--and this is probably obvious to most SC-L readers--you need to
ensure that your application has no SQLi vulnerabilities that would allow
data to be altered in an unauthorized manner. If you don't, then the HMAC
or dsig or whatever you are using to ensure data integrity will simply
be inserted / updated by your application or DB code like it would for
an otherwise legitimate authorized attempt.

HTH,
-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
_______________________________________________