Ep#105 – Solving the Problems of Cloud Native Applications

Building Cloud Native Applications can bring about many operational and security problems.
Today, we sat down with an expert in this field to talk about building cloud native applications,
and deploying applications that are secure in the cloud.

This episode features Fausto Lendeborg, Co-Founder & CCO, from Secberus, who provides
answers and explanations to a variety of questions regarding Building applications in the cloud,
deploying applications securely in the cloud, and much more.

Join us as we discuss:

• Building Cloud Native Applications
• Deploying Applications Securely
• Managing a Cloud
• Security, Compliance, and Governance
• DevOps

To hear this episode, and many more like it, we would encourage you to subscribe to the Virtual CISO Podcast on our YouTube here.

To Stay up to date with the newest podcast releases, follow us on LinkedIn here.

Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player.

See Below for the full transcription of this Episode! 

Intro Speaker (00:05):

Listening to the virtual CISO podcast, providing the best insight on information security and security it advice to business leaders everywhere.

John Verry (00:19):

Uh, hey there, and welcome to yet another episode of the Virtual CSO podcast. With you is always John very, your host, and with me today, FTO Linda Borg. And hopefully I got the last name right. Fto

Fausto Lendeborg (00:30):

Got it right. Got it right. John

John Verry (00:32):

<laugh>, uh, always like to start easy. Tell us a little bit about who you are and what is it that you do every day.

Fausto Lendeborg (00:38):

John, first of all, thank you so much for for the invitation and, and let’s have some fun. Um, so I, I, I’m a co-founder and chief customer Officer OFS Bears. And, um, the, the, the mission and the vision that we started ATS Bears was to, to truly, um, solve the security and operational problems that cloud, uh, building cloud native applications brings to the enterprise. Um, and, you know, my, my daily functions and duties, it goes from speaking to product and technology team. Truly just translating what the customer needs, what the customer wants into product and technology, being the voice of the customer in, in our marketing, uh, materials and, and truly expanding our brand. So I, I like to say that I do a little bit of everything, uh, but the most, my biggest task is to make sure that we continue to push forward, um, our mission.

John Verry (01:39):

Yeah. As a founder, you’re the chief cook and bottle washer and, and you clean the bathroom. Know, yeah. Understand, yeah. Understand the startup world. Um, so I, I always ask, what’s your drink of choice?

Fausto Lendeborg (01:53):

My drink? I’m a gin. I’m a gin guy. Yeah. Yeah.

John Verry (01:58):

G g and T right up martinis. Uh, and I’m an a an nerons, I’m an negron guy,

Fausto Lendeborg (02:05):

G and t, just because he doesn’t gimme a hangover. So that’s the one I,

John Verry (02:09):

Yeah. My, my wife, my wife is g and t, although she does it with lemon instead of lime.

Fausto Lendeborg (02:14):

Yes. Oh, lemme try that.

John Verry (02:16):

Yeah, yeah, yeah. Uh, and she, and you know, it’s funny because I was always like a vodka martini drinker, and then, you know, I started drinking all her GTS and suddenly found myself doing gin martinis and negronis. So

Fausto Lendeborg (02:28):

I was a, I was a vodka guy into one night, into one night, and then never

John Verry (02:31):

Yeah. <laugh>. Yeah. I’ve had a few of those nights. All right. So, so, you know, you talked about the cloud, and I don’t think we need to, you know, the benefits are of, of people moving workloads and applications to the cloud are very significant and obviously very well documented, but it’s not all rainbows and unicorns, right? I think everyone who’s moved stuff to the cloud has had that experience of what, what I’m gonna call sprawl, you know, in terms of, you know, what’s up there, you know, keeping track of that, uh, sprawl within a single cloud sprawl to multiple clouds. Um, and increasingly we see our clients, uh, uh, struggling with the idea of ensuring the security and compliance right of, of each of those clouds. So I know that’s a problem that you’re working hard to address. Would it be fair to call what you guys are doing, cloud security, posture management?

Fausto Lendeborg (03:22):

Um, yeah, in some sense. I mean, it’s a, it’s a component, uh, out of our platform. Um, I think we like to look at it a little bit different. I mean, that’s what the market position of the solution has to be, the cloud security, posture management, or csp. Uh, but I think there’s bigger problems to solve. Um, and there’s challenges that the enterprises are now, um, starting to understand they need to solve for.

