With security reaching mainstream consciousness, it’s time for developers and security experts to come together and fix the problem where it begins: at the application layer.
Unfortunately application security is poorly addressed at many of the world’s largest organizations. They have invested in network and perimeter protection, application security gateways and manual software audits, but these approaches are largely after-the-fact solutions that do not target the root cause of security: flaws in the underlying software.
Most security breeches that lead to identity theft, network outages, data loss or website defacement, have a root cause in a security flaw that was the result of poorly written code. Gartner estimates that approximately 70% of all attacks happen at the application layer, and that it is vastly less expensive for all involved—including the development organization and the customer—to remediate vulnerabilities during development rather than post-deployment.
Beyond the potential for severe brand damage, financial loss and privacy issues, risk-aware customers such as financial institutions and governmental organizations are looking for ways to assess the security posture of the products they build or purchase and they ultimately plan to hold vendors accountable for security problems in their software.
Finding Common Ground
Security and development professionals may live in vastly different worlds but they do agree that the best, long-term answer to security is to work together fixing these common problems.
This is because the traditional software development lifecycle does not deal well with application security concerns. Organizations generally prefer to focus on core functionality features, addressing security in an ad-hoc manner during development. Software developers also lack structured guidance—the few books on the topic are relatively new and they only document collections of best practices.
For instance, secure sockets layer (SSL) is the most popular way to provide data confidentiality and integrity services for data traversing a network. However, most SSL deployments are susceptible to network-based attaches because the technology is widely misunderstood. Particularly, people tend to treat SSL as a drop-in for traditional sockets, but when used that way, critical server authentication steps are skipped.
Performing proper authentication is usually a highly complex process. Organizations that deploy technologies such as SSL and Java are often susceptible to a false sense of security.
Speaking in Tongues
To add to the problem there is also an often unrecognized language gap between developers and traditional security professionals. Organizations do not realize that asking developers to add security to a product already in development is akin to asking an auto manufacturer to install seat belts, airbags and a steel-enforced, roll-over proof cabin into a car after it has hit the assembly line.
Development is a process-driven discipline where steps and roles are extremely well-defined, and upsetting the process can result in product development and shipment delays—an outcome that can make management, sales and even shareholders very unhappy.
Development organizations are driven by time-to-market and new feature pressures, not by the need to write more secure code. Only in the most high-profile cases do security breaches result in some sort of action taken by the development organization to rectify the situation during development.
Organizations have become accustomed to addressing security issues and problems when they appear, which is often well after software deployment. Again, industry research has shown that the cost of deferring security issues from design all the way into deployment is ten times greater than the cost associated with reliability.
The Answer
Clearly throwing more software at security problems is not the answer. The most recent example of this is the emergence of the anti-spyware market.
According to recently published research from the SANS Institute, hackers and virus writers are now aiming at the actual security products that corporations use to protect themselves. This research is further proof that current solutions are not working and it is time to address the root cause of the security epidemic.
To reach a solution to the growing problem of insecure software code, developers and security professionals need to open the lines of communication. Security has become a core requirement in today’s software and a top concern for organizations and business around the world. By working together and communicating security professionals and development professional can fix the current security crisis.
John Viega is CTO of Secure Software and responsible for the company’s core processes and algorithms for security analysis. He has co-authored four books including “Building Secure Software” (Addison Wesley, 2001), and the just-published “19 Deadly Sins of Software Security” (McGraw-Hill, 2005).