Ochaun Marshall — Securing Web applications in AWS

0:00Chris RomeoO'Shawn Marshall is a developer and security consultant. In his roles at Secure Ideas, he works on ongoing development projects utilizing Amazon Web Services and breaks other people's web applications. O'Shawn joins us to talk about the changing tide of serverless and frustrations with AWS security. Before we got to the actual topic, we talked about how he currently works as a developer sometimes and a pen tester security person the rest of the time, and the conflict that arises from this split role. Please enjoy this conversation with O'Shawn Marshall. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo.

1:14Robert HurlbutHey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey, and co-host of the Application Security Podcast. Robert was unable to join us today due to his day job. Today, I'm joined by Oshan Marshall, and Oshan's going to talk to us about security applications and the context of AWS and how that all comes together. Oshan, we always jump right in for our listeners' sake to our guest's security origin story. Because that really sets the stage for everybody who's listening here. And so how did you get into this crazy, wacky world that we call security?

2:08Ochaun MarshallUm, if I would like to start off the first security-related story, uh, it's actually 3rd grade. Yeah, 3rd grade. Um, I was almost, uh, I was almost expelled not only from my elementary school but from my district. for hacking into the library.

2:28Robert HurlbutHmm. I had—

2:31Ochaun Marshallthis is a gray-haired, like, probably 60 to 80-year-old librarian, and for some reason, me clicking the little book icon that said catalog and clicking and dragging that in and out of the recycling bin counted as hacking. For some reason, that horror story of having meetings, having the superintendent come in and all that, for some reason that didn't scare me from computers. I continued through, signed up for a technical STEM magnet school, Philip O'Berry Academy of Technology, and then I went to UNCG to study computer— University of North Carolina at Greensboro to study computer science. Got involved in the security club there, met with one of my roommates who introduced me to the company I'm working for now.

3:28Robert HurlbutVery cool. You survived that 60-year-old librarian coming after you. She was probably an incident response expert in disguise. She was creating disk images of the library computers and being like, look at this case we have against Oshan for clicking and dragging into the recycle bin. It's crazy that that got all the way to the superintendent. of schools to have to deal with that, but I'm glad you kept on the path and made your way into this world of security. One of the things you said in kind of our pre-interview, you mentioned this idea of the schizophrenic nature of hacking your web app. And so I'm really curious, first of all, what does that mean? And 2, what's the story that goes behind that?

4:13Ochaun MarshallOkay, so this leads to me. I am a full-time developer. and a full-time security consultant. So sometimes, uh, when my boss Kevin— well, I'll be working and working in actual development, and then boss Kevin will hit me up, or schedules will change, and I will spend a week in— I will spend a week as an active penetration tester, red team, and doing security. And then I have to switch contexts again to becoming a developer. So I'm, I'm really I'm really straddling both worlds here. So one time in the transition back from pentester to dev, I'm just doing just an assessment of where the application is, and I'm trying to get like, you know, some simple pop-up XSS, cross-site scripting.

5:07Robert HurlbutOkay.

5:08Ochaun MarshallSo I'm just going through, it's just like, I know the guy who wrote this, he's completely lazy. There is no way I cannot get XSS out of this. And, um, what— after a few hours I found out, and then I asked some of the senior consultants in the company, and it's just like, yeah, if you follow the security defaults, if you go with your framework, and if you don't do anything weird like adding unsafe, unsafe HTML, throwing that directly in the JOM, a lot of that security a lot of that security considerations the dev doesn't even have to think about. And so we use Svelte, but it doesn't matter what JavaScript framework you use. It could be React, it could be Angular, whatever, as long as you've got input filtering on your end as the developer and then output encoding when you're actually displaying the user input, then you've stopped cross-site scripting. It's only— we only get that when our clients, when people, when people subvert the controls that are already there and they don't take those controls into consideration on why they are there.

