Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

A Case Study - Selecting an Application Security Assurance Approach

December 2008 by Ulf Mattsson, CTO, Protegrity Corporation

This case study from company ABC will briefly discuss ways to develop and maintain secure systems and applications, including selecting suitable static-analysis code scanning tools for application development. ABC is implementing web application firewalls to protect web based applications and acknowledges that secure development will take a long time to implement partly based on expensive and time-consuming manual code reviews. ABC is selecting a solution based on code reviews and scanning of internal code for non-web applications. ABC also identified a long term project that will include penetration testing, scanning and review of the web application code base.

An effective code-scanning tool would definitely be useful in ABC development. Being a security oriented organization, it’s very important to minimize the number of bugs. The use of code scanning tools is also mandated by Microsoft’s SDL (Secure Development Lifecycle) that ABC is adopting. No matter what tool used, this should be accompanied with code reviews, appropriate testing including such as fuzzy testing, code standards that are followed, and proper education.

Apply coding and testing standards
SDL describes requirements for different phases in development, with the main goal to reduce the number of vulnerabilities in software products. It has been proposed that ABC should follow SDL rules by the end of 2009.The ABC coding standards will help developers to avoid introducing flaws that can lead to security vulnerabilities. The testing standards and best practices will help to ensure that testing focuses on detecting potential security vulnerabilities rather than concentrating only on correct operation of software functions and features. ABC are also introducing "Fuzzing" that will supply structured but invalid inputs to software application programming interfaces (APIs) and network interfaces so as to maximize the likelihood of detecting errors that may lead to software vulnerabilities.

Apply static-analysis code scanning tools and code reviews

Tools can detect some kinds of coding flaws that result in vulnerabilities, including buffer overruns, integer overruns, and uninitialized variables. Microsoft has made a major investment in the development of such tools (the two that have been in longest use are known as PREfix and PREfast) and continually enhances those tools as new kinds of coding flaws and software vulnerabilities are discovered. Code reviews supplement automated tools and tests by applying the efforts of trained developers to examine source code and detect and remove potential security vulnerabilities. They are crucial steps in the process of removing security vulnerabilities from software during the development process.

Separated code reviews will enhance security

Both PCI DSS (Payment Card Industry Data Security Standard) and SDL mention separate code reviews as a way to enhance security. In addition SDL mentions the use of static-analysis code scanning tools. Such tools often assists during code reviews, but may also be applied during normal development.

Static vs. dynamic analysis

There are two principal types of program analysis. Static, or compile-time, analysis is aimed to investigate a program’s run-time properties without actually executing it. Normally this is performed by source code inspection, but binaries may also be used. Dynamic, or run-time, analysis is performed when observing the program at execution. Testing, debugging and performance monitoring are examples of dynamic analysis. An example of a very simple static analysis would be searching for specific words like strcpy using a file-search utility like grep. The goal would be to identify where unsafe functions are used.

A search for strcpy will however also list values like strcpy_s. If strcpy is part of a comment, this will also be presented as a valid occurrence. Such output is called a false positive, i e something reported as a vulnerability though not. False positives are a big issue in static analysis since they give the user more data to evaluate than necessary. Each program construction reported as vulnerability must be considered and reviewed. Suppose strcpy is renamed to something else, for instance with a macro like ‘#define mycopy strcpy’. In this case a word search for strcpy won’t list any occurrence of mycopy, though strcpy really is used. This is called a false negative, i e a real vulnerability that hasn’t been presented.

Analysis tools

An ideal analysis tool would have no false negatives and no false positives, only true vulnerabilities would be presented. That is however not realistic. Instead they are often somewhat related; a lower false positive rate means a higher false negative rate, and vice versa. There are different free open source static-analysis tools, as described further below. These are only marginally better than the simple word-search as above. They search for specific unsafe calls like strcpy as listed in an internal database, and when found they present the position and a general comment about the problem. This handling gives a lot of false positives, but also a lot of false negatives since they only look for some calls. Such simple tools are of limited value.

More advanced tools

More advanced tools try to interpret the context of the word, based on the programming language used. This is called semantic analysis. The better this analysis is, the fewer false positives there will be. The free open source tools do perform some semantic analysis, meaning at least some false positives will be skipped.
In addition to look for certain language-specific words, advanced tools also look at the general program context. An intra-procedural analysis only looks at what happens within a specific function. This may be inaccurate, for instance when external entities like globals are used. An inter-procedural analysis tries to consider all parameters of the function, and the interaction of functions. This is much more complicated than intra-procedural analysis, considering different possible parameter values and paths for execution. Related to this is flow-sensitive and path-sensitive analysis, which tries to consider the program flow and the different paths possible. Even if supported by the tool, inter-procedural analysis may in some cases not be possible. If there are third-party libraries for which source code isn’t available, or there are yet unimplemented functions, the tools can’t inspect what happens inside these calls. This may result in false negatives produced.

Tools often try to simplify analysis

Tools often try to simplify analysis, to get better performance. Doing such as inter-procedural and flow-sensitive analysis could consume considerable resources. A tool may for instance only consider min/max values when handling integer input. Such simplifications are also a source of false negatives. In general, a tool will never be totally accurate, but the better it performs different types of advanced analysis, the more vulnerabilities it will find.

Conclusion

An effective code-scanning tool would definitely be useful in ABC development. Being a security oriented organization, it’s very important to minimize the number of bugs. The use of code scanning tools is also mandated by Microsoft’s SDL. No matter what tool used, this should be accompanied with code reviews, appropriate testing including such as fuzzy testing, code standards that are followed, and proper education. No matter what tool configuration selected, manual code reviews, education, coding standards and proper testing must also be applied. This case study from company ABC will analyze and identify an approach to develop and maintain secure systems and applications, including selecting suitable static-analysis code scanning tools for application development. ABC is planning an enterprise data protection approach and protects data across the information life cycle. ABC acknowledges that secure development will take a long time to implement, partly based on expensive and time-consuming manual code reviews. ABC is selecting a solution based on code reviews and scanning of internal code for non-web applications. ABC also identified a long term project that will include penetration testing and scanning and review of the web application code base. Please review http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1264694 for more information about how to secure the enterprise application environment.


See previous articles

    

See next articles


Your podcast Here

New, you can have your Podcast here. Contact us for more information ask:
Marc Brami
Phone: +33 1 40 92 05 55
Mail: ipsimp@free.fr

All new podcasts