Jim Manico and Katy Anton -- The Future of the OWASP Proactive Controls
With Jim Manico and Katy Anton
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.
Audio hosted by Buzzsprout. Nothing loads until you press play.
Episode chapters · 10 chapters
- 00:00The future of OWASP Proactive ControlsAudio
- 02:43A defensive counterpart to the Top 10Audio
- 04:46The project’s origin storyAudio
- 06:10Priorities for the next versionAudio
- 09:11Whether data should shape the controlsAudio
- 12:39Mapping to ASVS and other projectsAudio
- 14:25A five-year vision for the projectAudio
- 16:24Language-specific developer guidanceAudio
- 17:24How the community can contributeAudio
- 18:50Final thanks and next stepsAudio
About this episode
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.
About Security Journey
Security Journey provides application security education for developers and everyone in the software development lifecycle.
→ Learn more about Security Journey
Connect with Jim Manico and Katy Anton:
→ Jim Manico on LinkedIn
→ Katy Anton on LinkedIn
→ OWASP Proactive Controls
Resources
→ OWASP Proactive Controls
→ OWASP ASVS
→ OWASP Cheat Sheet Series
→ NIST Digital Identity Guidelines
Actionable
From this conversation
- 2:01
Use developer-focused proactive controls
The proactive controls are targeted for developers and are created by developers.
- 7:44
Use community data to update controls
More from community feedback as well, and get some data so we can make sure we're picking the right categories.
- 13:15
Tailor ASVS to your standard
It's meant to be a big requirement database so you can go through a forking process and build your own standard.
Transcript · 20 min conversation
0:05Chris RomeoThe 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:23So 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:49Chris RomeoOkay. 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:01So 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:43If 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:35Chris RomeoSo 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:51It'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:26Chris RomeoYep.
4:27So 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:46Chris RomeoNormally 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:04The 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:09Okay, good. Awesome.
6:10Chris RomeoSo what are some of the changes you're looking at for the next version that are kind of floating around in your head?
6:16We'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:22Right.
7:22And 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:44Yeah.
7:44And 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:10Chris RomeoI 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:34Yeah, they're not kidding around, and frankly, that's very new for the project.
8:39Chris RomeoYes.
8:39The 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:11Chris RomeoHave 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:41I 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:56Chris RomeoYep.
9:56Who 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:30Chris RomeoYeah, that's fair.
10:33I 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:52That 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:20Yeah, when I've talked to others, they don't know that's in there.
11:22Chris RomeoI 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:32There'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:42Okay.
11:42I 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:17So—
12:17Chris RomeoIt 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:31Exactly. 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:39Chris RomeoSo 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:54Well, 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:06Yeah.
13:06The 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:15Yep.
13:15ASVS 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:59Chris RomeoI 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:22So these all get— it'll happen no matter what.
14:25Chris RomeoA 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:49What 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:48My 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:24So 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:37I 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:54Sure.
16:59Chris RomeoI 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:08I 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:21Yeah.
17:24Chris RomeoI 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:44The feedback window is still open. We plan to have it until the end of September.
17:49End of September.
17:50Okay.
17:51All right.
17:51Chris RomeoSo 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:21Not 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:50Chris RomeoYeah, 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:07Thank you so much. Thank you.
19:10Thanks 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.
3,326 words · transcript by assemblyai
More like this
View all episodes →- July 21, 2020 · 41 minElie Saad — OWASP WSTG, Cheat Sheets, and Integration
- July 25, 2017 · 44 minDave Ferguson -- The OWASP Top 10 Proactive Controls
- November 10, 2021 · 40 minSimon Bennetts -- Using OWASP Zap across an Enterprise