Re: Expiring identifiable customer information

[Jeff Kowalczyk <..hidden..>]

Chris Travers wrote:
>
> Jeff Kowalczyk wrote:
> > Has anyone thought about ways we might expire, remove and optionally
> > restore identifiable customer/entity information from LedgerSMB
> > datasets?
> >
> > Obviously, preventing penetration of a production system is the
> > intention. There's always something in the news about breaches like
> > TJMaxx and
>
> First of all, I would point out that if your production *accounting*
> system is compromised you have plenty of potential problems, not the
> least of which might be the ability to print checks, create bogus
> invoices to cover tracks, and the like.  In short, this could be used to
> *steal your money.*  This is one reason why security is such of a
> priority for the LedgerSMB team.

But we support windows deployments, right? ;) Kidding aside, no matter
what the configured security, someone can always walk out with your
server.

The reason I'm interested in this issue is not necessarily the business'
money, as there's only so much of that to be stolen. Best-practice
security is appropriate for that risk in my case. And lock up the check
paper.

My priority is the potential cost in loss of privacy and identity theft to
the customers of a business.

Certain businesses may want or be obliged to forgo conveniences such as
demographic data due of the sensitivity of their identifiable customer
data (ICD). They have the option to extract that data before the ICD is
expired.

As system integrators, it would be up to us individually to assess whether
there are other deployed systems which also affect ICD retention policy.
LedgerSMB doesn't need to concern itself with those questions.

My use case would be served by a straightforward database API, protected
with the same privileges as update/deletes, which accepted customer number
(among other format parameters), and returned:

1) ICD in CSV, XML or YAML formats, keyed to the customer number. A strong
checksum of the formatted representation would be useful.

2) the successful return of ICD can be taken as a successful elimination
of all instances of that data throughout the LedgerSMB dataset. The API
call fails otherwise, and ICD data is not deleted anywhere.

3) a restore API which accepted the customer number and original CSV, XML
or YAML formatted representation, and optionally the checksum value. A
successful return code indicates a restore of related rows to the state
before 1).

I'm out of my depth here, but perhaps in a future version of the API one
could subsitute the checksum with key-signing for 1) and 3).

In my case, I would only make calls to this database API immediately after
a backup with a defined rotation, and pursuant to a data-retention policy,
such as selecting customers with no invoices open or recently closed.


FWIW, I saw broad applicability in this statement:

The TJX Effect

"Rather than retain credit card information after a transaction is
completed in order to settle disputes and handle chargebacks for returned
merchandise, federation CIO Dave Hogan recommends retaining only
information about the transaction itself--store number, time and date
stamp, register number, and authorization number. "That would minimize, if
not stop, payment card fraud," he says. (...) Thieves can't steal
sensitive customer data if retailers aren't storing it.

http://www.informationweek.com/shared/printableArticle.jhtml?articleID=201400171