How DIU is supporting Cyber Command

As U.S. Cyber Command is maturing, it’s looking to bolster partnerships with labs and research arms across the Department of Defense and private sector to provide cutting-edge equipment in order to stay ahead of threats.

To that end, Cybercom has been working with the Defense Innovation Unit, the Silicon Valley-headquartered organization whose mission is to help the Pentagon tap into the venture capital and commercial worlds to advance and integrate technology more rapidly.

DefenseScoop recently interviewed DIU’s cyber portfolio lead Patrick Gould about the unit’s support to Cybercom and how it works to solve the command’s hard tech problems.

Editor’s note: The following Q&A has been lightly edited for length and clarity.

Can you give a rundown of what DIU is, what it does, how it gets its requirements and solicits the commercial sector?

GOULD: Our portfolio has gone through some iterative changes over the years that DIU has been in existence.

We started as the IT portfolio and we did a lot of generic problems and projects in cloud migration, enterprise data environments, a lot more infrastructure build, productivity tools, and then enterprise IT and a lot less targeted security projects.

Over time, we realized that a lot of the demand that was coming into us was for just generic cloud services. And we felt that we had proven out the government’s ability and the DoD’s ability to use [software as a service] applications for productivity and for cloud services and whatever their application needs were at the time.

We pivoted pretty strong to more cyber warfare-type projects, mostly because the people that we [had] at the time came from the cyber warfare community.

Our team is really, really unique in that we have a cyber operator or a cyber warfare engineer from each of the Army, Navy and Air Force now. We’ve been working together [with a] Marine Corps officer as well. But then coupled with some folks that don’t have any military or government experience, or strictly commercial-based [that] have built companies, founded companies, sold companies.

I’ve worked at big companies, I’ve worked with small companies. We pair them all up on the team together. Our team has nine people right now and that unique background really helps us explore that commercial market, but also really understand that warfighter need and that operational analysts’ need from the DOD.

Most of our projects and the most successful ones are demand driven, so they do start from a DOD customer, usually a Cybercom, service cyber component, or DISA operator/analyst comes to us and says, “Hey, I have this operational gap or this problem that I can’t seem to figure out how to get solved or our acquisition community hasn’t delivered a solution for yet, or we were not sure that we fully understand the solution space. Can DIU help us scope that problem and go find that solution?”

We don’t deal with hard and fast requirements, like the traditional acquisition processes does. We deal in pretty human readable, easily readable, like one paragraph problem statements, so that we’re not prescribing, “We need something that runs on this type of hardware or this type of software and is painted this color.”

We don’t want to limit that customer base. We want to go solicit to the commercial sector [and say], “Here’s a problem we’re looking at. Do you have a unique solution, do you have a product solution, do you have something that you buy from someone else that you’d like to propose to us and then we can get that in front of those operators?”

Then that’s when we run our solicitation and we do the nuts and bolts of that — the CSO, the commercial solutions opening — which is our interpretation of the OT statute, so the Other Transactions purchasing type.

It’s just the process of how we go from problem curation to open solicitation and then funnel usually in our portfolio like 40 to 50 companies that respond down to two or three at the end of that, that we’re going to award a prototype contract to.

Then at that point, it’s fun, because it’s different than the rest of the acquisition community where we get to retain a vendor to provide a solution to the people that actually need that solution and they can test it, usually for six months to a year in our portfolio. Sometimes it’s up to two years, usually when you’re building hardware, or you’re integrating hardware, that timeline is a lot longer. But for us, most of our problems have been software based for us, our solutions have been software based.

You can really test a lot faster. We’ve done some like four months of testing after like a 30-day award period. We’ve also done ones that have taken a little bit longer, a year to two, but we’ve never done one more than two years in our portfolio.

Then the unique thing at the end of that process is if you declare success on that prototyping period — so if you use this thing and it provides some level of benefit to that operator or analyst or to that community that asked for it — there’s an opportunity for that vendor to go directly to production so they can be the sole provider and the sole solution for that problem area for the DOD without having to go back and re-compete.

That’s really like the carrot that that we dangle in front of the commercial market and the commercial community that’s out there is the ability to not have to go back through the process from the start and you get to go directly to being in the hands in some sort of live, operational context.

What’s the process in terms of getting that capability need from a component, putting it out to industry and getting a solution?

GOULD: There’s a lot of work in that problem curation phase, where our PMs and our analysts within our team get together and try to figure out no kidding, yes, is there a viable commercial market to solve this problem?

Then what we’ll do before we even post that solicitation is we’ll go out and we’ll talk to some of them, we’ll try to meet some of them. We’ll try to talk to some of the big, similar industry types to the DOD, like banking teams and large corporations, large corporate security teams, and figure out what they’re using to solve those problems to try to unearth some new vendors.

We had very, very unique relationships with the private equity and VC community. We talked to people like, “Who are you funding that has a solution in this area?” And we’ll do a lot of that market research and diligence with those folks.

But then, when we post that solicitation, it’s actually open to anyone. That mechanism is through our website at DIU.mil, there’s a “Work With Us” and open solicitations tab off the homepage there. That shows the specific problem statements that are available to be responded to right now. It has all the specs about the timeline and what’s needed.

We typically ask for no more than a five-page white paper or a 15-slide deck that describes that company or individual’s response to that problem statement that we put out. We want minimally modified things and products and slicks and material for that. We don’t want people to respond back to us with the exact problem statement that we gave them and [just say], “We will solve this.” We want to see an actual solution.

Most of the — on the cyber portfolio, the solutions that we get are mature security products that already have a market that are already being used by a number of customers. We’ll even go reference some of those customers to figure out how they liked it as we do that down-selection process … There’s a bunch of different metrics that we use to down-select those products as products to the two or three that make the most sense. Then ultimately, it’s up to that customer that came to us, that operations team or that analyst team that came to us initially, they get to make the final call.

