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

From OWASP
Jump to: navigation, search
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
If you are performing an application security verification according to the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project 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:
+
If you are performing an application security verification according to the [[::Category:OWASP_Application_Security_Verification_Standard_Project| 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:
  
  
Line 5: Line 5:
  
  
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 [https://www.owasp.org/index.php/How_to_meet_verification_reporting_requirements How to meet verification reporting requirements]:
+
The level of detail, and corresponding depth and breadth of analysis, is the same for ASVS Levels 1, 1A, and 1B.  
 +
 
 +
 
 +
A recommended first step is to draw a network-level picture that identifies which physical servers your application components are located on, and servers where none of your application components are located, as depicted in the figure below
 +
 +
 
 +
[[Image:Asvs_network.gif]] 
 +
 
 +
 
 +
The above requirements can then be met by simply listing web application and IT environment components, as described in the ASVS article [[How_to_meet_verification_reporting_requirements |How to meet verification reporting requirements]]:
  
  
Line 42: Line 51:
 
**E.g. "<open source server> <user function>-related subcomponents that were not modified" - this MAY NOT be included in a review
 
**E.g. "<open source server> <user function>-related subcomponents that were not modified" - this MAY NOT be included in a review
 
**E.g. "<open source server> <user function>-related subcomponents that were modified" - this would likely be included in a review
 
**E.g. "<open source server> <user function>-related subcomponents that were modified" - this 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]]

Latest revision as of 07:09, 29 March 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.


A recommended first step is to draw a network-level picture that identifies which physical servers your application components are located on, and servers where none of your application components are located, as depicted in the figure below


Asvs network.gif


The above requirements can then 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 (more to the point: to reduce) code review tool license fees.
    • E.g. "authentication module subcomponent" - this would likely be included in a review
    • E.g. "management subcomponent" - this would likely be included in a review
    • E.g. "<open source server> <user function>-related subcomponents that were not modified" - this MAY NOT be included in a review
    • E.g. "<open source server> <user function>-related subcomponents that were modified" - this would likely be included in a review