(upbeat music) >> Woman: 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 face as 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 exist 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 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 of 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 in 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. It 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, you know 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, you know being more opportunistic which is a fundamental tenet of agile and business today, but we need to do so in a way that provides the 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, you know, 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 how people are building and developing their code, pushing it out. What is that build time to runtime environment look like, and what are the services their using, and 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, SOC2, NIST, you know 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 man 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 the technology limitations or that technologies were necessarily applied to securing an old style of infrastructure. Have I got that right? >> Yeah, absolutely. You know there's a number of things in technologies that are really critical here, but also on the people side. You know we can't bring over some of the old processes, for example change control windows. You can't have a change control window in 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 the 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. You know what we're seeing in a lot of companies is a shift over to security as 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. Service is a term that's thrown and it means a lot of things to a lot of people, but to a DevOps person, they create something that can then be used as a service by other folks within the organization. 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 outcome, some capability, and that's really increasingly what we've got to focus on whether we call it a service or something else. Have I got that right? >> Yeah, absolutely, and you know 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, it needs to be integrated. And you know, 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 integrating 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 of 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 today? >> I think the first one is it can't be intrusive. So you know 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 your not going to be involved. The other is that it needs to pair to the tooling that is there. For example, you know our service integrates DarkLink, to Jira, and PagerDuty, and Slack, you know, 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's code, and 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's going to look like, 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 SISO. There's still going to be a SISO. It's a 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. You know 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. >> Peter: Especially in the visibility side. >> Absolutely, yeah getting visibility's key, and then there's going to be more security engineers. These are people with DNA in security but also are 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. So you know 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 cloud and migrating to the cloud. Give us a little bit of insight, visibility into how some of those migrate to the cloud shops are taking this roadmap as they move forward. >> Yeah, it's super interesting you know? We have customers that span across cloud born, you know more startupy, very tech savvy, and then very traditional, very large Fortune 50 companies. In the latter they're doing a couple things. One is they're trying to figure out 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 kindsa reasons why you'd want to do that, scale, performance, reliability, et cetera. The second is that they're being told or have initiatives driven from the top called cloud first, which means that everything new 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 they're 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, 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 startin' 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 we talk to customers, we run workshops with customers, and a lot of it, just bringing the teams together and understanding both worlds, and getting to know what are the DevOps, things that they're working on, what are the security people, how do we meet 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 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. >> Dan Hubbard, CEO of Laceworks. Great conversation about speed and safety. Thanks for being on the Cube. >> 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. (upbeat music)