Cloud Native Security & Compliance, with David Zendzian

Episode 264 · Fri, 02 Jun 2023 09:59:50 +0200 · 1:16:04 · SRT · archive.org · all Tanzu Talk

Well, we're back with another Coté and Cora episode. This episode we had David on, and I think it was you, Cora, who came up with the idea to interview him, right? Oh, yeah, I love David Zenzian. He is the head of Tanzu Global Field CISO, that's his title. And, yeah, he does these quarterly updates for our whole field organization on everything security for VMware Tanzu. And he is, I've also, I had the opportunity to meet him personally at a conference recently. I think it was a KubeCon in Detroit, perhaps. And he is just incredibly a nice person as well. So, yeah, I was really excited for this. And because we are doing author talks, our inspiration, our hook, was a publication that he's getting ready to put out within the next, I think, two weeks on VMware Tanzu PCI best practices for containers and container organizations. But, yeah, he does a lot of security work. And the conversation we had was so fun and covered so many different topics, right? I don't know. What did you think? Yeah, no, I mean, I agree. He's a lively person for the reputation security people have. Very, very, as he says many times, very optimistic and engaging. And, you know, I, you know, as odd as it may sound, it was really fun to read the PCI paper because, you know, over the, as I kind of talk about with him, over the years, things like compliance and security always seem like this mysterious, like almost occultic practice out there that's very complicated. But I've always kind of known, or not always, I've recently kind of known that if you actually go and you read a lot of the compliance and security things, like the PCI spec, like it's not that it's like not important or not complicated, but it's like not a big deal. It's just like, here's things you should do and you should do them. Now, the way it's, it doesn't have academic writing, but it can have that kind of density to it.

Like one thing I wanted to ask him that I didn't get around to is like, why are things written like this? Like, this seems like the style of the community to be very, to be very like, like formal and things. And I guess, I don't know, that's probably what you end up with when you're doing standards and things like that. But I think David did, in the conversation, I think, I think we figured out a lot of just like, what, as I kind of start, not start, but at some point I asked him, like, you know, you see all these surveys and security is always like a number one problem. And like, I don't know what that means. Like, what is that actually, like, are people worried about installing virus scanners or like turning off ports and configuration files? And I think, I think he, you know, we got a pretty good explanation of what it would mean, what it means in a cloud native world. Like, not even what it means, but what the security things are, and kind of how you go about thinking about what they would be for industry and region and just basic security as well. Yeah, I definitely have a clearer mind about everything security in the cloud space, cloud and container space specifically after talking to him. So I hope that everybody else gets the same benefit out of this. And as you said, David is incredibly engaging. So if nothing else, it's just fun to listen to him. Yeah, well, we'll jump right into it. And eventually, I'm sure I'll mention in the podcast here when the PCI paper comes out. And you can see what I mean by it being gripping, thrilling reading. If you've ever been told that security is an issue to have, there's some great stuff in there. A very, very, you can even tell there's some, there's some great tables, multiple columns, really something good to dive into. But he's also publishing a blog that has a little bit more of a personal note about his background, how he came up in security. And that's a great read. Yeah. All right. Well, enjoy listening. Why don't you introduce yourself, guest? So David Zenzian. I lead the field CISO team for Tanzu in the modern app side of VMware.

And I get to talk security to our customers and how they change what they do to do a modern app in today's world. So it's a really exciting, exciting space to be in. Yeah. And, you know, and when I, when I was, when Cora and I were reading through stuff ahead of this, I was realizing delightfully that you are, you know, a lot of what you talk about and work about is scoped down to applications. And I was like, oh, thank God. Something I kind of understand. We, you know, we don't have the whole gigantic wide world of security, which, which, which is, is beyond my, my comprehension being, you know, I, my excuse nowadays is always, I was an application developer. So everything you hear bad about developers, that's me, just not, not knowing anything that happens below the screen. That's right. And don't forget when we talk about applications, though, there's also that part that you, as a developer, you probably thought about, but didn't do a lot with that. I think one of the big changes today is the users, you know, the consumers of the applications. So that, that does bring it down to the end point in the bigger, broader scale of, of things, which gets really fun in our VMware conversations. Yeah, it's probably like most things where like, by the time you, you have the sophistication, I guess, in the, the, to be able to bring it down to the application level, it, it implies that you have addressed that topic at all the layers that support that, I guess. Right. It's a. Well, there's two sides to it. One is you're consuming off the shelf software. So, so a lot of, you know, a lot of, you know, even financial firms, you're a bank and you're receiving core software that's coming to you as containers nowadays. Um, but if you're, if you're like a tangent team deals with, if you're actually making software, you are a fairly mature company that, that, you know, you're either a startup who has a lot of funding just to hire developers because developers, you weren't cheap probably when you're a developer, right? I hope not. So it's, it's, it's a certain mindset of people who are actually producing software and you get to the customers we work with, you know, we're talking a thousand applications, 2000 applications. That's, that's big scope.

Yeah. And, and, and, and so speak, you know, getting right into that as, as we're doing here. Right. So, so there's, there's two scoping things we mentioned applications. And then you brought up the other one that like gets right into the area that I think, I think I, we are always interested in is like large organizations that have a lot going on. And I think their needs in the application security space, like, you know, well, I shouldn't answer the question for you, but I think there's a lot of similarities, but there's something about the scope of application security at like a gigantic global bank or, you know, a government agency that I don't know. Like, does it change, does it add new things or, or does it change things or is it the same? How, how are things different in the application security space? Security? Well, security is completely different yet the same as it was 30 years ago. If you look at the, you know, OWASP top 10, it's generally the same controls over the last couple of decades. Even when we start going into like the OWASP for APIs, it's, it's similar, you know, you're not gonna have the same channel attacks. It's not a GUI you're using, but similar type of attacks. But in a modern app world, this, the, the, everything is code. You know, your infrastructure is code. One thing that we're going to be talking about a lot more is your infrastructure building materials. You're maybe we'll call it an i-bomb, I think is what we're looking at as terms. You know, not only that, but the application building materials, the construction of all these applications is code and it changes how we approach them. So in the past, you know, a good example, I'll get log4j. It happened in our near future. You know, we all remember it. There are customers still trying to identify which of their apps have vulnerabilities to log4j and how to upgrade them and maintain them. And when you have a large company, if you had say 2000 applications and you had hundreds of development teams working on those, they're all doing it differently. If you didn't standardize five, 10 years ago, when you start coming to this next log4j, you're like, okay, you got 2000 apps, but it's all different stuff. And if we look at one thing where we talk about a lot of standardization, getting that common image you're starting from.

So you have the commonality across things. We're even doing our own releases. We're trying to standardize our own builds, how it comes together. It makes things like a log4j easier to address. It makes it, you know, the image, you know how the inventory is put together. So you can say, okay, I'm just going to change this basic image and it applies to 20% of my applications in one swoop. That makes the world different. In fact, there's a term that people would say you want to be, you know, secure by default, you know, which means you want to have your default configurations. And I tend to call it like table stakes. And in fact, I even push vendors like VMware or Google or any of the vendors out in the world, you should have a default secure configuration. You should have out of the box, this is what you get secured, authentication, your logging, all those default configurations are there for you to use. So we can get to the business of actually securing the applications because we spent too many decades focused on just upgrading servers. I talked to one firm, they had so many Windows servers, it took them 18 months to upgrade them. Oh, wow. So you never upgraded. You just constantly going. So how do we, you can get to a point where you're actually having thousands of nodes and automation. They can upgrade in days, you know, weeks at most. You know, we have, we have some customers that clusters so large it takes weeks, but it should not be 18 months. I mean, at heart, like basic, what I hear you saying is that simply the advance to being able to define things as code, you know, actual code and the configuration and infrastructure as code. That in itself positions us for much easier security and upgrades, I guess, and maintenance. It does. If we get that basic table stakes done, you know, if we know our infrastructure and the applications running, the building blocks of those are just always updated. If you think about, you know, the ideas we came up with years ago, the three R's, you know, we're paving the environment every week. If you upgrade your environment now, the hard thing, you know, code to your developer, you've learned these problems that you upgrade Java. Sometimes you can break things. So we need to have that communication in someone who's running, writing Java apps. Someone on the team needs to be following the release notes and understand what breaks and build tests around it. But we need to get that table stakes of the VMs, the applications, the building blocks of your routing, all the things you build your environment with.

