Adopting Zero Trust
Adopting Zero Trust
Adopting Zero Trust With Nicolas Chaillan: From Policy to DHS
0:00
-44:59

Adopting Zero Trust With Nicolas Chaillan: From Policy to DHS

The uphill battle that pushed US Federal agencies to adopt Zero Trust

Catch this episode on YouTube, Apple, Spotify, or Amazon. PS, you can help bring AZT to SXSW by voting for our panel here.

On January 26, 2022, The White House released a memo labeled Moving the U.S. Government Toward Zero Trust Cybersecurity Principles. In the memo, OMB’s Acting Director Shalanda D. Young detailed how the U.S. federal government planned to adopt Zero Trust principles over the next two years. While that is certainly one of the largest on the record pushes towards Zero Trust, there were stepping stones that led to this point. Case in point, this week’s Adopting Zero Trust guest, Nicolas Chaillan, has seen firsthand what led to this historic move.

Nicolas Chaillan is an Entrepreneur who became a US citizen about six years ago, and immediately joined the DHS where he became the chief architect and special advisor for cyber, leading him to become the first chief software officer for Space Force where he led the shift to DevSecOps for DoD and at the time implementation of Zero Trust. Prior to Space Force, Nic funded 12 tech companies, built more than 187 products, which were then sold across 45 Fortunate 500 companies. Now, in his spare time, Nic produces an ongoing series, In the Nic of Time, where he discusses everything from Zero Trust to cyber and taps into a diverse set of experts.

During his time with the DoD, Nic saw some of the earliest responses to what would be known as Zero Trust. Initially, as with most large ecosystems, the federal three-letter agencies resisted the notion up until there was a turning point. 

“We demonstrated that a small group of people can really make a big change in the behemoth that is the DOD. It's definitely, at the same time, the most rewarding and the most frustrating experience of my life.”

Coming into a space with thousands upon thousands of people and red tape, and making a push for something as significant as network connectivity and access, is vastly different from the private sector where speed is nearly a requirement. For Nic, he answered the call for something bigger and joined the DoD’s mission when an ISIS attack back home in France took the life of a loved one.

“We can be a SpaceX, we can change the way we do business. We can build software in a software-defined universe that's able to move at the crazy IT pace and we can bring people with us, bring new startups with us to get it done and, and grow faster, stronger together as a team and raise awareness to what is so important, and push back on the complacency we talked about.”

The U.S. Federal Government’s Adopting of Zero Trust

Two years. That’s the goal the federal government put in place to achieve an initial maturity level that better supports a hybrid (remote) workforce consisting of more cloud-accessible applications, stronger access management, and of course, the related principles. It is certainly a lofty goal, but Nic feels it’s certainly attainable. During his time with the Air Force and Space Force, it only took Nic’s team 45 days to implement Zero Trust.

“It's a pretty broad engagement with a lot of the most critical duty programs, all the way to nuclear weapons, to jets and bombs and, and space systems. And we build it in 45 days. We built that as a real Zero Trust enforcement stack. That's not just using the gimmick buzzwords of some companies and really kind of bringing a turnkey Zero Trust engagement.”

Today, there is no doubt confusion around the concept of Zero Trust, but half a decade ago, it was less monopolized by security technology vendors, and the most prominent voice was tied to Google. During Nic’s time with DHS, they were implementing their own BeyondCorp software-defined parameter concept, where much of his approach stems from.

Zero Trust Buy-in at a Massive Scale

Unfortunately, regardless of the initial successful build, the DoD decided not to move forward with the same approach and instead handed off the next implementation to a well-established federal contractor. It was during this time that the implementation moved from what was supposed to be a six-month engagement but spanned more than two years in total instead.

“I did a pretty good job at explaining things to leaders in a way they actually care and understand. If you go ahead and talk about Netflix to the leaders, they're gonna say, Hey, we're not a freaking video app. Right. But if you go talk about SpaceX, that's gonna better relate. I think how you position things, how you'd explain what you focus on.”

Regardless of the red tape Nic faced, and the federal government now pushing forward with Zero Trust, implementing any new concepts requires buy-in. Unfortunately, when facing a behemoth as large as the federal government, that is not always easy, and for Nic and his team, they were ahead of their time. Much of what Nic shares highlights just how impactful buy-in plays and why there were so many periods of ups and downs. Can one implementation of Zero Trust in a critical area of an organization be applied en mass elsewhere? What if politics and vendor favorability play a role? There are countless components that go into what is essentially a top-down digital transformation. Eventually, Nic felt the situation was beyond reconciliation and elected to move on from his role.

Invest in Your Education

Government bureaucracy aside, Nic still believes in DevSecOps and Zero Trust, and has since moved his attention towards helping people educate themselves. Through his regular LinkedIn live shows and other interviews, he’s helping facilitate the next wave of well-educated IT professionals looking to implement Zero Trust.

“That reminds me of this meme, right, where the CFO says, ‘what if we invest in these people and they end up leaving somewhere else?’ And then the CEO says, ‘well, what if we don't in this state?’ Right, because those people are gonna become obsolete pretty fast. And so investing in people regardless of the contract status and where they're coming from is so important.”

Nic knows all too well the amount of biased content and material available associated with emerging technology and cybersecurity principles, which is where he formed In the Nic of Time so that those in the government and private sector gain a better understanding. But, to compound issues around training and education further, the technology agnostic resources available today are also not exactly easy to understand, either.

“NIST doing a great job and I have a lot of friends at NIST and I love them all, but all of the publications are so complex and so abstracted, and you know it is very tough to really come to a conclusion after reading a lot of these, and it's a lot of content it's a lot to understand.”

