Building Open Source Software in the DoD

I had the opportunity to speak yesterday at the DoD Open Technology conference in DC. I proposed to the contractors in the room that they don’t need to wait for the government to force them to open code through initiatives like the Navy’s SHARE repository. I think they should improve their market positions by proactively using their copyright on source written under government contract and open it themselves. ITAR aside, opening it up and intentionally commoditizing it (ala IBM and the Apache web server circa 1997’ish) is a good business move.

I’ll go even further, I think there is a moral obligation to offer code written under government contract as a public good whenever possible (though sometimes with a temporal shift to the right). LIke the gallium arsenide chips in our cell phones, to the civilian nuclear industry fathered by Hyman Rickover’s nuclear Navy, there is lots of historical precedent for thinking this way (argue amongst yourselves whether Rickover’s legacy is a wholly positive one).

I’ll try to write more about this later but for now, if you are interested, you can take a look at reasonably self-explanatory slides below.

• • •

Coding is Maneuver II; A Different Conceptual Model for Certifying Software?

In the previous post, Coding is Maneuver, I made the claim that in cyberwar coding has some equivalency to maneuver warfare and that an agile cyber combatant will need to be able to write and deploy code in real time.

This idea has a few key implications for our current system of software acquisition. First, source must be open (for what should be obvious reasons). Second, the certification process to release a source code change onto the network must adapt in significant ways to support agility. It simply will not be possible to go through a traditional software acquisition, accreditation and operational testing and deployment process and turn things around in the necessary timeframes.

Maybe there is an opportunity here to re-think the conceptual basis for accreditation and testing. What if we accredited the “conditions” of the software’s production and its authors instead of the software itself and then incremented the accreditation “strength” for different types and timeframes of deployment?

In practical terms this might mean that software developed in real time during a cyber engagement by accredited personnel could receive a “spot accreditation” to be deployed into an accredited “system” with a time to live that would be enforced by the virtual machine it was deployed into. Basically, accredit the author instead of the system and then put a time and location box around the code that is enforceable by the container.

There are probably a bunch of things I haven’t considered that make this idea naive, but I don’t think the current approach is going to be agile enough. Tweaking it to make it incrementally more flexible and agile isn’t going to do it. What kind of conceptual shift, if not this one, will make it possible to stay nimble but secure in this environment?

• • •

Thoughts on the Air Force Cyber Symposium

I just returned from Shreveport Louisiana where I participated in the first Air Force Cyber Symposium. I spoke on the topic that I introduced in a previous post; Coding is Maneuver, and then went on to talk about three other ideas that I think the nascent Cyber Command will need to consider carefully. Those topics were cyber situational awareness (and it’s relationship to the geo-spatial battle field), culture, and the necessity of open source.

You can take a look at the slides (which are mostly self explanatory) here:

SlideShare | View | Upload your own

In this post I really want to focus on culture.

The provisional Cyber Command is being established at Barksdale on a bomber base and will carry with it, at least initially, the default culture of the spawning organization. I wonder how compatible that culture will be with the new tasking when you consider the kinds of people that they will need to attract and promote. The last sentence in this article that “we are training killers and not a bunch of geeks” really gives me pause. Does the author of the quote feel that to effectively play to an Air Force audience she has to use a pejorative tone toward the geeks that are the mainstay of today’s cyber domain? If such a bias exists within the force, how damaging will it be to this new command as it works to attract the best talent?

During my presentation I asked the audience how many people had attended a black hat, defcon, or similar kind of event. Very few had. Afterwards a young captain came up to me and said that members of his team would like to attend events like this but don’t for fear that it will be held against them; whether by interfering with their security clearances or in other ways. How can the Air Force create this nascent capability if it’s members feel precluded from participating in the communities of practice that form the basis of the necessary disciplines?

An Air Force pilot today would feel no need to be a member of generalized “pilot communities of practice;” they don’t meet annually with airline pilots at pilot conferences for example. After all, they are members of a pre-eminent force conducting a mature and well-operationalized form of warfare. But, from a developmental point of view, USAF Cyber Command is in the air warfare equivalent of 1914 or so, and in that era (which roughly corresponds to Eugene Hoy Barksdale’s service) air combat was evolving rapidly and U.S. Army pilots were frequently involved in local flying clubs, were learning from European advances, and in general, were engaged in flying as a community.

Cyber Command will be able to leverage the USAF’s positioning among the services as the “technology service,” but it will need to be careful to leave room in the nascent command for the growth of appropriate cultural norms. I’d be inclined to put some space between the new command and it’s SAC / Global Strike heritage and find a nice low slung office building somewhere along Routes 101 or 28 where they would be able to find the right balance between innovating and operationalizing.

• • •