We want to store some cardholders data in our database. The card we want to store are all connected to our own company account. Does this fall under the PCI framework? For example do I have to comply with the requirements relating to storage of cardholder data?

2 Answers
2

@Rook is right. You don't have to be PCI DDS compliant to store your own data, but you still should adopt the protection methods (but no all the added "bureaucracy") suggested by PCI DDS bill.

What is this DB used for, besides storing card info? Is it (even a part of it) accessible to outsiders? If used only internally, a IP restriction will give you enough peace of mind, if not - a PCI compliant WAF would be a good idea.

PCI is about protecting consumers and "consumer data". I don't think the PCI-DSS applies here, although it isn't a good idea. SQL Injection can be used to read these values, it is slightly better to hardcode these values in a configuration file, it is also a more appropriate design.

Agreed that PCI compliance probably shouldn't be an issue here, from a legal standpoint. However, it may still be a good idea to use some of the same criteria, to prevent certain opportunities. SQL Injection is really an orthogonal concern, so it shouldn't be the deciding factor for location (if an attacker can execute any injections, you have a problem). The configuration file actually strikes me as more suspect, as it may be easier to access by unauthorized internal parties. I'd prefer an actual database, protected as per regulations (use it for practice? ).
–
Clockwork-MuseOct 17 '12 at 19:47

@Clockwork-Muse Well the configuration file has the login information to the database, so that is a moot point. Directory Traversal is less common than SQL Injection... Really this design deserves its own post.
–
rookOct 18 '12 at 18:37