Assumptions allow you to document constraints like "the backend is secure". Assumptions can also affect the risk calculation: for example, you can specify that the attack feasibility is always "very low" and connect that assumption with threats that you have identified for the backend.
Asset identification is related to a special entity called "security goals". After you have modeled your system (or a part of it), you have to decide for each system element, if breaking one or multiple security attributes (e.g. Confidentiality, Integrity, Availability or Authenticity) of the system element might cause damage. If this is the case, [...]
You can do this in the Assessment Model. For example, by default the propagated damage is decreased if it is distributed to multiple independent elements. If you would like to disable damage distribution, you will have to override the default damage adjustment. This can be done in the Assessment Model. Go to “damage aggregators” and [...]
We don’t allow that Threats act on Data element directly, because we consider them “intangible”. Data can only be threatened during transmission or when it is physically stored somewhere. Thus, Threats may only act on a Component, or Data Flow (or Channel in the future). It then automatically affects the transferred Data. However, this has [...]
Yes, you can. The mechanism is similar to how you semi-automate the creation of Security Goals and Threats: create or go to an existing Model Assessment chunk and select the corresponding “risk assessment query”: Risk query The Risk query was made for the “one-Risk-per-Threat” way of thinking (see above). Note that you can [...]
We have observed two different ways of thinking about Risks: if damage is in the focus, people prefer to define Risks based on Security Goals, if attack paths and likelihood is in the focus, people prefer Threats. We think that it makes sense to have one Risk for several related elements so that reports become [...]