6:25Robert HurlbutYeah, that's, that's definitely good advice, something that we share as well. You know, the frameworks have a lot of security capabilities these days and we just need developers to tap into them. Like, you know, there's still a lot of legacy code floating around. Yep. I mean, that's going to be a challenge for our entire career. You know, by the time we're retiring from security, there's going to be still some legacy app that uses, you know, some ancient JavaScript that wasn't even a framework and, you know, has some challenges and things. But I do have a question for you based on the fact that you were describing these 2 different worlds. You know, you're playing as a developer, you're playing as a penetration tester and you're going back and forth. Here's the million-dollar question for you. What do security people not understand about development that really makes them— really, really makes developers' lives miserable, but security people may not even understand that they are doing such a thing? They may just think, hey, this is how things are supposed to be.

7:30Ochaun MarshallI could rant on for hours. I'm trying to edit myself mentally to be specific. In terms— application security is not just one layer of the OSI model. It is not just what's running on port 443 or port 80. There is an entire universe of complexity in there. Most of the reason why we are where we are technically is because of applications. We use applications every day. Unless your business is centered around security, that is the center of the business, whatever products or services the organization delivers. That's the center of it. It's not just— if devs don't understand something in security, it's simply because you haven't gotten into their world and to understand that they're trying to build and create beautiful things. If you tell them that, hey, part of making functional software is making it secure, then they'll be on board. Then they'll be on board with that. If you step in as the gatekeeper and you block them and say, hey, we won't ship your code unless you do this, check this, that, and the other checklist, that's just another hurdle. The organization is incentivized to find these— I'm going to be throwing buzzwords— agile, DevOps people, people who skip around corners and go around barriers. They're actually— the organizations are actually selecting for that. And if you become the gatekeeper, if you become the barrier to entry, their goal is to skirt around.

9:12Robert HurlbutYeah, I mean, that's in my experience. I've seen the same, the same challenges. And that's why I asked that question, because you have a unique perspective in that you're playing on both sides of the— and it sounds like you're going back and forth regularly. So you're, you're probably seeing those pain points more than someone who is a security person who has been doing security for 10 years. We tend to get blinders on. We just see the world as, like, of course you're going to do the right thing. Of course you're going to understand the OWASP Top 10, and you're going to write code from a defensive standpoint to prevent any of these types of problems. We end up— I don't know. It's rose-colored glasses. I don't know what to call it, but it's a challenge for us. We need to... Walk a mile in the shoes of our developers if we're spending all of our time in security to really understand what they're dealing with.

10:00Ochaun MarshallYeah, training. And one thing I'll add to that, training is really effective. Like, we— I'm pretty sure your organization has seen this as well, is that when you show developers how they can hack their web apps, it's just a simple QA check if they can inject JavaScript through a form. That's A simple example, but if you train developers to look out and see these things and notice that, hey, part of making this beautiful and part of making it elegant, part of making it functional is simply about making sure it's also secure as well, then their eyes will open and they understand. But part of that is actually talking to developers, not just going to the conferences and saying, oh, well, you're this should be standard, everyone should be doing this, that, and the other. Actually having the conversations with the development team, with the project managers, with the shareholders, and the people who are actually walking through the implementation details to facilitate this sort of transformation.

11:13Robert HurlbutYeah, I'll tag on to something you said here about kind of When you're going to the conferences, security people, we tend to go to the same security conferences. Who do we meet with there? Security people that already agree with everything that we're going to say. One of the things I've been trying to do is I've been trying to spend time at development-focused conferences. I live in Raleigh, North Carolina here, and the .NET Users Group had a day-long conference. It wasn't a security conference. It was all about .NET, and I do not know a lot about .NET. But, I do know enough about the OWASP Top 10 and the OWASP Proactive Controls, so I did a talk on the Top 10 and Proactive Controls from a .NET context and introduced some very basic concepts, and the folks were just eating it up. It's not like developers don't want to write secure code. We have to lay the foundation. We have to go to them and go to their conferences and educate them versus saying, well, they should all come to security conferences. Well, they're not going to. It's just not going to be. All right, so this is great. We could have a whole— we'll have to have another conversation about this whole topic because I could literally talk to you about this for an hour, and I think we would, or we'd probably talk for longer. But we do want to get to AWS because I know there's some folks who've seen the title of this episode and they're thinking, I want to hear about AWS. And so I thought we would start with understanding what are the security capabilities that exist within AWS today?