They should just be up to date. They should just be at the latest versions. And if they're not, you should have an understanding of what controls you need to put around them. And that should just, again, table stakes, default secure, should how it be. Now we can focus on the real application security. We can focus on real risk, which is, I think, where security teams really want to focus on because applications are the gateway to the data of the business. And we don't want to have applications insecure because some Java library needed to be upgraded. Yeah. Well, I guess that's part of the challenge, right? I mean, there are certain things you can control that are going to be sort of the same, right? If everybody imports the same third-party library, then that third-party library, if you can make sure that's secure, everybody sort of, you know, consumes that. But then there is also the custom code and the education around it. I think you've, I mean, you've often said security is about, is it people, process? What's the third thing you say? Probably technology. People process technology. So you can cover the tech maybe, but then there's the education of the people as they write new code. And security has to have an arm in that as well, right? Well, security, the hard thing, you know, other fields have this, but security has had the problem of technology has always been tried to be the answer. So if you look at anything in security, like just in the S-POM vulnerability scanning space, there's, what, 40, 50 companies every few months being just, like, funded to create. There's an oversaturation of technology to solve the problem, when realistically, it is those people and processes. You know, we have policies. I'm guilty of this. I wrote policies at Wells Fargo decades ago that I'm willing to bet are still there. You know, it's just... Hopefully they were good. Yeah, well, it was Oracle. So I know Oracle is still there. So the question is on the version I wrote it. So the upgrade process part of that. But yeah, I think I thought it was good. I'm pretty happy with it. In fact... I'm sure. I'm sure. If you wrote them, I'm sure they were good. But it's one of those things that the policies, how do you change them with the modern tools? And the people themselves, the way we train security...

I was talking earlier on the show before we started around the idea of the way we train people to be in security nowadays is either they learn on their own, they do, like, bug bounties, they do ethical hacking, they try to figure out, and they very specialize in the application or networking side. Or they go to college, and they might have a computer science degree with a specialty in cybersecurity, but that specialty is they're not treated the same. You know, when you have that CS101, you're starting to learn Java, they don't teach you, here's how you securely code Java. They don't teach you the mechanism, which is, to me, one of those frustrating things, because there's no developer today that's not going to work for a retailer doing PCI, healthcare, some government organization. No matter where you go, the code you have to write is going to need to be secure. And if you learn things, it's like if you learn to teach someone a language, if you're trying to teach a language, and they come back later and say, oh, well, that was wrong, let's change this in the middle, muscle memory has already been made. It's a hard... I mean, you don't generally have people who write unit tests even, right? There's no unit test for security. That's actually, I think, that the step that's happened, when we say DevSecOps, that's really what I mean is the people in process. You know, we're getting developers and security teams to work together, because security people see things differently. I'll be honest, I'm a very optimistic security person. I recognize the ways and attacks that happen, but I believe we're getting better at it. My friends are going to joke at me for saying that, but I truly believe we are getting better at it. But in this testing side, unit testers, you know, the common question, like when I used to do PCI audits, is that when I was going to a company, I said, okay, do you do testing? They're like, yes, we do testing. But then I have to ask the follow-up question, is it functional testing? Because think about when you were given a development assignment, you're like, here's the function I need to do. So the tests you write confirm that function. But it doesn't generally include security testing. Like if you have a login, well, did you test failed logins? Did you test, you know, try and make sure an account exists through password resets? All these little things that attackers are known to do, are we writing those tests? Or even better yet, what is the security community doing to provide, you know, unit tests that can be scripted?

So if you go to OWASP, you know, what are we doing to actually make it easier for developers to add some of those basic tests in that process? But this is the change that security is going through now is trying to get that people and process better. And I've seen it work great. There's one bank I worked with years ago. I'm really, it just, it's stuck in my head so strongly because we actually got 54, 56 applications in eight weeks in the production of four different data centers. Because every week during that sprint, security was there saying, I need to have, okay, we're working on this one function. And it talks to this database. I need, because of our policies, this test done. And then the end of the week, that test was done. They validated that that would always in the release cycle be testing that process for us. They had continuously integration of other requirements and then testing in the end. And that's how they were able to move really fast. And they can continue to move fast because the tests were already written. So they need, you know, both sides need a little guidance in working together. And that's really what the change is happening. It sounds like a lot of sort of a combination of that shifting left of security and also breaking down that silo where security was often sort of handled by a security team with tests later in the process, separately from whatever the development, without, you know, probably without a lot of visibility and even conversation with the security team. Very, very, very, very little. In fact, it was called throwing over the wall. You know, you would finish your application. You'd throw it over the wall. Security, if they're lucky, would get a copy running somewhere and then do their tests on it with any knowledge, without knowledge of what's going on. When I was a pen tester, one of the things I approached, the way I approached this is, again, the app-centric mind point of view. I didn't want to, even better yet, when I was actually, when I was working at a bank trying to hire pen testers, you know, so pen testing is a really specific practice. There's people who do physical pen testing. There's application. There's networking. There's data. There's people, the social engineering side of pen testing. And when I was hiring people to come and attack the bank I was working with, I was getting each of those personas together. Now, what's missing when you're having the security testing is I don't want to hire somebody.

If it can cost me $40,000 to hire a pen tester, I don't want to spend 80% of that budget to discover what I could just give them. Here's the application diagram. Here's the data flow. Here's the developers you have access to and understand the logic that was written. Let's find the real risk in the application, not those things that we already know about we're trying to validate. You know, a lot of security programs will hire people to validate their assumptions to justify the budget of the tools they're getting versus, again, that default secure configuration. We're doing the basic table stakes of upgrading everything every day. We know where things are at. We can focus on the real risk of the application. So when you're hiring security testers, you give them the knowledge. You know, there's what's called the black box and white box testing. I'm a white box fan. I want to make sure that you have all the knowledge you have. I'd rather spend two days in a deep dive than six weeks of you discovering what I could have shared in two days. It's just, to me, a waste of effort on that side. So if we, like, I think there's at least two groups of things that we've gone over here. And to take a layering approach, as we like to do around here in computer land. You know, like, there's, I almost want to say the stuff you're saying is, like, table stakes. A lot of it is, like, let's call it, like, infrastructure and platform security. And it's just, like, the systems that you run on and the way you have them configured, particularly when it comes to, like, networking access and how, where you get your software from and your ability to, like, upgrade it or patch it or whatever. Like, that's kind of, like, in this, like, table stakes platform area. And then there's the, like, chef's secret ingredients, which is application security, which is sort of, like, that's where it seems, like, most of the variability and just, like, unique wackadoodle stuff happens, right? Like, like, it takes a lot more, like, like, kind of curious, exploratory thing to figure out what's going there and also to make that layer secure.

