Subject: Re: [mile] Splitting the Impact class

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 10 Nov 2014 05:39:10 +0900

Hello Roman, Daisuke, and all,

I like the idea of splitting the Impact@type into two, i.e.,
IncidentCategory and SystemImpact.

Three comments on this issue.

1) I also think the category is different for each organization, so it is
fine to have free text field for the IncidentCategory.
   In this case, I hope the main body text of the IODEF-bis will have some
example categories.
   Without proper navigation (or examples), this field will be used totally
differently by users. That makes it difficult to analyze the IODEF documents
accumulated inside an archive. (sometimes some researchers wish to analyze
the trend of incidents by analyzing IODEF documents.)

2) For me, the SystemImpact is also one type of categorization; I mean,
SystemImpact categorizes information from the standpoint of the objectives
of the attacks.
   I think the objectives of attacks will alter little with time, so I like
the idea of using enum value (not the free text) for the value of
SystemImpact class.

3) Eventually, where are these new classes placed? I might have
misunderstood, but are they going to become the attributes or elements
inside the Impact class?

Thank you.

Take

2014-11-02 19:13 GMT+09:00 Daisuke MIYAMOTO <[email-masked]>:
> Hello Romain and all,
>
>  In my opinion, (a) incident category, will directly enrich
> the current incident response operation.
>  For clarification, here describes my understanding about (a),
> and please correct it if anyone finds my misunderstanding.
>
> (Existing) Impact type
> It is continue to be existing. New enumeration techniques (list of
> incidents, by Philippe?) will be useful for describing this part.
>
> (New) Incident category
> It will help reporting statistics about incidents. It will also suppress
> such problems that an organization often wants to categorize incidents
along
> with his/her national CERT, even though its category is usually different
> from IODEF. (e.g., my university in Japan wants to categorize with
Japanese
> CERT’s criteria that are different from IODEF.)
>
>  For (b), SystemImpact class, seems to be useful. The notification the
> attacker’s aim/tactics will give a good hints for incident response and
> facilitate the automation of the incident response.
>
> Kind regards,
> Daisuke
>
>
> On 2014/10/29 5:03, Roman D. Danyliw wrote:
>>
>> Hello!
>>
>> Issue #10 [1] is tracking the need to review the completeness of the
>> Impact@type attribute.  Examining the current write-up and the
discussions
>> on the mailing list [2] [3], it seems to me that this attribute is
serving
>> two purposes -- (a) as the incident category and (b) as a description of
the
>> technical impact to a given system based on the tactics/attack vector
>> described in the Method class.  Should we perhaps encode distinct classes
of
>> information into separate elements/attributes?
>>
>> The feedback on using Impact@type attribute for purpose (a), as an
>> incident category, is that everyone has a different scheme of
>> categorization.  My proposal to this use is that we should make a new
class
>> or attribute named IncidentCategory and it would just be a text field,
not
>> an enumerated value.
>>
>> To address use (b), a class to describe the technical impact to system
>> based on the tactics/attack vector described in the Method class, I would
>> proposed a new set of enumerated values.  For simplicity, perhaps also
>> renamed the Impact class to be SystemImpact.  The values I would envision
>> would be:
>>
>> <t>takeover-account.  Control was taken of a given account (e.g., a
social
>> media account).</t>
>> <t>takeover-service.  Control was taken of a given service (e.g.,
>> xxx).</t>
>> <t>takeover-system.  Control was taken of a given system.</t>
>> <t>cps-manipulation. A cyber physical system was manipulated. </t>
>> <t>cps-damage. A cyber physical system was damaged. </t>
>> <t>availability-data. Access to particular data was degraded or
>> denied.</t>
>> <t>availability-account.  Access to an account was degraded or
denied.</t>
>> <t>availability-service. Access to a service was degraded or denied.</t>
>> <t>availability-system.  Access to a system was degraded or denied.</t>
>> <t>damaged-system.  Hardware on a system was irreparably damaged.</t>
>> <t>damaged-data. Data on a system was deleted.</t>
>> <t>breach-proprietary.  Sensitive or proprietary information was accessed
>> or exfiltrated.</t>
>> <t>breach-privacy.  Personally identifiable information was accessed or
>> exfiltrated.</t>
>> <t>breach-credential.  Credential information was accessed or
>> exfiltrated.</t>
>> <t>breach-configuration.  System configuration or data inventory was
>> access or exfiltrated.</t>
>> <t>integrity-data.  Data on the system was modified.</t>
>> <t>integrity-configuration. Application or system configuration was
>> modified.</t>
>> <t>integrity-hardware.  Firmware of a hardware component was
modified.</t>
>> <t>traffic-redirection. Network traffic on the system was redirected</t>
>> <t>monitoring-traffic. Network traffic emerging from a host was
>> monitored.</t>
>> <t>monitoring-host.  System activity (e.g., running processes,
keystrokes)
>> were monitored.</t>
>> <t>policy. Activity violated the system owner's acceptable use
policy.</t>
>>
>> Would this approach be more useful for the community?  Is there backward
>> compatibility issues we need to consider as this will break the IODEF v1
>> model?
>>
>> If the community likes this approach, what additional enumerated values
>> should be included?
>>
>> Roman
>>
>> [1] http://trac.tools.ietf.org/wg/mile/trac/ticket/10
>> [2] http://www.ietf.org/mail-archive/web/mile/current/msg01526.html
>> [3] http://www.ietf.org/mail-archive/web/mile/current/msg01509.html
>>
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile
>>
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

