 from our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hello, and welcome to the CUBE Studios in Palo Alto, California for another CUBE Conversation, where we go in depth with thought leaders driving innovation across the tech industry. I'm your host, Peter Burris. One of the biggest challenges that every enterprise faces, they try to keep up with competitors today, is how to introduce the speed of adding new digital services, new digital capabilities, new types of customer experience, new types of operational challenges, et cetera, but do so in a way that retains the safety that's associated with traditional ways of doing IT. That leads to a set of tensions that exists between how DevOps, which is really driving that new speed equation, and security, which has been historically the locus of thinking about how to ensure that assets, digital assets don't get misappropriated by the business and by bad actors. So the big challenge is how can we bring the people, the technology and the processes together so we can achieve both the speed as well as the safety that are required to really drive business forward. So to have that conversation, we're joined by a great CEO today, Dan Hubbard, who's the CEO of Lacework. Dan, welcome to the CUBE. Thank you, great to be here. So let's start by getting a little bit about Lacework. Tell us a little bit about Lacework. Sure, yeah, so Lacework, we're really excited. Recently we raised another round of funding, which is going to really allow us to focus totally on this problem, which is how do we balance speed and safety and how we secure these modern architectures and infrastructure in cloud security. All right, so let's talk about, I mentioned up front that this notion of speed and safety, it's more than just a technology problem that goes deep into how businesses run their enterprise today. What is the experiences that you see your customers having as they conceive of how to move forward to this new world? Yeah, so for cloud migrants, what's happening is the development groups and applications are moving to the cloud at a very rapid rate. And every company that they're buying is cloud-born and they're moving at a really quick rate. And they're leaving security behind. So from the people aspect, the security people need to get involved with the developers to figure out how they can work in this coexist in an environment that allows them to deliver obviously, both security and speed or speed and safety. So the problem is essentially that we need to move fast as a consequence of competition and technology change and achieving, being more opportunistic, which is a fundamental tenant of agile and business today. But we need to do so in a way that provides a set of assurances that are required by compliance, by law, by new privacy regulations. How are you seeing customers solve this problem generally? How are they even thinking about solving it? Yeah, so I think the first thing is how they're not succeeding, which is typically they go to their incumbent vendors, security vendors, and attempt to apply something that is not purpose fit for this new infrastructure, being in cloud and cloud native. So things like taking a firewall and calling it a cloud firewall isn't working. Things like taking traditional technologies like antivirus or next generation antivirus is not working. And what we're seeing working is when you really step back and they really start to understand what, how people are building and developing their code, pushing it out, what is that build time to run time environment look like, and what are the services they're using? And then they need to apply some relatively fundamental security practices to it. How do I get visibility over time in real time? How do I attain compliance that is important to my company, PCI, SOC to NIST, HIPAA, whatever is important to you? And then how can I assure that we haven't had a breach? And if we do, how can we triage that breach? So in many respects, we are trying to bring, tried and true security concepts to this new world, but we need to do so in a way that doesn't drag along to technology limitations or the technologies that were necessarily applied to securing an old style of infrastructure. If I got that right. Yeah, absolutely. There's a number of things in technologies that are really critical here, but also on the people side. We can't bring over some of the old processes. For example, change control windows. You can't have a change control window and something that's running and you're pushing code a thousand times a day. There is no change control window, you're just doing it all the time. But you need to do things in a way that is mapping to the automation and the scale that's happening. In order to do that, you need definitely some technology and people and processes. So it sounds like what you're suggesting is we have to incorporate security directly into the DevOps process so that we at least feature some notion of a Pareto principle where each new push is at least as secure as a previous one, but ideally we're making things more secure as we go along. Yeah, I mean understanding change is really critical because things are changing so quickly. What we're seeing in a lot of companies is a shift over to securities, a governance and tooling org, and then security engineering, which is baked within DevOps teams, whether it is a guild of people that are connected to the application developers or right within the stand up or the group directly. But if I think about kind of the outcome of DevOps, the outcome of DevOps really is this kind of more modern approach to thinking about technology resources. Services is determined as thrown and it means a lot of things to a lot of people, but to a DevOps person, they create something that then can be used as a service by other folks within the organization. So one of the fundamental challenges here, it seems to me, is that historically we've tried to secure the server or the PC or the network or the perimeter or whatever else it might be, but really this cloud native approach is securing some outcomes, some capability, and that's really increasingly we've got to focus on whether we call it a service or something else. Have I got that right? Yeah, absolutely. And I think we spent years kind of surrounding the applications in the development, really partly because we may have not been involved. So it was great. We had firewalls, we had defense in depth, multiple layers that we added on top of the next layer and everything else, and really what needs to happen needs to be integrated. And in order to integrate into the services world, it needs to be as a service. So your security needs to be a service that isn't surrounding, it's actually integrated directly. And that's partly from a process perspective, also from a people as we talked about, but also as a technology. It's got to be really baked into the solution. So one of the things we've seen in our research at Wikibon is that there are, as we think about how to introduce these new capabilities into this kind of DevOps culture, this DevOps approach to building new IT assets, new business capabilities, that if the solution itself doesn't correspond to a way that DevOps works, it itself gets abandoned. I mean, it might integrate at some point in time in the future, but if it doesn't naturally fit into how things operate or how things evolve, then it gets abandoned. How would this new class of security products or services look so that DevOps picks it up, gets the best IP associated with the best security? Yeah. I think the first one is it can't be intrusive. So when you talk about blocking and tackling, it needs to be more about building and engineering than blocking. So you really need to make sure that you're not going to adversely or inadvertently affect the application and the service that's being run. So it's really important to the company. And anytime you introduce that, you're going to get blocked out or you're not going to be involved. The other is that it needs to pair to the tooling that is there. For example, our service integrates directly into JIRA and PagerDuty and Slack, real modern ways that DevOps work. So it needs to be directly integrated. And lastly, the service and the context need to deliver information that serves two audiences, the security people and the DevOps people because the DevOps people are often the ones that are triaging or they know the application and the information, the infrastructure is code. The security people may not. So they have to work together and provide both of those. So as we think about what a modern, secure DevOps function is going to look like, go out, give us kind of the picture of what it looks like in three years. How are they going to be working together and what are they going to be using to do so? Yeah, so I don't think there's like, this isn't the end of the CISO. There's still going to be a CISO, it's an incredibly important role. I think they're going to move a little bit more towards governance, compliance and tooling. They may have a tooling org. For us, it's more important that we interoperate with open source and the cloud providers than we do with other vendors. So having tooling to do that is really critical. Especially in the visibility side. Absolutely, yeah, getting visibility is key. And then there's going to be more security engineers. These are people with DNA insecurity, but also our coders versus the real deep threat specific environment that we see today. You know, I would argue there's probably more people that write code and understand assembler than there is in Python and Go. DevOps people, they don't know what assembler is or are using assembler. So that is still important. There are still attacks. You need to deconstruct them, you need to understand them. But there's a lot you need to do on the security engineering side, which is really how do I program this service? How do I automate and orchestrate it? So today, this is kind of where we're going. It makes perfect sense. But that's not where a lot of organizations are today. You mentioned the difference between built in the cloud and migrating to the cloud. Give us a little bit of insight, visibility and how some of those migrate to the cloud shops are taking this roadmap as they move forward. Yeah, it's super interesting. You know, every, we have customers that span across cloud-born, you know, more startup-y, very tech-savvy and then very traditional, very large Fortune 50 companies. You know, on the latter, they're doing a couple things. One is, they're trying to figure, how do I migrate a traditional app that's been built in a way not for the cloud to the cloud? That's kind of one. And there's all kinds of reasons why you want to do that, scale, performance, reliability, you know, et cetera. The second is that they're being told or have initiatives driven from the top called cloud-first, which means everything new, it has to be that way. It has to be cloud-native and it has to be delivered as a service. And then the last one is that when you actually are building an application and you're a new company, you're probably going to get acquired by one of these larger companies, which means that a cloud migrant becomes a cloud-native company by definition because the company's there buying. So it kind of spans across those three areas. What we run into though is that especially if they buy a company, they're very modern in how they think, they've got very modern practices. And then the traditional security people are going, oh, who are these? You know, what is this new technology? How do we interoperate? How do we take our policies, our practices, our functional organization and map those together? So they're really starting to figure it out. So I think we're kind of in this middle ground. There is very forward-thinking companies that have moved more forward, but still it's very, very early. And you know, we talk to customers, we run workshops with customers. And you know, a lot of it's just bringing the teams together and understanding both worlds and getting to know what are the DevOps, you know, things that they're working on, what are the security people? How do we meet, you know, in the technology and then in the process side? So it's a little bit all over right now and I think it's probably going to get better, worse before it gets better. But I think down the road, as people deploy things like Kubernetes and containers and services that are built a little bit better with resiliency into them, it's going to be a more secure place. And Hubbard, CEO of Laceworks. Great conversation about speed and safety. Thanks for being on theCUBE. Thank you very much, nice to be here. And once again, I'm Peter Burris. Thank you very much for joining us until next time.