Webinar: Classified Mobility Solutions: Streamlining Implementation and Operations

Webinar - Classified Mobility Solutions: Streamlining Implementation and Operations

Two experts delve into how defense and civilian organizations can improve mobility and remote work solutions for classified workers. Successful deployment of mobile solutions for classified communications depends on advanced technologies such as public key infrastructure or PKI-enabled dual virtual private Network or VPN client applications. These Technologies incorporate extensive configuration and processes that conform to the National Security Agency's Commercial Solutions for Classified or CSfC guidelines. Implementing these technologies and processes typically result in time-consuming manual efforts leading to cyber security vulnerabilities and downtime according to our subject matter experts and one of those is John Glover from Curtiss-Wright.

Transcript

Kimberly Underwood
Hello everybody, thank you for joining our SIGNAL Media webinar series. I'm Kimberly Underwood, Director of Digital News Media at AFCEA SIGNAL Magazine. I'd like to welcome you to our webinar entitled Classified Mobile Mobility Solutions: Streamlining Implementation and Operations, which is sponsored by Curtiss-Wright and Integrity Global Security. We have two experts today who are going to delve into how defense and civilian organizations can improve mobility and remote work solutions for classified workers. Successful deployment of mobile solutions for classified communications depends on advanced technologies such as public key infrastructure or PKI-enabled dual virtual private Network or VPN client applications. These Technologies incorporate extensive configuration and processes that conform to the National Security Agency's Commercial Solutions for Classified or CSfC guidelines. Implementing these technologies and processes typically result in time-consuming manual efforts leading to cyber security vulnerabilities and downtime according to our subject matter experts and one of those is John Glover from Curtiss-Wright, and John, over to you for introductions.

John Glover
Hey, thanks Kimberly. Good morning or good afternoon for most of you probably but for me on the west coast it's morning. My name is John Glover. I'm a Principal Software Engineer at Curtiss-Wright. I think the software team in the PacStar business unit and in my time with Curtiss-Wright I've been focused entirely on network management software. Under that sort of vast general area my focus has been more directed toward virtual private networks, encryption and solutions for managing end user devices along with the structure to support them. It's a really interesting problem for me, it's a really complex problem and fun to work on. Addressing the unique challenges in this space requires a pretty deep understanding of the problem domain and a lot of thoughtful design around that. I've been really fortunate to be surrounded by a great team with a huge range of expertise in network and data security. Curtiss-Wright has a deep expertise in implementation of a wide range of deployed CSfC Solutions and we've been building software and solutions for CSfC  since the program's early days. Most of those solutions are in a tactical space but we're in the enterprise space as well and we've been working with Gary and his team for a number of years now on bringing end user device management into the picture. Gary, do you want to introduce yourself?

Gary Markham
Thanks John. Good to see you again. My name is Gary Markham. I'm the Vice President CTO of Integrity Global Security. I have been in the government communications space, mostly in the classified but also enterprise infrastructure for almost 30 years. IGS is a subsidiary of Green Hill Software which has been in the embedded systems space for over 40 years providing high assurance, high reliability in the human life critical space. Our job at Integrity Global Security is to bring those expertise together which seems kind of odd, right? High assurance, high reliability is not generally what's happening in the IT space and so that's our focus is bringing these types of solutions together where we can take the technology that's been used for 40 years building Type 1 encryptors and airplanes and all kinds of stuff of that nature and bring it into the IT world where we can raise the bar and provide high Assurance platforms and solutions. That's where John and I have come together on the CSfC portal and we've been working on as he said for years bringing these CSfC solutions to market as COTS capabilities. Kimberly?

Kimberly Underwood
Yeah, thanks Gary and thanks John to you both for presenting today and thank all of you for joining us. I do want to make sure you know that this webinar is approved for continuing education credits in case you need to get another one of those by the end of the year. Specifically you can receive one Cert Nexus CEC for Cyber Security First Responders or one GIAC CPE or one CompTIA CEU for A plus, Network Plus, Security Plus or Cloud Plus credits. You do need to stay on for the full hour for the credit, of course. I'd also like to encourage you all to submit questions as we go along. To do that you'll use the ask a question box on the webinar console and when John and Gary have finished presenting we'll have Q&As for as long as time permits during this hour-long session. And then I'd also like to point you to the resources tab - there's a nice data sheet on Curtiss-Wright's IQ-Core End User Device Manager and IGS's SwIS so definitely check that out under the resources tab. And with that John I'll turn it back over to you.

