Maya Kaczorowski — Container and Orchestration Security

0:00Chris RomeoMaya Ketcharovsky is a product manager in security and privacy at Google, focused on container security. She previously worked on encryption at rest and encryption key management. Maya has a master's in mathematics, focusing on cryptography and game theory. Maya joins us to discuss how containers improve security, a high-level threat model of containers and orchestration, and tips for improving security as you roll out containers and Kubernetes. We hope you enjoy this conversation with—

0:26Maya Ketcharovsky.

0:27Chris RomeoMaya Ketcharovsky. Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is, how do we educate all these new folks? Security Journey has your answer. We provide a security dojo environment with level-based security education that gives your newfound champions a path to follow. And the best part? It requires almost zero administration by you. Visit www.securityjourney.com to set up a demo and learn how you can use the security Dojo to connect with your security champions. Hey, folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I'm also joined by Robert Hurlbut today. Hey, Robert, how's it going?

1:26Hey, Chris. Yes, it's Robert, Threat Modeling Architect. Good to be here.

1:29Chris RomeoSo our focus of this episode is container security and orchestration security, and we're joined today by Maia Kaczorowski. And Maia, we're just going to jump right in here, and our listeners are always on the edge of their seats waiting to hear people's security origin stories. So we want to ask you if there was a comic book episode 1 in the Maia story about security, what would that contain, and what are the things that you could share with us?

1:59Maya KaczorowskiYeah, thank you so much for having me. It's funny, I don't think of myself as having an origin story at all, so it's interesting that you're framing it that way. I got interested in— well, I think I've always been interested in security and in puzzles. So, as a kid, I loved, like, word puzzles and jigsaw puzzles and logic puzzles and everything like that. When I was in college, I studied math, which I still enjoy, and decided to work in cryptography. It felt like a really nice combination of real-world puzzles and really hard math, like no math involving numbers, just math involving letters. I did some algebra focused on cryptography and ended up studying that in my degree, Ended up working in something completely unrelated, ended up working as a management consultant for a few years, knew that I was excited about the security space. If there was a second input to that part of my life beyond studying cryptography, it was— you're going to laugh at me, and this will date me— it was an article in Wired, I want to say in like 2008, about the Estonia state attacks, state actor attacks. I just thought it was such an interesting topic from like a geopolitical and social point of view. I think the combination of cryptography and these real-world state attacks made me really interested in the space. When I had the opportunity a few years later, when I was a consultant to start doing work in security, I took it and ended up— it's been, I guess, 7 years or something like that now that I've been in the space, and I really find it super interesting and super fascinating.

3:42Chris RomeoYeah, I remember that Wired article that you're talking about, the Estonia state attacks. I remember reading that as well, thinking that was pretty interesting. So, how did you get to containers? And we're gonna introduce containers and orchestration in a second, but I'm fascinated with how did you get to the world of containers and orchestration from the world of kind of management consulting?

3:59Maya KaczorowskiYeah, so, from management consulting, I worked in security. I did some security work for large enterprises in healthcare, financial, insurance, etc. Typically, the typical engagement would have been something like, we've had a breach, we've had someone come in and clean that up, the board has written us a blank check, help us figure out what we should be building, how to stand up a SOC, stand up a vulnerability management program, stand up these standard things that you would expect in some large enterprises. I was doing that work, and at that time, Google reached out to me, and I joined Google as a product manager. Initially, I ended up focusing on encryption, again, because the area that I was excited about and knew a lot about from before. And then about 2 years ago, I decided to switch topics. I knew I wanted to stay in security, but wanted to go look at something else. The reason I picked containers is more selfish than anything else. It was an area that I saw gaining a lot of traction with users in the market, and an area that I saw needed a lot of guidance and a lot of direction, and, you know, I could have a lot of impact in that space. And so, I decided to go work on that so that I could do that. I wanted to be able to work on something cool and exciting.

5:11Chris RomeoNow, I've seen a few of your talks online, things that you've done, you know, about container security and things. And I was at a big tech company for a number of years as well, and I was looking at kind of what you were doing and thinking, wow, this is a product manager, someone with a product manager title who's very technical, who understands all the pieces. And now you're telling me that you're, you know, somebody who knows cryptography as well. So not really kind of the standard product manager background that I think of. And so how has that, your technical knowledge and your security experience influenced you as a product manager?