Rather, Nic recommends the books The Kill Chain, The Phonix Project, the Unicorn Project, DevOps Handbook, and A Seat at the Table, which will get you in the right mindset to innovate. Nic is also building a 45-segment course, too.

Takeaways From Nic and Neal

  • A decade ago, Iran got into federal systems, but Zero Trust would have prevented lateral movement

  • The days of boots-on-the-ground war is shifting towards cyber, and federal Zero Trust implementation may curb a potentially colossal attack

  • Beuarcacy is the largest hindrance of momentum when pursuing a cybersecurity-driven digital transformation

  • It’s easy to become obsolete in IT and cybersecurity, you need to educate yourself constantly

  • Neutral Zero Trust resources and maturity models are important, but are incredibly complex

Adopting Zero Trust EP 03 Transcript With Nicolas Chaillan

Elliot: thank you for joining us, everyone. As always I'm Elliot with your co-host and the voice of this podcast, Mr. Neil, Dennis. We have an absolutely wonderful guest today who has a probably more experience and more insight into the world of zero trust than most other practitioners that we're gonna be able to get access to for the foreseeable future.

He is absolutely not afraid of sharing's opinion. He has his own series that you can actually catch on LinkedIn live in most cases with if I don't mess this up, it is in the Nick of time. Is that correct? Yep. That in a good time, that's it. Yeah, there we go. And beyond what you're doing today your background is just absolutely astonishing.

You know, I don't wanna speak for you as far as where you were up until today. So with that, I'd just love if you could give us a little brief introduction into who you are, where you've been, and then we'll kind of 

Nic: just go. Yeah, of course. So I'm Nick Shalon. I'm the former chief software officer for the air force and space force.

I, I came from France, as you can tell with my French accent moved here about 12 years ago, became a citizen about six years ago, a month after becoming a citizen I joined DHS. I became the chief architect at DHS and special advisor for cyber. And then I became the first chief software officer for the air force and space force and leading the DevSecOps initiative for all of DoD and implementing, I guess, the largest implementation of the zero trust in the us government that I know of.

My background is in cyber. I funded 12 companies in software, cyber innovation. Built 187 products that we sold to 45 fortune 500. So I guess I'm an entrepreneur now you know, I guess a former government senior official and now back on the commercial site, enjoying Life again.

Elliot: how you put it that way. I've had my brief stint working with on the government contractor side. So I know how this speed of activity works over there, but I'm just kind curious. What was your experience like? Just in general we don't need to go too crazy into it. And why did you decide to pivot away from kind of the entrepreneurial world and you know, work on 

Nic: the three letter?

Well, this started when the, there was the ISIS attacks back in, in France. And you know, I got friend I got targeted and killed. And so that, that was kind of, kind of a wake up call for me to say, Hey, you know, I build a lot of great innovations, you know, Mobile apps, you know, touch table stuff.

I mean, we love pretty cool stuff in banking, healthcare retail, but it never, I guess, something that would be, you know, potentially life altering, you know, so I wanted to make a real difference. So I started DHS and then we we got the, I got the opportunity to go to DOD and that was really much more impactful, I guess, mission and work.

I think the impact I had also in the depart. Of defense was silly lasting and much broader. You know, I think we, we demonstrated that a small group of people can really make a big change in the behemoth that is the DOD. And, you know, I think you know, it's definitely at the same time, the most rewarding and the most frustrat.

Experience of my life. You know, I think it's kind of interesting because, you know, when you run your own companies and you have hundreds of people in 12 countries and you know, it's obviously a lot of stress and it's your money and it's, you know, a lot of work. I think I, I took 47 days of vacation in 17 years or something like that before, before the government.

So clearly you. It's hard work, but I can tell you the stress and the kind of the mission of duty was such a massive undertaking. And, you know, when you start touching jets and bombs and space systems and Ys and you have life at stake, and you know, you starting to realize that we're not doing so.

Against China and that you know, our kids may not have the best chance to win against China in 20 years. That's a pretty big wake up call. And, you know, when I started in India, I had no kids. And then three years after, because I had twins ended up with three kids, all girls and so that's it's also changes your perception and, you know, kind of put a lot more stress on getting things done and kind of.

Finding a little bit the bureaucracy and the complacency that we see, you know, in some of the Pentagon leaders kind of calling China, you know, near peer anniversary. Diminishing some of the innovations that might be the differentiator between winning or losing the next battles. And so for me, it was, you know, very important to, to show that we can move at the pace of relevance.

We can be a SpaceX, we can, you know, we can change the way we do business. We can actually build software in a software defined universe that's able to move at the crazy it pace and that we can. With the defense usual base and we can bring people with us and we can also bring new startups with us to get it done and grow faster, stronger together as a team and kind of raise awareness to what so important and kind of push back on the complacency we talked about.

Yeah. 

Elliot: That is without a doubt again, as I preface a. Monumental background. You know, you have basically seen and done it. All your exposure is still evolving. And the fact that you're able to bring your own conversation out into the world today, I think is gonna be incredibly beneficial. Just to shout out, obviously what you're building.

So folks use that 

Nic: as a resource. Well, you know, it's easier for me because you know, when you succeeded and you made enough money, you don't have to worry about money. It's pretty easy to start saying what you wanna say. And I understand. Many of the great civil and military servant in the government and the Pentagon particularly don't have that luxury.

And so it's, you know, it's up to people like me to be able to do it because if I don't do it, I, you know, there's not many people joining the government with that kind of already you know, kind of money put aside. And so he is just just the right thing to do, you know, Yeah, absolutely. 

Elliot: And I think I don't know how long ago it started, but like with digital services, when I lived in DC, I feel like that part of the world, they were trying to build it that fast acting startup, but obviously being able to trickle that into other agencies another monster in itself.