John Glover
Thanks Kimberly. So today we're going to talk about an NSA program called Commercial Solutions for Classified or CSfC. So I'm going to briefly discuss what it is, what makes it work and I'll call special attention to some of the important details that will come up again later in the discussion. I won't delve too deeply into the administrative details because they're boring and there's plenty of information out there on the NSA's CSfC website. Then we'll point out a few example use cases where CSfC solutions are making an impact for government and defense department agencies already and next we'll explain the specifics of two solutions or capability packages defined as part of CSfC. Because of our limited time I'm going to focus on capability packages that enable mobile access to classified data and services using data and transit solutions. I'll provide a high-level overview of the design so you can get a feel for how it works and the complexity involved and then after the high-level overview that should give you enough background for us to discuss some of the key challenges associated with orchestrating the design and maintenance of these solutions. There's a lot of expertise out there for you to take advantage of if you think CSfC is right for your use case. Next slide please. So Commercial Solutions for Classified is an NSA program. It's entirely focused on enabling classified data and communication solutions using commercial technology. By using these commercial off-the-shelf solutions, defense and government agencies can leverage private sector innovation. There's so much existing expertise out there and it allows the government to keep pace with rapidly emerging technologies. Using industry standard technology allows agencies to use experience grown in the private sector, meaning more experiences and resources to draw on for security. CSfC is based on the idea of using commercial off-the-shelf technology. Using this technology comes with some inherent risk. It's being developed outside of the government control so its provenance is less certain. CSfC addresses this uncertainty by curating a list of approved components. all components must be NIAP-approved and pass additional rigorous CSfC validations. Layering encryption technology is really a critical piece for CSfC. We're still on that previous slide Gary.

Gary Markham
Sorry.

John Glover
That's all right. Off-the-shelf technology is more accessible and open than proprietary, government proprietary Type 1 encryption. CSfC mitigates this risk by layering multiple disparate encryption technologies. These solutions apply two discrete layers from diverse sources into an improved solution. This design assures that your data and services remain secure. Product diversity also ensures that vulnerabilities with one vendor or product don't compromise the entire solution. This is a source of strength for keeping your data secure but it's also a major source of complexity in these Solutions and we'll talk more about this when we get into challenges. CSfC makes use of open and non-proprietary standards. This is going to ensure the widest interoperability and these standards also smooth the way for non-government agencies to bring their expertise and help tackle complicated problems. As I mentioned earlier CSfC defines a list of approved components. All the individual components in a solution must be sourced from this list and that rigor adds an extra level of assurance. The program maintains a list of approved trusted integrators who can help implement solutions. Trusted integrators aren't required but they're strongly encouraged. An experienced and proven trusted integrator can streamline your solution implementation significantly. They'll understand the technologies, they'll understand how those technologies can work together and they'll understand the pitfalls where those might not work so well together. It's also important to note that the government has mandated CSfC as the preferred choice of  Type 1 encryption for appropriate use cases and you can find specifics about that in CNSS Policy Number Seven. All right, next slide please. So let's take a quick look at the capability packages and annexes that are relevant to the conversation today. First we have MACP. The Mobile Access Capability Package outlines a very long set of requirements for implementing a classified data and transit solution. The solution can include secure voice and data capability allowing end users to access classified data and services remotely. Specific use cases for remote access can vary quite a bit and the extensive requirements make accommodation and account for this. Next, the WLAN Capability Package. This is very similar to the MACP - it outlines a data in transit solution for secure wireless connections to an existing infrastructure that provides classified data or services. So a number of annexes also exist to support these and other capability packages. Two of the annexes that are relevant to our conversation are Continuous Monitoring Annex and the Key Management Annex. The Continuous Monitoring Annex outlines all the requirements for monitoring a solution which includes both the infrastructure and the end user device components. These guidelines provide assurances that your team can monitor threats. This annex is all about your security, event and information management or SEAM. Requirements to allowed events are only part of the equation - you've also got to be able to apply a stringent rule set to the logs and alert users as appropriate. As with everything else CSfC, multiple separate enclaves make this a little more tricky. So the Key Management Annex describes requirements for managing keys. Pretty simple - it outlines physical security, data security and key generation and strength requirements. So there's an additional package I won't be talking about but it's worth mentioning - the Data-at-rest Capability Package. It may be relevant depending on your use case and so it's out there if you want to go look for it. Next slide, thank you. So this diagram shows a system design for the Mobile Access Capability Package with the logical network blocks that allow an end user device to connect through a possibly untrusted network to classified network services and data This is a data-in-transit solution and it could be paired as I said with the data-at-rest solution if necessary. This solution is often implemented using PKI-enabled VPN encryption components. Public key infrastructure offers a well-known and widely available pattern for key generation and storage and use so it's really a natural mechanism here. The red data is unencrypted classified data. The red network will contain only red data and it must be protected at the data's level of classification. This network ends at the internal interfaces of the inner encryption component where data is encrypted for the first time. The red network will include a set of services including an administration workstation, a SEAM component, a public key infrastructure such as Issuing Certificate Authority and the CRL or OCSP responder. Moving outward from the red network, data which has been encrypted once moves through the gray network. The gray network components must be physically protected at the same classification level as the red network The data has already been singly encrypted - it doesn't have the added assurance of a second layer of encryption. This network begins at the inner encryption component and terminates at the outer VPN component. The gray network is simply a transport network to move data from one encryption component to the next. It consists of the outer VPN Gateway, gray firewall and gray management services. These services are really similar to the red network's management services because it really just needs to accomplish the same tasks, just as a second layer of assurance. Any network outside the outer encryption component is considered untrusted. As a result, any data in this part of the solution is wrapped in two layers of encryption, once by the inner encryption component and a second time by the outer VPN component. With those two layers of encryption the wrapped data is considered unclassified. Alright, next slide. There we go. Because we're covering the solutions with end user devices I wanted to also show the Campus WLAN Capability Package. This is really similar to the MACP that I already showed. The primary difference is that it's using Wi-Fi as its outer encryption component rather than a VPN. This type of solution is intended to provide wireless access for some set of infrastructure. I'll talk a little bit about a use case for this later. I mentioned PKI before and it's used inside the infrastructure for authentication and encryption but it's important to note that the end user devices require keys too - they require lots of keys. The more end users in a system the more keys you need and keys are a bit of a crossover topic and we'll spend a whole lot of time - we spend a whole lot of time thinking about how to manage them securely. So this diagram is showing two different kinds of solution. First on the left is using a completely untrusted transport network. In this configuration the solution requires a re-transmission device. It will sit between the EUD and the untrusted network and connect to the EDV Wi-Fi or ethernet protecting it from potentially dangerous network activity. Solution on the right shows a slightly simpler use case when data is transiting a trusted government network. The data must still be encrypted twice and all of the inner workings are the same. The difference here is that your protections from the network itself don't need quite as much rigor so the retransmission device is not required. When data reaches the end user device the encryption process needs to happen in reverse so data is going to be decrypted one time by the device's corresponding outer VPN client and then decrypt it a second time by the inner encryption component and at that point the service or data will be exposed to the user for apps or email or whatever use case you're using. Services such as a virtual desktop interface can be used so that no data is stored on the EUD or the device can be a thick client and have additional CSfC data-at-rest protections. So as I mentioned before there's a whole additional capability package for that with its own complexity. Just know that all of the technology inside your infrastructure has a mirrored component on the end user device and all of that technology has to be provisioned and maintained and all that technology has to be managed and updated with new key material when the old Keys expire. And unlike your infrastructure that technology is all in the hands of an end user somewhere outside of your secure facility. There are many more instances of this equipment than what exists inside the infrastructure and it may all look the same but each one's unique. Each has its own set of key material. Each device has its own end user who needs to access your system and that end user is really the whole point of this, right? Getting data and services to that end user. Just to give you a sense of the range of data that end user device needs to be filled with, when I first got involved with the end user device part of this solution it was supposed to be a quick and easy task. One of my stakeholders came to me and said hey, you know we have a customer, he's using IQ-Core, they want to manage the they're managing their Network infrastructure with IQ-Core and they want to be able to use our management of the certificate authority to automatically sign certificates. We were already auto-signing from the application so it was pretty easy to add an API they could interact with but when we delivered that the stakeholder expanded his ask. He said they need three certificates and they'd like us to orchestrate that process for them. And so we did that and again it wasn't really enough. So they sent me off to talk with the source and that's when I met Gary and his team. We spent a lot of time looking at diagrams and documents and coming up with solutions and looking now at what we've come up with in response to that initial simple request of auto-signing one certificate, today per end user advice we're orchestrating three with an optional fourth certificate signings. Each of these certificates have to be bundled with the trust anchor. Some of the software consuming certificates want the trust anchor sorted leaf to root. Another software wants it sorted root to leaf and some want the root certificate in the bundle and some can’t handle it when the roots in the bundle. So we're also, in addition to that, we're also providing more than 60 pieces of configuration data and that's before we move into the advanced options. The kinds of data we're filling the EUD with include configuration for connecting to the network infrastructure NTP server addresses, Wi-Fi security configuration, anything related to user identity or anything that the device needs to be filled with so that it can connect and authenticate through the transport network outer VPN component and inner encryption component. Next slide please. So far I've been filling your heads with how complex these solutions are and there really is a significant value proposition with CSfC, otherwise why would we spend so much time solving these complicated problems. There are trade-offs, of course, right but consider the differences between how you work with Type 1 encryption and how you could work with commercially available technology. Type 1 encryption is controlled - that requires detailed security policies and limits where it can go. It's expensive. It's specific to government use and so you have a smaller pool of experienced users to draw from. The burden of training users is higher. Elements of the private sector have all the same needs for security that government agencies do but there are a lot more customers in the private sector and a lot more technologies are being developed for these customers. Putting the rigor and assurances of an NSA design solution around these technologies allows government agencies to leverage that Innovation and expertise. So compared to the private sector, the government agencies are small. Because the private sector scale is greater you benefit from all the economies of that scale, more development or lessons, hopefully by someone else, not you, who will share them with you and all of that adds up to reduced cost. When you're using commercially available products you don't have the same concerns around physical security. You don't have the same requirements for handling classified equipment on the end user portion of the solution. This creates more opportunities for novel approaches that you couldn't take with CCI. So a member of my sales team was recently telling a story and I don't know if it's true or not but it illustrates a point and it's kind of funny. So there was a general working with a particular agency who needed access to data remotely and he put in a request and it was approved and when they showed up to his house ready to build out a SCIF, his wife turned them away. She didn't want a SCIF in the house. Now whether or not it's true that agency is now standing up a CSfC solution built with technology from Curtiss-Wright and Integrity and it doesn't require a SCIF, so everybody's happy. Another key point is that because these solutions don't rely on CCI they can be shared with foreign allies and finally while key management is still complex with these solutions unless you have a great way to manage it, it's still less complex than with Type 1 encryption. Next slide please. So I've been talking about the boring details for a while and I'm going to let Gary add some color by highlighting and giving some background for a couple of actual existing use cases. Gary?

