Webinar: Cross-Domain and Secure Remote Access Solutions at the Edge

Webinar: Cross-Domain and Secure Remote Access Solutions at the Edge

Rob Link, Principal Sales Engineer at Forcepoint LLC, and Dominic Perez, CTO at Curtiss-Wright, explore the challenges and best practices for deploying cross-domain solutions in accordance with the latest Raise the Bar requirements from the National Cross Domain Strategy Management Office (NCDSMO). This webinar discusses cross domain, network segmentation challenges, extending cross domain with Commercial Solutions for Classified (CSfC), extending cross domain with virtual desktop infrastructure (VDI), and cites some real world examples.

Transcript

George Seffers
Hello and welcome to our SIGNAL Media webinar series. I'm George Seffers with SIGNAL Magazine. This presentation is sponsored by Curtiss-Wright Defense Solutions and Forcepoint and today we will discuss the use of cross domain solutions for securing remote access to classified networks. Our guests are Dominic Perez, Chief Technology Officer at Curtiss-Wright and Chris McCloskey, Sales Engineer with Forcepoint. Please be aware that today's event has been approved for multiple continuing education units. Following the presentation, we will host a Q&A session so viewers are welcome to submit questions using the ask a question box on the webinar console. And with that it is time to begin. Please welcome Dominic to get us started.

Dominic Perez
Hi everybody. I'm Dominic Perez and this is a webinar on cross domain and secure remote access solutions at the edge. This is sponsored by Curtiss-Wright and Forcepoint and hosted by SIGNAL. This webinar may contain references to products and technology that may be controlled by the U.S International Traffic in Arms Regulations but we will not be discussing in this webinar any technical data as defined by ITAR. If you have specific questions about the exportability of this technology you can direct those to Curtiss-Wright or Forcepoint representatives. Questions concerning those items will be addressed offline. You may know me a little bit better from PacStar but PacStar has been part of the Curtiss-Wright family since 2020 and we are transitioning the branding. Going forward, we will be known as Curtiss-Wright PacStar Communications Solutions. We're still based in Portland, Oregon where we manufacture our hardware and the vast majority of our engineering staff is located there. Here's an overview of some of the items that we'll be covering today.

We'll start with an introduction to cross domain and some network segmentation challenges. I'll pass it over to Chris from Forcepoint to talk about solving those network segmentation challenges. We'll hop back over to me to talk about extending cross domain with Commercial Solutions for Classified and extending cross domain with virtual desktop infrastructure or VDI, and wrap up with some real world examples and hopefully some time for Q&A. Very basics so that we can set the stage for what we'll be talking about today. This is about the most basic network that you could imagine and there's no real segmentation at all on this network. It's just a flat network. Please don't design networks like this - it's not 1990 anymore, but we can start and break up a network into segments and those segments might be by type of device, by user role or however we do that we can start segmenting with VLANs or with physical segmentation and enforce that segmentation with a router or with a firewall. That's pretty good for enterprise but when we're dealing like in this diagram with multiple networks touching multiple domains and then the DoD, those domains might be things like NIPR, SIPR or JWICS.

We need to enforce that segmentation in a much more serious way through a cross domain solution. So why are cross domain solutions needed? Do you see a diagram here, looks like this person has a pretty nice setup with eight monitors but they also have seven CPUs to deal with, multiple keyboards and it's quite the burden. It might not be that bad in a NOC but if you ever want to take this out to the field or deal in a smaller location you have to deal with swap or size, weight and power, and cross domain solutions can help consolidate this dramatically - in many cases from seven or more systems down to a single system. For security, in addition to enforcing that segmentation that I talked about at the start, you can also use cross domain solutions to begin to correlate events that may be happening on separate networks in separate domains. In the event of a cyber attack it can be essential to be able to correlate those time-stamped events across networks without having to switch context constantly. In, you know, more day-to-day operations, cross domain solutions can help with automation. You can act on information that is seen on one network and take those actions on another network. All of this leads to better situational understanding, allowing you to have a common operating picture of the environment as it is going along. And a final item is cost. Cross domain solutions admittedly do have a reputation for being high cost but that's only when considered in isolation. If you consider all of the multiple workstations that can be getting gotten rid of - redundant networks that can be eliminated, reduced infrastructure in buildings, not to mention transportation costs and energy costs. If you look at the total cost of ownership it can actually be dramatically less expensive. So who brings us cross domain solutions?

