Clear Messaging for AppSec Success
I caught S03E05 of the Application Security podcast the other day; “SAST, DAST, and IAST. Oh my!” It featured Pete Chestna (@petechestna). I found it so compelling, that I thought I would put together a few quick thoughts on what really grabbed me and add a few of my own.
I’m in no way an AppSec expert. If you want experts and their advice, there are plenty of people you can and should talk to or read. People like the good folks at Veracode, OWASP, etc. People like Daniel Cuthbert, Jim Manico, Mark Curphey, and Andrew van Der Stock. This is just a small sample. Point being: there are resources out there if you aren’t sure where or how to start your AppSec journey or if you want to elevate it.
There’s a real unevenness in AppSec as it relates to InfoSec budgets. Recent estimates I’ve seen show us at about a $90 billion industry with about $2 billion spent on AppSec. There are a few different ways in which we can slice and dice those numbers but I think most of us would agree there’s a real incongruity here. To address that incongruity, we need smart and articulate professionals out there spreading the message about security applications using the three “C”s: Consistency, Confidence, and Clarity. Pete really nails it during his interview. Here’s what I liked:
SAST and DAST. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) have been around for a while and have some level of adoption in enterprises. I still think we do a pretty poor job of explaining even the basics to business leaders. That’s why it’s not as widely adopted and why it’s even less successfully implemented in most enterprises. When Pete said to think of SAST as “Inside Out” and“the foundational technology” and then DAST as “Outside In” it really resonated with me. Dispensing with all of the hand waving and big words, this is such a powerful way to start the conversation. Yes, of course, there are other ways to explain SAST, DAST, IAST, and RASP. And no, this by no means ends the conversation and explanation. But leading with those simple words and phrases starts the conversation in a better place.
Requirements and Expectations Setting. I’ve been a part of two AppSec program builds. One went so-so, and the other didn’t go well at all. In the requirements gathering and expectations setting I like how Pete establishes a nice baseline of “Functionality and usability, Accuracy, and Integration” when talking about InfoSec tools. I especially enjoyed his description of ALM tools as “This is where work goes.” Point being: as InfoSec leaders, we need to acknowledge what developers use, how they use it, and integrate with it. I love this concept when dealing with development teams. The point here is that we - InfoSec - need to integrate with their framework(s). Not the other way around. This isn’t an issue of ceding a position; “you come to me, I don’t come to you.” It’s important for InfoSec pros to understand these dev teams have been running for years and have built a massive estate of infrastructure, tools, and processes. We are but one piece of that. An important piece, of course. A piece that was perhaps neglected in the past? Most likely. Nevertheless, you’re most likely walking into a program that’s been lacking an AppSec focus but still has considerable people, tools, and processes. Know your place in the process when building your requirements and expectations.
Velocity. I love the usage of the term “velocity” that Pete brings up. I’m going to merge it with a concept around software “defects” that I’ve included in my past evangelizing. Using “defects” works in my experience, especially in manufacturing or the energy sector. I’m definitely using it in the future. I’m thinking something like, “What if I could increase your velocity and decrease your defects?”
Education and Training. What is the top focus of an AppSec program? When you listen to the podcast, you’ll hear Pete say, “Secure Developers.” I like this approach and I think it meshes well with a more agile development environment where we focus on a lack of defects but with increased velocity (see what I did there?). While I agree that well-trained developers that, ideally, are producing few if any defects, is a key area of focus, I’m not sold on that being the pitch that gets us more seats at more tables. But I like the concept and it makes me think…a lot. My tendency is to focus more on requirements gathering, implementation tools and methodologies, and metrics & reporting with well-trained developers being another key pillar.
Pentesting. As we mature as an industry, I’m seeing and hearing more and more professionals talk about the lack of utility in or the misuse of penetration testing. I thought Pete did a really nice job of explaining one place where Pentesting is useful by saying “I want them [pen testers] to find logic-based errors.” Pete pointing out how SQL injection testing isn’t what we need people for is the kind of thing I wish more people in this industry would get.
My thoughts: Communications and Partnership. Communication and Partnership is one of those areas that sadly are going to make or break an implementation. This fact is both true and an honest-to-goodness shame; it doesn’t have to be this way. In my experience, InfoSec professionals have taken some really inartful paths in building or running AppSec programs. Here’s the thing, if you think you’re going to leverage the awesome power of the compliance gods to beat development teams into shape, you’re out of your mind and you probably need to find another gig. If you think you’re going to harness the fire and brimstone of management escalation to drive secure AppDev, maybe this isn’t the field for you. Perhaps you feel like putting your new intern on the project to lead it - to the tune of 25% of his/her time - is acceptable. Good luck.
I’ve seen - and participated in - plenty of AppSec programs that have a budget and focus and simply have the wrong people on the project. They don’t communicate using the three C’s - Consistency, Confidence, and Clarity - and they don’t inspire partnership and collaboration. Here’s what you need to take away from this: one can buy the latest and greatest tools, secure budget, have the board’s support, and have a team of pros ready to get their AppSec on but if they aren’t communicating with the three Cs and they aren’t engaging in a true partnership with the developers, odds are, they’ll fail.
AppSec projects - especially brownfield projects - need professionals who are technical, personable, collaborative, empathetic, sympathetic, knowledgeable, and politically adroit. When I hear people like Pete Chestna talk about the hows and whys of AppSec, I’m really encouraged; it makes me want to do better. As I’ve highlighted, Pete makes plenty of points that will do just that.
Link to Application Security Podcast episode: https://www.appsecpodcast.org/2018/02/16/sast-dast-and-iast-oh-my-s03e05/