In response to Sam Mason <sam@samason.me.uk>:
> On Thu, Apr 16, 2009 at 05:06:13PM -0400, Bill Moran wrote:
> > I disagree. We're already addressing the issues of security on the
> > application level through extensive testing, data validation out the
> > wazoo (to prevent SQL Injection and other application breaches). All
> > our servers are in highly secure data centers. We have VPNs and
> > access restrictions at the IP and the user level to the 9s.
> >
> > It's still not enough.
> >
> > My task here is to develop a system to protect the data in the event
> > that all of those fail. As a result, I'm looking for general advice.
>
> Mine would be to define what you do trust and not what you don't trust.
> I think you need to do that before you can get much further. At the
> moment the problem seems somewhat ill defined.
>
> For example; you say that you don't trust the application, yet the user
> must trust the application as they're entering their secret into it.
> How does the user ascertain that the application they're talking to is
> the "real" one and that it hasn't been replaced with a pretend one that
> sends their secret off to an attacker who has access to a real version
> of the program?
>
> Protecting against this in general is, as far as I know, is impossible.
> The get out clause is that you're not trying to solve the general case,
> you've got a specific set of use cases that you need to solve.
The primary portal into the application right now is a web site. As
a result, this part of it is handled by typical SSL certs and the like.
As far as the trust factor, you've blurred the lines a bit. My job
is to ensure that the user doesn't know or care about the lines between
application and database, but trusts the system as a whole. However,
I need to clearly define those lines and ensure that each part of
the whole has enough security measures to withstand a flaw in one
of the other parts. Think of the design of postfix, where each
program (smtpd, qmgr, etc) doesn't trust the input of the other
programs and runs in its own sandbox.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/