[OWASP-cheat-sheets] Application Threat Modeling Cheatsheet

Dominique Righetto dominique.righetto at owasp.org
Thu Nov 8 05:33:00 UTC 2018


Hi Mohamed,

I think also that it is a good idea to publish it as a draft on the CS
project section.

You can update the content of the current dedicated CS with this content
unless Jim disagree...

Thanks for your contribution.

--
Cordialement, Best regards,
Dominique Righetto
dominique.righetto at gmail.com
<dominique.righetto at gmail.com>dominique.righetto at owasp.org
<dominique.righetto at gmail.com>
https://righettod.eu
GPG: 323D19BA


On Thu, Nov 8, 2018 at 6:29 AM Mohamed Alfateh <mohamed.alfateh at owasp.org>
wrote:

> Hi Jim,
>
> Actually, once you requested some one to work on this cheat sheet, you
> linked us with Shruti Kulkarni. Then we started reviewing it with Tony UV
> till we have the current version.
>
> Is it possible to publish it on OWASP portal as a draft so we can ask the
> community to review and get comments on it ? Would you recommend some one
> else to review it?
>
> Regards
> Fateh
>
> On Thu, Nov 8, 2018 at 12:01 AM Jim Manico <jim.manico at owasp.org> wrote:
>
>> I am not an expert in Threat Modeling. Can we get other OWASP folks who
>> are threat modeling experts to review this?
>>
>> - Jim
>>
>> On 11/4/18 11:21 AM, Mohamed Alfateh wrote:
>>
>> Hi Jim,
>> This is a soft reminder :)
>>
>> On Fri, Oct 19, 2018 at 7:51 AM Jim Manico <jim.manico at owasp.org> wrote:
>>
>>> I am very busy over the next week. A little overwhelmed and short on
>>> time. Can you ask me again next week? I'm sorry folks. It's been a rough
>>> week....
>>>
>>> Aloha, Jim
>>>
>>>
>>>
>>> On 10/18/18 8:51 AM, Mohamed Alfateh wrote:
>>>
>>> Hi Jim,
>>>
>>> Please let me know if you received my below email, and if you have any
>>> comments or feedback to share with us.
>>>
>>> Regards
>>> Fateh
>>>
>>> On Sun, Sep 30, 2018 at 6:54 PM Mohamed Alfateh <
>>> mohamed.alfateh at owasp.org> wrote:
>>>
>>>> Hello Jim,
>>>>
>>>> Please find attached the final version of the cheat sheet.
>>>>
>>>> Regards
>>>> Fateh
>>>>
>>>> On Sat, Sep 1, 2018 at 3:45 PM Jim Manico <jim.manico at owasp.org> wrote:
>>>>
>>>>> I'm very grateful to see progress here. Thanks all!
>>>>>
>>>>> Aloha, Jim
>>>>>
>>>>> On 9/1/18 7:26 AM, Mohamed Alfateh wrote:
>>>>>
>>>>> Thank you Tony,
>>>>> I’ll work with Kanoma to update the final version.
>>>>>
>>>>> Regards
>>>>> Fateh
>>>>>
>>>>> On Sun, Jul 29, 2018 at 6:20 AM Tony UV <tonyuv at owasp.org> wrote:
>>>>>
>>>>>> Hi Fateh and Ahmed,
>>>>>>
>>>>>> Sorry again for the delay.  Never enough time. Below inline and
>>>>>> highlighted are my thoughts and feedback.
>>>>>>
>>>>>> Tony UV
>>>>>>
>>>>>> On Sun, May 13, 2018 at 7:48 AM, Mohamed Alfateh <
>>>>>> mohamed.alfateh at owasp.org> wrote:
>>>>>>
>>>>>>> Hi Tony,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sorry for the delay, a lot of business travels and then
>>>>>>> family time during vacations.
>>>>>>>
>>>>>>> We have updated the cheat sheet, please check the attached file and
>>>>>>> let us know if you will have any feedback,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Also please find my comments for your feedback inline below:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    - I reviewed the other cheat sheets that have been released as
>>>>>>>    final or release candidate ready and I think that this cheat cheat is a bit
>>>>>>>    less instructional and to the point as the others.  I would suggest that
>>>>>>>    you simply provide prescriptive measures that are poignant for the activity
>>>>>>>    that you are covering (i.e. - identify application components, define trust
>>>>>>>    boundaries, etc.)
>>>>>>>
>>>>>>> We have edited the cheat sheet to be more instructional. However, we
>>>>>>> just noticed that not all CS are written in the same way, here are number
>>>>>>> of CSs that you can check out: Yes, agreed that there are different
>>>>>>> formats and I feel that the best are both the online and offline content
>>>>>>> where a downloadable copy for deskside references would be successful, much
>>>>>>> like a lot of the other nice, polished downloadable content that OWASP
>>>>>>> provides.
>>>>>>>
>>>>>>> 1-
>>>>>>> https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet
>>>>>>>
>>>>>>>
>>>>>>> 2- https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
>>>>>>>
>>>>>>> 3- https://www.owasp.org/images/9/9a/OWASP_Cheatsheets_Book.pdf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    - The other sheets also seem to be divided into different
>>>>>>>    categories such as Developer/ Builder - Assessment/ Breaker, etc. I think
>>>>>>>    that this is pretty useful since the approach selected would be slightly
>>>>>>>    different per user of the process.  I wouldn't let prior sheets
>>>>>>>    guide you for how you organize a threat modeling cheat sheet b/c the
>>>>>>>    reality is that application threat modeling can be used for all roles.  As
>>>>>>>    a builder, during the design phase for earlier application security
>>>>>>>    adoption.  As a breaker for knowing where to spending your time in breaking
>>>>>>>    best, particularly if you a risk centric approach like PASTA - instead of
>>>>>>>    boiling the ocean for POC exploits, focus on exploits or attack patterns
>>>>>>>    that support a threat model that is more realistic and most impacting.
>>>>>>>    For example, threat modeling for the developer or architect will be useful
>>>>>>>    for them to think about where to build security in while the assessor or
>>>>>>>    breaker will be on how to pen test better for areas of greater threat
>>>>>>>    likelihood, business impact, etc.  I also think that within the developer
>>>>>>>    track, the threat modeling cheat sheet guidance should be different for new
>>>>>>>    apps vs. existing apps.  Some of the steps or cheat sheet items simply
>>>>>>>    wouldn't apply and my understanding is that many consumers of OWASP cheat
>>>>>>>    sheet series are looking for prescriptive guidance that they can even take
>>>>>>>    as a checklist to doing that respective cheat sheet guidance.  Prescriptive
>>>>>>>    guidance is key but will vary all depending on when do you want to apply
>>>>>>>    it, depending on the approach.  You can build controls or countermeasures
>>>>>>>    solely on the basis of use cases and the attack surface makeup of IT assets
>>>>>>>    (COTS, 3rd party libs, frameworks) and mapping to hardening guidelines but
>>>>>>>    devoid of threat context and then you can do the inverse but that would be
>>>>>>>    after correlating threats and demonstrating attack patterns that are viable
>>>>>>>    via POC attacks.
>>>>>>>
>>>>>>> We have added an intro to the cheat sheet to clarify the audience of
>>>>>>> this cheat sheet. We have divided the sheet to target both Architects and
>>>>>>> Assessors. I would take out Assessors or define what you mean by
>>>>>>> Assessors?  If they are the security champion or threat modeling SME, I
>>>>>>> would define what this means b/c some may take it as simply a security
>>>>>>> assessor which may very well be 1 shade of grey from an auditor,
>>>>>>> which they don't possess the security rationale and dynamic thinking needed
>>>>>>> in order to conduct effective threat models, since their profession is very
>>>>>>> binary in nature.  The cheat sheet can work for both existing apps
>>>>>>> and new apps and we have emphasized that. I think that is a good
>>>>>>> and distinctive quality that is important to have.  For developers;
>>>>>>> I think they may not be in charge of building the TM document,
>>>>>>> they may be responsible to implement the recommended/missing controls
>>>>>>> resulted from the TM. Please advise if they should be part of
>>>>>>> Threat modeling activity?
>>>>>>>
>>>>>>>
>>>>>>>    - Section 1.4 is confusing.  Many of the views and described
>>>>>>>    activities don't correlate and some of them sound like they overlap based
>>>>>>>    upon their own descriptions.  I think you have a good basis but check out
>>>>>>>    1.4.1. and 1.4.5 - both reference use cases so you run the risk of
>>>>>>>    confusing the reader or simply the reader picking one of those and always
>>>>>>>    ignoring the other.  Design considerations revolve around use cases so they
>>>>>>>    both reference some of that. Also, 1.4.4 may be out of scope to most OWASP
>>>>>>>    audience members since its a body of developers and architects.  Not saying
>>>>>>>    its not useful. but with threat modeling, there is a lot of content and
>>>>>>>    just thinking about making something that is pretty lean for consumption
>>>>>>>    and use for different roles.  On top of that you have the approach.
>>>>>>>
>>>>>>> First, section 1.4 is now section 2.2. Reference to 4+1 view model
>>>>>>> of architecture:
>>>>>>> http://ieeexplore.ieee.org/abstract/document/469759/?reload=true
>>>>>>>
>>>>>>> MS DLS and Cigital Toutpoints methodologies noted that the TM should
>>>>>>> be done in the design phase, and as per our experiences with the market,
>>>>>>> the more detailed design we have the more comprehensive threat model we
>>>>>>> can generate, that's why it is better to understand all details about the
>>>>>>> design. We have also highlighted that the CS reader
>>>>>>> can choose another design model. Agreed, don't know where we
>>>>>>> disagree here previously but commenting anyway.
>>>>>>>
>>>>>>>
>>>>>>>    - Speaking of approach, there are things that are missing if
>>>>>>>    this is to be a risk centric approach.  BTW, don't know if you heard of
>>>>>>>    PASTA, but its a risk centric approach that I co-authored with Marco Morana
>>>>>>>    from OWASP.  Its being taught a various universities and has been
>>>>>>>    implemented at various global organizations.  I can simply build an
>>>>>>>    infographic around PASTA and give it to OWASP but interested in @Jim
>>>>>>>    Manico's thoughts on this.
>>>>>>>
>>>>>>> We have reviewed PASTA approach, it looks very comprehensive,  my
>>>>>>> recommendations (away from this CS) is to develop complete use cases
>>>>>>> (similar to the ones you presented in the OWASP last year).
>>>>>>> one suggestion is to open a new OWASP project that perform TM for
>>>>>>> Webgoat application and keep it public, I believe we can find
>>>>>>> many volunteers interested to join this.  Agreed.  I think a OWASP
>>>>>>> flavor, while still citing others would be most applicable. That and
>>>>>>> besides, most tech people don't care about risk perspectives but rather
>>>>>>> improved, resilient and high integrity application features.
>>>>>>>
>>>>>>>
>>>>>>> In general, I think we cover many of the introduced activities in
>>>>>>> each stage, I have added section in the preparation phase regarding the
>>>>>>> identification for business objectives and compliance requirements,
>>>>>>> also added a reference for PASTA in the risk analysis in section 5.
>>>>>>>
>>>>>>> Please note that we are not introducing a new risk analysis
>>>>>>> methodology here, the provided approach is based on collection of
>>>>>>> information from different OWASP resources, AppSec talks, Books
>>>>>>> and presentations, we tried to make it generic as much as we can and
>>>>>>> provide sample of approaches, so the reader can understand the steps and
>>>>>>> follow the provided approach or any other ones.
>>>>>>>
>>>>>>>    - Before you diagram info flows, you have to enumerate your app
>>>>>>>    components, so that is missing under 5 or move 5.2 prior to identifying
>>>>>>>    flows.
>>>>>>>
>>>>>>> 5.2 is 3.1 and it has been move above.
>>>>>>>
>>>>>> This section is moved to section 2. We have added the objective for
>>>>>>> that section in the beginning of the section 3.
>>>>>>>
>>>>>>>
>>>>>>>    - for 5.1.2, its MVC, not MCV.  Common references in frameworks
>>>>>>>    is MVC.
>>>>>>>
>>>>>>> It has been corrected
>>>>>>>
>>>>>>>    - I suggest renaming 6.5 mapping abuse cases to use cases since
>>>>>>>    use cases have been previously identified
>>>>>>>
>>>>>>> It has been edited
>>>>>>>
>>>>>>>    - 6.1 perverses the use of the word threat to include the list
>>>>>>>    of what I presume are threat libraries.  None of those are threat libraries
>>>>>>>    and the problem today is that security practioners are using the inverse of
>>>>>>>    a lot of that in order to represent a threat library.  Also, many of those
>>>>>>>    lists, like the OWASP Top 10 aren't even backed by data to support that
>>>>>>>    they are the top 10 risks. Since the top ten are risks and not threats, not
>>>>>>>    a good reference as a threat lib. Nor the SANS top 25
>>>>>>>
>>>>>>> Totally agree, what we mean here is to use those references to
>>>>>>> figure out the threats from the list of risks or threat libraries, we have
>>>>>>> edited this section to reflect that.
>>>>>>>
>>>>>>>    - 6.3 should be a subset of 6.1
>>>>>>>
>>>>>>> Done
>>>>>>>
>>>>>>>    - Don't understand the need for 6.6.
>>>>>>>
>>>>>>> To make it clear, We have added the following to the cheat sheet:
>>>>>>>
>>>>>>> In most cases after defining the attack vectors, the compromised
>>>>>>> user role could lead to further attacks into the application. For
>>>>>>> example, assuming that an internet banking user credentials could be
>>>>>>> compromised, the user of this cheat sheet has to then redefine the attack
>>>>>>> vectors that could result from compromising the user’s credentials and so
>>>>>>> on.
>>>>>>>
>>>>>>>    - in PASTA, impact is addressed earlier b/c the audience that
>>>>>>>    knows impact knows the consdequences of product or use case failures more
>>>>>>>    than participants in the threat analysis phase.  Biased obviously but think
>>>>>>>    the PASTA steps are more condusive for collaboration amongst a diverse
>>>>>>>    group of people that may have knowledge of different parts of a threat
>>>>>>>    model and the variables of a risk formula.
>>>>>>>
>>>>>>> PASTA is great to integrate the application threat modeling within
>>>>>>> the risk management process, but we have to consider that even the
>>>>>>> methodologies for IT risk analysis may not address the impact early on in the
>>>>>>> analysis phase. To cover this new approach, we have added a section
>>>>>>> in the preparation phase, this will help the readers select whatever
>>>>>>> approach they will use.  PASTA is intended to integrate during an
>>>>>>> S-SDLC suite of phase for a new application or as part of a security review
>>>>>>> for an existing application.  I don't believe in application security risk
>>>>>>> assessments anymore (as those that may be conducted by the likes of ISACA
>>>>>>> types) b/c they are very binary and leverage a control framework
>>>>>>> basis for denoting risks versus contextually looking at threats, impacts,
>>>>>>> probability, effectiveness of countermeasures that may be present.
>>>>>>> R=(T*V*P*I)/Countermeasures
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Fateh
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, Aug 31, 2017 at 1:15 AM, Tony UV <tonyuv at owasp.org> wrote:
>>>>>>>
>>>>>>>> Hi Mohamed,
>>>>>>>>
>>>>>>>> Sorry again for the delay.
>>>>>>>>
>>>>>>>> I read the cheat sheet and below are my points and suggestions.
>>>>>>>> Happy to hop on a hangouts to chat around some of the below mentioned.
>>>>>>>>
>>>>>>>>
>>>>>>>>    - I reviewed the other cheat sheets that have been released as
>>>>>>>>    final or release candidate ready and I think that this cheat cheat is a bit
>>>>>>>>    less instructional and to the point as the others.  I would suggest that
>>>>>>>>    you simply provide prescriptive measures that are poignant for the activity
>>>>>>>>    that you are covering (i.e. - identify application components, define trust
>>>>>>>>    boundaries, etc.)
>>>>>>>>    - The other sheets also seem to be divided into different
>>>>>>>>    categories such as Developer/ Builder - Assessment/ Breaker, etc. I think
>>>>>>>>    that this is pretty useful since the approach selected would be slightly
>>>>>>>>    different per user of the process.  For example, threat modeling for the
>>>>>>>>    developer or architect will be useful for them to think about where to
>>>>>>>>    build security in while the assessor or breaker will be on how to pen test
>>>>>>>>    better for areas of greater threat likelihood, business impact, etc.  I
>>>>>>>>    also think that within the developer track, the threat modeling cheat sheet
>>>>>>>>    guidance should be different for new apps vs. existing apps.  Some of the
>>>>>>>>    steps or cheat sheet items simply wouldn't apply and my understanding is
>>>>>>>>    that many consumers of OWASP cheat sheet series are looking for
>>>>>>>>    prescriptive guidance that they can even take as a checklist to doing that
>>>>>>>>    respective cheat sheet guidance.
>>>>>>>>    - Section 1.4 is confusing.  Many of the views and described
>>>>>>>>    activities don't correlate and some of them sound like they overlap based
>>>>>>>>    upon their own descriptoins.  I think you have a good basis but check out
>>>>>>>>    1.4.1. and 1.4.5 - both reference use cases so you run the risk of
>>>>>>>>    confusing the reader or simply the reader picking one of those and always
>>>>>>>>    ignoring the other.  Design considerations revolve around use cases so they
>>>>>>>>    both reference some of that. Also, 1.4.4 may be out of scope to most OWASP
>>>>>>>>    audience members since its a body of developers and architects.  Not saying
>>>>>>>>    its not useful. but with threat modeling, there is a lot of content and
>>>>>>>>    just thinking about making something that is pretty lean for consumption
>>>>>>>>    and use for different roles.  On top of that you have the approach.
>>>>>>>>    - Speaking of approach, there are things that are missing if
>>>>>>>>    this is to be a risk centric approach.  BTW, don't know if you heard of
>>>>>>>>    PASTA, but its a risk centric approach that I co-authored with Marco Morana
>>>>>>>>    from OWASP.  Its being taught a various universities and has been
>>>>>>>>    implemented at various global organizations.  I can simply build an
>>>>>>>>    infographic around PASTA and give it to OWASP but interested in @Jim
>>>>>>>>    Manico's thoughts on this.
>>>>>>>>    - Before you diagram info flows, you have to enumerate your app
>>>>>>>>    components, so that is missing under 5 or move 5.2 prior to identifying
>>>>>>>>    flows.
>>>>>>>>    - for 5.1.2, its MVC, not MCV.  Common references in frameworks
>>>>>>>>    is MVC.
>>>>>>>>    - I suggest renaming 6.5 mapping abuse cases to use cases since
>>>>>>>>    use cases have been previously identified
>>>>>>>>    - 6.1 perverses the use of the word threat to include the list
>>>>>>>>    of what I presume are threat libraries.  None of those are threat libraries
>>>>>>>>    and the problem today is that security practioners are using the inverse of
>>>>>>>>    a lot of that in order to represent a threat library.  Also, many of those
>>>>>>>>    lists, like the OWASP Top 10 aren't even backed by data to support that
>>>>>>>>    they are the top 10 risks. Since the top ten are risks and not threats, not
>>>>>>>>    a good reference as a threat lib. Nor the SANS top 25
>>>>>>>>    - 6.3 should be a subset of 6.1
>>>>>>>>    - Don't understand the need for 6.6.
>>>>>>>>    - in PASTA, impact is addressed earlier b/c the audience that
>>>>>>>>    knows impact knows the consdequences of product or use case failures more
>>>>>>>>    than participants in the threat analysis phase.  Biased obviously but think
>>>>>>>>    the PASTA steps are more condusive for collaboration amongst a diverse
>>>>>>>>    group of people that may have knowledge of different parts of a threat
>>>>>>>>    model and the variables of a risk formula.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Happy to jump on a hangout to speak further on the above mentioned.
>>>>>>>>
>>>>>>>> On Thu, Jul 20, 2017 at 3:53 PM, Jim Manico <jim.manico at owasp.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Tony,
>>>>>>>>>
>>>>>>>>> Fateh would like to add the following threat modeling cheatsheet
>>>>>>>>> to the OWASP project.
>>>>>>>>>
>>>>>>>>> Can you take a quick look?
>>>>>>>>>
>>>>>>>>> Aloha, Jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------- Forwarded Message --------
>>>>>>>>> Subject: Application Threat Modeling Cheatsheet
>>>>>>>>> Date: Wed, 19 Jul 2017 16:25:23 +0200
>>>>>>>>> From: Mohamed Alfateh <mohamed.alfateh at owasp.org>
>>>>>>>>> <mohamed.alfateh at owasp.org>
>>>>>>>>> To: Jim Manico <jim.manico at owasp.org> <jim.manico at owasp.org>
>>>>>>>>>
>>>>>>>>> Hi Jim,
>>>>>>>>>
>>>>>>>>> I'm following up for the Application Threat Modeling Cheatsheet
>>>>>>>>> that I worked on before, seems it was not uploaded yet online.
>>>>>>>>>
>>>>>>>>> I have worked with my colleague (Ahmed Kanoma) to come with an
>>>>>>>>> updated version (attached the draft), please let me know if you have any
>>>>>>>>> comments, and what is the required from my side to update the current
>>>>>>>>> online version.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Fateh
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-cheat-sheets/attachments/20181108/127b03b6/attachment-0001.html>


More information about the OWASP-cheat-sheets mailing list