[ISM3 Users] Tuesday Insight: Threat Taxonomy

[Alex Hutton]

Hello All,

> While some will argue that the mechanism of the threat is important, I
> don't think it is always necessary.

I completely agree.

Information needed when studying Threat Communities depends on purpose
of study and level of abstraction required to be accurate.  As an
example, in FAIR risk analysis we define Threats to be "that which can
act against us".

Usually we start categorizing Threats similarly to Anthongy - by
whether they are inside or outside the trust of the organization
(Internal or External).  Then we simply use estimates of their
abilities compared to the overall population in a distribution in
calculation of how "vulnerable" we are to the Threat.  That percentile
rating is compared to another population distribution rating
concerning the control strength of the asset or controls within
context of the entire business process.

So for example, an External Technical Professional threat may have a
Capability rating of the top 90th percentile or above.  Internal
Non-Technical Amateur may have a Capability rating of the 60th
percentile.

If we believe that the strength of the organizations controls are in
the 80th percentile - then we are not so much "vulnerable" to the
Internal Non-Technical Amateur.  But when faced with the capabilities
of the External Technical Professional, they have a much better
probability of a successful attack.

The method simplifies the needed information while maintaining the
integrity of the desiderata (in a Jaynesian sense) used for risk.

In terms of the Threat Action - we divorce ourselves from "use of
exploit" (it's no longer needed in risk analysis due to the use of
population distributions, above) and that allows us to focus on the
intended action of a successfull incident - which is simplified into
the following categories:

Access
Misuse
Disclose
Modify
Deny

This action information is used only to create relevant loss estimates
for the six forms of incident loss (and even then we rearely operate
at that level of abstraction).

In terms of asking this question:

"Is it necessary to analyze every
> single way, or is it better to design and protect the systems in a way
> that makes it resilient to any threat?"

The answer would be to simply match the most probable Threat Community
with it's most probable action, and compare that to the current state
of controls.  A Force Mejeuer is most likely to "deny" for example -
so developing a bcp for the business process, training and practicing
an incident, and hosting the  necessary assets at a hot site should
increase the control strength of the organizations process to above
that of the natural force applied.


On 6/11/07, Vicente Aceituno <vac at zenobia.es> wrote:
> I haven't been able to find a good and commonly accepted threat taxonomy.
>
> A threat causes harm sometimes helped by a weakness, sometimes impeded
> by a countermeasure.
>
> A threat has an agent, a mechanism and consequences for an information
> system or repository.
>
> Using agent and consequences for classification, threats can be
> classed as Errors (unintentional human action), Attacks (intentional
> human action) and Accidents (&Disasters) (non-human action).
>
> The consequences of an Attack, Error or Accident can be:
>
> 1 Failure to destroy of repositories or messages
> 2 Destruction or Loss of repositories or messages
> 3 Theft of repositories or messages
> 4 Interruption of repositories or messages
> 5 Corruption of repositories or messages
> 6 Outdated repositories or messages
> 7 Unauthorized access, Disclosure of repositories or messages
> 8 Improper use of authorized access of repositories or messages
> 9 Improper recording of access to services, channels or interfaces
> 10 Failure to stop services, channels or interfaces
> 11 Destruction or Loss of services, channels or interfaces
> 12 Eavesdropping of services, channels or interfaces
> 13 Underperformance or Interruption of services, channels or interfaces
> 14 Corruption of services, channels or interfaces
> 15 Unauthorized use of services, channels or interfaces
> 16 Improper use of authorized access of services, channels or interfaces
> 17 Improper recording of use of services, channels or interfaces
> 18 Aging of services, channels or interfaces
>
> While some will argue that the mechanism of the threat is important, I
> don't think it is always necessary. There are hundreds of different
> and subtle ways to attack a system. Is it necessary to analyze every
> single way, or is it better to design and protect the systems in a way
> that makes it resilient to any threat?
>
> For example a good backup process can protect any system from several
> of these threats...
>
> My best
>
> Vicente
> _______________________________________________
> Users mailing list
> Users at ism3.com
> http://lists.ism3.com/mailman/listinfo/users
>