Subject: Re: [mile] IODEFv2 suggestions

From: Daisuke MIYAMOTO <[email-masked]>
Date: Fri, 24 Oct 2014 09:12:08 +0900

Hello,

  From July, my university's incident management system supports 
IODEFv1. (Thank all of you joined the discussion!)

  Currently, outputting my internal data records to IODEF works well. 
But, when I tried to import IODEFv1 request/response into my 
university's system, it found some difficulty that Legadec and Roman 
pointed as follows.

On 2014/07/30 11:19, Roman D. Danyliw wrote:
>> 16. Last but not least, IODEFv1 does not provide a native way to specify the
>> incident type. We can use Impact.type to describe the type of impact, but
>> that is different from the type of the incident itself. For example a denial of
>> service can be caused by different types of incidents (e.g. a DDoS, the
>> exploitation of a vulnerability, a worm, a surge in legitimate requests, a
>> physical outage, a unhandled bug, etc).
>> Even if it is hard to find a proper/generic way to categorize incidents that
>> everybody agrees upon, I think it would be good to add an attribute with an
>> enumeration for it in the Incident class.
>> Potential sources of inspiration:
>> https://www.us-cert.gov/government-users/reporting-requirements
>> http://veriscommunity.net/enums.html#section-actions
>> https://alienvault.bloomfire.com/posts/653702-open-source-security-event-
>> taxonomy/public
>> https://capec.mitre.org/about/index.html (although this might be too
>> detailed) And surely many others.
>> I think it should be possible to assign several categories to an incident,
>> because it is often a combination of several types (e.g. malware and social
>> engineering).
>
> Agreed.  Issue #46, sub-bullet #2 is tracking that some approach to categorize the incidents is necessary.  Your point is well taken that whatever taxonomy or free-form approach that is taken, multiple categories for a given incident should be possible.

　I welcome "Incident type" in IODEFv2, but the enumeration of
the type would be difficult by following reasons.
　(1) the number of type is still increasing.
   (2) variety of the existing types.
    - JPCERT/CC uses phishing, web hijack, malware propagation, scan,
      DoS/DDoS, control system, and other.
    - My univ.’s CERT also needs “spam” for containing spam senders
      as well as JPCERT/CC’s category.
    - Other CERT in different country may use different category.
      For instance, CNCERT may use phishing, DoS, Abnormal domain,
      Defacement, Backdoor, Malware, and Vulnerability.
    - In short, there are much variations.

  Regardless of the enumeration, "Incident type" field is useful.
  Not only for my CERT, but many CERT usually publish periodical 
incident status reports, so this field is useful for statistical
aspect.

  Instead of "Incident type", multiple selections of "Impact type"
is also helpful for us. In such case, I will use "ext-value"
for recording specific incident type as follows.

  <Assessment>
   <Impact type="file" completion="succeeded" />
   <Impact type="ext-value" ext-type="web-hijack-jpcert">
  </Assessment>

Kind regards,
Daisuke

---

From: Lagadec Philippe <[email-masked]>
Date: Fri, 24 Oct 2014 07:22:35 +0000

Hello Daisuke and Roman,

Since my initial message I have been working on a list of incident categories, compiled from several sources and standards. I plan to make a proposal for IODEFv2 soon.
Indeed,  there are many ways to categorize incidents and terminology is always an issue. But if we use a quite extensive list of categories, and if we allow several categories to be selected for an incident (i.e. like tags instead of exclusive categories), then I believe we can cover most use cases in a generic way, and obtain a structured description of the main characteristics of an incident.

Then these categories can be used for various tasks including:
- reporting, statistics, situational awareness
- suggest potential incident responses for each category
- automate impact and risk assessment

Regards,

Philippe.

-----Original Message-----
From: Daisuke MIYAMOTO [mailto:[email-masked]] 
Sent: 24 October 2014 02:12
To: Roman D. Danyliw; 'Lagadec Philippe'; [email-masked]
Subject: Re: [mile] IODEFv2 suggestions

Hello,

  From July, my university's incident management system supports IODEFv1. (Thank all of you joined the discussion!)

  Currently, outputting my internal data records to IODEF works well. 
But, when I tried to import IODEFv1 request/response into my university's system, it found some difficulty that Legadec and Roman pointed as follows.

On 2014/07/30 11:19, Roman D. Danyliw wrote:
>> 16. Last but not least, IODEFv1 does not provide a native way to 
>> specify the incident type. We can use Impact.type to describe the 
>> type of impact, but that is different from the type of the incident 
>> itself. For example a denial of service can be caused by different 
>> types of incidents (e.g. a DDoS, the exploitation of a vulnerability, 
>> a worm, a surge in legitimate requests, a physical outage, a unhandled bug, etc).
>> Even if it is hard to find a proper/generic way to categorize 
>> incidents that everybody agrees upon, I think it would be good to add 
>> an attribute with an enumeration for it in the Incident class.
>> I think it should be possible to assign several categories to an 
>> incident, because it is often a combination of several types (e.g. 
>> malware and social engineering).
>

　I welcome "Incident type" in IODEFv2, but the enumeration of the type would be difficult by following reasons.

  Regardless of the enumeration, "Incident type" field is useful.
  Not only for my CERT, but many CERT usually publish periodical incident status reports, so this field is useful for statistical aspect.

  <Assessment>

Kind regards,
Daisuke

---

From: Daisuke MIYAMOTO <[email-masked]>
Date: Fri, 24 Oct 2014 20:49:45 +0900

Hello Philippe and all,

  Thank you for your response. The category is useful for varous tasks, 
and I'm happy to hear your contributions for supporting it.

 > suggest potential incident responses for each category

  I concur with your opinion. It will be useful for CERT/CSIRT to 
complete incident response. I've got an idea for use of
CAPEC enumeration (along with RFC7203 format), but it was not
easy to input the values until CERT/CSIRT finished the incident
response.

Regards,
Daisuke

---

From: Jerome Athias <[email-masked]>
Date: Fri, 24 Oct 2014 14:30:32 +0200

ETSI GS ISI could be useful as high level before breaking down to
(STIX) CAPEC/CWE

2014-10-24 13:49 GMT+02:00 Daisuke MIYAMOTO <[email-masked]>:
> Hello Philippe and all,
>
>  Thank you for your response. The category is useful for varous tasks, and
> I'm happy to hear your contributions for supporting it.
>
>  I concur with your opinion. It will be useful for CERT/CSIRT to complete
> incident response. I've got an idea for use of
>> Since my initial message I have been working on a list of incident
>> categories, compiled from several sources and standards. I plan to make a
>> proposal for IODEFv2 soon.
>> Indeed,  there are many ways to categorize incidents and terminology is
>> always an issue. But if we use a quite extensive list of categories, and if
>> we allow several categories to be selected for an incident (i.e. like tags
>> instead of exclusive categories), then I believe we can cover most use cases
>> in a generic way, and obtain a structured description of the main
>> characteristics of an incident.
>>
>>    From July, my university's incident management system supports IODEFv1.
>> (Thank all of you joined the discussion!)
>>
>> But, when I tried to import IODEFv1 request/response into my university's
>> system, it found some difficulty that Legadec and Roman pointed as follows.
>>
>>> Agreed.  Issue #46, sub-bullet #2 is tracking that some approach to
>>> categorize the incidents is necessary.  Your point is well taken that
>>> whatever taxonomy or free-form approach that is taken, multiple categories
>>> for a given incident should be possible.
>>
>>
>>    Not only for my CERT, but many CERT usually publish periodical incident
>> status reports, so this field is useful for statistical aspect.
>>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile