We’re halfway through talking about the goals of security. In this blog, we’ll concentrate on confidentiality, which is the fourth goal of security. This is the goal that most people associate with security – that no one can see their data except for those who are supposed to see it. Most people associate this goal with encryption, and that certainly helps, but isn’t required. Part of confidentiality is being able to protect secrets even if the communication is able to be heard, such as over a network. Encrypting the data complicates the process – either we have to know the “special decoder ring” to be used (think old war movies when the spies used certain phrases to communicate) or have to use common algorithms and manage little shared secrets necessary to make those algorithms give unique results. We’ll call these little shared secrets “keys”. Encrypting the data isn’t needed if we can guarantee that no one else can see or hear the data. Think if we had a private cellphone connection to the person we wanted to talk to; if we could guarantee the connection was private, then we wouldn’t have to encrypt it.
A data breach is an attack against confidentiality. A company’s data should be kept within the company and a data breach is where others can access the data when they’re not allowed to. It’s also an attack against access control. Accessing the company’s database and looking at everyone’s information (Social Security Number, Credit Card number, etc.) is getting data that was supposed to be confidential between you and the company. In the end, it’s all about the control of your data to make sure that only those who are supposed to access it can, and if you can’t control access, then encrypting the data with a shared secret and managing that shared secret would be the next best practice.
For example, in my home, I would want to make sure that my financial data is confidential just to me. I may want to back it up to my local backup server to make sure that it can be recovered if my PC has a problem. But, my local backup server is used by everyone in the house. I need to make sure that only I can see the backups of my financial data, or that I encrypt them so only I know the password to decode the encrypted backup. I can see in this case, it’s really up to the functionality of the local backup server to protect the confidentiality of my data. A big problem could occur if that server isn’t configured correctly, such as everyone connects as a shared usercode, or if that server doesn’t validate who connects or if I inadvertently set the visibility on my unencrypted backup so that everyone can read it instead of just me. It’s also a problem if it doesn’t support encrypted copies, or I put it in the wrong directory, and so on…
So part of the issue is who can see the data because they use the same local backup server. That server has to have all of the right protections and logging to determine if there was a problem or not. As you can see, it’s not usually protecting the server against outsiders. After all, it’s in my own house and because I don’t allow anonymous Wi-Fi connections, it’s only able to be connected from inside my house. Instead, the challenge is restricting those who are supposed to also use that system or my local home network; that’s where I’ve got the most problems. Occasionally, we have overnight guests who want to get onto the Internet while they’re at our house, and it’s about restricting access to those who are supposed to be there, more than who aren’t. Or making sure that only the right people can connect to the data server (to secure it with Unisys Stealth®, for example).
That is why confidentiality is really about thinking security. From the home example above, there are many questions that I have to answer correctly and design my solution for confidentiality of my financial data backup depending on the functionality available and the environment which I’m using for my data. It comes down to picking the right environment for securing my data. The environment must be able to be secured, provide the right access controls, provide data encryption, and be able to show me who tried to access my data, both successfully and unsuccessfully. ClearPath Forward mission-critical servers provide a state-of-the-art environment for data confidentiality. ClearPath Forward servers, both those running MCP and those running OS 2200, provide all of the mechanisms for storing confidential data – no matter the data type. They have state-of-the-art protection mechanisms combined with logging/auditing mechanisms which assist with forensic analysis of the attempts to look at the data. Many clients around the world trust ClearPath Forward mission-critical servers to secure their (and your) confidential data from both insiders and outsiders.
Data confidentiality is definitely about how you think about security – because to really be confidential, you have to allow the right people to access the data while keeping those who shouldn’t out. It’s about thinking about the overall environment – Where? How? Who? What? And making sure that all of the pieces work together – including logging to see if anyone got in who shouldn’t have.