Building Better AppSec Teams: Communication, Collaboration, and Cloud | Kristen Bell

Episode 32 | Reimagining Cyber
Building better AppSec Teams: Communication, Collaboration, and Cloud | Kristen Bell

Kristen Bell  00:03 

It's super important that if you're building a portal or a wiki or this one stop shop for the developers to have these self service options, they need to know it exists. So, I always say, you know, every time you have an all hands call, or if you have a newsletter, or if you send out an email, and in your conversations, refer back to where this thing is, and tell everybody about it. 

Rob Aragao  00:34 

Welcome to the Reimagining Cyber podcast where we share short to the point perspectives on the cyber landscape. It's all about engaging yet casual conversations, and what organizations are doing to reimagine their cyber programs, while ensuring their business objectives are top priority. With my co host, Stan Wisseman, Head of Security Strategist. I'm Robert Aragao, Chief Security Strategist. And this is Reimagining Cyber. 

Rob Aragao  01:03 

So, Stan, who do we have joining us for this episode? 

Stan Wisseman  01:06 

Well, Rob, as you and our listeners will recall, we had Kristen Bell on a couple episodes ago. Well, we brought her back because we have so much more we want to talk about. Kristin is a senior manager of application security engineering at Guide Point Security. And if you recall, she's worked at an application security for many years. 

Rob Aragao  01:23 

Kristen, I'm so happy to have you back with us on the podcast. So, let's kind of continue the conversation we had previously, you have be taking us on this journey and how different organizations can mature their program. We continue and evolving it up into the right. And one of the areas is obviously how application security testing is being better embedded, let's say at this point to see ICD pipelines. And I'd love to hear you're kind of examples of where success has come from with more the automation capabilities, better integration into the dev tool chain, as you were talking about some different things earlier, like, what are some of the specific areas you're seeing around that synergy, again, of automation, and really helping the security testing capabilities just getting bedded into what's happening within the development teams and testing teams? 

Kristen Bell  02:13 

Sure. So, I think one of the keys to success, I think, is as we're bringing these developers along this path with us, one of the things that we need to be really cognizant of is them not getting a bad taste in their mouth for automation and for tools. The biggest thing you'll hear developers talk about is, “I don't want to be slowed down. I don't want the tool to be noisy.” And by noisy, I mean, lots of false positives. So, we take on when we're in a plan environment, we take on a multi phased approach, we start off saying, okay, developers, you know, here's what we're going to be doing. This is the goal, this is the path that we're down, and eventually, you're going to have these tools in your IDE for you to run yourself. So, I think one of the things that we're trying to figure out, as far as the scanning itself is, are things running smoothly, do our nightly scans, for instance, a way to have things going for the developers, for ease of use, we want to make it as seamless as possible, we want them to be getting the most high quality results as possible. And that really takes a lot of work on the front end. The clients who have tried to buy a tool and fully implement it, usually end up not being very happy with that tool, because the developers get really resistant to it. So, as we do that, the other things that we want to do from an automation perspective, is do things like integrate with a ticketing system, whether it's JIRA or some other solution, we really want that continuous feedback loop. We want to also be able to get the metrics out of that so that we can show return on investment. As far as CICD, we still want gates in that process, we still want there to be that checks and balances, we just have to be really careful about what those gates are, again, to not slow down the process. We also do things like recommend that there be a process around the developers requesting false positives, to be evaluated so that they can keep moving beyond their build cycle and then if those false positive so are real things, and that turns into an exception request. We want there to be more feasibility within the exception process and the risk acceptance process. In some organizations, absolutely every single exception rolls up to the CSO. And that's really not as sustainable in a fast paced development arena, right. So, we want other people on the security team to have the power to actually accept certain types of risk on behalf. And then we also want the app owners and development to have some skin in the game. Because if the security team was the only entity within the organization that has to take on that risk acceptance, there isn't the motivation for the developers and the app owners to actually fix some of those issues, everything starts turning into an exception. So, we do want to see a balance there as well. 

Stan Wisseman  05:43 

