Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Wall, Kevin 
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.w...@qwest.comPhone: 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
___

Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Chris Schmidt 
> 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.

Sounds like contextual access control to me - someone wrote a pretty good blog 
about that once :)

I do however, agree on the bad medicine point - just like in diagnosing 
software bugs, often something seemingly unrelated to the problem you are 
addressing is either a contributing factor or the root of the problem itself! 
This is why engineers should be the ones writing the standards instead of 
standards authors. :)

Sent from my iPwn

On Apr 26, 2011, at 12:19 PM, James Manico  wrote:

> Rohit,
> 
> The most cost-effective way to handle these requirements is to get your HIPPA 
> auditor drunk nightly.
> 
> 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
> 
> 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.
> 
> And now, let me leave you with a few lyrics from the Bon Jovi song "bad 
> medicine". He was singing about medical software, I'm fairly sure:
> 
> "I ain't got a fever got a permanent disease
> And it'll take more than a doctor to prescribe a remedy
> And I got lots of money but it isn't what I need
> Gonna take more than a shot to get this poison outta me
> And I got all the symptoms, count 'em 1, 2, 3"
> 
> ;)
> Jim Manico
> 
> On Apr 26, 2011, at 2:35 AM, Rohit Sethi  wrote:
> 
>> Hi all,
>> 
>> Has anyone had to deal with the following HIPAA compliance requirements 
>> within a custom application before:
>>  
>> 
>> §164.312(c)(2)
>> 
>> Implement electronic mechanisms to corroborate that electronic protected 
>> health information has not been altered or destroyed in an unauthorized 
>> manner.
>> 
>>  
>> 
>> §164.312(e)(2)(i)
>> 
>> Implement security measures to ensure that electronically transmitted 
>> electronic protected health information is not improperly modified without 
>> detection until disposed of.
>> 
>> 
>> 
>> How have you actually implemented these controls in applications? Have you 
>> used a third party tool to do this? Does §164.312(c)(2) simply boil down to 
>> sufficient access control?
>> 
>> -- 
>> Rohit Sethi
>> SD Elements
>> http://www.sdelements.com
>> twitter: rksethi
>> 
>> ___
>> 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
>> ___
> 
> ___
> 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
> ___
___
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
___

Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Rohit Sethi 
Yeah, it really looks like some of these are boiling down to the auditor's
discretion.  I realize there are a lot of ways to "ensure data integrity"
(thanks for a good summary Kevin). I was hoping to learn which specific ways
people have used to pass HIPAA compliance in the past, but it doesn't look
like there's any clear answer here.

On Tue, Apr 26, 2011 at 2:19 PM, James Manico  wrote:

> Rohit,
>
> The most cost-effective way to handle these requirements is to get your
> HIPPA auditor drunk nightly.
>
> 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
>
> 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.
>
> And now, let me leave you with a few lyrics from the Bon Jovi song "bad
> medicine". He was singing about medical software, I'm fairly sure:
>
> "I ain't got a fever got a permanent disease
> And it'll take more than a doctor to prescribe a remedy
> And I got lots of money but it isn't what I need
> Gonna take more than a shot to get this poison outta me
> And I got all the symptoms, count 'em 1, 2, 3"
>
> ;)
> Jim Manico
>
> On Apr 26, 2011, at 2:35 AM, Rohit Sethi  wrote:
>
> Hi all,
>
> Has anyone had to deal with the following HIPAA compliance requirements
> within a custom application before:
>
>
>
> §164.312(c)(2)
>
> Implement electronic mechanisms to corroborate that electronic protected
> health information has not been altered or destroyed in an unauthorized
> manner.
>
>
>
> §164.312(e)(2)(i)
>
> Implement security measures to ensure that electronically transmitted
> electronic protected health information is not improperly modified without
> detection until disposed of.
>
>
> How have you actually implemented these controls in applications? Have you
> used a third party tool to do this? Does §164.312(c)(2) simply boil down to
> sufficient access control?
>
> --
> Rohit Sethi
> SD Elements
> http://www.sdelements.com
> twitter: rksethi
>
>  ___
> 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
> ___
>
>


-- 
Rohit Sethi
SD Elements
http://www.sdelements.com
twitter: rksethi
___
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
___

Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread James Manico 
Rohit,

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

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

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.

And now, let me leave you with a few lyrics from the Bon Jovi song "bad
medicine". He was singing about medical software, I'm fairly sure:

"I ain't got a fever got a permanent disease
And it'll take more than a doctor to prescribe a remedy
And I got lots of money but it isn't what I need
Gonna take more than a shot to get this poison outta me
And I got all the symptoms, count 'em 1, 2, 3"