John Verry (03:48):

Gotcha. So, you know, managing a cloud, like from my perspective, there’s three highly interrelated disciplines, right? We’ve got, you know, obviously security, we’ve got compliance, and then we’ve got governance, which sort of sits across those two. Can you define each a bit and talk about their importance?

Fausto Lendeborg (04:05):

Yeah, I think for us, we look at governance as the umbrella, as the umbrella, um, term and, and, and domain and right under that security and compliance and kind of an overlap and diagram. I think for us, governance is, is a top level down approach. It’s a business approach to solving the security and compliance problems, right? Um, and we like to, to say governance is, is how the enterprise aligns their requirements, their risk, and their intent into security and compliance. It’s all about really combining and, and, and flipping the problem upside down. Before we used to rely on security to provide governance, and that for us was a bottom up approach. Put a tool in the engineering box, and eventually we’re going to get governance out of it. Uh, but as we transitioned to the cloud, I think, and, and new applications are, are getting built, um, we like to, to think that the new wave of enterprise platforms and applications are all business driven with business language. So for us, we’re starting governance as a business language to secure to security and compliance, and then security and compliance come in as an enabling of that governance. So it’s all kind of working together at the same time.

John Verry (05:28):

Yeah, it’s, it’s sort of the holy trium, and I couldn’t agree with you more. Uh, you know, I’m a big fan of the, the concept of tone at the top, and that’s really what governance is. And, and governance is indeed a business function because, you know, these applications exist for one reason to serve the needs of the business, right? Or to drive the business forward. And if business isn’t governing, if we’re not governing it from a business perspective, um, then, then we’re not going to achieve the business objective. So, couldn’t agree with you more with the, with your approach. Um, so, you know, with applications moving to the cloud, right? We, we see, uh, a significant move in most instances towards, you know, DevOps, right? And, and DevOps oriented applications. Um, and one of the things that I like about DevOps and infrastructure code is the benefit of as code, right? Yeah. Um, so what I was really intrigued by, uh, and one of the reasons that I wanted to chat with you is your quote, unquote as code approach to governance, security, and compliance. Um, to me that’s super intriguing. How does it work?

Fausto Lendeborg (06:29):

So if, if we first think about the as code world that’s getting used in, in, by, by DevOps in this new DevOps world, right? Um, everything is building to every, everything is transition into an ass code stack, right? So everything from applications, infrastructure, software, um, is just a way of building building applications cuz it’s very fast, right? It’s velocity and velocity is what got us here, the security problem and the cloud. So when you, when you, when you think about if the problem relies in an ass code world, think about this large snippet of code living everywhere, how can we fight the ass code world, if not with an ass code solution, right? So when we started thinking about how can we build governance, security compliance continuously to mitigate the risk that an as code world brings, we needed to think about governance as code.

(07:30):

We needed to think about compliance as code, security as code, and at the core and at the core policy as code, right? So for us, we decoupled our, the, the solution that’s codified in Nasco world from the host, the hosted environment of the application and, and the engineering stack in the as code world. And those two together as a blend are able to assess security compliance and governance at this because of ISAs code at the speed of as code built. So the big, the big thing we’re trying to do here and and, and how everything meets in the middle is that we need to have a solution that doesn’t block the engineer from going fast and from building. And one of the things that blocks engineers of going fast into today’s world is this methodology of security by design. Let’s take a quick break and let’s build, let’s make sure it’s secure before you build it.

(08:34):

And this approach worked 20 years ago in the world of change management, but as we transition to a cloud DevOps world, the security by design methodology doesn’t work. So for us is build a solution that is as code that can be assessed and read the as code risk and vulnerabilities, decouple those two and apply continuously configuration management policy as code logic to this build out at the, the velocity of the business, right? So taking a step back is we encourage customers to continue this DevOps centric world. We encourage customers to continue to build in multiple infrastructure. And because we know that tomorrow there will be another cloud, then it’s about decoupling where the infrastructure is from the, from the risk assessment. And it putting, putting those two together allows us to get to where we want to get.

