Portfolio Expert
A New Security Mindset
Security moves to the forefront in application development.
Every year, enterprises spend tens of billions of dollars on software, hardware and services to protect their IT systems and data from all types of attacks. Until recently, however, those efforts were focused on perimeter defense, establishing a wall around networks and servers to keep the "bad guys" out. While necessary, these defenses are no longer sufficient. Attackers have discovered an easier way in-attacking the application layer.
The core focus for software vendors, best practice niche players and Global 2000 corporations should be to emphasize security up front, as part of the application development process. Vendors are stepping up. Fortify Software Inc., Compuware Corp. and Ounce Labs Inc. have all announced products or initiatives, while process/training vendor Security Innovation Inc. continues to ply content and methodology approaches.
Ultimately, the application development team is accountable for vulnerabilities. The root cause of application security vulnerabilities lies in the application source code. This is a new problem domain for application development groups, and they need tools, best practices and education to resolve it.
Part of the problem is mindset. Under tight delivery schedules, application development teams are understandably reluctant to add another set of processes to an already long application development lifecycle.
Also an issue is the slow realization among developers that deliberate attacks might come from unforeseen directions. QA teams suffer from this as well-their test tools and procedures traditionally focus on finding performance and functionality defects.
One thing app dev teams are not strangers to is fixing bugs-many teams spend half their time bug hunting.
To a certain extent, security vulnerabilities can be considered a special class of defect that might be well addressed in the new QA regime. But that oversimplifies the challenge. Vulnerabilities arise from design flaws, not just from bugs. Hackers will develop increasingly sophisticated techniques to exploit those flaws and break code. Application development teams need to design and code in a secure way to reduce the risk of a successful attack.
Application software security risk is still somewhat of a new concept for application development teams. Security as a domain also has its own colorful language and best practices, and these too are foreign to the average application developer and quality assurance analyst. This creates a gulf between the application development group and the security audit team, one that parties from each side are only now beginning to cross.
It's the Tools, Stupid
Application development teams need strong tools to assess code quality from a security perspective, and to identify and remediate vulnerabilities. The tools must integrate seamlessly with other lifecycle tools, including the developer's IDE and the QA analyst's test management system. Finally, security must be incorporated into all phases of the application development process, from design and code creation to testing and verification. Security can't be bolted on at the end.
Consider the capabilities that an automated software security solution must provide: comprehensive, accurate coverage; multi-tier analysis; extensible architecture; multilanguage support; static and dynamic checking; and management visibility.
To improve application security, enterprises should evaluate automated tools from emerging software security vendors. IDC believes the core technology underlying these automated tools is now mature enough to help organizations dramatically improve the security of the software they create, without adversely impacting development team resources or schedules.
To be sure, large enterprises must contend with issues related to deploying solutions from small, venture-backed start-ups. But enterprises have shown they will adopt innovative technology from emerging firms when the value proposition is strong. In the case of software security, not acting could be catastrophic, and the alternative (manual code inspection) is cost prohibitive.
Management must define acceptable and unacceptable levels of risk and engage the security audit and application development teams to establish policy and ensure enforcement. Parameters that influence risk include the sensitivity of the information that could be lost or stolen; the costs of system unavailability or downtime; damage to customer trust and loyalty, brand and, potentially, market share; and regulatory noncompliance risk.
Important questions include: What is our policy for managing software security risk? How do we enforce it? How do we assess software security risk today? How sure are we of our assessment? Where are we weakest and most exposed? Automated software security tools help answer these questions.
There's a lot at stake. With new tools emerging, now is a good time to bake software security into your risk-management best practices.
About the Author
Melinda-Carol Ballou is program director for IDC's Application Life-Cycle Management research, where she focuses on software life-cycle process configuration and management, software quality and IT governance software. Prior to joining IDC, she ran Ballou IT Strategies, an independent consulting company specializing in PPM and ALM, and served as senior program director at META Group.