The Castle Walls
I remember clearly first reading The Castle by Edwin Muir in 1993. It's a wonderful little poem telling of the natural complacency which comes so easily to humans, of human value systems and social systems which cannot defend against treachery, and of the weaknesses of the perimeter defense. It seemed to me then to be a warning worth remembering. The more I learn, the more relevant it appears.
It's the perimeter defense that concerns me recently. The context is that of a large, multi-national technology company. The walls are electronic as well as physical. But the weakness is the same.
Like many companies, the company has an Intranet which is isolated from the Internet by firewall technology. The firewall prevents people on the Internet from gaining any access to company systems on the Intranet.
It is not too hard for a suitably determined individual to connect to the Intranet. This is a big geographically dispersed company with a huge workforce. The entire workforce must have access to the Intranet, if only for Human Resource applications and reading company policies. Weak physical access controls or certain weak passwords are enough to allow illicit entry. I know that both exist. And I haven't even looked for them.
Unfortunately, once you have gotten onto the Intranet in some fashion, the remaining defenses are woefully inadequate to their task. Once inside, passwords are sent in the clear over the network. Various readily available tools can be used to intercept those passwords and gain access to more and more systems and data. Also, I know that many systems are open to keyboard shadowing where every keystroke can be monitored.
No one has done anything malicious to introduce the weaknesses I mention. We need to connect systems and have them interoperate so that we may do useful work. Information security rarely spring into existence on its own. It is only as good as people put in the effort to make it. Without the effort, it does not exist.
Now we get to the specifics that inspired me to write this. For a new file system coming online at work, ftp access is allowed for transfer of data to and from the servers. ftp connections send unencrypted passwords and data from endpoint to endpoint. I asked for support for sftp. sftp offers greatly enhanced security at many levels, and from a user's perspective, is no different from ftp in usage.
The response was that I needed to contact some important person in my Division, with whom I normally have not business, to have a request submitted along with business justification. The justification needs to be over-and-above the need for security within the Intranet because current security guidelines permit ftp and telnet connections within the Intranet. (The company policy apparently assumes that one one untrustworthy will ever get within the castle walls or has its head in the sand with regard to the exposers that exist within the wall. Probably both.)
This made me sigh because the burden was high enough to be impractical. As Bruce Schneier noted, "Security has nothing to do with functionality." Security improvements often have no benefits beyond improved security. (And sometimes they introduce significant inconveniences.) There are a few additional advantages to some particular programs over others besides drastic security improvement, but probably none of them significant enough.
This particular story has a happy ending. Turns out another business group submitted such a justified request, so sftp is in the works. But this is not an isolated incident. I have had similar interactions previously and the result was that the secure option was too much work. The cost may indeed be prohibitive to retrofit everything with more secure options, but there is no excuse for not considering better security an objective in the deployment of new systems. Installing ssh/scp/sftp as a replacement for telnet/ftp and similar tools should be a no-brainer.