12:40Ochaun MarshallSo to summarize them all in with 2, you've got 2 modalities in which you can understand security in AWS. You've got managed services that are provided, like security out of the box sort of solutions. I don't mean that in a derogatory way. I mean fully featured security out of the box tools, and like things like Security Hub and the AWS WAF and those sorts of things. You've got those solutions, and then you've got all the other services in AWS, and you can actually, with those other services, build up that sort of tooling from scratch, from basic CloudTrail and things like that. You can run your own custom WAF on an EC2 instance, for example. Those are the sort of modalities people— and of course, not everyone is selectively one or the other. You'll see in any real world AWS environment, you'll have some security services and some building from scratch. The organization I work for, a lot of our tooling we have to build from scratch, simply for not just for billing reasons, but also to understand, to sort of understand the risks and the complications in an AWS environment. And understanding what— and since we do our own— since we do cloud security assessments for other people, knowing what to look— making custom rules, tweaking the dials, knowing what to look for there.

14:18Robert HurlbutYeah, I guess there's some of that basic stuff. Like, when I think AWS security, I think there are some basic things that come as components, like access control lists, for example, network-based access control lists that are set from a— controlling who can SSH into to the infrastructure is something that's built into AWS as far as the capability. You're not paying extra for it, but it's still something that you have to understand. You think about S3 buckets, right? They've been the bane of enterprise for the last couple of years because people created all these buckets with wide open access control lists, and then they're just using them, and then somebody finds it, sniffs it, and is able to do something with it. Right.

15:03Ochaun MarshallYeah, and that sort of leads into frustrations with AWS. There are a million ways to skin a cat, and that's always been the way with security. That's always been— I don't— I talk with people who have been in this field for decades, and it's not anything new that there are multiple ways to integrate security within any environment. In particular for AWS environments and and cloud in general, one of the major frustrations is that there are also competing frameworks. There's the CIS AWS benchmark for, this is what you should do in your cloud environment. There's also AWS Well-Architected, where it's like, oh no, this is what you should do in your cloud environment. You can give a talk about AWS stuff and show architecture and show an architecture slide deck, and some people would say, oh, well, I wouldn't architect it this way, but this is a sample image I took from the AWS documentation. So everyone has their own different opinions on it. There are some better ways, and then there are not. There is granularity. There are situations where you have better ways of going about it than others. There is no golden, the best, ultimate, perfectly secure way that is going to come out if you follow these guidelines. You have to tailor it to your own enterprise, to your own environment, and your own solutions, and what sort of applications, and what sort of things that you're running. There are so many AWS services that you're not using. You may not be using IoT devices. You may not be setting infrastructure for games. And there are different compliance requirements for people based on whether they're HIPAA or PCI and those sorts of things. So there's no golden standard for every environment. There is the absolute best you can get from your own environment.

17:07Robert HurlbutAs somebody who's spent some time looking at AWS and general security capabilities, do you feel like we could run a full AppSec program out of the capabilities of AWS or I think there's pieces missing, but I'm not 100% sure. So I'm curious, for you, as someone who's looked at this maybe deeper than I have.

17:27Ochaun MarshallYes and no. Yes, because there are— because AWS has certifications and like has courses built on security. Like they have like a course sort of training pipeline which they go over all the security options and all of that. And no, in that a lot of organizations, they still have a decent number of their infrastructure is on-prem. They may be in a hybrid situation where like 80% for compliance reasons, because the security people told them not to, other reasons that they haven't fully embraced the cloud yet. So they may be working around 80% on-prem resources and then 20% cloud, or they may be running the gamut where They saw Netflix a few years ago and said, we gotta do that. And you're now spread across not only AWS, but GCP and Azure. So, yes, there is, yes, there is a need for understanding security with a cloud context.

18:35Robert HurlbutYeah.

18:36Ochaun MarshallThere needs to be a rethinking of current security programs. If you don't take this, and if you're not taking this into account, you're not really utilizing these services well. We'll go into this, I'm assuming, later, but when we talk serverless, if you don't understand IAM, you cannot get serverless to work, much less get it to work securely.

