Beware "All or Nothing"

The technological base of most modern networking is rather naive with respect to security. It was created on the assumption that connection was good and that networks exist to transmit data and facilitate access to resources. Ah, the innocence of those simpler times.

The same was true of most software: it was written to be used. Once you logged into the mainframe or minicomputer or departmental server, you were authorized to do whatever there was to do. The original PC environments had no authorization at all: you turned them on and started typing.

This history means that an awful lot of technology's original authorization scheme was "none at all."  Adding authorization has not been easy, especially in a client/server environment. In a client/server environment we rarely can be certain of the other end which makes trust difficult to establish and maintain.

Early authentication was based mostly on permission schemes layered on after logging in. Early sys admins used permission schemes mostly to keep from making stupid mistakes; the idea was to prevent accidental access more than to prevent malicious users from stealing data.

There are many consequences of this history but this post is about a very simple pair: leaving the door unlocked or welding it shut.

Door Unlocked

When IT folks configure new software or hardware or, God help us, both at once, we try to reduce the number of things that could go wrong at every stage. We have a great temptation to turn off authentication and open up permissions "just until I get this to work."

Ah, the feeling of watching a newly installed piece of technology actually work! But the process is rather like recovering from a leg injury: once you can walk with a cane, you need to stop using the cane. Then when you can walk comfortably with a cast, you need to get the cast removed. Once you get the initial installation to work, you need to re-enable authentication and then grit your teeth as everything stops working. Then you need to struggle with the security until you finally get it right, which may involve a couple of weeks of discovering new and exciting use cases that need to be debugged.

Is it any wonder that sometimes technology is deployed before this integration with authentication is complete? If you are a manager, don't put pressure on IT to release it when it works (but without full security). If you are a tech, don't give in to the temptation to skimp on the security integration.

Door Welded Shut

The flip side of this coin is giving up on the security integration. This often arises with older technology that no longer meets updated security standards. It is tempted to simply unplug that technology and rely on the mighty "air gap" defense.

There are certainly cases where good technology is made unsafe by the passage of time. It is certainly true that the easiest thing for the cyber defender to do is to disconnect or shut down the offending system. But such drastic action needs to be carefully considered and to be clearly indicated. Few actions are worse for morale and relations than simply denying someone a digital asset in order to save you some trouble.

If we are honest, we techs often have alternatives. Faced with an old server which cannot be upgraded to your security standards? Consider a proxy behind which the old server can sit in safety. It is one thing to propose alternatives and be told that the budget or the timeline won't support them. It is another thing to shrug and unplug.