[MUSIC] There are somewhere around 10,000 active satellites, give or take, orbiting the Earth right now. As we increase the cadence of launches into space, there is improving awareness in the space industry of the increasing number and complexity of cybersecurity threats that space systems face. And the vulnerabilities introduced by those threats start much earlier in the development process than you might expect. So when or where or how exactly in the development process, good companies making spacecraft or space systems start the process to make those systems more cyber secure? Well, we are about to tackle that right here and now. [MUSIC] Welcome to T-minus Deep Space from N2K Networks. I'm Maria Varmazis. Our guest today is Brandon Karpf, friend of the show, founder of T-minus Space Daily, my former boss, and a cybersecurity expert. It is always a fascinating conversation when we have Brandon on the show, so let's get into it. [MUSIC] The thesis I think we're gonna be dissecting is why integrated GRC and DevSecOps is non-negotiable for space startups. Let's start up first with what the heck does that mean? We've got a bunch of acronyms in there, so let's define everything. Let's start with GRC. Hopefully our audience knows a bit about what that is, but in case they don't, let's catch them up to speed. >> Yeah, sure. So GRC governance, risk, and compliance. Essentially, it's ensuring that your business operations, your technology, and what you're providing adheres to regulations and legal frameworks that you are subject to. So this industry, probably the first one folks think about is the FAA rules. The Part 450 for launch licenses. Another one that most companies in this industry are subject to is ITAR and EAR regulations, so those are the export regulations. The other ones, since so much of this industry is still government oriented, especially DOD, Department of Defense oriented. CMMC, the Cybersecurity Maturity Model Certification, is oftentimes relevant. FedRAMP, which has to do with cloud systems. There's a whole set of these. But essentially, these are rules under regulations that you have to adhere to for your business operations, your technologies, your internal security practices, etc. >> Yeah, that is an acronym. Again, I would think a lot of our audience probably knows, but it's good to always identify what these mean. DevSecOps though, coming from cybersecurity, we know this is a phrase we've been hearing for ten years, but I don't know how familiar people are in space with this one. So let's talk about what that is. >> Yeah, so to define DevSecOps, we probably should define DevOps. >> Yes, indeed. >> Most folks are familiar with software development, and they think they know what software development is in software engineering. DevOps is kind of like the back end of software engineering. DevOps is how you actually take what your software developers have created and get it ready to deploy to a production environment. So this is like streamlining code to launch. Think of it kind of like a countdown sequence for a space launch. It is what are the steps that we go through to do unit testing, integration testing, end-to-end testing on the code, and get it fully integrated into our other code base so we can deploy it into a production environment without destroying things accidentally or creating vulnerabilities or what have you. The classic example folks would be familiar with when this goes wrong is the CrowdStrike issue last summer that they deployed a software patch, ended up creating a null pointer and memory, and essentially crashed every device running CrowdStrike. That's when DevOps fails. DevSecOps is integrating security into that pipeline, and integrating security capabilities into your DevOps pipeline. And again, this is very administrative. It's like, what are the tests? What are the unit tests, the integration tests, the security tests, the compliance tests that we need to go through with our code base before we deploy this software to production? And it's a critical function of everyone who's building technology. Yeah, and so DevSecOps, putting on my old old hat, I remember 10 something years ago, this was a really hot topic, and it has been since. And I think some of the discussion at that time was, okay, what does that mean on the ground? But also, who owns that? My question to you is sort of, is that a singular role? Is that something that's integrated into everyone's job? Like what does that mean? I mean, especially for a space startup, which is presumably running really lean, like really, really lean. How does that fit into what they're trying to do? Yeah, that's, I like that framing. I see DevSecOps and specifically the integration of GRC into this as a business strategy. And there are multiple steps where different functions integrate. I mean, the concept is like, these are your pre-flight system checks. You have to do these. And in fact, when we talk about the regulations and controls, Part 450 does require certain software reliability checks. And you have to actually attest to some of these things. So it's a critical function for your business operations, for your sales. It's a critical function for your IT development. Typically, DevOps is owned by the engineering part of your organization, the IT group. The CTO is typically the one who's managing that and delivering those capabilities and ensuring that everyone is following the proper testing protocols, the proper checks, et cetera. Integrating GRC into this, this is a little more complicated because now you have to talk about maybe bringing in outside experts, your general counsel, what regulations and controls are we subjected to. And actually having a conversation between the CEO, the CTO, your counsel, and how you incorporate those functions into your DevOps process. That's a little more complicated. The reason I proposed this, and I'm going to tell a little anecdote, last time I was on this podcast, I talked about the acceleration of software delivery and some of these new frameworks coming up through DOD and the Space Force that are supposed to enable speed to deployment, speed to deploy software. Well, a few weeks later, I was getting lunch with an old friend of mine. He actually used to be a sailor of mine in the Navy. He works now for a company called Hunter Strategy. And Hunter Strategy is like a classic IT development shop. They do some managed service work. They do some pen testing work. They primarily, in the government, work with DISA, the Defense Information Systems Agency, who's essentially the ISP for the Department of Defense. And we were chatting, and he was saying that they've recently, just in the last couple of months, started seeing unattributed inbound from space companies, like from space startups to their company. And what they do is they do a lot of GRC work with DevOps and security. And so we were kind of ideating about why is they're starting to be demand. And I think it does relate to what we were talking about even last time, which is the acceleration of software deployment. Mixed with the complexity of these regulations. We're talking about ITAR, EAR, the FAA rules, CMMC, and these companies recognizing that they cannot bolt GRC on at the end. They cannot do GRC as a policy, just a policy for the organization. If they're building software, building technology, they need to incorporate GRC in their software development, in their technology development pipelines. And no one really knows how to do that well, so they're starting to look at ways to outsource that. And hence, my buddy Hunter Strategy was saying, they think that this is a potential opportunity, but also an area that companies need to think about for their own competitive strategy and competitive advantage. Yeah, that's an encouraging sign of some maturity in the market, that people are hearing this message that if you think for efficiency sake, you can skip over that or maybe hand wave it until later, you're just shooting yourself on the foot because it will slow you down, even though you may think you're gaining speed, it's not going to help you in the long term. Well, and every engineering organization will tell you, anywhere from a third to a half of an engineer's time is spent on DevOps. That's not writing new code. That is writing tests for code, deploying the tests, the testing automation, doing code checks, code reviews. I mean, a significant portion of your engineer's time is spent on DevOps. So when we talk about integrating GRC, integrating security, there's some concern about taking even more of their time. But people who are doing this really well, right, people who are doing this really well are putting a lot of automation into it. So there's opportunities there as well. I was, you know, before this, I looked up some stats. Lockheed Martin, they released a report with GitLab recently, where they were able to cut system maintenance by 90% by integrating DevSecOps with automation tools like GitLab in their process. So they were able to cut system maintenance by 90%. That's a pretty significant gain in return. And now they're delivering code to production every six days. So that's massively accelerated. Yeah. We will be right back. I'm trying to think. Someone, maybe the engineering team, I'm going on hypotheticals. They're going, yes, we need this. Yes, we want this. But they're encountering internal resistance, maybe, or maybe it's the other way around. What would that internal resistance look like? What would you anticipate seeing? Maybe it's engineers. You don't want to, I don't know. I'm just. Yeah. I mean, in general, engineers are always going to be skeptical about more requirements, mostly because they are test saturated. They're overloaded. That's a challenge. So focusing, if there's a desire, and I think that there, I think there's a need, and we could talk about some of the finds that have come out from the FAA, and others like BIS around ITAR finds, pretty significant finds. We'll just talk about SpaceX got fine with over $600,000 for having an unlicensed facility for one of their recent launches. SpaceX can probably afford $600,000. My startup definitely can't. Right. I was going to say, they are the exception on that. 600K is a large amount of money for pretty much everybody else. For everybody else, right. That's an unplanned fine. You're not going to plan for that outlay of capital. That's a significant amount of capital. Their facility was unlicensed. Right? Now, I don't think it was unlicensed because of software issues, but your software, your security, the validity of your software security is part of the FAA license. So you could be subject to that level of a fine, and every violation is a $300,000 fine. I don't know many startups who can afford that. Maybe once, certainly not twice. Same thing with ITAR, very similar. Every export violation, we're talking about low to mid six figures per violation. These are significant fines. So if you're doing something in your software base, if you're pushing to a public repo for some reason, or there's a potential leak of your software, if you haven't integrated those security checks and those process checks into your DevOps pipeline, you could be subject to those fines. And those fines, again, are material to an early company. So I think there's a major risk to those companies by not integrating GRC in their DevSecOps pipeline and thinking about how to automate those things. The objection is this is more task. We're already spending 30 to 50% of our time on DevOps and DevSecOps. We don't have time to review all these regulations and requirements. And this is where I would encourage folks to look at automation tools, look at efficiency tools, look at those reports, the one I mentioned from Lockheed and GitLab, and figure out and talk to your service providers and figure out how folks are automating these systems because there are ways to do automated checks. Most of these testing frameworks now, when we talk about, for example, security testing, there's static analysis, dynamic analysis, software composition, and there's multiple different stages of security testing that are almost all automated. There are these automated frameworks, Google Test Framework, the Python framework, that can go through those tests. The same thing exists for compliance checks. So it's starting to incorporate those, so it's not taking more time from an engineer, but it is a standard part of the DevSecOps pipeline and workflow. Yeah, so it's not as heavy a lift as people maybe might have anticipated because things have gotten easier on that front. I have an off-the-wall question that may not even be relevant, but I just can't help but wonder if what you are building uses a lot of commercial off-the-shelf parts. Does that introduce any kind of friction here? Is that even irrelevant to what we're talking about? Oh, totally. Without a doubt. I mean, you're talking supply chain, right? And supply chain is a critical aspect of any security program and any DevOps program. In the software process, this comes in with open-source repositories and wanting to have a system that manages your software bill of materials. This is actually doing artifact management, so scanning your code base. And again, there's automated tools that do all of this. Build this into your DevOps pipeline of understanding your code dependencies, understanding who's working on what. There's a DOD system called Platform One. Platform One is a DOD initiative that provides DevOps tools and their approved DevOps environments. It's supposed to accelerate your compliance and your ability to get CMMC compliance, your ability to get FedRAMP, et cetera for the DOD. Platform One has a whole bunch of tools that do this. I'm not going to recommend one over another for your software bills of material and your artifact management, but there are tools that do this. And that's critical if you're using open-source. It's critical if you're using commercial off-the-shelf technologies. I will say there's not a single engineering software development shop in the world that I know of that is not using open-source tools in their development. So everyone is doing this. Everyone's using this, especially if you're using a higher level language like Python. Almost everyone just pulls libraries and uses whatever functions in there. If you've got a shop doing lower-level programming, they might have fewer dependencies, but it's a critical aspect of artifact management that you have to incorporate. You have to understand that if you're going to actually do DevOps well. This is actually a relatively solved problem that most folks just don't approach because they think it's more complicated than it actually is. But it's automatable for sure. And I would suggest people look at DoD Platform 1 for the set of pre-approved tools because if you're going to go get a DoD certification or try to get an ATO and authorization to operate in a DoD network, using those pre-approved tools will just accelerate your timeline. It'll make it go faster. You'll get compliance faster. You'll get certification faster. It'll be a good business strategy to adopt those tools up front. And that's what everybody wants. So that is the goal. So yeah, in this way, we can benefit from the maturity of the DevSecOps environment that's been building the last decade or so. So yeah, we don't have to homebrew all the solutions. Many of them already exist, and you can automate them much more easily than perhaps not that long ago. So take a look into it. And in every heavily regulated environment, which space is definitely one of them, having these systems in place and then layering in your automated workflows, layering in a policy that says what tests every part of your software, every part of your technology will go through, documenting that. We'll doing that up front, it's not that big of a lift for a startup. I'm building my company right now, and we're integrating all of this right now. And we have very few resources, but it's worth it because when it comes time to get an ATO, when it comes time to get CMMC, when it comes time to get FedRAMP, when it comes time to do your ITAR work and your EIA, like all of that work is made more efficient. And these tools, it's going to save you time, and it's going to save you money in the long run. [Music] That's it for Team Ina's Deep Space, brought to you by N2K Cyberwire. 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 ensures we deliver the information that keeps you a step ahead in the rapidly changing space industry. N2K's senior producer is Alice Carruth. Our producer is Liz Stokes. We're mixed by Elliot Peltzman and Tre Hester, with original music by Elliot Peltzman. Our executive producer is Jennifer Eiben. Peter Kilpe is our publisher, and I am your host, Maria Varmazos. Thanks for listening. We'll see you next time. [Music]
