Space and politics are still very much intertwined. From policy to funding, it really depends who's in office and what deals can be made. Now SpaceX's founder Elon Musk has been appointed in the new US administration. We shall see how that shakes things up for NASA and the FAA, as if NASA doesn't already have a lot to deal with thanks to budget allocations. Today is November 13th 2024, I'm Alice Cruz and this is T-minus. NASA's JPL announces cuts to the workforce. Rocket Lab announces new contracts for Neutron, Spire Global sells its maritime business. And our guest today is Ivan Novakov, CEO of Hallarm. Ivan will be talking to Maria Valmarzis about APIs in space raising new security concerns. It's definitely worth listening to later in the show. Today's intelligence briefing with some somber news. NASA's Jet Propulsion Lab in California known as JPL has announced that it will be making layoffs. JPL shared the announcement on NASA's website stating, "While we have taken various measures to meet our current fiscal year 2025 budget allocation, we have reached the difficult decision to reduce the JPL workforce through layoffs. This reduction affects approximately 325 of our colleagues and an impact of about 5% of our workforce. These impacts are occurring across technical business and support areas of the lab." The statement went on to say that, "These are painful but necessary adjustments that will enable us to adhere to our budget while continuing our important work for NASA and our nation." All employees were required to work from home today on November 13th, regardless of their telework status. At 9.30am local time, a virtual lab-wide meeting was held to relay the details of what to expect. Our thoughts and best wishes are with those affected by the layoffs. Moving on to some more positive news. Rocket Lab has shared their financial results from the last quarter. The company's revenue grew 55% year on year to $105 million and they continue to see a strong demand growth with a backlog at $1.05 billion. Rocket Lab also used their investor core to announce a multi-launch agreement with a confidential commercial satellite constellation operator for its new medium-lift rocket, Neutron. Under the contract, Rocket Lab will launch two dedicated missions on Neutron starting in mid-2026. They also announced a federal defence contract that supports Neutron and the development of Ozark Medi's engine with the US Air Force Research Lab. Rocket Lab's next launch, the Ice Ice Baby Mission for Kinesis, is scheduled to take off during a 14-day window that opens on November 23rd. Spire Global has announced an agreement to sell its maritime business to Kepler for approximately $241 million. The company says it plans to use the proceeds of the sale to retire all outstanding debt and invest in near-term growth opportunities. Spire will retain its satellite network, technology and infrastructure and will continue to serve its aviation, weather and space services customers, along with the existing US government portion of its maritime customer portfolio. The transaction is expected to close by the first quarter of 2025. Denmark has become the 48th nation to sign the Artemis Accords. A ceremony was held in Copenhagen with Kristina Uglund, Minister of Higher Education and Science, signing the Artemis Accords on behalf of Denmark. Robotics company Gita USA has raised an additional $15.5 million as part of its series B extension round. This follows the $45 million raised in 2023, bringing the total of the series B extension round to $60.5 million. With this additional funding, Gita aims to further advance on-orbit services and lunar infrastructure construction in the US and defence market. Japanese company iSpace has shared its financial results for the second quarter of the fiscal year which ends March 31st 2025. The Tokyo-based company has reported contract agreements totaling $99 million. iSpace also announced that their mission to launch with SpaceX is scheduled for no earlier than January 2025. The company says that preparations for the resilience land are progressing smoothly and that the vehicle will be shipped to Florida on time according to the planned schedule for their launch preparations. Rivada Spaces announced that its secure contracts for their proposed Outernet constellation in 18 countries and on every continent. These countries include the UK, Netherlands, Denmark, Finland, Colombia, Nambia and more are in the pipeline. Rivada also says that it's lined up more than $13.5 billion of business globally for its Leo network and has added 400 MHz of newly available spectrum to its portfolio. CIDUS Space has been selected to design and build the first generation of data storage spacecraft for Lone Star data holdings. CIDUS will be Lone Star's exclusive satellite manufacturing partner for six data storage spacecraft that will orbit the moon, offering advanced data storage and disaster recovery capabilities for mission critical information. CIDUS will manage the design, payload integration, planning and on-orbit support for each of the six satellites. The Space Development Agency has awarded a contract for Advanced Fire Control Ground Infrastructure to support demonstrations and potential future operations under the agency's Advanced Fire Control effort. The cost plus award fee contract, worth a maximum of $170 million, was awarded to CIDUS Technology and Training Solutions. CIDUS will lead a team of industry performers to provide a common, enduring ground infrastructure and resources to minimize cost and complexity for multiple advanced fire control prototype efforts. Initial funding of approximately $17 million was obligated at the time of the award. Sony Space Communications Corporation, known as SSCC and AstroDigital, are partnering to design, manufacture and launch two microsatellites. These satellites will each carry an SSCC optical terminal and will showcase SSCC's optical communications technology by establishing high data rate laser com links with each other as well as with terminals on the Earth. The satellites are expected to be launched in 2026. That concludes today's Intel briefing. As always, you'll find links to further reading on all the stories mentioned in our show notes. Today we've included the announcement of Elon Musk's new position in US politics, an announcement from Viacet and El Tan in Mexico, and another one on NASA's studies on sustainable aircraft. 80 Minus Crew, if you find this podcast useful, please do us a favor and share a five-star rating and a short review in your favorite podcast app. It will help other space professionals like you find the show and join the T-minus crew. Thank you, we really appreciate it. Our host Maria Valmarzis has been in DC this week speaking to sci-fi legend Rondi Moore. We'll be sharing that chat with you later this month, but before her travel, she spoke to Ivan Novikov, CEO of Wallarm, about APIs in space raising new security concerns. What are APIs, I hear you say. Here's Ivan with that explanation. APIs, kind of new wires. Whatever you think about connectivity, 99% of the chances it's driven by APIs. So, API is basically the way how different systems communicate to each other, transfer data. And if you, anytime using mobile app, your mobile app actually rely on APIs. So, API is the way how your mobile app connects to the cloud to get some data and show you the data back in the UX, the same websites. The majority of the websites now using the same approach, where the front end of the website communicates with an API in the back end, similar to bank-to-bank wires, right? It's driven by API or even the data that goes from the Earth to the satellites. So, it's also API. It's basically new wires that connect everything. Now, I feel like we're all up to speed exactly where we need to be there. Okay. So, for folks who are making, I'm going to be very broad strokes here, who are making some kind of spacecraft or working with, and you're facing with some sort of space application in any way, they're using APIs in a number of different ways. Either they are creating them for their application or they are using them or sometimes both. What are the issues that people in the understanding in terms of the security problems that can come up with API use in the context of space? Yeah. So, the first of all, I guess that API is just an interface, right? The term defined very broadly, as I said before, like a new wire and very specific implementation of the, you know, API, such as you mentioned, like in the space area, right? It really depends on like what's there, which data goes there. And I guess the main thing to put as a first thing that you have to, you know, understand while you start developing or building or use APIs is like nothing guaranteed by default. So, having API doesn't mean that any security controls will be delivered by default. And that's crucial. It's very important because when we, you know, like focus on something new, sometimes we assume that some kind of new security control should be also delivered in this new tag because this tag is new, but it's not because it's very broadly defined, you know, in many cases just like the general term and inside the hood, under the hood all the time, you will have some, you know, more and more specific thing that you have to focus on. I'm thinking through some space companies that, I'm not going to name names, but I'm thinking many of them have an API that's very open to the web because they want people to use the data that they're providing from their satellites, for example. I'm trying to think of like examples of what is the direction that we want to give people who are developing APIs for people to access? Or as you said, like not to assume that things are secure, but what do people need to do beyond that? Do they need to, what do they need to do next? I guess the first thing is just to start with the usual application security controls, right, such as, you know, identify who is your customer, who consume the API, right? How you can make sure that your consumer is actually your consumer means authentication, right? And then if you 100% ensure that or some sort of the authentication done, you have to focus on how exactly, you know, which functions this authenticated user can consume means authorization to very specific functions. And then when it's started, you have to make sure that the way how this authenticated and authorized users consume your functions actually your designed way, the way how you design, how you suppose them to use these functions means in many cases abuse or fraud or some other attacks like that. So it's basically kind of like main three things that we have to check. And then the most important part here is you have to design the things while you design your APIs and the way how it will be designed in the future before you actually roll out this to any, any, you know, production things. Otherwise, it just impossible to define that afterwards, right? If you release some API and never require authentication, you have to you have, you know, many users, it just hard for you to step back and tell, hey, no, no, no, now I'm kind of like canceling this and start over. So it's just hard. So that's why this three things should be designed before. And then all the next thing could be kind of like delivered once you will see, I mean, some, some real data, some real use case and some real attacks for sure. Can you give me a sense of the potential risks for a misconfigured or poorly configured or not at all well configured API? So what is that risk if someone, you know, if some, you know, access is wide open in a way that maybe the API provider didn't intend? It's not just that people you don't want can access your data or other things at risk as well? Yeah. So essentially, as I said before, API just direct access to the data. And that's very important because if you have a direct access to the data, then the basically you design API, right, to access your data. So it's not something designed for a different purpose, right, designed for this purpose. If you kind of like miss a few controls such as authentication authorization or, you know, the using kind of like limit and the usage, right, then you have a case when your data became accessible and then if it became accessible from different ways, not designed by you, then it caused some risks could be direct risks such as like your, you know, like private data or sensitive private data got compromised or indirect risk where just like legit users can see some, some more bad over years or over quarters, the data became, you know, like private or very sensitive to you because something changed. So that's that's that's what what basically makes API so unique in terms of this, why it's, you know, not like it was before this this API actually took over as the speed and accessibility. So basically, if we're talking about API, let's say, when I started cyber, it was not a problem to have an issue like security issue for five, 10 minutes, right, we all accept the risk and they tell, hey, five, 10 minutes is probably okay. I can, you know, manage to call someone and someone can, you know, block an access. So it's kind of like acceptable risk five, 10 minutes is not enough nowadays. Even one minute is just enough to download, you know, like couple of gigabytes of data, which is a lot and API makes this even faster because it's designed specifically to get access to your data in a very fast way without any, you know, any barriers in the front. So basically, if you have an issue with your authentication, and you basically don't have any couple of seconds because in 30 seconds, it's possible to download like a gigabit and it's at the gigabyte of data. It's a lot, right. And in many cases, entire user database on an entire, you know, scope of your secrets is basically feeds one gigabyte. Yeah, as you're describing this, I'm thinking national security issues seem to that seems like a very clear use case of where this could be a really big issue. That's a little scary. But also good to know, I mean, knowledge is power. So this is good to know. Yeah, so now that I'm terrified, what is the advice that we want to leave our listeners who are building out these solutions? What do we need them to know in order to lock down their APIs a bit better? Oh, as I said before, security design or security by design is the first thing, right. And then basically this points you to the most important piece of your API landscape or so-called posture. So if you have something that you don't know about, right, such as like APIs that you don't even know about, I mean, automatically it means that you don't have security controls there, otherwise how it's possible, right. So I guess having some kind of like, you know, baseline of an inventory or posture is probably the first thing that you should not think about posture is something, hey, I know that it's deployed, right. You have to think about that as like, do I have secure designs there or not? Which kind of controls were designed, you know, put it into the basement when I start to build it or my team build that or not. And if you don't have an answer, who built that, how it was built, then it's almost equal to you don't have any security there because you cannot rely on any, you know, reasonable feedback. And in many cases, you don't even know an owner or who is now responsible for the particular function, which means you in many cases will see no one responsible for the piece of the data, right, accessible to someone, which is a big concern, big problem. And I guess the while, you know, an entire, you know, world start to consume APIs, like heavily, they realize it's easy to build them, which is another risk factor. When it's something easy to build them, you know, it's hard to secure and hard to maintain, right, because essentially it's a trade-off, right. You if it's something easy, then there is a kind of like the back backside of the same problem, right, that in our case, it's a security. It's easy to build, it's easy to connect data to the API, it's easy to make the data accessible at fast, but it's a lot of security concerns connected to the same, you know, simplicity. We'll be right back. Welcome back and happy new year Mars. Yes, yesterday was a normal midweek here on our planet, but it marked the start of a new year for our neighbouring red planet. How do we know this? Because we, us earthlings, say so. The convention for counting years on the Martian calendar started in 1955, with a major storm named the Great Dust Storm of 1956. This is the 38th Martian year since we started keeping track. You see, a Martian day is called a soul, and it lasts 24 hours and 39 minutes, just slightly longer than an Earth Day. One year on Mars, however, equals 687 Earth days, or 668 souls, nearly twice as long as an Earth year. The Martian new year begins in the Northern Equinox. It's spring in the north and autumn in the south. Yes, Mars has four seasons just like here on Earth, although they don't equal in length due to Mars' elliptical orbit. And if you're now wondering how old you are on Mars, divide your current age by 1.88, and tell your friends just how much younger you are. It sure does feel good to be 21 again. That's it for T-miners for November the 13th, 2024, brought to you by N2K Cyberwire. For additional resources from today's report, check out our show notes at space.n2k.com. We'd love to know what you think of this podcast. You can email us at space@n2k.com, or submit the survey in the show notes. Your feedback, and we really do want it, ensures that we deliver the information that keeps you a step ahead in the rapidly changing space industry. N2K's strategic workforce intelligence optimizes the value of your biggest investment, your people. We make you smarter about your team, while making your team smarter. This episode was mixed by Elliot Peltzman and Trey Hester with original music by Elliot Peltzman. Our executive producer is Jennifer Iben, our executive editor is Brandon Kaaf, Simone Petrella is our president, Peter Kilpie is our publisher, and I'm Alice Carruth. Thanks for listening. [Music] T-minus. [BLANK_AUDIO]
