Security Principles

Here you do not read from the common things. Here you read from basic ideas which must be kept in mind when talking about anything.

One common false claim you always read (for example from Microsoft) is, that a system must drop it's security prior to making it more secure. If this would hold true a Doctor would need to kill his Patients to make them healty again.

Security is prophylactic. That is, you usually do not have an active threat. You onl want to lower the risk of a system being compromized. If you ask people to lower the security barrier to rise it afterwards, this is the wrong way. Besides it is a common trick of attackers.

Therefor security must live in an already secured area. You must be able to do everything with maximum security setting kept in place.

The Safe System Principle

A safe system has following properties:

  • It is fully patched.
  • It has a high standard of security, for example, no open port except the one needed to do the service.
  • Normal operation does not require root privileges.
  • The system lives in a protected Intranet.
  • The Intranet has a very good firewall. Especially none of the system's DNS query will ever reach the Internet.
  • The Internet access is always done through a proxy.
  • The proxy is of high standard, that is, it does not allow you to go everywhere.
  • For normal administration you are not allowed to change firewall settings.
  • For normal administration you are not allowed to change or add proxy permissions.
  • All policies are kept to the bare minimum. (For example: If Microsoft Update must be used you still cannot access www.microsoft.com.)
Very important is, that you cannot assume, that such a system allows SSH access. You cannot even assume, that there is some fast shell access.

The admin only has some way to execute commands on user level. This might not even involve a shell. Perhaps it involves sending paper letter to others explaining what to type into the console.

However one thing can be done:

You can somehow open a data tunnel to some remote system in the Internet which you fully control. But this system must be considered hostile in that some big brother is watching every bit the CPU of this remote system shifts around while he is of full control of the network infrastructure where the remote system lives.

Why is this important

This is most important because it is a good model to think about usablilty of something. If it is designed such that it does not pose a threat to this model and it does not require any change in the assumptions, then it is correctly designed. Else it is flawed from a security point of view.

So if you require to make things worse, you are not the good guy.

Example 1: Software install

On the safe system you can download and install software from the remote system. However you must somehow make sure, that nobody changed the software package, as the assumption is true, that there is a powerful adversary who is able to control everything you get from the remote system.

A proper way is to check the signatures of the software being installed. However this again means, not to rely on anything which can be controlled by a third party. Downloading the key along with the software is a strinct no-go. You also cannot access a public keyserver, as this would need to be able to connect there via the proxy. Which is a contradiction to the assumption, that you are not allowed to change the policies which are pekt to the bare minimum (and therefor disallow you to connect to keyservers).

Example 2: Data copy

If you want to copy data to the safe system, the data must be safe, too. This means, the source must be safe, too.

Therefor the source of data for a safe system is another safe system. This other safe system is in a secured area. Often there is no trust relation between the two systems involved, this means, both systems cannot talk to each other directly. They, however, can talk to their remote system which then can create a connection between those two systems.

What you have:

Secure System 1 can connect to Remote System 3
Secure System 2 can connect to Remote System 4
Both Remote Systems then can do the interconnection.

The data transfer process therefor must have following properties:

  • There musst be some tunnel to interconnect the two secure systems
  • The tunnel must be seen as being compromized
  • There must not be any assumption about how you do the tunnel. It's just some IP:port combination to talk to.
Nothing else must be required, for example installing some service to get it done is an absolute no-go.

Some other assumptions

Security in mind means to be restricted. Restricted means, there might be some restrinctions which are not in-band. Like that any connection automatically is teared down each 5 minutes or so, just for security reason. Or you are only allowed to transfer 1 KB, then the connection is dropped.

So if you define some process which shall live in a secure area, you must be able to survive connection loss due to outband restrictions which you cannot change.

Example 2: Data copy

For this example this means, that you still must be able to transfer data, even if the connection is instantly teared down. The data transfer still must be somewhat efficient. The restart of the connection therefor must have nearly no overhead, as if the overhead reaches, say, 1 KB, this means that the re-connect is not established before the connection is teared down again.

Conclusion

Secure algorithms work in a very restricted area, allow a complex setup with nearly no possibilities and must survive connection issues even to the highest degree.

For example:

  • rsync does not fulfill this, as you cannot consider you can start a shell. Therefor you must install the rsync deamon, which again is a no-go, as installing something is a policy violation.
  • Tar does work, if you have enough space to spare on the remote system. You can do a TAR, copy the file to the remote system after signing/crypting it.
  • Then the data is transferred to the other safe system, the signature is checked and the TAR extracted.
  • The signature check can involve manual commands, therefor the secret keys do not be exchanged over the remote system.
However TAR is clumsy, as we still have the problem, that we perhaps need to split some Terabyte big TAR files into 1 KB pieces to be able to ship it through the firewall/proxy policy.

(Note that I consider GCOPY to become a beast which can fulfill this all. However today it is not yet suitable for it.)

-Tino, 2009-05-30