01:50 The Defense Community Gets Cutting Edge Invention

Eric: Today, we have Enrique Oti, the Chief Technology Officer from Second Front Systems. A company focused on providing accelerated access to emerging dual-use technology being developed by VC backed companies out there.

Eric: Enrique comes from the military 23 year career with the United States Air Force, co-founder of the DIU. Some of us may know it as the Defense Innovation Unit out in Silicon Valley. He also founded the Kessel Run software development program for the United States Air Force.

Rachael: I was reading a little bit about where you're at today at Second Front Systems. I loved how your company described their focus, bringing together the leaders. Daring to re-imagine how the defense community gets cutting-edge invention into the hands of troops on the front lines. That's serious business and very exciting.

Eric: That's audacious from a goal perspective.

Enrique: Honestly, it's a pretty audacious company, which is one of the reasons I joined it when I left the air force. Two co-founders are both former marines, Mark Butler and Peter Dixon. Based of their experience in the Marine Corps and not having the most advanced technologies available.

Enrique: That's how they started this company. Saying, "Let's figure out how to get the right tech in the hands of the war fighter." So without a submission, of course I signed up like, "I'll find any way I can to do this." I was trying to do it from the other side of the military. Now I tried to do the commercial side.

Take the Hill

Eric: How does it work working with a Marine? My boss is a Marine and sometimes it gets a little dicey. He says, "Take the hill." And I say, "We're talking about cybersecurity here."

Enrique: No. I just have to use smaller words. But beyond that, working with the Marine is easy.

Eric: Sean Berg, that's for you. I did not say it.

Enrique: This is our company every day because we have an army, marines, navy, air force. We don't have any coast guards yet, but we have all the services. It is mostly just ribbing each other during every single call.

Eric: In our global government’s business, which is what I represent, that's exactly what we do. Every single call, we're on each other and it's fun. We all love each other and know it, but it's great. The barbs you hear coming out are HR friendly but great.

Rachael: Speaking of innovation though and this audacious focus of your company. It all comes back to the roots, from your career in the air force. Kessel Run was huge. Would you mind explaining a little bit about that for our listeners who maybe aren't familiar with it?

Enrique: Kessel Run was actually a program that I kicked off with a few of the airmen back in 2016. Actually some of the ideas for coming out probably a year earlier than that. We're trying to figure out how we can bring all these really interesting commercial technologies into the government.

Enrique: What we found out is, we couldn't. The government didn't have the right software. We couldn't integrate, we didn't have the right clouds. There are so many problems. So Kessel Run did not start out as, "Hey, let's build some massive weapon system."

Understand How to Integrate Revolutionaries Inside the System

Enrique: It started out as, why don't we learn how to code ourselves the way the commercial sector does? That way we understand how to integrate stuff down the road. It really just started as an experiment of how the air force code the same way Silicon Valley codes.

Enrique: Within a few weeks of starting off, we were given a task to actually solve a real-world problem. This is the tanker planning tool, which was exciting. It was fun. None of us knew anything about tankers or tanker planning. But when we were given a real-world challenge, we just dove in.

Enrique: Within a few months, we were able to solve it. That was kind of an eye-opener and not just for the air force, but for us as ourselves. People that are building this are going, "Wow, we actually can solve real problems and solve them really quickly." It went from being an experiment and a prototype to saying, "Maybe this is the way we should be doing business."

Eric: Enrique, you're talking about a tanker planning tool. So refueling tankers.

Enrique: Refueling tanker. How do you plan when fighter jets are going in and out of a strike zone? And how do they hook up with the tanker aircraft, get refueled going in and coming out? How do you make that more efficient and more effective?

Eric: The planning on airspace management, linkup management, and the like.

Enrique: Correct. That process was being done on a big whiteboard primarily. Then they'd take the plan that's written on a whiteboard. Run some calculations in Microsoft Excel, see if it worked. If they work, they'd type it into the official program of records saying, "Here's the plan."

05:30Laborious Processes Require Revolutionaries Inside the System

Enrique: That was a really laborious process. Took eight, 10, 12 hours a day. The real problem with that plan is if you had to change something at the last moment. It's really hard to make edits on a whiteboard and do the math for it. You'd have to, in many cases, just start over.

