none
Recommended approach to document threats which are felt to be fully mitigated RRS feed

  • Question

  • Sorry for a newbie question, but in going through the process of 'responding' to all the auto-generated threats, there are numerous cases where there IS a valid threat, but our design/implementation has (in our view) fully mitigated the issue.  I'd like to "certify" this (ie, I'm really happy about the state of this particular threat vis-a-vis some others).  Using the current modeller (v.3.1.4), what is the recommended way to show this?

    I'm not wishing to certify there are no threats "does not apply because...", unless I'm certifying there are no RESIDUAL threats due to the mitigation.  If the latter case is what is being documented, then the current choices ("within a trust boundary", "mitigated elsewhere", "accepted risk (per bug bar)") don't appear to cover what I'm trying to document (nailed this, and here are the details how...).  Unless the "bug bar" is the key, but I'm currently modelling stand-alone, no bug bar available as far as I can tell.

    The alternative (not setting the cert) leaves a long list of threats, some 'fully mitigated', some not, and the report really doesn't highlight the current status as well as I'd like.

    Finally(!), what is the reasoning for not having Impact as a sortable/searchable "high"/"medium"/"low" field, rather than just a textual description?

    Again, apologies if these are painfully elementary questions.
    • Moved by Hengzhe Li Tuesday, June 21, 2011 12:08 PM Forum Consolidate (From:Microsoft Security Development Lifecycle (SDL) - Threat Modeling)
    Thursday, January 21, 2010 9:33 PM

Answers

  • Let me try to clarify what I meant, because I answered late in the day at the end of a long week.

    Use the TM process to drive the creation of test cases.  So if you believe you've mitigated something, as you say, document that, and file a bug which starts "ensure the code really checks these things:"  or "ensure that deployment really checks these things"

    Only when you know that such a test case already exists, use "mitigated elsewhere" to link to the test code.
    Tuesday, January 26, 2010 7:04 PM

All replies

  • One approach would be to use "mitigated elsewhere," and point to the test case that demonstrates that it's mitigated and won't regress. If you don't have such a test case, I'd suggest using the TM process to drive the creation of those automated tests, so that you gain assurance that things you think are mitigated really are mitigated.

    Adam

     

     

    PS: The bug bar is not key, but there's a sample security bug bar http://msdn.microsoft.com/en-us/library/cc307404.aspx and privacy bug bar http://msdn.microsoft.com/en-us/library/cc307403.aspx

    Friday, January 22, 2010 6:51 PM
  • Thanks for the quick response.  I guess I'd prefer to reserve "mitigated elsewhere" for when that is actually what is going on (I have an admitted security weakness, but I've instituted a compensating control to mitigate it, perhaps just in the short term).

    A test case would presumably often be part of whatever description I'd provide describing WHY I feel a particular threat has been mitigated.  I guess I'm surprised that the documentation I'm trying to generate (threat model with a summary report for management as to 'how well are we doing') isn't a straight-forward product of the TM exercise (which probably means I'm missing the point...).

    From the standpoint of understanding the process better, isn't (hopefully) the result of good design a TM in which there are:
      - a great many mitigated threats (and thus there should be a way to document this by way of a clearly selectable option/choice),
      - a small or large number of auto-generated threats that aren't actually pertinent for a specific product/application ('do not apply because'), and
      - a relatively few unmitigated threats of varying levels of impact (and it would be nice to prioritize action items based on a perceived severity)

    btw - I'll take a look at the sample bug bar ref, thanks!
    Friday, January 22, 2010 7:45 PM
  • Let me try to clarify what I meant, because I answered late in the day at the end of a long week.

    Use the TM process to drive the creation of test cases.  So if you believe you've mitigated something, as you say, document that, and file a bug which starts "ensure the code really checks these things:"  or "ensure that deployment really checks these things"

    Only when you know that such a test case already exists, use "mitigated elsewhere" to link to the test code.
    Tuesday, January 26, 2010 7:04 PM