A lot of minor (mostly textual) changes

[ssproject1617.git] / report / organization.tex

diff --git a/report/organization.tex b/report/organization.tex
index 13aca57..51d3f36 100644 (file)
--- a/report/organization.tex
+++ b/report/organization.tex
@@ -1,5 +1,5 @@
 %
-% (TODO write out: dsprenkels)
+% Written by dsprenkels
 %
 % 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.
 %
@@ -10,14 +10,14 @@
 
 
 % Running the application
-Each of us has initially set up the CMS and made ourselves familiar with the
-CMS. This was easy, because one of us had made a \code{Dockerfile} for the
+Each of us has initially set up the \CMS{} and made ourselves familiar with the
+\CMS{}. This was easy, because one of us had made a \code{Dockerfile} for the
 others to use. This made running and installing the application trivially
 easy. Running the application made us understand the outline and components of
 the application. We could also find some spots were easy to find vulnerabilities
 could be expected. However, looking at the source code was more effective,
-especially when verifying that the CMS \emph{passes} a requirement. Buggy code
-is easy to find, bugless code is not.
+especially when verifying that the \CMS{} \emph{passes} a requirement. Buggy code
+is easy to find. Bugless code is not.
 
 We have chosen to split the work by category of security requirements in
 the OWASP Application Security Verification Standard. We set the goal to perform
@@ -26,16 +26,17 @@ a sound level 2 audit on the software.
 % Initial approach
 We were quickly set up and started to do each own parts of the audit by hand.
 For each OWASP ASVS item specific to certain mechanisms (like login and input
-validation), we would take the source code of the CMS and follow the control
+validation), we took the source code of the \CMS{} and follow the control
 flow to see if the application satisfies the security requirement. For more
 general requirements, we could just look at the code that is responsible for
-this requirement (like the \code{Response} class in the case of HTTP security).
+this requirement (like the \code{Response} class in the case of \HTTP{} security).
 When we had found that a requirement was not satisfied, we elaborate shortly
 and move on.
 
 This went well, because with five people the individual workload is just not
-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
-the CMS turned out to not satisfy the ASVS in most cases.
+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
+the \CMS{} turned out to not satisfy the ASVS in most cases.
 
 % Use of Fortify
 Because we were on track early, most of the audit was already done by when we