You want to avoid a culture of risk acceptance, you want to have the development team sort of own that as a responsibility on their side to ultimately work on that backlog of mitigations. They have to work off right. Typically, when we're talking about integration into the CICD pipeline, we're talking about using static code analysis, right. And, you know, dynamic analysis, you mentioned QA earlier, as being a good friend for the application security team, because dynamic analysis typically is later in the lifecycle. You know, it may be actually used by the QA team. But are you starting to see vast shift left and used earlier in that lifecycle? And maybe even integrating into the CICD pipeline? Are we getting the response times necessary to be able to, again, not frustrate the development teams? 

Kristen Bell  06:41 

I believe so. So, I think the DAST vendors don't want to be left out of shifting left, right. I think there are there are some competitors with them that are saying, oh, DAST is dead. And I really don't think that DAST is dead. I think that it's a very useful tool. As I said earlier, you know, it really looks at the application and what and how it interacts with its ecosystem. It has findings that you wouldn't necessarily get from other tools, like, are there things out on that server or things available to the web app user that shouldn't be? You know, can they fuzz a little bit and go find admin functionality, or be able to traverse some directories and get access to something that should be restricted? Those were things that DAST is really good at or looking at the SSL certificate or you know, other things like that, discovering things, maybe API's or whatever through the web application itself. So, DAST is a very valuable tool. And I think that, like I say, the DAST vendors don't want to be left out of shifting left. So, they really started to be more aware of how do we integrate better earlier on in the lifecycle. And I think we're going to see more and more of this from them as far as functionality and ways to integrate earlier in the development process. But we are starting to see it now. And like I say, I think it's a response to where the culture is going. And they just don't want to be left behind. And we're glad to see that because again, we see a lot of value in DAST. 

Rob Aragao  08:27 

Kristen, I just wanted to kind of take us back to one of the things you mentioned before around the developers and kind of some of the lack of security specific education kind of coming up through the ranks right, at schooling and going through and it's not really part of the program. Now it starts to get implemented the program, which, when you think about it at the court, it's not that developers don't care about security by any means, right? It's yeah, they've got this effort in front of them to work through to meet a deadline to release something that typically right, it's going to generate some new revenue streams or additional revenue to the company get it. Right. That's typically the case. But the need for securing or better enabling the dev team to understand security is key, as you've alluded to, are there specific examples that you've seen really work around, you know, how you get better buy in from the dev team around application security in particular kind of approaches or programs that have been really moving the needle in a positive direction? 

Kristen Bell  09:24 

Yes. So, I think it's a multifaceted approach. Right. So, we talked about from the very beginning, communication is so important and imperative to strong app sec program. And I think part of that is through education. We beyond the secure app sec Advisory Board, if you will, I think that's a great learning tool, because it works in a bidirectional manner. Right? The developers feel like they have a seat at the table. They have influence over the direction that they're app sec program is going. But they're also learning a lot. And those liaisons that are members of that board, go back to their teams, and they start teaching their teams what they're learning as part of being a member of the larger group. So, you have that kind of education happening. You also, one thing I always recommend to clients is to start, what icon I've been told it's really a corny name for it is an app sec, one stop shop. But you can call it whatever you want. What I'm basically driving at is a centralized location, where you can store all things related to your app sec program. So even your standards, if it doesn't matter, if your all of your standards for an organizational perspective have to be stored in the same location, you should be able to link it within your one stop shop over to the standards. If you do lunch and learns. If you have, you know, somebody who is speaking to your developers, you know, that's a, that's an app sec person out in the community that maybe one of your people saw an OWASP meeting or something and you invite them to speak to your developers, ask them if you can record it and store it there. If you find trending vulnerabilities coming out of your testing, there should be self service options for those developers. But going back to communication, it's super important that if you're building a portal, or a wiki, or this one stop shop, for the developers, to have these self service options, they need to know it exists. So, I always say, you know, every time you have an all hands call, or if you have a newsletter, or if you send out an email, and in your conversations, refer back to where this thing is, and tell everybody about it. And if you get questions that can be found out there remind those developers, that also helps us expand the resources, because as we said, usually the developers far outnumber the number of App SEC people. So, we're also in our program, working on how do we expand our resources to the nth degree. And these self service options are a big part of that. Other ways to get training into your environment, like I said, you know, I mentioned somebody's going to an OWASP meeting, I highly encourage development leadership to allow for and encourage their staff to join community organizations like OWASP, many times the bigger OWASP conferences, are really geared more towards developers and app sec people. There's ISSA, there's ASACA, there's a whole lot of different kinds of organizations, and community involvement, that these teams can go and be active in in their local communities, that I would also encourage people on the security team, if you go to a conference, these speakers have to, in order to get chosen to speak, they have to document their speaking engagements. And they like to do trial runs and dry runs to practice before they go to the National Conference. Most people in our industry love to talk about what we do. And they're happy to come and speak to your developers. So, I highly encourage people to reach out or walk up to a speaker after they've done a talk at a conference and say, “Hey, here's my business card. come speak to my developers, they need to hear this from somebody besides me.” 

