“Secure by Design” gets thrown around in the cloud a lot, but what do we actually mean by that? And is it even achievable?
Check out this post from Steve Zalewski for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark, the producer of CISO Series, and Edward Contreras, senior evp and CISO, Frost Bank. Joining us is our sponsored guest, sponsored guest, Gal Ordo, co-founder and CPO, Native.
Join the conversation on LinkedIn
Huge thanks to our sponsor, Native
Full Transcript
Intro
0:00.000
[David Spark] “Secure by Design” in the cloud gets thrown around a lot. But what do we actually mean by that? And is it even achievable?
[Voiceover] You’re listening to Defense in Depth.
[David Spark] Welcome to Defense in Depth. My name is David Spark. I’m the producer of the CISO series, and joining me as my co-host, one of our brand-new favorites. He’s been with us for a while. It’s Eddie Contreras, Senior EVP and CISO over at Frost Bank.
Eddie, say hello to the audience.
[Edward Contreras] Hello, audience. And David, thank you for having me back yet again.
[David Spark] We love having you back, and I know the audience does as well. Our sponsor for today’s episode is Native – The Cloud Security Control Plane for the enterprise. We will be talking more about that a little bit later in the show, and we’re going to be talking about that whole topic throughout the show.
But first, let’s set it up, Eddie. For a while, one of the most sought-after skills was cloud security expertise. I mean, I constantly was seeing on job sites. Multi-cloud has become the norm. But as the cloud sprawl continues, and the only way you can maintain security is to have cloud experts for each cloud vendor in your environment.
Is that sustainable, especially given that this is such a highly sought-after school? So is that what we call “secure by design?” What kinds of tools do we have then to count on? What don’t we need, or what do we want? What is it that we need in this environment, and how much we adapt for citizen developers creating code in the cloud?
Eddie, what do you think?
[Edward Contreras] You know, David, this is such a complex topic, and cloud is both simple and complex in the same time, and little have to do with each other, right? When you think about how cloud typically arrives at a location, there’s cost that’s evaluated, there’s capabilities, but the tail of the risk conversation is probably the longest one that there is out there.
So that’s why it’s a hard conversation, which is why this conversation today should be really insightful.
[David Spark] By the way, cloud sold itself to everybody on simplicity, cost benefits, flexibility, and then when you’re in it, the story changes.
[Edward Contreras] Completely true.
[David Spark] All right. Helping us with this conversation is our sponsor guest, who is a co-founder and CPO of Native, none other than Gal Ordo. Gal, thank you so much for joining us.
[Gal Ordo] David, thanks very much for having me. I’m really excited for this.
This problem won’t change on its own.
2:31.634
[David Spark] Nathan Koester of Ironclad said, “As your environment scales, so too do your tools. What works for one environment or component may not scale effectively, or you need truthing and confirmation. This is why at every organization I’ve been at, we have more than one source of truth, and we attempt to normalize to drive our focus.” Wow, that seems distressing.
Chetan Mane of Rajdharma Technology said, “The tooling debate, native versus third party versus hybrid, is often a secondary issue. The real gap is governance clarity. Secure by design in multi-cloud only works when identity is treated as a board-level risk topic, not just an IAM configuration.
Cloud controls are mapped to business risk exposures, not just technical coverage. Hybrid tooling decisions are driven by visibility and accountability, not feature comparison. Most organizations don’t struggle with tools. They struggle with consistent risk translation across AWS, Azure, and Google Cloud into something leadership can actually act on.”
So that last quote from Chetan, Eddie, it sounds like something we’ve heard before. It’s like, “If your processes are a mess, your tools aren’t going to fix it.”
[Edward Contreras] It is, right? And it’s funny, when I started reading the rundown for this, the first person I went to their LinkedIn site was Nathan. I was like, “I have to understand where this person worked. That was a very scary comment about multiple sources of authority.”
But if you unpack what Chetan says here, it’s very common, and I think this is one of the challenges that we run into, where IT leads the strategy versus the business. Because if your technologists are leading strategy, every single comment in here, it’s a point for discussion.
But if the business is leading the strategy, “Okay, well, why do you even want to go to the cloud? Should you be there? What’s the purpose of that?” And if you have that strategy up front, it starts to address these little comments here. But if you don’t, you have to deal with these independently, and you have to deal with them in real time, which is a challenge.
[David Spark] Yeah, that’s a good point. Gal?
[Gal Ordo] Yeah, so I actually love what Eddie just said, and, really, where, I think that cloud security should be focused on, clearly any other branch of security, is that focus on the outcome, not, “I want to achieve that sort of configuration flag or restrict that exposure,” but rather, “I want to make sure that my AI training accounts can never connect to the internet.
I want to make sure that my cloud cannot operate out of Thailand. I want to make sure that my AI agents running wild in the cloud cannot delete any databases without manual approval.”
All of these things are things that security leaders can say in a sentence and relate very closely to their business outcomes. And then, to Chetan’s point comes the point of, “How do we actually do this translation?” And to Eddie’s point, this has to be the starting point, the outcome that you want to achieve, and then you figure out how to achieve that.
Why is everyone so confused?
5:48.154
[David Spark] Heather Hinton, CISO over at Sitecore, said, “Secure by Design and Secure by Operation don’t have the same ‘root process trust’. So root of trust in the effectiveness of the process. “So secure by design’s root of process trust is in the threat modeling.
Secure by operations root of process trust is in the procedures that support secure operations and how those tools are incorporated into those procedures,” kind of like the last quote we got from the last segment.
“So the citizen developer angle makes worse the fact that we don’t have good secure by design, secure by operation, or secure by design is greater, say, than secure by operation,” if you can follow that, “the transition. And we likely aren’t going to do a good job of catching the citizen developer or their output in these disciplines.” So this is just [Inaudible 00:06:48].
We talk about this AI and technology, that if your processes aren’t in place and you’ve got problems, it’ll just amplify those problems.
But last quote here from Venkat Paruchuri, of Deloitte, he poses some questions. “Number one: What does the organization prioritize, simplicity for speed or complexity for innovation? It is much easier to streamline and secure a few architectural and infrastructure patterns and processes than, “We run everything under the sun.” Two: Does your specific domain and associated regulatory mandates force you into a federated model for tech ops, or can you do a hub and spoke?
So, for example, do you need to have localized cloud presence in some geography requiring multi-cloud mess? And lastly, do they care more about resilience over experience and usability? Often security’s hands are tied and our choices aren’t ours to make.”
So this last quote from Venkat and also Heather, I mean, this really talks about… In the setup, Eddie, we were talking about this in terms of like, it started off simple, but then it gets really, really complex. Oh my God, did they set up the complexity here, Gal?
I want to know a little bit of your history, Gal, in that, did you see this mess of complexity when you were starting your business?
[Gal Ordo] All the time. All the time, David. So I actually started the business having worked at AWS before then, and I led one of the security products for AWS, and we started Native because we saw this complexity with customers. We saw how, to my point from earlier on, taking those simple one sentences that you want to implement in your cloud become months and year-long projects for customers.
[David Spark] Can you isolate the complexities that you were seeing at the time?
[Gal Ordo] Yeah, I think a lot of it had to do with the number of tools that were actually in the arsenal that security engineers had, and the fact that they needed to take these outcomes and translate them into technical capabilities. So the easy thing that I said earlier on, making sure that only specific IPs are allowed to access your cloud from the internet, can translate into dozens, if not hundreds, of technical things that you need to enforce across different policy engines.
Just on AWS alone, you can access an environment from the internet for a public link to a database or through a virtual private cloud network, or through a bunch of other mechanisms, and each of those, the enforcement and the way that you manage that connectivity is done differently.
Even after you figure out all of the translation piece, there is also potential impact on existing workloads.
So at this point in time, I’ve not seen… There are very few customers who are starting from scratch in the cloud. There is always something, and then security becomes very concerned about those technical controls that they’re putting in, potentially breaking their environments.
And that’s where Venkat has even spoken about resilience over experience and usability. That’s where security never wants to be that person that breaks production, or that places a policy because of what developers cannot do what they want to do, and then people are coming and shouting at them.
Because of the complexity of the technical tools and because of the potential blast effect, blast radius, there have been a lot of people actually concerned from actually doing security in the cloud, and it became a visibility game rather than a building game.
[David Spark] Very, very good point. All right. Eddie, I want to know your experience because it’s interesting. Nobody goes into a clean environment. It’s so funny. Every time we put up a post about greenfield, people jump on it, they get very excited, because nobody ever gets that.
And going back to the very last comment from Venkat, the choices aren’t ours to make. You get what you were given, right, Eddie?
[Edward Contreras] You do. And I liked how Gal broke that down. If you think about a security person’s career, there is no shorter sentence or a period at the end of the sentence than, “Get in the way of product, get in the way of development, get in the way of the growth of the company.” You have to figure out how to meet the developers where they’re at.
Most companies don’t have one development team. You’re talking double, triple-digit number teams, and so if you make it too complex or too restrictive, you’re going to get an earful. So you have to understand, “Where do I apply my controls? Am I shifting my controls far enough left that their developers can still be innovative, and not have too much restrictions in place?”
So I do think it’s a sweet science how to get there, but you’re right. No one walks into a greenfield and says, “Oh, great, I get to start from scratch.” It’s, “I’ve inherited this. How do I make the best use of it?” And sometimes people come to the conclusion of, “It’s the processes that are complex, not the technology, and you have to figure out how to make them work together.”
Sponsor – Native Security
11:53.398
[David Spark] Who’s our sponsor this week? Our sponsor is Native. We all know that cloud providers ship powerful built-in controls, but most teams struggle to turn security intent into consistent enforcement across AWS, Azure, Google Cloud, and OCI. Different policy models force security teams into manual translation and one-off exceptions, which get brittle fast as accounts, services, APIs, and AI workloads change.
You know, actually, the best quote I heard was from a CISO who said, “I want someone to tell me this security program I had today, six months from now, a year from now, how out of whack is it?” Because that happens.
So Native, though, is the secure by design control plane for cloud security. It helps teams operationalize provider-native enforcement, manage intent centrally, and roll out changes safely at scale.
Native works through the cloud’s own mechanisms, so guardrails are enforced natively, while teams can preview impact before deployment and reduce drift over time. With Native, security isn’t bolted on after the fact. It becomes actually part of how you operate in the cloud.
Go to their website. It’s simple to find. It’s just native.security. The word, native.security. And when you go, let them know that you heard about them from the CISO series.
What needs to be considered?
13:17.503
[David Spark] Tony Gonzalez of Innervision Services said, “We need secure by design processes with solutions that help developers meet security team and overall compliance/framework adherence obligations. One particular area is cloud policy enforcement that can address the complexity of multi-cloud environments,” as you mentioned.
“Along with that, we need monitoring and governance solutions to catch what was missed/introduced to our environments by internal developers and SaaS solutions.” This is where the cloud gets complex. Tony explained it right there.
And Russell Spitler of Nudge Security said, “The interesting challenge these days is that citizen developers are not pushing to the public cloud. Products like Replit, Base44, Lovable, et cetera, means that the citizens are building without ever having to dirty their hands with code, much less AWS.
The glimmer of light here is that those platforms have made it easier to integrate into existing authentication systems like sign-in with Google, so the identity sprawl is not aggravated.” All right, Eddie, I’m going to start with you. It seems like cloud policy enforcement is a really simple, easy, wonderful way to get all the cloud platforms on board.
Yes?
[Edward Contreras] You know, it sounds easier said than done, right? This is one of those areas where, “Okay. Cloud policy. Is this a local policy, is it an enterprise policy? Is it specific to an Agile team, is it a dev team policy? Oh my goodness. How many times can we define policy?”
I think it’s very complicated, and I think we’ve been using secure by design through this conversation, but really haven’t set up what secure by design actually is, right? And when you think about it, does it necessarily mean you get the first phone call during a storyboard session?
Are you, in the first meeting, inviting Scrum Master? Probably not.
Most of the time, when you’re thinking of Secure by Design, are you threat modeling? Do you understand what the business is trying to develop, and then are there risks associated with any of the development thesis? And then do you have controls to manage those risks?
For me, that’s a journey, and it’s not something that you need to be in all 100 development teams to do; you just have to have a stage gate where you’re building this out at an appropriate timeframe. And if you can train your developers, even your citizen developers, who are acquiring code from wherever they want, “Okay, well, I’m just going to have one spot to check the code in.” Everybody has hundreds of CICD pipelines.
Okay, where do you check that in at? It’s really just about staging these environments appropriately.
[David Spark] Yeah. So Gal, can I ask specifically, how is Native helping, and literally the questions that Tony has right here?
[Gal Ordo] Yeah, so these are all great points from Tony, and Russell, and even Eddie. And one thing that I keep saying to my customers and my partners, building on what Eddie just said, is that policy is a breathing, living thing. And it’s not that you go in and install a policy and boom, you’re done.
And really, connecting to what Tony said, Tony has spoken about an enforcement layer within the cloud, as well as a visibility layer. That visibility layer has existed for quite some time now with the synapse of the world. I led one of those at AWS.
But the policy enforcement piece is really where more investment is needed on the cloud side, what we, at Native, are trying to do. And that’s where we are trying to make this easier both for security teams as well as development teams.
What I constantly recommend security is first to come up with what I call an organizational policy, something which must always be true, no matter the workload or the business unit or something like that. You start from that layer, and even at that layer, you uncover a lot of potential things.
Russell spoke about what AI agents might do. There are a lot of restrictions that you might want to put around those AI coding tools. You don’t want them just going in and deleting stuff, which I’ve seen happen countless of times and causing outages.
You don’t want them training on your sensitive data.
That’s a uniform set of policies that are organizational policies that even those are easier said than done, to build those, security needs to go in into the provider and build…use three or four or five different policy engines on each providers to achieve that, and make sure that this is constantly adapting to match the new type of workloads and where the sensitive data now reside and so on and so forth.
[David Spark] This is why we’re hiring so much expertise.
[Gal Ordo] Exactly. And that’s why with the modern enterprise being a multi-cloud, you don’t just hire one cloud expert, you hire an AWS expert and an Azure expert, and a Google expert, and so on and so forth. And it becomes this everlasting roadmap item that’s more of a security engineering work than a governance work in reality, and that’s what cloud security has become.
And then after going beyond that organizational policy layer, that’s when you start going into business units and individual workloads and so on and so forth. And there is a lot of work to be done there as well, and obviously, that’s where visibility tools can help with the nitty-gritty details.
But I claim that people should get started from the organizational policy layer, and even there, there is a lot of work to be done.
Sometimes it’s really not that difficult.
18:56.461
[David Spark] Dave Kelly of SensCy said, “One, it’s true that tools are abundant, and skilled operators of those tools are not.” Just what you were saying. “Two, security failure is usually operational, not architectural.” Good point. “Most breaches don’t happen because the tool lacked capability.
They happen because it was misconfigured, unmonitored, or misunderstood. Complexity compounds risk.” Oh, yes.
“Three. Every tool beyond our team’s comprehension adds cognitive load. Cognitive overload is the enemy of secure operations. Four, sustainability and competence in the environment beats sophistication every time. No CFO chooses a financial system that requires expertise the company doesn’t have.
We in security shouldn’t do it either.” What a great summary of this problem of, “We have too much complexity that doesn’t need to be there.” Does it, Gal?
[Gal Ordo] And it happens all the time, and sometimes even when cloud providers try to make some things simpler, it doesn’t always happen. One thing that I saw happening about a year ago, AWS launched a new type of policies, and they spoke about why the enforcement for those policies is better than the previous set of policies, because these ones are intent-based.
It’s not like a JSON that you go in, and you say, “This API should block.” Rather, it was focused on an outcome, which is where we all want to be in security.
And so I started testing those out with a few customers, and what I’ve seen is that the enforcement is done a little bit differently, and all of a sudden, it becomes a secure default rather than secure enforcement. And it wasn’t published out there. It wasn’t clearly stated out there.
And I’ve seen that happen countless and countless of times where one thing that customers think are doing one thing ends up doing a completely different thing. And that’s where there is a lot of complexity in those security policy engines and tools, especially as you go beyond enforcing a single outcome into enforcing the entire realm of organizational policies.
So the point is, I actually agree. I meet with hundreds of customers even who tell me, “Hey, in AWS alone, there are 40 or 50 or 60 different security policy engines and capabilities.” I met my co-founder at AWS. He was leading one of the other security products, and like us, there were a dozen other security leaders in AWS.
But when I met up with a CISO of a Fortune 100 in AWS, and they asked me a difficult question, and I came back to them with an architecture diagram containing five or six different AWS security services, their answer to me was, “First, how was I supposed to know that?
Second, this isn’t sustainable.”
And that, to me, is the core issue. And then I’ve just spoken on AWS alone, but multiply that in a multi-cloud world where each provider speaks in a completely different language, and to Dave’s point, you get to a cognitive load that’s so hard for security engineers to just sort through and get to that clear path for enforcement and secure by design.
[David Spark] Yeah, we’ve created a pretty nasty problem for ourselves, haven’t we?
[Edward Contreras] Yeah, we have, right? And maybe here’s a good example. And I love that story. That was amazing, right? When you unpack it that way, and you. ultimately, get to, “Someone’s not happy,” well, that’s all you need to know, and so it’s a problem.
If you look at how companies adopt containers today, a lot of containers offer a native solution for vulnerability management, and a lot of them will make a statement like, “It’s free and included in your license.” “Well, great. You’ve just introduced a very complex free product that ultimately ends up not being free,” if you think about unpacking that statement.
Now you have to design a workflow for your remediation teams, you have to purchase a module for your vulnerability teams, you have to then do new reporting and new metrics, and then, going back to Nathan’s earlier quote, now you have multiple source of truth.
All of a sudden, this free product is costing you FTEs, increased license, and complexity.
And it’s so easy for someone to come in and say, “Well, wait a minute. We got this really amazing cloud native software that you already own. It’s embedded. It’s not going to cost you a dime.” It then ultimately cost you millions. And it’s one of those challenges, and exactly what Gal said, “Now, where do you apply the policy?
Do you apply it locally within the product? Do you got to replicate that policy within your own environment? Do you have to then set other monitoring tools to monitor the effectiveness of that policy?” Complexity. That’s where you want to stay away from.
[David Spark] And you’re just talking also about the complexity of physically pulling it off. It’s also the complexity in the cost because nobody sees this cost up front.
[Edward Contreras] Correct, correct.
[David Spark] Because all those things are so small, and it’s like the death of a thousand paper cuts. Like, “Yes, I have to train them. Yes, they need to spend the time. How many people? What could they also be spending their time on?” There’s so much there.
There’s no spreadsheet that shows that.
[Edward Contreras] I’ll tell you, the CIOs who have a FinOps team, phenomenal investment. If you can understand how billing works and you can get to a total cost of ownership on your initial request versus death by a thousand cuts, “Oh, Q1, we got to increase license usage.
Q2, we got to add three FTEs. Q4, it just grows and grows.” If you get that up front, your CFOs will love you.
Closing
24:59.999
[David Spark] That’s a great tip. Let’s close on that great tip. Excellent. All right. I want to thank Gal and his company, and that would be Native – The Cloud Security Control Plane for the enterprise, could be a solution here. You should check on them.
I’m going to let Gal have the last word and explain.
So go to their website, native.security. Again, that’s native.security. All right, Gal, I’m going to let you have the last word. A couple of questions. First, are you hiring over at Native, and second, do you have an offer? Or explain it fully to people who don’t fully understand.
[Gal Ordo] Yeah, absolutely. So I’m going to start with the first question. First of all, yes, we are hiring, and we are growing rapidly because of the customer feedback that we’ve been getting on all of those issues. So feel free to reach out if you’re looking.
But we’ve also spoken a lot about the complexity behind actually doing and building cloud security in one cloud or in multiple clouds. And Native serves as a control plane, an operating system, if you will, where you can go in and state those security outcomes, these organizational policy in natural language, and we go and do the hard security engineering work of translating it into the individual cloud controls and doing the simulation to make sure that it doesn’t break production during the rollout and doing the operationalization of those over time, to make sure that you update the policy if you need exceptions or as new capabilities are launched and so on.
So we really solve these customer issues firsthand and decided to develop a new product at Native to solve them.
[David Spark] And how best should our audience connect with you and connect with Native to learn more?
[Gal Ordo] You can just go on our website and leave your details, or you can hit me up on LinkedIn.
[David Spark] Yeah, we’ll have his profile for the blog post for this episode.
[Gal Ordo] Perfect. They can hit me up on LinkedIn or just gal@native.security. I’m always happy to show what we’re working on or just have discussions on this kind of stuff. Honestly, this is the most fun part about my job.
[David Spark] I love talking to entrepreneurs because I love the journey of how they got there. And, by the way, your story of, “I worked at a job. I saw this problem. I left. I started my startup.” This is the most common technique of how so many of these startups begin, and I love it.
It’s great.
Thank you very much, Gal. Thank you very much, Eddie. And to our audience as well. I say this all the time, and I’m going to say it again. We greatly appreciate your contributions and listening to Defense in Depth.
[Voiceover] We’ve reached the end of Defense in Depth. Make sure to subscribe so you don’t miss yet another hot topic in cybersecurity.
This show thrives on your contributions. Please write a review, leave a comment on LinkedIn, or on our site, CISOseries.com, where you’ll also see plenty of ways to participate, including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at David@CISOseries.com.
Thank you for listening to Defense in Depth.