CRV2 RiskBasedApproach - Revision history

Gary David Robinson at 13:44, 17 February 2014

2014-02-17T13:44:33Z

Gary David Robinson at 13:44, 17 February 2014

2014-02-17T13:44:05Z

Gary David Robinson at 13:32, 17 February 2014

2014-02-17T13:32:31Z

Gary David Robinson at 12:05, 17 February 2014

2014-02-17T12:05:16Z

Gary David Robinson: 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..."

2014-02-17T09:55:09Z

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..."

New page

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
* integrate into repeatable CCPM
* mgmt will ultimately own the risk
* CIA of risk
* management of resources (machines, time, skills)
* what is high risk? Ease of exposure? Value of loss?
* analogy to car development/maintenance risk. Subjective or regimented risk, regulartory controls are higher risk
* test everything or just high risk?
* risk analysis involves cost/benifits analysis
* sizing review would allow mgmt to know what resources are needed
* redundancy and physical failure
* high risk issues/features are candidate for automated testing/review checks
* 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.
* diff codelines for more sensitive code
* 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

@@ Line 26: / Line 26: @@
 Risk is chance of something bad happening and the damage that can be caused if it occurs. The criteria for deciding the risk profile of different code modules will be up to the management team resposible for delivering the changes, however some common critera used would include:
- * Ease of exposure: Is the code change in a piece of code directly exposed to the internet?  Does an insider use the interface directly?
+# Ease of exposure: Is the code change in a piece of code directly exposed to the internet?  Does an insider use the interface directly?
- * Value of loss: How much could be lost if the module has a bug introduced?  Is the module some critical password hashing mechanism, or a simple change to HTML border on some internal test tool?
+# Value of loss: How much could be lost if the module has a bug introduced?  Is the module some critical password hashing mechanism, or a simple change to HTML border on some internal test tool?
- * Regulatory controls: If a piece of code implements business logic associated with some standard that must be complied with, then these modules can be considered high risk as the penalities for non-conformity can be high.
+# Regulatory controls: If a piece of code implements business logic associated with some standard that must be complied with, then these modules can be considered high risk as the penalities for non-conformity can be high.
@@ Line 45: / Line 45: @@
 # Reduce: This would be the typical resolution path: if the reviewer finds that the code change introduces risk into an element of business logic, a different code change should be sought that satisifies the requirements but at a lower risk.
-# Accept: If there is a risk in the code, but there is no other way to implement the business logic then the code can pass code review
+# Accept: If there is a risk in the code, but there is no other way to implement the business logic then the code can pass code review the risk is considered acceptable.
 # Avoid: It should be possible to consider not performing a code change, if the risk introduced by the change is too great.  Idealy this decision should be reached before the code review stage, but it is entirely possible that factors can arise during development that changes the risk profile and prompts management to reconsider if a change should go ahead.

@@ Line 5: / Line 5: @@
 ==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.
+A development house will have various degrees of code changes 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 ad hoc.
-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.  This will allow management to better size the development cycle, e.g. if a change is going to be done in an area which is high risk, management can know to set aside a day for code review, and ensure persons with relevant skills will be available.  The process of deciding which changes need which level of code review is based on a Risk Analysis of the change being made and the risk level of the module the change is within.
+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.  This will allow management to better size the development cycle, e.g. if a change is going to be done in an area which is high risk, management can know to set aside a day for code review, and ensure persons with relevant skills will be available.  The process of deciding which changes need which level of code review is based on the risk level of the module the change is within.
 ==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.
