From 300e85f3c63352c982b683c730531a8ede1a3895 Mon Sep 17 00:00:00 2001 From: Kelley van Evert Date: Tue, 22 Nov 2016 18:28:17 +0100 Subject: [PATCH] Structured the reflection somewhat; Added some reflection as to the ASVS; --- report/preamble.tex | 2 + report/reflection.asvs.tex | 53 +++++++++++++++++++++++++ report/reflection.auditing_process.tex | 20 ++++++++++ report/reflection.code_and_auditing.tex | 4 ++ report/reflection.tex | 35 ++++++++-------- 5 files changed, 96 insertions(+), 18 deletions(-) create mode 100644 report/reflection.asvs.tex create mode 100644 report/reflection.auditing_process.tex create mode 100644 report/reflection.code_and_auditing.tex diff --git a/report/preamble.tex b/report/preamble.tex index 03b12fd..cd35da8 100644 --- a/report/preamble.tex +++ b/report/preamble.tex @@ -76,6 +76,8 @@ % span code fragments \newcommand{\code}[1]{\texttt{#1}} +\renewcommand{\emph}[1]{\textbf{\textit{#1}}} + \author{% Kelley van Evert\\ Charlie Gerhardus\\ diff --git a/report/reflection.asvs.tex b/report/reflection.asvs.tex new file mode 100644 index 0000000..091f27a --- /dev/null +++ b/report/reflection.asvs.tex @@ -0,0 +1,53 @@ + +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) diff --git a/report/reflection.auditing_process.tex b/report/reflection.auditing_process.tex new file mode 100644 index 0000000..3811140 --- /dev/null +++ b/report/reflection.auditing_process.tex @@ -0,0 +1,20 @@ + + +% 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. diff --git a/report/reflection.code_and_auditing.tex b/report/reflection.code_and_auditing.tex new file mode 100644 index 0000000..8a78104 --- /dev/null +++ b/report/reflection.code_and_auditing.tex @@ -0,0 +1,4 @@ + +(TODO: Kelley) + +(TODO: Wouter) diff --git a/report/reflection.tex b/report/reflection.tex index fced269..e9d0f20 100644 --- a/report/reflection.tex +++ b/report/reflection.tex @@ -30,21 +30,20 @@ some components, like input escaping, are just not present. % - 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} -- 2.20.1