Gary Markham
Thanks John. So let's talk about some of those use cases, right? You've talked about all the stuff that goes into what you need to do to do a CSfC solution. What does it mean? What does it enable for the customers? Well, just a perfect example - Defense Information Systems Agency. They had an initial pilot, they called it WINDAR, WINDAR-S to get access to SIPRNET from a tablet infrastructure. The original concept for this was executive support, flag officers, folks that need access when they're mobile in critical quote-unquote bad day scenarios you can make your assumptions of what those are, but the concept of it is when somebody needs direct access and they're not carrying around a 42-pound Pelican case with a whole bunch of connectivity or they don't have a SCIF in their house. So this was the original intent behind it and then something happened. Covid happened. What happened when Covid happened? They sent everybody home. They didn't have access to classified from their house. The average person who was working there but still needed to get their job done couldn't get the job done and all of a sudden this exploded and it went from about 150 users to thousands overnight, literally overnight, and so now they're out there looking for the next generation of WINDAR. It's really hard to scale a pilot into thousands of systems. The next one. FBI. FBI had a use case where they had field agents who are all around the world doing what they do. They are investigating crimes, they are investigating all kinds of different activities, they are collecting evidence, they are communicating, they're doing all kinds of different things but to be able to do that on a classified level, what they had to do was go back to a field office somewhere they had to go back somewhere to a physical SCIF that had access to the FBI's classified infrastructure to be able to support adding that data in. Sometimes if you're in the middle of the US, you could be 100-200 miles away from a field office. They're not ubiquitous. They're not everywhere. So these guys are out there on paper and pen trying to take notes, collect evidence, do interviews and they're taking that data back and wasting a ton of time. They wanted the ability to be able to access classified infrastructure on the move, whether that's from their vehicle, whether it's from a hotel room, there's obviously rules around it but the ability to access classified through a non-Type 1 infrastructure was necessary. It just wasn't possible all the time to have a two-person Integrity or it wasn't possible to store the devices in a safe overnight, so that was needed on an enterprise level. John, you were in the military - talk through some of the Army tactical stuff. Yeah, so this solution is really exciting to me because as you said I was in the military. A long time ago I was a young active duty Marine. Okay a really long time ago and I had a barracks roommate who managed network infrastructure and he was using Banyan VINES and token rank networks. He was always telling me about something that was broken and always trying to fix it. Thinking about that now it seems pretty archaic, right? The cables, tokens all kinds of physical transport. We've come a long way since then in terms of technology. Advancement has meant that we've needed to update how we think about devices and connectivity. Technology and data are so pervasive that when it's not available it feels like we're missing something vital. So the Army's PEO 3CT program is adopting CSfC Wireless Solutions. This is using modern technology to allow soldiers to have data and communication channels when they need it. These resources are critical. This use case uses the Campus WLAN Capability Package to make network services available as early as and for as long as possible. The setup's fast. It makes the network one of the first services available instead of one of the last services. There's no cables to run. There's no requirement to transport and run the ethernet cables that may later have to be abandoned anyway and they just turn it on and services are up and when the unit needs to move they just turn it off and stow it in some fraction of the time that that gear used to take to stow, without the loss of the cables equipment. So we talked about all the wonderful things, we talked about the infrastructure, now let's talk about some of the challenges. Complexity. John, you mentioned over 60 different data elements to provision the EUD. There's over 40 discrete technologies in the back end infrastructure which in many cases has to be mirrored on the EUD to be able to connect. You've got components, because these are commercial off-the-shelf, they weren't really engineered to work together, these aren't a COTs solution where some engineer came in and built it from scratch to work this way - these are third-party technologies that are sitting out there, we picked them up, we put them together and you started layering the technologies to support this communication activity. Well, CSfC Solutions, great concept but now somebody's actually got to put these things together and do things in a way that they were never even thought of putting it together before. This is great Innovation but it takes a lot of work to put together a solution that is reliable and secure and maintainable throughout thousands and thousands of systems in the enterprise. The other interesting thing about this, you mentioned the gray enclave, right? This gray enclave is sort of this unique world, everybody understands the classified enclaves that exist today, there's usually a subset of those enclaves that have policies, that have procedures, that have understanding, right? Is the gray classified or isn't it classified? Well, it's not classified but it's treated as classified. What exactly does that mean? What are the policies around that? What it what does that mean from a labeling perspective? How do I label devices in there? All of these things add to the complexity of CSfC. And then, as anybody knows in today's world, you've got the procurement supply chain issues, okay. This is now a whole different animal than it was five years ago, three years ago, when you're trying to buy 40 plus different technologies that you have to integrate together and they've got to be on the list right, everybody talks about it being on the list, which means is it on the CSfC list? Well how do you get on the CSfC list? You've got to be NIAP-certified, right, so now you have the added complexity of making sure all of your components are not only NIAP-certified but they're current in their NIAP certification, they are current in the CSfC list and they're approved for use within your organization. So now you have this bureaucracy of components that have to be put together. This is where the trusted integrator comes in, right, this is really important to work with someone that's done this before to make sure that you can handle these complexities. So policy. This is the fun one, right? This isn't a technical problem, this is a policy problem. This is, hey we've solved all the technical problems, and then you walk in and you tell the policy guys or you tell somebody in your organization, hey I now want to allow classified access from home, right? Ever met this guy? I have many, many times. He's looking at you like you're absolutely crazy, right, he's the guy who's saying there's no policy for that. What do you mean we're going to allow access from home to SIPRNET, to various classified infrastructure - that's absurd - we've never done that before. Right? Well the reality is it has been done before, It's been done in the tactical world for years. From a classified infrastructure the tactical implementations have been out there for a long time where people needed access to complete the mission. We're in the same situation now but it's at the enterprise level. The things that you do in the tactical world to support this don't always work in the enterprise world. CCI is one of the main ways to do that, right, there's many tacklings, there's talons, there's ways to do that which is great if I'm putting two guys on an airplane and sending them around the world, I can do that. But if I'm going to issue those things to thousands of people to be able to support the mission across the board, to support while they're working from home during Covid, that's just not going to work, it's not affordable, there's no way to maintain the policy of handling all that, keeping the training up to date, certifying all your people, that is a huge thing. So you got a lot of organizations out there who want to do this, they just don't know how. They don't know how to get through this policy process and for a lot of folks it's just too hard. Right? And so we're holding ourselves back in those situations because how - we already got this approved through security. Are you going to go back to security? I don't want to do it. It's like the old commercial - give it to Mikey. Mikey will do it, right? I mean that's the problem. We've got to have this capability to get past the policy and I don't mean go around it, I mean change it and some of these things are pervasive from the organizations all the way top down and it's funny you mentioned the policy where, the policy where CSfC is the preferred solution yet most people don't know how to get there. So that's a big deal. And then we have the end user device. I  bring this one up because of the things that we together have worked on, in the experience that we've gone through, in most situations people think that the biggest issue is that back end infrastructure - I've got all these 40 technologies, I got to put them together. That thing that I put in somebody's hands - that's just a laptop right, that's just a tablet, it's just a phone. I'll figure that one out later. The EUDs are not an afterthought. You have to take all of the same technologies, integrate them together, put it in a system, hand it to an end user who has to be, it has to be easy to use. If they can't use it, they won't use it. If they can't use it without a very minimal amount of training it is going to sit there unused. You also have to be able to manage the life cycle. You got to be able to provision it, you've got to update it. You mentioned things like patching and key management. These keys expire at a maximum every 14 months and that's about to go down to 12 months. So now, every 12 months what are you going to do? Somebody has to bring their machine back in? What happens if it breaks - how do you handle that? What happens if somebody loses it? Those policies exist for CCI - they don't necessarily exist for CSfC. Then you have the multi-domain challenges. What happens when I want to access SIPR and NIPR? How do I handle the gray enclave, certificate management? Those things, right, in theory they're easy but they're easy because, honestly John, we've made them easy, right? If you're doing it manually you've now got to go out and do certificate revocation manually. Well, every device has to be in sync. You mentioned that we have three to four certificates for a particular device. If you renew one without renewing the other or if you have things like CRLs that expire, the system just doesn't work so you've got to understand the whole picture and it then has to be all the way out to the end point. You have to do a fully architected solution which is really important because if one of your components isn't architected as part of the overall solution you will fail. We've seen it over and over and does that mean you'll never get anything working? No, you'll get it working. You just won't be able to scale to the enterprise. So let's talk about how to be successful in this, right? We talk through the good, we talk through the bad, now let's talk about the path forward. First and foremost - preparation. You've got to get your stakeholders involved early and who are your stakeholders? First of all your AO - your accrediting authority and the CSfC office. They got to be contacted early, you got to be talking to them often, you have to go through the process. They're backed up. Last I heard it was about three months to start the process and get it through the CSfC office, right, and a lot of that is depending on urgency. Every government organization out there right now is understaffed when it comes to these types of activities so you got to work with them, they got to understand your mission, they have to understand the priority and sometimes you got to get a little nudge and that's where your AO comes in. The AO is the decision maker for your organization from a security, IT security implementation. They need to know what you're doing. Many of them have never even heard of CSfC. You've got to educate them. You've got to understand your stakeholders and make sure that this is a priority for the organization and most of them are going to say this. Between recruiting, between Covid or disaster recovery, disaster management all of these things, organizations understand the need for remote access to classified now at the enterprise level. So not impossible, but you got to go through that process, you've got to be well prepared. The other piece of it is work with your vendors, know your vendors and your trusted integrators really, really well, right? Some vendors, some products on the CSfC list got there once and they're trying to figure out what that means to them in the big scheme of things, right? The architectures for putting CSfC in place require a lot of commitment from vendors. They have to maintain their NIAP certification. Every time they patch they have to understand what the impact of that is to the overall CSfC architecture and we're talking 40 different components. If they're not committed to supporting CSfC there's going to be challenges there. So make sure you understand your vendors, make sure you work with them, make sure you know them, make sure you've got a good relationship with them because you're going to have to call in favors periodically to make this work. TIs - the Trusted Integrators. I will just make the statement - not all TIs are created equal - right? You need to do your research - there's over I think 70 TIs on the list - there's about 80 approved packages right now and several of those CIs or those TIs have more than one package that they've submitted. So you do the numbers. Some of them know what they're doing. Some of them have never submitted a package. Work with your TIs, understand them, get their reputation and also ask for references. Right? Know the implementations that have been done because some have done a really great job. Other implementations have not gone very well. The other piece of it is know your use cases, right? Everybody says, well I want classified, I want, I want remote access from anywhere. Is that really true? Do you need classified remote access from Starbucks? I don't think so, right? So you got to understand that and that goes back into your policies, that helps you understand your use cases, it helps you understand your security posture, it helps you work with your policy groups to develop the processes, helps you work with your IT folks to understand the requirements, all of those things - knowing your use cases is really important. Going through your pilots and understanding how people are going to use it. The process of preparing for your enterprise implementation is critical. There are successful steps to get there. You're not alone. That's the other piece of this. Communicate. Leverage the CSfC ecosystem. The CSfC office has done a really good job of bringing an entire ecosystem together - they've got vendors, they've got trusted integrators, there's an annual conference, they have information out there. That is not a typo by the way. AO and CSfC office should be contacted early and often. Yes, it is in both places. I cannot emphasize this enough. Work with your AOs, work with the CSfC office. They will help you. It's really important to go through and communicate. Leverage existing implementations. Don't reinvent the wheel. Okay, it's happened so often where somebody goes, you know what, they don't really understand our mission, they don't really understand what we're trying to do, so we're not even going to bother reaching out to understand what they're doing. Well, there's so much overlap in this space so leverage the existing implementations. Leverage the lessons learned. Use partners with the CSfC focus.   And I cannot emphasize enough having executive support. In most organizations it's really, really hard if you don't have the executive team pushing this from the top because inertia is one of your worst enemies. Well, we've been doing it this way for 20 years - why can't we just keep doing that? The answer is the world's changing. You can't keep doing that. Covid happened. We can't keep doing that. Right? The threats are changing. We can't keep doing what we're doing. We've got to move to the next generation. So let's talk about the lessons learned. A little levity here, don't get bit, right?   First and foremost you're not as unique as you think you are. We've done a lot of these implementations, we've done, talked to a lot of customers, we talked through the use cases. Your mission may be different, okay, but the IT infrastructure is not. Commercial Solutions are out there doing this in the world today. People are getting that remote access to secured infrastructure all over the place, whether it's the financial industry, whether it's the medical industry, they are already doing these things. There's a lot of regulation around that. Well CSfC is just another implementation of commercial technology. So leverage the world that you see out there. Leverage the use cases and talk to people because you're not as unique as you think you are. The other thing is, seen this over and over, know your IT teams cannot just set up a couple of VPNs in a couple of weeks and make it all work, compliant, secure solutions. You can't take a bunch of stuff that's been sitting down in the warehouse and just put it together and make it work. Can you make it work functionally? Probably. Can you scale it? Can you meet the compliance requirements that are required by NSA and your AO? Probably not. These technologies also, if you just take what you have and just try and put it together, they don't play well together. There's a lot of lessons learned around this and that's one of the reasons that NSA has put the technologies together on the list the way they have because they've gotten commitment from these organizations to support CSfC. As with any project outside factors will cause you delays, whether it's supply chain, whether it's policy, whether it's the fact that there's a tornado that went through somewhere and all of a sudden your entire supply of laptops you thought you were getting aren't happening. Real use case by the way - that was one of the customers, there was a, if anybody remembers the tornado in Nashville, wiped out the entire supply of systems that were going to the customer and they had to start from scratch. So and I use this - a go-kart will never perform like a Lamborghini - don't think you can build a system out of spare parts that you've got laying around and it will meet your enterprise scalable needs. The temptation is there - there's so much extra stuff in the IT world that's sitting in warehouse, redundant systems. Hey, we bought these last year, they never got deployed. These were our spares, can we just put that all together? The answer is sure, you can. Can you make it work? Probably. With the staffing you have, can you scale it? absolutely not. We've seen it over and over and over. If you want to run a pilot to understand the functionality in use cases, that's a great idea. If you think that's going to scale to the thousands, tens of thousands, sometimes hundreds of thousands of users, it's got to be an architected solution. You can paint it red but your go-kart will never corner like a Lamborghini. So that's our story here. Thanks for listening. Kimberly?

