--- /dev/null
+
+The OWASP ASVS presents us with a nice case of the development of application security awareness.
+ As an initial effort to provide a structured and general account of web app security concerns \&
+ their mitigation, it shows us in particular how awareness of, and development process around security
+ is still in its infancy, and also tells us some part of why exactly this open problem is so hard to tackle.
+
+First, note how it presents itself as a \emph{simple checklist}, with as single guiding structure the
+ categories under which the respective requirements fall (access control, session management, etc.).
+ We view this as an effort to make it \emph{conceptually simple}, transparent and accessible; it even states
+ the aim to be designed in such a way as to be easily transformed into automated penetration tests etc.
+
+Another typical way to present security concerns \& measures would be to list appropriate security concerns
+ per type of architectural component of a web app, and thus integrate it into the development lifecycle.
+ We suspect the ASVS is presented the way it is, exactly because security is an \emph{emergent property},
+ and thus security measures should not be regarded as attachments to respective components of an app.
+ Rather, it should be verified at each stage \& level; and thus a checklist is a better presentation.
+
+However, this method of presentation is just that. A philosophy on how to tackle security, and a
+ means to adoption and spread. More important to its nature is that it seems to present us with a
+ (process towards a) tested \& true technical \emph{knowledge base} on web application security.
+ And as such, its more striking feature is that it is an endeavor to discover and structure an
+ \emph{effective ontology} of web app security. Analyzing the requirements, one finds
+ that they most often have the form:
+ \begin{enumerate}
+ \item one or more architectural concepts or patterns (linked to each other)
+ \item their link to a security concept, which is often based on the link between the concepts above,
+ not just a concept on itself
+ \item (a typical mitigation)
+ \end{enumerate}
+
+% TODO: examples (?)
+
+The form is not accentuated, and this is probably done for the reason stated above: to stress the
+ simplicity of the checklist, and (because of security as an emergent property) to leave the list of
+ requirements open-ended.
+
+We feel that the above sums up the two key aspects of the ASVS: that it is a conceptually simply
+ structured checklist, as to be easily used \& automated; and that it is an endeavor to provide
+ an effective ontology of web app security. These two are in conflict to some degree, and thus
+ the key nature of the ASVS is that it is a careful compromise between the two.
+
+We feel however, that this should just be a start, and definitely need/should not be the final form
+ that the ASVS takes. The process of applying the ASVS (in an audit, or in a development cycle)
+ has much to gain from the insight that it is an endeavor of ontology; for example, by
+ documenting and using the above-stated form of the requirements for other possible
+ scenario's of presenting the ASVS (e.g.~during application development).
+
+% [2.6] (use of) authentication -> failing can leak info (=> fail securely)
+% [?] -> auth policy (=> implement)
+% (=> log)
+% [4.5] (use of) server -> unwanted transparency (=> disable)
+% data objects -> access policy -> its security depends on parameters (=> secure them)
+% [7.8] (use of) cryptography -> security policies (=> follow them)
--- /dev/null
+
+
+% Daan: If you would have to do something like this again? (...)
+We have noticed that, when doing an audit in a team, it is not feasible for
+everybody to have read all source code. Henceforth, trying this is just a bad
+idea. We are happy to have divided the project by ASVS category, instead of
+program component. For each requirement the the ASVS, the
+team had to verify that there were no mistakes in the code. This would have
+taken a lot of time if we had to verify each component for each requirement.
+Furthermore, the ASVS is an easy guide for dividing the work\footnote{The
+categories in the ASVS are all of similar size. We settled on giving each team
+member two categories to check.}. Dividing by component would have been a lot
+harder to do fairly, especially because when beginning the project we had
+little knowledge of the internals (and component sizes) of the CMS.
+
+We haven't experimented with working in pairs. This might be a good idea to
+experiment with. We are confident however that, because we have all checked
+each other's finished work (and the final product), we did not miss any
+problems.
+In the end, we are satisfied with the way we have done things.
% - Wouter: This last question might be generalised, to (web) applications in general, rather than this specific example of the TestCMS: ie. if you were to develop an application that will need to be subjected to a security review, would you do anything differently, given your experience in doing this, and if so, what and why?
-% Daan: If you would have to do something like this again? (...)
-We have noticed that, when doing an audit in a team, it is not feasible for
-everybody to have read all source code. Henceforth, trying this is just a bad
-idea. We are happy to have divided the project by ASVS category, instead of
-program component. For each requirement the the ASVS, the
-team had to verify that there were no mistakes in the code. This would have
-taken a lot of time if we had to verify each component for each requirement.
-Furthermore, the ASVS is an easy guide for dividing the work\footnote{The
-categories in the ASVS are all of similar size. We settled on giving each team
-member two categories to check.}. Dividing by component would have been a lot
-harder to do fairly, especially because when beginning the project we had
-little knowledge of the internals (and component sizes) of the CMS.
-
-We haven't experimented by working in pairs. This might be a good idea to
-experiment with. We are confident however that, because we have all checked
-each other's finished work (and the final product), we did not miss any
-problems.
-In the end, we are satisfied with the way we have done things.
+
+\subsection{On our auditing process}
+\input{reflection.auditing_process.tex}
+
+(TODO: Wouter)
+
+\subsection{On the ASVS checklist}
+\input{reflection.asvs.tex}
+
+\subsection{On HP Fortify / automated code analysis tools}
+(TODO: Charlie)
+
+\subsection{?}
+(TODO: Mart)
+
+\subsection{On the code \& streamlining subsequent security audits}
+\input{reflection.code_and_auditing.tex}
repositories / ssproject1617.git / commitdiff