Because, like, you know, for example, you, I don't know if it's out yet, but you and some people have been working on, like, a PCI document for, like, our Tanzu products, right? And as I recall, you don't exhaustively go through everything at some point, but it's sort of, like, here's a payment card. What's I stand for? I forget. Oh, it's PCI, payment card, PC. Now you're getting me screwed up. Payment card industry. There you go. It's, you know, I don't know it well, but there's, like, three or four subsets of it. Anyways, the point being, it's a document of, like, if you want to handle credit cards and debit cards and other stuff, like, here's how you would secure your goop. And a lot of the things in there are, like, you know, great. It's, like, you should make sure you don't just randomly download container images and use them, right? Like, that would be cool. And then there's more, like, I would say difficult things to achieve, like, how you manage certificates and making sure they're trusted and the ability to rotate them and stuff like that. But that's sort of, like, I feel like it's straightforward. It's a lot more straightforward than what you're going over at the application layer, which is, like, well, did you write tests to make sure you wrote code that may or may not exist? Right? Like, you're sort of, like, certifying just stuff. I mean, I can't even find the words because it's so vague. It's just, like, I don't know. Did you write bad code or not? We kind of got to go look at the code and see what happens. That is the hardest part of the testing. So, like, PCI is a great example, as you have there. So, PCI has been around for a little while. And it goes through changes every couple years. So, they just had the PCI version 4 of the DSS, which that's not the document I shared with you. That one's actually, like, several hundred pages. It's in-depth, all those things you have to have in place. And what happens is it's confusing when you have new technologies. So, back a while ago, I think about 10 years ago, I have to look at the dates, but there was the virtualization. They created a SIG that said, okay, virtualization is new, but how does virtualization fit into PCI?

Because PCI has all these controls. So, they had a white paper that came out of best practice guidance for that. And recently, there's a working group started, which we got myself and some of the TKG engineers and a couple other folks from inside Tanzu and VMware participated with them in the PCI SIG on the writing of, from PCI, their best practices for containers. It's a big word. PCI best practices for containers and container orchestration tools. Yeah. So, that was a big sentence to basically say, what's the best practice on this space? And if you look at the document, what I did is I took that document and then we applied it across Tanzu and said, okay, Tanzu, we have all these application things. And if you're looking at PCI, it really comes down to an application running in a card data environment, CDE. And it talks about the controls of the platform, the infrastructure, the applications. And that's really what PCI is protecting is the card data within the environments that run card applications. So, it fits you very well because we make applications that run in banks and retailers and places that have credit cards. So, one thing our customers look for is, well, PCI has its best practice. What's VMware's response to the best practice for your products? So, that's the document that will be coming out soon. We're in the final edits right now. And it's going to go through all these sections. And if you look at the table of contents of it, as you mentioned, it goes through authentication, your secrets, your PKI, your network security. But if you look at PCI, PCI goes, you know, application, you know, it goes from firewalls to your data, you know, you're basically your platform, you know, hardening security, your data encryption standards, your transmission standards. So, it's more, it's not containerized focus. Like, there's stuff that talks in this new guidance around container images and patent and runtime security and things that are not, you know, there's not an easy overlay for PCI. So, it's kind of guidance of, well, in this space, how does this apply to PCI? And then we provide our own interpretation of the tools and products we have around that space. Because PCI, it also is people, processing, technology. You know, a big piece of it is talks about policies. We can't provide guidance and policies.

It's up to a customer to do that. But we can provide answers of, you know, if you're building applications, how do you make sure you're building it right? But there's a whole section of PCI called, you know, it's in section six that deals with the application security. And it goes into the way you write code. And that gets a little interesting because it's like you said, you know, we can do the table stakes. We can get the platform that runs it all the way up to date. But when you're doing application security, it really gets fishy. You know, it's how do you validate someone did input injection validate, you know, protection. So, as an example, when I'm talking to development teams and security teams around observability in the modern cloud space, you know, the looking for an attacker, you know, doing blue team stuff or actually being, you know, watching for the attackers, developers might do input validation, which is one of those tests you're doing inside of PCI or any just general best development, best practice or security. But what are you doing with the output of that? So if someone injects, you know, it submits a form and they submit a 2000 character string with that form that tries to do injection into a command line. Well, that's going to fail your input validation test. It says, I only take, you know, social security number here. No, it's only mean not, you know, the seven digits or whatever the digits are. And it says, this is an input validation error. Well, are you logging that? How do you observe that in your observability? And, you know, looking at the tools and trends, we do a lot of demos on our observability products, but we usually show like spikes in CPU or spikes in network. Well, this would also be a spike. You know, if you see, you know, one or two validation errors, it's okay. If you see 6,000 in a minute, someone's doing something. And generally, application attacks are very cumbersome. You don't just like jump into an application and say, I'm going to break it. Unless you have the source code and you know where it is, you've got to find it. And it's very noisy finding it. If we can just detect them before they find it, you can block most things. Are the tools, I mean, all of the whole industry of software on containers, because it represents and it leads to this explosion of sort of scale of data to analyze, right?

So observability has had to advance a lot. Do the same observability systems that we use for managing our applications and our infrastructure, are they sufficient for being able to track and manage and audit security data at scale? Or is there need to create additional observability kind of, you know, systems for that? Yeah, we don't need to create anything new. I think, honestly, you know, looking at, you know, I hate to throw the names out there, but, you know, the RE operations tools, you know, if you look at those or Datadog or any of these tools, the tools are there. You know, security events are just that events. You can't have the log monitoring looking for logs, but typically even looking for logs, you're pulling out events. So the hard part is building the metrics of what events you're going to monitor. And I think that's where it comes, again, there's people and processes. If you're going to, at scale, if we're solving this problem for a scale, these companies have the multi-thousands applications. Well, one, if they have standardized images, you know, we talk about the technology using the standard platform, standard images, things that make it easy to maintain the default secure config, then they can focus on the app side. Well, logging, you know, if you have 2,000 development teams, you tell every one of them to log, log in failures or other errors in the app. How, honestly, Cody, you've worked with development teams. You know, Corey, you've probably worked with a couple in your life. How many different versions of that log file do you think you'll see? If you don't standardize and say, we need to have these type of events with, you know, so we're not telling the developer what to do, but there are some things I need to get in a consistent manner from the different teams. So we have to have some standardization that everyone abides by. And that's where having a common way for developers to interact with documentation, you know, again, maybe a portal for developers, you know, where you can actually have standardized documentation, standardized paths for building, you know, like the building blocks. If you're going to build an application, you know, that set of building blocks or accelerators that can actually say, here's how you're going to do input validation. Here's how you're going to do your logging. Here's how you're going to do your authentication. Here's how you're going to do data log, you know, your data connections.

All those things are predefined. Again, default, secure. Then everyone has the same mechanism they're building from. And then security only needs to build one model to watch for. You'll need to have a different regular expression for every different development team. Yeah. Yeah. No, sorry. Go ahead. Oh, I was going to say, I mean, you bring up, you know, you know, there's almost this universal thing that, of course, there's exceptions, footnotes and whatnot, but like variability is not cool. Right. Like, like the, the larger the organization, the more, I don't know, some formulaic way to put it, but the larger the organization, the more benefits you're going to get from reducing variability from standardization. Right. Which is not necessarily the case. Like, I don't know if it's the case when you go smaller down, but like at some point, some fancy curves intersect. And like, once you reach a certain size of organization, like standardization wins out for whatever you're giving up for it. And, you know, I mean, you provide just one, you just provide you went over one thing where like, I mean, log files are a great example of that. We're just like, if I have, you know, it's not only like when you're going over earlier, if you're a large organization, you've developed all these applications, but then as happens in certain industries, all of a sudden you find yourself owning gigantic rivals of yours, perhaps in banking. Like, and then you've multiplied your portfolio by whatever. So you have all these acquisitions and different policies and like, so you have a huge amount of variability already. And just like, you could imagine 500 different ways of logging something. And then that's just like a hassle to put up with. And like, so it does seem like it's, it's, I'm, I'm, I'm spending a lot of time on this point because it's hard to like describe the value of standardization often. You know, how do you balance creativity because you, you don't want to stifle developer creativity, but at the same time, does a developer need to think about how they do authentication?

