None

Absolute privacy for sysadmins


Is privacy a feasible goal? 5 simple rules that can keep your data protected.

By Kostas Koutsogiannopoulos

Introduction

When you talk with an experienced IT person about privacy, the first thing they say is: “There is no absolute privacy!” Even if there is true in this slogan, its is highly misleading. Because they hush up everything between “absolute privacy” and “use public platforms for everything”. As a matter of fact, you can do plenty of things to protect your user, your customer or yourself in 99% of the cases. So lets leave the 1% in the utopia’s sphere, and describe what is absolute privacy “for us”.

1. Be hosted on your own hardware

It's 2021. Cloud is everywhere. It is fast, it is affordable, it is cool. But lets be honest: If you matter about privacy, you can’t use it. You need to have control on the hardware.


Myth:
Hosted on your own hardware is out of reach! Cloud is cheap!
This is the subject of another article but, please, do your homework on that. Calculate your needs on memory, CPU, storage, redundancy. Someone else's computer is not cheaper than yours at most of the cases.

2. Be encrypted on every data transmission (Transport Layer Security)

Most data have no value, if you keep it isolated. Data is a thing that travel between services, computers, locations generating more data. You can ensure that it is encrypted when it is transmitted.

PacketSniff.png

Use modern encryption algorithms* and certificates that renewed regularly. Automation is key when you impose your encryption policy. Encryption needs to be a no-brainer process even for test environments when and where data is transmitted.

3. Be encrypted on persistent layer

In computer science, every system has a process that created it, and a persistence state. Practically the persistence state is data stored on disks (storage devices). This data must be encrypted. Anyone who can access your storage devices must not be able to determine the state of your systems without your permission.

klipartz.com.png

Pay attention to your backup policy too. Again, data on your backup devices need to be encrypted.

4. Be open source on every level of your stack

Open source, in contrast with other software, is supervised about its privacy (and other) characteristics by independent people. On closed source world, its only the developing company, team or person that can tell if sensitive data that is stored or transmitted is really protected. Even worse, if you consume a free/public platform like facebook, google etc then you and your own data is the "product" that those companies are trading.

stack.png

Myth:
Open source is for limited use. It is not suitable for big companies and big data.

The truth its exactly the opposite. Proprietary software does not seem to scale well in most of the cases. At least the software that you or I have access to (there are some cases that it is developed to scale up). On the other hand, modern open source software is developed with scalability in mind.

One of the most hot issues on the IT industry of 2021 is that cloud providers are aiming their "1 trillion dollar market" selling open source software "as a service" and companies, teams, individuals developing this software are not so happy about that. For example, check the recent changes on ELK stack licensing and the IBM/Red Hat changes on CentOS project.

5. Have a retention policy

When you are the owner of your data, you can tell which part of your data has value to you and for how long. You are free to use data to do your business but you need to take care of it when it becomes obsolete. In other words there is no need to maintain the privacy of data that is obsolete to you. You can simply delete it.

RetPolicy.png

Again, consider automation on your retention policy. The best time to force you retention policy is the moment you store the data.

* Encryption algorithms

When you encrypt data, a very important aspect is the algorithm that you use. Make sure that your software is using algorithms that are currently tested on the field. For example, MD5 algorithm was considered secure enough in 1991 but later was discovered to be totally insecure. Same thing with protocols TLS 1.0, TLS 1.1, SSLv2, SSLv3. Keep in mind that you need to secure the data at least for the time that has value. For example a credit card number that will be expired in 2 years, is considered secure enough, even if you could recover it from the encrypted data after 2 years of processing.


View epilis's profile on LinkedIn Visit us on facebook X epilis rss feed: Latest articles