5:50Maya KaczorowskiIt's funny that you say that. I think maybe it's a reflection of Google more than otherwise, Google has fairly technical product managers. I think it would be basically impossible for me to do my job without understanding some of the depth of detail that we have in our products. It's been a benefit more than anything else, obviously. I think the only flip side of having the desire to get more technical is not being able to directly go fix problems myself sometimes. Or like you're describing, some of the talks and content that I give, right? That's not strictly in my job description, but something that I do because I find it interesting and because I think it actually makes a big difference in terms of how users perceive and consume that security. A huge part of it is just telling people that features or functionality exists that they don't even know about. Gaining adoption of something like, I don't know, network policy or pod security policy in Kubernetes in the industry isn't about building the feature, it's about telling people it's there.

6:49Chris RomeoYeah, so kind of the pieces that a lot of people, it seems like these days, don't even know they exist, like all these security features and things in these tools.

6:57Maya KaczorowskiExactly.

6:58Chris RomeoWell, let's start by kind of level setting for folks. I always hate to assume that everybody knows when we say container and orchestration, I always hate to assume that everybody knows what we're talking about. And so it'd be great if you could give us kind of a high-level view when we're talking about a container and we're talking about orchestration, what do these terms actually mean?

7:21Maya KaczorowskiSure. A container is just a Linux construct. If you already know some Linux security, it's not anything significantly new. A container is a way for you to package your application and its libraries and dependencies to make it significantly more portable. Kind of how we had the evolution from a traditional software stack and that you cared about what hardware you're running on 20 years ago to virtual machines, and you could suddenly abstract away the hardware that you're using. The step that we've taken now is one step further, which is I don't have to worry about the hardware or the OS that I'm using. I can just take my application and its dependencies and put it anywhere in my environment. That makes it significantly easier for you to deploy your workload across many different environments. It makes it easier for you to have high resource utilization. It becomes a very different model of managing your workloads than what you had before. Now, what that leads to is the second piece, which is orchestration, which is actually really easy to just get 1 container or 10 containers up and running locally, you're fine. Once you start deploying all of your applications in containers, you're looking at managing thousands of containers at a time. You want to have some of them up and running, you want to benefit from the purpose of containers in that they're easy to scale up and down. You don't want to have to individually go in there and be like, oh, well, I need 89 containers today, but I only needed 88 yesterday, let me change that. A lot of the container orchestration pieces are around scaling up your containers, managing things like load balancing of traffic between your containers, best bin packing them for best resource utilization. If something is wrong with a container, alerting you and letting you fix that. That's what container orchestration lets you do. The most common tool in that space is this open source project called Kubernetes, which makes it very easy for you to do that at scale.

9:12Chris RomeoYeah, when I think containers and orchestration, I kind of end up landing and thinking, hey, Docker and Kubernetes, but there are other alternatives, maybe not as prevalent, at least on the container side. Let's start with the container side. Is Docker synonymous with container or are there other options there?

9:34Maya KaczorowskiDocker released one of the original runtimes that gained a lot of popularity and traction in the market. In terms of adoption, right? It's an open source runtime. Obviously, Docker has other products in this space that they sell. I don't know adoption numbers offhand, but we see other projects in open source also gaining traction now in terms of container runtimes. Anything that's like CRI-O based, Container Runtime Interface something based. Another example is containerd, which is another open source project. We see a lot of people moving towards that as an alternative runtime. In terms of orchestration, you're correct, there are many different orchestration options out there. An increasing percentage of them are Kubernetes-based. That's just in general, this whole space has really benefited from open-sourcing projects and an open-source community that's really dedicated and excited and interested in working on these projects at scale.

10:32Yeah, it's great.

10:33Chris RomeoIt's very helpful to set the stage here a little bit about these ideas of containers and orchestration. Let's kind of transition a little bit into the world of security in regards to containers, and I'll throw out a kind of a statement I've heard. I heard somebody say, and I'm curious, Maya, if you're going to agree with this or you're going to disagree with it, and certainly happy to hear kind of either side because I don't even know where I stand on this issue, and that is— Containers are not a security tool, is what somebody said. So, I'm curious, do you agree with that statement? Do you disagree? Why or why not?