We help facilitate this process and we help provide the justification and we help sway away from a vendor product that might not make it all the way through that process. But ultimately, what’s unique about this is that it’s the operators and the warfighters who make the call because they’re going to be the ones who are using it and they’re going to be integrating it.

Can you talk about some of the recent cyber projects that you guys have been working on?

GOULD: Over the past two to three years, we’ve done a whole bunch of series of projects with the DOD cyber community. A lot of them were focused on threat intelligence, threat data analytics, threat telemetry and threat data integration.

We actually did a four-step process with Cybercom over the past few years. And the first two stages have fully transitioned to operational use case and the third one is now in the process of transitioning from that prototype to production. And they were all around commercial threat data and threat intelligence.

It was estimated at the time that we started that industry threat intelligence providers and industry threat intelligence analysts held about 85% of the threat data as it relates to all the ongoing threats that are out there in the world — and the exquisite military intel collection capability was only really looking at 15% of it. We had to find a way to supplement that 15% with the other 85% that’s out there.

First, we started with just raw feeds and then we tried to build a platform. This is like the progression of the project — it was raw feeds and raw intel, then it was trying to build a platform so that analysts and operators could actually access those raw feeds and that data in a usable way.

Then we started doing more analytics on top of it. Then [we looked at] how do you start to correlate trends, how do you start to generate our own intelligence that can feed back into these apparatuses and enrich that data? And then really what we’re looking for was how do we now start looking for datasets that are traditionally cyber intelligence datasets that will also supplement and enrich that data? Because we’re starting to see a lot more indicators coming from non-IP based systems and EW emanations and other weird device emanations that could be useful for Cybercom or for a DOD cyber community.

The biggest benefit there was you have operators that can access threat intelligence data on the things that they’re seeing in the field without having to go back and find a secure phone, without having to put in a request to the intel analyst to then go generate a report on what they’re seeing. They can do it in real time as they’re live on an operation.

Because it’s coming from a commercial tool they’re actually able to talk about, so it’s not inherently classified if it comes off of that commercial tool.

If you’re seeing an indicator or you’re seeing some warning, that needs to be looked at. It’s severely limiting … to be out there and not be able to talk about it because of the source that came from but you know that the commercial industry is looking at the exact same indicators or the exact same piece of malware or the exact same technique.

That was extremely beneficial for them to be able to do that in real time and be able to talk about it openly with both their customers, their mission partners and within their teams.

That’s probably the biggest problem area that we’ve looked at.

We’ve also done a lot of patch management, asset management, asset inventory automation, security operation center automation. We did some cyberspace deception work. And most recently, we have a problem area … that just kicked off on a prototype that’s looking into cryptocurrency analysis — how are adversaries using cryptocurrencies and cryptocurrency exchanges and the blockchain to hide their actions or to fund their operations?

The DOD realized there’s a gap there when it came to the ability to analyze how malicious cyber actors were leveraging these new technologies and these new money sources to do their operations against our allies and partners. We really had to go out and figure out what’s the best commercial market because it is definitely ahead of the DOD when it comes to crypto analysis and blockchain technologies.

We’ve mostly tried to look at areas like that — where’s the commercial market leader in the technology space?

Things like IoT security and advanced fuzzing and patch management and a lot of automation-type problems. The DOD spends a lot of time trying to solve things with math. We throw more people at it and hope that they’ll be able to analyze harder.

Industry has figured out that your security team only needs to be like four or five people if you can automate most of your processes and then you can free those four or five people up to do cognitively more intensive tasks, rather than sifting through event logs or threat data or whatever the low-level task of the day is.

Most recently, the latest transition, it was a Cybercom-adjacent project where they were looking at — the thought was Cybercom teams were being deployed to take care of threats against systems that should have been patched or should have been managed earlier in the product lifecycle. Between Cybercom and DISA they came to us and tried to figure out how is the rest of the industry automating different patch types — and then automating the testing of different patch types across the myriad of different system types that the DOD has.

The DOD has, what’s the estimate, is it 300 million or 3 billion endpoints all running different operating systems, all different pieces of hardware, all different architectures, all running different applications or have … specific, unique mission sets.

The way we used to control the patching for all those things is you do it by some poor captain at the command would send out an email and say, “Hey, we saw this recent patch, or we saw this recent high-profile threat, can you query all of your systems and then email me a PowerPoint or a table with some of what you have?” And then some poor schmuck back at headquarters has to like sift through that all and figure out exactly what patch that they need for each of those different system types and each of those different devices. Industry is not having those problems.

We automated that patch generation as well as then the patch testing. Then we were able to start to push patches as well and test them in a way that didn’t break an operational system. That was always a big concern, too, of those people who owned those systems out in the field was, well, “What happens if this patch someone else traded for me breaks my unique mission in some catastrophic way?”

Another thing that industry wasn’t worried about — they weren’t worried about a patch breaking their banking system, or their user interface or their customer interface. We worked with companies to do that.

Actually, that capability, it was a problem with the patching and the patch management community and more that enterprise IT community, but it was affecting the Cybercom teams because those systems that weren’t patched or weren’t patched in a timely fashion were now having to have Cybercom teams deployed to them to go clean up a threat or to go kick an adversary off those systems or to help them rebuild the system.

This is really interesting to see the joint collaboration between the enterprise IT folks, the systems owners, and then the response and remediation and threat-hunting teams that all have this collective problem but they all had a different piece of it.

But again, industry figured out how to do that well before we did, so that was a really rewarding one.