-- 
--
Takeshi Takahashi, Ph.D.
+81 80 3490 2971
http://www.taketaka.com/

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Sun, 9 Nov 2014 21:30:52 +0000

Hello!

Thank you for the feedback. I'll have the -10 draft in the archive tonight after submissions are again accepted with a candidate implementation.

As to the specifics ...

> On Nov 9, 2014, at 1:42 PM, Takeshi Takahashi <[email-masked]> wrote:
> 

I completely agree. The new IncidentCategory class will be free-form to support the flexibility described above. My thinking would be to add text to the implementation draft discussing what to put here. If we wanted to be really ambitious maybe a way to reference a consortium specific set of categories.

> the idea of using enum value (not the free text) for the value of

Agreed. The SystemImpact will be enumerated as described below. Any more categories to add?

> misunderstood, but are they going to become the attributes or elements

I wasn't clear earlier. My thinking was to deprecate the current Impact class in favor these two new ones both in Assessment. Do we still need the current Impact class?

> Take

Regards,
Roman

>> CERT's criteria that are different from IODEF.)
>> 
>> attacker's aim/tactics will give a good hints for incident response and

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 10 Nov 2014 06:57:17 +0900

Thank you very much for your answers.
Things are clear to me.

>> 1) I also think the category is different for each organization, so it 
>> is fine to have free text field for the IncidentCategory.
>>   In this case, I hope the main body text of the IODEF-bis will have 
>> some example categories.
>>   Without proper navigation (or examples), this field will be used 
>> totally differently by users. That makes it difficult to analyze the 
>> IODEF documents accumulated inside an archive. (sometimes some 
>> researchers wish to analyze the trend of incidents by analyzing IODEF 
>> documents.)
>> 
>
> I completely agree. The new IncidentCategory class will be free-form to
support the >flexibility described above. My thinking would be to add text
to the implementation
> draft discussing what to put here. If we wanted to be really ambitious
maybe a way to >reference a consortium specific set of categories.

This is a good idea to put the guidance information inside the
implementation draft or guidance draft.

>> 2) For me, the SystemImpact is also one type of categorization; I 
>> mean, SystemImpact categorizes information from the standpoint of the 
>> objectives of the attacks.
>>   I think the objectives of attacks will alter little with time, so I 
>> like the idea of using enum value (not the free text) for the value of 
>> SystemImpact class.
>> 
>

Let me think about it until tomorrow's MILE session.

> I wasn't clear earlier. My thinking was to deprecate the current Impact
class in favor these two new ones both in Assessment. Do we still need the
current Impact class?

I agree the location you propose. In that case, I think we do not need the
current Impact class.

Thank you very much for your dedicated contributions all the time.

Kind regards,
Take

-----Original Message-----
From: Roman D. Danyliw [mailto:[email-masked]] 
Sent: Monday, November 10, 2014 6:31 AM
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

Hello!

Thank you for the feedback. I'll have the -10 draft in the archive tonight
after submissions are again accepted with a candidate implementation.

As to the specifics ...