In general, that's the NSA and the NDCSMO or the National Cross Domain Strategy and Management Office. If you are part of the Army or other pieces of the DoD there may also be specific cross domain support elements or offices that are specific to your branch. And the NSA brings us the cross domain program and the raise the bar standard that they refer to the requirements under. Under cross domain, to do one of these projects and programs there is an A&A process for assessment and authorization and there are a number of steps in that process and if you'll notice, you know, the first is preparation and you don't even get to assessment and authorization until you're very near the end and once live, one of these systems need to be monitored and maintained continuously. So it's really a continual process of approval. Chris is going to talk about this in quite a lot of detail but at a high level there are three main types of cross domain solutions.

The first being access, where a user is given the ability to view material on a different domain. The second would be a transfer solution where we're actually looking to transfer information from one domain and make the actual data available on that domain, and the third would be a hybrid which would be a combination of those two and Chris will go through several examples illustrating how those can be put together. Finally no discussion of security, especially in 2023, can be complete without talking about zero trust and to me a cross domain solution is really the epitome of zero trust. Zero trust is all about establishing trust ironically but doing it based on context, the context of the user, the context of the machine that they are accessing it from, and a cross domain solution often adds in the context of the actual data that is being secured. So we can look at what that data is and make decisions based on the content and whether or not that is going to be allowed. With that I'm going to pass it over to Chris.

Chris McCloskey
Great. Thanks so much Dominic. That was a great intro to some of the fundamental principles of a cross domain system and I think sets the stage nicely for the next section where we'll segue into talking about some of the cross domain solutions that Forcepoint provides. And for those who are unfamiliar with Forcepoint, Forcepoint is a commercial cyber security company and the leading provider of cross domain solutions deployed today within the Department of Defense and intelligence communities. Forcepoint CDS products have been in operation bridging the gap between separate security domains for over 20 years now and today Forcepoint has the leading number of CDS products complying with raise the bar guidelines enlisted on the NSA's CDS baseline list which is the list maintained by the NSA that any cross domain system will need to be on in order to be approved and authorized to operate and across the main capacity.

And as you can likely imagine, there is an extensive security evaluation and testing process which takes place in order for the NSA to authorize it across domain systems, so Forcepoint invests heavily to ensure that our products are meeting the expectations of NSA and raise the bar not only now but also in the future as requirements are continuously evolving and changing. So today we're going to talk about a number of our products including our CDS access product, The Trusted Thin Client or TTC for short, a subset of our CDS transfer products in the High Speed Guard and Trusted Gateway System. The Trusted Print and Trusted Mail systems which are add-ons or extensions of our Trusted Gateway System. The Data Diode and we'll talk about when a data diode may be required in tandem with a CDS as well as our Enterprise CDS management offering, the Forcepoint Control Center. Next slide please, Dominic. So Dominic introduced the concept of an access CDS which again is a means for a user to access multiple enclaves of varying security levels from a single endpoint.

And on the next slide we will, well I wanted to bring this image up on the left again which Dominic introduced us to and depicts what a workstation can and has looked like for a number of folks within the DoD that may have specific operations they're looking to carry out on NIPRNet, SIPRNet perhaps MPE environments as well as JWICS And while we can all look at that picture and see that a user sitting at this desk is probably out of space, maybe lacking room to sit their coffee, maybe sweating from all the heat coming off of the CPUs, what we don't see is the amount of network infrastructure and switching that it would take to scale this approach for hundreds if not thousands of users. And when you consider the power consumption and the cooling that it takes to keep all of this equipment operating, the costs can very quickly become overwhelming and cost prohibitive. So on the right side, we've depicted what we are essentially able to collapse this hardware footprint down to using the Trusted Thin Client where, instead of a user needing seven different thin or thick clients to access seven different networks, a user is able to access however many networks they need to, all from a single thin client device with a single network cable extended to that particular device and this can be done using a single monitor where they have multiple windows overlaying with the proper security label for that window and swapping back and forth but also on the top hand is a picture of one of our current employees' former desks actually where he was still able to use eight monitors and still have a full screen display for each individual network but a much more seamless experience using a single thin client.

So if we go to the next slide, we'll look at an architecture of a trusted thin client deployment and speak to some of the core components that really make this all possible. So starting in the middle of the screen we have what we refer to as the distribution console, which really acts as a connection broker between the thin client device and any back-end networks. And the distribution console physically connects to each air gapped network and again kind of acts as a traffic cop ensuring that users are only able to see networks that they're authorized and that their clearance level is appropriate to be able to see. Now to the left of the distribution console is what we refer to as the TTC Network. So that's going to be that single network that's able to be extended to users perhaps sitting at a workstation in a secure area on base and be able to pull those simultaneous sessions to their device. Now alternatively and at the bottom of that portion of the clients you also see a remote access implementation and that is where this same end user experience can be provided to end users from an unsecured location via Commercial Solutions for Classified which Dominic will speak in more detail to at a later point in the presentation.

