A lot of minor (mostly textual) changes

[ssproject1617.git] / report / reflection.asvs.tex

diff --git a/report/reflection.asvs.tex b/report/reflection.asvs.tex
index 091f27a..8f2272f 100644 (file)
--- a/report/reflection.asvs.tex
+++ b/report/reflection.asvs.tex
@@ -1,6 +1,6 @@
 
 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 \&
+  As an initial effort to provide a structured and general account of web app security concerns and
   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.
 
@@ -9,15 +9,15 @@ First, note how it presents itself as a \emph{simple checklist}, with as single
   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
+Another typical way to present security concerns and 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.
+  Rather, it should be verified at each stage and 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.
+  (process towards a) tested and 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:
@@ -35,7 +35,7 @@ The form is not accentuated, and this is probably done for the reason stated abo
   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
+  structured checklist, as to be easily used and 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.