[ISM3 Users] Tuesday Insight: Threat Taxonomy
Anup Narayanan
anupnarayanan at gmail.com
Sun Sep 23 19:13:22 CEST 2007
Hi Scott,
I will be interested in this conference call.
I agree with Vince when he says, the ways and means by which a threat may
materialize is unimportant because if you were to spend time analyzing this,
it would consume time, energy and resources without ever coming to a
concrete list of causes for threats?
Vince, a couple of queries?
When you use the word "agent", is it the same as "vulnerabilities" ? This
clarification will be useful for ISO 27001 implementers
When you use the word "consequence", is it equivalent to "impact"? I think
this clarification too will be useful for ISO 27001 implementers
Warm regards,
Anup
-----Original Message-----
From: users-bounces at ism3.com [mailto:users-bounces at ism3.com] On Behalf Of
Scott L. Mitchell
Sent: Friday, September 21, 2007 9:31 AM
To: ISM3 Users discussion list
Subject: Re: [ISM3 Users] Tuesday Insight: Threat Taxonomy
Vicente,
This is very thoughtful.
Did anyone else contribute to the threat taxonomy? Is anyone interested
in holding a conference call to figure this out?
Best,
== slm ==
-----Original Message-----
From: users-bounces at ism3.com [mailto:users-bounces at ism3.com] On Behalf
Of Vicente Aceituno
Sent: Monday, June 11, 2007 9:30 AM
To: users at ism3.com
Subject: [ISM3 Users] Tuesday Insight: Threat Taxonomy
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
_______________________________________________
Users mailing list
Users at ism3.com
http://lists.ism3.com/mailman/listinfo/users
More information about the Users
mailing list