But a very nice aspect of the Trusted Thin Client solution is the ability to perform all administrative functions from a single point active distribution console without the need to touch every single end user device. So say, for example, if you need to push out an OS update with a new version of the software, perhaps change the clearance level of a particular device if you have a device perhaps in a conference room that's only cleared to see certain networks - that can all be done administratively and remotely from the distribution console. And in fact the thin clients themselves are in a very secure lockdown operating system. There's no access to any command line terminals where they can elevate their privileges to make these sorts of changes so this is completely locked down. Even an administrator would not have that ability to perform that.

Now another fundamental part of the TTC solution is the fact that it leverages desktop redisplay technologies in order to function. So as opposed to having all of the data a user needs stored locally on that device, they would connect to virtual desktops residing in this case on networks A, B and C. And they would be simply redisplaying that desktop on the user's thin client device. So this connection could be over standard VDI protocols such as VMware or Citrix, it could be an RDP connection and now with our latest release even to an Azure cloud hosted virtual desktop. So using this approach, this eliminates any data-at-rest on the device - it is unclassified when it's powered off and eliminates the ability for a user to use some sort of external media to pull data off the device and then take it home with them, so very secure and a very friendly end-user experience from that standpoint. Next slide, please. Now the previous slide depicts rather a simplistic architecture where you may have just a few networks on base and a user, you know, uses a thin client to connect to VDI infrastructure residing on each of those networks.

However, the TTC solution is really designed to scale and support an entire enterprise. So today we have customers with TTC deployments upwards of 20,000 users spanning across multiple geographic locations both CONUS and OCONUS and this type of scale was achieved through a term we call distribution console spanning. And what this does is allow you to interconnect different distribution consoles that may reside at different geographic locations. And at those different geolocations you may also have certain networks that are accessible and some that are not. So by extending the Trusted Thin Client network to these different locations, what this allows you to do is say, a user at the bottom of the screen is at a location where only SIPR or Network A is accessible. Now through DC spanning or distribution console spanning, they can actually connect over that TTC Network and pull down a desktop, a desktop that sits on Networks B or C even though there's no local presence of that network at their location and to them it looks the same, it operates the same as the exact same user experience and they have no idea that there's no local presence there. So this is another area where when you look at the scale of an enterprise, there's significant cost saving opportunities when you think about eliminating the need to extend each and every network to each and every site for individual users to access it.

All right. Next slide please Dominic. So we've talked about some of the network infrastructure reductions that we can realize through an access CDS but, you know, an access CDS alone as Dominic mentioned previously does not solve for the problem for say when a user or a mission requires actually moving data between various classified domains. So next we'll talk about how Transfer CDS products can be used to support some of these requirements, of course in a way that's secure and compliant with the NDCSMO's requirements.

Next slide, please. So the first of our core Transfer CDS products and Forcepoint's longest running CDS product in operation is the High Speed Guard which has been deployed within the DoD and IC for over 22 years. The High Speed Guard is designed to move data across separate air gap domains and is specifically designed to support structured data formats and it can do so either in a unidirectional or bi-directional fashion. Now as the name states, it is in fact a high-speed guard so it's a high performance guard capable of reaching over nine gig a second on a 10 gig link throughput and doing so with single digit milliseconds of latency. And with any Transfer CDS guard, NSA's raise the bar guidelines require that any data passing through a transfer guard needs to be inspected by redundant or at least two separate filtering engines.

So in order to comply with this raise the bar principle, the High Speed Guard has two separate rule engines working simultaneously that will inspect every piece of data going through the guard bit by bit. So as part of an implementation we would leverage these two separate rule-writing engines, have custom rule sets crafted that validate the structure of any data going through the guard. And using this approach and this flexible rule-writing engine, that allows us to support new schemas, new data formats, we've never done before without the need for any software level changes so the magic of any implementation really lies in how those particular pool sets are crafted. The High Speed Guard also supports different transfer protocols and different ways of moving data, ranging from traditional file based transfers to streaming data types such as full motion video where you can perform video transcoding to actually change the format of that video, removing any steganography in the process.

This could include live sensor feeds or weather data that's streaming through the guard and also supports protocols such as HTTP or SNMP - Simple Network Management Protocol - to allow for network administrators to obtain different information about various network devices residing on each of these segregated domains. Another common example is say, when you may want to send up device logs or network logs to a high side SIM so you can monitor all of your network or device logs from a single location on the high side. And this is common as part of a CSfC implementation which has its own set of requirements for monitoring and reduces the burden of having to log into each of your CSfC networks to view those logs every couple of days. So if we can go to the next slide, I wanted to provide a quick glance at a small subset of the environments the high-speed guard is deployed in today. And that encompasses both traditional data center deployments but also supporting the warfighter tactically and at the edge and today the High Speed Guard is deployed both on Navy ships as part of ship self-defense systems as well as on airframes to support various reconnaissance missions so there's a wide variety of various use cases being supported today.

