[VOIPSEC] Privacy Regs/HIPAA- was SRTP thread
Mark Teicher
mht3 at earthlink.net
Sun Apr 3 20:01:47 CDT 2005
As this was my initial response to the poster, as the verbiage is very
vague, and a company that offers a HIPPA lockdown service for PBX,
voicemail and other communication infrastructure components would be rather
vague or difficult to understand by an enterprise that is attempting to be
in compliance
At 06:47 PM 4/1/2005, Harris, Michael C. wrote:
>An opinion of someone in the trenches fighting with this every day...
>
>Actual HIPPA verbiage in the federal register is very vague and can
>largely be interpreted as "follow industry standards and best
>practices". http://www.hipaa.org/ or see the security section of (sorry
>for the long link)
>http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&tpl=/ecfrbrowse/Title45/45cfrv1_02.tpl
>
>
>There is no clear instruction for communications or networking
>infrastructure and there is no direct ruling about requiring encryption
>either. There are some unique call outs for analog fax.
>
> >From there it is my belief that the NIST 800-66 document and others like
> it will be the gold standard of industry best practices against which we
> will be judged. At this point there is no case law or real enforcement
> to go along with the either the Security or Privacy portions of the
> rule. Future case law will probably make the determination, but until
> complaints make it to court and are ruled upon we really have no strong
> direction to follow.
>
>------------------------------------
>Mike Harris
>System Security Analyst & Instructor
>University Of Missouri Health Center
>harrismc at health.missouri.edu KCØPAH
>------------------------------------
>
>
>-----Original Message-----
>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>Behalf Of Bonnell, Joseph D (Joe)
>Sent: Tuesday, March 29, 2005 2:52 PM
>To: voipsec at voipsa.org
>Subject: [VOIPSEC] Privacy Regs/HIPAA- was SRTP thread
>
>For those that are under the delusion that communications systems today
>are comprised of tin cans, play string, and post-it notes, you can ignore
>this post. For the rest of us that are chartered with adhering to these
>standards from a communications system security perspective, read on.
>
>This thread is timely. Someone forwarded me this newly published document
>this morning (thanks) soliciting my input. This boring but important NIST
>doc was created to condense down the information security requirements
>pertaining to the HIPAA security rule.
>
>http://www.csrc.nist.gov/publications/nistpubs/800-66/SP800-66.pdf
>
>On a humorous note, if you read through SP800-59 (which is a document that
>the federal government uses to classify all information systems), you'll
>come to the inevitable conclusion that any information system could also
>communication tools such as tin cans, play string, and post-it notes. ;-)
>
>http://www.csrc.nist.gov/publications/nistpubs/800-59/SP800-59.pdf
>
>
>Enjoy,
>
>J
>
>Joe Bonnell CISSP NSA-IAM| Manager, Communications System Security
>Services | Avaya Global Services |720.444.4410| jobo at avaya.com |
>www.avaya.com/security
>
>
>-----Original Message-----
>From: Bonnell, Joseph D (Joe)
>Sent: Sunday, March 27, 2005 9:12 PM
>To: voipsec at voipsa.org
>Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
>
>I don't agree with the assessment or conclusions based upon the reference
>to service providers (or the USPS) within the HIPAA regs- then again, it's
>not my goal to necessarily enlighten the well-opinionated to my view of things.
>
>For those that understand the intent of either privacy act, the
>demarcation points of information ownership, and the inner workings of
>enterprise-class technologies, you'll get what I'm talking about.
>
>For those that are responsible for enterprise communications in either
>vertical, the _least_ of your worries is the latest implementation of
>whatever VoIP protocol is the topic of the day.
>
>Plz keep in mind I'm not attempting to detract the value that SRTP
>provides (or other likely needed improvements within the various protocols
>that are being relied upon to deliver VoIP) I'm just highlighting some
>other risks that I'm convinced are little understood.
>
>The risks I've identified are real. The ones that fully understand these
>risks will be light years ahead of those that actually believe that "if it
>ain't directly spelled out, then it must not apply".
>
>Back to lurking...
>
>Regards,
>
>J
>
>Joe Bonnell CISSP NSA-IAM| Manager, Communications System Security
>Services | Avaya Global Services |720.444.4410| jobo at avaya.com |
>www.avaya.com/security
>
>-----Original Message-----
>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>Behalf Of Mark Teicher
>Sent: Sunday, March 27, 2005 3:51 PM
>To: voipsec at voipsa.org
>Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
>
>Based on what has been stated regarding VOIP security, one could
>hypothetically utilize
>http://a257.g.akamaitech.net/7/257/2422/14mar20010800/edocket.access.gpo
>.gov/2003/03-3876.htm
>in regards Electronic Data Interchange, depending on the content of the
>information that is transmitted over a VOIP infrastructure (i.e. patient
>
>name, patient information, etc).
>In most cases, as originally stated neither GLBA and HIPAA call out
>enforcement within a communications infrastructure. It is very hard for
>
>organizations who provide VOIP infrastructure equipment to provide that
>type of assurance to enterprises they provide to. Currently there are
>very few organizations who will certify a VOIP infrastructure for security
>compliance let alone GLBA and HIPAA. Even if such assurances were
>provided, an organization providing this type of assurance would be liable
>if any part of the VOIP infrastructure were to fall out of compliance for
>any reason or be compromised by a untrusted party. Indemnification
>policies currently supported by such VOIP managed service providers would
>definitely need to be re-evaluated in the near future.
>
>
>
>At 05:42 PM 3/25/2005, Zmolek, Andrew \(Andy\) wrote:
> >Neither GLBA nor HIPAA specifically call out communications
> >infrastructure. However, since there is no specific exclusion for it,
> >the issue cannot simply be dismissed.
> >
> >For HIPAA the basic test is whether "Protected Healthcare Information"
> >is stored electronically in a given system. In the case of a VoIP call
> >that will only be true if the call is recorded and stored. So voicemail
> >and call recording systems may need to document HIPAA conformance if
> >healthcare information is likely to be discussed. And any call center
> >systems that access healthcare records will need similar documentation.
> >
> >It should be pointed out that there is no requirement (even indirectly)
> >for encryption of signaling or media by HIPAA regulations. In fact no
> >specific mention of voice systems in general (much less VoIP) can be
> >found in the privacy and security regulations, which can be found here:
> >http://aspe.hhs.gov/admnsimp/index.shtml
> >
> >GLBA is similar in that it has a "safeguarding" component distinct from
> >the privacy component we all know about from the disclosures one
> >routinely receives in the mail. A couple of years ago, the FFIEC
>finally
> >came out with detailed guidance to bank regulators (you can find their
> >examination guidelines at
> >www.ffiec.gov/ffiecinfobase/html_pages/it_01.html but you won't see
>VoIP
> >specifically mentioned). It can easily be argued that the risk
> >management program detailed by the FFIEC should apply to VoIP systems
> >just as any other application on the data network. We certainly have
> >customers in the financial sector who believe so and act accordingly,
> >although I've seen a much greater focus from those customers on
> >auditability than on encryption.
> >
> >When it comes to enforcement, GLBA does have a meaningful regulatory
> >surround with regular inspections by regulators who can inflict
> >considerable pain on a non-conforming institution. The same cannot be
> >said of HIPAA which is ultimately overseen by the Office of Civil
> >Rights, who does not perform regular inspections and has only
>threatened
> >action in a handful of egregious cases.
> >
> >
> >/\\//\Y/\ Andy Zmolek
> > GCS Security Team
> > zmolek at avaya.com
> > 303-538-6040
> >
> >
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> >Behalf Of Mark Teicher
> >Sent: Friday, March 25, 2005 11:50 AM
> >To: Bonnell, Joseph D (Joe); Chris at sip1.com; kapnet at mindspring.com;
> >Jeremy George
> >Cc: Voipsec at Voipsa. Org
> >Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >
> >J,
> >
> >Could you provide the sections in GLB and HIPAA where communications
> >infrastructure(s) is impacted?? For some reason I cannot recall those
> >individuals sections..
> >
> >/m
> >
> >-----Original Message-----
> >From: "Bonnell, Joseph D (Joe)" <jobo at avaya.com>
> >Sent: Mar 25, 2005 11:51 AM
> >To: Chris at sip1.com, kapnet at mindspring.com,
> > Jeremy George <jeremy.george at yale.edu>
> >Cc: "Voipsec at Voipsa. Org" <voipsec at voipsa.org>
> >Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >
> >Agreed.
> >
> >Both GLB and HIPAA have enormous impact within the communications
> >infrastructure (irrespective of whether it's a VoIP deployment or not).
> >
> >Unfortunately for most, SOX seems to be getting all the attention so
> >these other legislative directives seem to be lost in the fodder.
> >
> >Regards,
> >
> >J
> >
> >Joe Bonnell CISSP NSA-IAM| Manager, Communications System Security
> >Services | Avaya Global Services |720.444.4410| jobo at avaya.com |
> >www.avaya.com/security
> >
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> >Behalf Of Christopher A. Martin
> >Sent: Thursday, March 24, 2005 7:37 PM
> >To: kapnet at mindspring.com; 'Jeremy George'
> >Cc: 'Voipsec at Voipsa. Org'
> >Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >
> >I believe, if it is considered data, which VoIP is, it falls under the
> >same rules. Then again, those enforcing the regulations barely
> >understand
>the
> >requirements themselves and probably wouldn't even think about VoIP.
> >
> >But that may be a large assumption on my part (but I have seen this
>from
> >some of the auditors that I have run into).
> >
> >Christopher A. Martin
> >P.O. Box 1264
> >Cedar Hill, Texas 75106
> >Chris at InfraVAST.com
> >
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]
> >On
> > > Behalf Of Ken Peterson
> > > Sent: Thursday, March 24, 2005 10:50 AM
> > > To: Jeremy George
> > > Cc: Voipsec at Voipsa. Org
> > > Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> > >
> > > Jeremy,
> > >
> > > Last time I checked, HIPAA doesnt require any kind of voice
> >transmission
> > > to
> > > be secured... including VoIP.
> > >
> > > Cheers,
> > > Ken
> > >
> > > -----Original Message-----
> > > From: Voipsec-bounces at voipsa.org
>[mailto:Voipsec-bounces at voipsa.org]On
> > > Behalf Of Jeremy George
> > > Sent: Thursday, March 24, 2005 9:29 AM
> > > To: voipsec at voipsa.org
> > > Subject: Re: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> > >
> > >
> > >
> > > Will HIPAA requirements drive encrypted voice/IM/video ?
> > >
> > > - Jeremy
> > >
> > >
> > > On Wed, 23 Mar 2005, Brian Raymond wrote:
> > >
> > > > Date: Wed, 23 Mar 2005 20:41:09 -0500
> > > > From: Brian Raymond <brian-lists at dataline.com>
> > > > To: kapnet at mindspring.com, VoIPsec <voipsec at voipsa.org>
> > > > Subject: Re: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> > > >
> > > > I had a couple of comments for the thread.
> > > >
> > > > Avaya has always supported H.235 for security on H.323 calls so I
> >would
> > > > imagine they are still doing the same now. I'm not sure however
> >which
> > > > profile they are working with these days. There are a number of
> >security
> > > > profiles (Annexes) specifying different algorithms for encryption
> >and
> > > key
> > > > management. Related to MIKEY is H.235 Annex G, which is MIKEY and
> >SRTP
> > > for
> > > > transport. Signaling of H.225 is generally encrypted via TLS or
> >IPSEC,
> > > at
> > > > least what I've seen. Key exchange for media is over H.245 however
> >the
> > > > method is specific to the profile.
> > > >
> > > > I agree with some of the other members that the main reason there
> >isn't
> > > a
> > > > focus on application level security is that the market just hasn't
> > > demanded
> > > > it. That's starting to shift now but as someone who has previously
> > > worked
> > > > for a commercial vendor of a number of H.323/SIP products we never
> >saw a
> > > > real demand from customers for that type of support. Any customers
> >who
> > > > required security implemented it at layer 2/3 using some sort of
> >VPN.
> > > This
> > > > was generally not an issue because that type of system was already
> >in
> > > place
> > > > most of the time and provided much greater endpoint flexibility.
> > > >
> > > > I have supported the government sector for a few years now and
>even
> >in
> > > what
> > > > are considered high(er) security environments with arguably
>critical
> > > data
> > > to
> > > > protect transport encryption was never a real issue. Again this is
> >all
> > > > changing now and I'm seeing a number of splintered implementations
> > > popping
> > > > up. Most people I have talked to are only familiar with their
> >specific
> > > > application's protocol implementation and when designing a
>solution
> > > aren't
> > > > concerned about interoperability. This is actually quite
>interesting
> > > because
> > > > these same applications are using standards to foster
> >interoperability.
> > > >
> > > >
> > > > - Brian
> > > >
> > > >
> > > >
> > > > On 3/23/05 6:05 PM, "Ken Peterson" <kapnet at mindspring.com> wrote:
> > > >
> > > >> Ian,
> > > >>
> > > >> The only major vendor doing official SRTP, to my knowledge, is
> >Cisco in
> > > >> release 4.1 of their CallManager, which was just released last
> >fall.
> > > The
> > > >> signaling channel is protected via TLS - both phone and CM server
> >have
> > > >> certificates to authenticate each other. Over this "always-up"
> >control
> > > >> channel, they speak Cisco's proprietary Skinny protocol. During
> >call
> > > setup,
> > > >> the CM sends a shared symmetric key to both IP endpoints. The
> >endpoints
> > > >> then
> > > >> speak SRTP using AES-128 encryption and SHA-1 HMAC.
> > > >>
> > > >> I know of one major government organization that is implementing
> >this
> > > >> solution as we speak. They are the rare exception, however.
> > > >>
> > > >> Avaya's solution is supposed perform a similar process, but using
> > > H.323.
> > > >> Their release date was pushed back last time I checked (was
> >supposed to
> > > be
> > > >> out now.) Currently Avaya is using 102-bit AEA (Avaya Encryption
> > > Algorithm)
> > > >> between phones... I assume the voice is encapsulated in SRTP, but
>I
> > > could
> > > >> be
> > > >> wrong... anyone else know? The key exchange (again Im not
>confident
> >in
> > > >> this,
> > > >> due to Avaya's lack of documentation) should be a Diffie-Helman
> > > exchange
> > > >> over the H.225 control channel. Is that D-H exchange
>authenticated
> >to
> > > avoid
> > > >> MITM attacks? I would hope so, but I've seen no evidence to
>support
> > > that.
> > > >>
> > > >> Cheers,
> > > >> Ken
> > > >>
> > > >>
> > >
> >***********************************************************************
>*
> > > >> * *
> > > >> * Ken Peterson, CCIE 4297 * Cisco Certified Security
>Professional
> > > >> * PacketBrain, Inc. * Cisco IP Telephony Support
> >Specialist
> > > >> * Cary, NC 27511 * Cisco Content Networking
> >Specialist
> > > >> * *
> > > >>
> > >
> >***********************************************************************
>*
> > > >>
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: Voipsec-bounces at voipsa.org
> >[mailto:Voipsec-bounces at voipsa.org]On
> > > >> Behalf Of Brian Rosen
> > > >> Sent: Wednesday, March 23, 2005 4:44 PM
> > > >> To: Ian.Cuthbertson at nokia.com; Voipsec at voipsa.org
> > > >> Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> > > >>
> > > >>
> > > >> There is not much deployment yet.
> > > >> One of the reasons is confusion on key exchanges.
> > > >> Another is there is not (yet) much demand.
> > > >>
> > > >> Brian
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Voipsec-bounces at voipsa.org
> >[mailto:Voipsec-bounces at voipsa.org]
> > > On
> > > >>> Behalf Of Ian.Cuthbertson at nokia.com
> > > >>> Sent: Wednesday, March 23, 2005 12:10 PM
> > > >>> To: Voipsec at voipsa.org
> > > >>> Subject: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> Does anyone have a take on how widely deployed SRTP is in the
>real
> > > >>> world? Are all vendors offing solutions which include this
> >(gateway,
> > > >>> handset etc)? Which key exchange methods do they support?
> > > >>>
> > > >>> Thanks, Ian
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Voipsec mailing list
> > > >>> Voipsec at voipsa.org
> > > >>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Voipsec mailing list
> > > >> Voipsec at voipsa.org
> > > >> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Voipsec mailing list
> > > >> Voipsec at voipsa.org
> > > >> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > >>
> > > >
> > > >
> > > > _______________________________________________
> > > > Voipsec mailing list
> > > > Voipsec at voipsa.org
> > > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > >
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > >
> > >
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
More information about the Voipsec
mailing list