> 1) I also think the category is different for each organization, so it 
> is fine to have free text field for the IncidentCategory.
>   In this case, I hope the main body text of the IODEF-bis will have 
> some example categories.
>   Without proper navigation (or examples), this field will be used 
> totally differently by users. That makes it difficult to analyze the 
> IODEF documents accumulated inside an archive. (sometimes some 
> researchers wish to analyze the trend of incidents by analyzing IODEF 
> documents.)
> 

I completely agree. The new IncidentCategory class will be free-form to
support the flexibility described above. My thinking would be to add text to
the implementation draft discussing what to put here. If we wanted to be
really ambitious maybe a way to reference a consortium specific set of
categories.

> 2) For me, the SystemImpact is also one type of categorization; I 
> mean, SystemImpact categorizes information from the standpoint of the 
> objectives of the attacks.
>   I think the objectives of attacks will alter little with time, so I 
> like the idea of using enum value (not the free text) for the value of 
> SystemImpact class.
> 

Agreed. The SystemImpact will be enumerated as described below. Any more
categories to add?

> misunderstood, but are they going to become the attributes or elements 

I wasn't clear earlier. My thinking was to deprecate the current Impact
class in favor these two new ones both in Assessment. Do we still need the
current Impact class?

Regards,
Roman

>>  In my opinion, (a) incident category, will directly enrich the 
>> current incident response operation.
>>  For clarification, here describes my understanding about (a), and 
>> please correct it if anyone finds my misunderstanding.
>> 
>> (Existing) Impact type
>> It will help reporting statistics about incidents. It will also 
>> suppress such problems that an organization often wants to categorize 
>> incidents
> along
>> with his/her national CERT, even though its category is usually 
>> different from IODEF. (e.g., my university in Japan wants to 
>> categorize with
> Japanese
>>  For (b), SystemImpact class, seems to be useful. The notification 
>> the attacker's aim/tactics will give a good hints for incident 
>> response and facilitate the automation of the incident response.
>> 
>> Kind regards,
>> Daisuke
>> 
>> 
>>> technical impact to a given system based on the tactics/attack 
>>> vector described in the Method class.  Should we perhaps encode 
>>> distinct classes
> of
>>> To address use (b), a class to describe the technical impact to 
>>> system based on the tactics/attack vector described in the Method 
>>> class, I would proposed a new set of enumerated values.  For 
>>> simplicity, perhaps also renamed the Impact class to be 
>>> SystemImpact.  The values I would envision would be:
>>> 
>>> xxx).</t> <t>takeover-system.  Control was taken of a given 
>>> system.</t> <t>cps-manipulation. A cyber physical system was 
>>> manipulated. </t> <t>cps-damage. A cyber physical system was 
>>> damaged. </t> <t>availability-data. Access to particular data was 
>>> degraded or denied.</t> <t>availability-account.  Access to an 
>>> account was degraded or
> denied.</t>
>>> <t>availability-service. Access to a service was degraded or 
>>> denied.</t> <t>availability-system.  Access to a system was degraded 
>>> or denied.</t> <t>damaged-system.  Hardware on a system was 
>>> irreparably damaged.</t> <t>damaged-data. Data on a system was 
>>> deleted.</t> <t>breach-proprietary.  Sensitive or proprietary 
>>> information was accessed or exfiltrated.</t> <t>breach-privacy.  
>>> Personally identifiable information was accessed or exfiltrated.</t> 
>>> exfiltrated.</t> <t>breach-configuration.  System configuration or 
>>> data inventory was access or exfiltrated.</t> <t>integrity-data.  
>>> Data on the system was modified.</t> <t>integrity-configuration. 
>>> Application or system configuration was modified.</t> 
>>> <t>traffic-redirection. Network traffic on the system was 
>>> redirected</t> <t>monitoring-traffic. Network traffic emerging from 
>>> a host was monitored.</t> <t>monitoring-host.  System activity 
>>> (e.g., running processes,
> keystrokes)
>>> were monitored.</t>
>>> Would this approach be more useful for the community?  Is there 
>>> backward compatibility issues we need to consider as this will break 
>>> the IODEF v1 model?
>>> 
>>> If the community likes this approach, what additional enumerated 
>>> values should be included?
>>> 
>>> Roman
>>>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 11 Nov 2014 04:54:47 +0000

+1.
I think the categories of the new IncidentCategory class cover the vast majority of the case.
Panos

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Sunday, November 09, 2014 4:57 PM
To: 'Roman D. Danyliw'
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

