"It's not 'Will this solve my problem?', but it's 'How do I know that this will solve my problem?' Cross-domain solutions tend to be thought of from an acquisition perspective: 'If I have a cross-domain requirement and I want to solve that requirement, I need to go buy something.' A lot of missions get into that mindset without really understanding that it's way more involved and there are way more risks involved than, say, simply buying a firewall or something like that. Most leaders don't care about the nuances of cross-domain architectures. They care that the right data shows up in the right place so the mission can actually happen. The trouble is many programs treat cross-domain as an acquisition problem and only discover later that buying the box was the easy part.


 I'm Carolyn Ford, and on this episode of Tech Transforms, I'm talking with John Spicer, VP of Technical Strategy and Co-founder at Nteligen, a vendor-neutral cybersecurity and systems engineering firm focused on secure information sharing. John has helped architect and validate more than seven cross-domain solutions that made it to the baseline. And if you're in cross-domain, you know seven's a big number. He and I dig into why missions get stuck when they try to mitigate every conceivable threat instead of using a risk management approach and how that mindset leads to seven-figure hardware turning into shelfware because the architecture gets disallowed after the purchase. John talks about cross-domain as the so-called 'black art' of national defense. Not because the technology is mystical, but because breaking through silos of expertise and approvals is hard, and most mission owners don't even know all the stakeholders who have a say in their data flows. So instead of treating cross-domain like a box you buy and forget,John pushes leaders to start with a much simpler idea: the mission only works if the data actually moves where it's supposed to at an acceptable risk level. I started by asking him to strip the problem all the way down to basics:when a program exec is about to sign that cross-domain contract, what's the one question they absolutely must ask?"
