Interview: Bradley Schaufenbuel, Director of IS at Midland States Bank

In this interview, we're talking with Bradley Schaufenbuel. Brad is currently the Director of Information Security at Midland States Bank and held security leadership positions at many leading financial institutions.  

Bradley is the author of "E-Discovery and the Federal Rules of Civil Procedure: A Pocket Guide", published by IT Governance Publishing, and has had articles published in professional journals on a wide variety of topics related to information security and governance.

In this episode, Jeff and Bradley discuss what is unique about security in the financial industry, what to look for in security vendors, and security awareness training. The following is a brief excerpt of our complete interview. 

Jeff Williams: Now, I work in application security. So I do a lot of work with custom code and libraries and components and so on. Tell me what you guys are doing for application security. How should that fit into an overall security program at an organization like yours?

Bradley Schaufenbuel: I think application security is a vital component of any financial institution's information security program, regardless of whether a financial institution develops an application in-house or purchases an application from a third party. It needs to have some assurances that the code base is not riddled with security bugs, before that application is placed into a production environment.

Jeff Williams: I'm glad you mentioned that because so many people forget about the app that they didn't write, the ones that they've acquired or procured in some way. They should meet the same security requirements as the code that you're writing.

Bradley Schaufenbuel: Yeah, definitely. I think the best way to insure that insecure code is not leaving your financial institution's information vulnerable is to implement a robust application security program. That starts with educating application developers on secure coding techniques, assuming that you're developing applications in-house. If the financial institution has generated or has access to source code, that code should be reviewed for security flaws. The most expeditious way to accomplish this is through the use of automated tools, supplemented with human expertise.

Jeff Williams: Yeah, I couldn't agree more. It's a hybrid kind of problem.

Bradley Schaufenbuel: Yeah, but like you said, even if a financial institution does not have access to that source code, an application should be scanned for susceptibility to vulnerability, such as cross-sight scripting, SQL injection, using some kind of application vulnerability scanning tool. These reviews should be completed and any significant issues addressed before the application is promoted in production. Finally . . .

Jeff Williams: You know what's interesting? I was going to say you should even do it before that product gets acquired. Right?

Bradley Schaufenbuel: Yeah. Oh, yeah.

Jeff Williams: So many organizations I work with . . . they buy the product, they bring it in, they set it up, and then they do the security test, and they realize that this product is basically insecurable. It's just riddled with holes. Then they've got a really difficult situation on their hands.

Bradley Schaufenbuel: Yeah, that's true, definitely. The other thing that people forget about is that new application vulnerabilities are discovered every day. So a robust application security program should also include some type of continuous monitoring and testing after an application has been promoted in the production environment. A lot of people forget about that. Once they get it into production, and they sign off on all the security tests, they say, "We're done." Then it sits out there. Over time, vulnerabilities are found, discovered, and nobody goes back and retests that application. So I think that goes to the theme of this set of programs, which is continuous.

Jeff Williams: Yeah, I really appreciate you bringing that up. I mean, I really do think it's important. That heart bleed incident from a couple weeks ago really pointed this up in so many organizations, that vulnerability was discovered, but it was so difficult for organizations to track down where is open SSL being used, how can we test for it, how do we replace it, how do we update it, and just caused a ton of work for us admins all over the country.

It could have been a lot different. Right? If we were continuously testing for these things, we could have added a new application vulnerability to our management system, pushed out the rule, and then in a matter of minutes or hours or whatever, we'd have a full dashboard of where the problem is and what needs to be fixed and who needs to be contacted. It just could have been a lot, lot different.

Bradley Schaufenbuel: I agree.

Jeff Williams: What do you look for from an applications security program? What kind of output can they generate that really helps the organization?

Bradley Schaufenbuel: In terms of key metrics?

Jeff Williams: Metrics, other ways that they can influence the organization. What should they be producing?

Bradley Schaufenbuel: Okay. Well, a key tenant of the application security is that it's significantly less expensive to eliminate vulnerabilities earlier in the software development life cycle than later. So it used to be that the success of an application security program was measured using metrics such as the total number of security defects eliminated per 100 lines of code written. I don't think this legacy metric is as useful as it once was, but it remains a somewhat good indicator of whether developers are adopting secure coding practices.

I think the more meaningful metric or output is one that demonstrates that security flaws are being caught earlier in the software development life cycle rather than later. So I advocate tracking the number of security defects found during the code review process, versus those found by the quality assurance team during testing, versus those found by application security testers prior to promotion in the production.

So the key metric then becomes the percentage of security defects found at each checkpoint within the software development life cycle, with the goal of increasing the percentage of defects found in earlier stages over time.

Jeff Williams: Absolutely. I couldn't agree more. Because if you find a vulnerability in some later stage, you shouldn't just fix it and continue. You should ask the question: Why didn't we find this one stage earlier or one stage before that or all the way back during coding? If you do that root cause analysis, you can improve your program over time and push that stuff very early in the development process.

Bradley Schaufenbuel: Yeah. Going back to kind of the theme of the series, an important indicator of the inherent quality of application code is how many security flaws are discovered during the maintenance phase of the software development life cycle. So research shows that fewer post-implementation vulnerabilities are discovered in applications that were developed using secure coding practices to begin with. So the volume of bugs found during ongoing maintenance is an excellent indicator of initial code quality.