Security PrinciplesHere 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 PrincipleA 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.)
Why is this importantThis 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 installOn 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 copyIf 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.
Some other assumptionsSecurity 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 copyFor 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.
ConclusionSecure 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.