Carolyn Ford: "What's the most important thing that a PEO should ask before they sign a contract for a cross-domain solution?"
John Spicer: "Great question. I think the answer to that is actually pretty simplistic. It's not 'Will this solve my problem?', but it's 'How do I know that this will solve my problem?' Cross-domain solutions tend to be thought of from an acquisition perspective: 'If I have a cross-domain requirement and I want to solve that requirement, I need to go buy something.' And a lot of missions get into that mindset without really understanding that it's way more involved and there are way more risks involved than, say, simply buying a firewall or something like that. The processes can take a lot longer, the architectures can be more complex, and the approval timelines can be really long. So, I think people need to always step back and say, 'How do I know this is going to solve my problem?'because it means that they've actually sat down and thought about the end-to-end solution. Not just buying the CDS, but how does my data flow get operationalized? What about this is going to make sure that my mission succeeds? Because at the end of the day, if your data is not flowing and your mission isn't successful, then none of this is really important. So, I'd like to make sure that our clients are understanding how they're going to be successful and kind of get out of that mindset that 'I have to go through an acquisition process.' They do have to go through an acquisition process many times, but that in and of itself is not the solution."
Carolyn Ford: "Don't organizations buy cross-domain solutions because they have to?"
John Spicer: "They do buy cross-domain solutions because they have to move data."
Carolyn Ford: "Okay."
John Spicer: "Does that mean that buying a cross-domain solution for their mission was the right move? No.Maybe there are other cross-domain solutions that have been already deployed and are operational from other mission partners or other places within your organization that can satisfy your requirement. And so from that perspective, I would say not every cross-domain requirement requires an acquisition. Sometimes it just requires partnering up with someone who already has an existing data flow or an approval that will allow you to use their system to transit your data. And that could be anywhere from getting an approval to create a new data flow on that system that's already pre-existing, or it could be as simple as your data type is already approved for that system and you can partner up with somebody to co-mingle your data."
Carolyn Ford: "I feel like this dovetails into—I've heard you say, 'If you need a guard, call a vendor. If you need to move data, then you call us.' Right. So talk to me about that. Talk to me about operationalizing the mission."
John Spicer: "So the reality is that whenever there's a cross-domain requirement, there's a mission mandate for it.It's the only reason we would deploy CDS systems—because some mission somewhere has a need to share data across a boundary. And that is, for all intents and purposes, a method to achieving a goal. It is not in and of itself a goal. No mission really sets out—unless you're standing up an ECDSP or something—no mission stands up and says, 'I want to deploy a cross-domain system.' No, what they're saying is, 'I have to share my data with a partner, or with another system on a different network.' And this is really coming into play when you start looking at JADC2 and the mandates we have of being able to do all-domain, air, space, command and control, sharing information from sensors and whatnot. So at the end of the day, if we can't operationalize those data flows and the missions aren't successful, that's a bigger engineering and architectural project than buying the guard that sits at the boundary between the two networks, because you have to integrate with them. You have to understand, 'If I'm going to move data over this guard that I want to buy, what is the threat of that data not only to my mission, but what is the threat that that data could be posing to the rest of the network owners or the segment owners that I'm integrating with?'And so the questions and the engineering architectural considerations are much larger than 'I want to buy a CDS and install it.' We have to make sure that that data is going to be able to be moved, it's going to be safely moved against some risk tolerance, and that we're not injecting risk into other missions or other network owners. And so the reason we say, 'If you want to buy a CDS, call a guard vendor'—yes, absolutely. But if you want to move your data, people call us because the guard vendors are really focused on building a product that meets a need, and can get certified, approved, and deployed. And I don't mean this pejoratively, and making sales, right? But guard vendors are not in the position where they're going to get briefed on every program that buys their CDS. A lot of them don't even have the security infrastructure to support that. So their visibility is limited into the missions that want to make use of their stuff. So their ability to ensure that their stuff is fully compatible and that the integration architectures are all correct—that's difficult for them. And this gets back to what we were talking about: at the end of the day, it's the operationalization of the mission that is the goal. Buying and deploying a CDS is only one engineering aspect of achieving that goal, and it's very hard to do that with a myopic view of just the CDS product itself."
Carolyn Ford: "Do you think programs get stuck because they think, 'Oh, I just need to buy the CDS,' without thinking about the end problem they're trying to solve, which is to move the data? Is that where they get stuck, or are you seeing programs get stuck?"
John Spicer: "Yes, definitely seeing programs get stuck. And this goes back to one of the things that we talk about a lot: there's kind of this notion that cross-domain is a black art, right? It's a black science; only the super nerdy gurus get it. I kind of hate that moniker because what we'll tell people is that the technology and solving the cross-domain system isn't the black art. The black art is actually breaking through the silos of expertise, because the lifecycle of deployment and using a cross-domain system is very vast, with a lot of stakeholders. And a lot of times, these stakeholders are not even known to the mission clients, because the missions are thinking in terms of, 'I have this weapons platform I need to get data to,' or 'I have some application that I want to get data from,' or 'I want to get some data from sensors into an application that an analyst can sit at,' etc. They're not thinking necessarily in terms of, 'Who are the stakeholders that own all the networks? Who's the CDTAB? Who's the DOG? Who's the NCDSMO? Who's the ISRMC? How do they all apply to me from an approval perspective when I'm just trying to move my data into my application?' And so the places where we see missions get stuck is simply they get drowned in the sea of not knowing the landscape. But what they are familiar with—and to talk to something we mentioned earlier—is they're familiar with the ideas of like a firewall, right? 'Well, I kind of understand the process to get a firewall installed at a local network segment.' But the risk considerations of cross-domain operations are so much more in-depth and have so many more stakeholders. This is where missions get caught up. They want to go buy a CDS, but they don't understand everything that goes along with that, all the architectural considerations for their use, and how to threat model their data to understand why they're doing this safely or be able to defend why they're doing this safely. And so we've seen a number of scenarios where—I hate to talk about it, but it's true—missions will go out and they will short-step the process sometimes out of ignorance, sometimes out of impatience, but they'll end up buying a bunch of hardware that ultimately they never get approval to use because they didn't actually understand the landscape in which they were operating and because generally, at times, they got bad advice."
Carolyn Ford: "I really like that the black art is the silos of expertise because my brain translates that as it's the people. They're not understanding, like you said, the landscape—all the different stakeholders that need to buy in that will have to give approval to use it. Am I getting it right?"
John Spicer: "Yeah. So we tend to look at this—at Intelligent, we look at this from a lifecycle perspective. We're big into systems architecture and understanding engineering lifecycles, and we actually look at this as two separate lifecycles from two different types of clients. We have some clients that are actual CDS vendors themselves, where they're trying to build CDS products and maintain or achieve RTB compliance, yet they're trying to hit functional roadmaps, support their clients, etc. And just from a CDS vendor perspective, there's a whole lot to this: there's requirements analysis, security design, security design reviews with the NCDSMO and other stakeholders to make sure that your security architecture is appropriate and we think you're going to be good with RTB. Then there's developing it, testing it, going to the lab and doing test readiness reviews, operating the CDSs in the lab, and helping the lab understand what they're testing, all the way through to getting on the baseline. There's this really complex lifecycle there. And even within the CDS vendors, there'll be people that have different areas of expertise for each part of the lifecycle they're working in."
Carolyn Ford: "Right."
John Spicer: "So, we've done a lot of that work. On the flip side, if you look at it from a mission perspective, a mission perspective also has a lifecycle. Now, their lifecycle isn't about building a CDS, but their lifecycle does start with a requirements analysis, understanding their data, and threat modeling their data to understand how their data may or may not pose a risk to themselves and others. Then there's, 'How do I select the right CDS?' And you go all the way up the mountain, and each one of those segments might have a different person or subject matter expert involved, and a different set of stakeholders for approvals, right? So what we have found is that a lot of people don't understand all the stuff that's involved. Where Intelligent generally comes in is we've done both: we've developed a number of CDSs that have been approved for baseline, helping vendors, and written some bespoke stuff for the government, but we also do a lot of work on the mission side. And the thing that we see time and time again is that very rarely do people understand one lifecycle, much less two, and the interplay between them. So you may have, for instance, a contract provider that's really good at saying, 'I can run a data center, install a CDS, and configure a CDS.' But do they really understand all the limitations with which that CDS was saddled? Do they understand the 'whys' related to the best ways to integrate them, the best ways to get your data flows set up with them against your mission applications, etc.? So the thing that we're always seeing is, honestly, the technology is tedious and intricate, but it's not a black art. It's not super complex to understand. What is complex to understand is how all these things play together. Which is why we say at the end of the day, it's not about buying a CDS; it's about getting that data to move. Because all these things have to be successful to get the mission to work. And if the mission's not working, it doesn't matter how many CDSs you buy or what their configurations are."
Carolyn Ford: "The guy in the fatigues, the mission planners, and the people who are making decisions real-time in theater have to have their data."
John Spicer: "That's right."
Carolyn Ford: "How common is it for you to go in on the mission side and see that they've already bought a CDS and it's really just going to be shelfware because they didn't get the right CDS? Is that a thing to not get the right CDS, or are all CDSs the same?"
John Spicer: "It is a thing. Not all CDSs are the same."
Carolyn Ford: "Even if they're on the NCDSMO baseline—like I should be able to just pick one, right?"
John Spicer: "No. Well, maybe you should be able to, but that's such a multivariate question. The answer is I've seen it more often than I would like, and usually it is due to a series of missteps—unfortunate missteps based upon not knowing what the process really was and then taking some advice. And this goes back to talking with vendors. Vendors can tell you what their CDSs can do and they can help you understand how CDSs can integrate and solve some of your problems, but they're not generally in a position to ensure mission success from an end-to-end perspective. And I see gaps where a mission customer will talk to a vendor and make some assumptions about how confident they should be based upon their vendor conversations. Notionally, if you look at the larger model, especially in the DoD or now the DoW side where we have CDS and we have the 8540 process, a lot of these processes are built out to help people make the right decision, but unfortunately they don't always. And I have a client right now who pulled us in because they have seven figures' worth of CDSs sitting on a pallet in a loading dock, and they've been there for a while because their initial thought on what the architecture would be was disallowed after they made the purchase."
Carolyn Ford: "Oh wow. Are they going to be able to use them?"
John Spicer: "We are working through that right now. We are working through how to either repurpose those CDSs—because they have a number of CDS requirements—and also looking at, 'Can we salvage this particular set of CDS requirements using this hardware?' So we're in a bit of a regrouping stage on that, but they're not the only ones, unfortunately. To your question of, 'If it's on the baseline, can I just use it?'—that's like saying, 'Hey, all cars in the parking lot are the same.' I don't think the vendors themselves would say that; they'd say, 'Wait a minute, we actually have areas of competition. We have different features and different capabilities.' And that is very true. If you look across the fleet of CDSs on that baseline, there are definitely different capabilities that some do well and others just don't do at all. And then there are also different risk postures associated with those different devices that play into the risk decision. That goes back to: What is the lifecycle? What is the end architecture? What risk decisions are we making? Because all of these are predicated on making risk decisions for their use. What is the residual risk I'm willing to live with? What risks am I mitigating? And so the picture is always much bigger than just 'Is my CDS on the RTB baseline?' That's kind of like the predicate function."
Carolyn Ford: "Mhm. It just—I guess I think if I need a CDS, I probably have this pretty straightforward mission, right? I just need to move data."
John Spicer: "This is where I like to change the conversation, because when you say, 'I just need a CDS,' you have made so many presuppositions in that statement. What you actually need from a mission perspective is you need to move your data. Right? And so let me start at that. Which data do you need to move? How do you need to move it?Yes, you very well may need a CDS, or you may need multiple CDSs, or you may need multiple different flavors of CDSs. So it's not that you're wrong; it's just that these things aren't necessarily interchangeable as you might think of a typical network appliance, right? Also, every CDS decision goes through an analysis of a tuple: What is the data? What are the specific networks involved? What are the classifications involved? How does this CDS manage the risks associated with those things? So this idea that there's just a CDS as a generic capability, and I pick my best flavor and throw it in, isn't quite right. That kind of betrays the complexity of the risk equations involved. Like I said, it's not that it's super rocket science, but understanding how all these pieces fit together—it's very easy to put yourself on a path and then discover a new stakeholder six months from now that didn't like a decision you made six months ago."
Carolyn Ford: "Mhm."
John Spicer: "It's the world that we live in, unfortunately, because we really do have to understand what we're doing and why, and protect ourselves from our adversaries, because the threats are real."
Carolyn Ford: "Yeah. Let's talk about guidance, compliance, and regulations around those threats. So the National Cybersecurity Strategy came out in March of 2023. It calls for the modernization of IT and OT infrastructure. It included a shift toward zero trust within things like multi-level security and mission partner environments. Can you explain how you see cross-domain solutions fitting in these new paradigms?"
John Spicer: "Yes, that is a great question, and it's an area that is ridiculously fraught with confusion right now. It is very confusing to people. We recently did some work on behalf of the Air Force—specifically Air Force Research Lab—and we wrote some papers on ZT versus MLS versus CDS to try to make this a little bit easier for some key stakeholders in the Air Force to understand, and that has been helpful. I think in this topic, there are two big foundational truths to be held. The first is that ZT and CDSs are actually complementary technologies, but they're not the same technologies."
Carolyn Ford: "Right. I've heard, 'If you have zero trust, then you don't need cross-domain,' which, when I first heard that, I just thought, 'Well, that's crazy and kind of stupid to say that.'"
John Spicer: "Yes."
Carolyn Ford: "Because why wouldn't you need both? And why wouldn't—like this defense-in-depth kind of idea? But please continue."
John Spicer: "Yeah. We hear that all the time, and as a matter of fact, that's kind of the basis for—"
Carolyn Ford: "You're still hearing this?"
John Spicer: "Oh yeah, all the time. It's not just that I hear it; it's that you walk into environments where it's just been assumed: 'ZT is the new thing. Off we go.'"
Carolyn Ford: "We've got ZT. We're good."
John Spicer: "Yeah, exactly. Look, ZT and CDS architectures uphold some very similar principles in making access decisions. They have concepts such as principle of least privilege, principle of least knowledge, right?Where ZT is using attribute-based access control to make decisions on who can see what at any given time, that's very much the same type of concept that CDS operates under. However, they do it in very different ways with very different levels of confidence. So, if you look at ZT—and we'll talk a little bit here about MPE versus MLS—if you look at ZT being used where let's say the backbone is MPE, there are a lot of publications about that, right? So I have MPE. I have a secret environment with different people from different partner nations, right? And I'm going to use attribute-based access control to decide who can see what. Well, those are all still bound within the secret arena, right? We're not necessarily saying, 'I want to connect a top secret network,' or 'I want to put top secret people into this environment with people that don't have any clearance,' and we're not mixing classifications up. A CDS really kind of does that, right? We are connecting a network of one classification to a network of another classification. And this is when you can get into like the old PL models, right? PL3, PL4, PL5. And they are actually separating things based upon classification, and the stringency of their security controls in the underlying mechanisms that make the assertions are stronger than what has traditionally been viewed as the ZT mechanisms. So I think this is part of the reason why they tend to get confused—because they sound like they're doing the same things, and in many ways they're upholding the same principles and using the same principles to mediate access to entitlements and whatnot. Similarly, let's talk a little bit about MPE versus MLS. They are also very similar in context. They allow people with different entitlements access only to the data that they're allowed to see within a common environment, right? But the mechanisms by which they do that are the same. So, if you put someone in an MPE environment that isn't a cybersecurity nerd, it sure feels like they're living in an MLS environment, doesn't it? It's the same concept. So why not just use that as an MLS environment, right? Well, in 'nerd speak,' we would say it's not yet been proven that the strength of function or the strength of the mechanisms that guarantee those controls are strong enough for an actual MLS environment, where you might have someone with TS and all the compartments in the same network environment with someone that just has Secret. Those are very different concerns."
Carolyn Ford: "When you say the strength of the mechanism, are we talking about software strength like a firewall versus hardware-enforced? Is that what we're saying here?"
John Spicer: "That's a great question. Even that is an example of one mechanism being stronger than the other. So yes, that same type. Now we have software CDSs where the mechanisms within those CDSs have a much higher level of confidence than, say, something that's running an application space on top of a Windows environment. A lot of those things are tied back to kernel enforcement and mandatory access controls on the CDS side, whereas you don't always get that level of confidence on the ZT side."
Carolyn Ford: "Got it."
John Spicer: "And this is not to malign ZT at all. It's a very powerful tool, but what is getting crossed is where things apply or where things don't. The reality is they're very complementary, because what I see—and this is the thing that we've looked at with MPE and some other stuff—is when I want to get data into those environments, how do I do it securely so that the security assertions within those environments are upheld? So it's still upon us: if I'm going to import data into an MPE environment, how do I do it so that all the assertions that the MPE environment gives me or the zero trust environment gives me hold? And so this is why I say CDS is a complementary technology, and I think we're still figuring out how they interplay. And I'm also being a little bit lazy—I want to caveat that ZT and MPE aren't the exact same thing, but they're closely related because MPE is a great example of what you can do with ZT."
Carolyn Ford: "Okay. Well, for me, zero trust, as I've learned it, is an architecture. It's a philosophy, not a tool. It's an architecture, and you need multiple tools to actually make it work."
John Spicer: "Yes."
Carolyn Ford: "So my mind thinks, 'Well, why wouldn't cross-domain be one of those tools in your zero trust architecture?'"
John Spicer: "I love that question. I believe the answer to it is simply to acknowledge that, from a technical perspective, I think your view is valid. But in practice, when people are going out and talking about ZT, they're talking about more than a philosophy. They're starting to go down the path of making it synonymous with the implementations and products that we've been seeing that you can get into your cloud environments or on top of systems that are pre-existing. And so it's not necessarily synonymous with the model itself; that word has morphed into implementation mechanisms."
Carolyn Ford: "I see. So there's a zero trust club, and cross-domain is not part of that club right now."
John Spicer: "I think it's fair to say that from a layman's perspective. From an architectural model perspective, I would very easily agree with the statement that cross-domain systems are the original ZT architecture, because that's how they're built internally, right? You take the concepts of least privilege, least knowledge, and saying, 'I trust nothing in every single operation; I'm going to revalidate.' That's kind of how CDSs have been built for years internally. And now that model has been pushed out to the broader environments, which I think is great. But the implementation mechanisms there, I believe, are starting to get subsumed into the ZT concept. And so this is why I still tend to make a distinction here. But let's also be honest: we've gone down the 'nerd path,' and a lot of people don't actually think about things quite this critically."
Carolyn Ford: "Okay, let's talk about the deadlines in the National Cybersecurity Strategy. So there are deadlines to put zero trust in place—well, there have been these deadlines forever. But on systems that we know actually can't support it, like these old SCADA systems, especially in OT, how do you see that playing out? Are programs going to meet it, and how are they going to do it?"
John Spicer: "The 'gotcha' of all gotcha questions, right? Honestly, I do find that to be a very hard question to answer because it's such a wide landscape. We can look back at systems everybody knows, right? We have systems today running that arguably were obsoleted years ago, but they're just really good at what they do, and the cost of moving them over has been very high. And someone somewhere has done a risk analysis that says the risk that running the system poses is quite acceptable compared to the risk of trying to move it, etc. So, do I think everything will move over to ZT? No. Do I think as much stuff as reasonably can be moved over to ZT will happen? Likely. I think the more interesting question is probably not how far we will go; to me, the more interesting question is: How do we prioritize those transitions, and to what extent should the applicability of those transitions be? So, that's a 'Tell me what the future looks like' question from a practicality perspective, and there are so many other dimensions related to prioritization of funding and what's happening in the world today. Obviously, things are accelerating, and the information age has gotten so fast that everything changes from day to day, right? So I think we'll make great strides. Do I think everything will be transitioned over? No. But I do think it's a really curious question to understand how those prioritizations will happen, and that's going to come from the higher levels of government to help us understand prioritization and risk."
Carolyn Ford: "Okay. So zero trust and cloud are supposed to work together, but you said that CDS architectures are fundamentally incompatible with how cloud actually operates—and if I'm misquoting you, please correct me. What does that mean for government leaders trying to implement both?"
John Spicer: "We have to keep in mind that CDS and cloud are two different categories of capability. But back to the thing you quoted me about, I think more accurately: CDS architectural requirements are not compatible with the use of cloud compute required for the security functions of a CDS system."
Carolyn Ford: "Yeah, and I might have conflated because I threw zero trust in there too. Maybe zero trust doesn't belong in that quote."
John Spicer: "Well, we can hearken back to zero trust because it points to the same fundamental question, which is: If I want to connect two networks that otherwise should not or would not be connected—let's say I want to take a super sensitive network and connect it to the open internet—there's a high level of risk involved with that, and the systems that mediate those connections, we have to have a super high level of trust in. This gets back into understanding how robust the mechanism is that's adjudicating those decisions, right? So when you look at a lot of the requirements in RTB and the way we've done things before to make sure that we have high levels of trust in those systems, cloud architectures are generally not really akin to those requirements. So, for instance, if I want to have a filter that's going to filter some data before it moves between domains, I'm really filtering for two concerns: one is I want to make sure I'm not leaking data that I shouldn't leak, and the other thing is I want to make sure that I'm not ingesting malware or something. And the goal here is to protect the high-side system, right? I want to make sure I have a lot of trust in those filter processes that are filtering the data. And so the quote that you're referring to is this idea that we don't yet have enough trust, or we can't articulate enough trust, in, say, cloud compute such that it would satisfy what has traditionally been required for cross-domain implementation."
Carolyn Ford: "So you can't put a cross-domain in between the network we're trying to move data to or from—like put the cross-domain—this is a very simple world, okay."
John Spicer: "Great question. So you can say, 'This cloud is a network, and this cloud is a network, and I'm going to put a cross-domain system in between.' You absolutely can do that. But where I'm really going is that that doesn't necessarily mean that the cross-domain system will uphold a lot of the processing attributes of the cloud that we want out of the cloud, such as geographic distribution, scalability, and redundancy. So if you think about this—and this is a question we get a lot—'Can I just put my CDS in the cloud?' That becomes a very interesting question. Because let's go to a whiteboard: I have this cloud and I have this cloud, and I have a boundary between the two of them because they are networks. Putting it in the cloud isn't separating the cloud from something else. And so you get people that sometimes have this idea that if I just put my CDS in the cloud, then I get what I'm really after, which is unlimited compute, unlimited scalability—I can scale up, I can scale down, I don't necessarily have to worry about where it is, and I don't have to worry about the hardware. That's because the government has really pushed us toward this IaaS/PaaS model, which makes a lot of sense. And so when missions are writing their applications for Azure, AWS, or Google's implementation, they're not necessarily thinking about the infrastructure platform they're sitting on, because it's been taken care of for them. So this idea of saying, 'Hey, I want a CDS to be infinitely scalable and really easy to use as a service' makes sense from their perspective, because that's how they're thinking. But I can't necessarily just take the security functions today that are inside a CDS and offload them onto the cloud—like move all my filtration into the cloud—because I can't necessarily meet all of the assertion requirements and stringency that have traditionally been levied against CDSs. A lot of this is really centered around Department of War policies more so than I see, but it's still a valid question everywhere."
Carolyn Ford: "We're going to take a quick pause to thank the sponsor who makes these conversations possible.This episode is sponsored by Owl Cyber Defense, a pure-play cybersecurity company delivering Made in the USA data diode and cross-domain solutions trusted to protect some of the most sensitive government and commercial networks worldwide. Owl enables secure, near-instant collaboration across network boundaries, helping military, federal, and critical infrastructure organizations make faster, safer decisions. To learn more, visit owlcyberdefense.com."
Carolyn Ford: "Does the CDS architecture being fundamentally incompatible with the cloud make sense? No. My little brain still can't understand why we just can't do it. Like, why can't I have the cloud here and then my computer—I need this information, so I just put a cross-domain system in between my computer and the cloud, and that makes sure that I can't pass anything, say I'm on the high side, I shouldn't pass, and it keeps the malware out? Is it just because the cross-domain system can't handle the scale, or is that just not how it works? I think it's because I'm not an engineer."
John Spicer: "That's a really great question, and maybe that's a better way to word the question. Technically, yes, because we do that today. That's how we get data from one cloud to another. That's what an AWS diode provides. We know of systems where a physical CDS is sitting between clouds. My comment is that with clouds, you're really going for things like elasticity and services. Here's an example: I'm the Air Force, and I want to write an application where I can share data related to the maintenance history of an engine on an aircraft. And I simply want my application, where I'm keeping up with this stuff, to forward its information to my manager who lives on a TS/SCI network in the Pentagon, right? That person is not thinking at all about which physical box at which physical location with which filter policy I am going to have to mediate, because he's on the cloud. It's all just network services. And so when you talk about the ability to stand services up, sit services down, and get elasticity—because that's how we think—CDSs don't do that natively. It's a box at a location in a rack. If I need to scale, I have to buy more of them. If I want to move a new piece of data, I have to go through a whole process to get approval, and I may have to write filters and get the CDS re-evaluated. So all the architectural work that clouds have done of decomposing systems into services and microservices to facilitate faster processing, faster service standup, and elasticity—CDSs have done none of that. So as the cloud gets faster and faster with more capability and things are being stood up quicker, the CDSs will appear to be getting slower and slower in their ability to respond. And they don't possess intrinsically the ability to scale and respond the way the cloud does. And so the normal response is, 'Well, how about I start offloading some of that stuff into the cloud itself?' And then we start running into roadblocks because we don't yet have a high enough level of confidence with the cloud implementations to do that.Like one of the assertions or guarantees a CDS can make is: 'If data went in this side and exited the other side, I can guarantee with a very high level of confidence related to anything else that that data went through all the processing that has to happen in order for it to get to the other side.' Nothing was bypassed, I had redundancy, everything was always invoked, etc. That's all the Raise stuff in RTB. So now if I go to a cloud environment where I have multi-tenancy, thousands of users processing thousands of different things, and I now want to start doing trusted compute to make a cross-domain decision, how do I guarantee that the cloud did that properly? Because it's a sea of computers."
Carolyn Ford: "So really the problem is the scale."
John Spicer: "Yes, and it's the mindset shift of how people think now and how we want to do compute. In CDS, we are still in the world of 'This is the box.' The whole purpose of the cloud is to get away from the idea of 'This is the box.'"
Carolyn Ford: "So what are agencies doing? Because I know they want to move to the cloud, and I hear hybrid cloud, so how are they solving this problem?"
John Spicer: "Earlier I said that they were different categories of problems, because I can move mission to the cloud and not even address the cross-domain system, because I can still buy, rack, and stack CDSs and put them between the clouds. That is in fact what we're doing today."
Carolyn Ford: "That sounds really expensive and hard."
John Spicer: "It is, and it's very manpower-intensive and very complex. The more the cloud grows, the more the CDS integration problem grows because they have different compute models, effectively. This is the data-centric view versus the network-centric view, right? And so what we've seen and what we've said is, at the highest levels of government, a whole lot of money has been spent and some very large, impactful decisions have been made about the transition to the cloud. ZT supports that, like the stuff we were talking about with NSM and the other things you're pointing out here—they all point to that. But what they haven't done is a corollary investment into solving, 'How do we do efficient cross-domain solutions between these clouds?' They've kind of left it up to the missions who run into this problem."
Carolyn Ford: "Are the vendors solving it?"
John Spicer: "Vendors—like CDS vendors—are very limited in solving it because they are beholden to all of the certifications, approvals, RTB, and all the stuff they have to get approved in order to put their product on the street, make sales, satisfy their business models, and help missions. The problem is really at a higher level governance problem, because there's like this hole that the government has not yet addressed. I've talked to a lot of contacts within the government space and CDS experts, and we all generally agree on this: at some point, in order for this to get better, we have to change the mindset about how we do CDS, how we think of them architecturally, and actually try to go after some of these harder problems of, 'Well, what can I trust, how can I trust it, and why can I know that I can trust it?' And that gets back to the risk model and other things."
Carolyn Ford: "Well, I was just going to say, let's go right to when you and I talked a few months ago. You talked to me about risk versus threat. So let's talk about the distinction that you make between mitigating every threat that you can imagine and then actually managing risk to the mission. Walk us through why that statement matters."
John Spicer: "Sure. At the end of all of this in the cross-domain space, if I want to connect two networks of different classifications, that is fundamentally a risk decision, right? At some point, I'm going to make the decision on how much risk I'm willing to accept in order to get this mission satisfied. And part of that—we would always argue—should be a threat analysis: 'What are the threats that I am exposing myself to through this architecture, through this data, through these endpoints?' And then you would prioritize those threats and understand which ones must I really mitigate in order to be successful and not accept too much risk, and which threats are low enough probability or low enough impact that I need not worry about them right now because my mission imperative is too strong. Right? And I understand probability/impact—we could have that debate on qualitative versus quantitative risk management, all that stuff—but that's generally the example that people understand. So it becomes very easy to look at something or dream up a threat or identify a threat and think, 'The safest I can ever be is if I mitigate all the threats I can imagine.' The difficulty with this view is it really kind of short-circuits the risk decision, because the risk decision is balancing mission imperative, limited resources, and threat. But if I'm just going after every threat I can imagine, I've lost the balancing function of the other parts, which are resources and meeting mission. Because you could spend all the money in the world and all the time in the world going after every single threat you can imagine."
Carolyn Ford: "Well, and essentially you're creating more threats by trying to go after these unrealistic threats."
John Spicer: "I love the fact that you used 'unrealistic,' because even unrealistic can be considered in the eye of the beholder. And so this gets us back to: fundamentally, this is a risk decision. It's a lot easier to imagine a bunch of threats and try to mitigate them than it is to make an acknowledged risk decision that says, 'I'm accepting this risk.'And the other thing—I think we tend to see this in the cross-domain space—a lot of times, the people who understand the threats best are not the people who are empowered to make the risk decision itself. And so their advice or their tendency as technical experts is to really dig in on threat mitigation, because that is in their sphere of control. And it also provides them an avenue to potentially protect decision-makers from something they don't fully understand. Is that helpful?"
Carolyn Ford: "Yes. Have you seen organizations shift from a threat-based approach to a risk management posture? Have you seen an organization do that successfully?"
John Spicer: "Yes and no. We're talking about degrees. What I can say very confidently is that organizations who start looking at the bigger picture—or missions or specific architecture owners who start looking at the bigger picture—better understand the decisions they've made, why they have made them, and how that potentially impacts them. With that said, I believe one of the things that we still fight greatly is a compliance-based view versus a more risk-based view. What I mean by that is we have an awful lot of process, policy, and guidance centered around RMF, categorization, and control implementation. And over the years, we've seen a number of times where the idea of complying with a control set under an RMF approval process implies security, without necessarily really understanding what the threats involved are. And I've seen that become problematic, where people are accepting risks that they really don't understand because they simply think, 'I've done all the controls that were required.' In a normal non-cross-domain arena, I get it. But when you start saying, 'Hey, I'm going to take my TS network and expose it to potentially other adversarial activities because I'm connecting to something or any network of sensitivity,' the methods of attack can get a lot more complex and a lot more insidious very quickly. And so we see a lot of struggle there where even threats aren't taken seriously enough."
Carolyn Ford: "So we've talked a lot about RTB. It's a great segue, right? It's kind of the governing body to identify all these threats. It's also 500 pages long because of what we just talked about. So, who has the authority to change it, and what does it take? Or does it need to be changed, or do we just need agencies to be able to shift to this risk management mindset using RTB as the guidelines, without losing the forest for the trees, if you will?"
John Spicer: "In your question, is there kind of a predicate assumption that this thing is really big and it's putting a lot of pressure on people to comply and build cross-domain solutions that are expensive, and it's getting harder to maintain compliance, maintain systems, etc.? Is that—"
Carolyn Ford: "I mean, that's my understanding. It's my understanding that it can take years to get a product on the baseline and a million plus dollars. And then on the flip side, on the mission side, like we've already talked about, the implementation and understanding the architecture is also difficult, and it seems to be getting harder. This is what I hear."
John Spicer: "Yeah, that makes sense. There are some things to keep in mind: we have to keep in mind what RTB is and what RTB is not. If you go back to the beginning of RTB, RTB really touches on what we were just talking about, which is trying to fight this concept that 'I am compliant with my controls, therefore I am secure.' You can build a system that meets all of the controls, but if it was built like Swiss cheese, it's useless."
Carolyn Ford: "Back doors wide open."
John Spicer: "Or when the password change prompt comes up, I simply hit Escape and it goes away for six more months. There are all sorts of—"
Carolyn Ford: "Wait, I can do that?"
John Spicer: "I hope not. But that was really the genesis behind RTB when it got started: providing technical guidance to proper architectures, constructs, and the way to manage internal communications to make sure that your CDSs were built more secure. It is fundamentally not a risk model. It is not about making a risk decision. It is about, 'What is the quality of the system that was built?'"
Carolyn Ford: "Mhm. So is it up to the organization then to identify their own risk model?"
John Spicer: "Yeah. Before we even get there, we can acknowledge RTB. One of the things that has happened—I think the consternation around this topic is that the technical guidance in RTB has become so complete and so voluminous that it actually infringes on what people think are the responsibilities of the Authorizing Officials."
Carolyn Ford: "Meaning?"
John Spicer: "Here's an example: if you build a CDS to the RTB standard and you hit everything right, you are building a system that is likely qualified to sit in one of the most high-risk scenarios that you can consider, right?But if I have a very low-risk deployment, and all the CDSs available to me on the baseline are built for exceptionally high risk, I'm potentially swallowing a cost and efficiency bill that I might, as an AO, otherwise not need to absorb."
Carolyn Ford: "Because I'm paying for all the extra added security built into this system that you don't need."
John Spicer: "That you don't need. And so this could also be construed as technical experts and SMEs trying to protect decision-makers from threats they don't understand, but yet at the same time impinging on their ability to make informed decisions, right? And this is why I say RTB is not a risk model, but it definitely plays in this space because it does somewhat enforce a risk posture on the people who use these devices. Does that make sense?"
Carolyn Ford: "It does."
John Spicer: "The reality is, the more secure we build these things, to your point, the more expensive they get and the longer it takes."
Carolyn Ford: "Mhm."
John Spicer: "And this also kind of gets back to the cloud conversation where the OODA loops—to claim an oft-used term—the OODA loops are getting shorter and shorter and shorter, right? But the lifecycles of cross-domain deployment and cross-domain usage are not. So to your point, it creates this really interesting tension between all the stuff that is mandated by RTB and the timelines associated with satisfying it and how well or efficient we even are at developing our product or getting it tested, etc. There's an interesting tension between that and shortening OODA loops with shorter lifecycles for mission and a need to move faster."
Carolyn Ford: "Which opens up a whole new can of threats and risk. If this is so far out of reach because compliance has gotten so intense and the process has gotten so long, now we're sitting here with these shortened OODA loops. What do we use? We just MacGyver it on our own."
John Spicer: "Wow, you just made me feel old."
Carolyn Ford: "I love that you know the reference."
John Spicer: "Hey, that was like—I was going to be in front of the TV for this."
Carolyn Ford: "Oh yeah."
John Spicer: "Though I never did adopt a mullet that I would publicly admit."
Carolyn Ford: "You know what? They're coming back. It's not too late, John."
John Spicer: "It might be too late for me. I think there's a space there where we have to tread lightly, because there are so many variables in play and so many things that we can do. Do I think we need to do something to make this process faster? Absolutely. Do I think we need to do things architecturally and change the views of how we do CDSs? Are there things we can learn from the cloud environment? Absolutely. So I definitely think we are a long way from being perfect. But at the same time, the NCDSMO would say—and it's hard for me to throw stones at them on this—that we are still actively supporting short OODA loops and cloud integrations and all that. But I believe we are doing that at a cost, because when we go in and talk to a mission, I like to ask them, 'What is your hard requirement versus your soft requirements?' What I mean by that is, what are your 'no crap' requirements you have to meet, right? And then what are the things that are maybe a little less fungible? One of the ones that people like to harp on is latency: Really, what is your honest-to-God throughput latency? I know everybody wants everything in under a millisecond, but that's not life. And from a systems architecture perspective, well, maybe the CDSs that are available aren't doing the data type or the data exchange service that you want natively, so maybe we can engineer around that. But I do think long term, the continued inefficiencies associated with how we do these integrations will continue to mount. The cloud thing is a great example: as the cloud providers scale and scale and scale, and they're creating racks and racks and racks of more CDSs and buildings of CDSs that connect them, the inefficiencies will start becoming very problematic."
Carolyn Ford: "All right. So for a government leader listening right now who's trying to do cloud migration and cross-domain at the same time, what's one thing that they should do first? They only get one. I mean, it can be a list; your 'one thing' could be a list."
John Spicer: "I think the thing that they could do first is they need to step back from an acquisition viewpoint.They need to understand: 'What am I trying to accomplish such that my mission is successful?' That has to be the North Star. So much in cross-domain stuff is reactionary. We have so much going on right now, so many mission imperatives, and the tempo of things is exploding, right? And a lot of our mission planners are really focusing on what is close to them, right? And the deployment lifecycle, the engineering lifecycle, and all the stuff associated with getting a CDS deployed is a long lifecycle. So we see a lot of times where people leave that for too late, because, 'Oh, now I have to get this data across the boundary.' Well, that was a conversation you should have started a year ago or a year and a half ago. So the first thing that I would recommend to people is don't just look at this from an acquisition perspective, but figure out from a mission success perspective how you actually wrap these concepts into your roadmap and your mission lifecycle, and start planning for it that way. Because at the end of the day, it's not, unfortunately, as simple as, 'I'm going to go buy a firewall or I'm going to go buy a CDS, I'll talk to four vendors, pick the one I like the most, get the money approval, and pop the PO.' 'Now I have it, and now I have to do all the integration work.' It's unfortunately just, because of the world that we live in, more difficult than that."
Carolyn Ford: "Right. I love it. You are ending where we started. This is exactly how we started the show."
John Spicer: "I'd like to tell you that was planned, but maybe it wasn't."
Carolyn Ford: "It was perfect. So now we're going to go—this whole conversation has been delightful, and this is still one of my favorite parts because this is our Tech Talk questions. These are really fun. Rapid fire. So, from the gut, are you ready?"
John Spicer: "Yes."
Carolyn Ford: "All right. Zero trust: the most important concept in security right now, or the most overused buzzword?"
John Spicer: "Yes."
Carolyn Ford: "Okay, fair enough. If the CDS world were a movie, what's its genre?"
John Spicer: "I'm going to treat those as the same question, because the CDS world is really a specialized subset of national cybersecurity, right? What genre? Yeah, crime."
Carolyn Ford: "Tell me more."
John Spicer: "It's a story of adversaries doing everything and anything they can to steal, grift, and injure. But the heroes are trying to prevent it and apprehend them, but at the same time, they're simultaneously held accountable to the very policies, laws, and ways of life that establish us as a target."
Carolyn Ford: "Okay. I feel like you have a specific movie in mind."
John Spicer: "No, okay, so maybe too much about me: I'm a big fan of The First 48 television show on A&E. It's a crime show where every hour they follow some detectives that are trying to solve homicide in 48 hours. One of the things that always fascinates me is they are chasing down criminals that have not a care in the world about propriety, laws, social norms, or anything like that. But in their work to stop and apprehend these perps—or whatever the socially accepted word nowadays is—they are still beholden to the very laws that establish ourselves as a society. So while the bad guys can do anything they want at any time, we have to self-restrain ourselves based upon how we set our society up in our work to stop and uphold the law and get them off the streets. That's exactly what cybersecurity is with us. If you look at how it plays out, we've got RMF in the DoD CDS world, we have 8540, we have 1253 and the overlays—we have all of this policy written around how we do cybersecurity in this nation. But the adversary doesn't give a crap about any of that, right? And for us to ignore our policy and to just become the 'Wild West' would actually betray what we uphold ourselves as a nation. So, to me, there are very strong similarities."
Carolyn Ford: "So we don't get to go all Punisher and Daredevil, which is so frustrating to me. I love the vigilantes. Let's go. Let's be Batman."
John Spicer: "But if we were to do that, we would just be becoming them."
Carolyn Ford: "That's right. Okay. Network-centric or data-centric: which one wins 10 years from now? I think I already know the answer to this, but what do you think I'm going to say?"
John Spicer: "I think you're going to say data."
Carolyn Ford: "Or are you just going to say 'Yes'?"
John Spicer: "No, I think none of the above."
Carolyn Ford: "Really? What is it?"
John Spicer: "Well, maybe it won't be satisfying, but ideally they come to respect each other and collaborate."
Carolyn Ford: "Oh, look at you."
John Spicer: "Here's why: because at the end of the day, we're always going to have network-centric security models to work with, because we will always have networks that need protecting as an entity. Even if you look at a ZT environment, an MPE environment, or an MLS environment—we really didn't go down the MLS conversation because it becomes a philosophical one very fast—even when you get to the stations, you're still going to have network boundaries to protect. So I don't think we ever get rid of the network-centric model. But ideally, we start doing it in a way that truly supports a data-centric sharing abstraction."
Carolyn Ford: "Okay. It does make sense. It's a good answer. All right. CDS has been referred to as the black art of national defense. What's the one misconception you keep having to kill?"
John Spicer: "The technology itself isn't a black art; it's the siloed expertise and the overlooked need to do things like threat modeling and understand your threats. It's, 'How do I put all the pieces together?' Quite frankly, this is probably the major differentiator between Intelligent and most everybody else that's out there: our experience is we've built CDSs that have been certified, we've done information sharing architectures that integrate CDSs, and we've done threat modeling. So our perspective is that the real black art is understanding how everything across all these lifecycles fits together and successfully walking them so you don't make a misstep today that kills you at month 12 or 24 in the process. And the reality is 12 to 24 months on a lot of these things, because the risk decisions can be very serious in some situations, right?"
Carolyn Ford: "So the risks, the people—I mean, that's the secret sauce. That's the black art."
John Spicer: "Yeah. It's understanding—I hate the 'cat herding' analogy, but—"
Carolyn Ford: "But it works."
John Spicer: "—how to get everybody and all the pieces moving together. How do you get to the point, when you sit down and talk with your AO, that you are in a place to already articulate very well what you're trying to do, where you perceive the risks to be, and what their decision space will really look like, and engage them as a stakeholder? As well as being able to explain to the CDS vendor, 'No, really, this is what I need you to be able to do. Can you do this?' As well as being able to understand, 'Well, this is the data that I want to send, and if anybody really looks at this, this is where the adversary could use it against me.' And it's having all of these things lined up to try to make us as efficient getting through this process as possible."
Carolyn Ford: "Right. Where can our listeners connect with you and find Intelligent's published research?"
John Spicer: "You can always go to our website at www.intelligent.com. Off that website, we have contact information, and we have a way to get some of the papers that we've written. We're also out and about: in this cross-domain space, we go to CDTF, usually at DODS, and we were at West a few months ago. So we're pretty easy to get ahold of."
Carolyn Ford: "All right. Well, and you and I are LinkedIn buddies, so people can always connect."
John Spicer: "Oh yeah. You can always hit me up on LinkedIn. I'm not going to lie—my 'kung fu' with LinkedIn isn't always great because sometimes I just don't get there often enough. But yeah, you can always hit me up on LinkedIn, or you can hit the company up on LinkedIn. We're on all the social media presences."
Carolyn Ford: "All right. We'll drop all these in the show notes for our listeners. Thank you so much for joining me today. This has really been delightful."
John Spicer: "Yeah, you're welcome. This has been fun."
Carolyn Ford: "Thanks for tuning in. If you found this episode valuable, be sure to share it, leave a review, and smash that like button to help us reach more people who could benefit from the conversation. I'm Carolyn Ford. Tech Transforms is produced by Show and Tell and sponsored by Owl Cyber Defense. Until next time, stay curious and keep imagining the future."