Tech Insight: 5 Myths Of Software Security

[Jason Sachowski is a security professional at ScotiaBank. His content is contributed through the auspices of the (ISC)2 Executive Writers Bureau.]

Today's businesses rely heavily on software -- and increasingly, so do individuals. Yet with so much riding on our applications, we continue to see new vulnerabilities crop up every day -- and major data breaches as a result.

Why isn't software more secure? Some of the problem has to do with the development process, and some of it has to do with the need to better integrate software security with business needs. Let's look at some of the myths that continue to surround the software development process -- and how these myths contribute to the continuing vulnerability problem.

Myth #1: Software Security Is An Information Security Problem
It's a common misperception that anything related to security should be the responsibility of the IT security department. In fact, security best practices should be instilled as subfunctions of the overall business. In its 2009 article, Security Is Not Just a Technical Issue, the U.S. Department of Homeland Security said it best: Senior management must set the direction for how enterprisewide security practices are perceived, prioritized, managed, and implemented.

The Microsoft Application Architecture Guidemakes another important point: Security must be viewed as just another attribute of software, much like usability, performance, reliability, and scalability. Security controls should be a critical element in the software development life cycle (SDLC), from the definition of requirements to the retirement of the application.

Myth #2: Developers Are Solely Responsible For Application Security
When vulnerabilities are found in software, developers are usually on the front line of the finger pointing. Yet while developers are the primary creators that make software work, a secure SDLC process requires involvement from many other stakeholders, including analysts, architects, testers, auditors, and management.

With full participation of multiple stakeholders in a secure SDLC process, potential flaws can be identified both before deployment and during implementation, reducing the attack surface and strengthening defense-in-depth strategies. A "team approach" to secure software development will improve the software release, change, and configuration management processes, improving software deployment standards.

Myth #3: No Problem, The Code Was Scanned
Programmatic source code scanners provide a reasonable level of assurance that software was created without structural issues, but this is only one side of the coin. Humans are prone to error; there is no way of mitigating this. There will always be logical source code errors -- such as data validation or race-conditions -- that programmatic scanners may not detect.

Even if scanners could pick up logical source code errors, we still rely on humans to update new vectors as the threat landscape evolves. Again, having extra sets of eyes reviewing source code -- including analysts, testers, and auditors -- can help reduce the attack surface for each new application.

Myth #4: Security Is Software-Centric
The software development, deployment, and usage chain is only as strong as its weakest link. Developing and implementing secure software means taking a holistic view of how software will be implemented, including business use, architectural considerations, and logical access controls.

A commonly overlooked aspect of security -- and this is not software-specific -- is the relationship between physical and logical security. No matter how much effort is placed on implementing a repeatable secure SDLC process, a physical security failure can spell disaster. Encryption is the best possible solution to physical vulnerabilities.

Myth #5: Educate Once, Implement Many
All of the stakeholders involved in the secure SDLC process hold some degree of experience, but they may not all have the training they need to spot potential security problems in a developing applications. Even if those stakeholders are not IT security professionals, education and training in the field of software security are essential to the secure SDLC process.

A good approach to achieving current and relevant knowledge of the secure SDLC process is to explore industry-recognized professional certification programs. Through certifications, stakeholders are required to complete a minimal level of recognized training and education that helps ensure they are current on key aspects of secure software development.

It's important to remember that a secure SDLC process does not guarantee that software will be implemented free from vulnerabilities; all software is susceptible to attack in today's rapidly evolving threat landscape. The secure SDLC process is a holistic methodology that emphasizes "security by design;" in other words, it's not about developing perfect software, but about controlling the risks associated with software.

Software security -- and the secure SDLC process -- is essential to business. But it's important to remember that it is a process and requires a team effort. If all of the stakeholders participate, there's a much better chance of avoiding vulnerabilities -- and subsequent breaches.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.