11:12Maya KaczorowskiI'm going to lean towards agreeing, and I'll sort of explain my philosophy here. Containers in and of themselves change nothing in your security model. In fact, if you look at the name of the thing, container, it doesn't even contain. from a security point of view. So that's, that's a bit misleading already in terms of what it does. Now, that being said, if you adopt the philosophy and a lot of the, the tools that come with running in containers, things like a microservices architecture, things like a further lockdown CI/CD pipeline, you can actually get significantly higher security benefits than a traditional security model. And so what I mean by that is If you're able to lock down your— before, you had a VM running and you wanted to make a change, so you'd SSH into the VM, make a change live in production probably, and then watch it roll out and see what happens. That's also how you did things like patching, like how you patch things like Heartbleed a couple of years back. Now, if you use containers, you're actually not supposed to change containers once they're running in production. Containers are meant to be immutable. Instead of SSHing in and making a change, you patch You apply a patch to an existing application, you rebuild that as a new image, and you roll out that image. That rollout has the same canarying, testing, monitoring, all of that stuff, all that tooling that you have as for any other production rollout you're doing. Any patching now becomes a normal production rollout. What that means is that you can apply a patch at scale across your infrastructure relatively quickly, And know exactly where it has and hasn't been patched, which is a bit different from the old model. That's a wonderful blue sky situation to be in, and I've seen a handful of companies be able to actually achieve something like that, because you need so many other pieces. You need a CI/CD pipeline that you've— sorry, a continuous integration, continuous development pipeline that you've locked down so that you know what kinds of changes are going in. You need enforcement mechanisms to know that the only things that you're deploying are actually coming out of that pipeline. You need ways of doing what I described earlier, which is a blue-green deployment, which is when you deploy a new workload that, for example, is patched, and you have an old workload that isn't patched, and you move traffic over from the old workload to the new workload. You need lots of these pieces that aren't security-specific pieces, but if you don't have those, you don't get the security benefits.

13:41Chris RomeoSo, if I kind of summarize that list, I want to make sure I I captured the list of how containers improve security correctly. And so you talked about the microservice architecture, just being in that architecture, there's some security benefit in splitting things up, locking down your CI/CD pipeline because you've got, with the proper enforcement mechanisms, you're able to push out new versions and then kind of retire the old ones. And then you also talked about kind of patching. So are there other things that improve security related to containers? Yeah.

14:18Maya KaczorowskiYeah, one of the ones I didn't really mention earlier, I said containers don't contain. I think it's a common misconception that you can't have both. People think, oh, I have a container, I can't have strong isolation like I did with a hypervisor or VM boundary, etc. That's true, you can't have exactly the same thing, but you can have other isolation mechanisms that exist, again, in open source like gVisor, Kata containers, Nabla containers. There's lots of different options out there. for providing similar types of isolation. So, as you just said, CI/CD pipeline lockdown, patch management, enforcement of what ends up in your infrastructure. So, being able to actually have a check that says, these containers must meet these requirements before being admitted to my infrastructure. It's what's called an admission controller in Kubernetes. Then workload isolation provided by some of these open source projects. I guess my top-level message is, You can get a lot of benefits for security out of containers, but it's not the container that gives you that benefit. It's the tooling that's been built around containers and/or other practices that you adopt with the adoption of containers that give you those security benefits.

15:32Okay.

15:33Chris RomeoSo, when you think about the kind of the high-level threat model of containers and orchestration, what are some of the things on your list that you're thinking about when you put your kind of your attacker hat on and you start thinking from the outside? looking inbound to the Kubernetes clusters and the containers that are running within?

15:54Maya KaczorowskiYeah, I think there's 2 things to— just 2 different ways of thinking about this. The first one is worrying about attacks that are on applications that just happen to be in containers. So an attacker doesn't really care where your application is running. They're going to try to get into your Jenkins or your WordPress or whatever, that you have up and running through some vulnerability that you've left unpatched. They might be in a container and they might not even realize. What we're seeing is not people who are necessarily aware, attackers who are not actually aware of containers or containerized infrastructures, and who don't necessarily try to do anything interesting, like break out of a container when they've discovered such a containerized workload. They're just after the easy way of making money. Let me pop this shell and I'll run some cryptocurrency mining, and that's fine that I only got a container and not the host. It doesn't matter, it still works for cryptocurrency mining.

16:45Chris Romeocryptocurrency mining.