It's also an ideal system for, say, parsing large data sets such as satellite feeds, you know, pulling satellite data, passing it to a high side domain and perhaps allowing for command and control traffic flowing back down to change certain positional elements of any sort of device collecting data. And while we won't go into any specifics in this setting I will say the High Speed Guard supports a large number of standard messaging data formats deployed by the DoD and in the tactical arena and again this is all made possible by that rule-writing engine that I discussed earlier. And when it comes to supporting the war fighter and in tactical environments we have a specialized version of the High Speed Guard software designed to run on tactical hardware and by partnering with vendors such as Curtiss-Wright we're able to meet any size, weight and power constraints required to provide the war fighter the data they need wherever they need it in order to support the mission. Next slide please. All right. So the second of the core Transfer CDS products that Forcepoint offers is the Trusted Gateway System, or TGS for short.

This guard is also widely deployed across the DoD and IC communities today and as I mentioned the High Speed guard is generally designed to support structured data formats so on the other hand the Trusted Gateway System is generally designed to support more unstructured data formats. So what we're talking about here are files that may make it very difficult to write a rule set from scratch in order to determine if it might contain something malicious. So the TGS contains a number of both third-party commercially available filters purpose built to inspect very specific file types as well as a few in-house filters I'll speak to in a moment and the file types supported by these filters consists of things like office documents, image files, PDF documents, a number of other file types which all undergo deep content inspection to break apart the file, look for any sort of hidden scripts or malware embedded within them and this is done by, again, multiple redundant filters for every file that passes through the TGS. So again that concept of from raise the bar ensuring that every file is going through multiple sets of filtering to ensure that if a file or something malicious were to make it past an individual filter, there's always a second level of inspection performed.

Dominic Perez
Hey Chris, you know one of the things that I like about the Trusted Gateway System is the fact that if a PDF goes in you get a PDF out and it's not just like pictures of it, it doesn't flatten all the information, it just prevents that information from being transferred if it's not supposed to be transferred. And I think Forcepoint has a technology demonstration similar to that up on their website - is that right?

Chris McCloskey
Yeah, that's correct. So you're 100 per cent correct with any sort of data transfers going through the guard, it's not just a matter of converting any of those files to images to remove anything malicious. So we're able to take apart those files and rebuild them in their original formats to ensure that users can still interact with them as they normally would and we also are implementing the zero trust CDR technology into this as well, to do this really in kind of a state-of-the-art way so we will certainly provide a link to that here at the end of the webinar so folks can see how it works first hand. Great call out and yeah, as I mentioned so this really provides a way for users to transfer, you know, various data types that they're operating and interacting with on a daily basis and because some of these filters are, excuse me, some of these file types, are often user generated documents, the TGS allows for a couple of different ways for users to initiate a data transfer. Whether it be, you know, one option of just mapping to a user's file share that exists somewhere on the network and scooping that file up, passing it through the guard and putting it on another mapped directory on the destination side but also we can provide them with a web interface where they can go and log in using their existing credentials or CAC card, upload a file and then they would have the ability to select either one or multiple destination networks they'd like to push that file to.

And the web interface I mentioned also allows for what we call a reliable human review. So say for example if a user is trying to move data from the high side into a lower side domain for example, the system will require that someone with the proper authority log into the system to authorize that data transfer and those approvers can be dynamic in nature so you have - maybe you have members of a particular organization that have a designated approver for their individual unit so those approvers can be automatically assigned based on who initiated that transfer or perhaps where it's going. Next slide please Dominic. So on top of being able to, you know, filter common data formats using some of those commercially available filters, we also have ways to perform things like dirty word searches. So we're able to, you know, during any sort of data transfer, look at maybe a library of certain words that may have a certain level of classification that should not reach any other domain. So we're able to inspect that to ensure that there's no spillage say, again, whenever you're initiating a transfer from a high side to a low side.

And additionally, something Forcepoint is currently integrating into the TGS is a proprietary content disarm reconstruct technology - that's what you're able to go and see real time on the website once we provide that link which really provides a unique way of ensuring the Integrity of files different from traditional malware scans. So when a file passes through this filter, rather than again parsing that file and looking for malware, the zero trust CDR technology actually assumes that every file is compromised. So instead of the CDR filter looking at, or so instead, excuse me, the CDR filter looks at the good contents of each file such as the text, the images, and creates a new clean file every single time and removes any steganography that could have existed in the process. So we'll be sure to resend out that link here. Now in addition to some of these filters I spoke about, the Trusted Gateway also has add-on capabilities to support use cases such as enabling users to send emails across different security levels or to allow users to send print jobs, say from the low side domain up to a high side printer.

