The first answer that comes to mind is SAFETY! You will sleep better, knowing that your company’s data is safe.
The core of what you’re asking is, “Can my infrastructure support field encryption?”
So here is the answer in brief: Yes, it can. While encryption can demand additional resources, this is usually manageable. The main issue is jobs may take longer to run.
Before we drill in, let us all remember that when security costs. When we enter a building and we have to identify ourselves to the reception, we do this for security. We pay willingly with our time, since we can understand the need. It’s the same with data encryption.
Where might you actually sense it?
- General CPU usage could increase, according to the amount of encrypted fields that your application is using. Usually this doesn’t have a significant impact.
- Even when you join data or randomly access data, there is little chance that you will even sense a delay.
- According to most of our customers, the increase in CPU usage is not the issue. The main issue is increased run time for jobs that deal with files containing encrypted fields.
- You can sense the increase when you deal with groups of records.
- You may feel a delay when you have to read a sequence of records from a file, depending on the number of records and the number of encrypted fields that the file includes. Because it uses some of the system capability to prefetch data when read sequentially, it may seem to be suspended.
- You should expect a considerable delay When you have to display a sorted portion of data, and the key is an encrypted field. The reason is that the operating system stores the data order by the cipher value (to us human beings, the order appears random). To show the key portion of data in order, it first has to first be decrypted. There are convenient methods to change your programs, but the CPU operation effort is still there.
We recommend re-thinking how the programs work and finding alternative methods. Raz-Lee’s skilled engineers are well qualified to assist in this mission.
You might also consider using Tokenization rather than Encryption for these fields. iSecurity Field Encryption conveniently provides both these options and allows you to mix them.
Disk space is another issue. While the order and size of fields and even the Level Check of the file remain the same, internally more data is stored, and the disk space demand is higher. One reason for this is that the encryption method encrypts blocks. If we use the AES 128 encryption algorithm, every field from one to sixteen bytes in length will consume 16 bytes of storage data for its cipher representation. On the other hand, longer fields will only require this addition for the last portion of the string. In other words, shorter fields consume more overhead storage.
iSecurity/Encryption protects data when it is used. It also protects your data when it is saved to any media for backup or transmission. It is so strong that even when files are Journalled, the sensitive fields in the journal are protected.
Encryption is a must. Without it, a stolen backup tape will disclose the company’s data.
Encryption is a requirement of regulation that we must comply with, such as PCI and GDPR.
Once implemented, it remains in place and keeps us safe for a long time. iSecurity Field Encryption prevents the accidental loss of encryption. It controls situations where encryption loss could occur, and it has a watchdog that ensures that fields that are supposed to be encrypted are kept encrypted.