16:46Maya KaczorowskiThe second type of concern I would have or attack out of concern would be on containers themselves, and not necessarily on containers themselves, like, again, trying to break out of a container, but more likely on the container orchestration system. Because Kubernetes is still relatively new, although it's open source and lots of different people are working on it, it has some less than desirable defaults from a security point of view. There are people who have been running Kubernetes for years who have never gone back and changed what some of those defaults are and improve the security of their deployments. Really simple concerns like having your API server, which is the control plane for Kubernetes, be publicly accessible on the public web and not putting authentication in front of it, or having a UI dashboard, which is another open source component, that has the power to do things with the API server, again, publicly accessible on the web that an attacker can go find on like Shodan or something. The issue there is not you doing inherently anything wrong with your workload, it's you having a misconfiguration of your environment, just like you might have a misconfiguration of an application, a server, a cloud, whatever it happens to be.

18:03One thing you also mentioned was locking down your CI/CD pipeline. One thought I had, I remember this was also one of the threat models I've seen, or threat modeling perspective on containers, was at some point, or one point in the early days, it seemed like you could get containers everywhere. You can download them from different places and then run them. And that was one of the things we always say, don't do that. You know, how do you know where it came from? Do you know if that's still People still doing that?

18:32Maya KaczorowskiPeople are very much still doing that, yes. What you're describing is what we call software supply chain security.

18:39Yes.

18:39Maya KaczorowskiKnowing what ends up in your environment from a software point of view and where it came from. We often tie this to containers, and I think that's right, but it's actually more than containers. It's any binaries or packages or libraries. Containers just made it really easy to consume, but it's any of that stuff that you're pulling into your environment. Typical attacks that have happened in the last months and years have been people planting cryptocurrency mining software, planting tools to try to capture passwords for specific types of crypto wallets, et cetera, in images that are widely available or packages or binaries that are widely available, knowing that someone will pull it and try to run it and therefore benefit them in some way. Some of it has been targeted. Again, like looking for developers of specific applications, and some of it has been just broad swaths of hopefully somebody will run this and I'll get some money out of it. Some of it has been to known widely used packages and applications. Some of it has been what we call typosquatting, which is this looks like a plaything or somebody might mistype the actual container that they want, and they'll download this like if I was going to buy a a website that would be like a couple letters off of a popular website and get traffic just by people going there by accident.

20:03Chris RomeoI had never thought about typosquatting in an image name for a container.

20:08Maya KaczorowskiIt's a real concern. What's stopping me from mistyping this thing, any developer from mistyping something, and then pulling completely the wrong image?

20:18Chris RomeoWith any of those type of typosquatting things that you've seen, is it the case where the image is trying to take advantage of a bad security policy that might exist in a cluster to access a root file system of whatever the host is that's running Docker? What can they do, I guess, with that when they have a bad container there? What's their goal?

20:43Maya KaczorowskiI haven't seen Type 4 squatting yet be about a particular application and trying to model that application, which I think is where you're describing. One example would be last summer, somebody pulled up Docker images on Docker Hub, that were names like Docker 123321, knowing that like, hey, I'm just going to play around with this thing and test some stuff out. I just need a random name. It was downloaded tens of millions of times, like some absurd amount. Wow.

21:11Chris RomeoAre there any other types of attacks that we want to focus in on that are related to containers and orchestration?

21:19Maya KaczorowskiNo, I think it's really— you've gotten me to narrow in on the 3 that we often think about, which is What we'll call infrastructure security, which ends up being misconfigurations, mismanagement of networking secrets, etc. Software supply chain security, which is about what ends up in your pipeline and you knowing where it came from and if it's been scanned for vulnerabilities, etc. Then what we call runtime security, which is what happens if somebody does attack your application directly, and can you detect that in a container, and can you take action in a container, do forensics, etc.

21:50Chris RomeoOkay, let's move to kind of the defender side, I guess, of this conversation. For those that are out there running Kubernetes and starting to or have container infrastructure, what are some of the things that you recommend folks do to improve their overall security posture?

