This is an essay that’s been rolling around in my head for a while now. After six months, I’ve finally gotten it down on “paper.” I expect that some of these ideas will be with me for some years and will no doubt become more refined as time goes by. But for now, here’s something to think about.
Introduction: MILSWhile attending my last
OMG meeting in Brussels in June, I listened to a talk on a concept called MILS, or Multiple Independent Layers of Security. The concept is simple: government and military types have information with different security classifications (unclassified, secret, top secret, etc.). They want to be able to work with all of them while keeping them separate. (If you’re a nerd,
Google MILS -- it’s interesting stuff.)
Now, the number of security patches Microsoft releases every month, and the speed with which PCs without these patches can be exploited, tells you something about the state of software security these days. Therefore, the spooks and their colleagues in other agencies maintain all of this information separately—and not only in separate files, manipulated by separate programs. I mean, 100% physically isolated: on separate computers connected by separate networks. There might be three boxes sitting right next to each other on a rack, identical in every way except for the classification level of the information they work on.
Needless to say, this approach is inefficient. What these folks would like to do is have a single box and a single network and trust their software to keep things from mixing in ways in which they’re not allowed.
Aye, there’s the rub:
trust.
Now, my readers will know that one oughtn’t to trust Windows with sensitive information, but that doesn’t get one very far. Trust cannot be based on the reputation of a software vendor.
Some people will argue for or against
open source software on the basis of security, depending on how well they understand how open source works and how much faith they have in their fellow human beings. These arguments are beside the point too.
The point is this: You don’t want the firing codes to the nuclear missiles secured by our confidence that we have cleverer software people than the Chinese or the North Koreans. Trust must be verified, by which I really mean proven.
There is an old chestnut in the computer science world about a book by Don Knuth, one of the godfathers of the field. He included some example code with a warning: “Beware of the above code. I have only proven it correct, not tested it.”
...And this is where MILS comes in. The whole idea behind MILS is that you can prove that a system is secure if every piece of it is simple enough to be proven correct, and if the interfaces in and out of each piece are defined rigorously enough. In fact—and this is where the multiple independent part comes in—you don’t even have to make the whole system secure. If you can make the software component that orchestrates the actions of all of the others—the kernel in operating systems-speak, or separation kernel in MILS-speak—secure, and the particular services you need secure as well, nothing else running on the machine matters. One piece of rogue software doesn’t have the ability to affect, infect, or observe anything in the secure area. That’s MILS.
RevolutionThe concept behind MILS is incredibly important, and the reason is only superficially about security. It’s about something much more fundamental:
software that does what its authors intend it to.
Until all software has this essential characteristic, we software developers are not engineers; we are craftspeople. Good software is good because the people who write it are talented, well-educated, and conscientious people who follow what passes for repeatable processes in this industry. We are, at best, talented pre-industrial artisans.
This is not to say that engineered products cannot or should not exhibit craftsmanship. The Golden Gate Bridge and the iPhone demonstrate that they can and do. But no one commissions a bridge on the basis of the talent and good taste of its architect. They require—by law—a standard of design rigor that is almost unheard of in the software industry. Bridges are composed of
standardized, commoditized components and built according to
well-defined processes. The performance (though not necessarily the budget or the schedule; that’s another story) of the end product can be predicted with a high degree of certainty before the first beam is laid in place. ...And a good thing, because hundreds of thousands of people will trust their lives to it.
Assembling a product from predefined components brings a host of benefits: it enables division of labor; it speeds innovation while defraying costs by easing reuse. And most importantly from the point of view of this essay: it allows a complex system to be tractably modeled by decomposing it into smaller, more easily understood subsystems. Componentization is what the first industrial revolution was all about, and it will drive the next one as well.
Let’s return to those missile codes again. Consider for a moment the amount of software that goes into maintaining, firing, targeting, and monitoring a missile. I’ll give you a hint: it’s a lot. Much of it is built, not from standardized components with well-known characteristics, but custom, monolithically, from the ground up, for this type of application specifically. Can this software be trusted? For the most part, no; hence those redundant computers.
Very Far From Here, and Very ComplicatedWhen I was younger, my family went to Germany on vacation. We landed in Frankfurt incredibly jet lagged, rented a car, and soon became incredibly lost. We eventually stopped to ask for directions; the title of this section is what we were told upon relating our intended destination.
There are standard methodologies for building software rigorously.
- One that’s been around for a while is called DO 178-B; it defines five levels of rigor for development processes for software that runs on airplanes. DO 187-B, Level A certification is required for any life-critical airborne software system in the United States. That this certification works is borne out by the number of people who do not die every year because their plane’s navigation software crashed.
- A newer standard, called Evaluation Assurance Level (EAL), is gaining popularity in the intelligence community. It stresses not only development processes but also mathematical verification. EAL defines seven levels of software assurance, where Level 1 is the lowest (no assurance), Level 4 is the highest level achievable without mathematical models of behavior, and Level 7 can be achieved only with many lines of proof for each line of source code.
Unfortunately, very little software is actually developed according to these methodologies because of the incredible cost of doing so. This cost arises because of the impedance mismatch between the level of abstraction in which requirements and designs are specified and that in which software implementations are written. The former are written using some combination of English (or another natural language) and semi-formal models and diagrams. Many systems requiring high assurance are implemented using low-level programming languages like C because of the high degrees of performance and determinism they also require.
For those readers who have no idea what I’m talking about, this situation is analogous to building an airplane molecule by molecule.
Creating software that verifiably does what it claims—software that is not only highly secure, but highly reliable and predictable as well—in a cost-effective way will require new programming languages suitable for the expression of robust, secure, and verifiable software; new tools for the construction of programs; and updated development processes to leverage these resources in a repeatable way.
Time to get to work.