So the Trusted Mail system, to start, is as I mentioned additional kind of add-on capability. It's an additional service that would sit on either side of the Trusted Gateway system and is designed to work within your existing email infrastructure, so say if a user is accessing maybe his NIPR email from a mobile device somewhere, could actually send an email to, or a file, so you can send an email with an attachment to another user and have that email and that file reach a user's inbox on SIPRNet. Additionally, as a recipient of email or someone that may be managing five different email inboxes, you can have a consolidated view of your emails from all of your different domains on that high side network and not have to worry about missing emails just because, you know, you weren't checking the right inbox at the right time.

With the Trusted Print that's another area actually where there can be significant cost savings as you can start to collapse some of your printing infrastructure when you're working and operating across these separate domains. So for a user sitting on any sort of low side network, essentially they're able to go and when they submit a print job it actually goes to a Trusted Print adapter and sends that file through the Trusted Gateway system, performs the same level of filtering as would be done in any other case and assuming those filters inspect and validate that file, it sends it up to a high side printer. And this can work and be compatible with a printer that supports pin to print so when they go to actually receive or go to that printer, they have to put in a unique pin to actually release that print job ensuring that no one just walking by the printer is able to see that particular document. All right, next slide please Dominic. Alright. So we've talked about some of the use cases a transfer CDS can solve for and now we're going to talk about data diodes which are a different type of device from a traditional CDS. So using specialized hardware, essentially a data diode's job is to enforce one-way data transfers and according to raise the bar guidelines, a data diode is required when connecting a CDS to a quote high threat network.

And to abbreviate, the definition of a high threat network from the NSA - a high threat network is a network in which a known or suspected highly skilled cyber actor is operating. So the easiest example of a high threat network is commercial internet - that's no surprise there but also that high threat designation would actually extend to any network which has some level of connectivity perhaps via a firewall to another high threat network. So, many unclassified networks fall into this category, even some foreign partner secret networks could fall into this category as well, say if they have a back-end connection to the internet. So in terms of what Forcepoint offers here, in raise the bar terms it is a simple diode solution meaning there's no actual content filtering performed on the diode - it's a specific device meant to enforce that one-way transfer through optical separation. So how it functions - there are two servers.

First is a pitcher which contains a specialized network interface card only capable of sending a transmit signal. And second, we refer to it as the catcher. So the catcher also has a specialized NIC only capable of receiving that optical transmission and between the two servers is a single strand of fiber connecting those two devices so there is no physical way to actually move data from the catcher back down to the pitcher. It is a hardware enforced one-way transfer The diode is capable of handling different, you know, file transfer mechanisms from traditional file based transfers to some of the streaming use cases we spoke to before, as well as HTTP as well. And the data diode can interface with both the High Speed Guard and Trusted Gateway System in order to provide a complete raise the bar compliant CDS architecture when data transfers are required with high threat networks. So let's take a look at the next slide please Dominic.

And you may be wondering, well you know, what happens if I need to send data bi-directionally with an unclassified domain which is considered high threat? Isn't the diode going to break that? So the short answer is yes because you are enforcing and preventing any data from going back down with a diode sitting in front of a CDS. However the raise the bar has design patterns that would allow for this type of architecture and I will preface that this type of deployment can become a little challenging depending on maybe certain systems that may need to interact real time and there are different design patterns within raise the bar documentation which varies slightly from the one I have depicted here on the screen but in essence, this involves two separate diodes. So you can see on the left hand side we have one diode going up from that high threat Network A in this case for a low to high transfer. You also have a separate diode handling that high to low transfer and within raise the bar there's a concept referred to as the rule of three and what that says is essentially when we are deploying this type of bi-directional transfer architecture, that rather than just having to inspect that data twice there's actually a need to have a third level of filtering on any data that is also traveling back down high to low. So there can be some nuance here.

Just understand that it may require a second CDS technology and there are some considerations when designing this type of architecture. Alright, next slide please. Alright. And lastly we'll look at how the management of CDS technologies can be simplified using the latest CDS product Forcepoint has put through the evaluation process with the NDCSMO and our newest addition to the CDS baseline list. So if we go to the next slide I will, I'll preface this with just noting that raise the bar over the years has introduced a number of different requirements for how CDS systems should be capable of being remotely managed and monitored from an external system and management plane.

