Security Superfriends | Kathy Wang, CISO at Very Good Security
Kathy Wang is a total super security hero! You really need to hear the story of her ascent in her own words, but let me entice you with a few choice morsels.
She is a three time CISO who rose from the engineering ranks. And, when I say engineering, I mean down-to-the-metal chip engineering. This puts her in a class of her own; while there are a small handful of CISOs who have emerged from software development, I am not aware of any chip designers.
But that only scratches the surface! Early on, she worked for Bruce Schneier’s company Counterpane Internet Security (acquired by BT) and did a long stint with MITRE (yes, the folks that gave us so many good things including Mitre Att&ck). She is now focused hardcore on the cloud native space, having run security for GitLab for two years before joining Very Good Security.
Kathy has been rocking the security space for 20 years. The knowledge and experience she brings will continue to shape the future of cloud native security. I hope you enjoy this installment!
Be sure to watch the video to hear more, and subscribe to catch more great episodes of Security Superfriends.
Richard Seiersen: What approaches for locking things down without getting in the way of high velocity cloud native development are top of mind for you?
Kathy Wang: 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.
RS: With Kubernetes, you are, by its very nature, dealing with distributed compute at scale, where you're going to be collecting data from customers and then distributing that across a variety of environments. And, while a lot of the shared responsibility model from a staff perspective may be owned by those third parties, you are still accountable from a data perspective. The thing that we – you and I – will always retain is data – you know, accountability. How do I know that? Because you see what happens in terms of class action lawsuits. You see what's happening from a regulatory perspective. With cloud native development – exposing more value to more people through more channels – we should expect that to expand. So my question I like to ask CISOs is about “build versus buy.”
You're cloud native. You're in an environment with a bunch of developers. You probably have security folks who are, like yourself, engineers, and developers, and whatnot. I've worked at companies where it's like, “If it's not invented here…” So, I'm just curious, where do you sit on that spectrum, particularly for security?
KW: I have a background as an open source developer myself, and I actually don't call myself a developer – I'm a prototyper. I build stuff that works in demos for conference presentations, but I'm not someone who's a full software developer. But, because of that background, I do have a soft spot for open source solutions and open source software. The thing about the balance of that, though, is: Is it scalable, is it enterprise grade, right? Is it going to work for a different company environment, other than the use cases it was developed for?
Another thing that I do have a lot of experience with is doing highly technical product evaluations, especially around security products. I spent years doing that in the past as a defense contractor for various government organizations. I know firsthand that what you see isn't necessarily what you get when it comes to reading the documentation and looking at the performance of a product.
It's very important to me when my teams look at buy versus build solutions that we conduct a thorough technical evaluation of two to three different products, or open source code, or open source packages to see how all of that maps out across the requirements and use cases that we have.
I don't see a lot of people who seem to know how to do that very well, but, to your question about “buy versus build,” you have to probably lean more on buying when you have a very lean or small team, because, otherwise, you don't really have the full bandwidth to build out a whole solution yourself. But, it makes sense as your team grows to look at more build solutions. With the builds, the nice thing is that you can often customize it for your specific use case, which might be considered too snowflakey for a vendor to actually focus on implementing.
So, I think it makes sense from both perspectives, but it depends on the team, the skill sets, the bandwidth, and also your use cases. But, you have to do a thorough evaluation based on requirements.Too often, I just see people say, "Yeah, I'll just pick a product. Yeah, vulnerability scanner, I just need a vulnerability scanner." But, have you thought about why you need one, documented it, gotten all the input from different stakeholders? Your infrastructure team is going to be a stakeholder of this because they're going to worry about availability being impacted by the scanner. That's normal. But, if you haven't looped them in, what's going to happen is you're going to deploy this and you might get pushback at that point.
That's not when you want to find out about this, right? People can do better, I think.
Want to catch the latest and greatest in Security Superfriends? Subscribe to our Youtube channel for updates, and find all episodes of Security Superfriends on Apple Podcasts, Google Play, Spotify, or wherever else you get your podcasts.