>>LIBBY LONG: Good afternoon, everyone. And thank you for joining us today. Please join me in welcoming our moderator, Holly Rollins.
>>HOLLY ROLLINS: Hi. This is Holly Rollins, I am the vice president over our aerospace cybersecurity business, and I'm pleased to welcome you to our Cyber Resiliency for Tomorrow's Space Missions session today. The session is being broadcast and we're pleased to have several of our subject matter experts here with us.
I would like to begin by first just telling you who our panelists are. This topic, I think, is very germane given the changes in the geopolitical situation in the United States and worldwide and just recognizing that with the space being contested that this is a very germane topic.
Today we have several subject matter experts in this area. We have Alexander Gates, who is the Chief Research Officer at Shift5. We have Dr. Carl Fischer, who is the Chief Technologist of Advanced Technology and Information Solutions at Ball Aerospace. We also have Mr. Tim Hampton, at Sierra Space. And finally, we have our colleague, Mr. Kevin Coggins, who is vice president of cybersecurity on space systems here at the firm here, Booz Allen Hamilton. Just by way of housekeeping, you do have viewing controls that are available to you. If you scroll your mouse over the video player you can resize the material or your video.
Participants, you will all be muted throughout the presentation. To ask questions, type in the question function to the icon menu, which is at the right of the portal. Questions will only be visible to the host. They will not be visible to other attendees. And we ask that you submit questions early and throughout the presentation, not just at the end.
So with that, I'm going to transition over to the speakers for self‑ introduction. I'm going to start with Alexander Gates.
>>ALEXANDER GATES: Thank you, Holly, and thanks to Booz Allen Hamilton for the invitation. It is always great to talk about these topics that are so important to our country.
I've been working in cybersecurity and national intelligence issues for several decades, first in the United States Air Force and the National Security Agency, and finally in the Department of Energy before retiring and joining Shift5. And you know, I spent most of that time chasing bad guys through cyberspace. That should be no surprise. And working with some really brilliant people to solve national security problems using both offense and sometimes a mix of offensive and defensive capabilities. But what was really interesting when I shipped over to the defensive side and became clear that many nations, especially nation state actors, just as skilled, just as driven and determined to satisfy their national security requirements for their countries, their leadership.
And, you know, at the end of the day it came down to this. An advantage. Who, which country could create the advantage in cyber for their country to take advantage of at some point in time at the time of their choosing.
And what I like to say about that, that's one of the reasons I joined Shift5, because so much investment is happening in IT, where will the advantage lie in the future, and where is it today. And a lot of that is in OT space. Spaces that are largely unmonitored when you look at planes, tanks, the grid, when you look at space systems. OT space largely unmonitored, that's where an advantage can be gained. And, you know, that's something that's worth discussing and I'm glad, again, to be here. Thanks, Holly.
>>HOLLY ROLLINS: Thank you so much, Alexander. Carl?
I think you might be on mute. So we will let you try that again.
>>DR. CARL FISCHER: Thank you. I apologize for that. Hi, good afternoon. And thanks for the opportunity to serve on the panel today. I'm Dr. Carl Fischer, with Ball Aerospace. I have been working space-related applications for 18 years now, and I have approached this domain from more of a mission capability, software development, and scientific application perspectives. I began my career at Lincoln Laboratory, capabilities for the NASA NOAA mission set. And this is where I first learned the importance of agile software development for efficiently developing software that can achieve an evolving customer need.
When I joined Ball I began supporting DOD and in that role I got much closer to mission operations that required us to be much more cognizant of the impact of cybersecurity and cyber resilience. More recently I have served as chief architect and help serve real direct mission operations where cybersecurity is even more important, and more critical to the survival of those systems through attack.
And so I have continued through this time, though, to push for modern resilient, Cloud native architectures that have been proven out in the commercial market space, and I encourage this adoption of the zero trust systems using Kubernetes Clusters to achieve a resilience in a modern approach instead of the more traditional multiple systems. So I'm looking forward to our discussion today, and thanks again for the opportunity, Holly. Thank you.
>>HOLLY ROLLINS: Terrific. Thank you so much, Carl. Tim?
>>TIM HAMPTON: Good morning, and thanks again for the invitation. Pleased to be here with you and the rest of the panelists. I started my journey in cyber back in '95, so it has been 27 years of doing cyber, long before we called it cyber. Like some of my colleagues that are on the panel here, I started my journey with the Air Force. Over the past probably 10 or 15 years I have had the privilege and opportunity to focus on quite a bit of what I call mission cyber, and I have had the chance to look at weapon systems, aircraft platforms, a number of space systems, as well as space agencies. I supported NASA for a while, and now here at Sierra Space I'm interested in how do we extend into our space systems. As folks might be aware, we are set to launch Dream Chaser, followed by Orbital Reef which will be the replacement for the International Space Station, so I can't think of a harder topic to tackle right now than how do you secure a living platform inside space from a cyber perspective, and we have to do it across a number of different use cases.
I think what we need right now from a just general cyber perspective is we have to change the mindset in how we are approaching mission cyber, and we have to stop doing cyber for cyber's sake. And that's where we are really trying to go, my team is not focused on cyber for cyber, we are here developing and deploying space planes and space platforms. We just happen to have that, and we are so excited to talk about the challenges that we are facing today. Over.
>>HOLLY ROLLINS: Terrific. Thanks, Tim. Kevin?
>>KEVIN COGGINS: Hi. My name is Kevin Coggins, vice president at Booz Allen Hamilton focused on ensuring resilience in our most capabilities, intelligence, critical infrastructure. I'm also a board member of the space ISAC, so I see a cross-section of the challenges that space companies deal with especially in cybersecurity. Prior to Booz Allen, tackling challenges at the intersection of PNT and the adversary threat. My early career began as an engineer with my hands in the electronics, coding the embedded software, working on these systems, and in many cases testing them and finding all the ways to make it fail.
And, you know, that's a great intersection for the cyber adversary because that's their goal, is to cause a system to behave or fail in some way that, to Alexander's point earlier, that's an advantage to them.
However, my [ Indiscernible ] began as a young force recon marine before I was even 20 years old so I bring a little bit of the practicality to it from, you know, what the adversary is trying to achieve strategically and tactically. And, again, to Tim's point, you want to focus on what's important. I got that out of his message, so you are solving the right problems. Very excited to talk about this with the strategic panel today.
>>HOLLY ROLLINS: Let's go ahead and get into our suggestion. Adversaries are working quickly and pretty much continuously to improve their capabilities against U.S. interests to include space, and we obviously are looking at building and delivering secure and updatable software to match the speed of the advances of our threat actors.
So this first question is directed to Alexander. How can we use activities like a penetration testing or a threat [ Indiscernible ] throughout the system development life cycle into sustainment of the life cycle to help protect U.S. interests and specifically what is the realistic utility of these efforts? Alexander?
>>ALEXANDER GATES: Thank you for that question, Holly. That's an interesting question, having, you know, worked with SecOps, having managed, built, and utilized red teams, blue teams, and hunt teams to help, you know, assess networks, to help assess weapon systems and provide feedback. I think it is a valuable tool to have these types of teams. There is a big difference between penetration tests and red team, though. Red teamings are really taking an adversarial look at capability and going up to the line of breaking the rules to try to gain that advantage and compromise a system.
And if it is done well, a red teaming exercise where the rules are clear, the kind of standards are set, the boundaries, where there is cooperation and managed expectations, the recommendations that come out of a group that's allowed the proper time and tools to test a system can be invaluable to a program manager developing a system, whether it is software, whether it is hardware, whether it is an entire weapon system. I have seen it work very well when there is good coordination and good communication.
I have seen it not be as effective when there is budget issues, dysfunctions among the various programs, contractual challenges, and those things are a reality in many programs.
So I think the penetration testing, the hunting programs could be effective programs, tools for a program development.
>>HOLLY ROLLINS: Outstanding. Thank you so much. Tim, how can this help inform future designs?
>>TIM HAMPTON: Holly, that's a great question and I think I would like to build on what Alexander was saying. If you think about this from a tool in our arsenal, I would say where we have to focus as an industry is we have to stop focusing on compliance and vulnerability management and we have to start focusing on attack surface management. And that's what this does, is it discipline deployed correctly inside your environment and inside the mission systems and the companies that you are working with. If you have folks that are continually on the wire looking at how do I move from point A to point B, how can I get to either the data or the effect, Kevin's point, that the adversary wants to get to, now you have the ability to go back from an engineering perspective and say what do we do to build in a layer that can either obfuscate, defeat, or reduce the time to compromise inside their systems.
So, again, it is a little bit of a mind shift. We have to get out of the idea, one, these are snapshots in time. So many of our assessments in cyber are snapshots in time, and I don't think that done correctly these types of assessment should be that, it should be an ongoing, continual effort. Our adversary doesn't stop, but we are. When you take that shift and use it as a continual tool inside your environment to manage and reduce attack surface, now you can influence this generation or next generation or future generations of mission systems that are being built.
>>HOLLY ROLLINS: Thanks, Tim. Anyone else want to weigh in on this topic of informing future designs?
>>KEVIN COGGINS: I just want to add, one of the most important lessons that we can learn to apply future designs is from our current designs where we have systems where it takes us 3, 5 years to upgrade the user equipment, where the space vehicles are not upgradeable at all in some cases, and we will have to live with some of these legacy capabilities for 10, 20 more years.
And so I think we need to learn from that. The pace of the threat is increasing, and if our solutions stay static, if we don't do some leaps toward the architectures that these experts are talking about, we are going to continue to fall further behind.
>>HOLLY ROLLINS: Thanks, Kevin. We will go ahead and move on to the next question. Tim, if you want to start us, why is it important to integrate ground system architectures with your defensive cyber operation capabilities?
>>TIM HAMPTON: Thanks, Holly. I think what we really have to do, again, back to the attack path modeling and the concept of how are these systems connected. And you have heard it in the intros where it was discussed about more connectivity and interconnectivity on the ICS and OT side, and it is magnified when we start talking about ground systems. And what we have to realize is that to your point in the introduction, space is contested and will continue to become more and more contested, and this is the entry point. This is the demarcation point by which we will have the ability to either detect, respond, or recover from an adversary attack.
We have to evolve our thinking to start looking less about the data, and more about cyber when we are talking about space systems as it being a safety discipline. This is something that done poorly, or if you flip it around, executed correctly from an adversarial position, unmonitored could cause a loss of life event. Now, that's a little bit of a cyber Pearl Harbor, and I don't want to get into a doom's day discussion about it, but it is the single most effective point at which we can start to protect what will continue to be deprecated systems.
And to Kevin's point, it may take 2, 3, 5 years, so we have to defend at that entry point.
>>HOLLY ROLLINS: Thanks, Tim. Alexander, do you have anything to add?
>>ALEXANDER GATES: Yes. Thanks, Holly. And I think Tim brings up some great points, and I struggle with this question because I don't know how we can get to effective defense without some level of integration, right? The cyber is fast, yes, but the ability to monitor, detect, assess, and mitigate, you don't have to do all of that at () speed, but some of that has to be done pretty quickly. And it is not just the systems, it is also the people, the processes, and training that's required.
So when an event takes place, a threatening event that, you know, everything knows how to work, whether it is a system, whether it is a crew, whether it is a decision maker, whether that decision is automated, whether it requires an approval process, that those things happen in enough time at the proper speed to make difference. And to do that without some level of equipment, capability integration, without some level of crew training and, you know, some kind of exercise and test of the system, it is going to become more and more difficult to be successful as the systems become more and more automated and more and more advanced. So I just like to add that.
>>HOLLY ROLLINS: Terrific. Thank you so much, Alexander. Kevin, what are some of the best approaches for implementing zero trust in a ground system architecture? Do you have any thoughts on that?
>>KEVIN COGGINS: You know, I think the number one thing you can do when implementing zero trust in a ground architecture is around the users, you know, the humans are typically the weakest link in security and systems that they can touch. And there are multiple technologies that are well-advanced for people to authenticate their access to a system for a system to be designed to allow them to do the things they are allowed to do and not, you know, disallow them to access things they should not.
I think that's number one. I'm going to defer to these experts on the second and third that they would do.
>>HOLLY ROLLINS: Carl, did you have any thoughts on zero trust?
>>DR. CARL FISCHER: Yes, Holly. Absolutely. As one of the big priorities for me as I'm developing more modular and disaggregated architectures is that the growth of the number of micro services that are connecting into a system. And with a zero-trust model it is important that we ‑‑ that our systems that we are connecting into have awareness of every connection coming in, right? The principle is that just because you are inside the moat of the castle doesn't mean that you have access to everything that's going on.
And so as we start to do that using the paradigm of either secret tokens or symmetric cryptography, it is important that we develop capabilities to automate that. Because it is no longer really feasible to manage symmetric cryptography across hundreds of micro services or even dozens of micro services. That becomes a burdensome task. So automation becomes key, as is standardizing that process across all of the services. Those two go hand in hand.
It is important to get your development teams from the get-go in your program. Adding security after you have already developed your capability is much harder than starting from it at the beginning and carrying it all the way through. Thanks.
>>HOLLY ROLLINS: Thanks, Carl. And kind of building on that notion of baking in security, I will just go back to you. What are some of the challenges in balancing kind of that business and mission risk and keeping those in balance and, you know, how do you start to overcome that tension of that balancing between the business and the mission risk? Do you have any thoughts on that?
>>DR. CARL FISCHER: Yeah. Absolutely. Thanks. So, you know, a lot of our customers and our nation, as we have said several times, are pushing towards being able to respond more quickly to emerging threats, whether those are cyber or otherwise, and as we are trying to be more agile and responsive we need to develop new capabilities. And when it comes to the cyber domain, developing new software capabilities, our software development teams are always trying to evaluate new technologies that are available, whether that's a machine learning library or what have you, right? There is a lot of open-source libraries that are being developed in the community.
And over the years on the programs I have worked I have seen this addressed in a couple of different ways, but one of the challenges of cybersecurity is that oftentimes the library or software approval process says you need to get all the way through a complete cyber approval before you can bring any piece of software even into the sandbox for prototyping and developing next to mission-relevant type data.
And so one of the ways that I think we can balance those needs is by developing some capabilities that allow our development teams to bring in new software more quickly with an automated preliminary scan of software prior to software approval so that our software developers can be more efficient in their rapid prototyping, they can do it with real data, and get their hands on how their software might behave. But they can also do it in a way that's safe, and that our cybersecurity team is on board with and approves of.
So for me that's been one of the recent innovations that we have discovered, and it has really helped us achieve both a strong cybersecurity posture, as well as a rapid innovation posture.
>>HOLLY ROLLINS: Outstanding, Carl. Thank you. So Tim, just sort of building on what Carl was talking about with that delicate balancing act, if you could just extend that conversation and then also address how continuous monitoring integration and delivery constructs help agencies manage mission risk, if you can kind of tackling that, that would be terrific.
>>TIM HAMPTON: I think this is something we have gotten wrong as a cyber community for a long time, and how do we start to do that correctly, to drive the conversation. I think what Carl hit on is there is a technology piece and then there is a process piece, and I would like to talk a little bit about the process piece and then bring it back to technology when we get into the continuous monitoring portion.
So when you start talking about balancing mission and business risk, what we have to do is stop doing what's not our job. We have to be uncomfortable, and we have to break out of the controls and we have to break into cyber. The way that that looks is there are so many controls and so many cyber people think in controls rather than thinking in attack surface, thinking in threat reduction, thinking in helping the business make decisions. Many of those controls existed because no one was doing it, but it is not our job. We need to get out of the business of doing business continuity planning. We need to get out of the business of doing disaster recovery, we need to get out of the business of doing physical security protection. It is not that those aren't important, but those aren't cyber-centric controls.
So once you turn that back over to the business and say, I have to document this so that I can get to CEMC or [ Indiscernible ] compliant or 853 compliance, you become a mission enabler for the business and you get a vote at the table that you otherwise wouldn't have had when it is important.
So when you transition that over to continuous monitoring, again, I hit on it earlier and I think I will try to hit the same point from a different perspective here to tie a bow around it for you, Holly, is we have to stop managing to the vulnerabilities and that's what continuous monitoring leads us to do if it is done poorly. Don't manage the vulnerabilities, manage to the threat. And that's really what we are going to have to start doing. So, again, monitor your change management and config management board, monitor where the data is put that the adversary is looking to get, that's what we need to be continually monitoring, what changed in the threat, what changed in the environment, and what do I need to do in order to continue to block the adversary.
The vulnerabilities, we need to be past that as a discipline, and move into attack surface and risk monitoring.
>>HOLLY ROLLINS: Thanks, Tim. Yeah. And so for the participants, in about 10 minutes we are going to go to Q&A, so now would be a terrific time to start entering your questions into the chat so it can come over to the panel.
Kevin, I think I'm going to go back to you for some initial comments and then, you know, anyone else can jump in. What are some of the techniques you can use to focus on the "what" an adversary is targeting opposed to a "how" they are exploring those targets? So any thoughts on the benefit of thinking about what might be of interest to an adversary?
>>KEVIN COGGINS: Absolutely. I'm going to key off of what Tim was just talking about, another perspective. When you think about the controls and the attack surface, they are all things that map into your mission stack. There is something you are ultimately trying to achieve in your mission, and you need to understand how everything maps to that, every layer.
For example, at a very low-level layer, perhaps a "what" they are attacking is the critical infrastructure for your ground station. It is electricity, it is water, it is the things you need to have, humans onsite. And you need to understand what they might have attacked there and how to defend that, and you could have backups or other things to secure that should one of those critical infrastructure elements go down. And then you start building that stack up ultimately to the mission you provide, right, through your IT infrastructure, through your OT infrastructure, to your ‑‑ what you are trying to do.
So I think key is to answering your question of how to focus on the what, you have to lay out what the what is, and you have to do it in a structured way and you have to understand how it impacts your mission.
I think that's step one and a very important step. Once you do that, then you could dissect each layer to understand how to have the resiliency you need at your end game.
>>HOLLY ROLLINS: Yeah, Kevin. I appreciate you bringing that up. I think a lot of people want to skip the boundary definition step because it seems so rudimentary, and yet if you don't know what you are securing, that can be kind of upside-down. Anyone else want to weigh in on this, Carl, Tim, Alexander?
>>ALEXANDER GATES: Yeah. I will just add briefly and, you know, what Tim and Kevin said, I think, is spot on. And it is a challenge because of a lot of sort of targeting, skating to the punt where it is going to be getting in front of the adversary requires intelligence, requires information, and you know, although we have ‑‑ if you go back 10 years or even shorter than that, we have a huge sort of commercial cybersecurity, intelligence enterprise that's providing incredible information on vulnerabilities and threats, but it still comes up short in some respects in helping us get in front of an adversary. How does country A look at our space infrastructure, and target it for advantage and then develop tailored capabilities to execute perhaps over years to position themselves to do something. Those are the types of activities that we need to imagine and then try to counter so we can ‑‑ in which we have done successfully, particularly on the IT side.
But when you start talking about ICS, when you start talking about OT systems, we don't have that same investment. We don't have that same information and intelligence infrastructure. It is a huge blind spot for us in an area that needs a lot of investment.
>>HOLLY ROLLINS: Yeah. I think that that piece on OT is so critical, and that will be definitely a focus area in the future. Carl or Tim, any additional benefits you wanted to tease out?
>>TIM HAMPTON: One, we have to be better about sharing information. We are so secretive, generally speaking, and the force multiplier that the adversary has is their ability to share and work together. And until we can model that, we are not going to win this war and we are not going to get to what they are targeting. So we have to share what happened at zero space and how did that impact us and we have to talk to Ball about that and vice versa.
And the second thing you have to do is get back to the wire and the network diagram. And we skip that step and again we focus on the controls, not on the information systems that we are protecting, and that's a key misstep that we have to do.
And I think lastly we have to get into the adversary spaces and start listening to what they are talking about. And we are so hesitant to do that, you know, and I think that was something that Alexander was teasing out, is there is such a wealth of information that's out there. So put your staff out on the deep web, put them out on the dark web and start listening and set up those non-attribution networks within your space so that you can enable that and then we will start to actually get to what they are targeting and then we can try to move ahead of them.
>>HOLLY ROLLINS: Thanks, Tim. Yeah. I can appreciate that, you know, know your enemy and begin looking at the likelihood of a potential attack surface being compromised because obviously, I don't know of a single organization that has unlimited resources to throw at this, so it seems like, you know, we are all having to kind of hedge our bets.
Carl, just wanted to get your thoughts on how you implement agility in this process in a way that actually doesn't impede the mission capabilities for which the system was originally designed.
>>DR. CARL FISCHER: So I touched a little earlier on streamlining, which is where we can balance software and use technology to help streamline that. But that ties into a bigger picture approach where we can actually use automation and tools like continuous integration and continuous delivery to help our software development teams make sure that they are implementing the details of the RMF controls that are important for cybersecurity of the software we are developing in a way that doesn't require a great deal of labor and effort on their part.
So by automating the standard RMF controls to the maximum extent possible we can actually arm our software development teams with that immediate feedback, hey, I checked in code, it satisfies these controls, here, here, and here, and I'm following a little bit short on this one, maybe, because of some new software library that I'm using or what have you.
And I have seen some really great successes using that approach on programs. One of my favorite results that I have seen implementing that kind of an approach is that it no longer pits our [ Indiscernible ] against our software development team. A lot of times I have seen programs where software says we are done and mission assurance says you have got all of these vulnerabilities in your software when we scan it, you need to fix them all. By putting those scans right upfront in the process we are able to have everybody onboard on a single team with a common mission to make sure that we achieve our stated goals of, you know, nothing more than this threshold in terms of software vulnerabilities and issues.
And that puts our software team then working hand-in-hand with our mission assurance team to solve the problems instead of more contentious approach that I have seen happen in other programs. So that automation and getting that information right upfront to the developers in a way that doesn't drive additional labor on our development teams has been a real game changer in terms of the way we approach those issues and has allowed us to deliver that software more efficiently without affecting our risking mission security.
>>HOLLY ROLLINS: Outstanding. Anyone else want to add on this topic?
>>ALEXANDER GATES: I actually have a question for Carl, just to add to the scenario. Would that include potentially red teaming at the end once there is full deployment and is that something you would see that [ Indiscernible ] prove that process?
>>DR. CARL FISCHER: I think getting red teaming involved in a more continuous process, like I think we touched on earlier in this call, instead of waiting until the end, I think there is value to start looking as micro services get developed to have that red team start right away, how can I penetrate this system, how can I exploit vulnerabilities in the approach and catch these kinds of things earlier than we traditionally do.
And I think kind of similar to the improvements we are seeing by working side by side, RMF controls and software development requirements with a red team in that kind of a role you may see a partnership start to emerge where we can start to catch these things early and fix them while there is still plenty of time and runway before deadlines approach.
>>HOLLY ROLLINS: So, Kevin, Carl just mentioned partnerships and how critical those can be. Can you talk to us a little bit, during the introduction you had mentioned that you are a board member of the space ISAC. Can you tell us a little bit about the space ISAC and what information sharing looks like through that organization?
>>KEVIN COGGINS: I'm a board member on behalf of Booz Allen, and there are many other members of the space ISAC, Information sharing and analysis. And right now the space ISAC is standing up a watch center in Colorado Springs where we are going to collect information from across our members about the cyber challenges and threats we are seeing realtime in the space environment on the ground domain, challenges to GPS that might impact their enterprise, and we are going to get that information to members so they can manage their operations and manage through that threat as rapidly as possible.
And, you know, if a member is attacked, we want everyone to learn from that and employ mitigations. And so I tell you, it is one of the most impactful opportunities in the space community, to up your resilience based on sharing information and what others are going through.
>>HOLLY ROLLINS: Thanks, Kevin. And maybe we can even post in the chat that goes out to the participants ways ‑‑ the link that they can click on to get more information on this, the space ISAC.
We now have had questions starting to come in from the participants, so I think I'm going to transition over to that. So some of these are long, so I'm just going to kind of break them down. The question reads, several of you have talked about a need to change the culture of how cyber is treated in our space community. How do you think we can best shift the culture from a compliance mindset to one that treats cyber as an engineering and operational discipline?
And I don't know, Carl or Tim, does someone want to take this?
>>DR. CARL FISCHER: I will jump in and say a few comments. I think it is a great question and I think it really does come back to our strategy and the way that we manage both compliance with things like the risk management framework as well as vulnerabilities and issues as they arise.
And by folding them in as part of the rest of the software development culture, I do think that helps build a culture of collaboration across the teams, that development teams SecOps concept, so you are responsible for all 3, development, security, and operations as part of your software team. That is a cultural shift, but it is one that as leadership on programs we need to start by encouraging that collaborative activity and that shared responsibility for achieving that end goal and facilitate the collaboration and conversation between those teams.
But I will say, it is possible, and when it happens it really clicks and can make teams much more efficient. Over.
>>HOLLY ROLLINS: Terrific. Tim, how will tomorrow's systems account for the unknown cyber threat, maybe 5, 10, 15 years out, and how will that be distinguished from system design?
>>TIM HAMPTON: Tough question, right? What's my crystal ball say about the next 5, 10 years? We are having a hard time figuring out what the crystal ball says 5 days from now. I would say what we have to do is really get back to a couple of different key aspects. We have to get to one true systems engineering. And so we have to be partnered with the systems engineers that are developing these systems, and we have to get better at articulating cyber in the form of requirements not from a compliance perspective, but from an impact and effect perspective. So don't go talk to your engineering team and say, well, I need to implement, you know, control MA2, like that's irrelevant to them, what we need to do is go to them and say, we are building a system, we are building a platform in space, and I need primary, secondary, and tertiary coms with full capability and I need the ability to cut off one of those and I need to be ‑‑ I need the ability to rebuild it after we cut it down and reimplement it. You think about, you know, infrastructure as code on a space platform, those are how we start to account for the unknown threats. We don't know how the threats will come, but we do know, to Kevin's earlier point in his intro, what they are trying to do. They are trying to disrupt services or they are trying to steal data.
So that's what we have to focus on, is how do we put failsafes and build-backs into these systems that are going to persist through a system's life cycle into space infrastructure and into a space system.
>>HOLLY ROLLINS: Outstanding. So I'm not really sure who to direct this next question to, so I will just let you guys listen and you can jump in if this is your area. How do you view the role of hardware encryptors, like type 1, in future multitenant and future ‑‑ and is it archaic, and checking the box, or is it actually useful?
>>DR. CARL FISCHER: So I can speak to that briefly, and there may be other perspectives, but at least the ‑‑ I expect that still being essential. But at the same time as we move to more service models, whether it is infrastructure, software, platform, etc., I think crypto has one of the log poles of establishing your coms between your secure ground system and your spacecraft. And so I think several organizations are keenly interested in streamlining that process so it is more turnkey for missions. It is not something that we should be reinventing and redesigning every time, and it should be something that can be kind of quickly turned on for your specific mission and potentially shared across multiple systems with a common design approach. But I would be curious to know if others have different perspectives on that one.
>>HOLLY ROLLINS: Yeah. Alexander? I think Alexander had something to add.
>>ALEXANDER GATES: Right. And I will go quickly to this one, and then back to Tim's comment. Some type of crypto is always going to be needed, of course, until there is a scary scenario dealing with Quantum. But some level of protection or multiple levels of protection are going to be required, but it is not the holy grail. There is still ways to defeat the crypto, but defeat the com system. So the protection has to be in the end.
And you know, regarding future threats, I did want to address one point there, is that ‑‑ and Tim hinted at this earlier, at some point, and this shouldn't surprise anyone as a member of the IC, at some point we have to own the threats and make that kind of threat, you know, smaller and more manageable and be able to predict where our adversaries are going so we can better protect ourselves. If we are just building walls, just adding layers of protection, that's the way this process is going to work 10 years from now, that still is kind of ‑‑ that's a higher bar, I think, to clear, easier, however, if we have a better stranglehold on those threatening us.
>>HOLLY ROLLINS: Thanks, Alexander. Tim?
>>TIM HAMPTON: Yeah. I was just going to weigh in real briefly on the crypto question. It is an interesting question and I think from a slightly different perspective than the other panelists, when we look at it from Sierra Space and we see future space platforms and future life habitats, there is going to be a need for hyper-connectivity. And I think what you are going to see is you are going to see the need for high-speed communication from space to ground in a way that doesn't exist today. You are going to see the need for communication from platform to platform, and then intra‑platforms.
So as Sierra Space builds out the first Orbital Reef, the third and the fourth, there will be other competitors, and other pods or platforms that you will have to connect to. And we don't have type 1 encryptors across our internet traffic moving back on our backbones today and I think you are not going to see that in the future. I think for specific classified space systems absolutely, but I think as we as an industry build out an ecosystem inside space, I don't believe that the demand and the business and the latency that they will induce is going to be tenable for the missions that we are trying to launch.
So I think this is an area where we are going to have to evolve and think of things differently because at some point you end up recreating the internet in space, and that technology won't scale to the business need.
>>HOLLY ROLLINS: Thanks, Tim. So Kevin, I think we are going to go to you next with the next question from the participants. How do you ‑‑ whoops, wrong question. How would you rate the satellite sector for its information-sharing practices in relation to recent cyber attacks on both Viasat and Starlink networks?
>>KEVIN COGGINS: I have actually addressed that a few times over the past month, and it is a great question. I think they did great. I think honestly with their mission customers and within their infrastructure, they did great on the information-sharing they needed to do to address the threat and restore services. That's the number one priority.
I believe within the community there hasn't been the infrastructure to ‑‑ for companies to feel safe fully sharing things that may flow into something that's proprietary or a competitive advantage. The space ISAC and through its members are working through that. If you are within the ISAC we are creating those avenues to be able to share through the watch center.
But in terms of restoring the mission, I think the community has done great. Because that's the number one priority, to Viasat and Spacelink () had, to get things going again.
>>HOLLY ROLLINS: Thank you, Kevin. How do you ‑‑ let's see, I don't know, I will just let you guys decide who is going to take this one. How do you balance continuous monitoring with minimizing attack sectors, and interestingly enough, often the continuous monitoring tools themselves provide a very attractive attack surface.
So the solution that becomes part of the problem. So anyone have a perspective on that?
>>DR. CARL FISCHER: I will jump in. I would say in general the approaches I have advocated for involve really comprehensive infrastructure as code that deploys identical environments for development testing and production. And so one of the ways that we can balance that risk versus attack or that capability versus attack surface for continuous monitoring does involve establishing sort of a different posture between those different layers.
Early on in the development and test phase that detailed monitoring can be extremely useful not only for understanding cyber attacks, but also for developers who are trying to understand, you know, what may be causing issues or where they have bottlenecks in their code, but as you move into a production posture you want to dial back some of those features and capabilities.
I think at a very high level I would say performing that inspection as out of band as possible, so moving that contents off to another network where it can be collected and monitored independently of the mission operation system is one approach. But I don't have a lot of detail to dive into beyond that at this time. Over.
>>HOLLY ROLLINS: Thanks, Carl. So development teams, SecOps and zero trust are becoming effective methods to develop cyber into our space system. Do you see emerging technologies or concepts on the horizon to support cyber resiliency for space missions?
Alexander or Tim?
>>TIM HAMPTON: Yeah, Holly. I will take a stab at that, and I would be interested in Kevin's thoughts as well. When I think about emerging technologies and what's there and not there I think one of the things that we are not seeing a whole lot yet, but we will, is blockchain. And again, I think what we have to do when we start to look at these systems is we have to get to a level of ensuring that the data is correct. And I think blockchain is one area that we can start to look at critical command paths and implementing that, you know, sort of the same way we used to use hashes back in the day, you know, as we did file transfers.
And so I think anything that's fast is up for grabs, but I think that's what we are going to have to start to focus on, what's the impact to the latency and the overall user experience or business experience on these space systems, and I think what we have to also focus on is what are the things that are self-healing and can repair, right? And so, again, infrastructures of code that we can tear down and put back in place or replace very rapidly, I think those are things that we are going to have to continue to look at.
Those are some that come to mind.
>>HOLLY ROLLINS: Anyone else have comments on this topic?
>>DR. CARL FISCHER: Like I mentioned in my introductory remarks, that sort of develops a bulkhead approach to your system so that it is not one single server that can be exploited, but it is actually a whole bunch of small services that are fairly well isolated from each other. And that approach is another good strategy for disaggregating the system and making it more modular, but also constraining and making cyber attacks more difficult to move between different elements of the system.
>>HOLLY ROLLINS: Thanks, Carl.
>>KEVIN COGGINS: If I may, Holly, quickly, I'm just going to follow up on Tim. I could not agree more with blockchain and what I will call blockchain derivative technologies. I know of a few space capabilities that are leveraging these and they are extremely robust as to how they are using those. And as people figure it out, it is going to be adopted pretty broadly.
>>HOLLY ROLLINS: Terrific. Well, we got through a lot of our questions. We are coming up to the top of the hour and need to kind of start drawing it down. There was one additional question, and we may have to just default to Kevin dropping a link out to the participants to read up on this, but the final question was what lessons learned do we know from the KA‑ SAT attack on the Viasat systems at the start of the Ukraine War? Is this just a difference between commercial systems and government systems, and I don't know that we really have time to unpack that, per se, but if we can just share the link that Kevin had from the blog, unless anyone wants to just make a quick comment on that. But we are kind of running out of time.
>>KEVIN COGGINS: My only comment is that I don't draw a distinction between commercial and military systems. I draw a distinction between the missions. But the adversary is the same. And we do have a link from Viasat where they did share a lot of details about the attack. And that's the one we can share.
>>HOLLY ROLLINS: Terrific. So I think we are just going to go with sharing that link, and you guys can unpack that among yourselves.
So I really just wanted to thank each of the speakers for sharing their insights today, and thank you for those who submitted questions. Hopefully, you got some of the answers or at least a point of view that will help you.
If it isn't already, you will notice that we have a polling question that will appear on the right of your screen, and we would just ask if you could just take one minute or two to answer and provide your feedback. It is really critical to Booz Allen's ability to run the successful events in the future, so we would really appreciate your feedback.
You can also see on the slide that is up right now, we have provided additional resources and links to other information that you might find useful, and then you will also receive a recording of this webinar due to your registration and participation today.
And so with that, once again, thank you to each of the participants who dialed in to listen to this, and thank you again to each and every speaker. Have a blessed day. Thanks.