John Verry (09:35):

Yeah. So is it really, it feels to me like not that we’re not doing security by design more so that you’re changing the way that it’s being done. You’re more integrating security by design. Cuz if you think about it, if you’ve got policy as code, and I’m assuming that your policy is code is, you know, is establishing the, uh, the, the, the, the settings and, and and establishing the, uh, guidelines, right? To make sure that things stay within, within our boxes. You know, to me that is security by design, right? Your policy, if you will, is the design is design. You validated that the design is secure. So to me it’s, it’s not that you’re not being secure by design, it’s, you’re a better form of security by design because you’re integrating security by design into the workflow.

Fausto Lendeborg (10:23):

That’s very well put, uh, uh, put there John. A hundred percent. Yeah. The security by design is not relying on the engineers to secure by design, but relied on the governance business to design the environment and guard rules around them, correct?

John Verry (10:37):

Yeah. Which, which is, which is an awesome, uh, an awesome approach. Now you, you mentioned, and it sounds to me like, um, it sounds to me like the as code approach also has the benefit of, I’m gonna use the term providing a level of abstraction, right? So much the same way that ODBC provides a level of abstraction between the application and whatever backend relational database we want to use, right? And I can write code once and I can reuse that code across any database that I want in my application. It sounds to me like your, your policy is code and your securities code and your compliance is code might have the added benefit of it that I can write that once and it doesn’t matter if it’s sitting in Azure or if it doesn’t matter if it’s an AWS or sitting in Google cloud, right? You’re going to translate that properly in those worlds. For me,

Fausto Lendeborg (11:24):

That is a hundred percent correct. We have multiple levels of abstraction, right? So when the data comes in, when the ask code data comes in to be assessed into the platform, um, that data sits and gets normalized in, in our environment. So we have, we do have the ability of building a business security or compliance policy, um, that traverses the data stack across multiple environments. So the same policy applied in an Azure environment and the same policy applied to an AWS environment regardless of the underlying technology that the engineers are using.

John Verry (12:01):

Yeah. That would seem to solve another problem, you know, that I think most teams are having, including us as a consulting organization is, you know, it’s hard to have deep expertise in each cloud vendor’s offerings. You know, especially when you look at something like AWS or Azure every time you log in, right? There’s three new products or services or whatever you want to call them. Yeah. And staying on top of it is literally a full-time job. So, you know, anything that can actually help me, uh, have a single cloud security engineer that uh, can service multiple clouds right? Supports a hybrid cloud approach, you know, to me is going to be a win for the customer that uses that.

Fausto Lendeborg (12:44):

Yeah. John, I’ll tell you why. That, why that’s a problem. Now that’s a, and and that wasn’t a problem 10 years ago in, in cloud itself. I think when we first, when we first started building our applications in the cloud, we were doing a shift and lift a lift and shift into the, into the, this environment. Like same server that used to run in your data center now runs in your aws and the, the engineers and companies, they, they started looking at cloud lock in as a big risk. We cannot stay, we cannot use all the services that one cloud brings because we’re gonna be ourself, we’re gonna be locked in. But then we quickly realized as this cloud get, were coming completely stable across the board, the big three now engineers, were feeling more comfortable and the business starts to feel more comfortable to enable cloud lock in by using cloud services, pretty much cloud as a service services from the cloud that comes with battery to build cloud native applications in the, in the former serverless.

(13:51):

So when you bring an engineer into, into a team, DevOps, they are going to build an application based on the knowledge they have within the cloud they’ve been using. So now you start seeing, you, you bring multiple engineers and they all wanna build applications in different environments just because they’re comfortable. You’re going into a cloud lock in, but you’re going into a multi-cloud lock locking based on the engineer. So the way we build applications in the cloud today are completely different than the way we build up. We used to build cloud applications, um, applications in the cloud 10 years ago. So because we now at that, that, uh, that, uh, crossroad is the now the ability of having a platform that can be data agnostic across the board regardless of what the problem is, because now every enterprise will be in a multi-cloud environment.

John Verry (14:50):