Enrique: That's really where we came in saying, "Could we automate some of these processes? Do all the calculations on the backend? Build software so that not only could they make the plan, but more importantly, they could change the plan. And let the software figure out those second and third order effects?"

Eric: They could war game it and say, "Well, what if we change this variable?" I remember playing harpoon. I'll lose you on this one, but that's okay. I remember playing harpoon back in like the '90s. Having to marry up tankers with F14 Tomcats and aircraft to make sure they could make it home. That was like 386, 286.

Enrique: That is an old-school game. But yes, I also played harpoon. Good times.

Eric: In 2016, Kessel Run actually brings similar type capability. Obviously a little more complex into the battlespace.

Eric: I can see the need for it. Awesome. Didn't think we'd be talking about that today.

Rachael: There’s a note here about some of the lessons you learned about cybersecurity at Kessel Run related to pen-testing. Would love to hear more about that.

Enrique: I'd love to. When we started off, obviously we're trying to figure out how to build software. We just started to look at why it takes the military five, 10 years to get new software into the government? There is a whole issue with that.

The Biggest Hindrance

Enrique: There's a requirement process, contracting process, there is test evaluation. But we saw that the biggest hindrance was actually the security piece. Getting that authority to operate at the end after you've written your software. Sometimes that process took a year, year, and a half, sometimes two years. You had to do a lot of iterations.

Eric: So, wait for the authority to operate.

Enrique: Yes, waiting for the authority to operate.

Eric: You got everything built, you're ready to go. You've got to wait for security.

Enrique: Usually it's about a year. If there's a lot of errors, then also you have to iterate on the security design. Sometimes it'd be more than a year or two years to get towards operating. When we started Kessel Run, that was actually kind of the first thing we tackled. How do we accelerate the authority to operate processes?

Enrique: How do we meet all the standards and the risk management framework, the NIST 800-53? How do you meet all those standards, but do it in code, do it with automated processes, do it with checks? This was the idea of using commercial-style CIC pipelines.

Enrique: Letting those CIC pipelines populate all of your security controls. This was really at the time, I won't say totally revolutionary. We did not come up with this idea. US Digital Services really kind of came up with this idea.

Enrique: NGA was already trying to experiment with this. Paul Puckett, who's over the army now, at the time was at NGA. We worked with him on kind of how we do this. But we're the first to really do it at scale and get that process going really quick, making it really repetitive.

Revolutionaries Inside the System of Traditional Military

Enrique: A huge shout-out also to the team at Hanscom Air Force Base. The program office was the one who implemented this continuous ATO process and made it effective.

Enrique: But when it comes to security, what we found out over time is we put so much effort into securing the code. What we did not do is put as much effort as we should have into securing the actual cloud infrastructure in which we ran the CICB tools. It's one of those things where it's traditional military.

Enrique: We look at those production environments to say, how do we secure that app in production? Yes, we got that. Then we were really focusing on how we make sure the application code itself is secure. What we did to secure some of that underlying cloud architecture. Part of it's like it's relatively new to the government.

Enrique: Like most of the military members we had building and operating these clouds. They had very little experience with cloud architectures. They're used to on-prem data centers. We thought we were okay, we'd contracted out a third-party to do some pen-testing.

Enrique: We had a few of our own security people, and we thought we're good up until the point that we had a professional air force pen testing team, red team come in. They completely poned us. They found so many mistakes, and really what it came down to honestly at the end of the day was lack of automation.

Enrique: We didn't have immutable infrastructure because a lot of the work was not automated. Traditional military, we teach people to be system administrators. We teach them to go in, log into the Linux box, and administer the box.

Convict Changes and Revolutionaries Inside the System

Enrique: What we don't teach is to automate all your tasks so that everything is repeatable every single time. What we had are conflicting changes that you would not imagine you would have, but you did.

Enrique: Because people do things differently at different times. We'd had too many permissions where we allow developers to spin stuff up that wasn't automated on spin ups. It had some open ports, open protocols. It’s a massive learning experience for us.

Enrique: It was embarrassing. It’s a bit demoralizing in many ways, but it's exactly what we needed. That is why pen testing is great. Everybody should do pen testing all the time.

