Is there a silver bullet for security of your software?

The OWASP flagship project “OWASP Testing Guide” (WSTG) is often referred as cookbook of different techniques to find and verify security bugs. It is true in many senses, but for the management staff much more interesting the undeservedly forgotten parts of this guide. Specifically the second chapter (“Introduction”). Here we can find many invaluable advises on setting up the proper security in the software development life cycle. Below the essential ideas from WSTG. 

Count the cost of security efforts and security bugs 

Most people today don’t test software until it has already been created and is in the deployment phase of its life cycle (i.e., code has been created and instantiated into a working web application). This is generally a very ineffective and cost-prohibitive practice. One of the best methods to prevent security bugs from appearing in production applications is to improve the Software Development Life Cycle (SDLC) by including security in each of its phases. Threat modeling and other techniques should be used to help assign appropriate resources to those parts of a system that are most at risk. When a bug is detected early within the SDLC it can be addressed faster and at a lower cost. 

Do not rely only on penetration testing, it is too expensive. 

While black-box penetration test results can be impressive and useful to demonstrate how vulnerabilities are exposed in a production environment, they are not the most effective or efficient way to secure an application. Penetration testing, while useful, cannot effectively address many of the issues that need to be tested. It is simply “too little too late” in the SDLC.  

If the source code for the application is available, it should be given to the security staff to assist them while performing their review. It is possible to discover vulnerabilities within the application source that would be missed during a black-box engagement. Many serious security vulnerabilities cannot be detected with any other form of analysis or testing then source code audit. As the popular saying goes “if you want to know what’s really going on, go straight to the source.” Almost all security experts agree that there is no substitute for actually looking at the code. 

The correct approach is a balanced approach that includes several techniques, from manual reviews to technical testing, to CI/CD integrated testing. 

 Do not rely only on a code level security assurance. 

An effective testing program should have components that test the following: 

• People – to ensure that there is adequate education and awareness; 
• Process – to ensure that there are adequate policies and standards and that people know how to follow these policies; 
• Technology – to ensure that the process has been effective in its implementation. 

Do not rely only on automated tools for security testing. 

One reason that automated tools do a poor job of testing for vulnerabilities is that automated tools do not think creatively. Creative thinking must be done on a case-by-case basis, as most web applications are being developed in a unique way (even when using common frameworks). Creative thinking can help to determine what unexpected data may cause an application to fail in an insecure manner. 

Even the most sophisticated automation tools are not a match for an experienced security tester. Just relying on successful test results from automated tools will give security practitioners a false sense of security. 

Manual inspections is one of the most powerful and effective techniques. 

While the concept of manual inspections and human reviews is simple, they can be among the most powerful and effective techniques available. By asking someone how something works and why it was implemented in a specific way, the tester can quickly determine if any security concerns are likely to be evident. 

Eliminate the root causes of the problem. 

The patch-and-penetrate model involves fixing a reported bug, but without proper investigation of the root cause. It is essential to build security into the Software Development Life Cycle (SDLC) to prevent reoccurring security problems within an application. 

Align security with your existing software development methodology. 

Developers can build security into the SDLC by developing standards, policies, and guidelines that fit and work within the development methodology. A security bug is no different from a functional or performance-based bug in this regard. A key step in making this possible is to educate the development and QA teams about common security issues and the ways to detect and prevent them. One of the first major initiatives in any good security program should be to require accurate documentation of the application. 

To sum-up the main idea of this WSTG chapter: 

In reality there is no silver bullet to the problem of insecure software.