Being able to recruit folks with your kind of background and bring that kind of insight, I think is exactly the kind of steps they need a balance between. But I'm curious, you know, obviously with the speed of government on the table and they have hopes for adopting some sort of form of zero trust over the next two years.

How and I know there's a loaded question too, so just putting that out there. How attainable do you feel that goal is? Or do you feel it's a little bit too loft. 

Nic: Yeah. So first we built the zero trust implementation for the air force and space fold. That's now used by all the dev sec teams.

And so it's a pretty broad engagement with a lot of the top, you know, create most critical duty programs, all the way to nuclear weapons, to jets and bombs and space system. And we build it in 45 days and we build that as a real zero trust enforcement stack. That's not just using the gimmick buzz worlds of some companies and really kind of bringing a.

Turnkey zero trust engagement. You know, I was part of the team with DHS and Google that created the kind of the beyond cope, initial software defined parameter concept. And so I, I know what it means, you know, because people use zero trust now to have this loaded, meaning that pretty much every cyber up ability would fit into.

And it's just not right. You know, it's pretty well defined if you think about it. And you know, I think that the issue I see is first the DoD decided not to reuse the air force space force work despite the fact that it's the largest implementation and most agnostic, not only cloud agnostic, but environment agnostic, able to run at the edge.

Cloud classified cloud and on weapon systems which is an unheard of in the department. And so they went awarded a contract right to booze and under the premises that, Hey, you know, booze is saying they could do it in six months and get a second option. Right. With a stack that's again, push pushed by a prime where my zero trust team was comprised of eight companies that effectively were not acting as a prime.

The government was a prime integr. And the one doing the architecture and and the implementation and the product owner versus, you know, going to a prime and tell them, Hey, just build me this magical, you know, zero trust stack. And honestly the DISA definition of zero trust is very much bloated and is just to too wide, which makes it even a bigger problem.

But when you look at that engagement, right, not only, it's a single. Which was already full-time more expensive than what we spent in the air force to do the work. But now they're saying that they're now gonna meet the six months timeline and they wanna extend for another 18 months, which obviously is mindboggling to me, you know, first they passed on some of the vendors that supported me in the government on that cloud native access point engagement that we did.

And because they, you know, booth said they could do it in six months and now they're saying, well, you know, we're not gonna go there because and we're not gonna recompete and we're just gonna give an extension of 18 months after a fell six months engagement which initially was like, okay, we're gonna have a second option, but now it's looking more and more you know, one side fits all bloated you know, again, Program that's managed with the wrong expectation of delivery and timing.

You know, I'm all about having second option. I think the department should have a second option. It's great. But when you realize after six months that, you know, it is not even as good as what we put in 45 days for half, for the fourth of the money, you should probably take a step back and wonder if you should treat all that amount of money and treat all the time.

To get to an outcome. That's barely scratching the surface. It's barely doing unclassified zero trust implementation, where we have now the cloud native access point running on all fabric now. So it really makes no sense, right? If time of the essence, why don't we reuse existing enterprise services already nicely be used the largest implementation of zero trust in the government.

And. Egos or incompetence is getting in the way that the people running the show. Funny enough at this at the time were the same people that refused and kind of prevented me or tried to prevent me from building the zero trust stack, telling me that they didn't believe in zero trust Mely you know, a year or two before.

Not to forget we had the zero trust stacked down about, you know, about two years before they even started their MVP. So we were way ahead of the curve, but yet they refused to use it. And they were the same people. Telling us, they don't believe in zero trust. Now they, you know, if you listen to people, they're the world expert in zero trust overnight, you know, it's just , I've been, I've never done it ever which obviously experience is so essential when you're trying to bring something as complex and in, in the most complex and siloed organization on the planet, you wouldn't see anyone do that.

Doesn't make a lot of sense. So 

Neal: quick curiosity question. And from my background perspective, you know, I've been a consultant, but I've also been on the military side of this equation back in the day before zero trust was an official designated term. Were there some key things that you saw.

In particular that we're already part of this growth curve that you just needed to kind of etch into that you see that this is kind of missing within the Booz Allen approach for the greater side of the house. Are they trying to basically rip and replace everything and create something that new for better or for worse?

And if they are where there're things that you thought maybe they could have implemented or maintained as part of that implementation without doing that kind of exhaustive. Ignorance, I guess, for lack of a better 

Nic: term. Yeah. It's definitely a different approach. First it's very much locked into a single company Palo Alto.

But it's also mostly focused on the on some of the aspects of zero trust and it's pretty good. I mean, I'm biased obviously because I have created the other. Stack. And I think it's just not as good but I'm biased you know, we'll move on. But I'm more concerned about tangible outcomes, right?

If it was better, I mean, great. You know, putting in production, compare the outcomes, look at metrics, right? Define proper way to assess it. Compare the cyber poster. I would argue that the text stack is much more solid and less locked in, more options, more diversity of options, more control from the government standpoint, you know, piggybacking on dev SecOps, get ups, use ATO.

They can't even get accredited. They can't even get it running. They can't even get accredited even less on the high side. So if you build something nowadays on the wrong foundation and you're not using dev, you're not using incubate, you're not containerized. You're now using a savvy smash. You're not doing a good job at taking care of non-person entities, which is, you know, a massive chunk of the zero trust engagement.

What we enabled really is beyond just the people side of the house. We also enabled, you know, weapons to talk to each other in a jet seat to abs construct. We you know, we enabled a calf cap up sub event driven zero trust data centricity capability with the elastic on top. So we created stuff that really gives you a data lake with data centricity labeling, which will let us flatten, not just Sacra and secret no phone, but also like potentially top secret fabric all into one, really, you know, kind of labeling things down to the cell level.