Kimberly Underwood
Right, thanks Gary. That's great advice and and John, thanks for the information. So for you audience members, don't be shy, use that ask a question box on your webinar console and we have these great experts here to answer whatever you need regarding CSfC. It looks like we've one in the hopper here, Gary, who creates the policies for CSfC?

Gary Markham
Well the answer is lots of different folks, right? So policies for CSfC in particular are based on the organization's policies but they have to conform what the NSA's policies around CSfC, so what happens is the use case starts off which will drive the policies, policies can happen all the way up at the DoD level or organization level and they can go all the way down to the individual element. It depends on the implementer and it depends on who drives the policy for that organization but there's a coordination among all of those and you can't violate that policy at a higher level so it has to be coordinated across the board.

Kimberly Underwood
Right, sure and then here's a question about the MACP Mobile Access Capability. Can you describe some of the biggest considerations for continuous monitoring with the MACP solutions. Thank you.

Gary Markham
Is that for me or for John?

Kimberly Underwood
That actually is for either one of you.

John Glover
I can start off by saying that, so I'm a software engineer, right, so I come at this with a focus of understanding the process and how to make software that helps you achieve the process you're trying to achieve and so I don't know all of the specifics around the network side of this and what specific messages you're needing to see with your continuous monitoring but I can tell you that we do have experts who are looking at those policies and coming up with rules and ability to apply those rules to a solution. For me on the policy side though, it's important to note that in addition to your infrastructure which is inside your facility, you also need to be adding continuous monitoring of the end user devices and so that's something that's a little difficult to do unless you have a device that is built to support that kind of interaction. Maybe Gary, I don't know if you have any more to...

