Tim,
I would not agree with your assessment about the threat from external
sources.  Here is a case in point article and there are numerous
articles about the internet vulnerabilities of university healthcare
facilities.

http://online.securityfocus.com/news/122

Regards,

David Frenkel
Business Development
GEFEG USA
Global Leader in Ecommerce Tools
www.gefeg.com
425-260-5030

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, September 17, 2002 12:16 AM
To: Bill Pankey; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Integrity Control and Applications

Bill, without regard to beliefs.  The documented abuse issues revolving
around PHI Privacy and Security have uniformly come from internal
sources,
either the organization using PHI inappropriately, or its personnel
doing
so.  Outside hackers, crackers, and script kitties represent a real
threat,
but a largely unrealized one to date in healthcare.  Regardless,
integrity
comes from assuring authenticity of the whole work flow.  I too agree
that
stamping every packet in any extraordinary way is unnecessary, that the
use
of standard best practice safeguards, encryption using SSL for web
transmission (or intranet), with additional infrastructure safeguards,
such
as: active monitored intrusion detection (such as CounterPane), coupled
with
strong firewalls, antivirus software on a network level, thorough models
and
documentation, and complete security practices and policies address most
issues.  As long as there is a strong process in place to stay current
with
security, that's most of the battle.

However, I recently had the displeasure to hear about an application
being
implemented that negates all of this.  We can't forget the applications
themselves.  Frankly, in my opinion, applications should be looked at
VERY
carefully as a major potential source of both integrity breakdown, and
Security AND Privacy vulnerabilities.  Code reviews, where possible,
should
be a part of both privacy AND security risk assessments and gap analysis
when dealing with custom apps and even many commercially available apps
based upon platforms like MSSQL, Oracle, DB2/400, etc.  By their very
nature, many universal reporting tools to give full access are used.
Also,
application development tools that build in unknown features over and
above
the specific programmatic requirements are common - do you know what
overhead code or libraries are compiled into your finished app?  Far to
many
have residual access for maintenance or performance monitoring, or
excessive
access far beyond minimum necessary.  I'm not concerned about
Microsoft's OS
and its auto-update intentions, but I am concerned about webapps and
enterprise apps that phone home, that have maintenance backdoors, or no
real
thought to security beyond a password.  Many apps created using standard
tool sets have their own unique set of vulnerabilities over and above
those
of the OS.  This includes webapps that allow patient access with
extensive
tracking mechanisms built in.  All of these need to be carefully
factored
into your security and privacy model.

Apps also need to be included in the policies and procedures of an
organization - most do not.  From a Privacy perspective, some of the
greatest danger comes from webapps used in clinical practice.  Huge
numbers
of "Spyware" are automatically installed on user's systems.  One such
called
"Gator" actually sends home the contents of every HTML form filled in.
Other so-called browser plug-ins are equally bad.  Some Spyware cons the
user into installing it for its enhanced feature set, but most is almost
unavoidable being installed with the display of banner ads or on less
than
ethical websites.  Anti-Spyware tools need to be used in addition to
antivirus software, and the organization's policies need to tightly
control
the uses of systems used for enterprise purposes, especially if they
access
the web, where a simple java applet can easily defeat the best central
firewall (hence the reason for human monitoring services, and spyware
detectors).  In short, there are a number of things that can be done to
tighten up your apps, even though the security rule isn't final, they
still
represent Privacy vulnerabilities and liabilities and require mitigation
where they exist.  There can be no excuse for a poorly documented
application, without a complete understanding of its use cases and data
flow, a comprehensive description of its security schema, and thorough
policies on minimum necessary access, with equally thorough control of
the
infrastructure that supports it.  Also, all claims of HIPAA compliance
for
applications, relating to privacy and security should be treated as
suspect
and subject to rigorous proof.

I would like to suggest to both the Privacy and Security workgroups that
consideration be given to IG's that apply to applications specifically.
There are existing standards documents that support ASCA's rules, but I
feel
that a more holistic approach to guidelines may be needed.  I would be
pleased to participate in their development.

If anyone would like to discuss this further, please feel free to
contact
me.

Tim McGuinness, Ph.D.
Consulting Specialist in Privacy and Security
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

President,
HIPAA Help Now Inc.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
www.hipaahelpnow.com <http://www.hipaahelpnow.com/>

Executive Co-Chairman for Privacy,
HIPAA Conformance Certification Organization (HCCO)
www.hipaacertification.org <http://www.hipaacertification.org>

__________________________________________________________________
Phone:   727-787-3901   Cell: 305-753-4149    Fax: 240-525-1149
Instant Messengers:  ICQ# 22396626 - MSN IM: [EMAIL PROTECTED] -
Yahoo IM  timmcguinness - AOL IM:   mcguinnesstim
__________________________________________________________________


========================================================================
===

IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended
solely
for the entity or individual to whom it is addressed. If you are not the
intended recipient, please notify the sender at once, and you should
delete
this message and are hereby notified that any disclosure, copying, or
distribution of this message is strictly prohibited. Nothing in this
email,
including any attachment, is intended to be a legally binding signature.



-----Original Message-----
From: Bill Pankey [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 16, 2002 5:24 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: 'Integrity Conrol' vs 'Message Authentication'


Chris

I appreciate what you say.  Certainly TCP is spoofable but it provides a
valuable service in protecting against transmission errors, dropped
packets and the like and therefore is important to 'integrity'.

My question is not 'whether or not', but how integrity controls are cost
effectively implemented and, from a compliance point of view, isolated.
The idea that all packets should be signed seems far fetched.  To do as
much can hardly be cost ineffective as it essentially ignores all of the
HCO effort with respect to activities like physical access control,
personnel screening, workstation security and so forth.  If I were
transmitting over the public Inet, then I would consider signing all
packets.

I discount the conventional wisdom that most attacks are from inside the
LAN, although I accept that insecure workstations are often the vector
for attack.  HCO spend a lot of effort screening personnel who after
all, are 'caregivers'.  In some ways it antithetical for a provider
organization to protect itself from malicious activity of its staff.
Afterall the HCO give knives to its people and takes responsibility for
the consequences <g>.

Bill


**********************************************************************
To be removed from this list, go to:
http://snip.wedi.org/unsubscribe.cfm?list=privacy
and enter your email address.

The WEDI SNIP listserv to which you are subscribed is not moderated.
The
discussions on this listserv therefore represent the views of the
individual
participants, and do not necessarily represent the views of the WEDI
Board of
Directors nor WEDI SNIP.  If you wish to receive an official opinion,
post
your question to the WEDI SNIP Issues Database at
http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.


To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=Security
and enter your email address.

<P>The WEDI SNIP listserv to which you are subscribed is not moderated.  The
discussions on this listserv therefore represent the views of the individual
participants, and do not necessarily represent the views of the WEDI Board of
Directors nor WEDI SNIP.  If you wish to receive an official opinion, post
your question to the WEDI SNIP Issues Database at
http://snip.wedi.org/tracking/.
Posting of advertisements or other commercial use of this listserv is
specifically prohibited.

Reply via email to