Code Coverage and Design Flaws
Whether you perform “threat modeling”, conduct “design reviews” or engage in “risk assessments” for the purpose of identifying and hopefully correcting design flaws in an application’s design there is always a lingering question of completeness and accuracy. I’ll try not to derail the conversation and talk about what you do with the flaws (ie, how you rate them, prioritize them and a method for correction) you’ve found even though I really want to.
So, what about completeness and accuracy? Many organizations now go about performing some sort of activity prior to the construction of their widgets. Most probably think they’re doing a decent job. But how do we know? Is it the volume of flaws that are discovered? This is more like a warning light on an automobile than a measurement of the completeness of the efforts. I know, our buddies Saltzer and Schroeder have spoken about proving a negative requirement and I agree with them. I tend to think that this notion of completeness and accuracy are rolled up into a more well-known concept of code coverage. No, it’s not perfect, but it does a decent job here. Of course there is no “code” to cover in the sort of per-construction activities we perform. We deal with the raw materials that will eventually materialize into code. We don’t have the luxury of measuring the scope of our activities based on properties of the code (the number of lines, critical regions, etc). So how do we measure coverage? Do we rely upon methodological adherence? That seems dangerous. What about the quality of the design artifacts? Do they have use cases? The sort of inspection that we can perform seems to be proportional to the amount of time one has taken to articulate the design. But that only makes it more probable that we will be more complete and accurate. We can’t use that to measure our coverage either.
There are two aspects that contribute to quality code coverage ; identification of security code paths (I know there is no code yet) and depth of analysis. The first is the process whereby all untrusted points of input and output in the design are discovered and validated. In my world very few points are trusted, but there are levels of trust. The next is depth of analysis. It is not enough to go through a series of binary questions like “do you authenticate this communication channel” even if there is a well-defined policy governing authentication requirements. It isn’t just the coarse-grained patterns we’re speaking of here. It is the *design* of those patterns that must be evaluated. This is, I think, where many security efforts go awry. They boil down analysis and expertise into questions and answers. Questions do not achieve the depth of analysis criteria for code coverage. Without a doubt if a design doesn’t answer yes to these fundamental questions you’re at a hard stop, but for those that can answer yes you must go deeper.
So, are you confused? “Code coverage” in pre-construction security efforts must consider the methods to identify (and validate) inputs and outputs and the degree of analysis performed upon that data. How do we do this? I don’t know. What we can do is use these two categories (there may be more) as controls points for the consistency and/or reliability of our data. For example, if we’ve simply reviewed available documents to discover the project’s design elements there is probably a greater margin for errors and omissions. It follows then that our code coverage will not be as complete as it could have been. Yes, I know, it is only probabilistic. But that may be the best we can do. I’ll leave it up to everyone (all two of you) else to consider whether what I’m saying is valid. Good luck.