Security Center.

Customer privacy and data security is one of Zerion Software’s top priorities. Specific measures are in place to maintain privacy and security at all times. Customers may modify and change settings to ensure solutions work at an optimal level for their specific needs. Zerion Solutions has limited, audited access to identifiable information in any customer database for any reason, including customer support or troubleshooting.

​Sze Wong
Chief Executive Officer
Sze is the CEO at Zerion Software. He is a developer, a workaholic and, most importantly, a father of two. He is a little crazy at times and sometimes he will do things that seem to make no sense at all. Sze is most relaxed when he is working and gets stressed out when he is on vacations.

Joe Vetoe
Enterprise Support Manager
Joe is an Enterprise Support Manager by day, a dad by night (and most mornings), and pretty lazy on the weekends. He loves customers big and small and his main goal is to help them succeed. He is a movie lover, a drawer of drawings and a skilled Super Mario Bros. 3 player.

In recent hacking incidents, hackers were able to hack into over 28,000+ MongoDbs and hold that data ransom. Think about that.

We read about hacking stories and think that it would never happen to us. We believe our databases are secure or that we won’t be that unlucky…until it does happens. Every so often we hear that even big companies, governments, and institutions with high levels of security have been hacked. It seems like no one is truly immune,  yet we still think we are.

The Source of the Problem
More and more data is being collected and stored in a digital format every day. With the explosion of Cloud storage, your information is increasingly vulnerable. Your driver’s license information, your driving record, your activities, your emails, information about your friends and families; they all are being stored in digital format somewhere. How can you be sure that the companies that collect and store your data are protecting them diligently and securely?

Often, when discussing data security, most of the focus is on keeping data secure as it is transmitted from one point to another. SSL (Secure Socket Layer) is the common method used. In SSL, data is transmitted securely over the Internet via the use of HTTPS protocol. But, rarely do we hear about security while data is at rest.

What is Data at Rest?
Data at Rest is the term used to refer to data that is being stored on persistent storage (disk, tape, etc.). In most cases, the security for the database is based on a username/password system.  Once hackers get into the system, however, it is pretty much free for all. Encryption at Rest refers to data that is being stored on persistent storage in encrypted format. So, even if hackers find a way in, it provides another layer that could prevent data from being stolen.

The complexity of implementing Data Encryption at Rest falls on Key Management. Key Management deals with the creation, exchange, use and replacement of cryptographic keys.

Should the data be encrypted at the database level, at the table level, at the record level or even at the field level? Who should have access to the key?  Where should the keys be stored? Should it be the company with one single master key? Or should it be users? What happens when the key is misplaced, lost or stolen? The answers to these questions will determine the complexity of the implementation.

The least complicated method is to encrypt at the database level.  Key Management is simple because the key is likely to be kept by the company instead of users. It makes the method easy to implement. The downside is that it still relies on the company (or the employees of that company) to keep the key safe. An example might be the implementation by MongoDB. They use database keys to encrypt and decrypt data and one master key to encrypt or decrypt database keys; securing the master key is very critical.

The Importance of Trust No One Architecture
All of this leads to another keyword: TRUST NO ONE architecture. The bottom line is that the user, not the company, is responsible for taking care of their key.

It’s best to essentially trust no one, not even the company that stores the data; this is the view we take at Zerion.

To accomodate this, our encryptions are done at the table, record, or field level. Each user owns the key that can unlock tables, records, or fields that they have access to.  This means that, just because a user has a key, they do not have access every room in the house. This minimizes damage in the case of hacking or even kept unwanted personnel from accessing data.

The downsides for using this method are:

• Performance Degrading – Encrypting field by field will cause the performance in retrieving data to become slower.
• Complicate Key Management – The key management now has to deal with keys generating to users, key lost and recovery, etc.
• Searching – Searching data within the record is also more complicated since data are encrypted.

The reasons above are probably why Encryption at Rest has not been widely adopted by many companies and institutions yet. It is up to the company to decide whether protecting customer or their data should be their priority. We believe the customer’s data safety should outweigh any complexity in implementation.