Rachael: I can imagine. That's a huge learning curve, but also very eye-opening. With something like that, as you go through this process, are you finding that you need to start building teams with different skill sets or talents? How do you kind of evolve those capabilities? Then get the team the right experience they need to help evolve with this technology.

Enrique: There are two aspects. There's building the right team and then building the right partnerships outside of the team. I'll start with the partnerships outside of the team first. The first part is understanding why you do pen-testing. Why do you do red teaming?

Enrique: Again, in the traditional military mindset, it's a test, a pen test. You go in there and you write a report and people pass or fail. That's the wrong mentality. The idea of pen testing is pen testing should help you grow your team. It shouldn't be a competition between the red team and the blue team.

11:43A Collaborative Effort

Enrique: It should be a collaborative effort where your red team is fighting things that your blue team can fix. When this first pen test happened, we actually had a situation where some of the results got passed around. You had people all around the air force going, "Oh my gosh, look how horrible their security is."

Enrique: This is showing why everything's wrong with the cloud, which is not the right answer. The right answer should be, "Hey, look, they chose to pen test themselves. They found all these things and they're fixing it." It’s a mindset change with your external partners that not only is pen testing good, but you would do it even more often.

Enrique: You should be very transparent about all those mistakes you find. That's the only way you're going to get better. So what does it mean internally? It means, first of all, you need your own red team.

Enrique: It's not just your red team to do the continuous pen testing. It's your red team to coordinate with external red teams. To make sure that when they're coming in, it's the right mindset, it's the right attitude. It's the idea that they're coming in to find problems so that the blue team can fix it.

Eric: We want you to help us.

Enrique: It should be helping. That was a mindset change. Bottom line on our blue team, we did not have the people that had the experience with cloud security. Again, it's very different from traditional data center security. We had higher-end contractors. We had to send our military members for training. Honestly, at the end of day, the military is still behind.

People With Different Perspectives

Enrique: They’re behind how much of their cyber workforce really understands cloud, AWS, GCP, Azure, and how to secure this.

Eric: We run into that quite a bit and many times. It's either we're all in on the cloud and we don't think about security, or it's too unknown, too risky. We're not going that direction. Or some variant where we'll call the cloud a private cloud or hybrid cloud. It does. We do talk to a lot of people with different perspectives.

Enrique: What you're talking about is the risks there or not. Would like to talk about that. There's a lot of people who view the cloud as riskier than traditional on-prem data centers. I actually disagree. There’s more security if it's done right. What you do have is a shared security model, you have the big cloud vendors. You have the tools being put on top of it that are validated by the community.

Enrique: Plus you have your own team administering and running their portions of cloud. The potential for higher security is there. But the key to it is you have to have people that know what they're doing. You have to automate as much as possible so that you don't have that configuration drift in the development.

Enrique: The idea that the military has a bit of it's too risky to go cloud, therefore we shouldn't. In the long-term, it’s hurting our security even more. We should be jumping all in and training our workforce on how to operate in this new environment.

Eric: I love your perspective where we need a red team to work with the right team to set the right expectations. Because you're trying to learn, you're trying to get better.

Help Us Make the Revolutionaries Inside the System Secure

Eric: You're trying to automate at the same time. That's a very forward-leaning approach really. That is how everybody should be doing it. We want to go to the cloud because of the following reasons. Help us make it secure as we head that direction. How did you get people to join you?

Eric: Like the air force, the military does it this way. It's traditional. I imagine that would be easy for people who could get over the military construct of this is the box, you fit in and do your job. But there are some rebels in the military. I imagine you got some people who are like, "Yes, I want to do it in a modern fashion."

Enrique: Let's see, how did we get people to join? When I got my first team together, which was six airmen when I was still at the defense innovation unit. I was putting into my first team saying, "We're going to build an app." It was really me calling out to my friends, other people, other squadron commanders that I knew.

Enrique: Saying, "Does anybody have an airman that knows how to code?" Because I had no idea what I was doing at the time, to be honest. I knew we wanted to code, I had some ideas about it. But I didn't know the talent I needed or how to do it. So, I just call the people I knew and said, "Give me airmen."

Enrique: I had 47 airmen from around the air force applied to come out to California for six months. I just did an interview process, resume screen, I picked six people. Now did I pick the right six people for the technical standpoint?