+If the review intensity of code changes is based on the risk level of the module being changed, 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.
-Decisions on the risk of a module or piece of code should be based on some solid cost/benifit analysis.  It would be irresponsible to decide all modules are high risk, instead management should meet with persons who have an understanding of the code base, and security issues faced by the products, and create a measure of risk for various elements of code.  Code could be split up into modules, directories, products, etc, each with a risk level associated with it.
+Decisions on the risk of a module or piece of code should be based on some solid cost/benefit analysis.  It would be irresponsible to decide all modules are high risk, instead management should meet with persons who have an understanding of the code base, and security issues faced by the products, and create a measure of risk for various elements of code.  Code could be split up into modules, directories, products, etc, each with a risk level associated with it.
-Various methods exist in the realm of Risk Analysis to assign risk to entities, and many books have been dedicated to this type of discussion.  However at a high level 3 options of establishing risk would include:
+Various methods exist in the realm of Risk Analysis to assign risk to entities, and many books have been dedicated to this type of discussion.  At a high level 3 options of establishing risk could include:
- * Quantitive: bring people together and establish a monitary value on the loss associated with the modules, and gauge the likelyhood that the module could be compromised.
+# Quantitive: bring people together and establish a monitary value on the loss associated with the modules, and gauge the likelyhood that the module could be compromised.  Use the dollar values produced from these calculations to determine the level of risk.
- * Qualitive: bring people together and discuss opinions on what level of loss is associated with the modules, and opinions on likelyhood of compromise.  Qualitive does not attempt to nail down monitary assocations with the loss, but tends towards the perception or opinion of associate losses.
+# Qualitive: bring people together and discuss opinions on what level of loss is associated with the modules, and opinions on likelyhood of compromise.  Qualitive does not attempt to nail down monitary assocations with the loss, but tends towards the perception or opinion of associated losses.
- * Delphi: Independently interview or question persons on the losses and compromises of the modules, whilst letting the person know the feedback will be anonymous.  The impression here is that the persons interviewed will give more honest answers to the questions and will not be swayed by other persons arguments/answers.
+# Delphi: Independently interview or question persons on the losses and compromises of the modules, whilst letting the person know the feedback will be anonymous.  The impression here is that the persons interviewed will give more honest answers to the questions and will not be swayed by other persons arguments/answers.
@@ Line 33: / Line 31: @@
-==Feeding risk into continuous processes==
+When levels of risk have been associated with modules, then the policies can be created determining what level of code review must be conducted.  It could be that code changes in module X must be reviewed by 3 persons including a Secuirty Architect, whereas changes in element Y only need a quick one person peer review.  Possibly the code structure could be split up so that riskier code is placed into a separate repository with limited developer access.
-When levels of risk have been associated with modules, then the policies can be created determining what level of code review must be conducted.  It could be that code changes in element X must be reviewed by 3 persons including a Secuirty Architect, whereas changes in element Y only need a quick one person peer review.  Possibly the code structure could be split up so that riskier code is placed into a separate repository with limited developer access.
+Other options (or critera) for riskier modules can include demands on automated testing or static analysis, e.g. code changes in high risk code must include 80% code coverage on static analysis tools, and sufficient automated tests to ensure no regressions occur.  These criteria can be demanded and checked as part of the code review to ensure they are capable of testing the changed code.
-Other options (or critera) for riskier modules can include demands on automated testing or static analysis, e.g. code changes in high risk code must include 80% code coverage on static analysis tools, and sufficient automated tests to ensure no regressions occur.  These criteria can be demanded and checked as part of the code review to ensure they are capable of testing the code change.
+Some companies logically split their code into differing repositories, with more risky code appearing in a repository with a limited subset of developers having access.  If the code is split in this fashion, then it must be remembered that only developers with access to the code should be able to conduct reviews of that code.
@@ Line 45: / Line 44: @@
 The previous sections have covered the risk analysis decisions on what level of code review should be applied.  Risk analysis could also be used during the code review to decide how to react to a code change that introduces risk into the product.  At the end of the day, with typical Risk Analysis, the decisions to be made are "Do I accept, transfer, avoid or reduce this risk?".  In the environment of code review, "transfer" of risk does not really make sense (transfer normally means taking out insurance to cover the cost of exposure), but accept, avoid and reduce can still apply:
