Those of us who want to make computers more secure are failing. We are failing because our strategies for improvement are completely ineffective. We need a new strategy.
I think that a good place to start is to look at what has been effective in other fields that seek to change human behavior.
Consider, for example, the public health campaign to stop smoking.
When a smoker goes into a doctor’s office for a checkup, the doctor tells them that they should stop smoking. Smoking is bad for you. It causes cancer.
The doctor knows that the smoker will probably not stop smoking—smoking is addictive. Nevertheless, they tell the smoker to stop smoking. And when the smoker comes back the next year, they tell them again, and the next year, and the next.
Eventually, the smoker may die from cancer—like my mother did. I don’t blame doctors for my mother’s death, and I don’t blame my mother. She started smoking before we knew much about its health affects, and smoking is addictive. Doctors learned, and when it became clear that smoking causes cancer, they told her, over and over again.
And as a society we’ve done much more than that. We’ve banned cigarette advertisements on television. We’ve created advertisements against smoking. We teach this in school health classes. We’ve made it illegal for children to buy cigarettes. We’ve put health warnings on every pack of cigarettes. We’ve banned smoking in bars, planes, and public places.
We’ve conducted a campaign to educate the public—not just smokers—that smoking causes cancer, and it has been effective: in 1965, 42% of the US population were smokers, while today only 18% are smokers. Because of this campaign, my father quit smoking—he’s still alive—and none of my mother’s children are smokers. Millions of lives have been saved.
We must do the same in computer security
In computer security we have a similar situation. We know that C/C++ causes memory corruption which leads to one of the most severe security vulnerabilities: remote code execution. This is a statistical fact, just like it is a statistical fact that smoking causes cancer. There is a causal relationship between programming in C/C++ and buffer overflows. There is no such relationship for safe programming languages.
Unfortunately, that’s where the similarities end.
When we, the computer security community, are asked what can be done to improve security, we don’t say that people should stop using C/C++.
When asked to investigate an exploit, and we find that the root cause of the exploit is memory corruption in C/C++ code, we don’t say that the code “died” from being written in C/C++. (We may even blame something else entirely!)
When we give lectures, or keynotes, or interviews to the general public, we don’t say that we as an industry should move from C/C++ to safe languages.
We must start doing this.
When you find that an attack was enabled by memory corruption in C/C++ code, you should tell the victim that they should avoid C/C++ in the future. They may not be able to do this, just like my mother was not able to quit smoking. The legacy code issue is real. However, the more they hear this the more likely they are to change.
They may be able to switch part of their system, a library or a component, to one written in a safe language. They may decide to choose a database or other independent system written in a safe language. They may decide to hire a vendor or an employee who uses safe languages. They may eventually get around to rewriting their system in a safe language. They may write their next system in a safe language.
This is a campaign that costs very little and requires very little cleverness. It respects the victim/patient. They aren’t dumb for choosing C/C++, there are many reasons to do so; however, we have to remind them that they are taking a significant security risk. Not doing so is unethical. If my mother’s doctors had never told her that smoking causes cancer, I’d have sued them for malpractice.
(Much more: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16.)