Quote from: ikonic on June 21, 2011, 02:50:41 AM

~~Any and all interaction with the database should done using either Stored or Prepared Procedures~~

Prepared statements, yes, stored procs, NO.

SPs never really increase security (unless you are talking about the DA's job security), but they do complicate the design. Therefore, you shouldn't use them "just because". Most apps these days use some form of ORM and a minimal set of sprocs, if any.

Quote from: ikonic on June 21, 2011, 02:50:41 AM

HTTP Response Header Requirements

All cookies to have the "HttpOnly" and "Secure" attributes
~~HTTP Headers should not include Server OS version~~
~~HTTP Headers should not include Web Server version~~
HTTP Headers must include an X-Frame-Options directive

Security though obscurity isn't real security. The hacker isn't going to look at your headers and then run a specific exploit script; they'll just run them all and then some. My Apache logs are full of attempts to exploit IIS vulnerabilities, every day.

Also you can't really expect the client to honor any particular headers, either. (You should still use the security attributes, ofc, just don't count on them working).

Quote from: ikonic on June 21, 2011, 02:50:41 AM

~~All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits)~~

- Don't invent your own cryptography.
- Use the Unix crypt scheme with a NIST approved algorithm for password hashing.
- Require strong passwords.
- Introduce some sort of one-time password scheme in addition to the static one.
- Don't do wish-it-was-two-factor. It's just unnecessary if not embarrasing.

Quote from: ikonic on June 21, 2011, 02:50:41 AM

Where the need for database analysis is required the data should be purged of all PII prior to be delivered to the auditor

There is no need to purge anything if you follow a proper release managment process.

You should have at least three different environments: development, QA and production. Dev never sees the production data, and it's where you do all your development and most of your analysis. QA is a replica of the production, used for testing the releases before moving them into production. QA can also serve as a backup when production goes down.

Quote from: ikonic on June 21, 2011, 02:50:41 AM

Users with permissions to the database should be limited to the web application only

You can have different kinds of access schemes, but basically only a select few should have any type of access to production (or QA) DB or OS (or even apps).

Quote from: ikonic on June 21, 2011, 02:50:41 AM

Another good idea to discuss it the limit that can be transfered daily/hourly.
For instance, setting a maximum dollar amount to transfer out is pointless as you can simply crash the price and pull out. Perhaps a better idea would be to set volume limits instead?

You could use a 48+ hour average or something.

There could be rules to detect suspicious activity (sudden spikes in volume etc) which could trigger safety measures, such as seizing trade and withdrawals completely until the activity has been audited.