Gary Markham
No, I agree. I mean the answer is the data elements are fairly well defined and they're really not that different than the data elements you're doing in your regular network infrastructure. It's just a matter of doing that in a multi-enclave environment is one of the biggest challenges and how you bring that into a way to monitor all of the enclaves at the same time. Those are the biggest challenges. Defining the data elements really isn't the challenge.

Kimberly Underwood
Right, sure thank you and I think it was John you talked about kind of or maybe it was you Gary who talked about the value proposition of CSfC. One of them enables foreign allies to share, to access shared classified materials you know, without taking possession of the controlled crypto. One of the audience members wants to know have you successfully deployed solutions to Five Eyes or NATO Nations and then he says I'm curious if allies have adopted policies which support CSfC. Thank you.

Gary Markham
I'll take that, so John the answer is yes. There are several different initiatives. The initiatives we've been working with NATO on - they don't call it CSfC because then of course they'd be adopting NSA's terminology. They use the term MLV - Multi-Level VPN and so we've been working with several different NATO, Five Eyes and even other foreign entities to adopt the architecture, not necessarily the implementation, at NSA. The nice part about this is this really does allow for interoperability capability because they're using commercial off-the-shelf technology. It doesn't necessarily have to be ITAR and they put it together in a way that is available to all of them and the concept of it is similar to what the NSA has done with the enterprise gray where you can have a single-layer VPN where everybody can subscribe to that outer and then you have individual layers for the red. So basically, enterprise gray, multiple reds and now you can all participate in the same infrastructure which provides you access. I'm gonna go right into the next question which is around CDSs and CSfC because that fills right into the gap there where yes, they actually integrate very, very well together. There's a lot of CDSs out there, sorry, Cross-Domain Solutions, that will allow you to do multiple enclaves on a single platform and when when we refer to CDS there's two categories, right, there's access solutions and there's cross-domain transfer solutions. When we talk about the integration with these a lot of what we're talking about is cross-domain access solutions which are really exciting when you start combining these technologies. Now, there's some nervousness at NSA around combining cross-domain solutions which have a very specified category and release characteristics and who can use those and then you incorporate that with commercial off-the-shelf technology and you're integrating these things together. Those things are still emerging. What I will say is the availability of that technology is there right now. It's not a technology problem. This goes back to the policy conversation. This comes down to how do we use the technology in a way that can integrate together whether you're using a cross-domain access solution to be able to access multiple classifications and possibly multiple entities. I've been in centers where we have multiple foreign entities, coalition environments where you have, each one has their own computing infrastructure for their own network and then you have the coalition network and they're constantly going - I got this over here, how do I see this over here, how do I provide this information over here and right now it's all physically separate and it's a really hard place to work on and share information because you have these environments that are independent, where you're getting data from these different environments all together. So the answer is yes and it's a perfect matchup. We just need to figure out how to get the technology and policy to match up.

