--- title: "Jim Manico and Katy Anton -- The Future of the OWASP Proactive Controls" url: https://appsecpodcast.com/jim-manico-and-katy-anton-the-future-of-the-owasp-proactive-controls/ date: 2017-10-03 duration_seconds: 1177 guests: ["Jim Manico", "Katy Anton"] topics: ["OWASP Top 10", "OWASP Projects", "Secure Development"] audio: https://www.buzzsprout.com/1730684/episodes/8122705-jim-manico-and-katy-anton-the-future-of-the-owasp-proactive-controls.mp3 transcript: true --- # Jim Manico and Katy Anton -- The Future of the OWASP Proactive Controls *October 3, 2017 · 20 min* with [Jim Manico](https://appsecpodcast.com/guests/jim-manico/), [Katy Anton](https://appsecpodcast.com/guests/katy-anton/) on [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [Secure Development](https://appsecpodcast.com/topics/secure-development/) [Audio](https://www.buzzsprout.com/1730684/episodes/8122705-jim-manico-and-katy-anton-the-future-of-the-owasp-proactive-controls.mp3) ## Show notes Where should the OWASP Proactive Controls go after giving developers a concise defensive counterpart to the Top 10? Project leaders Jim Manico and Katy Anton discuss the document’s origins, intended audience, and plans for its next version. They explore how much implementation guidance belongs in a short list, whether data should shape future priorities, and how the controls relate to ASVS, cheat sheets, and other OWASP resources. The guests consider language-specific guidance and a future in which developers can move from a high-level control to concrete examples for their platform. Chris also asks how the community can review and contribute. The conversation captures an open-source project deciding how to remain approachable while becoming more useful to practicing software engineers. The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/). About Security Journey Security Journey provides application security education for developers and everyone in the software development lifecycle. → [Learn more about Security Journey](https://www.securityjourney.com/) Connect with Jim Manico and Katy Anton: → [Jim Manico on LinkedIn](https://www.linkedin.com/in/jmanico) → [Katy Anton on LinkedIn](https://www.linkedin.com/in/katyanton) → [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/) Mentioned in this episode: → [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/) → [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) → [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) → [NIST Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) Chapters: 00:00 The future of OWASP Proactive Controls 02:43 A defensive counterpart to the Top 10 04:46 The project’s origin story 06:10 Priorities for the next version 09:11 Whether data should shape the controls 12:39 Mapping to ASVS and other projects 14:25 A five-year vision for the project 16:24 Language-specific developer guidance 17:24 How the community can contribute 18:50 Final thanks and next steps ## Transcript *3,326 words · assemblyai* **0:05 Chris Romeo:** The Application Security Podcast. Here we go. Hey folks, in this episode of the AppSec Podcast, we speak with Katie Anton and Jim Manico about the future of the OWASP Proactive Controls project. And that project is something we've talked about in previous episodes quite a bit, and they are very interested in gaining additional feedback on it. So we want to get this message out to you as soon as possible. We hope you enjoy. Hey folks, we are once again at AppSec USA and we are joined by some special guests who are going to talk to us about the Proactive Controls Project at OWASP. And so Jim Manico is back with us. He has been on the podcast before, so we've already heard his security origin story. We know where he comes from. But Katie, would you introduce yourself and Just tell our listeners where, how you got into security. Hello. **1:23** So my name is Katie Anton. I come from a software development background. I actually, I had to implement security in for my previous company. And this is when I started looking into what do I need to do in order to integrate security into the software development cycle. And this is the beginning of my involvement with proactive controls. project. **1:49 Chris Romeo:** Okay. So just in case somebody who's listening doesn't know, we're going to talk about some of the details of proactive controls, but maybe you could just give us a high-level summary to kind of set the stage for folks. **2:01** So the proactive controls are targeted for developers and are created by developers. So Jim and I are from a development background, and Jim Bird as well, who who is a CTO. And they are controls, security techniques that we would like developers to use while they write their code. So this would be something that they can easily use while writing the code without being security experts, but they still are able to produce a more secure software. **2:43** If I may, like the— this is Jim, hello everyone. The proactive controls document, it's kind of like a comment on the OWASP Top 10. The OWASP Top 10 is risk-based, really for more risk managers or more traditional security people. And very often as the OWASP Top 10 made its way around, I found that developers— it didn't always speak to developers, right? It's not in their language, it's in security language. So proactive controls is a is a kind of a comment on the OWASP Top 10, a similar kind of list that's made for developers by developers talking about high-level security areas that they need to concern themselves with. It's an awareness document. It's meant for one read. So my hope is developers read it once, then they never read it again. They go focus on other documents that go into more detail and nuance. **3:35 Chris Romeo:** So how much of a— how much kind of practitioner-type stuff is in there though? Is it Is it enough for somebody to really get an idea what they should go and do? Or is that the intention of it, or is it supposed to be a little bit higher level, kind of like OWASP Top 10? **3:51** It's— first of all, it's a top 10 document, so it is meant to be a high-level awareness document. And, you know, and we were fairly liberal in how we picked the categories. There's not like a stringent criteria here per se. For example, one of the categories, number 2, is parameterized queries, which is very specific, and we give exact code examples of how to do that. Another area is implement identity and authentication controls. We could go read a book on that and still have a lot of ways to go. In fact, look at NIST 863. This is like a 300-page document that talks about identity. **4:26 Chris Romeo:** Yep. **4:27** So these categories aim at different levels, but we think they're the, the kinds of topics that developers really need to be aware about, especially for their first approach towards web security, to help them be able to absorb other material around secure software building. **4:46 Chris Romeo:** Normally we focus on the origin story, like we already heard where Katie came from and her experience here, but I'm curious as to the origin story of the proactive controls. What kind of started this thing? Was it like 2 people sitting around a table going, we should write a another list, or how did it start? **5:04** The project started— I'm the original project leader of it. The project started with Andrew Vanderstock and I discussing, you know, we need to have a developer-centric top 10. Andrew got the project started, and Andrew moved to other things. Andrew is very active within the community. He's working on the OWASP Top 10 now, ASVS, and many other projects. So he didn't have time to stick with the proactive controls, and we just started building it out. I and a few others started just building it out. It got near the end. Katie and Jim Byrd joined around this time and were extremely active contributors, so I asked them both to be co-leads. I don't think any OWASP project, especially documentation projects for awareness, should be controlled by one person or vendor. So Jim and Katie joined, and now we have— and all 3 of us are from very different development backgrounds, and we do different kinds of software development. So We have exceptionally civil conversations, I would say, to help determine, you know, what the next version is going to be. **6:09** Okay, good. Awesome. **6:10 Chris Romeo:** So what are some of the changes you're looking at for the next version that are kind of floating around in your head? **6:16** We're in transition right now. So right now we're just about to finish the current version, version 3.0. And keep in mind, up until now, version 3.0, this is Katie Jim Byrd and I doing the best from our experience to pick items developers need to be concerned with. And so 3.0 is a, is a reshuffling of some of the items, but it's not a— it's honestly, it's more of a point change. It's not a major change. And we're, and, uh, we're getting community feedback. We actually made the document world editable so anybody in the world can anonymously provide comments. We make those comments not fully submitted so we can review them and accept or reject them as the project leaders, but we allow feedback from the entire world. We're in the 3.0 feedback phase. And again, this is a relatively subtle change, I think, right? It's not like a prolific change. After version 3.0 though, we want to be more in alignment with the OWASP Top 10. **7:22** Right. **7:22** And be more in alignment with data. So now that the OWASP Top 10 leadership has changed, they have 4 different leaders from 4 different companies, a new call for data, they're on GitHub now, all these very positive changes. I'd like us to be more in alignment with them. But what we asked is, we're so close to the end of 3.0, we're gonna finish 3.0. **7:44** Yeah. **7:44** And then as we approach 4.0, we're gonna try to be more in alignment with OWASP Top 10, with a call for data, and try to, try to build this proactive control list as something that's more than from our heads, right? And more from just community feedback as well, and get some data so we can make sure we're picking the right categories. That's like the transition we're in right now. **8:10 Chris Romeo:** I think that's wise. I mean, we talked to the OWASP Top 10, the new leadership group here at the conference, and they took us through their process and how they're collecting the data and going through it and deciding which direction to go. And I think that's just a really positive way to approach it. Let the community have some feedback. Not necessarily— no single person should be able to drive anything. It's all feedback process, but I think it's really good stuff. **8:34** Yeah, they're not kidding around, and frankly, that's very new for the project. **8:39 Chris Romeo:** Yes. **8:39** The OWASP Top 10 has been historically picked by 1 or 2 people in a back room with cigar smoke and infrared light, whatever. And to some degree, it's kind of like how we've done the project. of controls. Not intentionally, but this has not been data-driven, and we have done community feedback, but it's just been us. So we're eager to— I'm eager to echo the OWASP Top 10's model of a call for data and really try to increase the rigor of what we're doing as time goes on. **9:11 Chris Romeo:** Have you thought about what type of data you'd actually call for? Because with OWASP Top 10, it's pretty easy. You've got all these human testers and companies that have testing. and they have all these millions of results that they found over time. But from a proactive controls perspective, what would you ask people, like what do you envision saying? I mean, is it like people weighing in on kind of what their process is, like providing you their secure development lifecycle for analysis, or what are you thinking there? **9:41** I don't have a good answer for that. That's a really good question. It's a question that we're just beginning to dig into. What I know is is to go get help, right? One of the members of the OWASP Top 10 team is Brian Glass, who's a legit data scientist. **9:56 Chris Romeo:** Yep. **9:56** Who did some of the early analysis of OWASP Top 10 2017 RC1 to show what the data really says. So we're gonna lean heavily on some of the experts at the OWASP Top 10 area around what data we should be looking at, around how to do proper data analysis. I don't have that expertise. I don't know how to answer that, but I think that we're going to need to do some new surveys and work with the existing top 10 team to answer that question. So stay tuned for that. When I have a better answer, I'll definitely give you a ring and let you know what we're going to do. **10:30 Chris Romeo:** Yeah, that's fair. **10:33** I want to have a question about just the content itself. I remember looking at version 1 and seeing it definitely was more web-based or top 10-based. Version 2, it added mobile, some mobile top 10 and some guidelines if you're a mobile developer, what are some things to look at. How did that come about? Curious about that. **10:52** That was actually community feedback. So during the world open edit mode of version 2, we had that feedback. So it was just coming from the community. It's a good point to inspect our game to expand on that one or to have separate controls for mobiles. But that was community feedback at the time. Okay. **11:20** Yeah, when I've talked to others, they don't know that's in there. **11:22 Chris Romeo:** I didn't know there was mobile. And so I haven't read it from, you know, I guess line by line. But Robert was telling me, oh yeah, there's mobile stuff. And I'm like, I think I read it all the way through, but I must have missed it. **11:32** There's some mobile chitchat in there, right? As we discuss other control areas, these control areas, we have more mobile notes and mobile references. **11:42** Okay. **11:42** I envision long-term that if you look at how the Application Security Verification Standard project matured, they began with an ASVS list primarily for web security with a mobile section, and now the mobile section has turned into a whole separate standard, right? So now we have the massive, right, the Mobile Application Security Verification Standard, and the ASVS, which is more web-centric, I envision, if this control project continues, I envision having a mobile proactive control list. And I believe the mobile project already has some of that done already, frankly. **12:17** So— **12:17 Chris Romeo:** It would just be kind of repurposing it as another, a new document, maybe taking some of the things they've already developed in their project and bringing them into a new document and taking your best practices in together. **12:31** Exactly. And frankly, what they're doing at the mobile project is extremely mature. So there's a lot of activity there that we can pull from. **12:39 Chris Romeo:** So you mentioned the interaction with the Top 10, the proactive controls. Do you see a direct tie-in with ASVS, like a mapping, or is there— will there be a crossover ever? Is there a need for a crossover between these 2 docs? **12:54** Well, I mean, everyone loves to map everything to each other, right? It's what the scientists do. Keep in mind that ASVS and the top 10s are for radically different purposes, right? **13:06** Yeah. **13:06** The top 10 is meant for initial awareness, to get you warmed up and get you introduced to the topic of secure software in a hopefully gentle fashion. **13:15** Yep. **13:15** ASVS is not meant for gentle. This is a whole different ball of wax. This is hundreds of nitty-gritty detailed requirements. It's really meant to be a big requirement database so you can go through a forking process and build your own standard. Companies charge a lot to provide secure coding standards for other companies, and I'd like to have a good base to help facilitate that process. So that's what ASVS is. Now, of course, you can map these things together. I don't think— I just don't think it's that important. I think they're really separate projects meant for separate things, and making sure they're at least loosely in alignment is a good idea, But I don't— the mapping just doesn't speak to me. Is that fair? Yeah, that's fair. **13:59 Chris Romeo:** I had somebody else ask me that question about the— how do these documents all going to fit together in the future? But I think that's a fair reason to say that it doesn't— that not everything does have to map. And the challenge is this is a volunteer organization, and mapping, as soon as you make it, 5 seconds later, one of them's broken because somebody tweaks something. And then it's a constant battle trying to keep it in But don't worry, Chris, someone's going to map everything to everything. **14:22** So these all get— it'll happen no matter what. **14:25 Chris Romeo:** A whole cottage industry of mapping that's happening out there. So I guess as the project leads for this project, if you could look 5 years, you know, think about 5 years in the future, what would be— I mean, what would be your kind of things you'd like to see that are different based on the proactive controls? **14:49** What I would like to see is that these controls are actually implemented by developers. So I currently work as application security consultant. I work with developers on a daily basis and there is still, because developers do not have training in secure coding or security, We still struggle with input validation. Contextual encoding is still something that is not very clear out there. Even securing the queries to the database, especially for certain things that cannot be parameterized, like table names or column names. So I'd like to see that developers have taken this have spoken about these controls to other conferences and we see less of these defects in software. **15:48** My vision or my hope that someday is that we have a different top 10 defense list or, I'm sorry, top 10 proactive control list for Java developers, for Ruby on Rails developers, for .NET developers, for mobile developers. for embedded developers. So the more that we can split this out for each ecosystem, the better it's going to be. The top 10 list for one language doesn't always map to the others. It loosely does, but there are really specific things in Java that we can call out that are very different than what's happening in Ruby on Rails. **16:24** So similar to the cheat sheets, right, in the sense that you have some specific things, but in this case for developers, here's a whole set of things for that language, that platform, to be thinking about that may be slightly different than another platform or language. **16:37** I think if we matured in that direction where we had the OWASP Top 10 proactive Java controls and similar, I think that would really call to developers at an even deeper level. I've been saying this for a long time. I haven't done it yet. It's due time, right? **16:54** Sure. **16:59 Chris Romeo:** I think it's good to look into the— look and see kind of where do we want to get to in the future. And who knows, we may end up somewhere completely different, but it's still good to think about that. **17:08** I think the other important thing, Chris, is that we get more in alignment with data, that we do a call for data and figure out what data we should even be looking at as defensive thinkers. So that's the other ideal in the future as well. **17:21** Yeah. **17:24 Chris Romeo:** I mean, folks can go to— they can certainly go grab this document. And anybody who's listening to this, if you haven't read this, we've talked about proactive controls, I think, 3 times in the last 10 episodes or so. It keeps coming back up. So if you haven't talked about or haven't looked at that document, you need to go look at it. And is it too late for feedback right now, or is the feedback window still open? **17:44** The feedback window is still open. We plan to have it until the end of September. **17:49** End of September. **17:50** Okay. **17:51** All right. **17:51 Chris Romeo:** So that means I can still go and— I did browse around the document. I didn't add any comments. comments to it, but I did find it was the Google Doc version that you had, so I could see there were other people poking around as well. So I guess that's the takeaway for the listeners is go take a look at this document. This is a chance where you can have your voice heard. These folks are project leaders. They're saying they want to hear feedback from the practitioners and everybody out there. And so yeah, I think that's— do you have any other questions on the proactive control side? **18:21** Not at the moment other than just a comment. It's a great resource. I've used it, I've taught it, I've introduced it to a lot of developers out there. They know about the OWASP Top 10, they've heard of it many, many places, but not the proactive controls. So thank you for your work, and for myself as a person out there trying to push it as well, I think it's great to have a resource like that we can put out there and help developers understand what they need to do and some ways to help them in their own secure coding. **18:50 Chris Romeo:** Yeah, thanks for being project leads. We know that that's not always It's not always the easiest thing. Sometimes you got to deal with people that are— that want to be difficult and whatnot. But, you know, we know you volunteer a lot of time. We appreciate it, and we really like the document, and I recommend it everywhere I go these days. So thank you for your time. **19:07** Thank you so much. Thank you. **19:10** Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org. --- Source: https://appsecpodcast.com/jim-manico-and-katy-anton-the-future-of-the-owasp-proactive-controls/