Security At The Beginning
Why should we secure software at the start of the cycle rather than the end of it? Because it costs a lot more!
Data presented by Fortify in 2008 indicate that the cost of correcting security flaws at the requirements level is up to 100 times less than the cost of correcting security flaws in fielded software.
AppSec vs Software Security
What is the difference between AppSec and Software Security? One is after the fact and one is before. I would personally invest more resources before than after.
On one hand, software security is about building secure software: designing software to be secure; making sure that software is secure; and educating software developers, architects, and users about how to build security in. On the other hand, application security is about protecting software and the systems that software runs in a post facto, only after development is complete.
Limitations of Static Analysis.
Static analysis tools cannot evaluate design and architectural flaws. They cannot identify poorly designed cryptographic libraries or improperly selected algorithms, and they cannot point out design problems that might cause confusion between authentication and authorization. They also cannot identify passwords or magic numbers embedded in code.
Why we should all have a Security University that provides training and accreditation to our employees. I have written up a base level training program for security personnel here. I call it Hacking University.
Training is another critical element of the SDL that requires the human element. Training helps to reduce the cost of security, and an effective training program will motivate your development team to produce more secure software with fewer problems with more efficiency and cost effectiveness.
Quality vs. Security
You can still have code which isn’t high quality but does have security.
As we will explain in this book, secure code does not necessarily mean
quality code, and quality code does not necessarily mean secure code, but
the foundation of software applications and the development processes
that produce them should be based on common best practices of both
quality code and secure code.
Good Business Sense
Security actually will save you money in long run. Nobody is going to use your application if the flaws are highly publicized. There is a business pragmatism to securing code.
In the end, software security is as much about a good business process as it is about quality.
Threat modeling and attack surface validation are perhaps the most timeconsuming, misunderstood, and difficult parts of the SDL. They require
the attention of the most seasoned and experienced person of the software security team: the software security architect. The idea behind threat
modeling is simply to understand the potential security threats to the system, determine risk, and establish appropriate mitigations (What? How
bad is it? How can it be fixed?).
Test The Attack Surface
You need to test at minimum the attack surface.
Given the normal constraints of time and resources, it is not possible
to test all code in an application However, at a minimum, testing should
cover the entry points and exit points of an application that may be accessible to an attacker, commonly referred to as the application’s attack surface.