So we really did things that could drastically improve. The everyday life of the worldwide, you know, there is 58 secret well networks across the mission partners. This capability would enable to flatten all this to one. Imagine if you have a UK aircraft carrier, they often have, you know, going from the UK to Asia, they would've to swap probably five times of devices to connect to the right SACL network.

It's despicable, you know, it's so dated. It's ridiculous, you know, and not to talk about the us side of the house where you. All these Comant commands having to manage 50 a networks and how to push data across the 58 and adding to burn freaking DVDs. Right. We brought a diode, you know, on Amazon.

We, we connected Amazon Azure backbone. We added stalling and 5g options on top. I mean, you know, we allowed dirty antenna connectivity with the right crypto on top with CSF CFS C and type one crypto. Federated the I cam of NATO partners. I mean, there's just stuff that we would, you know, we're able to do that.

That would be game changing in a situation where China decides to attack Taiwan. And yet, you know, and yet we're not gonna make it the default for something that, that is not even Something you can even touch, you know, it's so are there differences? Sure are, you know, might there be things we could learn and that's actually what I propose.

I say, Hey, let's merge the teams. And instead of you know, reinventing the wheel let's do the Delta, right. And focus on the 5% difference. Right. And it's funny how I, how many times I see teams both on the dev sec side and the zero trust side or the data fabric side. You know, walk away because of 5% of requirements missing to say, I'm gonna just re rebuild the whole thing all to take five years and not even get there.

When the 5% could have been a booster of boosting of funding to the existing team to get it done in a matter of weeks, that's sometimes it's ego, sometimes it's silos. We know we, we also educat. And train the material leaders and the PMs to not depend on enterprise services. There were so many people burned with Jedi.

You know, I remember the Jake, the drone AI center telling me no, you know, they're gonna wait for Jedi and they're not gonna use cloud one, you know, which is the cloud office of the air force space force and with multiple cloud options. Right. And not just one. And we streamlined the ATO of, for cloud enclave in a day versus just what we used to take eight months to a year.

Right. And so they would, they. They would say, we're gonna wait for this Jedi magic solution, which never happened. Right. So they lost, you know, two years and then came back and pretty much begged us to to take them on, on, on cloud one. And we did it under, under few weeks, you know, and and they waited two years of production capability, you know, it's just it just makes no sense.

I mean, if you tell anyone it's common sense, I can't even explain it, you know, it is just what it is. You.

Yeah, there's a lot 

Neal: of, so military background, once again. So you kind of touched on a topic for me from a historical perspective data and transition between solutions, right? It does kind of boggle my mind to think about all the work that we had to do to go from one network to another network.

When the solution now is pretty obvious from an interconnectivity capability to be able to transfer from one tech stack, one classification layer to another as seamless. There were some modicum of improvement there for being able to do certain data DTE type things, but there was always still a layer of implicit trust that had to happen where something had to be vetted a certain way with certain things, certain efforts, all this other stuff.

So the timeliness of what you were doing was always taken out in most cases. Yeah, I mean, from that productivity standpoint, alone, being able to get that efficiency and layer and transition, especially on a carrier or some kind of collection unit. To see. Yeah. I could definitely see benefits and the advantageous nature of what that brings for sure.

And it's unfortunate that it's taking what it is to get there, but 

Nic: yeah. And you know, when you think of the next worlds, right, it's gonna be about timing and ability to make the right decisions and ideally augmented through IML capabilities that, that can effectively ingest more data than the human brain can comprehend and maybe give some insights and advising on, on.

You know, basic decisions. I would also argue it could have saved life. You know, we back in Afghanistan, we bombed that bus. I had a bunch of kids in it and, you know, proper AI basic capabilities would've been able to analyze better the the sat imagine to to proactively see that, Hey, there, kids in this, you know, are you sure that you'll target?

Right. And you would think it's pretty basic stuff. Yeah, we do a pretty good, pretty poor job at this. And you know, it's all about giving the right tools to the leadership and to the world fighter to make the right decisions. And honestly compounding that into a single you know, very well secured and but, well, Built architected stacks.

So that he can really have structured and structured data augmented with AI, do popup events. So you can have a satellite, that's taking a picture of sending an event to the stack, and then you have maybe an AI capability consuming that event and augmenting detecting objects on that imagin and sending back another event with the augmented, you know, IM imagin with a new objects detections on top of.

With coordinates. And then he goes to a C2 stack. That's gonna consume these events and potentially make a decision to fire the tank that's being detected. And then you have a weapon targeting it. You know, it is actually a pretty basic stuff. And we have, we actually demonstrated it during the ABMS OnRamps and we can do this at scale.

But yeah. You know, the department refused to make it the norm. You know, I thought I was the CSO for six months with the joint staff on ABMS and I was pushing Know that jet C to join all main command and control thing that's supposed to connect all the weapons and give all these options.

But yet there is no no wheel from the leadership to start on dating things and you wouldn't see an Amazon right. Use different pop up and different events capabilities, different, you know, these things that needs to be orchestrated just like zero. The fact that you hear this say, Hey, we're not gonna, you know, do an enterprise service really for zero trust because each service can do their own thing and we're just gonna federate it.

Well, it defeat the point of zero trust. If you have different policy enforcement point, you're just gonna trust and whitelist. You know, the Navy policy enforcement point, which may or may not have the same enforcement in the same quality or capability that you have on. On the one we use, then you're just trusting.

And so how is that zero trust? Right? And so it doesn't work. You can federate zero trust tax. It's not an option. And, you know, we already did a very poor job at federating identities across air force, Navy, you know, space force, army and of course, false estate and Navy. And that's actually doable to federate identity.

