Subject: Re: [mile] Splitting the Impact class

From: Daisuke MIYAMOTO <[email-masked]>
Date: Sun, 02 Nov 2014 19:13:59 +0900

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
>