Does the Data Protection Act of 2005 Make Sense

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
It seems to protect big business more than the 55 million that have had
their personal information compromised due to sloppy security

It will also deflate State laws already enacted.

Re: Does the Data Protection Act of 2005 Make Sense

On 19 Mar 2006 11:55:09 -0800, wrote:

Quoted text here. Click to load it

People in the US think they live in a bubble.  There have been
effective European data protection laws for a long time now.

If you want a comment on the proposed legislation how about a
reference to it not what some dumb blogger thinks its about.

Of course a federal law is better than every state enacting its own
variety and there being lots of loopholes.

European Data protection law requires people who hold personal data
to do so in a controlled manner and with responsibility, and to make
it details of it and what exactly is held available to the subjects on
request.  It also requires that data is held for a purpose.
Jim Watt 

Re: Does the Data Protection Act of 2005 Make Sense

Quoted text here. Click to load it

GLBA has similar requirements, yet encryption of sensitive data on mobile
devices is still not required (see ).  Words/phrases like
"controlled manner" and "responsibility" are weasel words
( ) in
any law.

It seems to me that what matters more is what ends up being ruled in court,
which has a lot to do with public sentiment and less to do with the law

Adam W. Montville, CISSP

Re: Does the Data Protection Act of 2005 Make Sense

Quoted text here. Click to load it

when we were called in to help word smith cal. electronic signature
bil (and later the federal legislation) there were a couple of the
industry organizations also working on a number of the privacy
issues. one of the industry organizations had done a survey of driving
factors behind privacy legislation and found that the two main driving
factors behind privacy regulation and legislation were

* identity theft
* (individual) denial-of-service (by institutions)

cal. was also in the middle of passing opt-in legislation regarding
sharing of privacy information (i.e. organizations had to have your
permission before they were allowed to share individual personal
information), when it was pre-emted by GLBA with "opt-out"
(institutions had to send individuals descriptions of how they were
sharing personal information and give individuals a mechanism for
opting out ... as opposed to the pending cal. legislation that would
have precluded in any information sharing unless the individual
specifically directed).  misc. past mention of electronic signature

we were co-authors of the x9 financial industry standard for privacy
x9.99 ... and we spent a lot of time looking at HIPAA, GLBA as well as
EU-DPD (even tho x9 is US standards organization, we spent some time
considering international issues anticipating x9.99 might go to
ISO). As part of x9.99 effort, i did take a privacy subset of my
merged security taxonomy and glossary and merged it with stuff from

