Innovation's clockspeed mismatch (and crowdsourcing the Manhattan Project).

The trend toward increasingly widespread dissemination of technology is seen as eroding US military advantage, and that trend offers an implicit argument for more effective, faster, technological innovation. The Institute of Land Warfare Contemporary Military Forum's session on "The Future of Army Public-Private Partnerships and Cyberspace" took up that topic. Led by Lieutenant General Edward Cardon, Commanding General, United States Army Cyber Command and Second Army, the panelists offered opinion and insight on how the US Department of Defense in general and the Department of the Army in particular can keep from falling behind the pace of innovation industry sets in the commercial market.

Part of the challenge lies, several of the panelists thought, in the way the acquisition system, especially insofar as it's driven by formally articulated requirements, tends not to frame the operators' problems effectively.

General Cardon expressed it this way during questions and answers: "The Department [that is, the Army] is driven by requirements, and requirements are solutions to problems." To effectively engage industry and profit from its capacity for innovation, the Army needs to formulate and pose, as clearly as possible, the problems to which it's seeking solutions. "We should," Cardon said, "be in the problem business."

The session's moderator was Ori Brafman (author of The Starfish and the Spider, Distinguished Teaching Fellow at the University of California Berkeley's Haas School of Business, and Senior Fellow of the Fuqua/Coach K Leadership and Ethics Center (COLE) at Duke University). Panelists included Raj Shah (Director, Defense Innovation Unit Experimental), Brigadier General Patricia A. Frost (Director of the Cyber Office, Deputy Chief of Staff, G-3/5/7 United States Army), Colonel (retired) Peter Newell (United States Army, Retired, and Managing Partner, BMNT), and Shawn Wells (Chief Security Strategist, Red Hat).

Keeping pace with private sector innovation.

As General Cardon noted, the problem in cyber is that the Department of Defense and the Army will never, on their own, keep pace with the innovation going on in the private sector. He illustrated the gap by observing that the Army's whole science and technology budget is $4 billion—"a drop in the bucket of what the IT industry spends." Thus, he concluded, we need partnership, and our current model simply doesn't support the sorts of partnership we need. "It's not moving as fast as we'd like, and we have to do more."

The moderator invited each panelist to comment. Shah, who leads the Defense Innovation Unit (Experimental) whose mission is to bridge the divide and accelerated delivery of technologies to warfighters says that he's encountered more process and cultural issues than he has transition issues.

General Frost described her frustration by what she called the "clock speed dilemma." The Department of Defense must work at a certain speed, but it must also look to industry for innovation, and industry works at quite a different speed. "We've tried bending the process," she said, but believes we may need to shatter it, and in particular we cannot move forward by looking at the process in purely military terms. Commanders, too, find the acquisition system too slow. They are looking for products that can't go through a ten-year, five-year, even a one-year acquisition process.

Problem-setting and shared purpose.

Having lived through the experience of the Rapid Equipping Force, Newell took some lessons away for moving innovations to the force faster. " I never had an honest discussion of a problem until I handed someone a solution," he said, and this is because we articulate our needs as requirements, not as problems. "Invest in understanding the problem before you work on the solution."

Taking the approach of looking for problems, and then mapping them onto the Defense system, Newell noticed that the challenges were fundamentally social. It wasn't so much the speed at which one could buy things, but rather the speed with which you can identify a problem and induce people to work on it. You have to identify a problem, translate it into terms potential problem-solvers can grasp, and then articulate it as a value proposition for a small company. Being able to articulate problems in this way is how you communicate with industry and universities.

Newell expressed the problem-setting and solving process as a curriculum. "Hacking for Defense" will soon be taught at another fifteen universities across the country. The principal reason students take it is to apply their skills to a real problem. The second reason, and this Newell noted emerged as the course proceeded, was that students conceived a desire to do something meaningful to help servicemen and women.

It ought to be possible, and is possible, to motivate people to work on cyber problems without too much difficulty. As General Cardon put it, "Cyber's not a military problem; it's a national security problem."

In Shah's experience, with the right incentives you can recruit the right people from industry and the Department of Defense for very specific problem sets. He's been surprised by the extent to which there's convergence between military and commercial problem sets. "Consider the technologies Amazon is pulling together to deliver packages to villages in Indonesia." Those technologies are absolutely relevant to a wide range of military problems.

The incentive is rarely purely monetary, particularly in attracting people in universities to work on the problems one sets. "Money, we found in the class, was not the motivator," Newell said. Instead, it's essential to package the problem "in a way that fits into the timeframe of their life." General Frost agreed: "Organize the problem set to fit in the time they're willing to devote to it."

What about the civil-military divide?

Brafman shared some anecdotes about Berkeley, where he brought in military personnel to speak to students. People in uniform who came to Sproul Hall—the heart of the 1960s' Free Speech Movement and the symbolic source of that era's counterculture—weren't insulted; the students asked them if they were police officers. None of the students could even recognize the uniform. Indifference and ignorance are in some ways bigger problems than hostility.

Military service is very foreign now to most people in the country. It's therefore incumbent on us, Shah said, as a Department, and an Army, to reach out to the kind of people who are going to be critical to our defense. How do we organize them, how do we reach them, how do we expose them to our problems?

