Previous: Mitigations, Part 2: Creating Mitigation Proposals

The importance of documenting mitigations well is like the benefits of writing good comments in code. It helps your teammates to understand the mitigations in effect — including future teammates. And, if a Veracode report ever raises doubt about a component’s security, a well-written mitigation proposal can quickly resolve the discussion. It also enables your mitigation approver to approve your request quickly. Think of a well-written mitigation proposal as a gift that you give to yourself in the future. The most important aspect of a well-written mitigation proposal is that it clearly documents the risk for which you are seeking acceptance. Your proposal should clearly show how the mitigation reduces the risk and should be easily understandable even if source code is not available. It should contain as much relevant information about the mitigation as possible, so that even if teammates leave the projects or organization, the record of these mitigating circumstances is retained.

Good Example #1 

Here is one example of a well-formed mitigation proposal. It was written to address a flaw type called “Unsafe Reflection”. This flaw can arise if an application uses the Reflection technique to dynamically load a class at runtime. If it inadvertently allows a user to choose their own class, this opens a potential risk for exploits. While the Veracode scanner can detect the code patterns associated with this kind of risk, there are also factors that it cannot see, and these are what the mitigation proposal documents. It summarizes the controls that reduce the risk and makes an argument that the issue should be considered resolved.  

Mitigated by Design:

Technique: M1 - Establish and maintain control over all of your inputs  

Specifics: We validate that the class name starts with “com.tyrellcorp.pdf.forms” before it is loaded. 

Remaining Risk: If any classes within this namespace contained security flaws, the application would still load them. SAST and penetration testing have uncovered no known flaws that affect these classes.  

Verification: This method has passed unit tests and code review, on top of security testing. 

Notice that the TSRV format is in use here. The chosen technique of M1 is correct because it directly relates to what’s written for “Specifics”. The specifics describe what is validated and explain the purpose of the validation. The “Remaining Risk” section then clarifies what risk is left over, and how it is accounted for. Lastly the “Verification” section includes steps taken to verify the mitigation’s integrity. With this information, it should be easy for a security team to understand and approve this mitigation. 

Good Example #2 

The next example involves a proposal related to an Insufficient Entropy flaw. This kind of flaw arises when the scanner sees that a random number used somewhere in the code is being generated in such a way that the number is potentially predictable. The scanner flags this in case the number is intended for security-related purposes likes creating passwords or tokens. An automated tool can detect if a random number generator (or RNG) is predictable, but it cannot tell what the number is actually used FOR. So, if its function is something that poses no risk—like picking a random image to display—this could form the basis of a mitigation proposal.  

Page Break

Mitigated by Design:

Technique: M1 - Establish and maintain control over all of your inputs  

Specifics: RNG is only used to randomly choose which security question the user will be asked during password reset. The user sets 3 questions/answers during registration. RNG only returns values in the range of 1-3. 

Remaining Risk: If the code were altered to return other numbers, it could break functionality. 

Verification: Unit tests ensure that output range matches the number of available questions. 

Here, the proposal states that the number generation does indeed relate to passwords. This raises the question of its relevance to the app’s security, but the proposal lets us see the real extent of the risk. The technique is again M1, which is a correct choice for the Specifics that follow. These indicate the purpose of this RNG, so we can understand the impact of its use. It seems that it’s only used to select which one of the user’s predefined password reset questions they will see. There seems to be no risk associated with this at present, so the risk section instead accounts for possibility of future risk. Lastly, the Verification section shows how the level of risk is determined. Once again, it should be easy for the security team to decide to approve this mitigation. 

Now that you have seen examples of first-rate proposals, it’s time to consider some mistakes to avoid that may cause a proposal to be rejected. Pay special attention for these mistakes: 

• First, if a mitigation does not actually affect the risk reported in the flaw, it cannot be approved. Proposals that do not provide sufficient information are also not likely to be approved.  
• The proposal also needs to describe mitigations currently in effect, not ones intended to be added in the future.  
• A common reason for mitigation proposals to be rejected is if the proposal attempts to justify that remediation is impossible instead of describing any compensating control. For example, such a proposal might request an exception because the flaw is in a third-party library. If that’s the case, it may still be possible to address the risk by controlling inputs to the library.  
• Another such proposal might state that the flaw is in unused (or “dead”) code. If this is so, it can still be remediated by removing the code from the project. If a flaw seems difficult to remediate, Veracode is here to help.  

Bad Example #1 

This is an example of a poor mitigation for a flaw of type CWE 352, or Cross-Site Request Forgery.  

Potential False Positive:

We validate all input values before processing. 

It is impossible to know if this is effective by only reading this statement. It leaves open the questions of where, how, and why this validation is done. It also does not account for any attempts at performing the standard remediation for this flaw type, which the Veracode tool is able to recognize. Furthermore, this proposal should not have used the Potential False Positive option if the finding was not invalid. This proposal should use Mitigate by Design instead and allow the TSRV format to guide inclusion of the information necessary to review this. 

Bad Example #2 

Cross-Site Scripting, or CWE 80, is another common flaw type.  

Mitigated by Design: 

Technique: M5 - Use industry-accepted security features instead of inventing your own. 

Specifics: The code is used only in an internal logic that does not take user input. 

Risk: None 

Verification: Code review 

This proposal is better than the last one, because it does at least use Mitigated by Design and TSRV. However, the mitigation is based on the fact that the code is only used internally. 

This reduce some of the risk, but not all of it: what happens if an internal user’s account is compromised, or if an internal user acts maliciously? It is therefore not accurate to say that there is no risk involved. The verification section does indicate that a code review was performed, but it does not state what was checked or the role of this review in mitigating the risk. Unfortunately, there are too many open questions here for this proposal to be safely approved. 

Bad Example #3 

The next example pertains to CWE 404, which involves “improper resource shutdown or release”.  

Mitigated by Design: 

Technique: M5 - Use industry-accepted security features instead of inventing your own. 

Specifics: The resource is either a property or return value from a function call. This is a design choice that requires the developer using the class to manage the resource in question. 

Risk: None 

Verification: Coaching will ensure that the code is used correctly. 

Here, the Specifics indicate that the function does something inherently risky by design but contradicts itself when it later states that the Remaining Risk is None. This proposal also has nothing to do with the choice of technique (M5). While the developer training mentioned in the Verification section is a valid countermeasure, it is indeed better to describe this in the Specifics section, since Verification is meant for providing evidence of the mitigation proposal. It’s possible that the mitigation here really is a valid one, but the proposal should be re-written to address its errors before it can be approved. 

Bad example #4 

Lastly, here is a mitigation proposal for CWE 89, or SQL Injection.  

Potential False Positive: 

classname.jspf Is no longer in use in this application. 

We again see Potential False Positive used when it shouldn’t be. The proposal says that if a class is no longer used within an application. This may indeed provide some protection at present. However, if the code is no longer used, it is much better to attempt remediating it by removing the code from the project instead of mitigating it. After all, what if the class were to be used again 6 months later, perhaps by a new teammate that didn’t know not to use it? Then, the risk of SQL Injection would be re-opened. Using TSRV would be valuable here because it would require this user to disclose such a risk, and well as other steps taken to verify it.