Part 4: The reason that security is such a challenge for the software industry
(see “Mom’s Warning” and “The Defender’s Dilemma” and “Patch and Pray” for parts 1, 2, and 3)
Why is security such a major challenge for the software industry?
First, lets consider “Quality Assurance” in the software industry. I have managed software engineering projects of all sizes from the simple to the massive, so I have had some experience.
But it is my experience prior to entering the software industry that has given me the best vantage to describe the strange practice of software QA. Prior to joining the software industry I spent my time making semiconductors. Like many industries, semiconductors have extreme and exacting quality requirements that have to be carefully managed and validated all along the process of manufacturing them. In semiconductor manufacturing, we test the equipment daily, we test the processes that we plan to use far in advance of putting them to practice in a fab. We even test the circuits while they are still just ideas by simulating them on a computer long before the first silicon dye is ever cut. Entire manufacturing lifecycles are modeled and tested to forecast the expected output so that we know precisely the results of our efforts. In each of these cases measurements that are simply unconceivable to most people, and involving distances and temperatures that can only be registered with microscopes can make all the difference between a profitable product and a disaster. Once they are completed those semiconductors are going to be put in all sorts of equipment that drive mind boggling reliability rates.
With all that said, you can imagine the relative shock that I experienced when I started my journey into commercial software. At first, I simply thought that the software industry was not as advanced and that surely the same quality and reliability techniques I had seen before would prevail sooner or later. Well its been about 15 years later and I would say that is not going to happen anytime soon. Why is that? Well as I started to learn the subtleties of software, I began to realize the primary quality issue with almost all complex software systems is to make sure they actually do what we wanted them to do. And that does not mean “meeting the spec”. What that means is to make the spec right.
All to often it is only after we build a piece of software that we (or our users) can adequately (a relative term) say what they actually wanted. I will avoid the religious arguments about processes and methodologies, but simply point out that all software development methodologies emphasize iterative cycles and the use of prototypes (actually building a copy) in order to flush out features. Some extremely popular methodologies are based exclusively on this. It would require an entire paper to adequately describe why this is the case, but it is fundamentally driven by the fact that most complex software (particularly application software) is automating some activity or process which is itself ill defined. Often times, we cannot say with absolute certainty how the resulting product or system should work until we see it working because the software itself is part of a larger process. This can be heady stuff, but the fact is we have an industry that is actually very sophisticated in regards to quality and does a pretty good job considering the lack of proper definitions we usually start with.
Since the major issue with most systems is definition of precisely what it must do, and that is often times impossible without actually building it first, when it is played out in a competitive environment, the company that ships something first is at an extraordinary advantage. For they are the ones who start the iterative process of perfecting the quality by perfecting the specification. This has been institutionalized in the familiar Alpha and Beta version or the infamous 1.0 of any new software product. Software is deployed to users long before it is completed in order to improve the quality (from a definition point of view) and manor points have been given to the firms that get it in these user’s hand first. Well in the process of doing that, these users (Alpha and Beta testers along with 1.X users) also tend to catch “quality problems” with the software and they tend to report them as bugs. Today most software packages facilitate the reporting of these bugs as soon as they are encountered (Dr. Watson) and the user continues to play a critical role in the overall quality process.
Given this aspect of almost every software project, one that is engrained in the culture, methodologies, processes, and best practices of nearly every software team in the world, it should be no surprise that the QA regiment inside of the best software organizations pales when compared to that of a typical IC manufacturer. Tools have existed for decades in the software world that allow organizations to test designs and statically analyze code for quality issues and they barely register any use in the broad spectrum. The cost to a software organization between adequate quality and perfect is near infinite because of the competitive pressures related to shipping. Imagine how pleased you would be if your favorite software team spent an extra two years and doubled the price to make version 1.0 perfect – you would fire them long before it ever came along. In software, shipping is part of the QA process, the good firms manage expectations and beta tests so that GA production products are robust and expectations are met all the way around.
So now back to security. How do you think the requirement of absolute perfection regarding security vulnerabilities will be handled by your typical software organization? If your answer was poorly and awkwardly, I can concur your answer with thousands of hours of real life experience helping teams through this. The variants are many and we have covered a lot of them up to this point. They start with a lack of understanding about 1) what a security vulnerability is,
2) how to identify adversaries and their capabilities,
3) the emergent nature of security, its difference from quality and then understanding how
4) An understanding that security is an absolute – you either have it or you don’t
But most importantly they have a QA regiment that is perfected for getting things more or less right in an iterative fashion. What’s worse is this almost always is significantly dependent on some segment of the user population performing tests. But when it comes to security vulnerabilities, the only “users” that are going to find them are hackers. And hackers, unlike the rest of the users, are not going to file a bug report when they find one. They’ll just exploit it.
Comments (1)
Almost everyone in the software industry does not know the existence of the software quality measurement in the requirements analysis phase. There has been a standard which is not perfect, but it can check majority of the software quality itself including the security elements if required.
Because most of the so-called "process improvement" guru advocates the importance of process instead of quality of software itself, the software specialsts in the industry do not even know the existence of quality measurement technique since 1982 or so. Without discussing the quality in the initial phase of the system development and/or maintenance activities, no process could cover quality itself completely.
I admit that there are still plenty of improvement required to cover the elements of cyber-security and physical security, but there are ways to mitigate them from the initial phase instead of waiting for the coding phase. Did you know it?
Posted by Hiro Ochi | December 13, 2006 7:41 PM
Posted on December 13, 2006 19:41