22:11Maya KaczorowskiI think it really depends how far along you are. So, one of the conversations I've been having a lot lately is sort of what you do on day 1, day 1 security decisions, things that if you do now, you'll benefit from later. The first one I would mention would be structuring your environment. One of the first decisions you have to make when you're setting up Kubernetes is deciding, for example, how many clusters do you have? Are you going to segment teams using clusters or projects or namespaces? How do you want to manage deployment permissions for each of those different clusters? Are you going to let everybody run their own cluster in your environment, which I see some companies do, right? If they don't have a central infra team or a PaaS team, they let anyone go and spin up Kubernetes, which then makes it really hard to manage what's going on. I think that's the first question. A second question I would have would be around your permission model. Kubernetes has built in something called role-based access control, or RBAC, It's similar to RBAC that you've seen in basically any other security product ever. It lets you create roles and then grant users roles based on a set of permissions that you want to give them. So figuring out what your source of truth is going to be for your identities and what kinds of policies you're going to put in place is probably the next day one decision to make. Another day one decision is around how you'd like to deploy things to your environment. Again, going back to the CI/CD question, Yeah. Where ideally, you've only deployed things to an environment that have been tested for vulnerabilities and come from your build pipeline, etc. Often, see people set up something like a service account rather than— so a machine account rather than a human to actually do that deployment and do that testing automatically. Then lastly, there are some features in Kubernetes, or rather in some of the hosted Kubernetes offerings that can't be turned on after the fact, so they're only available on existing clusters. Um, so in that case, if, if, if you didn't kind of think ahead or plan ahead enough, uh, what we typically see happen, or often see happen, is somebody will have a toy cluster that they're testing out Kubernetes with, and then they decide they want to have more functionality later, and they sort of built up that cluster and started tweaking it, etc., etc. And then it's been 3 months and they're like, oh man, I need that feature, I can't turn it on, but I'm already too far down this road. Either do a bit of planning ahead of time, create a toy cluster, test out a few things and see what works, but then rebuild that once you're ready to actually go to production with it. Consider things like different kinds of templating tools to make it even easier for you to spin that up in the future if you would want to do that again. That's day 1. I'm happy to talk about other parts of what you see later, but it feels like a lot of the people interested in containers and Kubernetes today from a security point of view are relatively new. And so there's a lot of interest in that decision.

25:10Chris RomeoYeah, and just to kind of summarize, so we're structuring the environment, we're deciding how many clusters we're going to use, how we're going to do separation between teams. We're thinking about permission models and RBAC, maybe some other policies, and then we're considering deployment. How are we getting the containers into the cluster? And then you also talked about the toy cluster as a way to test things first and then rebuild when you're getting ready for production so that you don't accidentally turn something off that you think you're going to need and end up too far down the road. That's day 1.

25:43Maya KaczorowskiThat's day 1.

25:44Chris RomeoMaia, I saw a slide that you had, and I don't know, maybe you can mention which talk it came from and for folks that wanted to go track it down, but I saw a slide that had, like, like 4 quadrants where you were talking, I think, about kind of like day 1 stuff, and then you had kind of things in 3 other quadrants as well.

26:05Maya KaczorowskiYes. I think you're talking about a talk I gave at Google Next in 2018. It was called Kubernetes for Enterprise Security Requirements. So, there was a slide in there, I think, a really great place to get started if you're looking at that, called something like Your Security Journey or Your Security Journey on Kubernetes.

26:26Chris RomeoThe name of my company is Security Journey, so that's how I found the slide.

26:30Maya KaczorowskiJust searching for yourself, you have a Google alert set ready to go. Setting up a cluster is the first thing you're going to have to do, and some of the things we just talked about, like figuring out how to structure that environment, etc., but then setting up role-based access control, setting up network policies, namespaces, etc., for them to work in your environment are some of the decisions you have to make on the first day. Then we said follow security hygiene. Things like keeping Kubernetes up to date. This is actually unusual, I think, for a lot of enterprise companies in the sense that Kubernetes has a new release every quarter and is very good about actually releasing something new every quarter. That means that both from a functionality point of view, you want to be able to pull in the latest version, but also more interestingly for me, from a security patch management point of view, When there's a critical vulnerability in Kubernetes, the Kubernetes Product Security Committee releases a patch, and you want to be able to actually pull that in and update that. If you're running Kubernetes yourself, make sure you can perform an update, and if you're using one of the hosted providers, make sure that they either give you a timeline for those patches, or you have a feature like Node Auto Upgrade or something to apply the patches automatically in your environment. Some of the other security hygiene there is nothing new for security folks, things like Minimum IAM roles for minimum permissions, a minimal OS to not have additional content in your environment that you don't need to patch, using private IP addresses so your applications are not widely available, audit logging, etc. Then we had a section called Preventing Known Attacks. Some of the things that we've seen in the wild, including some of the ones mentioned earlier, so things like disabling the Kubernetes dashboard, protecting node metadata, scanning for known vulnerabilities. And then lastly, we said prevent and/or limit the impact of the compromise of a microservice. So, an application that you have running on top of Kubernetes in a container, if that were to get compromised, how would you prevent that from spreading in your infrastructure? Using things like pod security policy, protecting your secrets, using sandboxing technologies that we mentioned earlier, and then things like a service mesh for authentication and encryption between your different services. So, kind of rolling it back, it's set up a cluster, follow security hygiene, prevent known attacks, and then prevent or limit the impact of microservice compromise.

