On 9/4/07, Jeff Kowalczyk <..hidden..> wrote:
Chris Travers wrote:
>
>
> 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.
Two quick points:
1) Repeat after me: "Security is a process, not a product." If you leave a Linux/Apache/OpenSSL system online for long enough without running updates..... So security is more of a matter of programming attitudes and administrative skill than it is which OS the software runs on.
2) In terms of stealing your money, walking off with the server is a pretty minor risk. Sure they can print checks, but these are legal documents, and the charges can be reversed if you catch them in time. To effectively steal your money, the individual would need to break into the server and leave it in place to cover his/her tracks so you don't catch the issues for a while.
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.
That is part of it.
My priority is the potential cost in loss of privacy and identity theft to
the customers of a business.
Here is what I suggest to most of my customers (it is more important if you do credit card processing):
1) Store the minimum you need to store. Justify a business need behind every piece of information you store.
2) Train your employees about what information they give back to customers. For example, never give customers the social security number you have on file until you get it from them.
If someone says "What Social Security Number do you have on file for me?" The correct answer is probably "If you are worried about a problem. let me check. What is your SSN?" Then you can say, "Yes" or "No, let me fix that, did you say...."
(Note tht employees are generally one of the weak links security-wise.)
Best Wishes,
Chris Travers
3) Do your own risk assessment.
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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel