Data Security, have you considered it?
As you work tirelessly to enhance your applications to provide the latest enhancements or to make use of the latest technology, something which is often overlooked is data security. We hear almost every day of a data breach here or a data breach there. And let's face it, it damages reputations, leads to financial losses, and could ultimately result in you facing prosecution. It's a foregone conclusion that there will be breaches given the sheer volume of ever growing data that we store electronically on computers.
Businesses, governments, and other organizations are becoming increasingly aware of the need to protect data against unauthorized access from both external and internal sources. Also the global rise of "identity theft" and recent legislation, such as the Health Insurance Portability and Accountability Act (HIPAA), has made data security an issue which can no longer be ignored.
The costs of recovery from a data breach are often overlooked. For instance, a single stolen laptop ended up costing one company in excess of $500,000. It turns out that the laptop contained payroll information, and the costs soon mounted up when you take into account compensation, damage to reputation, and above all, management time in resolving the issue. So the next time you take your laptop out and about with you, ask yourself, "Is the data on this laptop secure?" "Does it really need to be on here?"
Almost everyone is now implementing a disaster recovery plan, and part of this is to normally store your data backups off-site. Is this secure? No. Not unless it's encrypted. Remember, a backup is typically just a textual dump of your data. So if the media falls into the wrong hands, there's more than a fair chance that they can read it. If your media falls into the wrong hands, it won't take long for an individual to scan the media looking for data patterns. For instance, a credit card number is relatively easy to look for, typically a 16 digit number. And as the first four digits identify the card supplier, it really isn't hard to look for four digits followed by a random 12 digits.
However, there are steps that as MultiValue technology providers we can take to protect our businesses and ourselves as much as possible. One option is to break sensitive data up. For instance, you may choose to break a credit card number into smaller chunks and store it in separate files or attributes, however this will almost certainly involve changing the application and there is still a problem with this — the software developers and support staff who have access to the application source code can still piece back together the data! So ask yourself, "Should they be able to review other people's personal data?"
So after considering whether you should actually be storing certain pieces of information, as with all databases, some of what is stored is not necessary. What's the next step?
Data Encryption at Rest
Data Encryption at Rest refers to all data stored in computer storage, both for on-line access and off-line data archiving. Data Encryption makes your data more secure, allowing you to control which users can access particular files. Each encrypted file has an associated encryption key which is used to encrypt the data. Users are granted access to the file by having permission to use that key to successfully decrypt the data. If they do not have access to the correct key, then they will not be able to see the data. A good data encryption system should also have the ability to securely manage the encryption keys, as the security of these will still dictate the security of the data. And should also allow you to pick more than one security algorithm.
Now some have asked, "What is the cost of implementing such technologies?" Well in "Reality" there is no budgetary cost to worry about. But as you're encrypting and decrypting data "on-the-fly," you will experience more CPU usage, and this will occur whichever encryption methodology that you deploy. However, as with all MultiValue databases, they tend if anything to be disk bound and not heavy on CPU, so there is typically more than enough CPU availability to cope with this. Of course, there will always be an exception. But in general, servers should be able to cope with this additional load on the CPU.
In summary, everyone who is responsible for storing personal data should first evaluate whether they need to store this information and if they do, for how long. Once this decision has been made, you should look to encryption to help maintain the security of that data as physical boundaries are no longer sufficient.
Some key points to look for when evaluating Data Encryption.
- The operation should be seamless — there should be no application changes required to implement it.
- It should automatically encrypt any data associated with the file, such as an index.
- You should have the ability to use the same encryption algorithms from within your application.
- The ability to create an encrypted backup should also be available, regardless of whether the data is encrypted.
- A secure method of managing the encryption keys should also be available.
- And above all, it shouldn't be an optional extra feature.
