Imagine that when shopping for your dream car, you walk into the showroom and you are greeted by an immaculately dressed sales person, who after exchanging introductions and finding out your requirements, gives you a tour of all the cars and their features, goes over the pricing and then tells you the cars don't come with seat belts as a standard offering – but it can be included for an additional price.
In this day and age, in most developed countries and some emerging marketscapes, this would be unacceptable from the vantage point of safety. Why is it different then when it comes to software – developed in-house or purchased commercially off-the-shelf (COTS) – and security features that need to be built-in as a standard and not bolted on when needed?
We all have heard of vulnerabilities and exploits in software. Full-disclosure lists are rife with evidence of insecure COTS software. The chronology of data breaches maintained by Privacy Rights Clearinghouse substantiates that software developed internally is equally insecure.
Software insecurity could be attributed to various factors. The cost of incorporating security within resource and time constraints, increased project life cycles, delay in time to market, developer mindset and inadequate security training and education are some reasons why software is inherently insecure.
However, a rise in the incidence of software security issues, globalization and increased regulatory and compliance requirements mandate that software be secure. Requirement 6 of the Payment Card Data Security Standard (PCI DSS) that deals with developing…
Please log in or subscribe to read this article