18:59Robert HurlbutYeah, or you end up opening it, making it wide open, so that it's in such an insecure state, based on our previous conversation about S3 in the early days. Yeah, so when I think about AppSec program in AWS, I can see there are some of the fundamental pieces, pipelines and things like that. I'm not sure where they are from kind of like a third-party software scanning, for example. I mean, I could certainly bring my own stuff to an AWS pipeline. I could go buy something from another commercial vendor. I could use an OWASP tool like Dependency Checker, RetireJS or something. But it seems like they got a little bit more work to go until they could say, hey, I'm going to give you a full AppSec solution from AWS? They're probably thinking about going there because it's part of their, you know, do everything approach.

19:47Ochaun MarshallSo yeah, right now I would say bring in the third-party tools, bring in— but there's a limit there. One of the security considerations is that there are some tooling that says, hey, we will— if you bring us into your environment, we can do security assessments. And then you have to look at the tool, and usually it's like some sort of CloudFormation stack where you're deploying out all this infrastructure for it. You have to realize that this is a third-party tool that's sitting in the middle of your environment, and you sort of giving it— you have to give it the keys of the kingdom in order for it to do its job. So that's why in our organizations and a lot of the clients that we work with, building it from scratch piece by piece and understanding it may, may take a bit longer than— may take a bit longer than just the sort of agile run and grab it. But when you're thinking of a security comp— you're thinking security context, sometimes being a little bit slower is not, is not terrible. Like actually slowing down and thinking, understanding— you need to understand the process before you automate it. Like, if you, if you don't know what's going on, then how can you see any benefit from automating that process?

21:07Robert HurlbutYeah, that's good advice just for in general, for anything. Yeah, you see so many times where people build this giant solution and they get to the end and they're like, huh, this isn't actually how it was supposed to work. Like, you have to, you have to understand, you have to do things manually enough so you're in so much pain that automating makes the— takes away the pain. And when you take away the pain, you're actually you're automating it the way that it actually is supposed to work, because you struggled with it for so very long. So, following down this path of AWS, when we think about app deployment options today, what are the choices that we have available? I think you mentioned serverless a little bit here in an earlier answer, but is it serverless versus kind of a traditional application deployment?

21:52Ochaun MarshallSo, there's serverless deployment, there's the traditional app deployment where you're just putting it on a server. There's containerizing it and then running it in the cluster, which isn't technically serverless because you've got to run these containers somewhere. Yep. But those are sort of the big 3 that I see right now. When you're considering serverless, you don't have to worry about one particular box, managing that infrastructure for that one box. Serverless has many definitions to many different vendors. AWS has their own specific definition of serverless. But when you talk to people who know how this stuff works, the concept of serverless is that you're shifting the focus away from the infrastructure, more to the business logic. From there, you've got services like software as a service, things that run business logic, like AWS Lambda, and those sorts of services that you're not worrying about where this is running. You just need this code to execute. So there's the containerization and container orchestration, in which, hey, we do care a little bit about servers. We need to make sure that We understand that the container that we're using is not just the container, but there's something on top. We're building it on top of something, and we also need to work with orchestration if we're doing multiple containers in the cluster. So there's that. It's not really serverless when you're using container technology, but there's those considerations. And then third is you're just using your traditional web application. There, you're just running— you have an EC2 instance, for example, where you're just deploying— or Elastic Beanstalk, and you're just deploying your application there, and it's just one server. You don't need to— One thing that you have to figure out is you may not need containerization. You may not need serverless for what you're doing. I've sat there, and there's a horror story of spending a year focusing on building a web application from scratch in serverless, and then we replicated all of the functionality that we built over that year in 2 months with just a traditional deployment to Elastic Beanstalk.

24:36Robert HurlbutHmm.

24:38Ochaun MarshallIf you're using these different deployment strategies, you need to assess, why is it that you're doing what you're doing? Is the headache of managing a server more than the headache of managing configuration with a dozen or more AWS services? If you're going serverless, you have to understand you're going to spend a whole lot of time in configuration.

