On Wed, Jan 27, 2010 at 6:35 PM, Michael Richardson
<..hidden..> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Chris" == Chris Travers <..hidden..> writes:
Chris> I am working on a security best practices document. I am interested in the
Chris> following things:
Chris> 1) Browser settings and recommendations
Chris> 2) Browser plugin recommendations
Chris> 3) Other general practices beyond the usual stuff (least privilege,
Chris> necessary for each user, etc)
I recommend that the browser/profile that you use for financial things
not be your default browser. I am a (debian)Linux user, I've used
galeon/epiphany and now chrome as my default browser over 10 years, but
during that time, I've kept the "mozilla" (not firefox) instance around
to talk to my banking web site and to SQL-ledger.
firefox has relatively good support for profiles, but it's rather easy
to get a new window/tab opened up in the wrong profile by mistake.
Chrome in "application" mode might also be useful.
Good points.
Chris> 1) New and patched Firefox with the NoScript prugin.
Chris> 2) Looking into IE8 and anti-clickjacking measures
Chris> 3) Recommendations that LedgerSMB is always run over SSL,
Chris> and that where appropriate SSL client certs are used as a
Chris> part of 2-factor authentication.
It would be great if there was a simple SSL client side cert system.
I would be willing to put together some scripts and rpm/deb-ify them.
But, it needs hooks into the administrative interface to generate them.
I am looking into the possibility of being able to do two-factor auth with client certs (i.e. seeing if Apache can forward cert info to the CGI script so we can check to see that the user on the cert is the same user as the provided credentials. LDAP might be needed to make that work cleanly though....
Chris> 4) Mozilla script security policies. I expect a number of
Chris> these to be cooperatively developed as addons for 1.3.
What do you have in mind here?
SSL is not really the panacea people think it is.
I say this as the author of numerous network encryption systems and RFCs.
I see SSL as a critical tool for solving certain kinds of problems. It is hardly a panacea but it solves certain specific problems quite well despite being somewhat clumsy because it is a partial port of an OSI protocol to TCP/IP (and OSI protocols ported to TCP/IP generally suck from a TCP/IP standpoint).
I'd rather we spent time on:
a) a good dump/restore/"fsck" program that can be used to
validate that data is still good.
This will become less important as the data integrity controls become more robust as they do in each version.
b) auditing tools, including ones that stream a transaction log
to another system. I think 1.3 has better audit history, but I
haven't been able to look under the cover of 1.3 yet.
I think 1.3 has much better RBAC.
One thing I'd like is the ability to give myself lower access
control, and like the bank tellers do, enter "overrides"...
Or do provisional transactions that must be approved.
Separation of duties is part of 1.3 for AR/AP/GL transactions. Invoices with inventory pose some problems that we haven't quite solved yet.
c) column encryption of certain data.
We don't have much in the way of payroll stuff yet, but I'll
want to store the person's SSN/SIN in the employee/vendor page.
There might be other things that should never appear in the clear
in a database dump.
That's something worth considering and shouldn't be too hard to add as an addon in 1.3, though the harder part is designing a system that provides the level of security one would expect from column encryption schemes.
Best Wishes,
Chris Travers