[00:06.500 --> 00:12.280]  Hello, I'm Pam Melroy and I'm delighted to be here today for Aerospace Village to talk about
[00:12.280 --> 00:18.440]  cybersecurity lessons learned from human spaceflight. So I'll start out by introducing
[00:18.440 --> 00:29.460]  myself. I am a retired Air Force test pilot and a NASA astronaut. I flew three times in space
[00:29.460 --> 00:34.760]  on the space shuttle to the International Space Station. My first two missions I was the pilot
[00:34.760 --> 00:40.040]  in the right seat. And on my final mission, I was the mission commander of the space shuttle.
[00:40.420 --> 00:46.200]  Now, all of my missions were to the International Space Station. And this is a picture of what it
[00:46.200 --> 00:52.120]  looks like now in space orbiting above us at about 400 kilometers. It's an international
[00:52.120 --> 00:58.620]  laboratory. Now, there's lots of very interesting science that you can do in microgravity
[00:58.620 --> 01:05.900]  as you're whizzing around in low Earth orbit, experiencing a balancing of all the forces. So
[01:05.900 --> 01:10.280]  it feels like there's no gravity. You don't feel the effects of gravity, even though they're there.
[01:11.980 --> 01:16.260]  We discovered we could do a lot of really interesting science on the space shuttle,
[01:16.260 --> 01:22.420]  like fluid mechanics, combustion, and even studying the human body and biology. But
[01:22.420 --> 01:28.280]  flying on the shuttle, we only flew about six or seven times a year for about 10 days to two
[01:28.280 --> 01:35.480]  weeks at a time. And so the United States joined with our partners, Russia, Japan, Canada,
[01:35.480 --> 01:41.280]  and Europe to build the International Space Station so that we could do science 24-7,
[01:41.280 --> 01:48.480]  365 days a year. And now, of course, if you look at the space station, you realize it's far too big
[01:48.480 --> 01:53.960]  to put on the top of a rocket and launch it. We had to bring it up a piece at a time
[01:53.960 --> 02:01.680]  and build it as we went along. If you look in the upper left-hand corner, you can see Atlantis
[02:02.260 --> 02:09.360]  from my second flight with part of the truss segment that the solar arrays sit on, filling
[02:09.360 --> 02:15.580]  up the entire payload bay. So we carried up an element at a time and then using the robotic arm
[02:15.580 --> 02:22.040]  of the space shuttle and the space station, maneuvered it into position and then bolted
[02:22.040 --> 02:29.060]  it down. And then we sent spacewalkers outside to make the power, cooling, and data connections.
[02:29.060 --> 02:35.720]  And then inside the space station, we would activate the element. Now, most of the time,
[02:35.720 --> 02:42.780]  we actually had to upgrade the software each time that we did that on the ISS because we had new
[02:42.780 --> 02:49.380]  mass properties, new capabilities. And so it wasn't just activating a new element, it was actually
[02:50.260 --> 02:55.520]  constantly evolving the International Space Station command and data handling system.
[02:57.510 --> 03:06.510]  Now, after I left NASA, I went on to a variety of opportunities in industry and government,
[03:06.510 --> 03:13.390]  including spending a couple of years with the FAA's Office of Commercial Space Transportation,
[03:13.390 --> 03:20.070]  learning all about space policy and the new emerging commercial space industry.
[03:20.070 --> 03:25.510]  And I spent four years at DARPA as a deputy of the Tactical Technology Office overseeing the air
[03:25.510 --> 03:31.650]  and space research portfolio. Space is incredibly important in our daily lives.
[03:32.030 --> 03:38.030]  The GPS navigation that we have on our phone is just the beginning. Think of all the apps
[03:38.030 --> 03:45.750]  that use GPS, agriculture, most importantly, financial transactions. When you use an ATM,
[03:45.750 --> 03:51.950]  the timing signal is set by GPS. We also use space for national security communications
[03:51.950 --> 03:57.850]  throughout the world. Think about remote sensing of our Earth to study the weather,
[03:57.850 --> 04:02.510]  be able to predict it, and have other indicators of the health of the Earth.
[04:02.510 --> 04:08.710]  We've had a very complacent attitude about our satellites because physical access was basically
[04:08.710 --> 04:14.770]  impossible once the satellite was launched. But now we know that our key infrastructure is at
[04:14.770 --> 04:20.530]  threat on the ground, and it is in space as well from both physical and cyber threats.
[04:20.690 --> 04:27.210]  Space systems have always focused on safety and mission assurance because you can't access them,
[04:27.210 --> 04:33.270]  you can't repair them, and it's expensive to launch things. So we've spent a lot of time
[04:33.270 --> 04:40.650]  focusing on redundancy and testing and mission assurance. Now we have the commercial world coming
[04:40.650 --> 04:49.530]  into play, doing things faster and cheaper. And we have the potential for lunar exploration.
[04:49.610 --> 04:55.250]  And we also have nation-states competing for achievements and resources in space.
[04:55.250 --> 05:00.570]  So the threat is evolving. We need to understand the implications and prepare for the challenges
[05:00.570 --> 05:05.510]  ahead. I'm going to talk a little bit about the lessons learned from the software approach to
[05:05.510 --> 05:10.970]  human spaceflight for both a space shuttle and a space station. But first I'd like to actually
[05:10.970 --> 05:16.330]  address, so what is the real threat? What could a hacker actually do to a satellite?
[05:16.710 --> 05:22.330]  Well, the simplest hack, of course, is a denial of service. Pretty straightforward. And it's
[05:22.330 --> 05:29.390]  actually happening today. Jamming of signal. Sometimes it's inadvertent, just having a
[05:29.390 --> 05:34.030]  transmitter tuned too loudly so it's drowning other transmitters out. And sometimes it's
[05:34.030 --> 05:42.210]  completely intentional. You could intercept commands and data. So you could understand what
[05:42.210 --> 05:47.390]  things the satellite is pointing at, what it's taking pictures of, see that data stream for
[05:47.390 --> 05:55.830]  yourself, and also intercept communications. There's also the potential for the man-in-the-middle
[05:55.830 --> 06:01.310]  type of attacks. That's quite a bit harder, actually, with most space systems now, because
[06:01.930 --> 06:06.510]  you would have to really understand the data stream in order to alter it.
[06:07.050 --> 06:12.730]  Now, could you do something crazy like send it over to hit another satellite? So if you think
[06:12.730 --> 06:17.270]  about a self-driving car and hacking that, you could drive it off the road. Well, not really.
[06:17.270 --> 06:22.630]  Most satellites don't actually carry enough propellant to maneuver over to another satellite.
[06:22.630 --> 06:28.570]  But what you could do is run the satellite out of fuel. You could shut down a critical system
[06:28.570 --> 06:35.510]  like cooling or pointing the solar arrays at the sun. Now, there are roughly 5,000 active
[06:35.510 --> 06:41.510]  satellites in space, but only the International Space Station has humans on board permanently.
[06:41.770 --> 06:46.070]  So even back in the 70s, when the shuttle was being designed, there was a recognition
[06:46.650 --> 06:52.170]  that it was going to be different. Lives were going to be at stake. So a much higher level
[06:52.170 --> 06:57.530]  of attention needed to be paid to software errors that could have catastrophic consequences.
[06:57.530 --> 07:04.510]  So I'd like to talk about some of the lessons that we can learn from the shuttle and from ISS.
[07:08.220 --> 07:14.100]  Now, it's kind of easy to make fun of the space shuttle. Yes, this is a picture from my first
[07:14.100 --> 07:21.180]  flight. And you can see that we interfaced with the shuttle computers using a cathode ray tube
[07:21.180 --> 07:28.220]  screen. And that's a blow-up of what it looks like. It's black with green letters on it.
[07:28.220 --> 07:36.240]  Absolutely no graphics processing units or, you know, any kind of artistry at all. It's anything
[07:36.240 --> 07:42.600]  that you could make with numbers and lines. And that was pretty much it. We also were very limited
[07:42.600 --> 07:48.060]  in the way that we could communicate. We didn't have a full keyboard the way most computers do.
[07:48.060 --> 07:54.560]  We had a small hexadecimal keyboard. Now, this actually wasn't that bad. One of the
[07:54.560 --> 08:00.240]  very clever things that was done with shuttle software was the extensive use of
[08:01.280 --> 08:06.800]  bundled commands, what I would, in my simplistic mind, think of as a macro.
[08:07.540 --> 08:14.840]  So there were many, many things that needed to have multiple tasks done, say to configure the
[08:14.840 --> 08:23.040]  entire vehicle for a different phase of flight or to prepare for another activity. So rather than
[08:23.940 --> 08:31.440]  throwing switches, which were limited space, or pressing in a number or an action for every
[08:31.440 --> 08:38.440]  single one, you had the capability to hit item and a number and then execute on a given page,
[08:38.440 --> 08:44.400]  and it would set off a whole string of bundled commands. So it actually wasn't as bad to
[08:44.400 --> 08:51.080]  interface with as you might think. Now, here's one of the areas that I really didn't like.
[08:51.080 --> 08:56.800]  The fault summary. So if something went wrong, this is the page that you went to. And it had
[08:57.000 --> 09:03.700]  a maximum of 15 faults displayed, which most of the time was pretty okay. But worse, it doesn't
[09:03.700 --> 09:10.280]  have any scrolling capability. So on my first flight, we had a malfunction. We had an electrical
[09:10.280 --> 09:16.760]  bus short on a payload bus that provided about one-third of the power to the payload and the
[09:16.760 --> 09:22.620]  systems aboard the space shuttle. Now, you can imagine when that happened, every bell and whistle
[09:22.620 --> 09:28.140]  went off inside the space shuttle. And when I went back to look at this fault sum, I didn't have
[09:28.140 --> 09:32.920]  very many choices. I had to either write everything down, because when I hit reset, it was gone and I
[09:32.920 --> 09:39.140]  could never see it again. And the messages would stack up and get lost behind each other. So
[09:39.140 --> 09:46.100]  definitely, you can see some real weaknesses in the interface area. I think that was a real
[09:46.100 --> 09:51.660]  challenge, I think, but probably very reflective of the capabilities of the 70s.
[09:52.500 --> 10:01.900]  The Shuttle General Purpose Computer, or GPC, was a marvel. Really, incredibly rugged. So carrying
[10:02.360 --> 10:08.660]  a whole whopping megabyte of RAM, but very, very rugged. It had to be rugged. It had to withstand
[10:08.660 --> 10:15.860]  the intense vibration and g's of launch. It also had to be very radiation tolerant, compared to
[10:15.860 --> 10:23.080]  the laptops that we carried that I'll talk about in a little bit, which had constant cosmic ray
[10:23.080 --> 10:31.480]  hits and corruption of data, requiring you to reboot them typically once a day. That was not
[10:31.480 --> 10:37.340]  the case with the GPC. It was very, very rugged, and it was meant to be radiation tolerant. It was
[10:37.340 --> 10:46.980]  also highly efficient. Only 400,000 lines of code to operate the entire space shuttle. Pretty
[10:46.980 --> 10:53.920]  amazing, actually, that we could do that. Part of the reason for that is that code in space has
[10:53.920 --> 11:01.340]  weight implications. That's right. If you're doing more computations, you need more power and more
[11:01.340 --> 11:09.340]  cooling, which is more mass and more volume. And so efficiency in software is incredibly important
[11:09.340 --> 11:16.200]  in space, and the space shuttle definitely reflected that. One of the cool things about the
[11:16.200 --> 11:24.740]  space shuttle software was it had a very, very low error rate. So I'm showing here a table from
[11:24.920 --> 11:31.120]  a great paper that's got the link at the bottom, reflective of the space shuttle
[11:31.120 --> 11:38.120]  software history. If you look back to the right-hand side there, the total error rate per
[11:38.120 --> 11:48.700]  case lock in 1981 was about eight to nine. That's pretty darn good. And within seven years,
[11:48.700 --> 11:54.720]  it was consistently down around one, which is an order of magnitude better than commercial
[11:54.720 --> 12:00.400]  software. Some would say two orders of magnitude, depending on the software. And you can see that
[12:00.400 --> 12:06.800]  by the time we got close to the end of the space shuttle, flying the space shuttle, we had gotten
[12:06.800 --> 12:17.100]  the error rates in our new updates down to zero. Now, how in the world did we do this? Well, we kind
[12:17.100 --> 12:25.220]  of had to brute force it, right? It was a lot of verification and testing. So each space shuttle
[12:25.220 --> 12:32.980]  mission had unique software on it. Now, there was the core software, which was the same, but it was
[12:32.980 --> 12:38.600]  actually a unique software load because you had a different payload. You had different mass
[12:38.600 --> 12:42.580]  properties. Maybe you were going to the space station, or maybe you were going to a different
[12:42.580 --> 12:50.100]  inclination. So for each shuttle mission, months were spent on that unique software load doing
[12:50.100 --> 12:57.440]  verification in SAIL, the Shuttle Avionics Integration Laboratory. And the idea behind
[12:57.440 --> 13:02.160]  that is you would have crews and engineers who would run through tons and tons of scenarios,
[13:02.160 --> 13:09.420]  lots of procedures, to verify that there were no unwanted changes to the software.
[13:09.420 --> 13:16.200]  This is pretty amazing, considering that there were no auto debugging capabilities at that time.
[13:16.200 --> 13:22.860]  So it was very manual intensive, but it does show that it is possible to get very, very low error
[13:22.860 --> 13:28.700]  rates. One of the other interesting things about the shuttle software program was that
[13:28.700 --> 13:37.100]  not only was verification very intense, but if a bug or an error was found,
[13:37.100 --> 13:45.440]  the program would go back and take a look at what process escape allowed that bug to slip through.
[13:45.680 --> 13:52.280]  So in addition to just checking the software, they were also looking at the entire coding process
[13:52.280 --> 13:58.400]  to go back and see if they could trap any other bugs that were from the same process escape,
[13:58.400 --> 14:03.980]  and plug that process escape so that future bugs would not be introduced to the system.
[14:05.140 --> 14:11.580]  Another aspect of the Space Shuttle that was really interesting and added to the resiliency of
[14:11.580 --> 14:19.000]  the system was the flexible redundancy in the software systems put into the general purpose
[14:19.000 --> 14:26.480]  computers. So we carried five GPCs aboard the Space Shuttle. Four of them were loaded with
[14:26.480 --> 14:33.360]  the primary avionics software system, known as PASS, and one computer was loaded with backup
[14:33.360 --> 14:41.880]  flight software, or BFS. That software was developed completely independently. It was a
[14:41.880 --> 14:47.240]  separate company, a separate group of people, there was no interaction or interfacing between them.
[14:47.240 --> 14:54.520]  That backup flight software was there to protect in case there was a flaw in the primary avionics
[14:54.520 --> 15:01.080]  software system that affected the four primary computers that were used. Now, backup flight
[15:01.080 --> 15:08.200]  software didn't have all the same capability as PASS. It had basically what you needed to
[15:08.200 --> 15:15.380]  complete an ascent and get to orbit safely, or if you had a problem occur on entry, to get down to
[15:15.380 --> 15:24.960]  the ground. So on ascent and entry, we flew with four computers running in parallel with each other
[15:24.960 --> 15:33.120]  and the backup ready to go. And if there were any failures that you lost confidence in either the
[15:33.120 --> 15:39.780]  software or the GPCs, the crew could press a red button on the stick and instantly jump over to the
[15:39.780 --> 15:46.680]  backup flight software and then get into a safe place with that software. Any computer could take
[15:46.680 --> 15:53.500]  any of that software. If you got on orbit and realized that the BFS computer that had BFS
[15:53.500 --> 16:01.920]  loaded into it had a hardware problem, that was fine. You could load BFS for entry into any one of
[16:01.920 --> 16:10.300]  the other GPCs. The mass memory unit on board had several copies of both sets of software.
[16:10.880 --> 16:18.720]  So if you found an error in the software, maybe there was a coding problem or a corruption,
[16:18.720 --> 16:25.100]  in one of the GPCs you could reload the software from the mass memory unit and you had actually
[16:25.100 --> 16:31.100]  several copies to select from in case again somewhere on the mass memory unit
[16:31.100 --> 16:37.140]  there was a corruption or a failure. Incredibly flexible, incredibly redundant.
[16:38.940 --> 16:45.440]  The other key aspect that I think had a very positive impact on resiliency but also on security
[16:45.440 --> 16:50.500]  is a distributed architecture and the space shuttle was one of the first vehicles
[16:50.500 --> 16:56.180]  to use this capability. So the idea is that you separate critical functions
[16:56.180 --> 17:02.300]  and then you're very careful and limit what information is allowed to pass between them
[17:02.300 --> 17:09.640]  and there are checks to make sure that you protect that. So on orbit we would
[17:09.640 --> 17:19.400]  shut down three of the GPCs into basically into a warm mode and so that we could restart them
[17:19.400 --> 17:24.240]  if we needed to. We had one actually was warm as a warm backup and the other two were shut down
[17:24.240 --> 17:30.240]  completely. And then in one computer we had guidance, navigation, and control. Very critical
[17:30.240 --> 17:37.020]  software controlling the vehicle, knowing where its navigation state was, knowing where you were
[17:37.020 --> 17:42.900]  pointed, all very very critical aspects of operating the vehicle. And then in another
[17:42.900 --> 17:49.720]  computer we loaded systems management software or SM software and that had critical functions
[17:49.720 --> 17:55.840]  having to do with the systems but the communications between these were very tightly structured.
[17:57.320 --> 18:03.840]  Well we found pretty quickly that three CRTs was not enough information for the crew especially as
[18:03.840 --> 18:10.840]  our missions began to get more complex on in the shuttle program. And so we added a third tier
[18:10.840 --> 18:20.020]  to the distributed architecture, a payload general support computer or PGSC. And that's a picture of
[18:20.020 --> 18:27.500]  the IBM ThinkPad that I flew on my missions as a PGSC. Each crew would carry somewhere between
[18:27.500 --> 18:34.840]  five and seven PGSCs. They performed functions like a world map so that you could just glance
[18:34.840 --> 18:40.160]  at the map and know exactly where over the earth you were. You could see critical things like if
[18:40.160 --> 18:45.500]  there was a loss of communications coming up, a comm outage, or something like that. But we used
[18:45.500 --> 18:51.220]  them heavily for mission support. In the bottom left picture is me and my friend Koichi Wakata
[18:51.220 --> 18:59.040]  had just completed a very complex robotics operation using the two PGSCs mounted behind us.
[18:59.040 --> 19:03.200]  Of course in microgravity it was pretty easy to mount those anywhere that you wanted to. They just
[19:03.780 --> 19:12.840]  would stick with a little bit of velcro on a platform. And those PGSCs would take data from
[19:12.840 --> 19:19.560]  the GNC and the SM computers but could not send anything back. So it was a one-way flow of data
[19:19.560 --> 19:26.980]  from the GNC computer or the SM computer to the PGSC. Now in the bottom right hand corner you see
[19:27.280 --> 19:34.400]  a picture of the Rendezvous and Proximity Operations Program, or RPOP, which is an app that we used
[19:34.400 --> 19:41.280]  to visualize the orbital mechanics between the shuttle and the station. And that picture was
[19:41.280 --> 19:48.400]  taken shortly after I docked to the space station showing my approach, my line of approach.
[19:48.400 --> 19:58.800]  Now we also used these laptops for email, but the email wasn't directly connected. In fact,
[19:58.800 --> 20:04.660]  what would happen is the ground would sync up our mail three times a day. So you know,
[20:04.660 --> 20:10.020]  three times a day we'd get a message from the ground, basically mail call, and you know,
[20:10.020 --> 20:15.860]  everybody would scramble for a computer to check their email. We could do that because we were
[20:15.860 --> 20:21.420]  only in space about 10 days to two weeks at a time. We also used it for file sharing and other
[20:21.420 --> 20:27.220]  things like that. The PGSCs were absolutely essential, but they were also very isolated
[20:27.220 --> 20:36.020]  and very protected. Now this is a pretty happy story about the overall security of the shuttle
[20:36.020 --> 20:41.540]  software system and how we approached it, but that doesn't mean that we didn't have unanticipated
[20:41.540 --> 20:50.140]  issues, almost all of them resulting from complexity. So we used for many, many years
[20:50.140 --> 20:57.740]  on the space shuttle, inertial navigation units were the primary form of maintaining the navigation
[20:57.740 --> 21:04.200]  state, you know, where are you in space? And the ground could uplink information from a radar pass
[21:04.200 --> 21:09.940]  or something that gave us more precise information. But when the opportunity came to integrate a GPS
[21:09.940 --> 21:16.660]  receiver, when they started to become lightweight enough and ubiquitous enough, that was a great
[21:16.660 --> 21:23.020]  opportunity because we were doing highly precise navigation maneuvers like rendezvousing with the
[21:23.020 --> 21:30.100]  space station. Now the first time we tested it was on STS-91 and of course we were smart enough
[21:30.100 --> 21:36.780]  not to make the GPS receiver be the only generation of the nav state. In fact, we disconnected
[21:37.550 --> 21:44.980]  the GPS receiver from the primary nav state of the GNC computer. So we didn't want to influence or
[21:44.980 --> 21:51.300]  upset that, but we wanted to monitor it. So there was an aiding state, basically a secondary state
[21:51.300 --> 21:57.140]  that the GPS receiver would periodically update. And that way we could sort of measure and see what
[21:57.140 --> 22:03.600]  the nav state would look like if the GPS receiver was updating it. Well, we had a little hiccup.
[22:03.600 --> 22:09.480]  The GPS receiver had a software anomaly and basically went into a control-alt-delete type
[22:09.480 --> 22:17.000]  reboot situation. And unfortunately, at exactly the same time, the GNC computer sent a message
[22:17.000 --> 22:23.640]  to the GPS receiver asking for an update to the aiding state. Well, the GPS receiver never saw it.
[22:23.640 --> 22:33.880]  When it came back up on board, it was not a flag that was set. And so as far as the GPS
[22:33.880 --> 22:38.140]  receiver was concerned, it had never been asked for the information and never provided it.
[22:38.140 --> 22:44.860]  So the GNC computer at that point said, uh-oh, GPS receiver is down. So stopped asking for updates
[22:44.860 --> 22:52.100]  from the GPS receiver. Now that aiding state began to degrade, right? You're propagating a navigation
[22:52.100 --> 22:59.440]  state without putting any corrections in. And sooner or later, the numbers started to go pretty
[22:59.440 --> 23:06.240]  funky and math errors began to be generated. No problem, right? No problem. I told you already,
[23:06.240 --> 23:11.720]  very limited information flows between the GNC computer and the systems management computer.
[23:11.720 --> 23:17.540]  Everything should be just fine. Well, there are two very important things that are communicated
[23:17.540 --> 23:24.040]  between the GNC computer and SM. The first one is the nav state. So the systems management
[23:24.040 --> 23:30.540]  computer knows where to point the antenna to talk to the ground. Unfortunately, when those math
[23:30.540 --> 23:38.600]  errors started to generate, the other type of information came into play, which is error codes.
[23:38.600 --> 23:44.660]  Of course, the systems management computer wants to know if there's a problem on the GNC computer.
[23:44.660 --> 23:51.660]  Well, the intercomputer communication bus got flooded with these math errors, which essentially
[23:51.660 --> 23:58.600]  choked out passing the nav state. So the systems management computer did not receive any updated
[23:58.600 --> 24:07.140]  shuttle state vectors. And eventually, this antenna lost lock with the satellite that linked
[24:07.140 --> 24:12.700]  it to the ground. And one of the most serious problems that can happen in space is a loss of
[24:12.700 --> 24:19.360]  communications. And it happened while the crew was asleep. Well, MCC to the rescue, mission control
[24:19.860 --> 24:29.140]  was able to actually get in and figure out how to manually... they eventually got a lock
[24:29.140 --> 24:35.020]  over a ground station. They sent a command to manually point the antenna at the TDRS satellite
[24:35.580 --> 24:41.960]  and then were able to fix the problem. But it just points out that
[24:42.660 --> 24:48.460]  it was really incredibly resilient and they thought through as many
[24:48.460 --> 24:52.820]  errors as they could. But in a complex system like this, you can still have problems.
[24:53.700 --> 24:59.580]  Now, we learned a lot for the International Space Station. I'd like to say we really upped our game.
[24:59.880 --> 25:04.840]  We learned a lot about security, starting all the way with the ground system.
[25:04.840 --> 25:11.280]  Even back in the Apollo days, there was not the capability to talk straight from Houston up to
[25:11.280 --> 25:17.840]  the spacecraft. But instead, a large set of antennas in White Sands, New Mexico, talking
[25:17.840 --> 25:23.840]  to the tracking and data relay satellite, which then communicates low data rate S-band audio
[25:23.840 --> 25:30.600]  information and high data rate KU-band video and payload data. This entire network is completely
[25:30.600 --> 25:39.380]  owned by NASA. So this is not going through open internet. There's no cloud. This is completely
[25:39.380 --> 25:45.980]  controlled to NASA. And of course, it's been updated. So just another aspect of the security.
[25:48.060 --> 25:53.100]  Another interesting issue was around mission control commanding.
[25:53.100 --> 25:57.100]  Now, people weren't really thinking about hacking, but what they were thinking about
[25:57.100 --> 26:03.320]  is making mistakes. So an innocent mistake could send a bad command. Now, that was true for the
[26:03.320 --> 26:09.640]  space shuttle, too. But we had fewer controllers for the space shuttle, all hands on deck,
[26:09.640 --> 26:14.560]  the six times a year or seven times a year that the shuttle was flying. So a high level of
[26:14.560 --> 26:20.220]  proficiency in a very small pool of people. Well, with the International Space Station
[26:20.220 --> 26:30.620]  operating 365 days a year and 24-7, we needed a lot more controllers. So there's a very rigorous
[26:30.620 --> 26:37.940]  certification process required for controllers in the International Space Station Mission Control
[26:37.940 --> 26:44.800]  Center to allow them to send commands to the space station. In addition, there are screening
[26:44.800 --> 26:52.640]  protocols, both before it ever leaves MCC, going up to the ISS, and once it's on board ISS,
[26:52.640 --> 27:00.100]  to check and make sure that that command will not inadvertently do some damage to the station.
[27:00.240 --> 27:07.100]  And so, again, really all of these characteristics were really there for safety,
[27:07.100 --> 27:12.560]  but they have the added capability of adding to the cybersecurity as well.
[27:13.520 --> 27:19.460]  Now, distributed architecture. This is at a whole new level on the space station.
[27:19.460 --> 27:26.160]  So starting with the command and control computers, multiplexer, demultiplexer, or MDMs, there's three
[27:26.160 --> 27:35.460]  command and control MDMs that control the station. And just like the GNC and the SM computers on the
[27:35.460 --> 27:43.100]  shuttle, in this case, there are multiple separate payload and ISS element MDMs to control the
[27:43.100 --> 27:49.340]  system. So highly distributed in that regard. And again, with very strict rules about bus traffic
[27:49.340 --> 27:55.900]  between them. Now, the crew on board the space station does not have cathode ray tubes, I'm very
[27:55.900 --> 28:02.200]  happy to report. Instead, they use a laptop called the portable computer system. I apologize for all
[28:02.200 --> 28:09.000]  the acronyms. This is what NASA does, though. Anyway, the PCS is used for the crew to send
[28:09.000 --> 28:16.980]  commands to the ISS MDMs. It's essentially a remote terminal. It plugs in. They are not networked to
[28:16.980 --> 28:24.440]  each other. They are plugged directly into the station and can send commands. Now, they have the
[28:24.440 --> 28:30.600]  same issues that we did on the space shuttle, wanting more screens, more apps, more capability.
[28:30.600 --> 28:37.760]  And so there is an ops LAN. It is a local area network using station support computers.
[28:39.080 --> 28:46.600]  These computers are used for procedures, email, and everything else. Including Twitter. Now, you
[28:46.600 --> 28:52.680]  may be wondering, because I told you on the space shuttle, we didn't have real-time access to the
[28:52.680 --> 28:59.160]  internet. Well, that's a real hardship on the space station, if you stop and think about that for a
[28:59.160 --> 29:04.940]  moment. Because there are people living up there for six months. And, I mean, just even really
[29:04.940 --> 29:09.040]  simple things. Like, if you were up there for six months, and maybe you wanted to go on the
[29:09.040 --> 29:14.800]  internet and buy your husband a birthday present. And lots and lots of other things. So, and of
[29:14.800 --> 29:22.480]  course, the onset of Twitter, which astronauts have embraced completely. So, it took a fair
[29:22.480 --> 29:28.020]  amount of work to set up the cyber security. Because that was already a consideration even by
[29:28.020 --> 29:33.740]  then. So, there's a computer inside the firewall at the Johnson Space Center that is the proxy
[29:33.740 --> 29:39.740]  computer. So, the space station support computers talk to the proxy computer, which then goes out
[29:39.740 --> 29:46.260]  onto the internet. Now, of course, just like any computer, it's still subject, potentially,
[29:46.260 --> 29:52.760]  to malware. But the most important thing is the station support computers, in no way, shape,
[29:52.760 --> 29:59.700]  or form, are networked to the actual commanding of the station. They're completely separate systems,
[29:59.700 --> 30:06.640]  and they don't talk to each other. And so, a hacker might be able to get at, with great
[30:06.640 --> 30:11.700]  difficulty, but might be able to get at somebody's email on board the space station. But they
[30:11.700 --> 30:18.200]  couldn't take over controlling the station. Sort of the ultimate in a distributed architecture.
[30:18.760 --> 30:23.880]  So, the use of computers is so important on the International Space Station. I just want to show
[30:23.880 --> 30:30.380]  an example, actually, of how they're used operationally. And this is a picture from
[30:30.380 --> 30:36.060]  my third flight in space, where we had a lot of important robotics operations. So, in the center
[30:36.060 --> 30:43.820]  of the screen, you will see three videos. And then, underneath the one on the left, and on the right,
[30:43.820 --> 30:50.580]  are two hand controllers. They control the robotic arm of the space station. So, that's how you move
[30:50.580 --> 30:58.660]  the arms with those hand controllers. Now, I talked about the PCS, which does command, and it actually
[30:58.660 --> 31:04.940]  can send commands to the big arm. Turn it on, turn it off, switch power sources, and so forth. And so,
[31:04.940 --> 31:11.060]  the PCS on the right was set up for ISS commands. And then, there's a backup PCS set up in the
[31:11.060 --> 31:19.680]  middle. It enables you to quickly, if there's a hardware or software failure on the primary PCS,
[31:19.680 --> 31:25.220]  you could go to the backup PCS very quickly. And in addition, it allows you to monitor other
[31:25.220 --> 31:32.040]  critical systems that interact with the robotic arm. And then, the other three computers, the two
[31:32.040 --> 31:37.720]  above and the one to the left, are part of the OPSLAN. They're station support computers. They
[31:37.720 --> 31:43.380]  provide extra camera views, procedures, file sharing, etc., etc.
[31:45.800 --> 31:53.060]  Now, areas of concern in space systems for me. I'd like to shift gears a little bit and say,
[31:53.060 --> 31:59.980]  this is what I see out there that is worrying me. First of all, uplink and downlink to most
[31:59.980 --> 32:09.980]  satellites is encrypted, but the data on the bus itself is not. So, of course, it's easy to say,
[32:09.980 --> 32:15.980]  well, there's no way to access it. It's just out there. It's in space. But in fact, I think it is
[32:15.980 --> 32:20.760]  an area of concern. It's something that we should be thinking about encrypting onboard traffic as
[32:20.760 --> 32:26.300]  well. Ground system vulnerabilities is probably the one place that if you're talking to a space
[32:26.300 --> 32:32.520]  person, they will acknowledge there is a cyber risk. Our ground systems are very vulnerable.
[32:32.520 --> 32:40.160]  They're just as vulnerable as any enterprise computer, as part of any enterprise IT system.
[32:40.320 --> 32:46.640]  Something interesting, particularly in DoD, is that all of the constellations and all of the
[32:46.640 --> 32:52.840]  satellites, most of them have completely unique ground systems. Now, DoD is moving away from that.
[32:52.840 --> 32:57.940]  They're having a common ground system going forward. But what that means is that they're all different.
[32:57.940 --> 33:04.040]  Now, the good news is, well, if you figured out an exploit in one, it wouldn't necessarily work
[33:04.040 --> 33:10.220]  on another one. But the flip side to that, from an enterprise IT management standpoint, is
[33:10.220 --> 33:17.660]  configuration management, patching, and so forth, is a nightmare. So, that is a real concern.
[33:17.660 --> 33:25.760]  And fortunately, it's being addressed in DoD. Edge computing. Well, the challenge
[33:26.460 --> 33:31.960]  there is, you know, I had talked a little earlier about how man-in-the-middle attacks are kind of
[33:31.960 --> 33:37.680]  hard on satellites, because real-time, you have to see the data stream and then figure out what
[33:37.680 --> 33:46.120]  you want to inject into it. Well, edge computing is becoming increasingly important. Now, I mentioned
[33:46.120 --> 33:52.180]  the fact that in the past, it's been minimized to do computations on board. There was really
[33:52.180 --> 33:58.640]  just enough code and just enough hardware to run the satellite, run its payload, and then
[33:58.640 --> 34:04.880]  communicate all the data to the ground. And that's, as I said, because it had weight implications.
[34:04.920 --> 34:11.240]  Well, with the advent of Moore's Law, satellites are becoming smaller and more efficient because
[34:11.240 --> 34:17.240]  their electronics are more efficient. So, one of the challenges in low-Earth orbit is, as you whiz
[34:17.240 --> 34:23.400]  around the Earth every 90 minutes, you really can only downlink your information when you happen to
[34:23.400 --> 34:29.100]  be within sight of a ground station. And any one ground station, you're only in sight of between
[34:29.100 --> 34:34.740]  5 and 10 minutes. So, you could take a picture, but you might actually end up waiting a half an
[34:34.740 --> 34:42.260]  hour before you can downlink it. Well, that's actually a challenge if you've got very short
[34:42.260 --> 34:47.800]  periods of time to get a lot of data down. And so, increasingly, we're moving into a place where
[34:47.800 --> 34:55.040]  there's more and more computation moving on board and really getting high-quality edge computing so
[34:55.040 --> 35:01.680]  that you can do all the data management, and that minimizes the amount of information that you have
[35:01.680 --> 35:07.620]  to downlink. I'm just going to send you a notification that something has occurred, or I'll send you a
[35:07.620 --> 35:13.140]  highly processed picture of what you're most interested in instead of a giant data stream.
[35:13.140 --> 35:19.000]  Well, that is also going to make it a lot easier for man-in-the-middle attacks.
[35:19.000 --> 35:27.140]  Finally, the most serious problem I think we have in aerospace is complacency. As I said,
[35:27.820 --> 35:34.640]  many people in space think that their systems are not vulnerable to cyber. We have an attitude in
[35:34.640 --> 35:40.580]  aerospace. It's part of our culture and our values to think about safety. Safety is integral from
[35:40.580 --> 35:48.880]  design to test and verification and operations. We just think that way. We are going to have to
[35:48.880 --> 35:55.640]  figure out how to insert cybersecurity and an awareness of that into the values and the culture
[35:55.640 --> 36:02.160]  of aerospace, all the way from the beginning in design and all the way through to operations.
[36:02.160 --> 36:08.780]  I really think we are going to need to do that. Now, fortunately, there's some exciting work being
[36:08.780 --> 36:15.840]  done on cyber-physical systems. One of my favorite demonstrations was in the Information Innovation
[36:15.840 --> 36:23.980]  Office, or I2O, at DARPA when I was there. It's the DARPA High Assurance Cyber Military Systems
[36:23.980 --> 36:31.100]  Program, or HACMS. So the picture you see there is an optionally crewed helicopter called Little
[36:31.100 --> 36:39.100]  Bird, built by Boeing. Now, the HACMS program gave a group of hackers access to the flight data
[36:39.100 --> 36:45.260]  recorder. And within 30 minutes, they had hacked their way into critical systems on the Little
[36:45.260 --> 36:53.140]  Bird, which really surprised everyone. So the HACMS program funded several performers to develop
[36:54.040 --> 37:01.240]  security capability and a secure kernel. So I'm not a software person, but to me, a secure kernel
[37:01.800 --> 37:06.580]  is very much like the distributed architecture that I talked about for the shuttle and station.
[37:06.580 --> 37:13.160]  You have a separation of critical functions, and then you have a high level of restrictions about
[37:13.160 --> 37:18.840]  what information and checks that go on for information that flows in and out of that
[37:18.840 --> 37:26.360]  critical area. This secure kernel was loaded into Little Bird. Those same hackers were given
[37:26.360 --> 37:31.740]  access in the same way, and all they could do was shut down the flight data recorder,
[37:31.740 --> 37:40.240]  not very important, and point the camera. So it is possible to develop secure cyber physical
[37:40.240 --> 37:47.160]  systems. Now, the HACMS program is over, but the System Security Integrated Through Hardware and
[37:47.160 --> 37:53.640]  Firmware program, or SIF, is still active. And those of you who were at DEF CON last year
[37:53.640 --> 38:02.180]  may remember that DARPA, through the SIF program, brought a voting box, a voting computer,
[38:02.540 --> 38:10.540]  to DEF CON to work on the vulnerabilities and challenges of how to protect that hardware system
[38:10.540 --> 38:16.560]  from software exploits. So I have high hopes. There's a lot of really good work going on.
[38:16.560 --> 38:24.080]  I would like to see these best practices and these technologies proliferate into space.
[38:25.440 --> 38:30.200]  So a lot of interesting trends in space that are going to have an impact on this.
[38:30.780 --> 38:37.260]  Some of you may be familiar with some of these proliferated low-earth orbit, or PLEO, constellations
[38:37.260 --> 38:44.060]  like Starlink or OneWeb. Now, I talked about low-earth orbit and having to wait until you
[38:44.060 --> 38:50.420]  came over a ground station. Well, the idea here is to have enough satellites which are also
[38:50.420 --> 38:57.380]  connected through cross-links, through a mesh network, such that if one satellite takes a
[38:57.380 --> 39:03.400]  picture, it can send the information through the mesh network to another satellite that's over a
[39:03.400 --> 39:10.980]  ground station. And so this would greatly increase the persistence and, in fact, make
[39:11.960 --> 39:17.060]  data ubiquitous at any time. Now, there's some real challenges with mesh networking.
[39:18.800 --> 39:25.560]  So the Space Defense Agency is working on that right now. I think you're going to see a lot
[39:25.560 --> 39:31.120]  more of these cross-links and these mesh networks, which, of course, will increase the attack vectors
[39:31.120 --> 39:39.040]  as well. NASA's working on going to the Moon and on to Mars. Their Moon-to-Mars program
[39:39.760 --> 39:46.080]  is a program that, just like the Space Station, they've reached out to international partners. So
[39:46.080 --> 39:52.880]  far, Europe, Japan, Canada, and Australia have all expressed interest in joining in going to the Moon
[39:52.880 --> 39:59.900]  to prepare and develop the technologies that will allow us to go on to Mars. And there will be an
[39:59.900 --> 40:06.780]  orbiting logistics platform called Gateway in lunar orbit. And then, not too different from
[40:06.780 --> 40:13.480]  the International Space Station, a Moon village made up of different elements that different
[40:13.480 --> 40:19.630]  countries have doing whatever science they're most interested in, but having shared infrastructure.
[40:21.900 --> 40:27.440]  As we push out into the solar system, we're going to need a lot more logistics hubs.
[40:27.440 --> 40:34.320]  So the most efficient way to get from point A to point B in space is through careful transfers
[40:34.320 --> 40:41.440]  of orbits. Low Earth orbit to geosynchronous orbit. Geosynchronous orbit to lunar orbit.
[40:41.440 --> 40:49.240]  Geosynchronous orbit to Mars orbit. And you're going to see these logistics hubs that allow us
[40:49.240 --> 40:59.440]  to refuel or even build new satellites, store and supply logistics, and transfer not just
[41:00.320 --> 41:05.820]  data, but also goods and supplies out into the solar system.
[41:06.540 --> 41:12.100]  NASA's already thinking about solar system internet, but there's a big challenge with that.
[41:12.620 --> 41:20.280]  Communications is done through RF. And what that means is it's prone to blockouts and fading. Now,
[41:20.280 --> 41:27.180]  the way internet protocol works today is a packet that cannot show that it has connection all the
[41:27.180 --> 41:32.940]  way to its destination never gets sent. Well, you can't have that in space because you're going to
[41:32.940 --> 41:38.580]  have these blockages, this fading of signal periodically. So NASA has been working on
[41:38.580 --> 41:47.720]  delay-tolerant networking that allows data to be cached as it pushes out. And so that way,
[41:47.720 --> 41:53.560]  if there is a loss of signal, that's fine. It can tolerate microseconds up to seconds
[41:53.560 --> 42:00.540]  and then pass along the information once the network is re-established. Interestingly,
[42:00.540 --> 42:06.360]  this has implications as well. DARPA has also been working on it for disruption-tolerant
[42:06.360 --> 42:14.700]  networking, and that's more for emergencies, disasters, humanitarian disasters, and things
[42:14.700 --> 42:20.380]  like that where there's not a consistent capability for the internet. And so
[42:21.900 --> 42:28.200]  delay or disruption-tolerant networking is going to be incredibly important as we develop
[42:28.460 --> 42:38.260]  a solar system internet. So I just want to say how wonderful it is to be here,
[42:38.260 --> 42:43.660]  and thanks for inviting me to participate at the Aerospace Village. I'm very excited about
[42:43.660 --> 42:49.520]  HACCASAT. I think it's a really great idea. It's a way to get insight into what the actual
[42:49.520 --> 42:55.700]  vulnerabilities are, just like we did the demonstration for HACCAMS. But it's important
[42:55.700 --> 43:02.760]  to remember that the implications for space cybersecurity are huge. Even today, I talked
[43:02.760 --> 43:09.740]  about how much of our economy depends on GPS, weather, and so many other pieces of data that
[43:09.740 --> 43:16.000]  we get from space. But there are bigger implications as we build out a solar system internet.
[43:16.000 --> 43:23.080]  We're really going to have the opportunity to completely think this through again and go on to
[43:23.080 --> 43:29.580]  internet 2.0 technologies, like delay-tolerant networking, and build in security from the
[43:29.580 --> 43:37.560]  beginning, which is something that we didn't do with internet 1.0. So I'm hopeful that someone
[43:37.560 --> 43:44.400]  out there that's listening today will have some ideas about how to build a more secure
[43:44.400 --> 43:50.080]  internet for the solar system. And I'm just going to ask you to get cracking on that. Thank you.