So Forcepoint has built what we call the Control Center which is designed to meet those remote management and monitoring requirements and is capable of supporting and managing up to 50 different High Speed Guard and Trusted Gateway Systems. And this can all be done from a single, you know, web-based graphical user interface and allows CDS sys admins to receive real-time blogging and device statuses from those systems so they can be alerted to anything unusual occurring within the system or anything problematic. And this also drastically simplifies the deployment of, say, a new CDS guard and it allows them to configure that guard with really a matter of a few clicks, say, if you wanted to deploy a new guard to add capacity to your existing deployment.

Or, say you have 20 different systems already deployed, you can push out a configuration update without having to touch each and every one of those systems. So as I mentioned today, the control center supports both the High Speed Guard and Trusted Gateway System and we do expect in the future we will move the management of the Trusted Thin Client product as well to fall under the purview of the control center as well. So with that I will turn it back to Dominic here to talk about the Commercial Solutions for Classified and the latest and greatest from Curtiss-Wright.

Dominic Perez
Thanks Chris. So we're going to talk a bit about extending cross domain with Commercial Solutions for Classified or CSfC. I imagine that most of you on this webinar are familiar but CSfC is a program with the NSA, separate from Cross domain, that is for the transfer, is for the establishment of the transfer of classified information across the network, not between domains. It is an alternative to the way that it's always been done with Type 1 encryption or HAIPEs, whatever you want to call them - devices like the KG-250. Now, and it's not brand new but it's still within the last 10 years, you can do this using two sets of commercial encryption such as a Cisco VPN and an Aruba VPN by tunneling one of them inside of the other. The exciting thing about CSfC is that it enables entirely new classes of mobility, especially for wireless. There's no practical way to do Type 1 encryption for a hundred different laptops. CSfC gives you the opportunity to do that and set up secure and secret networks much faster. It also is easier for working with our coalition partners and not having to deal with control cryptographic items or those HAIPE possession rules Curtiss-Wright has a number of CSfC solutions starting with PacStar's IQ-Core Crypto Manager and Continuous Monitoring Manager. Those are single pane of glass applications that are designed to streamline the deployment and management of CSfC, configure VPNs according to NSA guidelines, manage your certificates and basically make CSfC solutions a lot easier to manage. We have the PacStar small form factor modular hardware that has been certified with a number of CSfC partners and we can put together turnkey solutions or near turnkey solutions based on your needs that have been registered likely with others within your service branch and get those accredited much more quickly. Finally, PacStar has Enterprise CSfC solutions that take our CSfC technology and build it into fixed infrastructure and equipment like you would see in an enterprise 19-inch rack for serving thousands of users instead of the hundreds of users that we would be looking at on a tactical kit.

Additionally, outside of the PacStar group at Curtiss-Wright, there is a data storage group that has a number of CSfC data-at-rest components. I had to borrow this graphic from Forcepoint because they were able to get the little dot to move back and forth, that's beyond my PowerPoint skills but here you can see a Trusted Thin Client traversing a CSfC solution with the inner and outer VPN clients being wrapping and then unwrapping for access to the distribution console. And like Chris mentioned when he talked about the distribution console, you don't have to have access to every network on the far side of the distribution console. And that's what we can see here. We can see a distribution console with access to multiple networks whether those are directly connected to that particular distribution console or another within the network. I'm stepping back at looking at the CSfC infrastructure that makes this happen. You can see that we require a number of components in addition to just the two encryption tunnels but we can make this work over Wi-Fi or other wireless mediums or even wired but other wireless mediums such as LTE or 5G - it's really transport agnostic. Alright, some real world examples. Looking a little bit closer at Curtiss-Wright's PacStar IQ-Core software starting with the base version or Network Communications Manager (NCM) - that is your single pane of glass meant for managing and monitoring a network built of multiple vendors, whether that's your Ciscos, your Arubas, your Junipers, your Palo Altos, your SATCOM vendors, IQ-Core can give you an overview and let you manage that equipment very easily with limited training. We've extended that with IQ-Core ROAM that allows it to essentially manage instances of IQ-Core below itself, so you can set up a hierarchical network where the NOC can view and even drill down into the edge nodes but each edge node is able to independently operate.