General Cardon thought that training military personnel with industry should be done with the right industry, and with a follow-on assignment identified at the outset. "Permeability with service is a huge policy discussion—if you're looking for a high-end person, they're probably in our force." He also believes in the value of connectivity with academic institutions (and emphatically not just for officers).

Open-sourcing and crowd-sourcing.

"Sometimes we don't know what the problem is," General Cardon said, and once we do, in cyber, we find that somebody else had the problem first. "We don't yet have a community that's shared across government, academia, and industry."

Wells shared an anecdote from his days as a SIGINT operator in the early 2000s. They would work from a target list—"This bad guy was on this phone. But every now and then the bad guy would change his phone. It would take days to weeks to reaccredit software for the target's new phone." So accreditation issues often prevented them from actually reaching targets. Where we fall apart is in managing the chaos of rapid innovation.

He likes the open source model. "We can't, for example, keep reaccrediting Linux everywhere. We developed a system that enables us to accredit Linux-based systems rapidly." So his organization put put it out on Github, clearing the way for people to contribute to a broader community. " We now come government-ready out-of-the-box.

General Frost wanted it understood that soldiers, too, could contribute in such an environment, but "soldiers aren't given the right environment to solve their problems. It should be OK to fail." And she advocated fencing resources to enable that kind of work.

The requirements process can be an obstacle to innovation. "We've looked at the maker movement," General Cardon observed. "We also get hung up around classifications. Lawyers get involved." So, to the question, what about unifying Army cyber, he responded, "That's the reason for General Frost's position. The Army has been forward-leaning about putting money down in advance of requirements. I don't know how long that's going to last. We're working on our POM, but I don't know what we'll need in 2020. We're unfortunately organized around the requirements process."

In Newell's view, "The secret source in crowdsourcing is the speed with which you curate the crowd to get the people who can make a contribution. The problem is the bait."

And the operators are part of the solution.

Lieutenant General Edward Cardon, Commanding General, US Army Cyber Command and 2nd Army, speaks earlier this year before the Joint Service Academy Cyber Summit at West Point. He described the ongoing challenge of recruiting qualified cyber operators. US Army photo by David Vergun.

Wells offered another example. "We actually took a classified wireless program for nuclear subs and put it on Github. Putting it on Github doesn't do anything until you let people know what you're doing. We didn't so much want contributors as we wanted users. Then that user had to be given permission to participate in that community. Now, anybody can participate in this process without having to jump through the legal hurdles of putting IP out, or getting permission to represent the Navy."

Shah suggested some caution. "There's a lot of talk about Silicon Valley and tech companies, and the value of crowd-sourcing. But none of these are panaceas. The central problem is the way software has come to be the ultimate operational capability. You'll go nowhere until your developers and operators are together, and they're down at the tactical level."

"Cyber's extremely disruptive," General Cardon observed. "Where you sit determines how you see the problem. These problems often aren't new. Consider: corporate decisions that five years ago were taken by the CIO, are now taken by the CEO, or even the board. And why? Because of risk. Target provided the epiphany. In the Army, there's a recognition that cyber isn't an MI problem, or a Signal problem,. It's a command problem."

So how about a Manhattan Project for cyber? (Or not.)

One often hears at cyber security conferences what we heard from the audience at the Land Warfare Institute's Contemporary Military Forum: why don't we have a Manhattan Project for cyber? Alternatively, why don't we have an Apollo Program? After all, if we controlled nuclear fission in five years and put an astronaut on the moon in eight, surely a comparable level of effort would work wonders with cyber security. Put the resources and the talent to work on the problem and the problem will be solved.

There are reasons to reject this analogy, tempting as it may be. General Cardon put it this way. "The Manhattan Project idea falls apart because there's no clarity about the problem." Consider the way the problems that drove the Manhattan Project and the Apollo Program were formulated.

In October 1939 President Roosevelt's Advisory Committee on Uranium set the problem for the Manhattan Project roughly as follows: explore nuclear fission to develop "bombs with a destructiveness vastly greater than anything now known." The first device was successfully tested in July, 1945. As far as the Apollo Program was concerned, the problem it solved was set by President Kennedy in 1961: "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." And in July of 1969, NASA succeeded in doing just that.

Note that these problems were relatively easily stated. They were difficult and challenging problems to be sure, but each was, at bottom, a single big problem of the kind that has lent itself to solution by engineers since before Descartes codified engineering problem-solving in his Discourse on Method.

But what's the single big problem underlying cyber security that, if solved, would bring the challenge of cyber to a successful conclusion? There might not be one. Cyber security is an indefinite, complex, and shifting set of related but loosely coupled problems. And above all, cyber security involves working against an intelligent adversary who observes, thinks, and reacts in imperfectly predictable ways.

A fragment attributed to the Greek poet Archilochus may be instructive. "The fox knows many things," Archilochus is said to have written, "but the hedgehog knows one big thing." The Apollo Program and the Manhattan Project were problems for hedgehogs. But cyber security is one of the foxiest set of problems found in the world today. It's not like realizing space travel or nuclear power. It's more like the pursuit of perpetual peace, the end to crime, or universal prosperity. There are many problems, and solving them will require knowing many things. So cyber may be a field for foxes. For hedgehogs, even if they're well-heeled? Not so much.