Hiring for Personality Versus Skill

Enrique: Probably not. I probably should have had a different mix from a tech standpoint. But more importantly, I picked the right six people from the personality standpoint.

Enrique: That is something that is huge, which is, if you hire for personality, you can always train the skill. If you hire for skill, you may not get the right kind of people.

Enrique: What I needed were people that were willing to take what they knew about military culture. Then use that to inform their decisions, but they should be tracked by that. So, I basically had six people who were very much rebellious against the system, not in a bad way. Kind of in the good way of they'd been in the air force for a while and they just wanted to do something different.

Enrique: For the first cadre, those first six people for the first six months, it was a fantastic mix. As we started growing, we started attracting more of that type of mindset. People who want to rebel against the system, do something different. But then we kind of hit a little bit of a point where we got big enough.

Enrique: The rebellion mindset was actually a little bit detrimental to us. What we really needed was a kind of revolutionary mindset. It is not about rebels breaking against the system. It's about revolutionaries inside the system changing their hearts and minds.

Eric: Changing the system almost.

Enrique: We started off as defense innovation people. They're like, "Well, why are you doing this? Who says you're allowed to do this?" We'd give the kind of arrogant answer, "Oh, well we worked for the secretary of defense." That kind of only goes so far before people get really annoyed by you.

17:46 Where the Revolutions Inside the System Came

Enrique: As we transitioned this into the program office, that's where really the revolutionary mindset came. It said, "Now we're part of a program office. Let's change the hearts and minds of the program leadership, the staff, the security community.

Enrique: Let's bring the rest of the program office and the organization in on what we're doing. Make them part of the team." That's actually how we grew so fast. When I started in 2016, it was myself and six airmen. By the time I left command at the end of April 2020, we had about 1200 people. That's because we ended up absorbing other portions of the program office.

Enrique: Where we decided this program is ripe for a new way of delivering capabilities. Let's kind of bring it into the Kessel Run fold. So when Kessel Run started to kind of air operation, it started with air operation center. But then the core of it really was targeting and GEOINT.

Enrique: It was actually the targeting GEOINT program office that was the first one to really jump all in. Then we added more of the AOC, then we added some F35 work. We added some unit-level command control. Over time, we encouraged and convinced more people that’s the right way to do business and success breeds success

Enrique: The program started growing. We got a lot of very traditional military members in and civilians. When we said, "You know what? We'll send you to training. We will send you to a design school, we'll send you to a coding bootcamp." So you didn't need all these rebels anymore. It was, "This is now just the way we do business. Let's train people to do the job."

The Revolutions Inside the System Changed the Culture

Eric: You really changed the culture. From those six people in that initial startup phase to the way the air force actually develops.

Enrique: Correct. In some ways, I actually think that is it. The biggest success of Kessel Run is not the applications it built. The biggest success of Kessel Run is the culture that it built. You see that in a lot of these other software factories around the air force. Around the department of defense comes out of people that were at Kessel Run.

Enrique: Whether it's section 31, whether it's Space Camp/Platform One, even Black Pearl and navy. A lot of the people stood up to those new efforts. Some of them are absolutely amazing at what they've accomplished. A lot of them had either been full-time in Kessel Run.

Enrique: Or come from TDY to Kessel Run for a few months. Then they went back to their organization and said, "You know what, this is a new way of doing business." So the Kessel Run's big success was the cultural change more than any specific technology or application.

Eric: You really became the innovative development center for the United States Air Force in some ways and training school. Almost, because you're spinning these people off to other places.

Enrique: Very much we became a training school, which part of it was a little detrimental to realize. People would come in for four-six months and then they go off somewhere else and we lose them. We have to train up someone else. But we knew going into it that that model of getting some manpower early on wasn't so great for us.

A Program That Works

Enrique: But it was good for the air force writ large, which in turn helped Kessel Run. It just ends up being a program that actually works out.

Eric: As you're sending these people out, how did you change the air force? Programs accelerated, capabilities accelerated. Did you do any measurements to understand the impact that Kessel Run had in the air force in that four-year window?