Yeah. So when you, so once we’ve got your stuff implemented, is it, you know, do you look at it as being preventative detective corrective some combination of, all right, so I’m assuming, right? We, we plugged this in as code, you know, it’s sitting in the pipeline and, and in much the same way, infrastructures code ensures that we end up with a secure server, you know, based on having a validated image, I’m assuming that, that you are on that build cycle that you are enforcing you the, you know, the, the policies that we’ve put in place. And I know that my application is going to meet those policies at that point in time. Um, so, so I’m assuming there’s a, uh, what I’m gonna call a, um, a preventative component. Uh, is there a detective component as well? So what, you know, like we just had an issue with one of our clients where, um, you know, somebody spun up, uh, another dev instance, you know, not following normal pro processes, uh, they made a mistake with an S3 bucket and you know, S3 bucket, you know, permissioning, uh, and left some client data out there and that somebody found, um, so, so talk about that.

Fausto Lendeborg (16:02):

Yeah, I think it’s, it’s a, it’s a combination, John, and it’s a combination that we do, and it’s a combination that the customer needs. And I’ll tell you why. There’s a lot of impact on out of remediation that customers have been, uh, historically afraid of turning on, like fix something the moment you find it. Um, and that’s a complete automation. And, and there’s the challenge of how can you turn something and out outta remediation, how can you fix something without understanding the impact? And you’re risking the problem of a false positive. If it’s a false positive and you break something, now you have a business, a business risk, right? But I think the, what we do, and the way we build it is it’s configurable to the customer’s risk, appetite and their strategy of remediation, right? Um, so we have technology from detecting, um, and notifying the, the correct person.

(17:00):

And that’s something I don’t want to, to skip over because when you inform the right person of the problem, you now are cutting the investigation time, um, by a hundred x. Right? Now in the typical security world, we used to send all the alerts to the security team. Well, the security team doesn’t have any context on the application they’re building for us what’s super important to understand who owns the application, who broke the application, let’s make sure that we can detect the problem and route this policy violation to the right individual. So we do have detection capability in that extent. We also have prevention capabilities on preventing something from even getting built into a production environment. This is a so-called shift left approach. Insecurity shift, the shift left of the deb of cycle. Um, and then last but not least, we also have a multi, a multi action workflow engine, right? That allows us to, to prevent, if not, then we can detect, but we can detect in multiple channels to multiple people. And then we can also create automation to fix automatically in the web, in the web of webhooks that we can build. So it’s a, an array of tooling that we provide within the platform that allows the customers to say, this is my strategy, and now I’m going to configure and implement my strategy using the cigarettes platform.

John Verry (18:22):

Gotcha. So if I, so if I was using SEC PRUs, um, would I be, it, it would sound to me like, you know, much the same way I might implement a code checking tool in, into my automation that I’d be implementing something on the automation side. It sounds like if you’re doing detection, that you’ve gotta be sitting, you know, when, uh, and I was screwed the two of them up, whether it’s Cloud Trail or CloudWatch, but you know, like you’re sitting, you’re sitting in the, uh, logging right? And, and looking at what’s going on in the logging. Are you also instrumenting the application as well? You know, like some of the IAS tools do do, or you, or, or, you know, so I’m just trying to figure out like where you are shimming in to, you know, and how someone’s implementing you to, to provide all this functionality. Yeah,

Fausto Lendeborg (19:10):

I think the beginning is we, we connect to every, uh, all the GitHub repulse, right? And, and can and can verify when there’s a commit of code, uh, to a Terraform conflict file that’s about to get pushed, right? That’s a preventive mechanism on the detection mechanism in runtime or production environment, how people call it. It’s about listening to those log events and make and reading the changes. Once we can read, there’s a change. We go and assess the change in the infrastructure. Let’s say that today there was a database change, we then go and assess the entire configuration and all the assets around the database against the policy, which policies are in place. And then we execute the policy. So we build something called the policy execution engine that when we detect there’s a change in the configuration, we can then execute the policies that are enabled for that enterprise. Um, on the application. We don’t are, we’re not looking at traffic in the application. And that’s something we do that kind of, you know, east to west traffic and so on. Right now we’re focused on some of the biggest, um, risk for the enterprise, which is misconfigurations at scale, right? So think about companies that have outsourced and, and, and thousands of engineers working on applications at the same

John Verry (20:30):