And then finally IQ-Core Crypto Manager that I had mentioned before, we bring in the extensions that allow the configuration of VPN to CSfC requirements as well as certificate management in support of CSfC. Here's an example of one of our CSfC systems modeled after what we have been deploying with the Army for several years now and you can see that we have NIPR and SIPR access in a carry-on size case using nine of our PacStar 400-Series modules. And when we talk about cross domain with Forcepoint and their guard software that generally will run on an X86 server and throughout Curtiss-Wright we have a number of form factors that may be suitable for your platform or program. You know, on the left our 451 sever - that's an Intel Xeon with up to 16 cores and 128 Gigs of RAM and importantly for cross domain solutions, it's available with five independently controlled one gigabit Ethernet network adapters so you can connect up to five different networks and across the main solution or four plus an admin network that way. We also have the Parvus DuraCOR line. These are fully rugged IP67 servers that come with four cores, 32 gigs of RAM can also be compatible with Forcepoint software. They come with two gigabit NICs but they are expandable through rings like you can see in the bottom there, you've got a module on the top extended with a ring and that ring can add various interfaces like Ethernet. Finally on the far right for those of you that are tracking SOSA and CMOSS, that is a VPX 3U card that is an Intel Xeon processor that also can run Forcepoint guard software. And you're probably going to need some routers and switches to connect all of this up. PacStar partners with Cisco to provide the brain and IOS for all of our routing and switching products.

So we have our 447 based on the ESR6300, the 444 and 446 based on the ESS3300 and the 448 based on the 10 Gig 9300 switch. Similar products are available in the Parvus line with the 6300, 3300 and a combo module that puts the router and the switch in one enclosure we call the 63-33. And then a switch the DuraNET 20-10 if you just need to add some switching ports. On the VPX ecosystem, honestly can't even start to touch on the number of different variations of switches that we have but suitable for pretty much any use case you've got, we've got a switching solution in VPX for that. Jumping back to the PacStar 400-Series, the magic really comes together when you bring in the smart chassis and those smart chassis would hold four or five PacStar modules and click into our transportation options. The chassis provides AC or DC input for power and a backup battery that can run one to two hours depending on the workload that you've got going.

Also shown here is a VPX smart chassis that is compatible with the PacStar 400 Series ecosystem so in the place of anywhere where you might put a four slot PacStar 400-Series chassis you can now put a five slot PacStar VPX chassis. And you got to get it out to the field. For a simple system that might just be a Pelican case with a few modules and some batteries. It might be that Mini Transit case that I showed that is airline carry-on size. The inside of that is actually a 19 inch 4U rack. Then we have commercial racks available like you see there and also rugged vehicle mounts both in the 19-inch form factor and in the SAVE form factor as Illustrated on the far right. Finally we can tie it all together with PacStar and Forcepoint. The Tactical CDSS Software provides multi-level access with the Trusted Thin Client and simultaneous access for multiple local enclaves and more than 50 users on a single device. That can be deployed for unclass through top secrets and you can see over on the right a system with Network A show in both the Trusted Gateway system and the High Speed Guard and the Trusted Thin Clients. And I'm zipping through this a little bit because I want to leave at least a couple of minutes to take questions. So with that I will wrap it up and we can go back to video on for a few questions.

George Seffers
Okay, great. Thank you Dom and Chris for a great presentation. It is time for our Q&A, viewers are welcome to submit questions using the ask a question box on the webinar console and it looks like we have quite a few questions coming in already, So, Chris, I think the first one is for you. How can a CVS work within a DevSecOps environment?

Chris McCloskey
Yeah, that's a great question. So yeah, that's actually become a much more prevalent question that we've gotten over the last couple years. So you know, in DevSecOps, you know, a lot of times folks are developing code, they might be working with different virtual machines, containers, things that they need to produce but then also move up to a high side domain. So to support DevSecOps there's a specific implementation of the High Speed Guard which I didn't actually get a chance to speak to earlier but it's called CDUX - it stands for cross domain unstructured exchange of data. So this is a very specific implementation. It does have some additional requirements that need to be in place outside of the CDS itself but it is designed to provide a NSA approved means to transfer things such as code, software binaries and things that you'd often find in the DevSecOps environment.

Dominic Perez
I think we lost your audio George. Still muted, George.

George Seffers
Alright, there we go. The next one is for you as well, Chris. Can Trusted Thin Client support the use of graphically intensive applications? Yeah, that's another great question.

Chris McCloskey
So yeah, the answer is yes. Really, with things and applications that are very graphically intensive, it does become something that you certainly need to plan for and scope that ahead of time. And really the key to making sure that the end users using these type of applications have a positive experience is designing the VDI to support it. So nowadays, a common approach to that is putting traffic processing units actually within the VDI as part of that initial build and assuming that is scoped out properly and designed properly, the Thin Client can certainly support it. But we do always, you know, say the end users experience is as good as the VDI is scoped out. So definitely a good question and definitely something to consider as part of that buildup.

George Seffers
Okay and it looks like I accidentally skipped one. Can Trusted Thin Client support the use of graphically intensive applications?

