Things to do on the Jewish new year
Tomorrow is Rosh Hashana, the Jewish new year. Ten days after is “Yom Kippur”, a day of fasting (not for me, though. I will be spending Yom Kippur speaking at the CNASI conference in Sao Paulo and the local “Churrascarias” are just too good to miss. God will have to forgive me this time, but I’m sure she understands – there has to be a Churrascaria in heaven.
By the way, if you are in Sao Paulo on Thursday or Friday next week drop me a note and I’ll buy you a caipirinha).
This period between Rosh Hashana and Yom Kippur is when every Jew should summarize the year that ended and think of all the faults that he has done to his fellow men, so that he can fix those or at least ask them for forgiveness. When it comes to providing security to their users, most organizations need to ask for forgiveness. So to help you, even if you not Jewish, here’s a quick check list of bad things you may have done to your users this year.
* Not provide a useful service.
A common fallacy is that security is the opposite of usability. In fact, there’s very little correlation between usability and security and anyone who says otherwise is using security as an excuse to not do something.
The worse offenders are those who prevent you from a certain service in the name of “security”. Lets see: I can buy online anything that I wish using only a credit card (amazon, ebay). I can transfer money to people and have them transfer money to me (paypal). I can buy plane tickets and print my boarding pass (all airlines). I can buy and sell stock. Order food. File my taxes. Consult with my doctor.
Whatever the service you think of providing through a computer, it’s probably not as sensitive as my medical information, not as expensive as a first-class airline ticket, not as financial as a money transfer and not as fresh as a hot pizza. All of these can, and are, done over the Internet every day – so what’s your excuse?
* Not giving your users the best security possible
Here’s a common line: “We’re not a target for hackers, so lets use a fixed password that is hidden in the HTML page inside a HIDDEN form field. What are the real chances of anyone finding out?”. There is no excuse for not using the basic, common, proven security measures. Putting a decent security for just about any system is not an expensive task and just like you lock your door even though you’re not fort knox, you should protect your system with something that is not trivial to break by someone who knows the system design. By the way, sometimes all it requires is a little thinking – some of the most effective security measures are just clever design ideas.
* Not solving other system’s problems.
So you’ve implemented a nifty challenge-response system but your password is stored plaintext in a backup database that sits on an open share. The fact that you are not responsible for the backups does not relieve you from the obligation to ensure the system is secure end-to-end.
* Not thinking “how can I improve my system’s security”.
Maybe you have an excellent security in your system. It might even be tested regularly and comes up with a great score. But what can you do to further secure it? Maybe there’s a new feature in the framework you’re using, or a new plugin/widget/component that can help your users be a little more secure (while not compromising on usability!). I don’t like to use clichés like “security is a process”, so I won’t. But you get the idea.
* Not helping your users protect themselves against your system.
When doing threat analysis designers commonly forget an important part: your users should be able to defend against attacks from your system. It’s the ethical thing to do: what if some day someone hacks into your system? What can they then do?
But it’s also the practical thing to do. If your system is potentially dangerous to users, they won’t use it. Forcing ActiveX usage is an example where many systems fail: some enterprises disable ActiveX in browsers as part of their security policy (some even go the extra mile and disable Internet Explorer completely). These organizations will not be able to use your service. The same goes for dangerous client-side scripts, needing admin privileges to do stuff and replacing vital system files.
The good thing about security is that like with Yom Kippur, you always get a second chance. No matter how many of the above mistakes you’ve made, it’s not too late to fix it. And when you do, most people will forgive you – that’s a sure way to pile up your karma and go to heaven (you can later exchange the karma points for whatever your religion keeps score in).