Kimberly Underwood
John, anything to add, you wanted to add there?

John Glover
I think Gary covered that pretty well.

Kimberly Underwood
All right then I'll turn to you for this one. Let's say I think we need one of these solutions. How do I get started?

John Glover
Sure, yeah. So I'm not at the NSA. I'm not a policy expert there but I'll just say that the first place to start is with the CSfC PMO right, and your local CIO or CISO right, because you need to make sure you don't have an existing solution that you're not aware of you can take advantage of and then you're going to want to probably reach out to your peers, you know, other people who've built solutions. You can find lists of registered solutions on SIPRNET and then thirdly all of the trusted integrators are listed on the website. Do some research. Again, talk to your peers, find out who they use. There's a whole bunch of information out there that can help you with this. All right, thank you.

Kimberly Underwood
I think Gary, maybe you can point to this one. If CSfC is so complicated how does it save money and effort.

Gary Markham
Yeah and we covered a lot of this but the real answer on this is you have such a large ecosystem to bring and leverage. One of the advantages of CSfC is there's thousands of people out there, millions of people using Cisco VPNs. There are millions of people using Aruba technology, right? There are millions of people using these commercial off-the- shelf that you can bring in with expertise and you don't have to, one, pay for the development of all of it yourself which is incredibly expensive, then you can leverage the existing training that everybody gets because it's commercial off-the-shelf technology so you can hire people that are already trained so your time to market is faster, how much you pay somebody, right, if you if you have a CCI certification - that generally comes with a bonus. You don't necessarily have to have that when you're dealing with commercial off-the-shelf technology. So there's a lot of cost savings that come just because there's so many other people using it.

Kimberly Underwood
And then what makes it so complicated to provision a client?

Gary Markham
Well John mentioned there's over 60 data components that we use to provision a client so most solutions out there still are doing these, collecting these data elements manually. And then they take the device and they plug it into one enclave - black, provision the systems from, you know, the black components and then they unplug it, physically move it somewhere else, provision the gray components, again manually getting all of the data components and collecting them into a package, building the VMs, setting up the VPNs. Most of our customers have been telling us it's been taking them anywhere from three to five hours to provision a single EUD so you take that into equation of how do you scale this? Well honestly, that's what we've been working on for the past couple years and we've now gotten the process down to about two and a half minutes to provision a system because with the combination of technology where you have a single pane of glass to manage your infrastructure and your endpoints, you can now use that to streamline the process. The whole point behind it is if you're manually doing these things you are never going to scale. We've heard it over and over that for most of these implementations they get to about the 1500 user point and they just start falling over on themselves. That's why you've got to have this concept of being able to manage everything in a cohesive manner and be able to support it long-term because if you have thousands or tens of thousands of systems out there, you can't be doing four to five hours provisioning a system.

John Glover
Yeah, if I could just add a little bit onto that and sort of reiterate what you said. I mentioned earlier I'm a software engineer, right, and my focus is around putting policies into software so that the user can't mess it up, right? When you're provisioning a system manually you're going to make mistakes. You do one, two, three fine - you can do them perfectly but you do four, five, six, ten, hundred you're going to start making mistakes and it's going to be a painful experience and so the more we can make these processes automatic by putting them in software and then applying policy at a software layer, the better off you're going to be and the more secure your system is going to be.

Kimberly Underwood
And then you talked about kind of end user devices. If a device does need an update or patching, how can an organization do that without bringing the device back to their facility. How does that work, I guess?

John Glover
Yeah so this is kind of tricky, right, it'll depend on what your end user device is, right? This is this is going to be EUD-specific sometimes.   I'll say that with Gary's solution we do over-the-air updates, right, so we do updates live while the system is functioning. You connect to the the red network, then you have access to the updates your EUD needs and so that's how we handle this so all I'll say is if you have a way of making your updates automatic happening over your red data connection that's really the best policy - the easiest policy. maybe Gary has I don't know Gary if you...

Gary Markham
- no I'll just say the concept of it is you want to be able to provide those updates whether it's patches, whether it's security updates, whether it's certificate updates, whatever that is - if you're not able to do an over-the-air update in a secure fashion which means from an NSA perspective you've got to do it over the red network, you're not going to be able to scale. If you've got to bring these things back in and reprovision them - not going to work.

Kimberly Underwood
Right, sure. We've run out of time. Thank you all for submitting questions and for any that went unanswered the companies will follow up with you all directly offline. Don't forget to check out that resources tab where you find the datasheets and there are both companies capabilities. Thank you for joining all of us. Thanks to John and Gary for presenting today and you can continue to link to the archived version of this webinar. Also see previous SIGNAL Magazine webinars on our website which is www.afcea.org/signal/webinar. This concludes our webinar today. Thanks for joining us and have a good day.