Time. Gotcha. And the Zeus, uh, policy as code sits in that Terraform file. So, so is that where it’s, is that where it’s typically being inserted? Like if someone’s thinking about how does this actually work in the real world?

Fausto Lendeborg (20:45):

Yeah, so it works. We, we have a full SA aging list, um, application and we, you know, when we detect, uh, the, a change, we go ahead and, um, pull the information from the api, from the cloud api, the infrastructure service api.

John Verry (21:03):

Okay. Okay. So your, your code exists in the SA application. It doesn’t exist in the client’s DevOps code?

Fausto Lendeborg (21:12):

That is correct. Yeah. Everything, everything is within our product. That’s correct.

John Verry (21:17):

It’s, it’s, it’s interesting to me cuz your tool sounds very, um, complex. Well, at least I thought this was gonna be a very complex conversation, but you made it sound very simple, <laugh>, um, and I’m like, I must have missed something. What did I miss?

Fausto Lendeborg (21:34):

I think that the big, the biggest thing that we talk about, John, is false positives and alert fatigue across product, uh, security products. Um, we, we, we, we coming from the world where there’s too many alerts and it’s just, uh, engineers are just turning this tools off because who can spend so much time investigat investigating this alerts? Um, so one of the things that we fight a lot, not five combat, right? Uh, the pain that we combat the most is the operational challenge that these enterprises have in trying to eliminate alert fatigue and reduce false positive rates, right? Because if you can do that, you now have you, your medium time to remediate, get shorter. Um, and, and it allows you to really mitigated managed risk, right? Because risk is an adaptable cycle, right? There’s always going to be risk introducing into the, into the, into the business, right?

(22:37):

There’s always a change. So the attack surface continues to get bigger. But we are not talking about all, all the products in the market are talking about just detecting, detecting risk of remediating risk when no one talks about managing risk. When you turn on an enterprise solution security solution that is in the marketplace and you turn it on across 500 cloud environments, you will receive 50,000 alerts. How do you manage 50,000 alerts? You cannot add or remediate immediately. You can fix everything cuz everything will break and you cannot send it to the SOC because they now have to investigate every single alert. By the third day they’re going to just not continue to do it. And by the third day there will be another 10,000 alerts. So we are living in this like giant lake of alert fatigue and we solve that by helping enterprises solve the operational challenge by routing the, the alert to the right person and tracking the, the entire process. And we, we believe that if you can solve the operational problem, you will then solve the security problem.

John Verry (23:51):

Yeah. And do you meet, do you meet the people that you like? So as an example, like developers are Ty typically sitting in Jira where, you know, security folks might be sitting in Slack or some other channels. So I mean, is is that part of the process as well as, you know, getting to the right people through the right tools? Because if you can meet people where they live and work every day and they don’t have to go somewhere else to get this information, uh, it just simplifies the hell outta things.

Fausto Lendeborg (24:15):

That’s it. That’s it. And everybody has different channels and different processes and different risk and you know, for us it was how can we build a platform that can be tailored to the company’s strategy? Because every company has a different strategy,

John Verry (24:30):

Right? And, and anything you can look, I mean it doesn’t really matter. Um, and one of the problems we have is that as tools try to be both security and compliance tools for folks, you know, what happens is security and compliance, you know, are, are two sides of the same coin, but they feed different masters. Security is about the needle in the haystack. Finding that needle, right? Isolating it right signal to noise compliance is about the haystack, right? It’s proving that all that other stuff happened. You know, so, so this idea that you’ve got a mechanism by which you can improve that signal to noise for the security folks right? To solve these problems to, to, uh, you know, incident detection and response time can be reduced. Um, definitely makes a ton of sense.

Fausto Lendeborg (25:12):

A hundred percent. John, I agree. A hundred percent. A hundred percent with you.

John Verry (25:15):

Yep. So, so going back to how it worked, cuz now I’m intrigued, right? Cause I, I had a mis idea of how this worked. So that same so realistically, even the, like I was thinking that inside of the initial build, you were in their code, right? In their, in their automation really, whether it’s an authorized change, an unauthorized change, a new build, someone making a change outside of normal build processes, because you’re sitting on the logs, you’re gonna detect all of that the same way and your compliance engine, every time it sees one of these checks is going to actually run and say, Hey, I have an issue here, or no, everything looks okay.

