I recently read this article by DHH (the creator of Ruby on Rails if you didn’t know). It’s title certainly holds true: writing software is hard. We shouldn’t expect every piece of software to be good if we understand that it is difficult to write and difficult to master.
This got me thinking though, about software security. This is something else that is also very difficult to get right and to master. Unfortunately, the bad guys really have the advantage when it comes to security. You, as the developer, need to be perfect in order to have a truly secure system. You can’t miss anything. The bad guys only need to find one weakness or mistake and they are in.
The article brings out:
This is classic cognitive dissonance: Accepting that writing software is hard, but expecting that all of it should be good.
This seems to be true with software security as well. I’ve even noticed it in myself. Accepting that securing software is hard, but expecting that all of it should be secure. There are going to be breaches, the bad guys will get in, and the headlines will keep on coming with bigger exploits and problems. Windows is 30 years old. Has Microsoft stopped releasing security patches for it? Why not? Security is hard.
Think about the subtle, easy, and devastating mistakes developers sometimes make when creating software. Most are aware of things like buffer overflows, but what about where your sensitive data is stored? Let’s say you are encrypting sensitive data in the database. Where do you store the keys? Some have stored them in the same tables as the encrypted data! You can well imagine, one SQL injection vulnerability exploited and all of that encryption means nothing because you gave the attacker all he/she needs to get the data.
Another example: security questions. I don’t much care for security questions, and I won’t get into the reasons here. However, they are still often used and need to be protected. This is another area where a subtle mistake can bite you. Do you store the security questions and answers in plaintext in the database? Again, even if you encrypt sensitive data and hash the password so an attacker can’t get to the data, it would be for nothing if the security questions are left in plaintext. If the data is compromised, the attacker simply goes to your site, enters the security questions and answers, and voila! password is reset to whatever the attacker wants.
While there are mitigations to these scenarios, they are illustrative of the fact that subtle errors in judgement can ultimately lead to compromise in unexpected ways. An entire post could be dedicated to mathematically perfect encryption that is simply coded incorrectly, leading to a weakness that can be used to break the encryption.
I’ll end with a comment on another poignant note from the post:
If I blame my tools or my process or my stakeholders or the full moon, I get to exonerate myself, and my ego, but I’m left with far less motivation to improve and very little insight into how. If I instead accept at least partial responsibility, there’s a clear place to start improving.
This also applies to security. Software security is a massive subject area on its own with new exploits popping up all the time. If you make a mistake that introduces a vulnerability, take responsibility for it and fix it as soon as possible. Learn from your mistakes and the mistakes of others and start improving.
Building software is hard. Securing software is just as hard. Don’t take it lightly. Don’t expect to master it quickly. Take responsibility for the security of your software. Most important of all, keep learning.
Stay safe. Code safe.