Code Review Preparation - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T15:11:11Z

Added navigation to facilitate sequential reading online

Thomas Herlea: Redefined "Importance" to address concerns from the Talk page

2010-09-09T14:59:51Z

Redefined "Importance" to address concerns from the Talk page

Thomas Herlea: moved Preparation to Code Review Preparation: The previous title was too generic and possible to misunderstand as "OWASP Preparation"

2010-09-09T14:33:26Z

moved Preparation to Code Review Preparation: The previous title was too generic and possible to misunderstand as "OWASP Preparation"

KirstenS: /* Context, Context, Context */

2009-01-23T13:07:10Z

‎Context, Context, Context

KirstenS: /* Discovery: Gathering the Information */

2009-01-23T13:04:46Z

‎Discovery: Gathering the Information

KirstenS: /* Before We Start */

2009-01-23T13:02:50Z

‎Before We Start

KirstenS: /* Laying the Groundwork */

2009-01-23T13:01:24Z

‎Laying the Groundwork

KirstenS: /* Context, Context, Context */

2009-01-16T13:42:00Z

‎Context, Context, Context

KirstenS: /* Discovery: Gathering the information */

2009-01-16T13:41:18Z

‎Discovery: Gathering the information

KirstenS: /* Before we start */

2009-01-16T13:41:06Z

‎Before we start

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
@@ Line 80: / Line 85: @@
 * Security Configuration
 * Network Architecture
 [[Category:OWASP Code Review Project]]

@@ Line 16: / Line 16: @@
 The reviewer(s) need to be familiar with:
 # '''Code''': The language(s) used, the features and issues of that language from a security perspective. The issues one needs to look out for and best practices from a security and performance perspective.
-# '''Context''': The working of the application being reviewed. All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be over-kill, and out of context. What type of data is being manipulated or processed, and what would the damage to the company be if this data was compromised? Context is the '' "Holy Grail" '' of secure code inspection and risk assessment…we’ll see more later.
+# '''Context''': The working of the application being reviewed. All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be over-kill, and out of context. What type of data is being manipulated or processed, and what would the damage to the company be if this data was compromised? Context is the '' "Holy Grail" '' of secure code inspection and risk assessment… we’ll see more later.
 # '''Audience''': The intended users of the application. Is it externally facing or internal to “trusted” users? Does this application talk to other entities (machines/services)? Do humans use this application?
-# '''Importance''': The availability of the application is also important. Shall the enterprise be affected in any great way if the application is “bounced” or shut down for a significant or insignificant amount of time?
+# '''Importance''': The size of the consequences of failure. Shall the enterprise be affected in any great way if the application can not perform its functions as intended?
 ==Discovery: Gathering the Information ==

@@ Line 52: / Line 52: @@
 This is a keystone to security and assessing possible risk to the application. How desirable is the information? What effect would it have on the enterprise if the information were compromised in any way?
-“'''''Is the application internal or external facing?'''''”, “'''''Who uses the application; are they trusted users?'''”''
+“'''''Is the application internal or external facing?'''''”, “'''''Who uses the application, and are they trusted users?'''”''
-This is a bit of a false sense of security as attacks take place by internal/trusted users more often than is acknowledged. It does give us context that the application ''should'' be limited to a finite number of identified users, but it’s not a guarantee that these users shall all behave properly.
+This is a bit of a false sense of security, as attacks take place by internal/trusted users more often than is acknowledged. It does give us context that the application ''should'' be limited to a finite number of identified users, but it’s not a guarantee that these users shall all behave properly.
 ''“'''Where does the application host sit'''?”''

@@ Line 23: / Line 23: @@
 The review team will need certain information about the application in order to be effective. The information should be assembled into a threat model that can be used to prioritize the review. Frequently, this information can be obtained by studying design documents, business requirements, functional specifications, test results, and the like. However, in most real-world projects, the documentation is significantly out of date and almost never has appropriate security information.
-Therefore, one of the most effective ways to get started, and arguably the most accurate, is to talk with the developers and the lead architect for the application. This does not have to be a long meeting, but just enough for the development team to share some basic information about the key security considerations and controls. A walkthrough of the actual running application is very helpful, to give the review team a good idea about how the application is intended to work.  Also, a brief overview of the structure of the codebase and any libraries used can help the review team get started.
+Therefore, one of the most effective ways to get started, and arguably the most accurate, is to talk with the developers and the lead architect for the application. This does not have to be a long meeting, but just enough for the development team to share some basic information about the key security considerations and controls. A walkthrough of the actual running application is very helpful to give the review team a good idea about how the application is intended to work.  Also, a brief overview of the structure of the codebase and any libraries used can help the review team get started.
 If the information about the application cannot be gained in any other way, then the team will have to spend some time doing reconnaissance and sharing information about how the application appears to work by examining the code.

@@ Line 16: / Line 16: @@
 The reviewer(s) need to be familiar with:
 # '''Code''': The language(s) used, the features and issues of that language from a security perspective. The issues one needs to look out for and best practices from a security and performance perspective.
-# '''Context''': The working of the application being reviewed. All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be over-kill, and out of context. What type of data is being manipulated or processed and what would the damage to the company be if this data was compromised. Context is the '' "Holy Grail" '' of secure code inspection and risk assessment…we’ll see more later.
+# '''Context''': The working of the application being reviewed. All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be over-kill, and out of context. What type of data is being manipulated or processed, and what would the damage to the company be if this data was compromised? Context is the '' "Holy Grail" '' of secure code inspection and risk assessment…we’ll see more later.
-# '''Audience''': The intended users of the application, is it externally facing or internal to “trusted” users. Does this application talk to other entities (machines/services)? Do humans use this application?
+# '''Audience''': The intended users of the application. Is it externally facing or internal to “trusted” users? Does this application talk to other entities (machines/services)? Do humans use this application?
 # '''Importance''': The availability of the application is also important. Shall the enterprise be affected in any great way if the application is “bounced” or shut down for a significant or insignificant amount of time?

← Older revision	Revision as of 14:33, 9 September 2010
(No difference)

@@ Line 11: / Line 11: @@
 Performing code review can feel like an audit, and most developers hate being audited. The way to approach this is to create an atmosphere of collaboration between the reviewer, the development team, the business representatives, and any other vested interests. Portraying the image of an advisor and not a policeman is very important if you wish to get full co-operation from the development team.
-Security code review teams that successfully build trust with the development team can become  trusted advisor. In many cases, this will lead to getting security folks involved earlier in the lifecycle, and can significantly cut down on security costs.
+Security code review teams that successfully build trust with the development team can become  trusted advisors. In many cases, this will lead to getting security folks involved earlier in the lifecycle, and can significantly cut down on security costs.
 ==Before We Start==

@@ Line 40: / Line 40: @@
 *Important Business Impacts
 Defining context should provide us with the following information:
 *Establish the importance of the application to the enterprise.
@@ Line 62: / Line 61: @@
 If there are internal and external users, what are the differences from a security standpoint? How do we identify one from another? How does authorization work?
 “'''''How important is this application to the enterprise?'''''”.