Need Direction on WHAT to Implement...

From: Keith (keith_at_keithadler.com)
Date: 02/01/04


Date: Sat, 31 Jan 2004 22:37:56 -0800

Quite frankly, this is really a rather touchy subject.
I've produced solutiosn for banks before and I'm well
aware of the security issues you are facing. They are
far more complex than what we could easily discuss in
this forum. But let me give you a few pointers:

1. You need to use a secure protocol between the web
server(s) and the SQL Database. The default protocols
are not secure.
2. The data should be encrypted at the web server and
stored encrypted in the database. This makes it
impossible for a DBA to distinguish the data. Decryption
could be done by the app server content back to the
financial services institution. A company makes a
product called NetLib Encryptionizer which is good from
what I've heard. Go to http://www.netlib.com/ for
information. Still use line encryption as well. You
could also encrypt the Stored Procs, Views, etc. if you
wanted to be over cautious using http://www.allry.com/.
3. Infrastructure is a key element to security in this
solution. The solution needs to be deployed to a secure
environment where communications between web server(s)
and SQL Server can be isolated. In addition, controls
around how users access the website should be put in
place. This solution will be as much as a network
architecture as it is a software architecture. Locking
down the machine and controlling user priveledges will be
key.
4. Use more than SSL to ensure the bank is who they say
they are. I would employ certs and validate the IP
address of the user to ensure the bank users are using it
from the right location. In fact, I wouldn't allow bank
users access unless it was from the internal bank
network. It all depends though on the bank's
intentions. User certificates would be a must. Customer
data should be protected. Of course, no user certs for
customers as that would be a pain.
5. Encrypt the swap file on all servers. There's a
number of solutions that offer this.
6. The customer access solution and the bank solution
should not be the same app no matter what. This would be
a major security mistep.

There's a number of other things but perhaps this is a
start for you.

Good luck.

>-----Original Message-----
>Please understand that I am not asking HOW to do
something - but,
>rather, I
>just need some advise on what "technology" or method I
should
>employ...
>
>The problem is this:
>
>I have a client for whom I am developing a web site in
ASP.NET. The
>client is a bank - therefore, the entire site will be
secure (SSL).
>
>The banks' customers will be entering account number
information to
>the
>site - and we will be storing all inputs into a SQL
Server database.
>The SQL
>Server database resides on one of OUR servers.
>
>The bank client then wants to periodically download, on
demand, the
>information that its customers have entered. (And the
bank wants to
>download
>the information entered in Excel spreadsheet format.)
>
>I need to determine how I am going to get the entered
information from
>our
>ASP.NET server to our SQL Server database in a format
that will be
>unreadable to us (me, my company).
>
>Likewise, I need to make the information available to
the bank to
>download
>in a format that they CAN read.
>
>Where do I start????
>
>I am an experienced, MCSD.NET certified developer - and
I can
>implement
>anything.
>
>I just need to know where to begin.
>
>Many thanks for your assistance!
>
>~ Celia ~
>.
>