What is the I2O and how does it fit in with other DARPA offices?
At DARPA, there are six technical offices, and the Information Innovation Office — or I2O — is one of these six. As the names indicates, "Information" is tied into information technology, and I would say more broadly the information ecosystem. Information ecosystem consists of pieces of hardware, computers, etc., and, of course, software that is running on these systems. We tend to focus on the software and the algorithms.
We divide our office from a point of view of thrusts.
One would be empowering the human within the information ecosystem. We want to do more in terms of how do we enhance the human/computer, human/machine partnership. We have one program in our office looking at communicating with computers. How we can do that better, in terms of getting away from keyboard-type entries? Can we take advantage of how, as humans we take advantage of non-verbal queues — we are able to communicate with context. That is an area we view as an important growth area.
Then, we have an aspect of enhancing human understanding. This area would be what we do with our data analytics programs.
The other side would be the human developer from the point of view of software. We are looking at this aspect of open source software, where you have close to a trillion lines of code, and it is growing at about 10 billion lines of code per year. How can you make more efficient use of that? There might be sitting in that vast amount of code the very program you are looking for. How do you give someone the tools to do that? We have a program looking at that.
Those are examples of how we try to empower the human.
Then on the point of view of guaranteeing trustworthy computing and information. We take a view that in the context of computing infrastructure, there is this aspect of what we can do to harden and make more resilient the various systems we use. Do not even allow an attacker to get a foothold. Then, there is the aspect that inevitably you will have an attacker get a foothold. What can we do to detect quickly, isolate and neutralize that type of attack?
In the context of making a more resilient network or hardening, we have a program that is looking to use a methodology called Formal Methods. It is looking at saying that I can specify software and then prove that these specifications are met.
Let us say I have the software system for a motor vehicle and I will have software that is controlling the entertainment systems and I will have software that is controlling critical engine functions. I do not want someone who might be able to successfully attack the entertainment system software to get into my critical engine system software. I can specify that, then looking at the various aspects of the code, I can translate that into a graphical problem that I can prove that this specification will be held.
It is much deeper than a [website] certification process. You actually make the code itself, you are going to deny an attacker the ability to exploit any kind of vulnerabilities in the code because you have now specified a particular action to be taken or not be taken. The code itself is resilient against that.
In the case of the Unmanned Little Bird helicopter, we hardened the operating system and particular modules associated with the communications of the system as a whole. This was on the mission computer.
Then we had a particular aspect where we took the software and the hardware associated with a camera that we could plug into the system. The camera software was not hardened and we gave attackers root access to this camera system software. Since we had formally proved, mathematically proven that you could not get from that point into the other critical software, this was the test. Indeed, they were not able to find the path.
This is the case where I can rebuild my code and I am going to build it in such a way that is correct by construction.
This is an effort that is now being applied to cybersecurity. These methods have also been used to assure safety, in terms of the kind of software systems that control aircraft. This is an area that we have been pushing. It has hope for systems that have lines of code in the tens-of-thousands to approaching hundreds-of-thousands of lines of code. It has its challenges because the proofs become much more challenging as we expand the number of lines of code. It goes beyond just naturally building a more resilient system.
Now, it is not pure magic. If I miss a specification, if I really did not catch the fact that I want to go from one particular software module to another, then that could be a possible weakness.
What does the innovation process look like?
I believe that what DARPA first of all tries to do is look at something that is truly different and unique than what is already being done outside of DARPA in the commercial sector. To do that, we have to get great awareness of what is going on. Of course, what also tends to drive it is particular needs from the DoD perspective — because there is a "D" in DARPA. That actually has a nice focus, in terms of pushing us toward looking at challenging problems.
Number one is: what is that big step that is definitely not being addressed in the commercial sector in a more incremental basis? We are really looking for these big jumps; what might be the next challenge, the next thread, for example.
We have a program that looks at the aspect of algorithmic vulnerabilities. A program called Space/Time Analysis for Cybersecurity is looking at particular types of algorithmic attacks that would look to tie-up a system in time or in terms of space, which really is memory in the context of computers. That is an example where you are asking yourself, "What is the next hard challenge to stimulate new thinking," in terms of how can we go about detecting that in a program that was perfectly coded.
You want to have goals that are certainly ambitious and then the program proceeds and we will look at how we address it. A DARPA program can fall short — we allow that fail — but our whole premise is that if we are successful there is this tremendous payoff.
DARPA is set up for a uniquely high rate of failure. How do you deal with that reality?
We have to accept that we are going to have a failure rate. We want to recognize it early because then we end up stopping the effort. That is not outside the possibility here. Or we look at what might be an unexpected situation or we fell short. Why is that? We would like to understand it.
The conclusion may be the time is not yet ready. It is an aspect of DARPA — it is not necessarily open-ended discovery, but we are thinking that there is something we can achieve. We realize it is a challenge but we at least think there is a feasible path there.
The program is all about saying, "Can we address and achieve what we think is feasible?" That is part of the DARPA story. I think if it was not stretching so hard, you would not be getting the kind of breakthroughs that have been the history of the agency.
How do you measure the cost/benefit or return-on-investment up front?
If you can do a complete cost-benefit analysis, it is not a DARPA problem because now you have a much clearer sense of what the payoff would be.
That is not to say that we do not sit back and ask ourselves how possible this is. We do ask the questions, "So what is new? Why do we think we have a chance?" I think that is an important consideration, because there are ideas that come along that are not ready, it could be that computer processing power has not reached a certain level.
There have been ideas for new types of algorithms, in terms of solving problems, handling data. But, you did not have the processing power — Moore's Law had not taken you far enough along. That is one thing I like about the word "re-search" because it is all about re-visiting, researching what someone in the past may have explored.
Then we always like to ask, "What makes you think you can do it?"
How does DARPA support civilian agencies?
We find in the case of our particular office, since we are software focused, the advances we make can be picked up by the commercial sector, which ultimately then can benefit the government as a whole.
Inside a software program there is early work that DARPA did with the randomization of addresses. Those kinds of innovations have made headway moving into software companies, which then the government can reap in terms of buying the product.
We have also seen startups that we will help develop the technology. It is up to those entrepreneurial individuals to go off but we have had quite a few occur with our programs.
One other aspect worth emphasizing is we have pioneered this open catalog within DARPA. It is on the DARPA website, you can Google "DARPA open catalog." It is more for the technical folks but there is a listing of programs that someone can explore further. It is a starting point.
Aaron Boyd is an awarding-winning journalist currently serving as editor of Federal Times — a Washington, D.C. institution covering federal workforce and contracting for more than 50 years — and Fifth Domain — a news and information hub focused on cybersecurity and cyberwar from a civilian, military and international perspective.
