The Server Autonomy

Server Autonomy Protection

[1] Server autonomy is an important issue in the layered security environment. It means that the server is not vulnerable to unnecessary external threats. The server can be protected from such threats by ‘hardening [2]’ the server and preventing unwanted executables from running on it without the permission.

When manually installing an SSL, the server is accessed directly by the Administrator and all executables are only performed after the Root access has been granted directly during a unique session. This is a secure method of installing the SSL Certificate [3], albeit that the process is manual, and the server’s autonomy is maintained.

In the case of SSL Management from a central server, the server is configured to permit external executables to run. This more sinister issue means that the servers on the network must permit executable commands to be sent from one server(s) to another and monitoring or controlling this traffic is very difficult.

This gives rise to the serious security issue that there is the possibility to run unauthorized, external executables. If you can compromise the central server, then all the servers on the network are vulnerable. Combine the ability to run executables with the Root access password and the entire infrastructure is undermined. On the basis of this combination of no autonomy, Root access and the ability to run executables, this method of SSL management should not be considered. ‘Best practice’ should not be allowed to undermine security simply for expedience or convenience.

The DSSA™ [4] software that is installed on any server is specifically designed to harden the server’s autonomy and not to permit any commands or executables to be received or run. All commands and executables come from the DSSA™, so all communication originates from it in an outward direction. No communication can be received by the DSSA™ unless it specifically initiates the communication request/response.

Just as the DSSA™ does not contain the Root password, nor does it have any mechanism to understand any external communication. So the non-existence of Root access adds a layer of security and the inability to receive, process or run executables adds a second layer of security to the server. All communications originate exclusively from the DSSA™ and therefore the server’s autonomy is not only preserved but also improved.