Stan Wisseman  13:42 

That's a great recommendation, a great set of recommendations. Kristen, we've covered a lot of ground, I do want to ask one last question around what we're obviously seeing with digital transformation, and specifically, development and apps going to cloud environments. That's another set of challenges for app sec. Right? Yes, as microservices and containers are used. It's a whole other environment that we have to deal with. Right. And I just wondered as far as when you're helping organizations pivot to address these new risks that are introduced with this shift of workloads and development and testing to cloud? How are you helping them understand what to do? 

Kristen Bell  14:33 

So, we do have in house cloud expertise so sometimes I'm conferring with them, and we've come up with some joint recommendations. I think there's a couple of pain points for organizations making the move to cloud. One is that old traditional separation of duties, right? It was always very clear cut, where the infrastructure, you know, no developers ever have access to production and we don't make changes in production. And those rules have all changed when we start talking about cloud, because infrastructures code is just more code. So we talk about profiles of people, and people playing different roles within the development teams in order to keep those separations of duties and tact. So that would be one. The other I think, is all of this data. You know, we have these emerging privacy laws all over the place, we had New York, there's one in Brazil, we've had GDPR, California, the list goes on and on. And it's going to continue to grow. And so now we have these data points, like you're saying, micro services and API's. And these privacy laws are requiring us to geolocate data. So, it's extremely complex, and adds exacerbates more around, you know, where all this data is flying to. And now we have to track it, right. So, I think, things that have come up that used to sort of be dead are things like threat modeling. Threat modeling, going through that exercise and looking at those data flows and the trust boundaries, and identifying what data is going through the flows. It helps us document and make that a repeatable process as well as be adhering to the compliance requirements that we're now faced with, with this geolocation of data requirement. So, we're seeing things like that. We're also seeing technologies going back to DAST for a second, who, you know, used to be that DAST could test a web application, but it wasn't really great at testing guileless technologies like API's, well, now we're seeing the technologies be able to ingest swagger documentation, postman projects, soap UI, right? So now we can start actually automating some of the testing of all of these guileless technologies that we're seeing and all of these data flows that we're now contending with? 

Rob Aragao  17:08 

Well, Kristen, I think you've definitely shared many different examples of what other organizations should consider as part of their app sec program, wherever they may be in their journey. I really like the aspect of maybe pivoting from that kind of previous terminology and thinking around the security champion to your application security advisory board. To me, it sounds like you know, a better way to present things to get more collaboration, more people involved. And it's not kind of sitting in one silo with someone so kind of controls it from a security point of view. I also like the one stop shop, I think the self service model is a different examples kind of capture, everything makes a lot of sense. And in the end, it kind of comes down to maybe what I would refer to as kind of the three C's, right? You're driving the proper communications, collaboration amongst the teams, you're tearing down the walls, and ultimately, that all enables culture, right? The culture of really security, just embedded baked into anything that anyone is doing, no matter what role they have, within that kind of software journey. So, appreciate you coming on and sharing those different examples, a different way to kind of really look at things and help organizations overall. So thanks, Kristen. 

Kristen Bell  18:09 

Thank you all. Thank you so much for having me.  

Stan Wisseman  18:12 

Thanks, Kristen. 

Rob Aragao  18:13 

Thanks for listening to the Reimagining Cyber podcast. We hope you enjoyed this episode. If you would like to have us cover a specific topic of interest, feel free to reach out to us and you can find out how in the show notes. And don't forget to subscribe. This podcast was brought to you by Cyber Res, a Microfocus line of business where our mission is to deliver cyber resilience by engaging people process and technology to protect, detect and evolve