Is that where their creative juices are flowing? If they are, then cool. Maybe they can work with a team, make a standard that works for more development teams. But how do we balance that? You know, we even had a problem here inside VMware. You know, how do we balance the need for functions and creativity and features while trying to balance the need for the everyday, just standardization patches, all those things that come, it's a, it's a fine line to balance. So you feel like you're not stifling that creativity that got you to the point that you are big enough to have the need for all the developers. Yeah. I mean, ideally the better you can solve the problem by maybe consolidating, deduplicating, having every, if, you know, if you have one law, if, I mean, it's, it's sort of this, I mean, I know you're an optimist, so you can see this future, but if you have a company and you can have one sort of API that people use for login so that they don't have to worry about it. Then you do free up their time for creativity in their, in their space rather than having to recreate the wheel for login. But as Coté's pointing out, enterprises are large and then you have acquisitions and, you know, between the ideal and practice, there's, there's, there's that gap of like, you know, can I really get everybody on using one login API? And if you have, even if you don't have acquisitions, which that's also a huge question, just having more than a dozen development teams and then trying to make a standard around that means someone's going to have to change what they've written. And how do you approach to detect that? You know, how do you approach, you know, who gets that debt? How do you, you know, how do you budget so people have time to work on making that standard? Because you already have existing code you got to work with. Now I met with a bank a few weeks ago and they had an acquisition where they're going through the same problem. They have, they only had 10 developers internally because they didn't do a lot of development. They had a lot of off the shelf banking products. Well, they acquired a bank that is a hundred percent container driven that, you know, has hundreds of development teams. So their, their whole world is changing as they're figuring that out. And how do they plan in advance while not causing a problem?

Because we all know acquisitions also mean that you're going to have two years of things not integrating and the customers want to, you know, they want the integration. So, yeah, do you find one of the, one of the things that, that I think is true for the platform space is that as we moved from virtual machines to containers and then to container platforms, and then maybe, you know, more sophisticated container platforms built on top of Kubernetes, more comprehensive platforms. We saw this a lot with Cloud Foundry, right? We talk about platform teams that could be just, you know, two, four, six people total to support a very large enterprise. Are you finding that, I mean, security seems so broad in scope that, like, I wonder, do you, are you seeing that security teams are able to get smaller to support larger organizations or are we not there yet? I think security teams have been traditionally small to begin with, but they are segmented. You know, there, there's, you know, in a large organization, if you're going to have, you know, like the, the large retailers or manufacturers, you know, we already have several hundred, if not several thousand applications. Those, those, you're going to have your, your security operations team that just runs and watches events and, and they, that's all they do. But there might be segmentation of, they watch end, endpoints, like our desktops and laptops versus servers. It's a different skill set of what to watch for. There might be some, or it might be the same team, depending on how they put that together. Then you have your access and identity management teams. You know, those are generally people have processes around onboarding. So if you have an organization with 70, 80,000 employees, you're going to have a lot, you know, even, even we in VMware, half of our company has only been here for what, a year and a half, two years. And we're, we're what, 30,000 people. That's, that's a lot of people's accounts to change every day. So there's dedicated teams to that. There, there's dedicated architects who just work on the designing of the, so there's already been some segmentation around those different areas, but the teams aren't traditionally very big. I, I was working with a company out in, out West and I can see where it was, but they, they have a small security team.

They're, they're a fairly old company. They've been around for a couple of decades, but they're, they're trying to figure out that scaling problem because they don't have the ability to grow. Cause as, as they get more and more containerized apps, there's more and more ways their team is interfacing with these teams because we have found that everyone now can scan containerized apps. So everybody is involved in that security story. So when, when security things come up and they have to have an in-depth conversation and you actually help the developer or help the platform team understand the risks of that security, what happens when you now have, you know, a thousand apps with all those conversations and they aren't standardized on common images. So it's a thousand different conversations, but the team was only 10 people to begin with, you know, so we have, we have a bigger scope now and the teams have still been small. So I don't, I don't think we're going to see any optimization of security for probably five or 10 years because I think it's driven by two things. One, there's a lack of people in security space that we need more security people. But separately there's the scope, you know, understanding application security is completely different than understanding network segmentation at its core. I mean, they're tied together, but we don't train this. So it's experience is going to be part of it. So you need to have more senior. I don't think that we're going to have the automation in place for the security side for several years. You know, we saw this conversation on do-it-yourself versus using pre-built platforms and having opinions around this. You know, we're still trying to please everybody. And I just don't think we're at a point where the security teams, which are already small, will see the optimization because they don't, there are no developers usually on security teams. You know, they can't automate these things. They depend upon either bringing developers in, training developers, you know. So there needs to be some changes. Like I mentioned earlier, the teams on the platform side and the application side have had two decades to get used to automation, agile, extreme, those tools. Security teams have had five years. So we're five years into that 20-year journey that developers are already at.

And let me ask you, how often you run into development teams that are still struggling with modernizing the way they do development? So I think security teams were a good 10, 15 years behind the ball on that with a whole new set of tools everyone's trying to learn at the same time. And not enough people to help cover the current load and then work on the new one at the same time. So we're a couple years out. Yeah, you're starting to answer what I was interested in talking about next, which is to do one of my well-known statement questions. It seems like if we were to borrow from the DevOps world, as you were just describing, I'm summing up a little bit here or summarizing what you're saying, that what we would like to move towards is automating as much of security as possible. And kind of getting in that area where, you know, there's the platform security and the app security. And again, going back, you know, I imagine a lot of whether it's PCI or DOD, whatever, like all these different security specifications, you could, in theory, get to the point where you had like a special interest group, a SIG. And they were like, you know, here, like, almost literally, here's a YAML file and use that, right? Like, you know, of course, that's a little, maybe a little too low level. But sometimes, you know, it would just be like, yeah, like every time you download this version, it's going to have like a default password. So remove that, right? Like, kind of like, just automate all this stuff. And then there's the things that you can't like immediately, you can't automatically automate, but you can, following this idea of compromising ultimate agility by standardizing, you could say like, you know what, this is just how we're going to manage containers. And you have to use our registry. And like, maybe it's going to take three months to get a cool new feature in a project that you're using, because we're a gigantic bank, and we need to be secure, right?

Like, and, you know, I mean, that's kind of worst case scenario, but it's sort of like, we automate all this stuff. And now in the, you know, in the same thing you would hear about, like, from, you know, fancy platforms as a service, like Cloud Foundry and stuff, like, we need, like, I don't know, five or eight people who manage that, right? Like that layer, because most of it's automated. And then we can shift most of our security resources to being like that ideal state you were talking about earlier, where you have the development team, and they're doing their stuff. And there's, like, a security person there, like, you know, leaning back in their chair, and like, have you tried this? Like, how about these 10 things? Like, if you, like, if you're making a login window, you need to try these things, and let's poke at that. And then, like, whenever you're at the window where, like, you are giving someone a higher security, like, rating, you're upgrading a user to an admin, we should test these things out. Like, you know, like, all that application layer stuff that is much more, I would assume is basically, like, artisanally crafted per code base, right? Like, it's hard to... You have some standardization on some of that stuff. You know, there's some things that you don't want to, again, you don't want to have everybody define how you log in. You want to have some basic standardization on that. But you mentioned that the data, you know, the password part, that actually is, there's a vulnerability in MySQL that is fixed by changing default password, that the Helm chart in the application catalog changes that password. So, again, that default security, not secure by default, but shipping out default security. To get to that point where you can have a small platform team, then make sure that the VMs that run the platform, that have the container images, that make the applications, all that is up to date. You don't have to think about it, you know, whatever your cycle is. Now, there's one exchange I'm working with out in Asia. They're doing it every six months. I keep pushing them. We need to at least do it monthly. You know, one of my favorite stories is hearing up on main stage on SpringOne a couple years ago, the idea that, you know, in big banks, you know, changes are really coordinated.

