From 8fb82c4902649e3b7edd81c2e6acdfe55c732806 Mon Sep 17 00:00:00 2001 From: W Date: Wed, 23 Nov 2016 14:55:59 +0100 Subject: [PATCH] write reflection on bottlenecks --- report/reflection.bottlenecks.tex | 38 +++++++++++++++++++++++++++++++ report/reflection.tex | 3 ++- 2 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 report/reflection.bottlenecks.tex 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} -- 2.20.1