6 Reasons Secure Coding Can Still Lead to a Shipwreck
Despite our best efforts to write secure code, computer security breaches at major banks, retailers, and government agencies are making front page headlines on a regular basis. Here are six reasons writing better code may only address a fraction of a bank’s total application security risk.
1. The tip of the iceberg: Modern banking applications are written by developers using a combination of their own software together with open-source components, third-party libraries, and development frameworks -- much in the way manufacturers use a mix of in-house and sourced components in their finished products. Various industry studies suggest that only 10 to 30 percent of custom applications are written by a company’s developers. So even the most secure coding practices in the world, perfectly executed, will only address at best 20% of the potential risk. That’s only the tip of the iceberg.
2. It’s not my iceberg: This statistic varies among financial institutions, but in most large banks at least half of all of software applications are purchased, perhaps with a small element of customization, from a third party. Since it’s unlikely that a bank can access the source code of third-party applications, verifying whether they have been developed with acceptable security best-practices is extremely difficult. As we’ve witnessed over the past two years, many high-profile security breaches have exploited vulnerabilities in third-party applications or the IT supply chain.
3. The ship has already left harbor: The best time to enforce rigorous software security standards is early in the development lifecycle. Unfortunately, most banking applications were developed before stringent security standards were a core element of the original design. Many can’t be taken out of production and re-written to remediate a security flaw -- especially since the timeframe for software remediation can take up to three months in a large organization. Banks running major systems that have known security flaws are hoping that some combination of virtual firewall patching and serendipity will prevent a catastrophic and highly public outcome.
4. The ship is registered in Somalia and has a foreign crew: Most large banks today, even those that favor in-house development over third-party packages, do not maintain all of the custom code in-house in a single, easily managed location. They may use multiple development centers around the world spanning different time zones, languages, and cultures. In fact, a significant proportion of so called in-house development is actually contracted out to software consultancies, independent developers or favored software contractors in countries from India and China to Hungary, Estonia, Ukraine, and Russia. Maintaining effective quality control over software development security practices becomes increasingly difficult as the supply chain is elongated.
5. The ship looks beautiful but has holes in the hull: A further range of risks arises from the application platforms and run-time environments on which banking applications are deployed. No amount of secure development practices will protect against vulnerabilities in the application platform (e.g., Apache Tomcat, WebLogic, JBoss, WebSphere, etc.) or in the runtime environment itself (like Java, which is favored in the banking sector).
6. Captain Phillips is drunk on the bridge: The assumption that having a policy in place that requires developers to follow security best-practices is going to protect banks from coding errors is counter to a basic tenet of human nature. Human beings will not always perform in the most perfect way in all circumstances. Furthermore, the demands of delivering a feature set on time to the business unit that is paying for the software may conflict with the extra care needed to enforce all appropriate security standards.
So while it should remain our goal, even the most secure coding is not enough to prevent Titanic-scale disasters when it comes to application security. In addition to security awareness training for developers and secure coding policies and procedures, financial institutions should consider instituting security controls at the application deployment phase. These include penetration testing and an emerging technology that analyst firm Gartner calls Runtime Application Self-Protection, or RASP. This approach implements security protection (not merely detection) within the execution environment and is particularly useful in guarding against zero-day attacks.
Brian Maccaba is CEO of Waratek. His former company, Cognotec, developed AutoDeal, a pioneering Web-based foreign exchange trading platform that was adopted by more than sixty banksworldwide. London Institutional Investor magazine named him among the top thirty individuals in ... View Full Bio
Tweet This