Enrique: I know there are some measurements. Off top of my head, I don't have any. A lot of the early measurements we did were more about software delivery timelines. You could look at traditional programs of record that were sending out an update maybe every few years.

Enrique: Really good programs where the government was sending out updates once a year, maybe once every six months. Some of our software applications, we had updates rolling out live to the field. Accredited every few weeks, every few days, in some cases, within a few hours.

Enrique: We definitely needed to look kind of like the DORA metrics of software delivery. We had a lot of measurements on that. There were some measurements on cost savings. Obviously the tanker planning tool was probably the easiest one.

Enrique: There's actual real cost that's associated with fuel efficiencies. Other applications, it's harder to measure the cost efficiencies. But we look at some of the user feedback on customer satisfaction.

Enrique: Honestly, in many cases, that should be the ultimate feedback. Is the customer happier? That planner, that intelligence officer, are they happier using your tool than their other tool? A lot of that's measured by, are they using your tool rather than using PowerPoint and Excel?

The Turnaround Time on Applications

Eric: Or the whiteboard tanker example. I like this better than the whiteboard. I erased it by accident yesterday. We didn't know what to do after that. What do you think the turnaround times on applications came from? We're talking a year plus on ATO. What do you think they came down from if you were betting?

Rachael: Three months, six months.

Eric: I'm going under that. “Price is right” rules. How'd you do that? You take these long ATOs from 12 months plus. What were you able to get them down to?

Enrique: We changed the methodology. Our first ATO took 21 days. It was the first one we did. That was the tanker planning tool. Once we went past that, what ended up happening is, we moved security from the end of the process to beginning of the process. That's what changed everything.

Enrique: You know what you're coding against in terms of standard for security and compliance. You should just have that as part of your software development process. It actually makes every engineer a security engineer which is not the traditional military model.

Enrique: Traditionally, you have your engineers write code. Then it goes up to the security team to check it for the next year. If you view security as being something that everybody's responsible for, you force people to coach or secure standards. Then when the code rules out of the pipeline, it's actually credited by default, that was a radical change.

Enrique: The idea of a continuous authority to operate, which is, if you're using the right processes, the right tools any code that you push that pipeline is secure when it comes out. Now you have code that is coming out.

24:42 A Foundational Insight About the Revolutionaries Inside the System

Enrique: After your assessors take a look at it, you could have something brand new piece of code. Once it's met an initial state, could be accredited within days with the necessity of looking at it. Then every update is just automatically accredited. It doesn't go through another ATO review process.

Eric: We spoke to Derek Weeks in episode 98, I looked it up here on DevSecOps practices. He's in the commercial world and works for Sonatype. They talked about how they release code hourly in some cases. I'm not a developer, but it was the first time I really got a foundational insight into DevSecOps.

Eric: How quickly you can turn things and do it securely. I really think this is some of the future of the security world. We've got to build it in from the beginning, we've got to be nimble and agile. It's got to be fast. He hit on something here. Can you imagine waiting for a year?

Enrique: That's key. It's the speed. If you look at a vulnerability that rolls out, if a vulnerability rolls out and you have to manually log into systems and patch those vulnerabilities, it could be sometimes months or years. The military's had this, where they've had vulnerabilities sitting in the system for months or years.

Enrique: It takes that long to patch and go through machine by machine. If you actually have an excellent DevSecOps environment, and you have immutable code, any configuration code and instructor's code, then if there's a vulnerability, you could literally collapse a cluster.

Enrique: Spin up a new one with a patch installed, you can fix vulnerabilities within hours. Kessel Run has proven that on both infrastructure and on applications.

This Dynamic Industry Requires Evolution and Revolutionaries Inside the System

Enrique: Being able to roll out new code in minutes or hours versus months or years.

Eric: Think about how many applications never even make it to code because of that process and the timeframe. The perceived timeframe. They just stay on the whiteboard or in somebody's notebook. Now you can just, "Hey, we can do that for you. We'll spin it out." "I don't have that much time." "We'll get it out to you next week."

Rachael: That's crazy. I'm always so fascinated to hear you have this dynamic industry. Dynamic technology is constantly evolving, and within the government space, compliance is a big topic. You've said that the air force needed to move away from being compliance-based.

Enrique: Compliance was great initially. The idea of compliance that if everybody does security to a certain standard, then in theory, you're secure. The problem is in execution, when you write compliance policy, it's almost out of date the moment you write it. There are always new changes in technology,there are also vulnerabilities.

Enrique: So you run into two kinds of issues. Number one. If you have a new threat come out, the compliance is not equipped to take care of that new threat. The second thing is, if you have a new technology come out, that’s actually more secure than the previous technology. Compliance in many cases limits, bring on a new technology.

Enrique: It hasn't gone through a multi-year evaluation process. The compliance models actually introduce insecurities to the system. So, the DevSecOps model, and the sec part of that where best practice is encoded in both your underlying infrastructure. It's encoded in your infrastructure developments, encoded in your application development.

New Technologies, New Risks

Enrique: As new technologies come out, as new risks come out, I can just install new configs in my scanning tools to find stuff. I can rewrite my infrastructure and deploy a whole new infrastructure. I can even transition infrastructure from one provider to another.

Enrique: There's so much I can do to mitigate risks if security allows me to operate in a matter of minutes or hours. That kind of security model actually requires security officials who are much more technical. This was also a change that needed to occur in the DOD.

Enrique: We have a lot of security officials who are very good at understanding the policy. Understanding how to meet these intent or the stamps of policy. But they're not as technical as some of the security engineers that are out there. When a security engineer brings them a new idea, trying to convince an accrediting official to change their mindset is sometimes hard.

Eric: It's not on the list, it's not on that checklist. They don't think about risk in that way, they think about compliance is what I've seen.

Enrique: But it's not that they're bad people. They're good people that were trained in a certain way of doing business. There are a few of them. There are definitely some accrediting officials out there especially in the air force. They are risking their necks right now with the type of accreditations they're doing.

Enrique: Because they are trying to ensure that this methodology sticks and takes hold, and understands the right thing to do. But I don't think there's enough of them. There are a few that are just killing it right now. It's awesome, wlling to take risks.

Revolutionaries Inside the System of the Way You Do Things

Eric: Policy says, "Do it this way." By changing the way you do it, you're almost violating policy in some way.

Enrique: That is correct. In many cases on the security side, we need to zero baseline that policy. To actually rewrite the policies is to accept the fact that there's continuous evolution in technical architectures. There's continuous evolution in tooling, and there's continuous evolution in methodology.

Enrique: I'm not saying this is easy, this is hard. But how do you write a policy, which the government loves? How do you write a policy that takes into account variability? But we need to find a way to do that because static policies are actually hurting our security.

Eric: You're almost building some level of compliance upfront in the way you're building the code. They may not see that, but you're really building it in as you build it. As opposed to the STIG checklist or the CCRI type checklist that they go through. To make sure that, okay, did you update this?

Eric: Do you have this configured this way? You're just building it right upfront. So every time you iterate, it's already in there. It gets almost security at the build level, it's just assumed it's in there. It's built-in.

Enrique: The way we're doing it is, we're taking the compliance frameworks like NIST 800-53. We're using a software product that when you enter the type of technologies you're using, it builds out tickets for your backlog.

Enrique: Your actual software development backlog in JIRA or pivotal tracker stuff. Your developers know from day one what they have to complete off the backlog to meet the standards.

30:58 The Great Thing About Being Compliance Based

Enrique: Then as your code goes to that CICB pipeline that Jenkins builds that links into is SonarQubes and Fortifys or their scanning tools. Those scans then inform the software whether you met the standard or not. So yes, it is building in compliance upfront.

Enrique: But there's a great thing about it being compliance-based off of code for some compliance being based off of PDF documents. If we need to change something, if there's a new fault when it comes out, we can go into that compliance software to say, "This is the new standard."

Enrique: Immediately every new piece of software, if they don't meet that standard, they're going to fail their build. It forces everybody to immediately meet the new standards in order to get their next build-out. It's a much more dynamic way of doing security that allows you to keep up with the threats.

Eric: What do you think about sending a bunch of agile developers, more modern developers into the accreditation teams? To help them understand what you're doing and get that comfort level and change policy. I don't know what they want to do.

Enrique: The way we do it is we have the accrediting teams sit with the developers and see how they do the work. This is what we did at Kessel Run. We'd gone to the accrediting officials and we sat them down. They saw how we did the code.

Enrique: The great thing about doing your compliance in the code itself is you can print reports. We can print whatever reports they want to see about what code is compliant with what standards and it's there. It's something they can look at that they're comfortable with.

More Comfortable With the Process

Enrique: As they get more comfortable with those reports, they get more comfortable with the process. At the end of the day, rather than doing security based off of reports. The reports should merely be an output of a secure development process.

Enrique: Honestly, as NIST is moving forward with this compliance's code with our OSS Cal standard, as companies start building towards that compliance's code standard, there'll be more natural for crediting officials to accept this type of variable adaptive compliance.

Eric: This would drive, we're talking government here, but the commercial world, same problems. We've got supply chain issues. We've been talking about Sunburst and everything else. But you could drive the same type of behaviors into more secure code on the product vendor side.

Enrique: That is going to be a huge part of the industry moving forward. Because the Department of Defense really as we stood Kessel Run, its platform one. All these other organizations that are moving towards DevSecOps.

Enrique: A lot of us looked towards the commercial sector for best practices and for security, for the tooling and the processes. The government is starting to adopt it and really going all in adopting it.

Enrique: What's interesting is, as you look back at the commercial sector kind of with this new lens on, you realize even though these tools come from the commercial sector, there's a lot of commercial companies that don't follow them.

Enrique: Even though some commercial companies do and kind of set the standard. The majority of these companies, especially ones that are supplying to the federal government, aren’t meeting these types of development standards, these methodologies, these processes.

Secure Software Development

Enrique: In many ways, it's incumbent on the federal government to help these companies. Especially those who are doing government work to help them with secure software development. Help them with securing their company, help them with securing their products.

Enrique: Because if not, government money is just going to these companies. It's being siphoned out the back door by the Chinese Communist Party or by the Russians or by the Iranians. Even before the product ever gets in the hands of the federal government.

Enrique: The government needs to help these processes that we've learned. I'm not with the federal government anymore, but with my federal government hat on. These processes, we look at the federal government, we need to help push it back out to industry for these small and medium-sized businesses that are supplying the federal government.

Eric: Which is interesting because I'm trying to think back to CMMC. It’s one of the biggest modern initiatives. I'm trying to think back through it around DevSecOps, secure development, anything on the development side. It's really more compliance-driven. Are you doing cybersecurity, are you doing this? What are your policies? How are you structured? Maybe that's an angle for the CMMC teams.

Enrique: There was a little bit of CMMC that covered the software development portion. But the part that CMMC is really missing is the continuous monitoring. As we went down, in the air force it’s continuous ATO and rapid ATO. One of the things we looked at is you have to be able to do red teaming. And you have built to do continuous monitoring, which traditional ATO processes don't have.

Continuous Monitoring of the Revolutionaries Inside the System

Enrique: Traditional ATOs, you scan your software once, it's good. Maybe two years later, you scan it again. We kind of went down this crossroad. You had to continuously monitor and have this kind of authority to operate. CMMC is kind of in the same boat. You fill out the paperwork, you get a third-party credit official look and say, "Yep, you're good to go."

Enrique: But what you don't have is continuous monitoring of the company's infrastructure. You don't have a continuous red teaming of that company's networks to see. First of all, if they really are meeting the standards. And as things change, are they going to continue to meet those standards? That's where CMMC needs to go to be true active security rather than merely compliance-based.

Eric: Baby steps. Let's say you're like Forcepoint, you're building a software product. I don't think CMMC really looks at how you're writing code, how you're protecting it. Protecting it, securing the networks and the endpoints and everything. But really not getting into how you're developing code. Ensuring you're encrypting passwords and simple things like that from a developer's perspective.

Enrique: There are a few things in there that look at that. It's not as much, it's more about how you secure your company. Obviously, you look at this whole win hack and the exploit against that environment. That was not an exploit of the tool in production.

Enrique: That’s a supply chain attack on exposed services as part of their software development process. That is a real issue. In theory, if people implement CMMC to the absolute perfect extent, maybe some of that's mitigated. But then, no one ever knows because it's a paperwork drill.

There’s No Active Scanning