It's pretty simple to federate identity management. Including all the way to a fifth, 365, but yet they managed to do it in a way that doesn't work. And so you can't see, you know, S of people in the Navy or you can't find them in the address book and it is just broken, you know? And so if they couldn't do it with basic, I cam.

You know, how are they gonna do this with zero trust? It's not gonna happen. You know, it's actually not technically feasible. And all they say in response to that is, oh, we're gonna figure it out when it's time. That's not an answer, you know? They should have mandated it. You know, I told the joint staff, the J six CIO, I to To be very flexible when it comes to a lot of different things like databases and APIs and you know, programming languages and things.

But then when it comes to identity management, when it comes to zero trust, you wanna have one option and be opinionated and force it across the enterprise. If you wanna have a shot at being able to do a secure jazzy too, otherwise it's gonna be. A tobacco is gonna actually be probably the weakest access to DOD networks.

Neal: So it kind of brings me to a anecdote from maybe eight, nine years ago where I think zero trust as a construct done. Right. Would've maybe kept the Navy from getting popped by Iran. I don't know if you remember that or not, but during the whole op Abibi and a bunch of other. Things 20 13, 12 through 14 and a little bit later, Iran was very hot to trot and it was making public news a lot with what was going on.

But it turned out that they had gone into the Navy unclassified solutions. I think it was originally actually through the wr service and then ma through NWR, back into the actual, you know, unclassed network and then mucked around and did what they did for whatever long. Right. But if we think anecdotally what zero trust would bring to bear, and we talk about the connectivity layer, like you mentioned, right?

The speed of doing things for the war fighter, for people like myself, boots on the ground, stuff like that. But more importantly, it's that day to day stuff as well. Just the overall integrity, right? Cause the moment someone like Iran, China, Korea, whoever it is next door neighbor who just decides doesn't like the Marine Corps today gets into that even a UFO U O network.

You know, it calls into question everything up. Right. But from a zero trust, echelon perspective that would've stopped. What Iran did day one, they would've gotten in yeah. Through that network device, wherever it was initially through the exploit that they leveraged, but they wouldn't have pivoted.

Right. I think that's one of the key things I think people need to think about is long term for the military. It's good for interconnectivity and speed of work, but it also just mitigates those low layer. Those low hanging fruit issues that call into and question the overall integrity of the networks you're using to do what you're doing, because you're not worried as worried about some non P T sponsored group from Iran doing something bad or at least being as effective in.

Nic: Right. You know, I would actually argue is borderline criminal that the department is still not already fully implemented behind a full zero trust architecture. I think you know, the goal of. The duty CSO was to get to zero trust across DD by 2027, which by the way, by the time that happens, which of course they're gonna miss the deadline, but even if they did attain it zero trust would probably be obsolete by then.

So that tells you you know, zero trust. I was pushing at DRS almost six years ago all to here, by the way the DHS leadership that zero trust was not the right answer. And of course prevented. And then they ended up getting the CV in the world of the year, because that's what you do when you do a whole bunch of stupid stuff.

And then of course, now he is having his own consulting firm advising people on how to do zero trust. How does that make sense? I don't know, but you tell me, but you know, this is the kind of stuff I've seen. Right. And it's pretty senior leaderships, right. People and. You know, you see the same thing with duty CSO and carrier bureaucrats, right?

That you know, effectively are now embracing it six, seven years too late with timelines that are completely Unacceptable, you know, 20, 27 is five years. You know, we've done a massive list in 45 days. After a year we had countless programs already on, on the C app. And that's a good example.

That is, it is doable to, to move at the right velocity. And we demonstrated that, you know, that a small group of people can kind of, kind of move that behemoth of D O D. Right. But it is just, it just is pointing to when leader already stuck with the, this huge timeline, then of course the rest of the food chain is just gonna have that complacency of lack of urgency instead of you know, being motivated to get it done.

If you start the engagement by saying, Hey, you know, we have until 20, 27, The first, they know that by 2027, the guy is gonna be gone. You know, no one is gonna be there to enforce it. But then also, you know, that gives them way too much time. And then there is a lack of urgency for MVPs.

And then you see what you see with booze, right? With a six months pilot that turns into a two year nonsense and no recom competing the work either. You know, how is that fair to the people, to the company that lost the bid? Because they said, you know, the timeline wouldn't be achievable. No, you're admitting it's not achievable, but you're not recom competing the work.

How does that make any sense? I don't know. Yeah. I think 

Neal: that goes my personal frustrations. One of the many reasons why I'm no longer on that side of the fence. I left the classified world about six years ago, seven years ago. Give or take a few. Lot of little things, but the biggest thing was obviously that bureaucracy layer and I worked at Booz Allen.

Booz Allen is part and parcel. One of the reasons why I have the skill sets I have today to do the things I do outside of the Marine Corps and everything else. But that being said, I was always fortunate enough to work on these very smaller, minimal projects, 30, 40 people contracting out whatever, small scale things.

I did work at F cyber 24th when it was still the 24th. And there was some projects to do some gateway reengineering and rejiggering to kind of consolidate gateways, right. To go from back then. I don't know the numbers, but a large number to a lot less and try to consolidate security entry points for better monitoring, log management, all those fun stuff.

The only thing that happened well, in my opinion, similar to what you're talking about, booze, wasn't the one doing it. It was the actual 24th was doing the project themselves and then obviously putting butts and seats to help with it like myself. So it was a direct military engagement. They went direct to vendors to solicit for inputs, all this other fun stuff.

Same thing happened. It was supposed to be about a six-ish month, four to six month transition from old stack to new stack, shut things down, get there. They got a little happy with some vendors and the vendors talked them into what ended up being about a two year rollout. When everybody sitting in the office was like, no, if you just give us the equipment.

