Getting software into the hands of soldiers in the field is a long and complicated process. Unlike, say, a software rollout at a corporation, the vagaries of security, system compatibility, and resource access can turn a standard deployment into a years-long ordeal.
Last week Resilience spoke to Enrique Oti, the CSO at Second Front Systems, a US-based company that speeds up that process in the United States and Europe. Thanks to his company’s connections to the Department of War and the Ministry of Defence, among others, the group can push software through in a few months thanks to their experience and multiple clearances.
Oti explained how the process worked, why it was vital, and what he’s seeing when it comes to fast-tracking technology due to the Ukraine war.
Resilience: Why don’t you tell me a little bit about Second Front?
Enrique Oti: What we’re working on is trying to close the gap between capabilities and delivery to the warfighter. As you probably well know, there’s a huge challenge with the government trying to onboard, integrate, secure, and accredit commercial technologies.
And so what we’re doing is we run a platform on top of military infrastructure, everything from the cloud to the edge, to allow the military to find commercial technology, bring it in, and try to get it up and accredited in a matter of weeks rather than spending tens of millions, hundreds of millions of pounds, and taking 18 months to two years.
Resilience: What takes so long for all this software to be accredited, do you think? Why is your team necessary in the equation?
Oti: At the end of the day, these problems have existed, honestly, for decades. And there are a few underlying issues that are causing the delays in these approaches. So the first one, I think, is security. What the military does, especially in regulated or classified environments, requires a different level of security than what your standard piece of software is out on the open internet.
And so that security drives necessary changes to infrastructure, networking, and certain controls. If I was a commercial software developer and I’m just deploying something out to AWS, I have full control over my infrastructure, networking, and configurations. In the military, I don’t. The military controls that. MOD controls that. Defence Digital controls that. In the US, it’s controlled by whoever is running that cloud.
And so there’s just a pure configuration aspect. To get software onboarded, you’re going to have to do configurations that just take time. The commercial vendor is going to have to change their software, and then the government’s going to have to work on the configs to make sure that software works. So there’s a base-level technical workload.
Beyond that, though, there is an organisational workload, which is that for a commercial company, they may not have the security clearances. How do they access an environment that they’ve never worked on? Especially for dual-use tech startups, a lot of startups have not gone through that rigorous ListX process, facilities clearance process, to be able to work in those military environments.
So it’s actually very hard for them to configure their stuff because they’re deploying blind into an environment that they don’t know how it runs, and they have to go back and forth through trouble tickets to iterate on it. And from the government side, again, no one in the government is an expert on all software. So when you’re actually trying to answer questions through trouble ticketing systems, it’s really hard to get at the real granular details.
And so there’s that whole bureaucratic aspect of it. It’s hard for a commercial company to work in this environment if they’re not used to it. And then the third one comes to the assurance process itself. The process for assurance, it’s great in concept, but in practice it’s manual. It is dozens of different documents, literally hundreds of pages of Excel spreadsheets, diagrams, and Word documents. It is static information that requires extensive review by the government and extensive rewrites by the commercial vendors.
And I’ll give you an example. We’re running through this right now with an MOD customer. It’s taken us, we’re probably approaching about, I’d say, seven or eight months of work just to do the paperwork. This is without any of the engineering time associated with it. Just the paperwork has taken over half a year already.
Resilience: You’re talking primarily about software?
Oti: Correct. Obviously, hardware has similar challenges, but hardware testing, there are obviously a lot of regulatory aspects of hardware testing that have been around for a long time. But in the way we are approaching it, in a world that is very software-defined, especially with AI, everything is truly software-defined. If you can’t update your software fast enough, it doesn’t matter that your hardware is good and secure if your software can’t enable a capability. And so our approach is actually, how do you make the software deliver and secure faster?
Resilience: Is there more general urgency associated with this right now, or has it been the same?
Oti: I think the urgency has changed. I think the understanding of the problem probably goes back at least a decade, where people have realised that the pace of commercial technological change, that the military is no longer driving that change, therefore the military must adopt commercial tech. So that has been a realisation for at least the last decade, two decades. And so it’s probably about ten to fifteen years ago when you start seeing these first inklings of how we do software security and accreditation differently, at least in the US system.
I think the war in Ukraine has driven that home for Europe. And what you’re seeing is in the UK, in NATO, and on the continent, a real understanding that yes, software is a core component of warfare. And if you can’t deliver and secure software faster, you can’t keep up. And so I think there is a radical understanding now of the importance of software.
Now, has that driven actual change in the processes? I’m not as optimistic. I don’t think it has. I think there are pockets of excellence where this is occurring right now, but I think in the wider system, a lot of people are still trying to do rapid software adoption using traditional approaches, and obviously there, that’s a disconnect.
Resilience: Let’s say I’m a startup and I have a tool that might be dual-use. I want to put it in for the approval process. What’s the timeline for those things now?
Oti: Again, it depends on what we’re talking about. In the US, there are pretty understood timelines under the FedRAMP system or the DISA provisional authority system, that you’re probably talking about eighteen months to two years under traditional methodologies. Obviously, our approach, our target in the US, is less than 90 days.
In Europe, and I’ll speak mostly NATO and the UK, that’s where we have most of our experience in the last couple of years. I think in NATO and the UK, the answer is it depends. And the reason is that I think the processes are less clearly defined. The overall structure of assurance and accreditation is laid out in a lot of documents, NCSC cloud principles, Secure by Design, some policies like JSP 453 in the UK or D32 in NATO. So I think at the high end, a lot of the overall structure for assurance and accreditation is laid out.
But in practice, what we’re seeing is not a very clear and consistent methodology. It’s very difficult for the commercial vendors. You may talk to one security official who can walk you through the process in months. You may talk to others where it’s literally years of paperwork. And we’re seeing this especially, I think NATO runs a spectrum. I’ve seen some really fast processes in NATO, but I’ve also seen some of the slowest processes possible in NATO. I think in the UK, you don’t have the extremes, but I think you have a pretty set norm of a relatively slow process. But it’s driven less by the amount of work and more by the lack of clarity in the procedures involved in that work.
Resilience: If I were a small startup in Estonia, would I work with you guys? Would I do it myself?
Oti: Well, obviously in the US military, I think we’re probably by far the cleanest, fastest, most repeatable path. We could take a non-US company. We’ve done this with multiple of our customers. We can run them through our processes, get them in front of an accrediting official, and get them accredited on a classified network in less than 90 days. And we’ve done this over and over again for the last few years. So I think in the US market, we’re clearly the path to unclassified IL4, IL5, Secret, Top Secret.
Over here where we’re trying to expand to, I’ll have to say we’re not there yet. For example, NATO. We are under contract with NATO DIANA to basically deliver capabilities into the NATO enterprise. And we just put out our first application on behalf of NATO DIANA, and it took 17 days from start until accreditation to get them up and running. Now that’s a sample set of one.
I’m hoping going down the road, it continues to be that fast. And part of this has to do with, let’s just be blunt, DIANA is really becoming a beacon of excellence when it comes to innovation in the NATO ecosystem, between their rapid adoption model for contracting and the way they are now approaching cybersecurity and compliance, and us running that first app through. I think you’re seeing DIANA going forward is going to be probably one of the best paths into NATO for a lot of these countries, like Estonia, like a German company, you name it, any UK company.
But I’ll say we’re not there yet. We’re there on our first use case. We have a second app that’s about to go through the system right now. And what we’re working with NATO on is then how do we take this capability and move it away from NATO unclassified and move it up to NATO restricted and NATO secret? And again, between DIANA and NATO SHAPE, you’re seeing some really innovative approaches to security and compliance where our methodology ends up being, honestly, the technical enabler of that leadership that has a new vision.
In the UK, we’re getting there. So we ran a pilot program with the British Army that was very successful on MOD Cloud, on their AWS ecosystem. And we’re in the process of deploying out to Navy Digital Hosting, which is the Royal Navy’s cloud. We’ve got our authority to test, and we’re working down the road for our first app deployment and our authority to operate through the Royal Navy. So I think what you’re going to see over the next few months is the general availability of our product inside the MOD.
And then we’d have the ability, if there are vendors, whether they’re UK companies, European companies, or American companies, to be able to move quickly through that accreditation ecosystem, assurance ecosystem, in the UK. Again, we’re not there yet. I think we’ve demonstrated with the Army and the Navy our ability to move fast and implement security and accreditation differently. But we can’t say that right now we have a generally available platform for vendors to come through.
Resilience: What do you think is missing in the ecosystem right now?
Oti: I think in the US ecosystem, what you’re missing is kind of the idea of reciprocity, which is there’s still kind of a delineation between accrediting officials, that just because one accrediting official has approved something, the other one should or should not approve it. That reciprocity is not quite there. It’s getting a lot closer, though. There’s a lot more understanding, especially as we’ve been able to show technical evidence of security.
We can show that evidence to one official, they’ll accredit it, and then we show it to another official, and they’re like, yep, that’s good enough for me. And we start building these relationships among accreditors. So I think the US, it’s coming together, not through a top-down-driven approach, but more through kind of a spider web of different accreditors working with each other, working with us, and going, yeah, if it works here, it should work there. And so the reciprocity is still, I think, the last remaining hurdle in the US.
But the ideas of cloud operations, cross-domain transfer, continuous authority to operate, CI/CD pipelining, continuous monitoring, these theories have actually been put into practice in the US pretty well. And I think they’re pretty well understood.
In the UK, I think there are a couple of issues that are still not quite there yet. One is obviously the adoption of cloud. Cloud adoption is still an ongoing process with the Ministry of Defence. MOD Cloud is there in a UK official classification. But you’re still seeing the use of the cloud is still kind of very stovepiped. There’s not a lot of true shared services across the frontline commands and MOD in terms of once you deploy one capability to the cloud once, it’s available for anyone. So the idea of how you have software as a service or platform as a service in an unisolated cloud like MOD Cloud, that process is still kind of ongoing.
I still think there is a limitation idea of technical security and assurance versus documented static assurance. I think there still is a reliance on, to prove it, you need to fill out documentation versus proving it in code and proving it through alerting and monitoring. And again, that’s changing. We’re seeing that in a few areas, people are kind of approaching that new model. Even within Defence Digital, you do have a continuous authority to operate methodology that is starting to kind of catch on, but you’re not seeing it really widespread.
So I think it’s just kind of a comfort level by senior leaders with cloud and new cloud methodologies that I think is still lacking. NATO, I think it’s actually just that there’s an absence of clouds, just to be honest. I think NATO is still kind of understanding how you operate clouds in a manner that is both supportive of a coalition, but also supports sovereignty of the member states. And that is actually, to be honest, a very hard nut to crack because it’s not just at that point about security and accreditation.
It is about data management, it’s about data tagging, it’s about cryptography. And so NATO, obviously, because of the member states, is a little bit harder to challenge. And so even though they probably have a much more centralised security authority as opposed to the MOD, which is very federated and decentralised, I think NATO just has a tougher problem to solve technically on how to then do this in an automated manner. And again, there are some shining lights in NATO that are really pushing hard at this.
But it is a tough challenge in a coalition environment.