28:53Chris RomeoAnd so, kind of from the things you talked about in that first section, we talked about day one and then kind of follow security hygiene, having maybe a few other things added in the mix. What do you think is a realistic timeline for somebody who's new to Kubernetes? Say, let's just— I'll give you a scenario. has been handed the task to say, hey, we want to use Kubernetes for our application deployments, and we want you to figure it out. What do you think is a reasonable timeline for them as they're getting into this and trying to understand all these pieces?

29:24Maya KaczorowskiYeah, I mean, so, like, I'll look at myself, and it probably took me 6 to 8 weeks to understand what Kubernetes was even trying to do. And, like, I watched talks, and, like, I read documents, and I kind of understood the concept and played with it myself directly. But it takes a while just to grok it. If you've never seen something like this before, it doesn't resemble how you managed your VMs before. It doesn't resemble a traditional enterprise architecture that you've seen before. Just from a concept point of view, it'll take you some time to get around it. Once you have the concept of Kubernetes, security isn't really that different. Like I said, it's things like minimum privileges and locking down access to certain things and audit logging. Those things are things that you're familiar with if you're a security person. So, that stuff isn't new. Learning how to do it specifically in Kubernetes or with containers might be new. I would say that the next frustration or difficulty, I think, in this space is if you're trying to do it all yourself, there isn't— there is a lot of content out there. It is not necessarily super well organized. Because so many people are excited about Kubernetes and containers, there's a lot of stuff where you can go learn about, like, how your IPs are rotated and whether you should set up a network policy and what it should look like. But getting it all in a concise step-by-step guide isn't something that I've seen. I know there's some books coming out, I think shortly, from the community, so that should be good. I would say, and again, I'm extremely biased in making this statement, but one of the hosted providers will save you so much time. in that they'll do at least half of your to-do list for you. If you have that option rather than running Kubernetes yourself, from a security point of view, I would take it. There's obviously other considerations for why you should or shouldn't do that, but that should make your life significantly easier.

31:15Chris RomeoFor somebody who might be new and jumping into this right now, are there any resources that you would point them to as a place to start?

31:23Maya KaczorowskiYeah, I would look at some of the talks that are online from KubeCon. KubeCon is the Kubernetes conference. There's a lot of content on security. There's been a security track every time I've gone there, so there's a lot of stuff out there. I would look on the Google side. We have a blog post series called Exploring Container Security, which you can get access to, that has probably about 20 blogs now, 20 blog posts now, that go over different aspects of container security. So if you want something you can refer to quickly in that regard, we also have an ebook which is more targeted towards a business reader who doesn't necessarily understand what's going on in that space. Then I would say there's a handful of people, like, it sounds silly to say, but on Twitter, there's a big security community, and there's a big container community on Twitter, and the intersection is louder and happier to be on Twitter than either one individually seems to be. Follow some people in that space. Ian Coldwater, is obviously an expert in this space. Greg Castle, Ian Lewis, there's a bunch of interesting people saying interesting things online.

32:33Chris RomeoVery cool. Well, Maia, thank you for taking us on kind of this introductory walk into containers and orchestration and security. And this has been very good. I've written a whole bunch of notes and a bunch of things to think about here. So yeah, I just really appreciate the fact that you would share this knowledge that you have with our audience. This has been very cool.

32:55Maya KaczorowskiYeah, of course. Thank you again so much for having me.

32:58Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute. And Robert, @RobertHurlbut. Remember, security is a journey, not a destination.