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.w...@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 _______________________________________________