ISACA Journal Author Blog

ISACA > Journal > Practically Speaking Blog > Posts > Addressing Information Security at Its Root: Insecure Software

Addressing Information Security at Its Root:  Insecure Software

| Published: 12/10/2012 8:30 AM | Permalink | Email this Post | Comments (0)
Rohit Sethi, CISSP, CSSLP, and Ehsan Foroughi, CISM, CISSP

Rohit Sethi
Ehsan Foroughi

Insecure software continues to be the dominant root cause for the hacking incidents cataloged in the Verizon Data Breach Investigations Report. Unfortunately, most organizations tend to emphasize detective and corrective controls with respect to application security rather than preventive controls. A 2012 report from Quocirca found that nearly all organizations use static/dynamic vulnerability scanning or web application firewalls as their primary approach to application security.

These results mirror our empirical data:  Organizations rarely emphasize preventive controls. Our own research shows two main factors for this:
1. Lack of scalable approaches to preventive application security
2. Lack of emphasis on preventive controls from audits

Until recently, organizations had to rely on some combination of education and manual, expensive techniques such as threat modeling to holistically integrate security into software requirements and design. The emergence of commercial off-the-shelf (COTS) and in-house developed secure application life cycle management (SALM) tools is helping close this gap.

SALM tools are decision-tree systems that provide a tailored set of security requirements from a large knowledgebase through user-supplied criteria. Think of them like tax planning for application security:  Users provide details about the technology stack, compliance requirements and features of their software, and get back a tailored set of requirements and verification tasks to ensure that their software is secure. SALM tools provide the scalability organizations need to effectively integrate preventive application security controls.

The second factor is still largely missing. Despite being specified in audit frameworks, such as the Payment Card Industry Data Security Standard Section 6.5, auditors rarely request evidence of secure software development practices, apart from superficial knowledge of the OWASP Top 10. The information security budget and goals tend to be heavily focused on compliance and audit findings, rather than security best practices. As a result, development teams focus on audit findings—namely detective and corrective controls—while still producing insecure software. This approach is cost-inefficient; according to IDC, fixing a security defect in static analysis is 6.5-times more expensive than fixing it in design. Moreover, studies show that static analysis can only detect up to 40% of preventable defects, which leads to greater risk.

Organizations have the potential to substantially improve software security. Now they need the support of the controls audit community to make it happen.

Read Rohit Sethi and Ehsan Foroughi’s recent Journal article:
Preventive Technical Controls for Application Security,” ISACA Journal, volume 6, 2012


There are no comments yet for this post.