Initial organization stub
[ssproject1617.git] / report / organization.tex
1 %
2 % (TODO write out: dsprenkels)
3 %
4 % This document describes our security analysis of the (?) CMS according to the OWASP ASVS (v3.0.1), as well as an analysis of Fortify's results compared to our findings \& the OWASP ASVS categories.
5 %
6 % Outline: first our analysis, then a summary of Fortify's analysis and how it compares to ours etc., then some reflection.
7
8 % E.g. did you split the work by files in the code, or by category of security requirements? Did you double-check important findings? Or did you use several pairs of eyeballs on the same code/ security requirement, in the hope that more eyeballs spot more problems? (How) did you integrate using the static code analysis tools into this process? Did you use other tools and methods?
9 % Have you tried to run the application? (If so, was this useful, and did you find than running the application was helpful to then review the code, understanding its functionality better? But you might want to dicuss this in the Reflection section.)
10
11 \section{Organization}
12
13 Each of us has initially set up the CMS and made ourselves familiar with the
14 CMS. We have chosen to split the work by category of security requirements in
15 the OWASP Application Security Verification Standard. We set the goal to perform
16 a sound level 2 audit on the software.
17
18 % Initial approach
19 We were quickly set up and started to do each own parts of the audit by hand.
20 For each OWASP ASVS item specific to certain mechanisms (like login and input
21 validation), we would take the source code of the CMS and follow the control
22 flow to see if the application satisfies the security requirement. For more
23 general requirements, we could just look at the code that is responsible for
24 this requirement (like the \code{Response} class in the case of HTTP security).
25 When we had found that a requirement was not satisfied, we elaborate shortly
26 and move on.
27
28 This went well, because with five people the individual workload is just not
29 that big. Furthermore, finding vulnerabilities is a lot easier that verifying the security in a lot of cases. This speeds up the auditing process, because
30 the CMS turned out to not satisfy the ASVS in most cases.
31
32 % TODO(dsprenkels) Use of Fortify
33 % TODO(dsprenkels) Running the application
34 % TODO(dsprenkels) Double-checking process (see V2.2 as example)