When I was working at Wells Fargo a couple decades ago, I would work on firewall changes through the day. And then twice a week, we'd have a 11 p.m. to 2 a.m. call with the two engineers doing the actual changes in the firewalls, me there to make sure that they met the conformance tests, and then 40 executives to make sure their applications are still running. And we need to get past that. And what happened is, it gets to a point, if you can choose the right applications, this is key, you can make these platforms, but if the applications you put on them are not properly designed, they have no error budgets, they have no high availability, they don't allow you to actually reboot platforms. What happens when you upgrade your database? You have to reboot or migrate a database. You have those circuit breakers and things within what you, so the application needs to be built for these platforms. But if they're done right, we should just have the platform with a small team automating the entire table stakes. It's just, you know, we have that pre-built guardrails definition, which, you know, comes into, you know, our story. If we actually even look at, you know, say, ARIA guardrails, I'm not sure if you looked at that yet. You know, we can actually have, we actually have the idea that we could pre-define a PCI environment or a banking environment, whatever the controls you want to have. It just builds that environment, deploys your application service, your Cloud Foundry, your TAP, whatever it might be. And then from there, the applications just push automatically. Table stakes are done. You just maintain the upgrade of that. The controls are on or in place. You're using reporting on the backside of it through some sort of, you know, cloud checking tools to say, okay, all the controls are required. I'm auditing them. I can provide an audit report daily to my audit team. So the controls and the environment are there. Now we just can focus on the application. You know, who is using it? What's the consumption? What's the patterns? What's actually being attacked or not being attacked? We don't have to worry about, you know, did, was there a vulnerability in the library that's in the container? You know, the scanning of containers should not really be needed in the end because we're going to get a new container every week. And there are some vulnerabilities that are never going to be patched, but generally those are very low risk. But you still need to understand the risks to them. I want to get to the point where we're having the conversation on understanding those risks to those long running vulnerabilities or the risks the way you've written code and not worrying about upgrading your VM or upgrading your container.

That should just happen. You know, a small team can maintain a very large environment for that. We don't need to. We need to get back past the date where we're saying, well, when's your upgrade cycle? It should be assumed. I'm upgrading regularly every day. How close are we to this vision? I think applications are the hardest part for that because a lot of applications aren't designed for that. But if you look at some of the most successful Cloud Foundry customers, they do upgrades in the middle of the day. They do it, you know, they're doing upgrades about every 7 to 10 days based upon the release of us releasing TAS every 10 to 14 days. So they're just consuming it as the updates come out. How do you see us? How close are we in the Kubernetes space to that same vision? I think we have the mechanisms for supporting platforms that upgrade like that. There needs to be a few tweaks. You know, some of the places that, you know, we might have to do some manual pipelines around it. But I think the platform itself, Kubernetes, the tools that are actually providing, you know, the automation of applications pushing into the Kubernetes, cluster API, you know, all the backstage stuff, all those pieces come together. We have automation in that space. It really comes down to are the Kubernetes applications being designed? Are they properly designed to handle an infrastructure that's continuously upgrading around it? And that's where it gets really interesting. We start thinking about, you know, the errors of Kubernetes. You know, people will deploy an application to a cluster or maybe an application to two clusters and then use like something like an Ivy Networks or an F5 to load balance those. You know, I think what we're seeing is this trend toward recognizing an application isn't just a single cluster because clusters go down either through manual maintenance or unexpected things. So the idea that we're having this space for applications run that's realistically a multi-cluster organization. If you think about the scale of any of these large applications, they're not single Kubernetes cluster anymore. There are many clusters tied together with meshes and ingress and egress through proxies, you know, whatever it might be. It's these complex things that the idea that a single cluster shouldn't be a problem. So, yes, I think we have the tools in place for continuous maintenance.

The applications are the real question. Did you design an application that's highly available, multi-data center? You can actually take a data center offline, you know, like Dick's Sporting Goods did on SpringOne Day. They had two Cloud Foundries running, they just turned one off and it just kept running. Did you design the application? And that's the question we should be getting to is are we helping customers make applications that are ready for modern security, modern platforms? So we can have the default secure modern platform in Kubernetes, Cloud Foundry, whatever it is. That shouldn't matter. That should just be handled in the background by automation if possible. I mean, it's interesting because, like, what you're saying, like, I've heard of this idea, right, of, like, you know, if you have an application, you should code it so that it can go down, right? But I have not actually heard it in the context of security. Normally, you hear about it in terms of, like, well, if your application, you know, keep your state outside. So if your application needs to go down because of a glitch, usually you think about it in terms of hardware failure or network failure. Can your application sustain the failure of the infrastructure around it? But in reality, what you're saying is, is your application coded in a way that allows a security process to intentionally take down the system around you in order to patch it? Well, Netflix actually championed that. You probably have heard of chaos engineering, your chaos monkey. Yes. Yeah. But still chaos engineering is about what if there's a network glitch, right? It's not. It can be anything. Your chaos engine can be, you know, can disrupt your access to your registry. It can disrupt your access to a cluster. It can mess with service mesh. Anything in your clusters is fair game to turn off or on. Right, right, right. So, you know, an upgrade can simulate an upgrade. It can simulate an outage. It can simulate an attacker knocking a single microservice offline. So it's the approach toward making applications resilient. Yeah. So tell me, like, if this is a reasonable line of thought. Like, it seems like, based on what you're saying, let's see. You got this new architecture for applications cloud native, which also means you've got new infrastructure for, like, running containers instead of VMs or, you know, bare metal.

That's orchestrated by something, which is likely Kubernetes, at least by interest at the moment, to orchestrate your containers running. And then, you know, and then, you know, next slide, you throw up the crazy CNCF, like, project chart. Like, all the plugins. Because I think another thing that, like, I come to appreciate almost on a weekly basis over the past three years is that, like, and I mean this in a good architectural design way, is that, like, Kubernetes actually doesn't do that much. Like, it's this little core that basically just, like, places stuff on, I'm going to really simplify it, places stuff on computers and make sure you have what you want on there and then make sure that the stuff, the little apps that you put on all the computers can talk with each other. And there's a little bit more that it does, but that's kind of it. And, like, all these things that you would assume an infrastructure as a service does for you, you pull from that slide of all the projects and all the various things to add in there. And then the issue there is that it's all very new and frothy and exciting. And so I suppose you could, you know, if I knew how to do math, you could do the, I forget which one has to be in an order, but you could do either the permutations or the combinations of all these different things. And it probably would be, like, well, that's impossible, right? Like, all the various different ways you could combine this stuff together. So you've got that. And then, you know, so that opens up the need to basically revisit how you go in and you make sure your infrastructure and platform layers are secure. Now, you may not have to completely redo everything. Like, you may not have to redo how you hand out certificates or how you store, like, secrets or passwords. But you at least need to go in and make sure it's still applicable. And if it's not applicable, you got to, like, do some new stuff for that. And so that is a problem, not to be all funny about it. But, you know, the hopeful thing that you're pointing at is, like, well, we could automate a lot of that, right?

Like, maybe we could go in and use, like, guardrails or just modify a Helm chart. I mean, not just. But, you know, maybe we couldn't do all of the different combinations or permutations of this stuff. But we could say we can do 50 of them, right? Like, or, like, here are, you know, here's a box of opinions. And you can select one of eight opinions of what a platform looks like. And essentially, we can automate doing a baseline, like, secure, not secure enough, but, like, doing as much automation of security, like changing, making, like you're saying, making MySQL secure by default or whatever the fun phrase was. And then, you know, you can pick one of those, and then at least we get that platform security. And, like, I don't know, I'm imagining, like, maybe after you run this mega script, you generate a readme file that's, like, and here's the other stuff you got to do, right? Like, and now you have, like, you know, this is your pre-made meal that we've done for you, and now here's the way that you put it together. I mean, again, being loose about it. But it seems like getting to that point is, like, a major step that would take, like, you know, as you were saying, like, several years where you can actually just automate this stuff. And then, you know, each time you go up to the application layer, I can tell that's the more exciting part because you get very excited, right? But that's where there's, like, more of the creativity and stuff. And it's, I feel like it's very analogous to the, like, first, or, you know, the first two phases of DevOps where it was basically like that, except it was, like, the thrilling world of server configuration. Like, everything, and now when you say server configuration or platform configuration, the scope of that is so much more than it was just, you know, probably when you were developing, you know. Absolutely. And there's huge wins you can have with some of this, you know, certificates or credentials, you know, service bindings. Just a pure idea of, you know, Coté, let me just go back in your past.

