report/reflection.asvs.tex

   1
   2 The OWASP ASVS presents us with a nice case of the development of application security awareness.
   3   As an initial effort to provide a structured and general account of web app security concerns and
   4   their mitigation, it shows us in particular how awareness of, and development process around security
   5   is still in its infancy, and also tells us some part of why exactly this open problem is so hard to tackle.
   6
   7 First, note how it presents itself as a \emph{simple checklist}, with as single guiding structure the
   8   categories under which the respective requirements fall (access control, session management, etc.).
   9   We view this as an effort to make it \emph{conceptually simple}, transparent and accessible; it even states
  10   the aim to be designed in such a way as to be easily transformed into automated penetration tests etc.
  11
  12 Another typical way to present security concerns and measures would be to list appropriate security concerns
  13   per type of architectural component of a web app, and thus integrate it into the development lifecycle.
  14   We suspect the ASVS is presented the way it is, exactly because security is an \emph{emergent property},
  15   and thus security measures should not be regarded as attachments to respective components of an app.
  16   Rather, it should be verified at each stage and level; and thus a checklist is a better presentation.
  17
  18 However, this method of presentation is just that. A philosophy on how to tackle security, and a
  19   means to adoption and spread. More important to its nature is that it seems to present us with a
  20   (process towards a) tested and true technical \emph{knowledge base} on web application security.
  21   And as such, its more striking feature is that it is an endeavor to discover and structure an
  22   \emph{effective ontology} of web app security. Analyzing the requirements, one finds
  23   that they most often have the form:
  24   \begin{enumerate}
  25     \item one or more architectural concepts or patterns (linked to each other)
  26     \item their link to a security concept, which is often based on the link between the concepts above,
  27           not just a concept on itself
  28     \item (a typical mitigation)
  29   \end{enumerate}
  30
  31 % TODO: examples (?)
  32
  33 The form is not accentuated, and this is probably done for the reason stated above: to stress the
  34   simplicity of the checklist, and (because of security as an emergent property) to leave the list of
  35   requirements open-ended.
  36
  37 We feel that the above sums up the two key aspects of the ASVS: that it is a conceptually simply
  38   structured checklist, as to be easily used and automated; and that it is an endeavor to provide
  39   an effective ontology of web app security. These two are in conflict to some degree, and thus
  40   the key nature of the ASVS is that it is a careful compromise between the two.
  41
  42 We feel however, that this should just be a start, and definitely need/should not be the final form
  43   that the ASVS takes. The process of applying the ASVS (in an audit, or in a development cycle)
  44   has much to gain from the insight that it is an endeavor of ontology; for example, by
  45   documenting and using the above-stated form of the requirements for other possible
  46   scenario's of presenting the ASVS (e.g.~during application development).
  47
  48 % [2.6] (use of) authentication  ->  failing can leak info                                     (=> fail securely)
  49 % [?]                            ->  auth policy                                               (=> implement)
  50 %                                                                                              (=> log)
  51 % [4.5] (use of) server          ->  unwanted transparency                                     (=> disable)
  52 %       data objects             ->  access policy     ->  its security depends on parameters  (=> secure them)
  53 % [7.8] (use of) cryptography    ->  security policies                                         (=> follow them)