Subject: Re: [mile] Feedback on draft-murillo-mile-cps-00 and implications for 5070bis

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 5 Aug 2014 18:55:50 +0000

Hi Roman,

Comments below. 

For 1) I think it would be worth of having a free form summary.

For 2), I think it could help to have free text field for course of action. I don't think IODEF was intended to focus on mitigations, but a free text field that is option could benefit the receiving parties.

For 3) I think two more attack-categorization enumeration values for System@category and NodeRole@attack-type would also not be a problem.

Agreed on the data from cps that can already be described in IODEF.

Panos

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Thursday, July 31, 2014 2:32 PM
To: [email-masked]; Martin Murillo
Subject: [mile] Feedback on draft-murillo-mile-cps-00 and implications for 5070bis

Hello!

The presentation on draft-multillo-mile-cps-00 at IETF 90 started a discussion on identifying data elements described by cps-00 that might also be relevant to enterprise incident reports.  In my judgment they are at least as follows:

(1) IncidentTitle (Section 5.6) and BriefDescriptionOfIncident (5.23) -- these are classes that quickly summarize the document.  A similar idea was proposed in the bullet #4 of the feedback from the NATO implementation by Lagadec Philippe (http://www.ietf.org/mail-archive/web/mile/current/msg01503.html).  Should we add a "Summary" class similarly defined as the Description class to IODEF-Document, Incident, and EventData?

(2) RecurrencePreventionMeasures (Section 5.22) -- should a free-form text description be added to describe future measures that should be taken to prevent the class of activity described in the document from occurring the future?

(3) EntryPoint (Section 5.15) and CommandAndControlCenters (Section 5.18) -- both of these classes attempt to categorize a system as having a given role in the incident -- entry point into a network by the attacker and the C2 servers of the attacker.  System@category in 5070bis also tries to categorize systems but with these enumerated values: source, target, intermediate, sensor, or infrastructure.  Only one category can be assigned per system.  NodeRole@attack-type is poorly documented (see Issue #40) but it allows for values of c2-server, sink-hole, malware-distribution, phishing, spear-phishing, recruiting, fraudulent-site, and dns-spoof.  

There appears to be a need to classify the intended role victim system independent of the incident, NodeRole@category, but also the role it played in an incident/event especially in categorizing the attacker infrastructure, NodeRole@attack-type/EntryPoint/CommandAndControlCenters.  It seems like we should reconcile these.  In 5070bis, there appears to be overlap between System@category and NodeRole@attack-type.  EntryPoint and CommandAndControlCenters from cps-00 suggest new enumerated values for these attributes (or perhaps for a new one)?

Any strong feelings for adopting these concepts into 5070bis?  I'm thinking all three are useful and easy to implement.

It was also suggested that certain overlap might exist.  Comparing cps-00 with 5070bis-07, I believe certain cps data elements can already be represented without an extension.  They are as follows:

** ReportingParty (Section 5.7) = Incident/Contact@role={reporter, creator}
** ReportReliability (Section 5.8) = {Incident,EventData}/Confidence
** TargetSystem (Section 5.11) = EventData/Flow/System@category="target"/Node/NodeRole
** Exploit (Section 5.14) = Incident/Method
** PerpetratingParty (Section 5.16) = Incident/RelatedActivity
** DetectioMethod (Section 5.17) = EventData/Discovery
** OrganizationalImpact (Section 5.21) = Assessment/{BusinessImpact,MonetaryImpact}
** Logs (Section 5.24) = RecordData

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Martin Murillo <[email-masked]>
Date: Thu, 07 Aug 2014 19:45:56 -0400

I second Panos in his reply to this thread. Some comments below:

> (1) IncidentTitle (Section 5.6) and BriefDescriptionOfIncident (5.23) -- these are classes that quickly summarize the document.  A similar idea was proposed in the bullet #4 of the feedback from th…
Doing it would certainly make IODEF richer w/o being too specific. It 
looks that there's the need of that addition.
> (2) RecurrencePreventionMeasures (Section 5.22) -- should a free-form text description be added to describe future measures that should be taken to prevent the class of activity described in the do…
I think this is applicable to all systems/reports and will make IODEF 
richer.
> ** Logs (Section 5.24) = RecordData

Indeed, overlaps exist and CPS needs to make further use of the already 
existing elements.

The items above need to be definitely reused. However some type of 
extension will still need to be done to express the CPS incident in 
machine readable format. For instance, TargetSystem might actually be a 
PLC that does not have an IP address but an ID or node address; it might 
be communicating through a protocol such as HART, etc.

Or, in an extreme scenario when the attacker knows how to cause damage 
gradually, the target will be the actual variable of an algorithm that 
is running in a RTU/PLC or control system. The specification of these 
will need an extension of appropriate elements that are contextually valid.

That aside, I believe that the more rich 5070 is, the more it will 
leverage the work to be done in other extensions. This will also 
leverage development time.

With regards to CPS, when 5070 can, for example, describe  the 
malfunction of a computer/CPU/etc and a subsequent smoke and the 
automatic enabling of fire extinguishers, all due to the reaching of a 
threshold temperature due to the reconfiguration of the BIOS or drivers 
by a hacker, it will be start being more applicable to CPS systems.

Martin