CNET también está disponible en español.

Ir a español

Don't show this again


Mind the gap, please

Security and application developers speak different languages, says Secure Software's Kevin Kernan--and the result is often chaos.

    Most people would agree that the best long-term answer to the security problem is to make software intrinsically more secure.

    Nearly every security breach that leads to identity theft, network outages, data loss or Web site defacement has a root cause in a security flaw that was the result of poorly written software code.

    Research firm Gartner estimates that approximately 70 percent of all attacks happen at the application layer and that it is vastly less expensive for all concerned to fix the vulnerabilities during development rather than after deployment.

    Hackers are increasingly targeting antivirus applications.

    So if there's broad agreement about the solution to the industry's long-term security woes, what's holding back progress? Simply put, a major language gap exists between security and application development.

    For the most part, this is an under-the-radar problem. Most organizations don't see the language gap between developers and traditional security professionals. They don't realize that asking developers to add security to a product already in development is akin to asking an auto manufacturer to add seat belts, airbags and a steel-enforced, rollover-proof cabin into a car after it has hit the assembly line. It ignores the fact that software development is a process and that the only way to affect the quality of the end product is through changes in process.

    Security professionals want to help developers write better code, but the only way they know how is by throwing more software at the problem. The SANS Institute published research demonstrating that hackers and virus writers are now aiming at the products corporations use in their defenses. In fact, now that operating system developers like Microsoft seem to have figured out how to better shield their products, hackers are increasingly targeting antivirus applications.

    So, to be clear: The hackers are now attacking the software that protected our software.

    Does that mean we are supposed to add yet another layer? Are we going to deploy new software to protect the software that was protecting our software?

    Confused? You're not alone.

    Development professionals live in a world vastly different than security professionals. 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 professionals live in a world vastly different than security professionals.

    Development organizations are driven by the need for quick time-to-market and the pressure for new features, 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. Most developers don't understand the first step of secure coding and testing: that by putting two properly written lines of code together, you can actually introduce new vulnerabilities.

    The software industry needs an agreed-upon lingua franca for collaboration between development and security. The industry needs to develop a standard for integrating security processes, roles and artifacts into the existing life cycle with minimal pain and impact on time to market. Even if the approach is modular and takes time to implement, a standard will still mark an all-important first step to improving software security.

    Such a standard is a must, if we are going to truly change the way that software is developed and affect the security quality of the end product.