How to migrate existing microsoft threat templates will multiple grouping

[rsrinivasanhome]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I have an existing microsoft threat model template . We have created our own grouping so we have code similar to below

<ElementType>
      <Name>Generic Mobile Application</Name>
      <ID>My.GM.App</ID>
      <Description>A representation of a generic mobile App</Description>
      <ParentElement>ROOT</ParentElement>

How do we handle such scenarios when we import to threats manger studio? I am not able to see the grouping post migration.

I have rules referring to this ID - My.GM.App

Advise on how to handle this scenario will be helpful

Describe alternatives you've considered I am able to see the children objects ie - android and ios app but my rules have started to evaluate wrongly. Let me know if any more info is required ?

[simonec73]

I understand that this is an XML fragment, but still it does not look like a correct XML for a TMT document. Please be advised that you should never edit a .TB7 or .TM7 file directly. This is not a supported scenario for TMT.

I need your template or something able to reproduce the problem, to understand what is happening.

[rsrinivasanhome]

I am attaching a sample threat model template built on the azure template. When I use it with Microsoft threat modeling the following condition is not executing

 <GenerationFilters>
        <Include>(source is 'My.GM.App' )</Include>
        <Exclude>(target.ShowAzureServiceThreat is 'No' or target.ShowAzureAssetThreat is 'No' or target.ShowAzureDataServiceThreat is 'No' or flow.ShowBoundaryThreats is 'No')</Exclude>
      </GenerationFilters>
      <Id>TH9909</Id>
      <ShortTitle>Check if jailbreakcing is enabled only fire if mobile app</ShortTitle>

But in threat manager studio I am getting a false positive when I import the template in threats manager studio. Even without mobile app I am getting the error

[rsrinivasanhome]

AzureTemplate_simulatedSample.tb7.txt Remove the .txt extension and you can try it out

[simonec73]

Ok, thank you. I confirm that this approach is not supported as of today, because the grouping is not following the standard structure. You have essentially removed External Interactors, Processes, Data Stores, Flows and Trust Boundaries, replacing them with something fundamentally different, to create a different hierarchy. Unfortunately, TMS is bound to the standard hierarchy. This means that it may be possible to import your template, but the hierarchy you have created would be lost.

For example, from the example above I would need to create an Azure Asset, which would be an External Interactor (because you used a rectangle shape); then the Advisor, again an External Interactor; then Active Directory, a Data Store; and so on. All those stencils would be unrelated in TMS. Only the properties would be duplicated.

Is that the result you want to achieve?

On a side note, the association between stencils and TM shapes seems wrong. Are you going to fix that?

[rsrinivasanhome]

This is the template I am building upon - https://github.com/AzureArchitecture/threat-model-templates so that is where I got the hierarchy from . My existing template are based on this hierarchy. If I change the type I think it will impact the migration but willing to correct. Why does Azure ADB2C come as External Interface and Azure AD as a process ? Is the classification dependent on the tag ? I feel active directory , azure adb2c should be data stores . Can you highlight with some examples this part - "the association between stencils and TM shapes seems wrong. Are you going to fix that?"

[simonec73]

Yes, the types of shapes would determine the type of entity. If I cannot rely on the parent node, I need to rely on something else. :) This is what I was referring to when I wrote that the association is wrong.

[rsrinivasanhome]

Do you feel active directory should be a data store ? For me any service with state should be a datastore .

[rsrinivasanhome]

can we change the "entity type" within threats manager studio ? I think you mentioned before we can not use notepad to update the file .

[simonec73]

Do you feel active directory should be a data store ? For me any service with state should be a datastore .

The difference between Processes and Data Stores is not that the first have no data, but that the latter has no logic. Bottom line, I guess it may be best to define it a Process, because it handles authentication.

[simonec73]

can we change the "entity type" within threats manager studio ? I think you mentioned before we can not use notepad to update the file .

No, you can't. You can change the shape in TMT using the Template editor though.

[kwwall-gri]

@simonec73 wrote:

The difference between Processes and Data Stores is not that the first have no data, but that the latter has no logic. Bottom line, I guess it may be best to define it a Process, because it handles authentication.

IMO, it's not clear that this should be an absolute though.

For instance, we typically model databases in threat models as "Data Stores", but those same databases may have stored procedures (a sort of latent logic that still has be invoked) or DB triggers (active logic, automatically triggered by the DB via CRUD actions). Typically though, it's still okay to identify those threat model artifacts as "data stores" rather as "processes" because thee primary emphasis is on data rather than the logic.

I think the exception would be if the logic is paramount to the understanding your threat model in some specific context. When the emphasis is on the logic rather than just the passive data, it probably makes more sense to identify it as "process", as in the case with AD, which primarily has an AuthN/AuthZ decision making role.

Alternately, I know of no hard-fast rule to threat modeling to list something it as both Data Store and Process, as long as you give it 2 distinct names. E.g., "Application DB" as a data store and "Application DB Triggers" as a process.)

YMMV. Just my $.02.

[simonec73]

Of course you can apply a different definition, but the general definition adopted by the STRIDE methodology corresponds to what I have used here.

For example, I've recently assisted to a presentation by Michael Howard, where he has noted how the rigorous representation of a DB with Stored Procedures should be with two different shapes: the main one would be a Data Store, and then you would have a Process to represent the logic.

Nevertheless, as Adam Shostack writes in his book all representations are wrong, and what you should strive to achieve is a useful representation. So, you want to assign a different meaning and that works for you, you are welcome to it.

That said, I guess we are not really saying anything particular different. The general rule can be bend, and I have seen perfectly legitimate Threat Models with DBs been treated as Data Stores even if they had some business logic.

On the other hand, something like Databricks must be represented as a Process, because it is there to process data. But it is also true that it has a significant component which stores data, therefore it could be considered a Data Store as well.

Bottom line: the rule I have represented is the general rule, but there are exceptions which depend on what you do want to highlight the most.

I hope it makes sense.