Fausto Lendeborg (25:54):

Correct. Correct. So think about the, the, the C I C D pipeline, which is the, the process of where engineer pushes code from, from code to cloud, right? Kind of the entire pipeline. When you have thousands of engineers making thousands of changes a week, you now have that times a lot, right? So it is not just one pipeline, it’s everybody has their own pipeline. Um, so for us it’s to keep track of everybody’s pipeline. When there’s something goes wrong in any process of the pipeline, we stop them at their breaks, say, look, this is validating company policy, company policy xyc, and this is how you, right? So we, we go from, from that prevention mechanism, if it gets pushed and we detect another authorized or an authorized problem in a runtime or cloud environment, then we also detect the same person that pushed the, the, the change.

John Verry (26:47):

Gotcha. But I mean, would you, so remember I talked about before, you know, someone going outside of the normal DevOps automation processes and spinning up a standalone instance to do some troubleshooting. Um, I’m assuming you would’ve seen that. We,

Fausto Lendeborg (27:03):

We

John Verry (27:03):

We’ve seen that and, and you, but I’m just assuming that by, you know, like the way that you implement this, if you see a change and that change is, let’s say, you know, so I’m assuming you’ve got somewhere in your policy security, compliances code, whatever it might be, something that says S3 buckets should not be set to open. And if I, if any S3 bucket from, from looking at the logs, any S3 bucket gets opened, you know, with an, uh, you know, with without it being properly secured, you’re gonna flag that right away.

Fausto Lendeborg (27:31):

That’s correct. That is correct. We, we, we see everything and it’s about creating different baselines for different set of environments. So we do have an environment that’s production baseline, uh, development baseline. So it’s building the governance strategy for all the environment and we, we do look at all the data.

John Verry (27:48):

Gotcha. And this, um, and one last question because I’m curious, the, your, your policy is code or infrastructure is code, is that just like a XML variant, you know, yaml, some, some type of standardized language that you’re, you’re doing this in?

Fausto Lendeborg (28:03):

Yeah, we picked Rigo, Rigo language, um, rego, R E G O. And we picked that because there was a big project out of, um, the cloud native foundation called open policy agent that built Rigo and had a huge community, very easy language to, to write for an engineer. So we 4, 5, 6 lines of code we can iterate through the logic.

John Verry (28:26):

Gotcha. And I’m assuming that, um, you’ve got a repository of prewritten rego code for most of the major, you know, like an S3 bucket not being left open, right? I’m sure is not something I’ve got a code, I’m sure that’s something that I can just click on a button and, and that code is already done for me.

Fausto Lendeborg (28:43):

Yeah. With over 600 policies out of the box that our customers can start with. And those policies can actually be clone, um, edited and completely customizable, right? They can map to compliance regulations, they can have their own risk and, um, environment, uh, risk, uh, severity, uh, completely configurable.

John Verry (29:01):

Gotcha. Um, right. So I’m assuming like on the security side, right, they’re the types of settings that we talked about on the compliance side, that might be where if I’ve got patient health information, you know, I might have some, I might have something which is validating that we’re HIPAA compliant.

Fausto Lendeborg (29:18):

That is correct.

John Verry (29:19):

Okay, cool. So it’s almost like AWS security center where we can go in there like an our, our cloud based app, Oscar, you know, we have, uh, you know, the P C I DSS stuff enabled, we’ve got, uh, the AWS security essentials enabled, um, CIS bench, cis ci CSC enabled, and we kind of track and make sure that we’re staying compliant with all that stuff. So same kind of an idea,

Fausto Lendeborg (29:39):

The same, the same, the same concept. Yeah. I think for us a little more on the scale side, create any, any custom framework, any custom logic, any custom process and automation, and then multi doing that multi-cloud,

John Verry (29:53):

Right? And I would imagine that that, that that’s that dual facing value prop, right? I’m gonna turn on a bunch of stuff automatically. Thank you for doing that for me. But everyone has a unique snowflake environment, right? Everyone’s business and and application contexts are different. So people are going to also want to customize this to their specific context to get the most value out of

