Communications of the ACM
Tony's Law
Credit: Andrij Borys Associates / Shutterstock
Someone did not tighten the lid, and the ants got into the honey again. This can be prevented by placing the honey jar in a saucer of water, but it is a nuisance, occupies more counter space, and one must remember to replenish the water. So we try at least to remember to tighten the lid.
In the context of security, the software industry does not always tighten the lid. In some cases it fails to put the lid on at all, leaving the honey exposed and inviting. Perhaps the most infamous example of recent years is the WINvote voting machine, dubbed the worst voting machine in the U.S. A security analysis by the Virginia Information Technologies Agency in 2015 found, among other issues, the machines used the deprecated WEP encryption protocol, that the WEP password was hardwired to "abcde," that the underlying Windows XP (which had not been patched since 2004) administrator password was set to "admin" with no interface to replace it, and that the votes database was not secured and could be modified.7 These machines had been used in real elections for more than 10 years.
Comments
Lawrence Brunelle
While the author has stated truly many of the problems with which we are beset, I find I can't agree with regulation as the solution any more than the many-times-promoted "solution" of certification.
Here's why.
Regulation and certification are both concepts dependent on someone (well, a large body of agreed someones) bearing the correct knowledge AND authority to compel correct behavior. There are indeed bodies who CLAIM to have the knowledge. My observation is that they do AND they don't. Certain prescriptive practices are perhaps appropriate for one context and quite the opposite for some others. We have all seen the ghastly results of municipal ordinances run amuck, because the local governing body was not competent to write them, and we have seen (all too few) examples to the contrary. We can't reasonably expect government regulators to get it right any more frequently.
Don't believe me? Think of regulations as requirements. We all who write software know (or should) that if we want to regard a requirement as meaningful, we ought to be able to test it. And yet, extracting conditions of satisfaction, stated meaningfully so as to resolve to a set of tests, is frequently the greatest part of the development effort. And that is when dealing with those whose business interest is in gaining reliable software producing known and desirable output. Some regulator working for some government has less interest than that, and may be perfectly happy to shut down a whole company - it isn't HIS livelihood.
But supposing his diligence and good faith, and even his competence, when and how will he and his fellows examine any body of software? Are we going to simply examine only the gross failures? Maybe we insist on a record of tests passed? What would actually be effective? Let's not forget that, as the author says, "every industry is now a software industry." That means that the scope of software development is beyond measurement. What regulator will have THAT scope of knowledge?
But who is the most likely to know a body of code and what its vulnerabilities are? That would be the very people who develop it, who are intimate with it. And I report that, after over 20 years of writing C++ on various Unix flavors, in a number of firms, I find that the best defense there would be people who actually CARE about the work they produce. Yes, the technical education is indispensable. And a decent testing environment is of great importance. But the people you want are those who will look for and find a way to know they got the code right, no matter the methodology. That is a better solution than certification or regulation. And it has this additional virtue: it is attainable, today.
Displaying 1 comment