When you were developing in the past, I'm assuming you need a database. So, if you're an enterprise, the process you went through of having a database for your application generally involved opening a ticket, someone created a database, someone created a password, probably emailed to somebody who then emailed it over to you. That's right. You know, your application, it became a secret. This password's everywhere now. So, if we can take just the basic, again, table stakes, get those things out of the way, those things that can be automated. We have service bindings where you say, I'm building an application. I want to bind it to a database. And then I want that password to rotate daily. No one knows a password. It's all automated. There's no password or credentials to leak. You know, certificates are the same way. The idea that we can use certificates without having to have this big, huge hurdle of getting a certificate, you know, automation around majority consumption. Like, I've got Kubernetes clusters. I don't even renew certificates. It's all Acme. They just renew every three months on their own. I never have to think about it. So, taking that out of the picture means we're not spending cycles monitoring hundreds of certificates for maintaining and upgrading and having had someone dedicated to making sure we don't go offline because our SSL certificate expired. Or having a database password expire or somebody leave and you have to change a password. You're like, okay, now who knows how do we rotate these passwords? Taking those tables to take things out saves so much more time on those people who are trying to work around it. Now we can actually start focusing, as you said, on the fun stuff. Well, I'm a security guy, so my idea of fun stuff is probably different than the average person. Well, so this gets to the next thing, you know, I was interested in talking about here, which is, you know, I look at a lot of surveys and I get to do some analysis of our own state of Kubernetes survey, which is always fun. And, you know, with Kubernetes or with any new technology, like concerns and problems, like security is always like number one or number two, right? And, you know, we've kind of, we've provided a little bit of the answer here, but like it's making me realize even more that like just to see like security as a concern is sort of like, I don't know, to be a bit aggressive in it is kind of a nothing burger.

It's just sort of like, it's like, well, yes, but what of the five, you know, not 500, but what of the many things is the concern for you? And I think that, like that leads to the next thing is like, I mean, I vaguely know what OWASP is, right? Because I remember that, that, that came about like in the kind of like early DevOps days. So I remember seeing that and like, is that like sufficient? Like, like, like, is, is, is there a list that like, let's say we're, uh, nevermind the cut, the complexity of like three giant banks that have merged together and now they got to deal with that. But like, let's just say we're building a banking platform, right? And we're, we're, we're going to build a cloud native platform. And then we're going to, of course, develop, uh, in Java and spring. And like, can I just go to like OWASP.org and like go through their things and I'm more or less cool? I mean, obviously, as we've mentioned many times that the application layer, you're writing code and like, that's more artful, but it's sort of like, what is the list of things that's behind that security is my number one concern? Is that, is that like catalog somewhere? Not as easily as you'd like it to be. Um, so at a high level, if you're, say you're in banking, well, first question is, which region are you in banking? Because you have Singapore monetary authority, you have the FCC, OCC, we have the FDIC, we have, you know, we have all the FCC probably for transmission. Anyway, uh, either way there's, there's FFIEC, which has banking and, and their testing methodologies for banking in the backend. If they're doing credit cards and PCI fits in and they all refer to OWASP. So that's, that's one piece of it. But when you start looking at infrastructure, there's other standards that are coming out. There's, there's the CIS, which is how you approach hardening. So if you're going to deploy MySQL or Apache, what are the common hardened methodologies for hardening the application? If that's going to run on a Linux container or a Windows container or a Windows VM or a Linux VM, there's a hardening standard that you'd expect to have shipped by default with those things or ways for you to tune those. So all of these standards are going to have, you know, you must follow industry standard hardening, which OWASP is not going to talk about hardening.

That's the open web application security. So there are ties to the platform and the application security. Just like there's, there's an API OWASP, there's other OWASP, but then you have CIS or STIG for hardening, STIG for the federal government, CIS for the rest of the world or U.S. federal in the rest of the world. But then you're going to have even more on top of that, you know, how do you actually make a secure application? So Google recently released Salsa, and again, I'm going to probably butcher the term, it's SLSA.dev. And it's basically secure, it's a supply chain artifact. So the parts, the dependencies, the containers, the things that come out of building applications in a modern environment, what are all the security risks? Everything from the developer committing code to supply, you know, actually your registry, your build process, are you building things consistently? And can you validate and attest to that? So the supply chain side of building applications, then there's CNAP, which came out of Gartner and heavily influenced by Palo Alto, because they have a lot of products in the security space there. Looking at the cloud native application security, which includes parts of Salsa, but also your actual cloud environment, your infrastructure, the runtime security as well. So it talks about the bigger picture of the running application. Now, FFIEC and PCI may not mention Salsa or CNAP specifically, but they'll say industry standard because standards change over time. Right, right, right. So OWASP has been around for decades, but they're all going to refer to, well, what's the platform? What's the standard for that platform? What's your vendor's best practice that goes with that? So to do all this, you need to start off with your vendor's best practice and the industry standards for the different layers you're doing this. So I have one slide I share when I'm talking about this that shows multiple supply chains filtering through service message into multiple clouds. You can picture a modern app, that big, big circle with all the connections going between it, but it shows the supply chain on each of those. And you have the Salsa side of all the risks in the slide chain, but each one of those connections, each one of those places, there's a security risk providing either a risk-based approach or a tool from a security tool that provides protection. Is there a runtime security tool? Is there a service mesh? Like our service mesh that we have has security tools built in the mesh itself.

So every layer of these has a risk associated to it and then generally some sort of compensating security control and or methodology or practice that goes with it. And if you're doing a bank, all of this is in scope for you. How does this impact the build versus buy question? Oh, well, it's the same impact because if you're buying, and I'll give this example from a financial side. So say you're, again, banking, you're doing a bank co-tay. So you're starting your bank and you decide, I'm not going to build my own core because building a core is really hard. And the actual getting certified, having my core certified is a big uphill battle. So I'm just going to buy a core. Now, if you're going to buy a core from Temenos or, you know, Fiserv or FIS or whoever it might be that produces cores, you might actually be asking them, well, how are you building it? You know, the question we're asking of, like, we as VMware, we are constantly asked, and what we and my team help with is, how are we building our software so that our customers who are receiving the out-of-the-box tools, you know, how can they validate that we've developed it securely? And what trust and mechanisms do we have? And that's where you have the federal S-bomb mandate that came out because just asking a vendor to say, trust me, I'm doing it, is generally not been good enough over history. So off-the-shelf software has an assumption that they're doing good, but we've gotten to a point where sometimes those assumptions are being questioned. So you had the federal mandate that came out and said, if you're going to work with the federal government, you need to provide a build of material so I can understand what you've built your product from. So I can see that you're upgrading, you're not running a version of Java that has log4j from two years ago that you've not upgraded. So this whole S-bomb mandate means you're going to have regular updates to the S-bomb with each new release because that's just the first step. Then you start having Salsa come in, which is great, you've got an S-bomb. How do I know you've built this consistently and securely in the process? So how can you as a business attest to your Salsa? And this is where Salsa is right now. As they produced a standard a few months ago, the working groups are breaking down now into how do you actually do attestations?