one of the considerations was regarding privacy breaches (cal. passed
one of the earliest bills requiring notification in cases of privacy

part of the issue here is a lot of stuff has been lumped into the
category of identity theft/fraud ... and there has been some recent
effort to break out "account" fraud as a separate category (especially
since a lot of the breaches making it into the press have tended to be
account fraud oriented).

in the mid-90s, the x9a10 working group was giving the requirement
to preserve the integrity of the financial infrastructure for
ALL retail transactions ... for the work being done on x9.59
retail payment standard

the issue here was that the majority of payment security work had been
around lost/stolen cards. PINs (for debit cards) are part of
multi-factor authentication and can be considered a countermeasure for
lost/stolen cards (modulo the people that write PINs on the cards or
the debit cards that have logos and can be used w/o requiring a PIN).
Reporting lost/stolen card would result in account being turned off
... possibly before any fraud could be done (again a countermeasure to
lost/stolen card).

a problem (studied by x9a10) was that starting with online, electronic
transactions (by at least the early 70s), skimming and harvesting of
electronic information became a threat (that could result in
counterfeit cards, fraudulent transactions, etc).

partially becomes of skimming and harvesting threats

there has been periodic efforts to institute massive secrecy-based
countermeasures protecting account numbers (as well as the rest of the
magstripe information).  this created some diametrically opposing
objectives ... since account numbers are required in numerous business
processes related to the payment business (and therefor has to be
readily available). On the other hand, the heavily secrecy-based
security paradigm would require that the account number is never

An additional side issue is "security proportional to risk" thread
... looking at the potentially massive discrepancy in value of the
data breach to the crook ... vis-a-vis the value to the merchant

PINs, in theory represent multi-factor authentication when used in
conjunction with a card ... i.e. from 3-factor authentication

* something you have
* something you know
* something you are

a PIN is "something you know" and a card is "something you have" ...
with a PIN being considered a countermeasure for lost/stolen card.

however, implicit in multi-factor authentication is that the different
factors are vulnerable to different threats. the advent of online,
electronic transactions by at least the early 70s ... really opened up
the skimming & harvest compromises. An issue in skimming compromises
... is that both the PIN ("something you know") and the card magstripe
("something you have") could be BOTH skimmed at the same time
... invalidating assumptions about the value of multi-factor
authentication and vulnerability to different compromises and
threats. The skimmed magstripe information was sufficient for easily
producing a counterfeit card.

part of the x9.59 work was to drastically change the heavy
secrecy-based security paradigm ... by eliminating divulging account
number as fraud threat, as well as changing the card. a chip-card was
required as "something you have", but it wasn't "skimmable".  A PIN
could still be used as countermeasure for lost/stolen card.  And the
card would actually be a countemeasure to "skimming" (the PIN)
... none of the data-breaches, skimming, and/or harvesting
vulnerabilities were sufficient for enabling fraudulent

So the new kind of physical card became a strong countermeasure to the
skimming, harvesting, and data breach vulnerabilities that had been
around since at least the advent of online, electronic transactions in
the early 70s (meeting assumptions about multi-factor authentication
being vulnerable to different threats and exploits).

Part of this is my observation that even burying the planet under
miles of (information hiding) cryptography is not sufficient to
prevent leakage of account numbers ... in part because there are so
many business processes that the account numbers are required for
(current situation creates diametrically opposing objectives of total
secrecy about the account number and at the same time requiring the
account number to be widely available).

Now, reporting lost/stolen card and turning off the account number is
still a countermeasure. One of the issues with reporting and account
number deactivation with skimming, harvesting and data breach
vulnerabilities ... is that typically a lost/stolen card is noticed
and reporting may deactivate the account even before any fraud has
occured. The first notice of skimming, harvesting and data breach
exploits is likely to be after some fraud has actually occured
(noticing them on a monthly statement or when all the money is gone).

The heavy, secrecy-based security paradigm was further at risk because
for ages, it has been well known that the majority of fraud and things
like data breach compromises involve insiders (not only does the
heavily-secrecy based security paradigm account numbers have to be
available ... they have to be available to the group of individuals
that are responsible for the majority of the compromises). So a major
x9.59 standards objective was to eliminate divulging account numbers
as a security and fraud threat (enormous secrecy-based security was no
longer required for preventing account fraud).

some postings in threads related to recent account fraud and data
breaches FraudWatch - Chip&Pin FraudWatch - Chip&Pin FraudWatch - Chip&Pin FraudWatch - Chip&Pin FraudWatch - Chip&Pin FraudWatch - Chip&Pin Debit Cards HACKED now Debit Cards HACKED now Debit Cards HACKED now Debit Cards HACKED now Debit Cards HACKED now Debit Cards HACKED now

part of the secrecy vis-a-vis authentication issue was raised
in an old thread. the security PAIN taxonomy

P ... privacy (sometimes CAIN, confidentiality, aka secrecy)
A ... authentication
I ... integrity
N ... non-repudiation

and it was raised that to provide "good" security, both "Privacy" and
"Authentication" was necessary at equivalent strength. The x9.59
counter-argument was that existing payment environment requires
enormous secrecy (privacy) to achieve security (eliminate fraud), in
part because of poor authentication (and therefor it is rather trivial
to skim or harvest information and perform fraudulent transactions).

THe x9.59 scenario is if there is sufficiently strong authentication,
then it is no longer necessary to require secrecy as mechanism for
preventing fraudulent transactions (and meet the original X9A10
working group requirement to preserve the integrity of the financial
infrastructure for ALL retail payments).

Privacy, confidentiality, and secrecy might be required for other
reasons ... but the X9.59 financial standard objective no longer
required enormous secrecy-based security paradigm in order to
eliminate the most common forms of account fraud.

Anne & Lynn Wheeler | /

Site Timeline