[GA ARES] Ares Digest, Vol 18, Issue 1

[JD]

I have a different basic problem with the whole thing than those I've see so
far.

I didn't join the Red Cross.

I am not now, nor do I have any intention of becoming a Red Cross volunteer.

I joined ARES.  I think I have been a good member.  I try and do my fair
share, although I know there are many others that do far more.

We have all chose to provide our time, equipment, and skill (and to help
each other to improve those skills) to aid our community.  Not to become a
minor branch of the Red Cross.  If I am ever needed to deploy it will be as
a proud ARES member.  If my help as an ARES member is not welcome I can
always go DXing.

And isn't it the Incident Commander sets the rules for deployment?  Wasn't
that the point of all that "FEMA IS" stuff we all had to go through?  Or are
we to assume that the IC and the Red Cross are the same from this point on?

Those that think that security is the only purpose or even the main purpose
of this maneuver are not considering all the political sides of the puzzle.
An old friend of mine that has been an Iowa Senator for as long as I have
known him told me once "The only reason anything happens in Washington is
MONEY or VOTES".

Every form that is passed is an eager (you sent in the form voluntarily
didn't you?) potential volunteer the Red Cross can count on its roles.
That's a lot more votes and clout for the Red Cross.

I have no problem with the Red Cross wanting to pump up their numbers.  I
would just like them to pick on someone else.


JD
KI4MEH



-----Original Message-----
From: ares-bounces at gaares.org [mailto:ares-bounces at gaares.org]On Behalf Of
ares-request at gaares.org
Sent: Thursday, November 02, 2006 12:01 PM
To: ares at gaares.org
Subject: Ares Digest, Vol 18, Issue 1

Send Ares mailing list submissions to
        ares at gaares.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://gaares.org/mailman/listinfo/ares_gaares.org
or, via email, send a message with subject or body 'help' to
        ares-request at gaares.org

You can reach the person managing the list at
        ares-owner at gaares.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ares digest..."


Today's Topics:

   1. American Red Cross Volunteer Background Checks (KG4QDZ)


----------------------------------------------------------------------

Message: 1
Date: Wed, 01 Nov 2006 18:05:12 -0500
From: KG4QDZ <kg4qdz at arrl.net>
Subject: [GA ARES] American Red Cross Volunteer Background Checks
To: ares at gaares.org
Message-ID: <45492828.6090202 at arrl.net>
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

As an expert in the field of internet security and privacy, I feel I should
add
to this discussion. Complaint records with the Better Business Bureau are a
quaint concept, but you will find that most of the entities that become the
focus of privacy breaches do not have BBB complaints ahead of time. In fact,
it
would be nearly impossible, without constant surveillance and a law
enforcement
level of access to their operations to begin to track it effectively without
their consent.

As far as https goes, that only encrypts the data from browser to server.
That
is the least likely point of loss for personal data. No one tries to
intercept
data in transit these days. The more important issue is how that data is
stored, their data internal architecture and processes, the personnel who
have
access to it internally (most IT staff will have access to it without a
specific need as well), and it's security, archiving and disposal. Talking
about https making things secure is naive and irrelevant. Almost the entire
scope of technology related security breaches in the last decade were from
break-ins by hackers, unencrypted data stored on machines (on and off site),
databases being taken off site, malware theft, data transit and off site
storage, improper disposal, and employee breaches either on their own or
through phishing. Https addresses none of these. I would press for
assurances
and _demonstrations_ that their data management is sufficiently protected
and
robust, besides limiting the scope of the agreement. Less than 10% of all
privacy breaches are reported by some estimates, because their revelation
would
typically be a PR disaster. One must also consider that millions of records
of
personal information can be stolen in an instant, from companies that have
had
no previous problems. Data loss is rarely a dribble that garners complaints.
Once it happens, it's gone.

As far as the few laws that require informing consumers of breaches, below a
certain number of folks, no reporting is necessary (and none outside the
state
with the law). It also assumes that the breach was detected, which can be
the
most challenging of all. The info is gone, and there's no evidence it was
taken
wrongly (after all, it's a data vendor's business to ship data out the door,
so
to speak).

>From a legal and privacy point of view, if authorization is given for
additional checks, then additional checks can be performed at any time at
any
point policy is changed. There will be no protection. Period. It is also up
to
the volunteer to police the agreement, since there are no additional
warnings
or requests from the ARC if more checks are done, or notification of what
types. To sign an agreement based on unspoken policies, or those that aren't
referenced in the agreement, is the worst foolishness.

This .com vendor does not have this data for everyone in advance, but
fetches
it when requested and stores it. It's life cycle, from archiving,
encryption,
usage and disposal at this vendor are cause for as much, if not more,
concern
(they may agree to summarize it for the ARC, but will still retain the
original
detailed records). Any investigation into data protection would also apply
to
them. In fact, being so far removed from the person signing, it would be
almost
impossible to manage what they do with the data. The volunteer is not a
client
of the .com and has no leverage or agreement with them. It is common
practice
to 'share' data with partners, each of whom then have their own practices
and
can also share or sell it again. Without an agreement with the .com
directly,
there is no protection from secondary use. In GA, we are not required to be
notified if a breach occurs to their systems either. You will never know,
only
suffer the consequences.

Effort should also be made to limit the number of checks over time. I'm not
sure the RC has even thought through this, but they will. Suppose you
volunteer
this month, then go away for a year. At what point will they consider your
data
'out of date' and get another report? This could be a monthly event or a
yearly
one. The information will certainly be considered stale at some point...
Given
the broad terms of the agreement, what will they ask of the .com next time?
As
a convenience, I would bet it's written so that you don't have to sign
anything
for future checks at their discretion 'for your convenience'.

You won't find the realities of privacy protection, systems and
internet architecture, it's threats, and how identity theft works from data
vendors, and you won't find it as a complaint at the BBB. An
identity theft occurs every 30 seconds and is rarely traceable. The _only_
protection one of our members may have is a distinct _lack_ of authorization
for the ARC (or the .com) to carry such data should it even be traced back
to
them in a future loss. No matter what policy states, and that policy can
always
be revised, people ultimately have access to the data, and people are the
ones
who traffic in such data. If the ARC asks for blanket permission for this
data,
then I would suspect they not only don't understand its importance, but that
their IT systems and policies may also be inadequate to secure and protect
this
data through its life cycle.

The ARRL should negotiate for audits and inspections of how their member's
data
will be handled, as well as these other terms and conditions. To agree, at
an
organizational level, that members should hand over sensitive data to
another
organization, without inspecting their processes and technologies for
maintaining that data, is woefully negligent. ARRL members no doubt trust
that
these relationships will not cause additional personal risk beyond the
volunteer effort, and that it has been thoroughly tested. Ask any CEO, CIO,
etc, if their data is safe and secure and you'll get a resounding 'yes'. Yet
there are almost daily breaches of systems - systems and processes that were
self-declared 'secure' a day or a year earlier.

There are other concerns as well that should be accounted for in this
situation. In talking to a banking industry consultant, he advised me that
most
'credit checks' result in some nominal downgrade of your credit score. Most
credit apps and employment sourced checks do this, but that there is an
information category of check that banks use to pre-screen for credit card
offers that doesn't. Seeing that this company does this for employment type
screening, a hit may occur. It's a small detail, but bears investigation.

And on the part about striking through, a few comments:

- On legal agreements, both parties must initial the changes. One person
doing
so does not make it binding. There are cases with different outcomes on
this,
but it's generally accepted that both must AGREE. Think about it - if that
worked, you could change all sorts of things on you mortgage and such just
by
striking and initialing yourself. Or if you signed and sent an agreement off
for the other party to sign and they did this, would you be bound by their
capricious changes? Not unless both parties initial is it binding, and with
the
RC, you have to have someone initial who is empowered with the ability to
bind
the RC in legal agreements.

- The RC system isn't set up to handle variants, so from the point of view
of
the RC researcher or future RC administrators, it may become "permission is
on
file" or "no permission is on file", NOT what KIND of permission was signed.
They only have 1 permission form for everyone, and the one doing the checks,
now or next year, doesn't have access to the strike through mod.

- Policy can change at any time without requiring a new signature since no
detail is specified in the form. Next week mgmt could change their minds and
get anything they wanted, and for those that signed, they have no recourse.
Even a strikethrough would be very shaky ground that would probably be
violated
in practice, even if the intent was initially to honor it.

The best privacy protection (which includes accuracy) occurs when the
originator of the data, the receiver of the data, and you all have it and
verify it at the same time, with no storage or middlemen. For instance,
Macy's
is the originator of the data regarding your Macy's account. The DoJ is the
originator of your criminal record, etc. They have a stake in its accuracy
and
security. Because of the inconvenience of getting data from every party, the
big agencies came into being. With them came industry error rates exceeding
50%! They had no responsibility for the data, they just sold it. Now there's
another tier like this .com, which aggregates more data from other secondary
sources for a third tier like the RC. All of these 'systems' are accessable
and
hackable (by technology or by fraud).

This discussion doesn't even touch on errors propagated through the system,
however be aware that a high percentage of personal data that does circulate
has errors, yet there is not a consistent way to detect or correct a lot of
it.
I was once involved in an effort for one of the big three agencies to get
data
from the others and reconcile problems. However, the reconciliation
consisted
of taking the worst as fact - ie, if one report said you were OK, and
another
late, assume the late one as accurate and leave it to the consumer to fix.
The
more places handling your data, the more places for errors, and the errors
are
reconciled against you. Not really the RC's fault, but you let another
entity
aggregate your personal data...

After weighing the options you may consider this acceptable risk for getting
the big mortgage for your dream castle (less data is collected for that),
but
is this opportunity to volunteer and work a radio worth such personal risk?

73, Skip

-----
-Dr Skip Coppola. KG4QDZ









------------------------------

_______________________________________________
Ares mailing list
Ares at gaares.org
http://gaares.org/mailman/listinfo/ares_gaares.org


End of Ares Digest, Vol 18, Issue 1
***********************************


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.13.24/514 - Release Date: 11/2/2006