I guarantee you, we can do this in probably two to three months. But the bureaucracy behind it is what slowed everything down. And that was one of the big deciding factors for me to finally step off. It's a government beast. We get people like yourself that understand that this is a 45 day or even a three to four month project.

But then the lobby has come in and say, no, this is a two to six year project. And look at the billions of dollars extra. We're gonna give you for doing this. Probably going a little tangential. 

Nic: My side. No, but I'm not even blaming booze. You know, I think the real blaming is at the government level, right?

Yeah. Booth is just exploiting the system. And honestly they probably won't put the team a on the project because of the fact that they feel like they can get away with team F. And so then you only get the results you get, you know, when they let the government, you know, I had you know, with platform one and the dev secs team, we had the 37 companies on co.

No prime. Right? The government was integrator. I had a government people, Hoy value stream, and no single company was in charge of a single value stream. It was always a mixed team of different companies, which is pretty cool. It's actually the way to do business. And of course we had a process to have key positions, you know, with interviews with me and the team to make sure the contractors would not swap people without approval.

And so we would've the right kind of talent, you know, in that team with I think 280 contractors. And so I, I was doing the interviews and things like that. And the minute I left, I can tell you that they swapped the talent. Like nothing else. And, you know, there was no, no one in the government to, to compare if if the new people were better or not than the existing team.

And that's what happens. Right. That's that's where, you know, training and kind of the, that's why I'm spending so much time on LinkedIn and things, you know, create videos and content to educate people because you always go back to learning. You know, with a crazy pace of it. If you don't spend an hour day to, to learn and you know, not only you're behind you have to catch up, but then you have to keep up.

And so I always tell people like invest in yourself, whether the company or the agencies is giving you time to learn is irrelevant. I mean, for sure, I recommend, you know, I was giving an hour day to my people to learn. I recommend salary you know, agencies to at least give 30 minutes. But and whether it's a contractor or not, doesn't matter, you know, people say, oh, you know, we're paying these contractors.

They should already be good. But the fact is you still don't want them to leave your program. You want them to stay. So you have Good retention of information and you have the right, you know, team structure. So you wanna retain people, but at somehow you don't wanna invest in them. Right? So as that reminds me of this meme, right, where the CFO say, what if we invest in these people and they end up leaving somewhere else.

And then the CEO says, well, what if we don't in this state? Right. Because those people are gonna become pretty obsolete, pretty fast. And so investing in people regardless of the contract status and where they're coming from is so important. And I couldn't really find on biased content, you know, because you look at Amazon and Google and all these providers, they have a lot of learning platforms, and then you have the UDA, me and all these platforms with a lot of content, pretty cheap, or, you know, pretty basic, or, you know, there's not a lot of thought in some of these training.

There's not a lot. Content design for managers and non-technical people as to why all this matters, you know why to pay attention to dev sec digital transformation, all the cyber principles. How do you explain it to people? So they understand more than the buzz world. You know, I did a pretty good job at doing this, and now I hear, you know, the secretary of the air force and others, you know, you use the term container and things where you.

And it's not, you know, talking about shipping containers anymore, you know, so it's pretty cool stuff. But it's all about education and learning and training. And we need, you know, that's why I've been building a lot of this content on LinkedIn and stuff, because I feel like, okay, you know, we need to have people in the government that can understand the stuff.

So at least we're buying the right things the right way with the right contract vehicles, the right process, but also the right enforcement and the right due diligence and the right understanding of velocity and results and things like. So on the 

Neal: note of. Aside from your podcast your presentations, if there was one thing to get someone started day one, what would that recommendation be?

You know, what book, what construct, what vocabulary term to learn to get them down into the rabbit hole. 

Elliot: Yeah. Even frameworks, like what N has put out for comment, any of those kinda activities, especially in the zero trust world away from probably the vendors' definitions and concepts. 

Nic: Yeah. yeah.

And look, NIST doing a great job and I love a lot of friends at NIST and I love them all but all of the publications are complex. And abstracted and you know, it, it is very tough to really come to. After reading a lot of these, and it's a lot of content it's a lot to understand.

And so I don't think anyone would really be able to succeed pretty fast starting there. You know, I think first a is a good step back on like basic understanding of agile. I would argue most of the government still does not understand agile and to be great is not stuff like safe and all these nonsensical you know, certification pay to play nonsense.

It's not. And you know, first I always push, you know, a couple of books, right. I think for the military side, I think clearly someone should take a look at the kill chain, right. Where I think we explain the threat and the, you know, because you have to go back as to why all this matters and why we need to wake up and why this is important.

And, you know, so I think that is so important to, to really have a good grasp of, and then of course you have the more technical stuff. I mean, you know, starting with the. Phoenix project, right? The unicorn project, the DevOps handbook, you know, the seat at the table right. These books are giving you kind of the right mindset as to how to innovate and then, you know, like I said, I release a lot of videos on YouTube and we do the show where we have guests but then, you know, we're releasing this 45 segment course, you know, for different personas, right.

For developers ops guys, because I get like network to engineer, right. That spent 20 years in the government telling me, Hey, you know, my job is getting automated. What am I gonna do? Next. And so I want give them a path to success by the way, with tremendous pay right in site, Royal, BT engineering, you know, devs engineers and all these things.

And so they, you know, I'm creating these courses where we're gonna be able to take someone from there to there and, you know, partnering with the Lin foundation to do the right certification. So they have something tangible out of. Although I'm not a big fan of certification. I think the foundation certifications actually pretty hands on and pretty good, but I'm also doing it for managers because again, I think if you don't have the top cover, we don't have someone that explained things.

