Don’t let development pressures cut security testing short.
There are more than 5,000 known security vulnerabilities and the number is growing. In 2008, there were 11.5% more internet security vulnerabilities disclosed than in 2007. That’s because we’re getting better at identifying and eliminating vulnerabilities. But all the progress made can be thrown out the window, if you’re in a hurry to roll out the latest and greatest software upgrade.
There are a lot of reasons for time schedules to be cut short. Let’s say something is added or changed in the development process which results in the need for more development time. To catch up, the temptation is to shorten the time scheduled for testing. Studies of security breaches that have made recent headlines reveal that inadequate testing procedures were largely to blame for most of the breaches.
This scenario is common in the financial services industry. When institutions do roll-outs, they often don’t allow sufficient time for security testing. Or if they do, the developers take too long, often shortening the time needed to perform sufficient security testing.
Solving security problems is more of a cultural and management issue than a technical one. People at the top of an organization need to realize that security testing is imperative. Pushing for a change to be squeezed in as soon as possible will affect the testing schedule and you’ll need to allow for extra time.
Everyone in the organization, from the board room down to the marketing department, must understand that proper security testing is more important than meeting a project deadline.
Treating security this way makes sound financial sense. Tangible losses from attacks, for example, can affect productivity, revenue, direct costs and customer trust. Even if no customers lose money in a security breach, a customer complaint alleging that your institution has breached the Data Protection Act by failing to adequately secure financial data can cause big problems.
The moral of the story? Don’t cut security testing short just to meet deadlines. Fixing a problem once software has gone live is much more expensive than dealing with the problem at the design stage.
Got an opinion? Please help continue our conversations by commenting on this post.