Dominic Perez
You're getting them all today, Chris.

George Seffers
Yeah they're front loaded for Chris for some reason.

Chris McCloskey
Yep, that's the one we just covered.

Dominic Perez
Graphic app, yeah. Yeah.

George Seffers
Okay, I'm so sorry. Are there alternatives to building out on-premises VDI that will work with Trusted Thin Client?

Chris McCloskey
All right, lots of Forcepoint questions. I like it but yeah, so yeah. So there are alternatives as I mentioned. The Trusted Thin Client does support remote desktop protocols as well. Generally, we don't recommend that for hundreds of users, generally kind of tens of users just due to the nature of the technology and that VDI scales better. But yeah, there are other options as well aside from that, whether it be cloud hosted BDI or in, you know, some cases folks do not want to build out on-prem BDI because of some of the costs associated with the infrastructure and that's where we actually have customers that used some of the rack mounted PacStar hardware to decrease some of that, you know, hardware footprint to build out small scale VDI Solutions as well. So a couple of options to consider there.

George Seffers
Okay super and Dom we're gonna get you in there. Do I need to use CBS to use CSfC?

Dominic Perez
No, not at all. They're two separate programs from the NSA. But what we were trying to illustrate today is a way that you combine those two programs to kind of get the best of both worlds. Certainly we can do CSfC if you just need network connectivity to a secured network or we can do cross domain if you have two different domains at a remote location or we can do them both where we Implement CSfC and quite often we would use the Trusted Thin Client for an access over that CSfC solution and that can really ease the burden of the amount of equipment that would need to be taken to the field to access multiple networks, especially if you have more than one or two networks that you need to deal with.

George Seffers
Okay, super, and the next questioner is asking how can I learn more about raise the bar?

Dominic Perez
Yeah, raise the bar is a program that is administered by the NSA. They maintain a website if you just Google NDCSMO Or we'll try and put a link in the resources for that. There's limited information available on the public internet but there are links for uh NIPR and SIPR there if you have that access or just an email. The raise the bar standard I believe is available for US consumption and five eyes governments so just reach out to the NSA and they'd be more than happy to get you on your way with that.

George Seffers
Ok thank you, very good.

Dominic Perez
I hope you don't have any more questions for Chris. I think we lost him.

George Seffers
Yeah, I'm not sure what happened there but maybe he'll be back in a minute.

Dominic Perez
Gotcha.

George Seffers
For the Thin Client Solution endpoint, how is versioning and vulnerability management on the OS handled along with reporting and continuous monitoring i.e. IAVMs or uploads?

Dominic Perez
Yeah so that might be a little bit more for Chris but basically the Thin Client, the Thin Client endpoint, okay, so the Thin Client management - how are we patching the Thin Client, I guess is the root of the question. Obviously the virtual desktops patching would be managed at the enterprise infrastructure and but the Thin Client, how is the versioning and patching managed for that Chris?

Chris McCloskey
Yeah, sorry, I'm not sure what happened there but yeah. So for the Thin Client solution, so as I mentioned it does run a lockdown proprietary operating system based off of a particular Linux release, trying to make sure we don't get into too many weeds here, but all of that is managed from the distribution console. So the distribution console and Thin Client will remain on a consistent version. When there are patches made available such as in the event a vulnerability is identified, the software patches would come from Forcepoint, would be uploaded to the distribution console and from there the next time the user logs into the device or power recycles it, it would automatically download that. Yeah. In addition with reporting and continuous monitoring, so there's also a very granular level of logging collected from the Thin Client devices. All of those are passed up through the distribution console and can be offloaded to say a log server under your high side.

George Seffers
Okay, great. I think we have a few seconds for one more. For VPX and CDS, how have you implemented the domain separation in the back plane to meet the different security domains defined on RTBOWTDT4.

Dominic Perez
Yeah, thanks for whoever submitted that question and that is where I'm going to draw the line of what we discuss in a public forum. So we'll reach out to the person who asked that question and explain how that is done.

George Seffers
Okay, excellent. Gentlemen, thank you again for a great presentation and to Curtiss-Wright and Forcepoint for sponsoring today's event. And thank you to our viewers for submitting questions - we certainly appreciate your time. Please note that there are some resources from both Curtiss-Wright and Forcepoint available to you under the resources tab and to learn more about Curtiss-Wright Defense Solutions and Forcepoint, you can visit their websites. I’d also like to point out that you can continue to link to the archived version of this webinar and see previous SIGNAL webinars on AFCEA's SIGNAL Magazine website. That concludes our SIGNAL Media webinar for today. Again, we thank all of you for being with us. Have a great day everybody.