Enrique: There's no real active scanning continuously to see if somebody misconfigured something. See if there's some configuration drift. That's where we're really hurting as the federal government. It’s our ability to help these companies that honestly can't afford to implement really expensive security. How do you help them implement security if we're trying to use their products?

Eric: You've got to build it in, almost needs to be a way of life.

Rachael: A lot of big challenges have been raised. I love that you keep coming back to the red team's continuous monitoring. How are we going to get ahead when we look at supply chain in general? That's a really big, hard problem that we need to solve, particularly for the government supply chain.

Rachael: When you have these smaller organizations, they just don't have the money to build all these extravagant security systems that really make them more secure. With your experience in innovation and invention in the next five years, what do you see happening here for us to start getting a handle on this?

Enrique: There are a couple of things. First of all, I will plug my own company, Second Front. We are actually looking to roll out a product that will help with some of this more active security, monitoring, and software development. For these small and medium-sized businesses that are trying to work with the federal government.

Enrique: We think they need help. The federal government needs to be secure. But for them to be secured, these companies that are providing products need to be secured in how they develop. We were actually trying to target that specific niche market by saying, "We can help them do software development better."

35:00What Needs To Be Done First

Enrique: "We can help with their active security so the federal government is getting good quality software." But that in and of itself is not enough. The supply chain is too vast and too complex. What needs to be done first is being able to map that supply chain. There is very little understanding of the real supply chain for technologies inside the federal government.

Enrique: Especially as you start talking about the hardware side. Now you're starting to go beyond software when you start talking about embedded processors. Where are the parts coming from, who's designing those parts? We have very little insight in the supply chain.

Enrique: Over the next five years, the federal government needs to invest in this rising group of commercial technologies that are trying to understand and automate supply chain analytics.

Enrique: The federal government needs to invest in that. Not just as a customer, but as an actual R&D investor. To make sure those technologies are detailed enough to understand the risks. Especially when you talk about nation-state risks from Russia and China.

Rachael: It's a big task, but it's one that absolutely needs to try to move forward. But, it's exciting to think of as particular with the work that you're doing. As you start training new folks bringing diverse thoughts into this industry. It's exciting to think of what's coming next.

Rachael: Who's going to have this really ingenious idea, maybe, that kind of revolutionizes things and simplifies it? It's a much easier path forward versus right now. It seems like a very huge rock we're trying to push uphill to get there. But that's why I love cyber. It's so exciting.

One Last Call

Enrique: I love cyber too. So, I'll make one last call on that. It's actually not about who comes up with this next big idea, it's who can adopt it. It's less about innovation and more about entrepreneurship, which is that as a new idea comes out, who's going to get it first?

Enrique: Is the Chinese Communist Party going to implement it first? Is the US government going to implement it first? Does the US government even understand the potential impact of this new technology to even think about implementation?

Enrique: That's actually where I'm really excited about it. You're having a whole new crop of people in the federal government who are really thinking about technology adoption. That's what we really need.

Rachael: That's always the tough part. If you've been in technology a long time, you're either too early or too late. The whole thing is to be able to commercialize it and get it out and adopt it. I'm really excited for the path forward. Thank you so much Enrique for the conversation today.

Rachael: Thanks everyone for joining us for this week's episode of To The Point. Be sure to subscribe so you can get a new, fresh episode every week to your inbox. Until next time, take care.

About Our Guest

Enrique Oti

Enrique Oti is the Chief Technology Officer of Second Front Systems, a company focused on providing accelerated access to emerging “dual-use” technology being developed by venture-backed companies in a range of areas, including cybersecurity, advanced analytics, machine learning, and open-source intelligence.

Prior to joining Second Front, Enrique had a 23-year career in the United States Air Force, during which he served in multiple assignments as a cyber warfare officer and China Foreign Area Officer.  Enrique commanded an intelligence support squadron in Korea and was a co-founder of the Defense Innovation Unit in SiliconValley. He founded the Kessel Run software development program, and in his final assignment, he was the commander of Air Force Lifecycle Management Center Detachment-12 (Kessel Run).

Enrique earned a BS in History from the US Air Force Academy, an MS in Strategic Intelligence from the Joint Military Intelligence College, and an MA in International Relations from Zhejiang University in China, where he studied as an Olmsted Scholar.