Difference between revisions of "How to perform a security architecture review at Level 1"

From OWASP
Jump to: navigation, search
Line 13: Line 13:
 
*''<application component name> – <1-2 sentence description>''
 
*''<application component name> – <1-2 sentence description>''
 
*''<application component name> – <1-2 sentence description>''
 
*''<application component name> – <1-2 sentence description>''
 +
  
 
''The intended environment of the TOV can be described in terms of the following components:''
 
''The intended environment of the TOV can be described in terms of the following components:''
Line 24: Line 25:
  
 
*Examples of IT environment components are application servers and operating systems.
 
*Examples of IT environment components are application servers and operating systems.
 +
*In most instances, also identifying subcomponents for each TOV component will be helpful and/or necessary if for example counting LOC to determine code review tool license fees.
 +
**E.g. "authentication module subcomponent".
 +
**E.g. "management subcomponent".
 +
**E.g. "<open source server> <user function>-related subcomponents that were not modified" (and thus would not likely be included in a review).
 +
**E.g. "<open source server> <user function>-related subcomponents that were modified" (and thus would likely be included in a review).
  
  
 
[[Category:OWASP Application Security Verification Standard Project]]
 
[[Category:OWASP Application Security Verification Standard Project]]
 
[[Category:How To]]
 
[[Category:How To]]

Revision as of 08:39, 19 January 2009

If you are performing an application security verification according to the OWASP Application Security Verification Standard (ASVS) verification requirements, then you will need to perform an analysis of the application’s security architecture. The ASVS Level 1 security architecture requirements read in part:


“... the web application can be defined by simply listing its components. Components may be defined in terms of either individual or groups of source files, libraries, and/or executables... the list need not be sorted or otherwise organized; the web application can be treated as groups of components within a single monolithic entity...”


The level of detail, and corresponding depth and breadth of analysis, is the same for ASVS Levels 1, 1A, and 1B. The above requirements can be met by simply listing web application and IT environment components, as described in the ASVS article How to meet verification reporting requirements:


The Target of Verification (TOV) can be described in terms of the following components:

  • <application component name> – <1-2 sentence description>
  • <application component name> – <1-2 sentence description>
  • <application component name> – <1-2 sentence description>


The intended environment of the TOV can be described in terms of the following components:

  • <environment component name> – <1-2 sentence description>
  • <environment component name> – <1-2 sentence description>
  • <environment component name> – <1-2 sentence description>


Helpful hints:

  • Examples of IT environment components are application servers and operating systems.
  • In most instances, also identifying subcomponents for each TOV component will be helpful and/or necessary if for example counting LOC to determine code review tool license fees.
    • E.g. "authentication module subcomponent".
    • E.g. "management subcomponent".
    • E.g. "<open source server> <user function>-related subcomponents that were not modified" (and thus would not likely be included in a review).
    • E.g. "<open source server> <user function>-related subcomponents that were modified" (and thus would likely be included in a review).