 Live from Boston, Massachusetts, it's theCUBE. Covering AWS Reinforce 2019. Brought to you by Amazon Web Services and its ecosystem partners. Well, welcome back everyone. We're here at CUBE's live coverage here in Boston, Massachusetts for AWS Reinforce. First inaugural conference run security. I'm John Furrier, Dave Vellante. Next guest is Dan Hubbard, CEO of Lacework. I've started out of Mountain View, California. Great to have you on. Thanks for joining us. Thanks, thanks for having me. So, you know, Reinvent was developers. Reinforce is kind of like CISO's coding security. Cloud and intersecting with security. This is a new kind of show. What's your take on it? Super impressed so far. I mean, there's what, 8,000 people here. You know, we have literally hundreds of demos lined up at the booth. So really impressed so far, first impressions. It's a good move for Amazon to do a security conference. Don't you think? I mean, really smart. Yeah, really smart. It's a lot more about defending than, you know, a lot of the security conference about offense and vulnerabilities and how to find kind of holes and weak cracks. This is really about, how do we defend, you know, our security in the cloud? Talk about your company, your mission. You guys are a startup. You're going after a hot space. The CISO's, or CIO, is the one you talk to. They want a new breed of supplier service provider. Certainly cloud, APIs are going to be critical in all this. So, you start to see really smart platform thinking, systems thinking around, companies around, the security challenge and opportunity. What do you guys do? Explain what you guys do. We really believe, you know, this new wave of cloud, IS and PASS, really needs a new architecture. It's a whole new architecture from an IT perspective, so we need a new architecture from a security perspective. And the great thing about the operating model is you can do a wide set of things and then go deep in the areas that are really important. So what LACE Work does is we allow you to secure IS and PASS services with compliance, configuration, host and container security. And there's one platform that kind of wraps across all of those different areas. And that's targeting for developers, right? So they don't have to think about security all the time? Is that like one of the core things? Yeah, so definitely, so in almost every case, security is unlocking the budget. However, DevOps is involved. And DevOps is involved from an influence. But, you know, it used to be that, you know, developers would ask security for permission. Now security is going back to developers and asking for permission to secure the infrastructure. Yeah, and you said that the architecture has got to be different because the IT is changing. So cloud security needs a new architecture. What are the fundamentals of that architecture and how is it different from security on-prem? So I think it has to be SAS. So it's got to be delivered multi-cloud from the cloud. You know, if you're going to secure the cloud, it really should be from the cloud. There's business models that should be different. You know, it's almost always a subscription. There's not perpetual models. You know, you're annually reoccurring your revenue. You're always keeping your customers happy and you're always innovating. The pace of innovation has to be really quick because the pace of the cloud is moving at such a dramatic speed. So those are kind of business-oriented, you know, that's kind of a different definition of architecture than I thought. Technically, is it a fundamental do-over or is it fundamentally similar? Well, you know, there's some of the tenants which are the same. You know, we need to get visibility. That's very similar. You know, we need to have controls. We need to have auditing. We need to find threats. However, the way you do it is very different. So you don't own the hardware. You don't own the racks. You don't own the network. You got to get used to that. You got to live above the responsibility line. So you have to fit within their infrastructure. So what that means is you need to be very API-friendly because we're sucking a lot of data. You know, on Amazon, we're pulling in configuration and cloud trail data. And you also have to be able to deploy inside their infrastructure. So we support things like Kubernetes, things like Docker, or we also interoperate with things like Bare Metal and, you know, in the AMIs themselves. What problem do you guys solve? You know, every startup has that cultural vector in. They kind of sometimes you weave into a market and then also you get visibility into a key value property. What's the key problem that you solve and what's the benefit? So the key value we solve is if you are in the cloud or migrating to the cloud, we give you compliance, configuration, and threat protection across all your clouds. So irrespective of which cloud you live in or operate in, we give you one central threat detection engine and which gives you visibility but also gives you compliance and controls into that. So Amazon has this, you know, shared responsibility model. They're protecting the compute, the storage, the database and customers are responsible for the endpoints, the operating system, the data, et cetera, et cetera, et cetera. And Amazon certainly has tools to help them. What is fuzzy to me sometimes is, you know, where AWS leaves off, where ecosystem partners like you guys come in, you obviously have to keep moving fast. Oh yeah. To your point. Absolutely. But can you help us sort of squint through that maze? Sure, yeah. I mean, the easiest way that I can explain it is, if you can configure it, you have to secure it. Everything below is the provider's responsibility. That said, there are different areas where things are kind of peeking through the responsibility lines. So what I see is a world where there's not 50 security vendors that you've bought, like in-premise or traditional data center, but you're interoperating with a provider. So, you know, the big three providers, open source, and then a solution like ours. So it's more about how do we interoperate there together. But what we do is we sit actually right within your container and on the host themselves with an agent, and then we suck in their APIs. So technically it's a little bit different. So the threat of containers is an interesting topic, all right, you're spinning them up and you're spinning them. It makes VMs look like, you know, child's play. Yeah. So are you using specific techniques to sort of fake out the bad guys, and make it, you know, raising the bar on them and their cost, are you using sort of algorithms to do that, spin them up, spin them down? Yeah. You know, like the shell game. What we do is we get baked right into your infrastructure. So every single time you deploy and run through CICD, a new container or a new app, we're baked in there. And what we're doing is we're looking at all your applications, processes and network traffic, and then we look for the known bad and the unknown bad based off of that behavior. So it's native security in the container at the point of creation, not an afterthought. Correct. What's your take on Kubernetes landscape? Obviously, pretty much everyone's kind of consolidated around that from a de facto standard. That's good news. Where does it go next? Cause there's all kinds of stateless stateful applications. That becomes like the service mesh conversation. You got all kinds of services that could, you got Lambda out there, automating all these things. These services are being turned on, turned off in real time, you can't be, you can't get long at all. It's incredible. I think Kubernetes is the fastest growing enterprise open source project ever. Where every customer we talk to is either in the midst of migrating, migrating or just thinking about it. That said, the world is looking to go multi-cloud, but most customers today have a combination of in-premise, bare metal, AMIs, Kubernetes containers. What we're doing is we give you visibility into your Kubernetes infrastructure. So we talk pods, nodes, clusters, namespaces, and we allow you to secure the management plane and the communication between those. So it's really critical when you're deploying those from a security perspective that you know what's happening. The ephemeral nature of it is very different from regular security too. You need to answer questions like what happened for 10 minutes during this timeframe six months ago? And that's really hard with traditional tools. Yeah, it's really hard. And that's really where the automation plays in. Talk about the journey of where your customers are going at because we're seeing a progression kind of categorically, you know, three kind of levels. I really wanted to enter the cloud. I really want to take advantage of that cloud and very aspirational, maybe not realistic, but it's on their plans. Then you've got people who go out and do it, get stuck in the mud, the wheels are spinning culturally, whatever's going on, and then full-on cloud-native, hardcore DevOps, eating glass, spitting nails, just kicking ass and taking names. So you've got the leaders, people who are kind of in the middle and then people jumping in. Where do you guys see your benefit? What are some of the challenges? How do you guys get into those areas? I think it's a super dynamic marketplace because what's happening is every big company that may not be fully cloud-native is buying companies that are cloud-native. So then they become the sexy new way to deploy and then they start figuring out how to deploy there. So one of the trends we're seeing is core centralized security is becoming governance and tooling and then they're distributing the security function within the app teams themselves and that model seems to work really well because you've got security practitioners baked within the DevOps team, but then you've got a governing role with tooling and centralized tooling from there. That said, depending on the customer or the prospect, it's all over the place. Many systems are scratching their heads saying, oh, I don't know what's going over the cloud guys, they've got a different group that's running it, they're trying to figure out, how do I just get visibility? I know my name's, I'm the one they're going to come after if there's a problem. So it's really all over the place right now. But you're a service, so you're baking it in, we're natively into the containers. Yep, it doesn't matter. The container aware, if you will. It doesn't matter if you're in-premise or not, containers or not, we work across all of those. So was that the hook for your sort of original idea, your business plan, your investors, you've raised I think 32 million, you got 70 employees. What was that hook? What attracted the investment community? So I think the original idea was, if you're deployed in the cloud and you have a breach, how do you know you had a breach? You know, things that happen come and go very quickly. All the data is encrypted on the network. I don't have full visibility on the network itself. So that was the original idea. How would I go back in time, kind of a time machine to find out what happened? Then we originally supported AWS and it was really about visibility within the AWS infrastructure. Then Kubernetes happened. Now the big hook really is, am I using containers? Am I using Kubernetes? And then how do I make sure I'm compliant and then I'm following best practices? And then that breach scenario still definitely happens. Everybody tries the service before they buy it and they're almost always finding out problems along the way. What did Kubernetes do for you guys that made a kind of such a step function change for what you guys were doing? Was it because they had the dynamic nature of dealing with the services, was it the orchestration? What specifically was the benefit? I think the orchestration, the single management plane from a security perspective is one of the big things. If you get access to that one brain, if you will, you have access to everything. Obviously the ephemeral workload is big. Yet it was an enforcement. Kubernetes with service mesh and things like pod security policies allows us to hook APIs in a way that you can actually write enforcement versus a firewall or some of these old school ways of killing packets. Yes, you got a cloud native approach. Kubernetes comes along. It's aligns with your philosophy and architectural approach. And we run Kubernetes ourselves. So our entire infrastructure is based off of Kubernetes. So we were a Kubernetes user very early on. So we just take the things that we learned to our customers. So here's a quote from a CISO. I won't say his or her name, but I want to get your reaction to it. When talking about dealing with suppliers, looking for the new generation of suppliers, like what you guys are doing, I would put you in the new classification of emerging suppliers. This is the message to all the suppliers in the room. I happen to be in there. Have an API and don't have it suck. Because UI is shifting to API, UI focus is shifting to API focus. So we are evaluating every supplier on their APIs. Your reaction to that? I absolutely agree. So there's two levels of APIs. One is you have to interoperate with the APIs from the providers in order to get the data properly, right? That's a big, big component. The other is you have to have APIs for your consumers. And you can't automate without APIs. So that's really critical. That said, I will disagree a little bit on the UX and UI aspects. If you are triaging data, it's really important that you have the right data at the right time, and visualizing that data in a way is pretty important. How real is multi-cloud in your opinion? I mean, everybody's talking about multi-cloud. A lot of times we've said multi-cloud is kind of a symptom of multi-vendor, but increasingly it could be a strategy. In terms of you're thinking about your total available market, your market opportunity, how real is it when you're conversations with customers? It's very real. We were really surprised. We first started supporting AWS, and then we added GCP and Azure together. Now we have a core principle that everything we build has to be parity across all the clouds. And we had a huge uptick across GCP and Azure very early. So we were really surprised. What we were surprised about was it's not portable workloads. So it's not about taking one application distributing across multi-cloud. That's kind of fiction. That doesn't happen very often. It's either you bought a company that's in another cloud or use a past service in another cloud, or you have just two totally disparate applications in a large company that just happen to be in different clouds and the data's in different places. They don't need to inter-operate. So it's just a little different, but we're seeing- Kind of horses for courses as well, right? Some clouds may be better for data-oriented. You're point early and we've heard this in some of the CISO conversations. M&A becomes a big factor because they get new teams and new culture and they might have different cloud approaches. But I totally agree with you on that. I would say I would even go more further and it's absolutely fiction between multi-cloud because it's just got latencies on the connections, whether they're direct connections or not. They've all gone the factors. So I've always said, and I kind of believe and I'd love to get your thoughts on it, is the workload should dictate to the infrastructure which cloud it should use and go with one cloud for that if it makes sense. And then use multi-cloud across the workloads and the workload can handle a better cloud that the cloud selection be driven by the workload. It's certainly from an application perspective. You want to silo it, you know, probably there. I think what's interesting about, you know, a lot of the work each provider is doing in security, a lot of people ask, well, you know, why don't I just use all my provider security tools? And the answer is, they've got some great tools. You should use those for sure. But there is a bunch of technology above that that you can use. And then you've got to span across multiple clouds. What you don't want is three different APIs for security across every single cloud. That's going to be a major pain. You have to stitch those things together. And that's where you guys come in. Yeah, absolutely. What's your take on this show reinforced against inaugural show? Love to go to the inaugural shows. If they don't have a second one, we can say we were there. Yeah. Reinvent, you made a comment before we came on. Reinvent started out, we were there early on as well. It was developers. Yeah. It wasn't a lot of fanfare. In fact, you could wander around Andy Jass. It wasn't crowded at all. It was great, great time. That was younger now. Amazon's gotten much stronger, bigger. What's the vibe here? Is it developers for security? Is it CISOs? Is it, because what's your read on the makeup and the focus of the attendees? So I think it's a little bit of a mix of both, which I think is good. I've met a number of developers or what I would call kind of new breed security engineers. These are engineers that are more interested in how does the cloud work and interoperate and how do you secure that versus reverse engineering malware with assembler, which a lot of the other places are really about the threats and what are the threats and how specific are those? This is really a little bit more about how do we up our game from a security perspective in this new world order, which is really good. Which is cloud very agile, very fast, horizontally scalable, alas, all the goodness of cloud. All right, final question, developers, bottom line is developers continue to code and do the things whether it's a DevOps culture of having a hackathon and testing new things out, which is how things roll now. Getting into productions hard, what's the developer's impact to security? Is the trend coming out of the show that security's baked in enough to think about it? It's kind of like how configuration management took that track and DevOps took that away. You mentioned that earlier, you can configure it, you can secure it. So similar track for security, going the way of automation, what's your role? So automation is going to be critical for sure and then it's going to be a combination of security and DevOps together. Call it DevSecOps, call it security engineer, whatever you want to call it, but it's definitely going to be a combination of both. Security people aren't going away, that's for sure. We're still going to need security experts and focus is just a critical aspect about this. Dan, thanks for the insight coming on here, Reinforced. Take a quick second, give a plug for your company. What are you guys looking to do? You're hiring, what's going on in the company? Yeah, sure, Lacework, we're going to help you protect all your workloads, your configuration and compliance in the cloud, regardless of which cloud. We are hiring, websiteslacework.com and we'd love to talk to you. What's the culture there? Culture's great, very fast moving, very fast paced, very modern, we live and breathe by the success of our customers. It's a subscription business, so we have to continue innovating and renewing our customers. Got to be smart, probably, to deal with Kubernetes and containers, thanks for coming on. It's theCUBE coverage here, live in Boston. I'm John Furrier, Dave Vellante. Stay tuned for more live coverage after this short break.