Rain Capital’s Chenxi Wang on ‘DevSecOps’ – InApps Technology 2022

CloudBees sponsored this story, as part of an ongoing series on “Cloud Native DevOps.” Check back through the month on further editions.

Turning your IT shop into a DevOps shop is the way to go if you are in a  competitive industry based any way at all on the quality and feature set of your software. But, as Marriott has just discovered, all your work will be for naught if a malicious attacker penetrates your system and  wreaks havoc. But how do you get security into the flow of your software lifecycle?

For answers, we sought out Dr. Chenxi Wang, the founder and General Partner of Rain Capital, an early stage Cybersecurity-focused venture fund. Dr. Wang is also the co-founder of the Jane Bond Project, a cybersecurity consultancy.

Prior to that, Chenxi served as the Chief Strategy Officer at Twistlock, was in large part responsible for that cloud native security company’s early growth. Before that, Chenxi built an illustrious career at Forrester Research, Intel Security, and CipherCloud. At Forrester, Chenxi wrote many hard-hitting research papers. At Intel Security, she led the ubiquity strategy spanning both hardware and software platforms. Chenxi started her career as a faculty member of Computer Engineering at Carnegie Mellon University.

So, we want to find out more about security for cloud native operations, and how it affects DevOps practices…

The cloud native environment is such that things just come and they go very easily. You’ve got an ephemeral sort of workload. And you also got very a potentially a large scale system. Lots of cloud native environments have internet-scale applications. So, you got very large systems that are dynamically orchestrated. So that’s kind of the nature of it.

So a few things security cannot rely on is, for instance, security becoming part of an infrastructure, you have to be very careful about embedding security into the infrastructure.

For instance, in the past, you could instrument the server, right? But if you don’t know where your workloads going to run tomorrow. They go from this cloud to the other cloud, then you may not be able to count on this type of server instrumentation everywhere.

If you are using serverless then you can’t really instrument the server, so lot of things have to push up the stack into the application layer. [The instrumentation] travels with the application for instance. Or it’s done through a different set of infrastructure, like security is done through the orchestrator, for instance. So thinking about where in the infrastructure layer security is going to fit is an interesting thing for the cloud native environment.

I’m kind of curious about the idea of moving up the stack to the application layer. Either you think about the application security and you also think about doing as much through the orchestrator as possible because those are the key elements are always going to be there in a cloud environment.

I’m seeing less of the kernel level agents more the user-land capabilities. I’m also seeing a lot of data that is only now decrypted at the application, not in the network. The data security policies all have to happen very close to the application. So, that’s the part that is really interesting I think.

Things are coming out of infrastructure and getting pushed to the application layer. But I don’t mean things that are embedded into the application per se but they are actually being separated out from the application as a separate entity. So if you think about the service mesh — the service mesh is a new capability that abstracts networking and security from the application.

So at the same time as things get pushed to layer seven things also getting more modular in the sense that application developers can focus on application. They don’t have to worry about networking, they don’t have to worry about security and, security and networking functions are being encapsulated into sort of manageable units itself being microservice driven. So I see that as a march trend where things are moving in that direction.

Authentication itself is a difficult thing to do. And so it’s better [this way]. Somebody in the organization sets up a standard for the useful tools [to use]. And here’s your certificate authority because that would be a lot to ask of each at each developer for each application even to do it correctly. That’s something for all of them to agree on something.

That sounds a bit like the Google Zero Trust Model?

Yes. So it’s … I wouldn’t say the Google Zero Trust model, the Zero Trust models actually defined by Forrester. Google had its own version of zero trust, which it called BeyondCorp. And at the most fundamental layer, they are both the same thing. They basically say “OK, so if I’m an application, I want to talk to the other application. I want that network between us to just be a conduit. The network is not going to see me anything other than metadata. It’s not a new process payload is not going to process identities. It’s just going to be a dumb pipe.”

And that has a lot of implications when you cannot do network level, interception and filtering. So things have to happen either on the endpoint or the application. It’s happening more readily  in a cloud native environment because everything is decentralized anyway, and it’s easier to treat [issues] inside your corporate [environment] in the same way as [those] external to your company

Are there issues we should think about when talking about security DevSecOps?

Yes, absolutely. So another aspect of cloud native applications is that they are updated all the time. And as new functions getting pushed to production systems, security has to be with it. Security has to be part of the CI/CD pipeline.

In the past you have with the major releases, you have your security reviews and security testing all done. Everything else stops until you finish that. That doesn’t work anymore, so vulnerability scanning has to be done in a way that fits seamlessly into the CI/CD process.

Are you finding that there are two total providers who are moving in this direction? 

If you look at security, automation is probably one of the biggest recurring themes we’ve heard of late. Security has gone from the manual review to security engineering, meaning that the tasks are carried out automatically. The metrics are gathered automatically, the different tasks are stitched together automatically and reporting is done automatically.

I don’t think we are 100 percent there yet, it’s definitely happening in that direction.

Culture seems to be a big issue that an organization must face when moving to DevOps. It’s getting developers and system administrators on the same page and having them rethink their jobs. What are some of the issues that people should think about in terms of DevOps in light of security? 

So, yes. One thing in terms of culture is I think security products and security technology in the past are predominantly produced for security users right? So you, the users of the product or security operations or security analysts, so have a certain level of expertise and expect certain kinds of information.

Today, I think the expectation is changing in the sense that, it’s no longer sufficient for security people to do security because it’s clear that security is everyone’s business. Right? And, we have to actually engineer or put together security functions that can be used by non-security experts.

So, DevOps is a big push for that, in the sense that DevOps folks are not necessarily security trained or security experts, but they have to be able to use certain tools, to not only meet DevOps, goals and requirements but also do certain security tasks so that security does not get lag behind.

And so the big change is the customer of security is very clearly not security anymore. It is operations, it is platform engineering. It is developers.

Security and ops are becoming more and more one team versus two separate teams. People realize that you just can’t do those things separately and still have an environment that is operationally efficient and secure. It’s no longer the security officer saying “No, you can’t put that up because it breaks our firewall.”

Excellent. So should we even bother with the term DevSecOps or SecDevOps or is it just assumed to be DevOps security kind of part of the agreements?

I think, depends on who you ask and I’m not hung up on any particular terms. I think if you ask DevOps folks, they just say yes, it’s DevOps and the ones that are pushing DevSecOps or SecDevOps are actually security folks

I think probably in some distant future we’ll just say DevOps as opposed to DevSecOps but, that is because we’re still in transition, DevSecOps right now draws attention to the issue. And once that issue is sort of dissipated and that security is successfully embedded into the DevOps process, then everything will just be DevOps.

And, Google really is the one that really practices DevOps best, even though even they did it before it was called DevOps. The operational benefit is astounding if you look at the way Google does its operations/

Then you have lots of companies maybe, you know, 20 or 30 percent of the companies are in the middle, like they’ve been doing DevOps and they’re scaling up on DevOps but they still have challenges, they still are not entirely DevOps and so they still looking at how security can fit in, and there’s a lot of trial and error.

Feature image by Abbie Bernet on Unsplash.