[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working draft of Application Security Policy for LedgerSMB 1.3

On 2010-Mar-03 17:58, Chris Travers wrote:

Comments and feedback are requested.

This document describes the current security strategy of LedgerSMB 1.2.x, an
open source financial accounting program which started as a fork from
SQL-Ledger in 2006.   This document only addresses the 1.2.x stable branch as
security standards would be weaker for 1.2.x and stronger for 1.4.x.
I assume you will want to change the first two references to 1.2.x to 1.3.x instead. 



The major vulnerability in a financial accounting program is the ability to
enter malicious data in order to cover for fraudulant activities,


s/fraudulant/fraudulent/


Technical risks include standard attacks agains the software.  These include


s/agains/against/


In rare cases, the software may not
have enough information to properly address the technical attack and hence some
level of trust has to be placed in the client.
s/the software may not have enough information to properly address the technical attack/it may not be technically feasible to address the attack in the server-side software/
Because the phrase "may not have enough information" will likely lead to non-technical auditors/customers/etc. saying "well, GIVE it more information". 


Social engineering attacks cannot be corrected
on the server and must be solved via user training.


s/on the server/in software/

Covers both server-side and client-side implicitly.


There are two ways this can be done.  The first (supported out of the box) is to
use HTTP basic authentication, where the username and password are not encrypted
in transit.  In this case, SSL is absolutely required because an eavesdropper
could obtain username and password data by reviewing network traces.  Since this
is the typical configuration, the default install only allows connections from
localhost and contains warnings the requirement for SSL when changing this
setting.
Should the document discuss the issue of having the password unencrypted in memory on the server? It's certainly possible to design systems that only do password hashing & verification; the current design of using user-supplied credentials to authenticate to Postgres does not (at the moment) behave that way.
Obviously, if someone has hacked the webserver, they've got lots of opportunity to tamper with data in-transit, even if the connection between the web server and the database is completely secure, so I'm not sure if it really matters or not... I don't know much about OWASP.
Also, while it is true that most SMB installations will have the webserver colocated with the database - and thus using SSL for the DB connection provides no benefit whatsoever - it is certainly possible to have the Pg server running somewhere else (another VM is one obvious possibility). In that case, SSL for the DB connection could be considered relevant. I remember you said something about this in the 1.2.x document, I don't see it here, however. 


Further sales orders, quotations, etc., because they are not financial
documents, do not have separation of duties capabilities.  Separation of duties
is a key accounting feature which is used to prevent both human error and fraud.
Logical fault here, I think. Not being a financial document shouldn't necessarily be incompatible with separation of duties. On the other hand, it is true that the nature of the objects as currently designed, implemented - and understood throughout the industry - does not lend itself to any sensible separation of duties. Better to say there is no widely-accepted definition of "separation of duties" for these objects at this time?
Otherwise, it reads well and although I keep my nose out of formal security standards as a rule, it looks like it is - at least - a good step towards satisfying users who have to worry about demonstrating compliance with [pick your favourite standard]. 

--
Thank you,
-Adam Thompson
 <..hidden..>
 (204) 291-7950