And I think I did a pretty good job at this. That's why I got so much momentum in the OD. I did a pretty good job at explaining things to leaders in a way they actually care and understand. If you go ahead and talk about Netflix to the leaders, they're gonna say, Hey, we're not a freaking video app. Right.

But if you go talk about SpaceX and that's gonna better relate. So I think, you know, how you position things, how you'd explain what you focus on. I saw, you know, the very first achieved the officer of D OD was focused on business stuff. And I kept telling that person, Hey, you know, this is not a good idea.

You wanna, you know, we're a mission, a weapon, you know, driven, well fighter driven, organiz. The business stuff is yet to support the world fighter, but it's not the mission. So you should really focus on data around the weapon stuff. And that first person refused until David Burke really came in and took over and really focused on the weapon stuff.

And so I did the same with dev secs, right? We took nav 16 jet and Ruper QMA and service smash on the jet in 45 days on the legacy hardware. And so we demonstrated was doable. We demonstrate you can do it on legacy. Something that used to be running, you know, a D and C now is running you know, potentially Java Python and go, you know, AI ML capabilities on top and different things.

You know, we wanna pick the right use cases to get the momentum and get the data to back it up and get people excited. And so I think that's what we did pretty well. So that's the way, you know, people need to think. How to get started because you need to have the bottom up and the top down support.

Right. Ideally. Right. And so you need to build that and create a momentum. And so a whole video segment that I am I'm recording now is about how to build that momentum with your leadership and all the different tricks I use to do that. And it's kind of 11 different things that I ended up listing to explain to people.

Here's the step by step, you know, kind of thoughts I had when I did. To get where we, we got to pretty quick in, within a year, we had massive traction and massive support from the leadership. Nice. 

Neal: So I got one more thing in my mind here. You mentioned maybe 10, 15 minutes back zero trust today, but not necessarily in five years.

Where do you think structurally, this might go in that concept, I mean that the fundamentals will obviously still be there at a core. But the idea should hopefully agree, grow beyond what it is today into something better, bigger, more capable, more timely. So where do you position that at, in theory in a couple of years from.

Nic: Yeah, I think it's tough to know, but you know, I think the stuff that I see obviously in term of maturity of your adoption of dev sec of zero trust and dev secs which, you know the fact that, for example, we built the cloud native access point on top of platform, one as a dev secs construct to give us the authority to operate so we can release multiple times a day.

All these are foundational enablers to move at a pace of relevance. And the fact that this side is not doing this by definition is already bound to. Because you can't get ever fast enough. And you're just getting behind it just doesn't work. Which is why they're not gonna meet the timelines.

Right. You have to do it until the right constraints and the right setup and the right foundation which is not the case in their case. I, you know, it took me a little bit more time to set up the foundation, but once you have the right foundation, just like a house, right. You don't want to build it on the wrong footprint.

I think data centricity is gonna become. Kind of the real maturity, you know, what we did where we built a polic enforcement point that's agnostic and not acting as a proxy, but was a re reverse proxy. So effectively tools like Kafka and elastic would have pre hook and post hook to go query the P enforcement point, which is a abstracted policia code stack that's effectively separated and decoupled.

So data owner can effectively. Right. The policy is both for assigning labels to data down to the cell level, but then also to assign which user get access to what label and their, what condition, and not just based on the user identity and the role, but also based on the device being used. So if I use a government device versus a personal device, maybe time of the day geofencing, so different kind of rules.

To be able to enforce the assignment in run time of label. So if I use a different device, I don't get access to the same kind of information. And so really getting to that, you know, Chrome jewel of of data centricity, the way we built it of footy across enterprises. And that's what I'm helping a lot of banks and healthcare companies reach out to me and be like, oh, how do we do this?

Right. And it's all based on open source tools and it's, you know, and it's the glue code to put it together is kind of the complexity. So looking at how do we opensource data? How do we streamline that, that deployment process to, to create this kind of data fabric that can that can act as that integration point.

But you know, the key on the policy enforcement point, a lot of people end up using a proxy, which now if you have a proxy between your Kafka and your app or whatever connector, then the native connector of Kafka, and there's 120 connectors of Kafka. They see things and new things.

Now you can't use the connector because the connector is built to talk directly to Kafka, not to your proxy. And so people that do it as a proxy is that's very short-sided and kind of broken architecture. And it's is creating snowflakes. It's creating also bottlenecks and massive lock in, in term of vendor lock.

And so we did it as a R reverse proxy. We did it as a hook. And so Kafka would query the police enforcement point. So you could still talk directly to Kafka, but if we doing the pre and post enforcement to also filter down the data if you have a PI or maybe a secret well to Germany, secret route to France secret, well secret, no phone sell maybe the, what is, you know, secret rail and the, who is CSS CI.

In the same database, same table, but it's done to the cell level. And so the query would filter, filter out those cells. Through the policy enforcement point enforcement and it's policy code, and it's all managing the, get Ray pro and all scalable and, you know, the change management enforcement is done through marriage request and all the good stuff.

And so you remove all the bottlenecks and more importantly, you empower the data owner down to the data owner to, to write these policies through a nice UI. So they don't have to know code and stuff. Right? So all these stuff that we've been building with open police agent and all the community with CNCF and, you know, And Envoy as a re proxy, you know, an as a service smash, all this stuff is a massive enabler for company but you know, the learning to get.

And first even understand what I just said beyond my French accent. But just like really understand it right in term of what it really means and why it matters. I would argue most people don't even know why, what I said matters. If you don't know what it matters and you don't have the maturity of the tech enough yet to see what's coming next and why it's gonna become a problem.

