According to PCI PAN can be stored in the database as long as strong cryptography is used. I couldn't find which cryptography is considered strong according to PCI. Here's the issue: I have PAN numbers stored as clear text in one of my databases, these numbers are gathered from a specific application (with set access rights) to generate reports. The thing is, currently, anyone accessing the SQL database can view or maybe copy the numbers as clear text. What i was told about TDE is that anyone accessing the database from inside our network can still view the numbers as clear text, and only if the database was copied to the outside, these numbers will be encrypted. My questions are the following: Is it okay by PCI standard that a database administrator can view the numbers clearly even if the database was TDE encrypted? Can an SQL Database be encrypted by other means (DES maybe?) so that the numbers can only be visible from inside the application and everyone accessing the DB will view encrypted data only?
I am assuming that you are here talking about the "TDE" feature provided by Microsoft SQL Server.
TDE means Transparent Data Encryption, emphasis on "transparent". This is an encryption layer applied on data as it is stored; every single byte that SQL Server manages is encrypted before being written on disk, and decrypted when read. Applications which use SQL Server need not be aware of that process; it is a matter which resides purely in the dialogue between SQL Server and its storage files. Hence the transparency. The nice side of it is that it is easy to apply, and performs very well (small to negligible CPU overhead, no extra I/O, no extra space...). The dark side is that SQL Server itself, not the application, is the gatekeeper: whoever is granted access by SQL Server will be able to see the clear data.
For PCI compliance, see this document which includes this paragraph (at the end):
"Full-disk encryption" is what applies to TDE (TDE is nominally applied on files, but all of them). In TDE, the actual encryption key is managed by SQL Server, who will grant or not-grant logical access to users based on... its configuration, which may or may not map on user accounts. So I would say that whether TDE grants PCI compliance depends on how it is used.
I am not entitled to give a definitive answer on how PCI compliance can be achieved with TDE, but I note that the Wikipedia page includes an encouraging excerpt: "Enterprises typically employ TDE to solve compliance issues such as PCI DSS." So it can be surmised that meeting PCI requirements with TDE is possible, or at least many people appear firmly convinced that it is possible, which is almost as good.
PCI compliance and encryption deals with encryption from the security perspective of key management. While it references strong encryption, this is generally taken to mean industry standards such as 3DES 112, AES 128/256 etc. Where Public Key Encryption is referenced, it's looking for RSA2048.
Cardholder data (PAN) must be encrypted at rest using strong cryptography. With TDE, the data is encrypted at rest using your choice from SQL so that'll likely be AES128 or AES256.
For PCI compliance, you need to be able to show dual control and split knowledge of encryption keys. If you can demonstrate this (which you should be able to) with TDE, then you're. It may be worth discussing this with your QSA if you have one.
You should think about why you want encryption and what it's protecting you from (unless you simply want a tick in the box for PCI). With TDE, the encryption is transparent so, if the disk is stolen, the thief views encrypted data in the database space whereas local users see clear text data at all times. Because of physical security controls, the physical theft isn't the issue but rather the theft of the data. Using TDE means the data will be copyable and viewable by internal staff and depending on the controls in place on the front end, could also be extracted in clear text by a [malicious] end user.