;)
Jim Manico

On Apr 26, 2011, at 2:35 AM, Rohit Sethi  wrote:

Hi all,

Has anyone had to deal with the following HIPAA compliance requirements
within a custom application before:



§164.312(c)(2)

Implement electronic mechanisms to corroborate that electronic protected
health information has not been altered or destroyed in an unauthorized
manner.



§164.312(e)(2)(i)

Implement security measures to ensure that electronically transmitted
electronic protected health information is not improperly modified without
detection until disposed of.


How have you actually implemented these controls in applications? Have you
used a third party tool to do this? Does §164.312(c)(2) simply boil down to
sufficient access control?

-- 
Rohit Sethi
SD Elements
http://www.sdelements.com
twitter: rksethi

 ___
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
___
___
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
___

Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Wall, Kevin 
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.comPhone: 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_Asso

Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Rohit Sethi 
Thanks Kevin and those who answered me off-list.

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.

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?

On Tue, Apr 26, 2011 at 8:57 AM, Wall, Kevin  wrote:

> Rohit,
> You wrote:
> > Has anyone had to deal with the following HIPAA compliance requirements
> > within a custom application before:
> >
> > §164.312(c)(2)
> > Implement electronic mechanisms to corroborate that electronic
> > protected health information has not been altered or destroyed in
> > an unauthorized manner.
> >
> > §164.312(e)(2)(i)
> > Implement security measures to ensure that electronically transmitted
> > electronic protected health information is not improperly modified
> > without detection until disposed of.
> >
> > How have you actually implemented these controls in applications? Have
> > you used a third party tool to do this? Does §164.312(c)(2) simply
> > boil down to sufficient access control?
>
> Having never had any practical experience with HIPPA, my take on these
> sections
> may be different (read "wrong") than others, but the way I read these
> requirements,
> they have to do more with ensuring data integrity than *merely* proper
> access
> control.
>
> If that is their intent, then I would look at access control as providing a
> necessary, but not sufficient security measure to satisfy these
> requirements.
>
> Consequently, I would think that a mechanism such as HMACs or digital
> signatures
> may be appropriate security measures here.
>
> -kevin
> ---
> Kevin W. Wall   CenturyLink / Risk Mgmt / Information Security
> kevin.w...@qwest.comPhone: 614.215.4788
> Blog: http://off-the-wall-security.blogspot.com/
> "There are only 10 types of people in the world...those who can count
> in binary and those who can't."
>
> 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.
>



-- 
Rohit Sethi
SD Elements
http://www.sdelements.com
twitter: rksethi
___
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
___

Re: [SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Wall, Kevin 
Rohit,
You wrote:
> Has anyone had to deal with the following HIPAA compliance requirements
> within a custom application before:
>
> §164.312(c)(2)
> Implement electronic mechanisms to corroborate that electronic
> protected health information has not been altered or destroyed in
> an unauthorized manner.
>
> §164.312(e)(2)(i)
> Implement security measures to ensure that electronically transmitted
> electronic protected health information is not improperly modified
> without detection until disposed of.
>
> How have you actually implemented these controls in applications? Have
> you used a third party tool to do this? Does §164.312(c)(2) simply
> boil down to sufficient access control?

Having never had any practical experience with HIPPA, my take on these sections
may be different (read "wrong") than others, but the way I read these 
requirements,
they have to do more with ensuring data integrity than *merely* proper access
control.

If that is their intent, then I would look at access control as providing a
necessary, but not sufficient security measure to satisfy these requirements.

Consequently, I would think that a mechanism such as HMACs or digital signatures
may be appropriate security measures here.

-kevin
---
Kevin W. Wall   CenturyLink / Risk Mgmt / Information Security
kevin.w...@qwest.comPhone: 614.215.4788
Blog: http://off-the-wall-security.blogspot.com/
"There are only 10 types of people in the world...those who can count
in binary and those who can't."

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
___

[SC-L] Question about HIPAA Compliance in application development

2011-04-26 Thread Rohit Sethi 
Hi all,

Has anyone had to deal with the following HIPAA compliance requirements
within a custom application before:



§164.312(c)(2)

Implement electronic mechanisms to corroborate that electronic protected
health information has not been altered or destroyed in an unauthorized
manner.



§164.312(e)(2)(i)

Implement security measures to ensure that electronically transmitted
electronic protected health information is not improperly modified without
detection until disposed of.


How have you actually implemented these controls in applications? Have you
used a third party tool to do this? Does §164.312(c)(2) simply boil down to
sufficient access control?

-- 
Rohit Sethi
SD Elements
http://www.sdelements.com
twitter: rksethi
___
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
___