We are at the end of the second decade of the 21st century now, and we are still suffering from poor application coding security practices of all sorts. This is costing us big-time in dollars, intellectual property, privacy, security, apprehension and consternation!
As individual consumers, we tend to think of things like identity theft, invasion of privacy and loss of services when we consider the problem of poorly secured applications. But the problem is much broader and deeper than that. Holes in application coding security can also be used to attack communications systems, utility and industrial control systems, supply chains and transportation systems, and military command and control and weapons systems. These kinds of failures can lead to wide-scale confusion, outages, disasters and the deaths of innocents; possibly lots of innocents.
So why is this still such a problem? I think one of the most prominent reason is the virtually universal desire for speed to market. The concern that gets their product or service in front of the consumer first is the one that is most likely to reap the biggest rewards. That is what developers and providers want most; market share and profits. Add to this the fact that the things that application consumers want most are originality, functionality and convenience. Coding-in proper security mechanisms affect all of these aspects of application development. It takes more time and effort to code securely, and security mechanisms often affect the functionality and convenience of applications.
With the deck stacked against application security like this, how are we supposed to solve this problem? Unfortunately, I think we are going to need to regulate application coding security into some kind of assurance program. For a domestic or foreign concern to introduce applications into the American market, those applications should first be analyzed, tested and certified. This is probably not going to sit well with a variety of different consumers, especially at first. But hopefully it won’t take too long to get used to it. After all, in the 20th Century we regulated safety testing and assurance for a whole array of products, and people not only got used to it, they now demand that such assurance processes are in place.
However, all of this is not going to be easy. For one thing, some group is going to have to set the standards and develop the testing paradigms. This can be problematic with applications because they are complex and new vulnerabilities and exploits emerge regularly. This will probably mean that applications will need to undergo periodic re-certification testing. In addition, another group will also be needed to actually perform the testing and authorize the release of the applications.
All of this will amount to a whole new industry, and an expensive one at that. But something must be done about the problem. The possible severity of the consequences of not assuring application coding security are just too terrible to contemplate or countenance.
If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.