Bank exec recommends more software security scrutiny

National Australia Bank (NAB) delivers a scathing report on the insecurity of enterprise software

Since establishing a technology risk and security team more than two years ago, the National Australia Bank (NAB) has delivered a scathing report on the insecurity of enterprise software, including that provided by information security vendors themselves.

During a presentation at this year's Gartner IT Security Summit in Sydney, the bank's general manager of technology risk and security, Gary Blair, said over the past two years his team has reported 48 defects to software vendors, and since only high and medium defects are reported "they are not trivial".

"I would like to have a basis for not talking to you today, but two defect reports a month is too large," Blair said. "We believe the research focuses elsewhere. Most security research for commercial software is done in the consumer space. We don't believe there is enough focus on enterprise software. It may have been sufficient in the past but not any more."

NAB's technology risk and security team discovered most vulnerabilities related to privilege escalation, and authentication bypass mechanisms and SQL injection attacks were also prominent.

Two security testing capabilities were created within the team to focus separately on projects and operations. The team itself undergoes an annual probity check to ensure "the right people" are working in the team.

"We identify defects in own code and in the configuration of commercial software, but we found more than that," Blair said, adding the serious attacks are moving up the solution stack making network layer defenses still necessary, but not sufficient.

Blair said data is becoming the primary target and serious attacks are motivated by financial gain, and international crime gangs and rogue nation states have proven well enough financed to recruit the skills to perform attacks.

"I'm impressed by quality of exploit code," he said. "We are seeing growth in ability for people to deploy malicious code and that code is well written."

Back in the "green screen" days banks had a person sitting at a terminal with a secure SNA connection to the mainframe and would interact with a customer over the phone. As technology adoption broadened, banks provided customers with direct access to systems via IP networks.

"We are opening up data stores to people who previously didn't have access," Blair said. "The business models are the right ones, and there is no going back; we are putting data into position where we need to consider security. Software as a service, SOA, and Web 2.0 also present more risk to data."

The team's focus is on testing at the time of product evaluation prior to purchase or, having gone through that process, while going into production when "defects in vendor code should have been sorted out".

NAB has now published its own reports on enterprise security architecture and patterns, secure code standards, secure code reviews, and security training for architects and designers.

Blair said security auditing is difficult to do with vendor products as the bank has little or no control over security in third-party products, but believes the vendors are opening up.

"Some are more than happy to talk about defects, and some grudgingly accept them and see how their own code can be improved," he said.

Blair said software used in the financial services industry is not inherently less or more secure than that for other verticals but did single out software for security purposes.

"It's almost a contradiction in terms, but we see so many defects in security software," he said.

In one case, the bank tested a security product which was recommended by industry commentators and "had all the pedigree" only to find the product didn't stack up to the vendor's claims and could not be deployed.

"Beware of claims of a product being security tested by the US Department of Defense or US and Canadian banks," Blair said. "Security products are not immune from defects and vendor claims should be checked and not taken at face value."

Blail's team also discovered the length of time it can take to report a defect and have it closed by the vendor.

"We are committed to working with vendors to close them out and 90 days seems to be the right time to close defects out," he said. "Some .Net vulnerabilities take longer, and depending on the nature can take up to a year. I am concerned about defects that take up to 120 days and shows vendor intransigence."

The team notified IBM of two defects in its MQ messaging software, one being a secure channel bypass that was considered a critical vulnerability.

"Their [IBM] MQ labs could not repeat the vulnerability, so we packaged the exploit code and then they could repeat it," Blair said. "We remained in contact with them from March and on August six they fixed it."

Blair said product maturity does not equal security, and MQ "would be a case in point".

"We would like the industry to consider what we have done and to challenge what we have said or agree with it," he said. "We have a problem we have to address as software is being used in increasingly hostile environments and customers' expectations are changing."

Blair said vendors need to increase focus on security engineering during product development and Microsoft has made "massive gains" in this area.

"Above all, view third-party reviews as an opportunity to improve software quality," he said. "We are getting better at testing and we still have time in the industry to address this problem with vendors and customers."

When asked about the similarities between what the NAB has done and the development methods of open source software, Blair said most of the open source software the bank uses is supported by a vendor, but the team would like to do a lot more work with the open source community.

Join the newsletter!

Error: Please check your email address.

Tags securitysoftwareSecurity IDbankNAB

Show Comments
[]