How do you, can you self-attest? Do you need to have a third party like PCI as self-attestation or third-party attestations? And PCI has done it by size. So if you're PCI level one, meaning you've either been compromised or you're just large in the number of transactions you do, then you have to hire a QSA to do your audit. The question for Salsa is, we don't quantify that. There's no, like with PCI, they can say, you can't process credit cards unless you do what we say. So there's a big, big stick. You know, the carrot is you get your money from credit cards. So that works well. But in Salsa, it's put together by Google and VMware and Red Hat and the communities come together and say, we want to have our customers trust us better. And as someone who was a QSA, the reason I joined Salsa as a working group is I want to see this attestation side. How are we going to actually validate that? And this is where off-the-shelf software comes. You know, the idea that I'm receiving software from someone, again, that core for your bank, Coté. How do you know that each release followed the, you know, they're going to provide you a guide. We actually have our own guide when the customer asks us, here's how we develop secure software. And how do we actually show and attest that? That's coming through the S-bomb and soon the Salsa attestations that come with it. I expect starting to see companies having that in the coming time, in the years. Can you talk a little more about this concept of attestations? Because, so, I mean, you're talking about S-bombs, right? So, a secure bill of materials or a software bill of materials, right? Where somebody who produces software says, here, this is what's in it. Or, so you're really, it's sort of like a self-reported bill of materials. It's a bill of materials, but it doesn't tell you how you've built it. So, it's just a, I can get any container and I can get an inventory list of that inventory of that container and say, here's the bill of materials that made that container. But how do I know how you've actually, you know, layers are an OSA model. You've put these together. How do I know that the process you used to build that? Was that a Docker file on someone's laptop that's going to have the dependencies change from one build to the next? Is it a build service? So, how do you provide that? And this is where it's also coming together, trying to figure out how do we validate and report on these attestations?

There's two sides to it is, one, if someone's going to do self-attest, you have to have some level of assumption that they're going to do it honestly. You know, you have to trust at some point the contracts and stuff to help validate those trust conversations. But I'm a big fan of, if you're a big firm, say like a VMware or Google or Microsoft, I would expect to have a third party come through, like a QSA and PCI. And if you're going to have this testing methodology, you say, here's how I do my builds. Here's how I do my code check-ins. Here's how I do all those things in Salsa or CNAP, whatever it comes out to. How do you prove that? So, some things can be done through code. You know, if, say we're building, you know, our own applications in Tanzu with TAP, which we are. There's a project I actually work on building our own products with our own products, which means we're going to have similar build methodologies, similar consistency in containers, similar consistency in the actual way we're actually building and releasing our software. And the benefits for those is that means we now have a better way of attesting this. So, what the TAP team is working on right now is, as Salsa is figuring out what does it mean to attest, so we're trying to figure out, well, how do we in our own software provide that? Because some of these attestations, I would expect to be digital. I would expect, again, this automation to come in. If I'm attesting for CNAP, you know, I get out of the Salsa to CNAP, if I have a cloud environment running my platforms, I should get a report every day that tells me all those controls I built, the security groups, the access controls, the secrets, all those things the cloud provider makes for my building my environments, I should be able to get a report every day that tells me all those controls are matching what I've put and how it matches my policies. So, I can then show my auditor every day over time. Wouldn't it be great if we had a time-based graphic log for this stuff? Anyway, it would be the idea that we have this attestation self-handling through automation, and then those things that tie it together would be a manual, either internal, professional. In PCI, you can get, actually be a QSA where you're trained and you actually do audits. There's also a PCI specialist. I'm sure somewhere in VMware, in one of our security teams,

there's someone who's actually currently trained in the latest PCI to make sure that we as a company are following that without having to hire an auditor for every little question. Similar for Salsa or CNAP or these standards coming out, there's a certain attestation we should be able to give internally as the standards are more mature. But there's, how do we actually do this automated? How do we actually get, our first part of the conversation, we want to automate some of the security things. Well, how do we generate those automatic reports and put them in a way that we can say, not just to ourselves, but to our customers, how it's done? And this is where, you know, buy versus build. If you are buying your core for your bank code today, I would expect, I'm sure if you were doing one today after this conversation, you'll be expecting your core provider to not only provide an S-Bomb, but the details of this build process. How do I know that the next release I get is going to follow that build process? If you made changes to your build that impacts the way the software builds and runs, I'd want to know that because a core banking product is the center of the bank. That's where all, you know, that's where your money is kept. You know, money's all digital now. It's in that core. So I think even if you're building yourself, you have the same questions. How do you prove to your customers? In the end, that's what it's coming down to is how do people trust that the work you've done is the work you've intended to do? Right. Like you're saying, you know, when it comes to the ultimately like a testing that something has been done properly, I guess you go all the way back to there's a prime mover of just like, oh, I trust that person, right? And I trust that they set up all of the automated stuff that therefore generates all the like signing and things that like are cool. But you do have to trace back at some point that this is a, I was told they set up their salsa this way. They did just like generate all, you know, start some, some, obviously it would be a lot of work, but like you do have to have some sort of kernel of, of, of trust at the beginning that kicks all these things off. Well, there's always that, that conversation trust, but verify. And then going back into security, security is generally in companies driven by compliance.

So PCI is a compliance standard, you know, so these standards come out. So FFIC for banking, Singapore banking authority, you know, even GDPR across Europe, how do you handle the data when customers ask you to delete or change it, you have access to it. So having these compliance regimes drive security requirements. But I think, again, going back to what I'm, I'm hoping that the changes we'll see in security is we can automate those compliance regimes. So we can really start focusing on the real security risks of the businesses we're running. So, so that, so then as, as a final topic, let's, let's talk about like something, you know, it's, it's kind of in the build by area, but is it like, like, okay. So both what is the current like security, like CISO, whatever culture and like the one you think should exist, right? Like in the same way that you're like automating this stuff would be fantastic. Like, you know, what, what's like the vision for the future and also the current as far as like, like, would you go to like a vendor or a cloud provider and like buy full stack bank compliance? Or is it, or is it like, you don't do that instead you go to like auditors who do it or you do it on your own or like, what is, what's like the current like culture of like, again, if, if I were, if, if Cora and I were building our bank, like, do we just go to like, you know, Fiserv and they just do it all? Or like, normally do you involve other parties or do other things? Well, Fiserv would want you definitely, definitely yes to just outsource and have their, their SaaS or on-prem product be the end all be all. Well, and, and then, and then, for example, also like, you know, as, as delightfully, I, I, I love the, the very professional sterile nature of any document about PCI compliance, but there's a great joke in, in your document, which is like, well, you know, PCI says you need to have security cameras, which Tanzu has nothing to do with. So there's like, you know, there's all this other stuff that like, I, I mean, I'm kind of blowing up my question here, but it's sort of like, what is the current method that people go about doing this stuff?

Do they, is it single source or do you have multiple people or like, how does it work out for any of this? I wish there, well, there are people who can help with various things. So, so before I was starting the bank before Pivotal, I was actually at a private data center with my brother and we actually hosted PCI customers. We had all of the IT, you know, everything in PCI, except for those policies and the physical side of where their office was. We did, we did, we did, they gave us a copy of the, so we were their entire IT for running it. So you can outsource a lot of that stuff. There are definitely firms who would like to do as much of those pieces for you, but realistically, it, it is not a single provider to provide all of it. Because again, people process technology, you can outsource parts of the technology. Generally, you're not going to outsource all of it. So going back to the Fiserv banking side. Well, what if your bank also wants to have loans? You know, are you using a provider to do your, you know, know your, know your, know your question, you know, the KYC, know your customer of doing the loan application process. And in that process, Fiserv won't have that. That'd be another vendor. So each other business you get into will probably have other vendors in that space that are providing some tools. Then you, then you start looking at, well, how do I integrate them? How do I tie them together into one common tool? And that's what I think you would focus on if you're starting a bank is you'd find the best of breed for the products that you are providing. And those that you think you can do better, that's where you can actually make your business around. You're actually going to integrate these in a certain way, or maybe you're going to find out that the way you're doing, you know, loan applications is different than the rest of the world. You're going to change it. You actually make your own, know your customer product and actually sell that to other people on top of your banking. Maybe you'll build that yourself. So it really depends on what is your business and how you're going to approach it. And it really is an integration story of tying those together. Right, right. So, so like, like, and then as you were saying, right, you have not, not only like industry and sub industry things you need, like, like in banking, you know, you have different, different, I'm sure different things for like loans versus like trading. And then you also have regional, like nation specific, and then also whatever a super group of nations is like the EU, like, like you have standards from them.

