Protecting Data Part 2 (PCI DSS Standard)

In yesterday's blog I talked about protecting data at rest (e.g. when it is being stored in a database). In reviewing the PCI Data Security Standard used by credit card companies I thought it was interesting that they require sensitive data to be encrypted at the column level when the data is being stored. They actually distinguish in the specification between column level encryption and using an EFS (Encrypted File System) solution. The standard states in requirement 3.4.1 that "[i]f disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.".

The PCI standard calls for column level encryption at the database level however it does make exception if this is not possible, and as noted above if an encrypted file system is used instead of column level encryption then the key must not be tied to a user account. This would require the company to take definite steps to ensure that the keys were protected. If it was simply tied to a user account (generally a service account used by SQL Server) then it would not be possible to enforce non-repudiation since all the system admins would have access to that user account.

Another feature of the PCI standard that I like is the fact that it calls on a continous security plan. In section 1.1.8 it establishes that (at least) a quarterly review of the firewall and router rule sets must take place. Section 10 calls for regular monitoring of security logs and network tests. Section 11 calls for regular tests of security systems (not just network tests) and processes which would include penetration tests by a third party. All of these requirements stress the fact that engineering for security is a continuous process and not a one time event.