This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "CRV2 RiskBasedApproach"
(Created page with "Development notes: * Doing things right or doing the right things... * Not all bugs are equal * long term or short term risk * Accept, Transfer, Avoid or Reduce * integr...") |
|||
| Line 1: | Line 1: | ||
Development notes: | Development notes: | ||
| − | * | + | * 3? - Accept, Transfer, Avoid or Reduce |
| − | + | * 4 - integrate into repeatable CCPM | |
| − | + | * DONE - mgmt will ultimately own the risk | |
| − | + | * 3 - CIA of risk | |
| − | * integrate into repeatable CCPM | + | * DONE - management of resources (machines, time, skills) |
| − | * mgmt will ultimately own the risk | + | * 3 - what is high risk? Ease of exposure? Value of loss? |
| − | * CIA of risk | + | * 3- analogy to car development/maintenance risk. Subjective or regimented risk, regulartory controls are higher risk |
| − | * management of resources (machines, time, skills) | + | * 1 - test everything or just high risk? |
| − | * what is high risk? Ease of exposure? Value of loss? | + | * 3 - risk analysis involves cost/benifits analysis |
| − | * analogy to car development/maintenance risk. Subjective or regimented risk, regulartory controls are higher risk | + | * 1 - sizing review would allow mgmt to know what resources are needed |
| − | * test everything or just high risk? | + | * ? - redundancy and physical failure |
| − | * risk analysis involves cost/benifits analysis | + | * 4 - high risk issues/features are candidate for automated testing/review checks |
| − | * sizing review would allow mgmt to know what resources are needed | + | * 4 - a lot of static analysis tools allow for modules/tests to be plugged in. High risk could be candiate to be mitigated in this way. |
| − | * redundancy and physical failure | + | * 3 - diff codelines for more sensitive code |
| − | * high risk issues/features are candidate for automated testing/review checks | + | * 3 - quantitive vs qualative risk |
| − | * a lot of static analysis tools allow for modules/tests to be plugged in. High risk could be candiate to be mitigated in this way. | + | * 1 - risk could determine who reviews/how many people/# of signoffs etc |
| − | * diff codelines for more sensitive code | + | * 3 - risk is chance of something bad happening and damage if it occurs |
| − | * quantitive vs qualative risk | + | |
| − | * risk could determine who reviews/how many people/# of signoffs etc | + | |
| − | * risk is chance of something bad happening and damage if it occurs | + | __TOC__ |
| + | |||
| + | |||
| + | ==1 Not all bugs are equal== | ||
| + | |||
| + | A development house will have various degrees of code being reviewed, from simple one line bug fixes in backend scripts that run once a year, to large feature submissions in criticial business logic. Typically the intensity of the code review varies based on the perceived risk that the change presents, though typically the perception of this risk is informal and adhoc. It comes down to the management of resources (skilled persons, company time, machines, etc). It would not be common to bring in multiple security architects/experts for every code change occuring on a product, the bandwidth of those persons or those teams would not be large enough to handle every change. Therefore companies can make a call on which changes are important and need to be closely scrutenized, and which ones can be allowed through with minimal inspection. The process of deciding which changes need which level of code review is based on a Risk Analysis of the change being made. | ||
| + | |||
| + | |||
| + | ==2 Who makes the call on Code Review Risk?== | ||
| + | |||
| + | So if we are going to vary our code review intensity based on the nature of the change being made, who should decide the level of risk? Eventually, company Management are responsible for the output of a company, and thus they are responsible for the risk associated with products sold by the company, therefore it is up to Management (or persons delegated to by Management) to create a reproducable measure or framework for deciding the risk associated with a code change. | ||
| + | |||
| + | |||
| + | ==3 Options for deciding the risk associcated with a code change== | ||
| + | |||
| + | |||
| + | |||
| + | ==4 Feeding risk into continuous processes== | ||
Revision as of 12:05, 17 February 2014
Development notes:
* 3? - Accept, Transfer, Avoid or Reduce * 4 - integrate into repeatable CCPM * DONE - mgmt will ultimately own the risk * 3 - CIA of risk * DONE - management of resources (machines, time, skills) * 3 - what is high risk? Ease of exposure? Value of loss? * 3- analogy to car development/maintenance risk. Subjective or regimented risk, regulartory controls are higher risk * 1 - test everything or just high risk? * 3 - risk analysis involves cost/benifits analysis * 1 - sizing review would allow mgmt to know what resources are needed * ? - redundancy and physical failure * 4 - high risk issues/features are candidate for automated testing/review checks * 4 - a lot of static analysis tools allow for modules/tests to be plugged in. High risk could be candiate to be mitigated in this way. * 3 - diff codelines for more sensitive code * 3 - quantitive vs qualative risk * 1 - risk could determine who reviews/how many people/# of signoffs etc * 3 - risk is chance of something bad happening and damage if it occurs
1 Not all bugs are equal
A development house will have various degrees of code being reviewed, from simple one line bug fixes in backend scripts that run once a year, to large feature submissions in criticial business logic. Typically the intensity of the code review varies based on the perceived risk that the change presents, though typically the perception of this risk is informal and adhoc. It comes down to the management of resources (skilled persons, company time, machines, etc). It would not be common to bring in multiple security architects/experts for every code change occuring on a product, the bandwidth of those persons or those teams would not be large enough to handle every change. Therefore companies can make a call on which changes are important and need to be closely scrutenized, and which ones can be allowed through with minimal inspection. The process of deciding which changes need which level of code review is based on a Risk Analysis of the change being made.
2 Who makes the call on Code Review Risk?
So if we are going to vary our code review intensity based on the nature of the change being made, who should decide the level of risk? Eventually, company Management are responsible for the output of a company, and thus they are responsible for the risk associated with products sold by the company, therefore it is up to Management (or persons delegated to by Management) to create a reproducable measure or framework for deciding the risk associated with a code change.