>> 1) I also think the category is different for each organization, so 
>> it is fine to have free text field for the IncidentCategory.
support the >flexibility described above. My thinking would be to add text to the implementation

This is a good idea to put the guidance information inside the implementation draft or guidance draft.

>> like the idea of using enum value (not the free text) for the value 
>> of SystemImpact class.
>> 
>
categories to add?

>> misunderstood, but are they going to become the attributes or 
>> elements inside the Impact class?
>> 
>
class in favor these two new ones both in Assessment. Do we still need the current Impact class?

I agree the location you propose. In that case, I think we do not need the current Impact class.

Kind regards,
Take

-----Original Message-----
From: Roman D. Danyliw [mailto:[email-masked]]
Sent: Monday, November 10, 2014 6:31 AM
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

Hello!

As to the specifics ...

Regards,
Roman

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 11 Nov 2014 18:22:30 +0900

+1 to the comment that the new IncidentCategory class covers the vast
majority of the case.

Take

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Panos Kampanakis
(pkampana)
Sent: Tuesday, November 11, 2014 1:55 PM
To: 'Roman D. Danyliw'
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

+1.
I think the categories of the new IncidentCategory class cover the vast
majority of the case.
Panos

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Sunday, November 09, 2014 4:57 PM
To: 'Roman D. Danyliw'
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

categories to add?

Kind regards,
Take

-----Original Message-----
From: Roman D. Danyliw [mailto:[email-masked]]
Sent: Monday, November 10, 2014 6:31 AM
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

Hello!

As to the specifics ...

Regards,
Roman

---

From: Daisuke MIYAMOTO <[email-masked]>
Date: Wed, 12 Nov 2014 05:56:49 +0900

Of course, +1!

---

From: Lagadec Philippe <[email-masked]>
Date: Mon, 17 Nov 2014 10:16:50 +0000

Hello,

First, I agree we need two separate classes for the incident categories, and the impact(s) assessment.
Incident categories = description of what happened
Impact assessment = description of the consequences of the incident

But to make it really useful when several partners exchange information about incidents, I think they need to speak the same language.
If incident category is only a free text field, then it will not be very useful. (BTW, a ML_STRING field can only have a single value for a given language, according to section 6 of the RFC)

Just like system impact, we can have an enumeration which should cover most cases.
As mentioned earlier, I am building one based on several existing sources and standards. It is not perfect, but I think it maps quite well most of the custom or standard enumerations I have seen so far.
I will send it in a separate message.

Moreover, I would like to know why the extension mechanism for enumerations (ext-type) was removed. Maybe I missed the discussion about it.
To me, it was a simple and effective way to support custom values that are useful in a specific deployment, when the senders and recipients agree on their meaning. 
>From my understanding, using the IANA registry procedure is good to allow the community to extend enumerations over time, but it does not cover the case when we just need to use custom values in a specific community.
I thought we could have both the IANA registry and the ext-type mechanism, for different purposes.

Regards,

Philippe.

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: 09 November 2014 22:31
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

Hello!

As to the specifics ...

Regards,
Roman

---

From: Lagadec Philippe <[email-masked]>
Date: Wed, 19 Nov 2014 15:24:31 +0000

Hello all,

Attached is a list of incident categories that I would like to propose for a new enumeration in IODEFv2.
There is no perfect way to categorize incidents that will satisfy everybody, but we can at least give it a try.

This is a list I built by merging and adapting incident category enumerations from various standards and sources, including:

- FIRST cases: http://www.first.org/_assets/resources/guides/csirt_case_classification.html

- US-CERT: https://www.us-cert.gov/government-users/reporting-requirements (categories currently used in STIX 1.1.1: http://stixproject.github.io/data-model/1.1.1/stixVocabs/IncidentCategoryVocab-1.0/)

- VerIS: http://veriscommunity.net/enums.html#section-actions

- and a few others.

As mentioned in the file:

- It is assumed that one incident can be tagged with one or several categories, so they are not mutually exclusive.								
- These categories are meant to provide a high-level, structured and common description of a cyber incident. Categories may be related to the cause of the incident, the techniques used by attackers or the impact of the incident. Each category may lead to different incident response procedures.

Note: the intent is not to replace the impact assessment type enumeration. It is just that sometimes a category is both an attack technique and an impact type, for example "denial of service".

