Interview with an AppSec Professional: Designing an AppSec from the Inside Out

While it’s difficult to get permission from one’s corporate communications team or legal department on chatting with vendors, I was able to secure an interview with one of our financial services customers who use both Dynamic and Source code scanning.

Naturally, securing the financial and personal information of their customers is a primary concern, along with the integrity of the accounts. I think it’s important for companies who are successfully protecting their infrastructure in holistic way to talk about how they’re accomplishing their goals so that other companies can mimic their best practices, and I asked them for an case study.

Even though they wished to remain anonymous, their Application Security Tech Lead “Julie” was allowed by her management to be interviewed.

Me: Tell me about how your organization is built around the idea of security – both network and application, if you don’t mind? Set the scene for us.

Julie: We were lucky – our CSO staffed out the Security organization from the ground up. Application Security was a defined position, and has been for nearly five years now.

We have a dedicated network/infrastructure security team, and they have separate processes. Because application-level vulnerabilities are different in genesis than infrastructure vulnerabilities, anything that comes up comes to the Security Team, which I’m a part of. We work closely with the DevOps team, so we can work in new findings with their backlog and sprint schedule.

Me: Did you try out other application security vendors before coming to WhiteHat?

Julie: Sure we did. Even some open source scanning tools. The challenges are the same across them all – but we really liked working with your Threat Research Center team, and having dynamic and static options from the same vendor.

We do annual third-party penetration tests as well due to security policy. Honestly, most of what they identify are items we’ve already found with WhiteHat previously. Only once in four years has there been any kind of discrepancy – we like the complete coverage.

Me: What do you like about our Sentinel Source service?

Julie: Well, first of course is finding code issues pre-production. Once we figured out how to integrate the process with our developer environment, it was great. We had some configuration challenges at first, learning how to pull source code and point it in the right direction. We’re broken into multiple code bases and applications – so size and scale were a challenge for us.

We also had slow going through certain hooks – i.e. debugging in our lower level environments. That was worth the time to set up with a great deal of care. But through it all, we had the TRC to ask for advice and Q&A.

Me: Did you use any integrations into your IDEs? ALMs?

Julie: Not really. We use it through Sentinel. We toyed with the Visual Studio plug in, but our developers at this point just want the user stories in their backlog. They pick up the stories, and configure the sprints. And they use Sentinel for reference, or to ask questions.

Me: Has your application-level patching speed improved?

Julie: Oh, much, although the speed can depend on the vulnerability – what it is, and where it is. We started out with dynamic scanning of our production website a few years ago with WhiteHat, and since have added static code scanning and dynamic scanning both to our QA environment. We have a policy we’ve put into place requiring High and Critical vulnerabilities to be patched prior to pushing anything into Production.

Me: What about Medium and Low level vulnerabilities?

Julie: We try to fix those as well, but for anything not High and Critical, we do a risk analysis versus time to fix by talking to the development team, and sometimes slot them into a following sprint. All new vulnerabilities we find get taken care of relatively quickly though. Mostly.

Me: Mostly?

Julie: Yeah, it’s a function of whether the scanners find something new in Production. Once those new findings show up in your scanning engines, it kicks off a process of looking at them and performing a risk analysis. We have a strict timeframe for High and Critical that remains a constant, though.

We found a sharp drop-off in findings on the production side once we had established source code scanning. Not an elimination, though. There’s always new findings in the wild, right?

Me: How has using WhiteHat Sentinel changed the way your development team does their jobs?

Julie: First of all, our development teams have gotten better. They attend some of your technical webinars and demos, as well as annual training. We really like the way you guys explain vulnerabilities to them, so they learn as they go. 

Me: Are you looking at going mobile any time soon?

Julie: It’s a future plan, and an active project. The development is happening offshore with contractors, but once it’s built all the source code comes in house and we’ll be scanning and, of course, fixing it ourselves.

Me: Do you have any advice for other financial organizations like yourself?

Julie: Sure! Build application scanning into your development process, so that you are scanned and tested before you ever reach production. It helps minimize your risk, and sure saves time.

Me: Thanks so much for your time!

The post Interview with an AppSec Professional: Designing an AppSec from the Inside Out appeared first on WhiteHat Security.

*** This is a Security Bloggers Network syndicated blog from Blog – WhiteHat Security authored by Jeannie Warner. Read the original post at: http://feedproxy.google.com/~r/WhitehatSecurityBlog/~3/-xe0h7IW-ZA/