Does the Data Protection Act of 2005 Make Sense

Discussion in 'Computer Security' started by tedrichardson9925@sbcglobal.net, Mar 19, 2006.

  1. Guest

    , Mar 19, 2006
    #1
    1. Advertising

  2. Jim Watt Guest

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

    >It seems to protect big business more than the 55 million that have had
    >their personal information compromised due to sloppy security
    >procedures.
    >
    >It will also deflate State laws already enacted.
    >
    >http://fraudwar.blogspot.com/2006/03/will-special-interests-place-business.html


    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
    http://www.gibnet.com
     
    Jim Watt, Mar 19, 2006
    #2
    1. Advertising

  3. aioe.cjb.net Guest

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


    GLBA has similar requirements, yet encryption of sensitive data on mobile
    devices is still not required (see
    http://www.securityfocus.com/columnists/387). Words/phrases like
    "controlled manner" and "responsibility" are weasel words
    (http://www.montvillearchives.net/Blog/tabid/53/EntryID/90/Default.aspx) 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
    itself.


    Adam W. Montville, CISSP

    http://www.montvillearchives.net
     
    aioe.cjb.net, Mar 21, 2006
    #3
  4. "aioe.cjb.net" <> writes:
    > GLBA has similar requirements, yet encryption of sensitive data on
    > mobile devices is still not required


    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
    stuff
    http://www.garlic.com/~lynn/subpubkey.html#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
    HIPPA, GLBA, FTC, and EU-DPD
    http://www.garlic.com/~lynn/index.html#glosnote

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

    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
    http://www.garlic.com/~lynn/x959.html#x959
    http://www.garlic.com/~lynn/subpubkey.html#x959

    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
    http://www.garlic.com/~lynn/subpubkey.html#harvest

    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
    available.

    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
    http://www.garlic.com/~lynn/2001h.html#61

    PINs, in theory represent multi-factor authentication when used in
    conjunction with a card ... i.e. from 3-factor authentication
    http://www.garlic.com/~lynn/subpubkey.html#3factor

    * 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
    transactions.

    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
    http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
    http://www.garlic.com/~lynn/aadsm22.htm#21 FraudWatch - Chip&Pin
    http://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin
    http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
    http://www.garlic.com/~lynn/aadsm22.htm#25 FraudWatch - Chip&Pin
    http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin
    http://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
    http://www.garlic.com/~lynn/2006e.html#22 Debit Cards HACKED now
    http://www.garlic.com/~lynn/2006e.html#23 Debit Cards HACKED now
    http://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
    http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
    http://www.garlic.com/~lynn/2006e.html#30 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).
    http://www.garlic.com/~lynn/subpubkey.html#harvest

    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 | http://www.garlic.com/~lynn/
     
    Anne & Lynn Wheeler, Mar 22, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. william mook

    I got some equipment does it make sense to start an ISP?

    william mook, Oct 9, 2004, in forum: Computer Support
    Replies:
    21
    Views:
    790
    Piccolo
    Oct 11, 2004
  2. paul gregory

    does this make sense, fsb question to ecs about my mainboard

    paul gregory, Oct 10, 2005, in forum: Computer Information
    Replies:
    1
    Views:
    387
    paul gregory
    Oct 15, 2005
  3. Replies:
    0
    Views:
    300
  4. When does SLR start to make sense ?

    , Oct 8, 2006, in forum: Digital Photography
    Replies:
    39
    Views:
    806
    Hebee Jeebes
    Nov 17, 2006
  5. Doctor Cerebros

    Uk Data Protection Act and Vets

    Doctor Cerebros, Dec 30, 2006, in forum: Computer Support
    Replies:
    9
    Views:
    497
Loading...

Share This Page