Fausto Lendeborg (30:12):

It. Yeah. And, and, and for that, we, we actually build it within, uh, uh, the core of our technology. Uh, we have a feature attribute based access control abac, I’m not sure if you’re familiar. So with abac, which dynamically syncs in with any identity management, we can actually understand the attributes that the engineer has access to and provide a unified tailored dashboard of the product. So if you have an engineer working on application one and an engineer working on application two, and they both have the same policy enabled encrypted S3 bucket, when an engineer engineer one logs into their S dashboard, they’re gonna see the policy violation of their own application. And when engineer two logs into the SS dashboard, he’s going to see the policy violation of application number two, which means none of them are going to overlap in, in alerts, but the policy will remain enabled. And that’s how we actually close the engineering app from the top.

John Verry (31:15):

Gotcha. And then I’m assuming that you’d have an option if you wanted somebody in compliance or somebody in security to, to know about that as well? I’d have the option of ma of having it visible on their dashboards as well.

Fausto Lendeborg (31:27):

That is correct. So we did a combination with policy as code rback na back to actually get this done.

John Verry (31:32):

Gotcha. And then if, uh, and then do people use your dashboards and reports directly in terms of being able to demonstrate com compliance or, um, or do you typically, are you providing some type of an API or some type of a feed to whatever mechanism, whatever GRC platform or sim platform they’re using to to, to manage their

Fausto Lendeborg (31:53):

Compliance? Yeah, it’s both. It’s both. We do have customers that that can output the, a real time report snapshot of, of a current application. Compliance, scheduled reporting is enabled in the product. Um, but also we have customers that added their own integrations into their, into different stacks. So combination, combination of flavors.

John Verry (32:14):

Um, what’d we miss? Anything?

Fausto Lendeborg (32:18):

Uh, no, I think we’ve, I think we’ve covered a lot. Think we cover everything?

John Verry (32:23):

Yeah. Damn, you’re good. That’s all I have to say.

Fausto Lendeborg (32:27):

I, all

John Verry (32:29):

Right. So, so yeah, hopefully, I, I know you’ve been dealing with a hurricane this week, so I’m prepared to give you a pass if you didn’t do your homework. Did you do your homework? You know, the next question, question.

Fausto Lendeborg (32:40):

Horrible. An amazing

John Verry (32:40):

CSO give, right? Give me an amazing or horrible, uh, what fiction character or real war person do you think would make an amazing or horrible cso and why?

Fausto Lendeborg (32:49):

I was think I was thinking about this and I had a name of a horrible CSO or a, a amazing cso, um, amazing cso, yes. Um, Sherlock Holmes was the person that I thought

John Verry (33:05):

<laugh>. Okay. And why?

Fausto Lendeborg (33:09):

Uh, just finding out, finding out the problem through investigation, the incident, and be able to map it, um, and create defenses around that, right? How to, how to never replicate, um, how to avoid the replication of the incident. I think a very methodical person that can see everything very, very fast across multiple disciplines, I think that would make, that would make an amazing season, right? Understand the thread, understand the compliance, understand the technical engineer, kind of really a multi-domain expertise. Um, that’s what I thought.

John Verry (33:50):

So I only have one question. Would he still be an amazing CISO if Watson was not his security manager?

Fausto Lendeborg (33:56):

Not at all. And it’s Watson <laugh>. Okay.

John Verry (33:59):

Okay. So you, you didn’t caveat it that way, so I had to make sure <laugh> right. Um, if, uh, if, you know, if, if folks, uh, are interested in learning more about Zeus, uh, what would be the best way for them to do that? Fsa,

Fausto Lendeborg (34:16):

Um, directly on our websites, bur.com, you know, kind of, we have a lot of contact information there. Uh, we have a really, a lot of really good information about our product, our platform, our methodologies, our brand, uh, our vision, our mission, our team, like, we put everything out there, all of our content. We, we try to really build it, uh, with, with really trying to push this and solve this problem for, for the enterprise. So directly on our website, they can find all the information about our company.

John Verry (34:48):

Awesome. Man, this has been fun. Thank you,

Fausto Lendeborg (34:51):

John. Thank you. Thank you so much for having

John Verry (34:52):

Me. Um, same here, man.