Hear from security veteran Kathy Wang about how security leaders should approach securing cloud native environments. Kathy Wang - three time CISO, rose from the engineering ranks, starting her career as a chip designer. Hear about her background – from Bruce Schneier’s company Counterpane Internet Security (acquired by BT), to her stint at MITRE (the folks that gave us so many good things including Mitre Att&ck), to her work in the cloud native space, having run security for GitLab for two years before joining Very Good Security. Check out some excerpts below. -- RS: What approaches for locking things down without getting in the way of high velocity cloud native development are top of mind for you? KW: I learned a really long time ago that security is a process that cannot be implemented in a way that blocks shipping of products or impedes business operations. The problem is, if you are the type of security leader that implements security processes in that way, probably very quickly, you'll be looking for your next role, right? We don't want to block shipping your products. We don't want to impede business operations. There's probably a more efficient and scalable way to build security processes. Everyone knows that there's never as many security engineers on any security team as there are developers at the company. That's just how it is. So, what can we do to scale the security team and also empower developers or other departments that are involved to help themselves self-serve in some parts of the security process? I've been in this long enough to know that we can't fully automate away humans in the process. That's not going to work. Many people have tried, but it's not gonna work, so there are ways to do this. We can, for example, empower developers to make decisions earlier on in a development process. This is part of an SDLC process that developers can say, "Hey you know what? What can I do now to tell myself that what I'm working on implementing is something that I absolutely should get security reviews on?" That's one way to do it. Another way is to say, at the time of code commit, "What automated measures are in place to help me decide whether I do want to commit this code from a security perspective?" Those are all tooling and automation and processes that can help to shift things left to the developers and empower them to make good decisions, and also scale the security team. This is really, really important. RS: I have to assume again here you are dealing with data security, as the CISO in a high velocity cloud native organization. I have to additionally just assume, by the very nature of all that, that regulatory compliance is huge for you. How do you balance the demands of going fast, moving fast, cloud native development, and the needs to meet – what are at times, perhaps, Draconian - data security requirements? How do you balance those requirements – got to go fast, got to compete, and have a ton of regulatory compliance requirements? How do you manage? KW: When it comes to compliance, I think it's worth talking about the difference between compliance and security here. Compliance is about a starting point. You want to be compliant with PCI DSS, SOC 2, CCPA, whatever it is. But, that's your starting point that you then have to build on – kind of a security approach on top of that to raise the bar continually. It's not easy to do that, right? But, at the same time, you have to allow developers to do their work. Everyone has to be able to share products. You have to take this sort of a continuous approach and say, “What can we do that is both reactive and proactive in this whole development pipeline?” What that means is you have to build in more proactive measures, like internal reviews early on in the process, automation to allow for decisions about committing code at the time of deployment, and then you also have to understand that you're not gonna catch 100 percent of everything. Security is never 100 percent, first of all, but you're not going to catch 100 percent of everything, so what are the reactive measures? Whether it's red teams that do threat modeling, or it's vulnerability research teams that look for ways to exploit the existing code base, or it's bug bounty programs, where you're now outsourcing some of the research to hackers external to the company. All of this has to work together, hand in hand with compliance starting points, to help you achieve a comprehensive security posture look, but, still at the same time allowing for business operations and for continuous delivery of product and shipping. I don't know if these are cruel and unusual requirements to me. I think it's very standard to see this type of requirement, especially if you're a cloud native company. You're definitely going to see this all the time, and it's expected for a CISO to be able to handle these types of requirements.