Added new custom elements which are frequently used for threat modeling

[gandhirajan]

Added new custom elements like Vault, Gateway and Message Queue which are frequently in modern applications which can be provided out of the box in the framework going forward for easing the threat modeling.

[izar]

hi, thanks for your contribution! Do you have specific threats that should go together with these elements?

[raphaelahrens]

If message queue includes Pub/Sub broker I could supply some specific threats.

[gandhirajan]

raphaelahrens

The message queue element is related to pub-sub of course that involved resources like Kafka or Event hubs.

[gandhirajan]

hi, thanks for your contribution! Do you have specific threats that should go together with these elements?

Thanks for the response Izar. Is there a threat repo available where can I look for this info so that I can hook the respective threat info to the elements?

[izar]

You mean pytm threats? They're in threats.json together with the code. I would really like to avoid adding elements for the sake of adding. Unless they bring something unique and useful, they can still be expressed as Elements, with additional attributes created on the fly, or extended in a local library.

[raphaelahrens]

@gandhirajan you can find the threats here https://github.com/izar/pytm/blob/master/pytm/threatlib/threats.json

[gandhirajan]

You mean pytm threats? They're in threats.json together with the code. I would really like to avoid adding elements for the sake of adding. Unless they bring something unique and useful, they can still be expressed as Elements, with additional attributes created on the fly, or extended in a local library.

Agree with you Izar. Haven't added them just for the sake of it. These are most frequently used elements in modern day apps and have specific threats associated to it. Will add them shortly.

[raphaelahrens]

For Pub/Sub brokers this paper has a good summary of threats on page 11.

The threats are

• Masquerading: spoofing the source of a message caused by unrestricted publishing or directly by the broker.
• Eavesdropping: infodisclosure caused by unrestricted subscriptions or by the broker.
• Replay: caused by eavesdropping + missing freshness, either by the broker or the client
• Flooding: DoS via publishing.
• Thrashing: DoS via subscribing.
• Blackhole: the broker drops message into /dev/null
• Corruption: tampering by the broker.

[gandhirajan]

@izar @raphaelahrens Thanks for your inputs... I am in the process of associating threats to the respective elements like Gateway, MessageQueue and testing them... Will update the changes by end of coming week. Thanks again.

[gandhirajan]

@izar @raphaelahrens updated the threats for the respective elements. Please review.

[gandhirajan]

@izar @raphaelahrens Did you got a chance to look at the changes? Any feedback?

[izar]

hi, yeah, sorry if i didn't make myself clear - just adding new elements as targets of existing threats is not a very good justification for their addition - if at all it just proves that those new elements are not, indeed, new. If instead you can find threats that use unique attributes of the new elements, that is a different thing. At this time it seems that the existing elements and the flexibility in their naming is enough to cover these proposed new elements.

[gandhirajan]

hi, yeah, sorry if i didn't make myself clear - just adding new elements as targets of existing threats is not a very good justification for their addition - if at all it just proves that those new elements are not, indeed, new. If instead you can find threats that use unique attributes of the new elements, that is a different thing. At this time it seems that the existing elements and the flexibility in their naming is enough to cover these proposed new elements.

@izar Got your point. Will have a check on this.

[izar]

To be explored in the future.

[gandhirajan]

@izar I am still working on this and I see that the pull request is closed. Can I go ahead and submit my changes once they are done or it wont get through?

[izar]

Better to have a new PR with the whole thing - new elements, their rules and documentation.

[raphaelahrens]

@gandhirajan do you have your progress somewhere public, so I can take a look. I still see some value in these additional elements.

Also is is always possible to create a separate python module which would work with pytm.

You could then use it like this

from pytm.pytm import TM, Server, Datastore, Dataflow, Boundary, Actor, Lambda, Data, Classification
from xtm import Vault, Gateway, MessageQueue
....

What currently is a bit cumbersome is to add new threats to the existing threats, since you would need to create a complete new treat.json file. But this is something which could be address in a separate PR, which allows to load multiple threat files.

[gandhirajan]

@gandhirajan do you have your progress somewhere public, so I can take a look. I still see some value in these additional elements.

Also is is always possible to create a separate python module which would work with pytm.

You could then use it like this

from pytm.pytm import TM, Server, Datastore, Dataflow, Boundary, Actor, Lambda, Data, Classification
from xtm import Vault, Gateway, MessageQueue
....

What currently is a bit cumbersome is to add new threats to the existing threats, since you would need to create a complete new treat.json file. But this is something which could be address in a separate PR, which allows to load multiple threat files.

@raphaelahrens Thanks for your response. I have updated changes under https://github.com/izar/pytm/compare/master...gandhirajan:pytm:master I have also added 2 new threats related to gateway resources in threats.json file for your reference. Please let me know if I m on right track to proceed on this for rest of the resources.