- Categories are grouped into two levels: The main categories have no slash in their name (white cells). The second-level categories with a slash in their name (grey cells) are more specific, to give more information about an incident if possible. Second-level categories are "contained" in the main category starting with the same name. For example, "Malware/Worm" is part of "Malware".	

Regards,

Philippe.							

-----Original Message-----
From: Lagadec Philippe 
Sent: 14 November 2014 17:12
To: 'Roman D. Danyliw'; Takeshi Takahashi
Cc: [email-masked]
Subject: RE: [mile] Splitting the Impact class

Hello,

First, I agree we need two separate classes for the incident categories, and the impact(s) assessment.
Incident categories = description of what happened Impact assessment = description of the consequences of the incident

Regards,

Philippe.

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: 09 November 2014 22:31
To: Takeshi Takahashi
Cc: [email-masked]
Subject: Re: [mile] Splitting the Impact class

Hello!

As to the specifics ...

Regards,
Roman

---

From: Daisuke MIYAMOTO <[email-masked]>
Date: Fri, 21 Nov 2014 01:55:44 +0900

Hello!

  It is very interesting, but this discussion is
little-bit confusing, so can I clarify it for me?

----------------------------------------------------
(1) In RFC5070, ImpactType class is available for
  the category of technical impact of incidents.

(2) New categorization is discussed since a "local"
categories dit not fit to the ImpactType Class.

(3) My (mis)understanding can be shown at:
http://www.ietf.org/mail-archive/web/mile/current/msg01535.html

  There are three types of describing the category.
   - ImpactType class
      ** this class is still available. (** this was my misunderstanding)
   - IncidentCategory class
      - this is new class for explaining incident in plain text
   - SystemImpact class
      - this is new class for describing technical impact

(4) The current version of RFC5070-bis says.

   - ImpactType class
      ** this class will be obsoleted.

   - IncidentCategory class
   - SystemImpact Class
----------------------------------------------------

  According to the attached XLS files, Lagapedec's approach
aims at improving the categorization schemes, and it seems
to be succeeding. At least, this will help my CERT/CSIRT
operation in my country. (In other words, a local incident
category in Japan may fit to the proposed category.)

 > It is assumed that one incident can be tagged with one or several 
categories, so they are not mutually exclusive.	

  I agree. Current malicious campaign sends malware with social 
engineering. In such case, I want to describe it with "malware" and
"social engineering".

  There are some unclear points as follows.

(1) How about other operators? Does it fit to your operation?

(2) How to describe "Other" in Lagadec's incident category) ?
   The easiest way is use of "ext-" value or text format

(3) There might be two ways for organize the categories.

Plan (A)
  Impact Class (enumeration)
  IncidentCategory Class (text)
  SystemImpact Class (enumeration)

Plan (B)
  IncidentCategory Class (enumeration)
  SystemImpact Class (enumeration)

  Which is better for us?

Kind regards
Daisuke

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 26 Nov 2014 11:58:11 +0900

Hi Lagadec, Daisuke, and all,

Thank you very much for raising this issue here.

As an individual:

I might have forgotten some discussion, but my understanding is that the editors has chosen to have "maximum flexibility" for the IncidentCategory field based on the feedbacks from the community.
They made the field a free text field so that users can write categories at their disposal.
That is what I understand; at least, Roman has spared enough time for us to review, and no objection was raised until now.
Using the "-ext" approach is fine if the use of the "-ext" is rare.
I like the way how IODEFv1 prepared allowed enum values and free texts using the "-ext" value, but I would like to respect the result of the discussion.

Having said that, I would like to ask another proposal (in addition to the two choices Daisuke has proposed in the email below) here;

We could have another draft that describes the taxonomy.
While we keep the IncidentCategory Class to be a free text field, the texts in the IODEF-bis RFC can say that we recommend to use the taxonomy mentioned in the taxonomy draft.
So, users can write free text, or some words described in the taxonomy draft, or the identifiers of the words (e.g., taxonomy-draft:35)
(Users who wish to automatically process the IODEF document should use the taxonomy.)

In this way, we could keep the IODEF-bis draft concise.

As a co-chair:

All, please note that the IODEF-bis will be reaching the stage of the WGLC before the next meeting.
So, if you have any comments, please kindly share it on the list ASAP.

Kind regards,
Take

