Re: Working draft of Application Security Policy for LedgerSMB 1.3

[Chris Travers <..hidden..>]

On Wed, Mar 3, 2010 at 5:05 PM, Adam Thompson <..hidden..> wrote:
> 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.

Will get the minor errors fixed this pm and send out a new corrected
working draft.
>
>
>> 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".

Maybe:  "Due to the way web-based software works, there are certain
types of attacks which are indistinguishable to the server from
legitimate uses of the software."
>
>> 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.

Ok.  Good.  Will accept this (via Luke's suggested wording).

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

Good point.  Maybe:

"There are two downsides to this method.  The first is that users who
are already logged into the network must also log into the
application, possibly using a different username and password (though
shared management of credentials is possible).  The second is that the
web server must have access to the password in an unencrypted form.
This means that if the server was compromised, it would be possible
for an attacker to capture the password information as users log in."

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

Ok.   I see this as separate from this document, and want to prepare a
general "how to secure PostgreSQL for use with LedgerSMB" document.
Maybe a brief mention that this will be documented is appropriate here
nonetheless?
>
>> 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?

Thanks for pointing out the issues here.

Well, one could always suggest that the same processes are at work.
Separation of duties is a fairly flexible principle and could in
theory (and often in practice) be applied to offline elements as well
(one person signs the checks, a different person has access to the
check stock, for example).

The key here is that being a non-financial document, one cannot use
them to cover, say, stolen money.  For this reason they usually aren't
subject to the same level of scrutiny.  Long-run maybe it would be a
good idea to have that capability.  However, quite frankly, any
business which needs extra review of sales orders and quotations is
likely to have other complex compliance issues.....

The basic thing is that separation of duties, as a means of preventing
financial fraud, is not applicable to non-financial documents.  There
might be other risk factors which might require it, but they are
outside the areas of fraudulent usage.

So with that in mind, maybe:
"As non-financial documents, orders and quotations do not pose the
same risks of financial fraud and so are generally excluded from
separation of duties mechanisms at this time.  Most businesses which
enforce separation of duties on financial documents do not need to do
so for these types of documents.  Typical reasons for enforcing
separation of duties here have to do with concerns other than those
which we have chosen to target for this release."

(I am not entirely sure if separation of duties for these documents
even falls under the umbrella of security, though it may be required
in certain cases for unrelated reasons.)
>
> 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].

When we get to 2.0, I would like to get the application certified by
Veracode or similar.

Best Wishes,
Chris Travers