In the traditional data center world, security was (or is) very network-centric—firewalls, IDS, network access control, focus on the aggregation of all traffic traversing in, out and across the network. But cloud-native applications rely upon different constructs and methods of building applications. It’s not just the software and technology stack that requires different security in the cloud-native era.
We can’t just surround cloud-native applications with security; we must build in security. And to do that requires an understanding of how container and microservices applications are made using DevOps and how DevOps works to build in security properly. Enter Lacework, a platform built for DevOps teams to build security into cloud-native applications.
Vikram Kapoor, Lacework co-founder and CTO, joins this DevOps Chats to explore API-centric applications and infrastructure-as-code. We discuss how to build security into cloud-native applications through the DevOps-based software creation process, and not rely solely on runtime security technologies. He also discusses some of the planned uses for the recent $42m round of funding.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Mitch Ashley: Hi, everyone. This is Mitch Ashley with DevOps.com. You’re listening to another DevOps Chats podcast. Today, I’m joined by Vikram Kapoor, who is Co-founder and CTO at Lacework. Our topic today is security as a platform. Vikram, welcome to DevOps Chats.
Vikram Kapoor: Thanks, Mitch. Thanks for inviting me. I’m very glad to be here. I’ve been developing applications for 20 years and I’ve worked in systems and security and databases for the vast majority of it. And I’m glad to be talking to a DevOps audience today and share my thoughts on security.
Ashley: Excellent. Well, you have a rich background in security. Tell us a little bit about—I think you were the original founder of Lacework, is that correct?
Kapoor: Yeah. So, I’m the Co-founder of Lacework and the CTO. I’ve been here for, like, the last four and a half years now. And before this, I worked at Oracle for a large period of my career initially, and then I’ve been working on basically data center applications or data centers in one way or the other.
That’s really what kind of motivated me to start Lacework where, you know, solving the data center’s security problem or a cloud security problem is predominantly a very interesting problem and it’s a hard problem and people are kind of struggling with it to kind of do it the right way. And we started Lacework to make sure we can solve it as a platform which kind of does a large number of things versus, you know, point solutions for security for cloud.
Ashley: Mm-hmm. Excellent. Well, it’s great to hear that’s sort of where you came from. Oftentimes, entrepreneurs take a problem they’ve had and go create a company to do it. Sounds like you’ve done that, too.
We had some recent news. I know you had some funding, a funding round of $42,000,000—congratulations on that.
Kapoor: Yeah, thanks.
Ashley: Yeah, awesome. So, not to just talk about the money, but let’s talk about what you might do with some of that funding. What are some of your plans around helping grow the company?
Kapoor: So, we are actually very excited to announce that and get that funding of 42,000,000. Basically, you know, it kind of is gonna go towards the company goal, which is to kind of secure clouds. And we believe that you really need a new generation of security which is purpose-built for cloud to kinda solve that problem. Partly because, you know, the cloud has fundamentally changed the tech stack, and it’s actually very different than the old school collo data centers, even though, you know, it seems as if all I’m doing is entering VMs, but you know, it’s actually a lot more than that. And partly because it’s very dynamic, it’s very loptic, it’s very API centric.
And it’s becoming, you know, more DevOps kind of—the whole DevOps kind of trend is partly because of moving to the cloud and then how that enables people to do things more efficiently. Unfortunately, that also introduces new attack vectors, it makes the old technologies not very useful—like, ideas of firewalls that are great, but they’re not sufficient enough in the cloud environment.
And the funding is basically gonna go towards supporting the product innovation at scale and help us cultivate a culture for security and compliance and DevOps to embed security continuously in their environments, essentially.
Ashley: Well, great. Let’s pull that apart a little bit, because you’re talking about a lot of things there, and I’m really interested in your thoughts on this. One is, you know, the technology stack has changed. Certainly, we’ve seen different kinds of software containers, et cetera, cloud services, but we’re also architecting applications, different microservices, et cetera, and then there’s also the culture side of it.
Let’s start with culture and why DevOps is so important to building that into your product and how you create that. I think we’ll talk about sort of your platform strategy next, but tell us about DevOps and how that fits into the picture.
Kapoor: Yeah. So, essentially, if you kind of think about the new stack and the cloud and containers and Kubernetes and microservices—like, the main underlying team in all of that is kinda driving toward infrastructure as a code, right? Like, essentially, you’re not racking and installing hardware any more that’s been done by the public cloud provider. Even if you’re a Cloud Native application, you’re fundamentally gonna deal with VMs and containers and the code that you need to run versus the infrastructure that’s running under the cover. And that world is very API-centric. It’s really—everything is done through an API.
Now, when you have things that are being done by an API, you always need developers to do it. And so, that kind of becomes a DevOps team where you are—you’re kind of developing code to actually run an infrastructure. So, essentially, the code becomes the main team there. And security—you know, kind of derives from that infrastructure. Like, if you design it in and bake it into your infrastructure doing your build-up, I mean, it’s far easier to kind of deal with it versus later on, you know, strapping on a firewall or IDS on the system.
Kapoor: So, to me, like, you know, DevOps and security has become really critical, partly because of the API-centric world, and then having the need for security to kind of bake into the architecture early on versus later in the game.
And the other thing which is also kind of very interesting to me is that containers, on one end, have actually made things very easy for developers to develop, right? Like, I can worry about my dependencies and not about other applications. But at the same time, it also has pushed some of the responsibility from the operations side to the developers now, like, vulnerability management being a good example, or lease privilege being a good example. Like, when I develop something, I need to kind of worry about it at that point and not later in the CM.
Ashley: Mm-hmm, shift left, move into DevSecOps, yeah.
Kapoor: Yep. So, that kind of goes into DevSecOps where, let’s look at trying to basically help our customers kind of piece this together where you have to be able to kind of have some responsibility that goes to developers, some to security, some at run time, some at build time, and have visibility and automation in order to be able to manage your thousands of VMs and hundreds of developers coding and developing and releasing software every day at a very high speed versus doing quarterly releases.
Ashley: Okay, so, some things you said there are really interesting. One is, we have different kinds of architecture. We’re building applications that are API centric rather than just APIs as an integration layer. We’re obviously creating lots of containers, lots of microservices, pushing the security into that.
Talk about how DevOps as a methodology or process or a philosophy of how you build software, how has that changed how you approached building security products for that environment?
Kapoor: Yep. So, I think the—so, in the earlier world, right, like, you know, in the collo and the data center world, security was basically driven through perimeter. And network was, like, you know, the way security got delivered to a large number of people, whereas the network-centric, like, network IDS or a network IPS or firewalls.
But when I think about developers and how containers and microservices are changing the architecture, we have actually built up Lacework from the ground up to actually not be perimeter centric. So, essentially, it’s about the things that run in the environment. It’s about tracking behaviors for every individual entity, be it a user or an application or a container, and then think about scale from ground up where, you know, it’s not so much about a VM one, because VMs can come and die all the time, or scalability happens all the time, IPs change all the time, and being able to kind of think about them as a unit, as a cluster of things so that then you can scale up your security along with DevOps.
So, when I think about a service that, I imagine, scales up during the day and scales down during the night or can burst into the cloud—you know, as DevOps I can do all that today with the technologies that are available to me. Then the security also has to basically take that into account and not produce false positives just because a new VM started or it doesn’t understand that these 20 containers are really the same application.
So, Lacework actually is designed to do that, and I think that’s part of the reason why it’s new security where you have to think about how DevOps works to actually deliver security for them in the new world versus trying to define a perimeter and trying to watch every VM through a firewall rule or microsegmentation of, “This is what you should do because”—well, guess what? VMs don’t last that long. Containers are a few seconds, so I don’t really care about containers, I care about the application that’s running on top of it.
Ashley: Mm-hmm. I’ll have to say, Vikram, you’re warming my heart here, because it’s important the technology is actually believed how we create software is fundamentally changed, and yes, DevOps is a big part of that. But that shift also, of course—now, you’re talking about thinking about security at an API, a security container, not at perimeter of what servers talk to across networks, which is a whole different philosophy.
Kapoor: Yep, yep. Yeah. So, I think that’s actually one of the fundamental shifts, I think, which is kind of driving from the DevOps world into security at this point where, you know, I don’t think it’s enough to basically not understand what’s going on from the visibility perspective in your accounts.
So, clouds are—you know, if you kind of think about cloud evolution, there are three big public cloud providers today and there are hundreds of services each and then hundreds of APIs in each service. And every one of them has potential—like, you know, big JSON objects that they take and then have security implications on your posture.
So, you know, and that’s just the APIs. And then you have resources that you have—like, buckets and security groups and VMs and ports that you may or may not have turned on. And then, along with all that, you’re running VMs and you’re running containers and you’re running Kubernetes and you’re running a lot of stuff in there.
So, for a human to keep track of all that and understand how an attacker will come in from where and go where and what it will attack is basically a pretty hard problem. And to solve that problem, really, you have to kind to get above the physical noise of, you know, which VM, which container, and get to the logical place where you say, “This application and this user or this set of services” and then be able to, from there, derive the security properties automatically and understand what a user does in one environment at any given time so that, over time, I can build a behavior profile for them and then use that to detect when they deviate from their behavior profile.
Kapoor: So, that’s kind of the basis for how we do security in a picture, but essentially, kind of, it derives from the fact that you kind of have to start thinking logical and not think more physical when it comes to assets.
Ashley: Well, I think what you’re describing, too, is, Lacework talks about security as a platform, or as platforms—
Ashley: – which is the comprehensive components of all of that and all of the inner workings of that. How would you describe security as a platform?
Kapoor: Yeah. So, security as a platform, to me, basically boils down to cloud as a platform, you know, as the middle of that. Like, when I think of AWS or GCP or Azure, it’s a platform where I run my application the way I need to do it. Like, I may use SES, I may use SQS, I may use Left Shift or Aurora or some other service.
Kapoor: So, I kind of write my application for my needs. And, similarly, when the security for that application comes into play, it has to come into play for all the services I use, and it has to kind of play as a platform, too.
So, fundamentally, you know, you’re not trying to buy a piecemeal product which solves your, you know, configuration problem and then a piecemeal product that solves an API problem and a piecemeal product that solves your file integration monitoring or host ideas. But you kinda really need to think of it as a platform where you say, “All of these are aspects of my security, and if I don’t do one, I leave the door open for an attacker to come in from there.”
So, interestingly enough for an attacker, if I get into one of your applications through either application vulnerability or through a weak password or whatever, right?
Kapoor: From there, I could get into your cloud account through instant profiles and credentials that I acquire from there and then from my account, I can open your buckets and I can—so, as an attacker, the weakest link is the link I need to go attack.
So, if you don’t think of this as a platform where you kind of comprehensively watch everything, get visibility across the board, protect everything, you are going to leave a door open somewhere, and that’s where the guy is gonna come in from. So, to us—yeah.
Ashley: Sorry. It’s just shedding that kind of shell security approach, that perimeter. Even if you collapse the perimeter, it’s still thinking of it as you’re gonna—everything inside is gonna be safe, protected. It’s not, you have to protect all the layers of it, because any one of them may be an attack vector surface.
Kapoor: Yeah, yeah. In fact, I think that the perimeter, the nonexistence of perimeters today is partly why all the perimeter solutions like firewalls and network IDs basically, fundamentally, don’t work on the cloud. That you just—there is no perimeter.
Like, if you think of S3—you know, in my old world, I guess, S3 used to be a filer sitting behind my firewall, behind in a caged lock somewhere within a room with no API access and I would argue it’s secure because you can’t get to it. But nowadays, S3 is your filer, and—guess what? It’s a giant filer available from anywhere in the world to anybody in the world at any given time, at speed, at cost. And the only thing that protects them from not being able to access your data is a 50 byte bucket policy. And if I get to your account, I can change that 50 bytes.
So, it’s fundamentally, lack of perimeter means that you have to kind of think of this as a very different problem, and that’s why a new security comes into place.
Ashley: Now, to effectively use Lacework, do you have to be approaching this developing your software as Cloud Native applications? Can you do this if you’re just doing Docker and containers orchestration, Kubernetes? What’s sort of the entry point to begin using your technology?
Kapoor: Actually, we support multiple ways to do it. Like, so fundamentally, if you are using these technologies, like container, Kubernetes in a cloud account somewhere, you could—there are two ways we can approach that problem. One is an agentless way where you end up giving us your credentials or your IM role, for example, to be able to read some of the properties of your account and then we can kind of secure that or give us access to your ________ or ECR read only and we can then secure that part. Or, it’s per VM, like a sensor or an agent that runs on the VM and then delivers the security properties of, you know, there are security features that are relevant on a per VM basis.
So, we can kind of engage people on both sides and a lot of our customers start with the agentless thing where they kind of get started on the basic stuff that they need to do and then they kind of, as they become more sophisticate, they end up using more on the sensor and the agent side to give more deeper visibility and the analytics and the ________ detection capabilities that we have.
Ashley: Okay. So, for the elements that don’t require an agent, what kind of security services are those? What is it securing?
Kapoor: Yeah. So, for things that don’t require an agent, some of the examples would be, if you have a cloud account, you want to actually regularly monitor your resources to make sure those sources are not accidentally or by mistake misconfigured.
You also want to look at your APIs and make sure that there is no anomaly in the behavior in the APIs itself. Like, somebody—for example, your administrator who logs in from California all the time suddenly starts logging in from another country. Things like that.
Kapoor: And then along with that, you also have vulnerability management where you also, you want to make sure that the software that you’re really deploying doesn’t have any vulnerabilities in there, any critical vulnerabilities that you need to patch. That’s the third piece that we do for agentless SCU, essentially. And then we do that, obviously, for Azure, GCP, and AWS—like, three big accounts. And I think going forward in the roadmap, we’re also gonna help people with making sure their Kubernetes audit logs and the Kubernetes compliance and all that stuff is also taken care of from an agentless perspective.
Ashley: Okay, great. Well, kinda go back to the culture part of this, a little bit. How do you see security engineers, people that are network security professionals, making this transition to kind of rethinking about security as a platform, thinking about it not just as a perimeter to technology—what are some of the ways people can make that transition? Because I’m sure it’s probably a little easier for application developers to do that, because they understand all the elements of the software that they’re developing, Kubernetes ,et cetera.
Kapoor: Yeah, yeah. So, actually, so I think it’s—there is a lot of good news on that side. But, so, a little bit of perspective before that.
So, essentially, network at this point is basically not very useful, right? Because IT supports change, Kubernetes runs a BGP overlay on top of the base network. But at the same time, for a network security person who has the skill set of kind of trying to understand how to use connectivity as a basis to detect problems. That kind of migrates to a higher level where, if you can get, you know, some tools like Lacework, you know, an application connectivity graph or a container connectivity graph or their behaviors, you can basically apply the same security principle at the application layer. So, kind of try to understand why there is a command inflow coming in or something, what DNS ________ is doing.
So, essentially, you know, that security knowledge kind of translates up to the application stack, but you really need to get to the application of the user. Basically, fundamentally, a lot of the security earlier—people used to do applications, but the IP import used to be proxy for an application. So, I would remember the IP of my database, and I would know the port for my database, and therefore, I know it’s my database.
But nowadays, there is no IP import that’s fixed. So, fundamentally, I think it’s the same knowledge, but you have to apply the application layer. So, you need tools that can let you do that, and then I think it becomes a lot more interesting.
Ashley: Well, it seems like you’re saying, also, that moving from a more traditional security world where things are very protocol centric—you know, TCP/IP, et cetera—to a world where you still have protocols, but of course, now, you’re dealing with software architecture, maybe this is a good approach to help security engineers learn more about that software architecture without having to be experts in it to start out.
Kapoor: Yeah. So, they don’t need to be an expert on it when they start out. But fundamentally, if they look at an application ________ for their data center and imagine you’re running 5,000 VMs and you have front ends and the back end and a middle tier and you have Nginx running and HAProxy running and Kubernetes running—at some point, you know, at the network layer, it’s a complete mismatch. But when you look at the higher level in the logical application layer, you end up seeing a very clear signal of external IPs coming into Nginx, from Nginx getting forwarded to the internal proxies and then proxies getting to the applications and the application then responding and then they’re talking to another of their dependencies and finally going to the DNS service on the other end.
So, for somebody who has done network security, I think it’s a little bit of a learning curve, but basically, you know, it’s a transition to an application world where it’s a similar view. And then the security properties of the network can be translated to the application. But you need to be having tooling that can get you to the application layer to begin with. Otherwise, it looks like a big mismatch of IPs and ports which have, basically, no meaning, and everything is encrypted on top of it.
Ashley: Ah. This has been really great. I have one last question that kinda goes in a very different direction, and that’s you as an entrepreneur, you’ve been doing this for a while—I think about four years since you started and help co-found the company.
What have you learned about being a CTO, about that role or about yourself through the evolution of Lacework that you can share with other entrepreneurs?
Kapoor: Yeah. So, I think one of the things which has been the biggest learning for me here is really how, when you start kind of, start with a premise and you start thinking about the problem that you’re trying to solve, how that problem kind of matures at the base and how you kind of keep pace with it.
So, like, fundamentally, when we started four or five years ago, Kubernetes was just starting out, wasn’t as big a thing it is today. And then clouds were obviously a very big piece and that’s why we started the company to begin with. But like, one of my learnings is to really kind of keep in touch with how—it’s very important to keep in touch with how the market is kind of evolving to make sure you can kind of be where they need to be, you know, when you need to be. So, you need to be really thinking ahead, like, six months to a year.
For example, right now, we are already kind of thinking about how Kubernetes gets evolved and what their roadmap is and how we play with them so that a year from now, we are in the right place where we need to be to help our customers. Versus not knowing about something and then eventually that becomes a problem because we couldn’t help customers.
Ashley: Well, Vikram, this has been fantastic. Thank you for being on the podcast.
Kapoor: Yeah, thanks a lot. I’m really glad to be here. I’ve really enjoyed my conversation with you.
Ashley: I did, as well. I’d like to thank Vikram Kapoor, Co-founder and CTO of Lacework, for joining us today. And, of course, thank you—you, our listeners—for joining us. This is Mitch Ashley with DevOps.com and you’ve listened to another DevOps Chats. Be careful out there.