> From: Daisuke MIYAMOTO [mailto:[email-masked]]
> Sent: Friday, November 21, 2014 1:56 AM
> To: Lagadec Philippe; Roman D. Danyliw; Takeshi Takahashi; [email-masked]
>   It is very interesting, but this discussion is little-bit confusing, so can
> I clarify it for me?
> 
>   According to the attached XLS files, Lagapedec's approach aims at improving
> the categorization schemes, and it seems to be succeeding. At least, this will
> help my CERT/CSIRT operation in my country. (In other words, a local incident
>   I agree. Current malicious campaign sends malware with social engineering.
> In such case, I want to describe it with "malware" and "social engineering".
> 
> > This is a list I built by merging and adapting incident category enumerations
> from various standards and sources, including:
> >
> > - FIRST cases:
> > http://www.first.org/_assets/resources/guides/csirt_case_classificatio
> > n.html
> >
> > - US-CERT:
> > https://www.us-cert.gov/government-users/reporting-requirements
> > (categories currently used in STIX 1.1.1:
> > http://stixproject.github.io/data-model/1.1.1/stixVocabs/IncidentCateg
> > oryVocab-1.0/)
> >
> > - These categories are meant to provide a high-level, structured and common
> description of a cyber incident. Categories may be related to the cause of the
> incident, the techniques used by attackers or the impact of the incident. Each
> category may lead to different incident response procedures.
> >
> > Note: the intent is not to replace the impact assessment type enumeration.
> It is just that sometimes a category is both an attack technique and an impact
> type, for example "denial of service".
> >
> > - Categories are grouped into two levels: The main categories have no slash
> in their name (white cells). The second-level categories with a slash in their
> name (grey cells) are more specific, to give more information about an incident
> if possible. Second-level categories are "contained" in the main category
> starting with the same name. For example, "Malware/Worm" is part of "Malware".
> 
> >
> > Regards,
> >
> > Philippe.
> >
> > Incident categories = description of what happened Impact assessment =
> > description of the consequences of the incident
> >
> > But to make it really useful when several partners exchange information about
> incidents, I think they need to speak the same language.
> > If incident category is only a free text field, then it will not be
> > very useful. (BTW, a ML_STRING field can only have a single value for
> > a given language, according to section 6 of the RFC)
> >
> > As mentioned earlier, I am building one based on several existing sources
> and standards. It is not perfect, but I think it maps quite well most of the
> custom or standard enumerations I have seen so far.
> > Moreover, I would like to know why the extension mechanism for enumerations
> (ext-type) was removed. Maybe I missed the discussion about it.
> > To me, it was a simple and effective way to support custom values that are
> useful in a specific deployment, when the senders and recipients agree on their
> meaning.
> >>From my understanding, using the IANA registry procedure is good to allow
> the community to extend enumerations over time, but it does not cover the case
> when we just need to use custom values in a specific community.
> the implementation draft discussing what to put here. If we wanted to be really
> ambitious maybe a way to reference a consortium specific set of categories.
> >
> >
> >>    I think the objectives of attacks will alter little with time, so
> >> I like the idea of using enum value (not the free text) for the value
> >> of SystemImpact class.
> >>
> >
> > I wasn't clear earlier. My thinking was to deprecate the current Impact class
> in favor these two new ones both in Assessment. Do we still need the current
> Impact class?
> >
> >> Thank you.
> >>
> >> Take
> >>
> >
> > Regards,
> > Roman
> >
> >
> >>
> >>> suppress such problems that an organization often wants to
> >>> categorize incidents
> >> along
> >>>> Issue #10 [1] is tracking the need to review the completeness of
> >>>> the Impact@type attribute.  Examining the current write-up and the
> >> discussions
> >>>> denied.</t> <t>availability-system.  Access to a system was
> >>>> degraded or denied.</t> <t>damaged-system.  Hardware on a system
> >>>> was irreparably damaged.</t> <t>damaged-data. Data on a system was
> >>>> Personally identifiable information was accessed or
> >>>> exfiltrated.</t> <t>breach-credential.  Credential information was
> >>>> accessed or exfiltrated.</t> <t>breach-configuration.  System
> >>>> configuration or data inventory was access or exfiltrated.</t>
> <t>integrity-data.
> >>>> backward compatibility issues we need to consider as this will
> >>>> break the IODEF v1 model?
> >>>>