25:05Robert HurlbutYeah, that's definitely going to be a challenge as we move more and more towards the serverless world. I'm not convinced we're going to land there where everything has to be serverless, and I could be wrong. The pundits will say, you know, you're wrong often, meaning me is wrong often, but I feel like something else is going to appear on the horizon. Serverless seems like it makes sense to me from a security perspective to have small pieces doing different functions. But, it also seems like— I'm a keep-it-simple person, right? If things are really complicated, I can't understand them, and so I can't even operate in that world. But, that also plays well in the security world because, if it's simple, it's so much easier to look at something and say, that's simple, hence it is secure, versus looking at something and going, that's complex, hence it is secure. I feel like I can make this simple equals secure argument a whole lot easier than someone can make, well, we have all this complexity, which makes it secure. No, that makes it prone to error. when someone tries to make a change and they don't even know what the thing's even supposed to be doing. So, from your perspective, what are some of the security challenges? Let's focus in on serverless here, because that's kind of where it seems like there's a lot of people thinking about this. What are the security concerns from a serverless perspective?

26:24Ochaun MarshallSo, one of the security concerns from a serverless perspective is, A, the security of the business logic itself. If you're doing insecure things, Doing insecure things serverless does not make it more secure. You have to focus. Is what we're doing a good thing to do? We talked to a client, which we'll name unnamed, who wanted to deploy a web app that's simply browser-based to do banking. Now, think about that.

26:57Robert HurlbutMm-hmm.

26:59Ochaun MarshallHow are you going to authorize or do anything like that if you're just shipping it out as a browser? You need a backend somewhere to at least verify that this person is who they say they are. But it's— but when you use some buzzwords and you use like, oh, I imagine this, it can be easy to go around the rabbit hole and throw thousands, if not millions, of venture capital into a black hole. So one, focus on the business logic. Like, is this— are we doing the right things here? Second order of business is the configuration behind that. So, how is— just as a functional engineer, like a DevOps engineer, how are we managing this project, and how are we managing changes to that project? If it's serverless, and you've got a dozen different— we've got a dozen pieces in one service, and then another dozen services with those dozen pieces, How is that all being managed? Is it in the codebase? Is it in— is the infrastructure described through the web app itself, or is it scattered around through a bunch of bash scripts, or worse yet, manual console settings that some engineer did years or months ago, and no one knows how any of this works? So in the context of serverless, what you need is— context of serverless is not only that, is the configuration, and then third order, how do these interoperable pieces work together? Is it that— is it that— are we using wildcard— if we're using star or wildcards in pretty much every part of every bit of our policy just to get it to work? That's a fine POC, but that does not need to get into staging. That does not need to get into staging, much less in production. That doesn't need to leave a localized dev environment. You got it working, good. Now, let's get it to the point where it'll actually work as it should.

29:15Robert HurlbutYeah, that makes sense. The other thing I think about from a serverless perspective is there are some fundamental pieces of security that are going to apply to everything that we do in the world. And so when I think serverless, I think, okay, authentication. How are we authenticating the users' requests, whatever is happening here?

29:33Ochaun MarshallYep.

29:34Robert HurlbutAuthorization. How are we ensuring that the right request, that the right user has the right privilege levels to be able to do things? How are we enforcing that on the backend? logging? How are we keeping track of everything that's happening to ensure that when someone does something bad, we can chase them down and catch them versus going, huh, well, they just used that browser-based app to transfer $1 billion because we didn't have everything working on the backside. So, um, when you, when you think about AWS in terms of security, uh, what are some of the frustrations that, uh, that you see?

30:11Ochaun MarshallSo frustrations, uh, one of them, Of course, many ways of skinning a cat, obviously. Another one is the built-in— the reason why a lot of S3 buckets— I'll go S3 buckets, because that's a red herring, and that's easy to beat up and kick people for having open S3 buckets. But the tooling is sort of— we've gotten to this point in the cloud where a lot of the stuff is proof of concept, or POC software. It's really easy to get running. It's really easy to get started. And then, in the blurb, in the documentation— and this is without fail, Microsoft, Amazon, everyone does this— it's like, in a production system, you might want to do it in a slightly different way than this. And that's the frustration. The security part, we haven't gotten to the point where the security part is easy. We've gotten the functionality part is easy, but we haven't gotten to the point— there hasn't been a real demand to get the security part to be easier than it should be. One reason why I say this is because if you're adding a new AWS service into your web app, if you're adding something new, one of the first things that you have to do is use— you think, okay, I'm going to use a built-in role in the IAM policy. You're going to use a built-in role. Usually, that's full read-on access, full write-on access, or full admin access. There's not a lot of gran— there's not a tutorial on how to do the granularity. It's all JSON when you actually dive into the technical details. It's just writing key-value pairs and understanding how to connect the different parts together.

