Need Direction on WHAT to Implement...

[Celia Oblinger]

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 ~

 

[Keith]

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.