While the Payment Card Industry Security Standards Council has set very explicit standards about the requirements for the back-end storage and access of PII (personally identifiable information), including the requirements to protect a debtor’s stored data and to encrypt the transmission of that data when moving it across public networks, the technology partners of loan servicers have a variety of options to support compliance.
In discussing these options, it’s first important to understand data encrypted at rest and data encrypted in motion. The latter refers to the normal encrypting of data just before it’s sent over a communication channel. After an encoding process, the data is sent to its destination. During this journey from point A to point B, the scrambled information is unreadable to external parties. Upon arrival, the data is decrypted and stored in a readable manner.
Data encrypted at rest is data that is encrypted while sitting idle on its home server. This renders the data useless should a rogue database admin walk off with a company hard drive or flash drive.
In recent years, financial industry regulators and auditors have started to require that the Personally Identifiable Information (PII) be encrypted at rest. PII is defined as any information that identifies a person, for instance, a Social Security Number.
Seeing this industry trend toward encryption at rest, we decided to act on behalf of our Nortridge Loan System (NLS) customers. But first, we had a choice. One option was to use database encryption, for example Microsoft SQL Server’s Transparent Data Encryption (TDE). This option (and its equivalent in Oracle) allow for encryption of the database at rest. Having the data encrypted at rest keeps the data encrypted in backups, exports, and on the hard drives. Were a backup or the actual hard drives from the server be stolen, the data would remain encrypted. Without the encryption keys, the data would be unreadable. While this option is very effective, we chose a different path.
We chose to build encryption into our software using an alternative that negates a need to set up either TDE or to use Microsoft SQL Server’s Enterprise Edition. Meanwhile, our alternative method also encrypts the data but in a way we feel is unique to our industry and is extremely secure.
In fact, our method is so secure I am compelled to share a ridiculous statistic with you. Assuming a brute-force attack – an exhaustive key search in which every possible combination is attempted – executed at 1 quadrillion combinations per second, it would take longer than the current age of the universe to crack the code.
The data being encrypted at rest will be decrypted when requested to be shown in the application and then re-encrypted when modified and saved to the database. This is also the case with all of the Nortridge interfaces and reporting tools.
Though data encryption always comes with trade-offs in terms of minor performance penalties, we feel like NLS database information is securely protected in the most practical way available for our users.
If you would like to learn more about our encryption method, please feel free to connect with my, either by contacting our main number here at Nortridge.
