Yesterday I posted a blog on “9 Qualities of Good Software”. Today I’d like to expand on #9, security. A good piece of software should “protect the information it is responsible for.” It should “secure the bits.” I have found one of the best ways to gain insights into computer technology (the bit world) is to look for parallels in the “real world” (the world based on atoms). Once one understands the major differences and similarities between bits and atoms, it is much easier to understand how to live in a world filled with bits.
As a husband and father, I take seriously my job of protecting my house and those in it. I’m protecting things made of atoms. I can see them. As a bit builder, I take seriously my job of protecting my clients’ information. In some sense, they cannot be seen or felt. They are intangible, though in many cases extremely valuable. One of the major differences between bits and atoms is that atoms can be seen and for the most part, bits cannot be.
Why do I say “for the most part.” Bits cannot be seen by the “naked eye,” the untrained eye. But with the right tools, a trained individual can sort of see the bits. In my 28 years of teaching computer science, I have noticed those that are inherently good with numbers can usually see the bits in their head. That’s because they are good with numbers. Securing bits has everything to do with understanding numbers. Its a “numbers game”.
In the atom world, we secure things in layers. The number and strength of each layer is determined by the value of the item being secured. For example, most of us secure our money in a bank. The bank secures it in a vault. The vault has layers of protection and so on. Now one thing worth noting in the atom world, which is also true in the bit world, the tighter I secure atoms (i.e. the more layers), the more difficult it becomes to access them when I need them. For example most of us use keys to gain access to our cars. Without the keys, accessing the car’s functionality is considerably more difficult. Not impossible, just more difficult. If I live in a neighborhood in which car jacking has become a way of life, I probably also want to install other layers of security on my car — steering wheel locking bar and LoJack come to mind. An interesting thing to note about the locking bar, it is fairly easy to find something that will “hack through” this layer of security, such as the BUSTER — removes steering wheel locking bars (which, btw, I found in the same google search I used to find a locking bar, so take note — even the crooks use google!). Which brings up an important point about information security — any bits I can secure, can be made unsecure by someone else.
Rule #1 — securing bits is a numbers game
Rule #2 — any bits that one person can secure, can be made unsecure by another person willing to put enough effort into it– beware of anyone telling you they can guarantee 100% security!
Rule #3 — increasing security decreases usability (makes things more difficult even for the honest folks)
Rule #4 — like securing atoms, securing bits is best done in layers
Rule #5 — it is harder to know something is secure when you cannot see it is or not
Rule #6 — securing stuff (bits or atoms) requires being able to think in advance of all the bad things that can happen
It is rule #6 I find to be the most challenging. Consider the events of 9/11. Prior to these events, not many people considered the extreme vulnerability of tall buildings! Now everyone is aware of this. In the early days of websites which had databases on the back-end, not many people considered the extreme vulnerability of SQL injection. This is a technique whereby someone can do unexpected things to your bits in a database — change them, get a listing of them, or simply delete them! Now any developer worth his/her weight in bits is well aware of this problem. In addition, a growing number of tools we use to build web-based software takes this into account to help the developer create systems which avoid this vulnerability. There are hundreds of these types of vulnerabilities to which web applications can be exposed. If you want more details, I recommend CWE/SANS TOP 25 Most Dangerous Programming Errors.