- * Reduce: This would be the typical resolution path: if the reviewer finds that the code change introduces risk into an element of business logic, a different code change should be sought that satisifies the requirements but at a lower risk.
+# Reduce: This would be the typical resolution path: if the reviewer finds that the code change introduces risk into an element of business logic, a different code change should be sought that satisifies the requirements but at a lower risk.
- * Accept: If there is a risk in the code, but there is no other way to implement the business logic then the code can pass code review
+# Accept: If there is a risk in the code, but there is no other way to implement the business logic then the code can pass code review
 the risk is considered acceptable.
- * Avoid: It should be possible to consider not performing a code change, if the risk introduced by the change is too great.  Idealy this decision should be reached before the code review stage, but it is entirely possible that factors can arise during development that changes the risk profile and prompts management to reconsider if a change should go ahead.
+# Avoid: It should be possible to consider not performing a code change, if the risk introduced by the change is too great.  Idealy this decision should be reached before the code review stage, but it is entirely possible that factors can arise during development that changes the risk profile and prompts management to reconsider if a change should go ahead.

@@ Line 1: / Line 1: @@
- * 3? - Accept, Transfer, Avoid or Reduce
+__TOC__
-  * 4 - integrate into repeatable CCPM
- * DONE - mgmt will ultimately own the risk
- * 3 - CIA of risk
+==Not all bugs are equal==
- * DONE - management of resources (machines, time, skills)
-  * 3 - what is high risk? Ease of exposure?  Value of loss?
+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.
- * 3- analogy to car development/maintenance risk.  Subjective or regimented risk, regulartory controls are higher risk
- * 1 - test everything or just high risk?
+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.  This will allow management to better size the development cycle, e.g. if a change is going to be done in an area which is high risk, management can know to set aside a day for code review, and ensure persons with relevant skills will be available.  The process of deciding which changes need which level of code review is based on a Risk Analysis of the change being made and the risk level of the module the change is within.
- * 3 - risk analysis involves cost/benifits analysis
-  * 1 - sizing review would allow mgmt to know what resources are needed
- * ? - redundancy and physical failure
+==Who makes the call on Code Review Risk?==
- * 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.
+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 - diff codelines for more sensitive code
- * 3 - quantitive vs qualative risk
+Decisions on the risk of a module or piece of code should be based on some solid cost/benifit analysis.  It would be irresponsible to decide all modules are high risk, instead management should meet with persons who have an understanding of the code base, and security issues faced by the products, and create a measure of risk for various elements of code.  Code could be split up into modules, directories, products, etc, each with a risk level associated with it.
-__TOC__
+Some companies logically split their code into differing repositories, with more risky code appearing in a repository with a limited subset of developers having access.  If the code is split in this fashion, then it must be remembered that only developers with access to the code should be able to conduct reviews of that code.
-==1 Not all bugs are equal==
+ * Ease of exposure: Is the code change in a piece of code directly exposed to the internet?  Does an insider use the interface directly?
-==2 Who makes the call on Code Review Risk?==
+==Feeding risk into continuous processes==
-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.
+When levels of risk have been associated with modules, then the policies can be created determining what level of code review must be conducted.  It could be that code changes in element X must be reviewed by 3 persons including a Secuirty Architect, whereas changes in element Y only need a quick one person peer review.  Possibly the code structure could be split up so that riskier code is placed into a separate repository with limited developer access.
-==4 Feeding risk into continuous processes==
+ * Reduce: This would be the typical resolution path: if the reviewer finds that the code change introduces risk into an element of business logic, a different code change should be sought that satisifies the requirements but at a lower risk.

@@ Line 1: / Line 1: @@
 Development notes:
-  * Doing things right or doing the right things...
+  * 3? - Accept, Transfer, Avoid or Reduce
- * Not all bugs are equal
+  * 4 - integrate into repeatable CCPM
- * long term or short term risk
+  * DONE - mgmt will ultimately own the risk
- * Accept, Transfer, Avoid or Reduce
+  * 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__