

Ask HN: rules for storing banking info? - jam

There are a lot of rumors about rules that companies must abide by security-wise to store banking information - say, checking account and routing numbers. It's very difficult to dig up anything factual on the matter, though.<p>It seems to me that it must work one of three ways:<p>1.) The government provides a set of security standards which must be met to legally store banking information.<p>2.) Banks provide security standards which must be met to retain their business.<p>3.) There are no specific standards, but you are liable to be sued for any breech in security.<p>I know how important it is to have near impenetrable security when storing important information. I'm looking specifically to demystify the legal end of things. Have I hit the target with one of these three theories?
======
Tangurena
The case is mostly #3.

PCI-DSS is the most commonly used standard, is aimed at retailers and payment
processing systems. And while it is credit card based, much of what is in it
covers other stuff that you should be thinking about if you're storing banking
information.

One book to look at is Cryptography in the Database. There is a section about
laws that cover data security such as GLBA (which says nothing that a
developer finds useful) and SOX (which, for software development, is more
about background checks and version/configuration control).
[http://www.amazon.com/Cryptography-Database-Defense-
Symantec...](http://www.amazon.com/Cryptography-Database-Defense-Symantec-
Press/dp/0321320735/)

Another book that may help with keeping the data away from hackers (and rogue
employees) is Translucent Databases. I have the 1st edition, and the 2nd just
came out last month: [http://www.amazon.com/Translucent-Databases-2nd-
authenticati...](http://www.amazon.com/Translucent-Databases-2nd-
authentication-steganography/dp/1441421343/)

In support of #1, check out NIST's 800 series of standards. When we were
looking to bid on a government computing contract, they included a long list
of them by reference, effectively turning a 3k page RFP into about 6k pages:
<http://csrc.nist.gov/publications/PubsSPs.html>

------
gaius
The phrase you want is "PCI Compliance"

<http://www.pcicomplianceguide.org/>

~~~
jam
Thanks a lot for the link.

It looks like going for PCI compliance is what's necessary for credit card
information storage - any idea whether there are similar regulations around
bank routing / account information?

~~~
gaius
There are, but I personally have no experience of them. I'd be surprised tho'
if you were PCI compliant and _not_ compliant with whatever that is.

------
aristus
If you are thinking about doing this yourself, I would hire some programmer
who used to work for a bank (lots of those around nowadays).

I don't recall if there are any Federal or industry guidelines for banking
encryption, but there is FIPS for general security. There is also explicit law
about audit trails, chains of custody, access controls, reporting breaches,
etc. In general you are legally obligated to know you were pwned and how.

Access to a system must not allow access to data. Access to one account must
not allow access to another (ie, use a different encryption key for each
account). Physical access to a system must be secured and audited, etc.

