Every software development project must keep security in mind, and it must fit like any other task and, in some cases where privacy is a key factor (and FastFix is a good example), it must be present to a larger extent.
The security guidelines to be followed in this project are based on the need to ensure that security is included in the Software Development Life Cycle (SDLC), since it is proven that trying to fix security code issues in later steps of the development life cycle, will produce higher cost that in earlier levels.
The main ideas of FastFix security guidelines should be provided by the spirit of the Open Web Application Security Project (OWASP1) Application Security Verification Standard (ASVS2). OWASP is an open-source community project that includes corpora-tions, educational organizacorpora-tions, and individuals from around the world. This community works to create freely-available articles, methodologies, documentation, tools, and tech-nologies. ASVS is an international standard, although created as a way to normalize
1http://www.owasp.org
2http://www.owasp.org/index.php/OWASP_Application_Security_Verification_Standard_ASVS
the range in the coverage when it comes to perform web application security assessments.
Most of its concepts can be exploited to define security guidelines in development projects even if they are not web applications.
Figure 4.5: OWASP Application Security Verification Standard [13].
The procedure is similar to the one presented in Figure 4.5, with the purpose of in-cluding security support within the SDLC. First, as described in [1], we have defined the security requirements in the scope of the project. Next, in the design phase, these security requirements will be closerly watched to ensure that all design decisions taken in the project are fullfilling the mentioned requirements. All the risks and threats will also be identified. Once the implementation starts, security audits will be performed to discover vulnerabilities using black box testing or ethical hacking. The running system will be tested remotely, without using knowledge of the inner workings of the application itself, to find security vulnerabilities. Security testing will be done following the recom-mendations of a recognized open standard as the OSSTMM. The test will be done using automated penetration methods and tools as well as manual audits.
Best practices and possible errors in code will be assured mainly with the static code analysis, but regarding security, the source code must be reviewed to verify that the proper security controls are present and that they work as intended. Code review is the most effective technique for identifying security flaws. As explained in the OWASP Code
Review Guide, security code review is a method of assuring secure application developers are following secure development techniques. Tools can be used to perform this task but they always need human verification, since tools do not understand context, although they are good at assessing large amounts of code and pointing out possible issues, which must be verified to determine if each of them is a real issue.
While manual code reviews can find security flaws in code, they suffer from two prob-lems. Manual code reviews are slow, covering 100-200 lines per hour on average. Also, there are hundreds of security flaws to look for in code. Source code analysis tools can search a program for hundreds of different security flaws at once, at a rate far greater than any human can review code. However, these tools don’t eliminate the need for a human reviewer, as they produce both false positive and false negative results. As part of this task, automated source code static analysis will be done for each of the developed modules before each integration.
In order to organize the security code review guidelines, we will focus on the most critical security flaws that can be found during a code review:
1. Input validation: It must include protection against cross site scripting, SQL-XPATH-LDAP injection, cross site request forgery, buffer overflow and format bug.
2. Source code design: The first stage where security must be taken into account is source code design. In this category, we must survey security check families like:
redundant code, insecure method scope and unused external references.
3. Information leakage and improper error handling: It contains security check families regarding how source code is managing errors, exceptions, logging and sensitive in-formation. Examples of these checks are: Unhandled exceptions or insecure logging.
4. Direct object reference: This category refers to the attacker’s capability to inter-act with application internals, like direct reference to database data, filesystem or memory.
5. Resource usage: It is related to all the unsafe ways a source code can request operating system managed resources. Most of them are prone to result in some kind of DoS (Denial of Service), like memory leak, unsafe process creation or insecure file deletion or modifying.
6. API usage: It refers to APIs provided by the system or the framework in use that can be used in a malicious way. Hence, we will watch for insecure database calls, HTTP session handling or strings manipulation.
7. Best practices violation: This category gathers together all security violations that don’t fit in previous categories. Most of them contain warning source code best
practices, like unsafe variable initialization or missing comments and source code documentation.
8. Weak Session Management: Some examples are: not invalidating session upon an error occurring, not checking for valid sessions upon HTTP request or not issuing a new session upon successful authentication.
9. Using HTTP GET query strings: Passing sensitive information using a query string and HTTP GET, since no protection can be provided agains it, not even SSL.
Bibliography
[1] Roberto Amado, David Monteagudo, Fernando Seco García de Ceca, Sergio Zamar-ripa López, Emitzá Guzmán, João Coelho García, and María del Carmen Calle. D7.1:
Global performance, security and privacy requirements, 2010.
[2] Douglas K. Barry. Web services and service-oriented architecture: the savvy man-ager’s guide. Morgan Kaufmann, 2003.
[3] Bernd Bruegge and Allen H. Dutoit. Object-Oriented Software Engineering Using UML, Patterns and Java. Prentice Hall, 3rd editio edition, 2010.
[4] Paul Duvall, Steve Matyas, and Andrew Glover. Continuous integration: improving software quality and reducing risk. Addison-Wesley Professional, June 2007.
[5] Edgewall Software. The Trac Ticket Workflow System, 2011. Available from: http:
//trac.edgewall.org/wiki/TracWorkflow.
[6] Martin Fowler. Continuous integration, 2006. Available from: http://
martinfowler.com/articles/continuousIntegration.html.
[7] Erich Gamma, Richard Helm, John Vlissides, and Ralph E Johnson. Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, Massachusetts, 2000.
[8] João Garcia, Paolo Romano, Alessandra Bagnato, Javier Cano, Walid Maalej, Dennis Pagano, Sergio Zamarripa, Emitzá Guzmán, and Benoit Gaudin. D8.1: Trial and Validation Plan, 2011.
[9] David Hovemeyer and William Pugh. Finding bugs is easy. ACM SIGPLAN Notices, 39(12):92–106, 2004.
[10] Steve McConnell. Code Complete: A Practical Handbook of Software Construction.
Microsoft Press, Redmond, WA, 2nd edition, 2004.
[11] Stephen John Metsker and William C. Wake. Design patterns in Java. Addison-Wesley Professional, 2006.
[12] Sun Microsystems. Java Code Conventions, 1997. Available from: http://www.
oracle.com/technetwork/java/codeconventions-150003.pdf.
[13] Open Web Application Security Project. OWASP-ASVS Approach, 2011. Available from: http://code.google.com/p/owasp-asvs/wiki/Approach.
[14] Dennis Pagano, Tobias Röhm, Walid Maalej, and Emitzá Guzmán. D2.3: User Requirements and Conceptual Architecture, 2011.
[15] Stephen R. Schach. Object-oriented and classical software engineering. McGraw-Hill New York NY, 2002.