32:09Robert HurlbutMm-hmm.

32:10Ochaun MarshallBut in terms of quick POC, click-through, let's get this to work, usually, to get something to a point where different parts at least communicate with one another, the easiest way is still throw on a full policy. And this is where I feel like S3 is a red herring. is because, of course, Amazon then cracked down and then provided better and more sane defaults, but there are so many other services, like think CloudFormation. CloudFormation is an infrastructure as code service. So when you're thinking of CloudFormation stacks and deploying, you're deploying dozens of services. Though it's really hard to tailor those down according to the principle of least privilege, because they have to have the privileges they need to function. Whether it's just being able to create EC2 instances, creating S3 buckets, creating Cognito, using Amazon Cognito, and things like that, that's a lot of stuff that you have to be permissioned.

33:26Chris RomeoRight.

33:27Ochaun Marshallto do, and it's really hard to break that down and make it granular. So there are no hard and simple rules that'll just make anything easier. I made fun of wildcards a few minutes back. I'm not contradicting myself when I say this, but you can't just go on further and say, oh, we can't have any wildcards in our IAM roles or IAM policies. That really— that you're really shooting yourself in the foot then, because You have to have the least permissive permission requires a lot to do, depending on the service and depending on what you're actually trying to do.

34:09Robert HurlbutYeah, I feel bad for the person in the development organization who's responsible for IAM roles, or the, you know, in AWS or in another cloud provider, because I was talking earlier about keeping it simple. There's no way.

34:25Chris RomeoNo.

34:25Robert HurlbutIt's not simple. It's so complicated. Like, I've been playing around with some AWS services, and the security person in me says, we have to do least privilege. We have to go through here and analyze all the events. I'm like, there's 1,242 possible privileges that this thing could have. Like, how could I even understand the categories behind it? So it's definitely crazy, but I think, you know, like you mentioned with S3, you know, Amazon moved in the right direction by saying, hey, We're just going to block— it's very hard to create a public S3 bucket now if you actually wanted one. You have to go through and really click a whole bunch of options to make that happen. I think that's part of security. Built-in security is hopefully where all of our cloud providers will go in the future. I don't think it's going to put us out of a job because I think it's still going to be complicated regardless of how they do it, but I think that's definitely the way of the future. Oshan, I want to kind of land the plane. here. I know we'll have to have a follow-on conversation to talk about pipelines and DevSecOps in the context of AWS, but we'll do that in the coming months here. But when you think about kind of your final thoughts, your conclusions, maybe a key takeaway for our audience, what would you want folks to take away from this conversation if they only remember one thing?

35:47Ochaun MarshallSo, the only way forward is empowering developers to make informed security choices. That is the only way forward. And the second order of business is that as AppSec professionals, we need to become mentors. We could still be wizards, like Gandalf is awesome, but you have to realize that Frodo, the main characters, the protagonists, the Frodos of the world, those are the developers. They're the ones in the organization that's going to carry the story because they're either building or— they're building or creating a service or providing a service to the organization. Unless your organization is focused on security and that's what we do, and even then, the focus then is then on the client that who then builds this wonderful and beautiful world of technology that we're in.

36:43Robert HurlbutYeah.

36:44Ochaun MarshallSo, first order, empower the dev. Second order, as an AppSec professional, just be a mentor and guide and facilitate them on their journey.

36:54Robert HurlbutYeah, that's great advice. This will be the first Lord of the Rings illustration that's ever been used on the Application Security Podcast, and I love it. I want to see you do a talk on AppSec and the Lord of the Rings. I will be in the front row with a sign. Going, you know, go Oshan or something. Yeah, so Oshan, thank you so much for taking the time here to share your experiences with AWS. And I know we didn't even get into the full depth of the conversation, so all that means is you've got to come back for a part 2 sometime in the next couple of months where we can talk pipelines, we can talk DevOps in the AWS context. So thank you for taking the time to share with our listeners today, and we look forward to talking with you again very soon in the future.

37:34Ochaun MarshallThanks for having me.

37:35Chris 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.