If you don't do. And it's gonna slow down your adoption. It's gonna slow down your integrations because you're creating this proxy snowflakes that now people have to create connectors to, instead of just using the native open source connectors, it's just simple things like that can drastically make a massive difference in your execution.

And that's why you see teams for example. Spend you know, when it comes to I C a in this the first two years is being focused on only 20 applications from the controller office because of compliance requirements. But if that used a more traditional approach, which did a pretty, for one program, they did a pretty good job with this.

I just phase slow because they don't use dev sec. So it's always okay, you don't have the foundation to move fast. Right. So I actually proposed them at no cost to move them to. To the dev sec platform, one stack. So they could actually, you know, have a cont say to you and be able to have a C I C D pipeline and all the good stuff, which they refused of course.

But you know, you would think. If you stop making snowflakes now application trying to connect to the ICAM stack, have to create these snowflakes integration rather than just using what everybody else is doing. And it just slows down the integration aspect and scale aspect of all that stuff.

You know, it is just, you know, we talk about culture. Culture is hard, but the fact is. Tech is so difficult that it makes culture harder because people are afraid of failing and afraid of making the wrong decisions. And so you end up, you know, having the fact that because the technology changed so fast and it's so difficult that makes it so the culture and the fear and the adoption of that change in your brain is even harder.

So people that say, you know, tech is easy and culture is hard. Completely wrong. I can tell you the tech is hard. The culture is hard one, but if you have great tech culture is easier. Okay. But if you dismiss the tech and you just say, it's a culture problem, usually assign, you're not very technical and you just, you know, don't even understand the technical problems to facilitate that option.

So to make it that the culture gets easier over time by streamlining these enterprise services. Right. So that's the way I think. 

Neal: Interesting. I think that's a great spot right there. You know, the more you can bring to bear the right stack, the more you're able to let people be people in the solution and do the jobs that they want to do and need to do.

Makes it more timely, more relevant. And you, hopefully in, like you mentioned your friend who's being automated out, but he's looking for a next echelon. That should be the goal. In my opinion, of most of the things you do in the security stack is to find that person who's down here, give him an opportunity to be here and let a machine do this stuff 

Nic: now, no matter which, by the way, whether you agree or not that you know, things are gonna get automated is gonna get automated regardless.

So it's not like they want, they need your approval. To do it. So you can put your hand in the sand and hope for the best, this gonna happen. Anyways, just like drivers. You know, you look at taxi drivers, you've got truck drivers. The fact whether or not we like it, I can tell you 10 years from now, a lot of it's gonna be fully automated.

We see already happening with self-driving and trucks self-driving. You know, we can pretend it's not gonna happen and complain all along, but the fact is it's gonna happen anyways. 

Neal: Exactly. Exactly. 

Nic: Elliot. 

Elliot: Yeah. All right. So to pull us a little bit out of the deep end, obviously we went really deep into it, but I think for providing context into what you have done in the past and where you're basically educating people today this is like the most behemoth use case for adopting a zero trust and functional elements and cultural elements that lead up to it.

So I think providing that context over to the private sector. And I think we'll just kind of, get closer towards the end of the conversation and obviously we'll continue it on and point people over towards your courses. But for folks who are interested in zero trust tomorrow what is that?

As far as the journey go is it looking into existing frameworks? Is. Chatting with organizations who might have experienced what does a day, one entry point look like for any kinda organiz. 

Nic: Yeah, I made eight minutes, I think, video on YouTube about zero trust. I'm not pushing my content but the fact is if I did it is because I couldn't find anything better.

Okay. That's right. Bias content. But the fact is I did that. But then I, when you look at the publication we posted on the cloud native access point online. So if you look for duty cloud native access point, you're gonna find the whole architecture of GeoTrust and how we are. We architected it.

We have a whole, our video on. Also. So I try to really make all this content widely available. You're not gonna find a place. I know of at least where you can just go and find this stuff. You're gonna find companies, like you said, are pushing their own stuff. The difference with my content first, you know, the videos on YouTube and free.

But two, I'm not pushing a product. You know, I'm not pushing a company, right. Implementation. I'm not pushing one cloud provider. It's very abstracted, very agnostic. So I would argue, I guess it's less biased. Right. But I don't think you would find what you want other than if you're okay, going to a Palo Alto, all these scatter or app gate or whatever, or Google, or, you know, and they all have their own sauce, but it's pushing, you know, their own products.

Right. So take it with a grain of salt, I guess. 

Elliot: absolutely. You know, I think we're kind of getting close to the end of this, but I. You know, the best thing that we're gonna be able to do is obviously point people towards content that you've already produced. You've had a lot of fantastic conversations with people who are relevant to this space.

But at the end of the day, zero trust we just wanna reiterate is not technology. And I think we've definitely hit home on that, in this conversation. But, you know, again, thank you so much for your insight and your conversation. Again, I don't think that we will find people with this level of exposure and being able to navigate through some of the complications that come through a behemoth adoption as this.

So thank you so much for that insight. We really appreciate you sharing your experience with us. Nicholas 

Neal: has been a pleasure. Thanks for going back and forth, sir. Thank 

Nic: you again. No, of course. Anytime. Happy to come back one day.

Discussion about this podcast

Adopting Zero Trust
Adopting Zero Trust
Today, Zero Trust is a fuzzy term with more than a dozen different definitions. Any initial search for Zero Trust leads people to stumble upon technology associated with the concept, but this gives people the wrong impression and sets them off on the wrong foot in their adoption journey. Zero Trust is a concept and framework, not technology.
We are on a mission to give a stronger voice to practitioners and others who have been in these shoes, have begun adopting or implementing a Zero Trust strategy, and to share their experience and insight with peers while not influenced by vendor hype.