Your technology itself is different. You might find, you know, say, say you've got like a big bank, say you've got 2000 applications, you might find that you have 50 or 60 core base, you know, accelerator images that you want to tie together to those. So it's not going to be one image across all of them, it might be 50 different images, which means that different sources for those pieces. I was talking to one bank, actually a company that does a lot of credit card processing. And I said, well, how would you feel if, if all these products, because they're a big VMware customer, you know, if you had better, you know, you have the S-bombs, we can provide, you know, vulnerability details. Well, if we provide all this for you, would that make your life easier? And he said, well, except for the fact that we also have Microsoft, we also have Google, we also have, you know, it lists out the 40 other vendors you have. And his job as a CISO is to know the risk and security. So it's great we can automate a lot of the application, the platform, but he's going to run that inside of a Google and Microsoft clouds, which have their own sort of constraints on those and tools. So he has to manage all these different vendors that are integrated together just for the different business lines of his company. So it's playing all these different places. And again, their teams are small. So now we have the need of diverse skill sets of these different types of products. So it still is kind of a challenge, but it's a fun big picture challenge, which I think is why I feel like you're all here. I like the approach that your brother and you's business there kind of implies is that if you think of your stack as a bunch of layers, then what you're looking for in all of your, let's call them suppliers, your suppliers in that layer is that they basically have that stack of certifications and compliance. That's what you need, right? Yep. So that, you know, they go, they go to, they go to you, you and your, they go to the brother's PCI compliant managed service provider. And essentially, I mean, I would imagine you would say like, we have all these initialized standards in the scope of our layer. You look at VMware, our SaaS offerings, we have ISO 27001, we have, you know, the SOC 2 audits, we have the Cloud Security Alliance.

There's based upon the type of business, some of them are doing FedRAMP, you know, base objectives. So based on the customers and the needs of those customers, again, those regulatory compliance frameworks drive certain sets of standards and audits and validations that happen that we need to provide to our customers to show that attestation. And I think that the application layer is the one that's the biggest focus now beyond, you know, we've had SOC 2 for a long time. Now we're actually going to the next depth when customers are asking for SBOM. In fact, I've seen several customers talking about putting in their MSAs, the requirement of VMware providing SBOMs. And even PCI, we've mentioned recently, version 4 came out, the vulnerability scanning inside PCI used to be, you know, addressed high-end criticals. Now it's not only just high-end criticals being addressed, but starting in 2024, 2025, I forgot the exact date, customers are going to have to do risk assessments on every low and medium finding, too. So if you've got 2,000 servers in your PCI environment and you've got to do every low and medium finding risk assessment, your team wasn't big enough to begin with. How are they going to handle that? And that's all, is that all part of, I mean, if the application is now the biggest focus, that is what Salsa is all about, right? I mean. Well, Salsa is the building blocks to make up the artifacts that you run in your clusters. So it provides security of the coder, the committee into the registry, the registry security, the, you know, also as well as your source code repository. You know, all the parts of building software and the artifacts that come around that, Salsa is looking at how you protect those. But it doesn't deal with the running side. So that's where CNAP comes in. And it doesn't address, Salsa was not meant to address PCI. It's just, it's a supply chain conversation. But I expect, you know, if you go through the PCI best practices document, you'll see parts of where Salsa comes in. Like it talks about your container orchestration tools, your registry and building process. You know, those are parts of Salsa on that. One other question is, there's been this sort of, I don't know if it's a vocabulary change or just sort of like a foe we're having, but secure software supply chains and just supply chains in general are sort of like the term of the day when you're talking about taking an app from code to production.

Does that, is that instead of or on top of the way we have used CICD as a term for so long? Well, CICD is a nuanced conversation. So you can't have a supply chain without a CICD, but you can have CICD without the full supply chain because supply chain must take it back to its original practice. You know, they were building cars. You know, the supply chain is where you gain your chip from that's made and shipped to one place and tested and shipped to another place and put onto a PCB and tested and shipped. So the supply chain, in fact, there's some standards coming out around, you know, how do you actually do this, you know, the S-bomb or I-bomb or other building materials, which includes the physical side of supply chains. So supply chains, you know, say you're flying out of a jet and they're doing maintenance on the engine, they can tell you by the serial number on the fan blade of that jet engine where it was made and the tensile strength as it was tested to prove that that blade met the requirements as it was shipped on the supply chain. So supply chain is that big picture story from manufacturer to release that you can attest all the individual pieces, where they came from, how they're built, how they're tested, how they're validated to get to the final product. So supply chain is a bigger picture of everything it takes to make that application. And realistically, a supply chain, if you think of a modern app, many modern apps aren't just one service. You know, they're going to be 50 or 60 microservices, if not hundreds or thousands of them. So realistically, a supply chain is all of those, but there might be thousands of CICD pipelines that make that work. So supply chain is really that bigger picture story of the application in its whole and what it took to get there. Well, that was great. I think I think I have a little bit of an idea of what people are talking about when security is in a survey that it's, you know, I, I, I would say there's a lot going on, but it's not incomprehensible. It's just a lot. It's, it's, it's like knowable complexity. Uh, but, but, uh, it's, it's not just as simple as like making pancakes, which I guess could be difficult if, uh, if you don't have experience.

Like anything that's complex that you break it up into parts and you, and you treat those parts and you take one part, automate it. But I'm going to go back to getting one of the favorite phrases I learned in my pivotal days, which I'm still using today is even these platforms and the automation that go with them. They are products make sure that you have a PM, a designer, you know, the security team, the whole balance team for that platform. And it's not just, you know, once you've built it, the engineer, the platform team runs it, but things are going to change. We're going to have new standards tomorrow. We're going to have new ways of changing, you know, Kubernetes is still maturing. So as these platforms change, they need to also have the same treatment to them as a supply chain and security. It's not a destination. It's a journey. Yes. Security is a journey. Well, on that note, if people wanted to join you on your journey through the exciting world of security, do you have, do you have any, uh, any web logs or, uh, or, or LinkedIn profiles, social media accounts that you would point them out? I'm going to start with LinkedIn, um, David's in, uh, in fact, I put DMZ on my thing here, but if you just search, you know, VMware DMZ, you'll probably find me. Um, I'm fairly easy to find. I've never, you know, again, be in security. People are like, Oh my God, we got paranoid and hide ourself. I'm fairly visible. I am on Twitter, but I don't post much. So I'm not gonna really share that one. If you find it good for you, uh, or just see me. I'm, I'm, I'm every year I go to, I've been going to DEF CON since DEF CON six. So I'm out there in the desert every year. I hate the desert. So let's make it fun and enjoyable. So come visit me there. Um, but also any, any of these security events, RSA or b-sides, or even our VMware Explorer, I, I tend to be out there talking to people. If you are out there, find me on LinkedIn, email me, uh, at VMware, um, and highly available, highly available. Yes. There you go. All right. Well, great. Well, thanks again for being on that. That was, that was really enjoyable. And as always, this has been a Tanzu talk. Perhaps you watch the video on our YouTube channel, or maybe, uh, you are subscribing to the podcast. And if you're not, if you've listened this far, you should by going to Tanzu talk.com and you can find the show notes for this episode.

You have to hunt around for it. Cause I don't know how it generates the URLs for it. Uh, the thing that I use, but it's fine. Just search for Tanzu Talk. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.