From: W <kuhnen@science.ru.nl>
Date: Wed, 23 Nov 2016 13:55:59 +0000 (+0100)
Subject: write reflection on bottlenecks
X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=8fb82c4902649e3b7edd81c2e6acdfe55c732806;p=ssproject1617.git

write reflection on bottlenecks
---

diff --git a/report/reflection.bottlenecks.tex b/report/reflection.bottlenecks.tex
new file mode 100644
index 0000000..42ced32
--- /dev/null
+++ b/report/reflection.bottlenecks.tex
@@ -0,0 +1,38 @@
+ % Wouter:  What were the bottlenecks in doing the security review in your
+ % experience?
+
+% Only working on part of the code: 'big picture' may be missing
+When we divided the work that had to be done for the security audit we
+settled on giving each each member two categories to check. Then later we all
+verified each other's findings.
+
+This approach meant that everyone got very familiar with a certain
+functionality of the web application. But it also created a bottleneck in
+the sense that it is easy to lose overview of the application as the sum of
+its parts. We feel this bottleneck is an acceptable consequence of the way we
+divided the workload.
+
+% Finding the code which handles a requirement (failing is easier than pass)
+Another bottleneck we ran into when failing a requirement was not trivial, was
+finding the actual code which handles a requirement. When assessing if a certain
+requirement passes or fails the OWASP guidelines, one has to find the code which
+implements the requirement. For many of the requirements this comes down to
+finding a counterexample. In our experience there are not often very hard to
+find for this specific web application. However for some requirements
+counterexamples will be harder to find. For these we needed to find all the code
+which touches upon this requirement and then verify it.
+
+To summarize the previous paragraph: it is almost always easier to fail a
+requirement and be sure of it, then to pass it. Because passing means that the
+requirement is OK in \emph{all} cases. While failing needs only to mean that an
+requirement fails in \emph{one} case.
+
+% Verifying each other's results
+The final bottleneck we like to note concerns the verifying of each other's
+results. When verifying the results of your group members (collegues) it may be
+difficult to fully double-check their work. This touches upon the previous
+point, for when a counterexample is giving it is trivial to see the result is
+correct. However when a member of the group passes a requirement it will take
+more time to verify this is the correct verdict. In the end we are confident of
+our results, but this may be a bottleneck which can be addressed in the initial
+organisation.
diff --git a/report/reflection.tex b/report/reflection.tex
index e9d0f20..fdcdf2c 100644
--- a/report/reflection.tex
+++ b/report/reflection.tex
@@ -34,7 +34,8 @@ some components, like input escaping, are just not present.
 \subsection{On our auditing process}
 \input{reflection.auditing_process.tex}
 
-(TODO: Wouter)
+\subsection{On the bottlenecks}
+\input{reflection.bottlenecks.tex}
 
 \subsection{On the ASVS checklist}
 \input{reflection.asvs.tex}