Software security lessons from the professionals
Finding issues in code before anytime runtime tests is a simple value proposition. This is because static analyis tools have been around for some time - Lint, RATS, ITS4 and so on. Today, many proprietary static tools exist. Some focus on quality issues (i.e., memory leaks) while others focus on finding security vulnerabilities. But using static tools for security is not simply a matter of deploying them, finding problems and making a fix. Reality is a good bit more complicated. If it were that easy, then any software vendor or e-tailer would use static and other security tools to guarantee no vulnerabilities.
Today, our customer base includes ten of the largest banks worldwide. Some of these banks actually highlight the security of their online systems as a differentiator to attract more customers, while others even go as far as to guarantee a full refund on all funds removed from customer accounts by unauthorised parties. How did these organisations get to a state where they can make such expensive assurances when they collectively transact trillions of dollars?
The simple answer – it was a very long evolution. Studying this evolution can serve as a model for future software development teams in organisations across any industry – insurance, transportation, embedded, you name it. By exploring the stages that these banks have gone through, organisations can learn lessons on how proper policy can improve the effectiveness of testing cycles and fix potential security flaws faster - ensuring completely secure software.
The Evolution of Secure Software
Stage 1 - 100 % Reactionary
In this stage, the banks had a strong Systems Development Lifecycle (SDLC) designed to meet functional specifications. The problem was that developers were giving no consideration to secure coding – instead taking the view that this was the job of security professionals. Developers, as Gartner explains, “…mistakenly believe that application security is a responsibility of security professionals. They assume that their only responsibility is to deliver functionality requested by their business clients. They analyze, design, program and test applications to ensure that applications are compliant with clients’ functional requirements. They are not testing applications for conditions that could break or abuse applications.” (Gartner research, 16 November 2006, Application Developers Should Assume Responsibility, for Application Security, by Joseph Feiman.)
However, security teams within these banks lived in a constant state of fear knowing that a successful hack was inevitable. And when it happened, impromptu patch management teams sprang into action. From a security standpoint, this represented a simple four-step process: code, deploy, get hacked and fix what was broken. But this was also the most expensive security strategy since vulnerabilities were put into production code on a regular basis. As a result, people’s pagers were continually going off and security teams were constantly working to fix vulnerabilities on a reactionary basis, impacting negatively on overall morale.
Stage 2 - Robohacking
Recognising there was a problem, the next logical step for many banks was to beat hackers at their own game and put in mitigating solutions. Many chose to conduct some sort of penetration (black box) testing on production code in the hope of finding vulnerabilities before the hackers do, or simply hire ethical hackers to do the same.
However, while such techniques proved necessary and valuable, they didn’t offer a clear indication of risk exposure. Banks soon realised that while black box testing did add value, it wasn’t enough. While black box testing was - and still is - an important component of security testing, banks have begun to ask themselves:
- Where exactly is the application broken?
- How much code coverage am I actually getting?
- How many areas are truly at risk?
- Is the application fundamentally more secure?
- Are we curing the illness or just treating the symptoms?
The answer became apparent when their security teams were still putting out fires on a regular basis and it was clear that nothing much had changed.
Stage 3 - Code reviews
To truly understand risk exposure required a more detailed understanding of the software, and banks slowly began to incorporate security source code reviews. These were helpful on a number of fronts:
First, the “shock and awe” of showing developers exactly how hackers exploited the code that they wrote very much helped to evangelise the “security starts with development” message. Second, manual code reviews identified many issues early in the cycle, preventing issues downstream. Third, security teams were empowered into what is called a “gate model”, meaning if the security team felt the application wasn’t secure enough to go live, it didn’t. Developers, forced to comply, made the necessary security fixes to meet production requirements.
However, this approach was expensive, as application size, and complexity, continued to grow at exponential rates and made thorough analyses impossible. Security was still putting out fires, although pagers weren’t going off as often.
Stage 4 - Use a static analyser
Many of today’s static analysers are precise and scalable. However, this must be coupled with an appropriate policy to support it. Otherwise, a static analysis tool can catch security holes early, but if developers continue making them, then this becomes an expensive strategy.
Stage 5 - Building security in with the security-conscious developer
Finally, the banks realised that smart developers produce fewer bugs and therefore education was needed. Today, many banks have introduced training focused on developing software securely.
Static tools, deployed at the desktop for unit tests and centrally for system tests, reinforced what developers learned. Not surprisingly, given the high profile and high-risk exposure of the software that they were coding, developers within the banks embraced the knowledge and rarely produced the same errors.
Although hackers always look for new ways to break into code, many security teams within banks today report a vast reduction in “S1” vulnerabilities. More importantly, their pagers are almost always silent.
Conclusion
Automated discovery and vulnerability analysis technology enables businesses to do more intelligent code audits and do them more frequently throughout the software development cycle. However, just as poor financial processes can’t be fixed through auditing alone, security-deficient software development processes can’t be fixed through code auditing alone.
Businesses need to learn the lessons of the banks described, and fix the software development process for their critical applications, just as they would fix any other faulty business process that jeopardises their budgets, brands and bottom lines.
In addition to using automated discovery and vulnerability analysis technology, businesses need to weave security expertise – “security DNA” – into their software acquisition, development and deployment activities.