How are "target" and its relevant "condition" extracted from a particular threat?

[amrmp]

I've been looking at the source code and trying to automate the logic extraction from the threat information. I've got a couple of questions:

• How was the initial threats file produced? In other words, for "Flooding" in threats.json, how were the attributes for the "target" and "condition" extracted? Can you please put me in the right direction? Is this a personal interpretation of the CAPEC information?
• So, for example, the "Flooding" attack is a parent of "TCP Flood," "UDP Flood," and so on. I wonder if one can use the same logic and prefill the "target" and, to some extent fill the "condition" field? I feel they pretty much inherit the same logic/condition, but of course, someone's expert opinion is really appreciated.
• There are some attacks whose fields such as "severity", "likelihood of attack", "example", or "reference" are missing in CAPEC. I wonder if it was you, how would you fill them cautiously and correctly?

Thank you.

[raphaelahrens]

Hi, how the example threats where created can be answered by @izar . I assume he created them for his needs and added it as an example.

Currently there is no logic for inheriting attributes from other attacks, so you will have to copy the parent threat and modify it. For the UDP and TCP Flooding you first need to know which protocol is used. But currently pytm does only know about the port and not the transport protocol. That means that you cannot always describe which transport protocol you are using. For example syslog over TCP uses the same port as syslog over UDP . So a patch would be needed, so the transport protocol can be specified.

In my opinion the most important information threat modelling gives you is the knowledge of a potential threat. The severity and the likelihood depend on the software and the environment in which the software is used. For example lets assume we have two case where the same software is used. In the first case information processed is not confidential. In another case the information is highly confidential.

What is the severity if we find an information disclosure threat? It depends how we use the Software. In the first case it is not a big issue. In the second it will be a big problem. But thanks to threat modelling you are aware of the potential problem and can make a judgement for each case.

If you don't know the environment in which your software will be used then you can't make this decision. Then you will need to either mitigate just in case someone will use it with sensitive data or you could inform the users of your software about the potential risk. Either way you could not have done any of these actions if you would be unaware of the potential threat.

To conclude the severity and likelihood are very context sensitive and can only be absolute if the context in which the software is executed is fully known. E.g. you run your own software or your users tell you how they use your software.

This is also the reason why you can use different threat libraries, so that you can adapt it to your needs and your users needs.

[izar]

The whole attribute system was kept open and easy to extend on purpose, as there is no way to encompass the whole gamut of options beforehand. The idea is "if a rule needs an attribute, create the attribute and create the rule". At this point logic interaction between attributes outside of rules is almost non-existent, so that doesn't create many ripples. People are free to extend Elements as they see fit and create specialized elements, or to enrich the existing ones.

I agree 100% wich @raphaelahrens on the severity and likelihood comments. In fact this is an area I am actively engaged in these days, and trying to get as much clarity on the boundaries between automated and manual as possible.

[amrmp]

Thanks for your replies, @izar and @raphaelahrens. Looking at your code and the way you extracted the conditions w.r.t. CAPEC is still questioning me.

@izar I believe you considered the "prerequisites" field in conjunction with the "Related Weaknesses" to come up with the "proper" conditions, right?

• If that's the case, some of the threats in your database, do not hold "all" the information about those fields. Are there any explanations for this? I think this can be automated to a great extent for extracting the rules and conditions.
• If not, did you simplify your implementation by focusing on the important conditions?

I think those rules in the "condition" field are more your interpretations about the threat. Am I right?

Thank you, and I look forward to hearing from you.

[izar]

Most of the translation from CAPEC into threats was done by @avhadpooja - she can better give details on the process.

[avhadpooja]

Hi, this is the process I used:

1. Get a CSV file from CAPEC
2. Weed out threats that don't have every column filled i.e. severity/pre-requisites etc. missing
3. Condition and target are not created in an automated way. In order to create a high fidelity threat store for pytm, I manually translated the "pre-requisite" column to create conditions and target according to the elements we had at the time.

hope that helps!