Quote from: MikesMechanix on June 24, 2011, 05:29:38 PM

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.

I guess the focus is toward fine graining access controls so if you can do this on the DB you are using then either way is fine.

Quote from: MikesMechanix on June 24, 2011, 05:29:38 PM

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

Its another layer in the toolbox and if you are running a decent firewall that has packet inspection you can kill most stuff before it gets to the server

Quote from: MikesMechanix on June 24, 2011, 05:29:38 PM

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.

Agreed, but most development and QA environments are never matched to production.

Quote from: MikesMechanix on June 24, 2011, 05:29:38 PM

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.

Agreed

ikonic

Posts

Merits