Subject: [mile] Courses of action COA

From: Jerome Athias <[email-masked]>
Date: Fri, 20 Dec 2013 11:43:56 +0300

Hi,

I would like, if I may, try to join efforts on this one.

https://github.com/STIXProject/schemas/wiki/Proposal:-Add-Parameter_Observables-field-to-CourseOfAction

Best regards

2013/12/20 Roman D. Danyliw <rdd^@^cert.org>:
> Hello!
>
>
>
> Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines the need
> for a means to specify a predetermined course of action (COA) in the
> Expectation and HistoryItem class.  Five implementation options were
> suggested.  After review, I would propose adoption of a blend of #4 and #5.
>
>
>
> <proposal>
>
> ** Add a class named “DefinedCOA” to Expectation and History Item
>
>
>
>    +-------------------+
>
>    | Expectation       |
>
>    +-------------------+
>
>    | ENUM restriction  |<>--{0..*}--[ Description ]
>
>    | ENUM severity     |<>--{0..*}--[ DefinedCOA  ]
>
>    | ENUM action       |<>--{0..1}--[ StartTime   ]
>
>    | STRING ext-action |<>--{0..1}--[ EndTime     ]
>
>    |                   |<>--{0..1}--[ Contact     ]
>
>    +-------------------+
>
>
>
> DefinedCOA
>
>       Zero or many.  ML_STRING.  A unique identifier meaningful to the
> sender and recipient of this document that references a course of action.
> This class must be present if the action attribute is set to “defined-coa”.
>
>
>
> ** Add an “defined-coa” to @action in Expectation and HistoryItem
>
>
>
> 17.  defined-coa.  Perform a predefined course of action (COA).  The COA is
> named in the DefinedCOA class.
>
> </proposal>
>
>
>
> Examples of this approach would look like the following:
>
>
>
> [Example 1]
>
> <!-- simple example, no details provided -->
>
> <Expectation action="defined-coa">
>
>    <DefinedCOA>Procedure-A</DefinedCOA>
>
>
>
> [Example 2]
>
> <!-- preserves the type of action taken -->
>
> <!-- distinguishes Description from COA easing parsing complexity -->
>
> <Expectation action="watch-and-warning">
>
>    <Description>Do the following ...</Description>
>    <DefinedCOA>Procedure-A</DefinedCOA>
>
>
>
> [Example 3]
>
> <!-- multiple COA requested -->
>
> <Expectation action="defined-coa">
>
>    <DefinedCOA>Procedure-A</DefinedCOA>
>
>    <DefinedCOA>Procedure-B</DefinedCOA>
>
>
>
> Roman
>
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: "Stoecker, Paul" <[email-masked]>
Date: Mon, 23 Dec 2013 15:33:41 +0000

I am always concerned about things like this where there is a provided means of what to do or what actions to take.  

What if the course of action is wrong?  Or worse what if a nefarious person were to put in a IODEF document where the course of action opened them up for an attack?

Is it good to have COA or would it be better to not have a COA and just share the information to detect malicious activity and leave it to the analysts to understand the issue and respond as they see fit?

Sent from my iPhone

> On Dec 20, 2013, at 3:46 AM, "Jerome Athias" <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Harrington, Christopher" <[email-masked]>
Date: Mon, 23 Dec 2013 13:03:24 -0500

I would think that the course of action would be dependent on the
capabilities that the receiving party had. Unless we are talking COA at a
very high level like BLOCK, ALERT, IGNORE, etc.  As an example what would
you send for a COA for a malicious delivery URL? Sending a generic BLOCK COA
would be fine. Sending something like BLOCK AT PROXY wouldn't work since not
everyone has a proxy. Again, situational dependent. 

>From a practitioners standpoint EMC wouldn't be sending a COA for any
indicators that we generate. 

Thanks,

--Chris

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Stoecker, Paul
Sent: Monday, December 23, 2013 10:34 AM
To: Jerome Athias
Cc: [email-masked]; stix-discussion-list Structured Threat Information
Expression/ST
Subject: Re: [mile] Courses of action COA

I am always concerned about things like this where there is a provided means
of what to do or what actions to take.  

What if the course of action is wrong?  Or worse what if a nefarious person
were to put in a IODEF document where the course of action opened them up
for an attack?

Is it good to have COA or would it be better to not have a COA and just
share the information to detect malicious activity and leave it to the
analysts to understand the issue and respond as they see fit?

Sent from my iPhone

>> Ticket #32 (http://tools.ietf.org/wg/mile/trac/ticket/32) outlines 
>> the need for a means to specify a predetermined course of action 
>> (COA) in the Expectation and HistoryItem class.  Five implementation 
>> options were suggested.  After review, I would propose adoption of a
blend of #4 and #5.
>> 
>> 
>> 
>> <proposal>
>> 
>> ** Add a class named "DefinedCOA" to Expectation and History Item
>> 
>> 
>> 
>>   +-------------------+
>> 
>>   | Expectation       |
>> 
>>   +-------------------+
>> 
>> This class must be present if the action attribute is set to
"defined-coa".
>> 
>> 
>> 
>> ** Add an "defined-coa" to @action in Expectation and HistoryItem
>> 
>> 
>> 
>> 17.  defined-coa.  Perform a predefined course of action (COA).  The 
>> COA is named in the DefinedCOA class.
>> 
>> </proposal>
>> 
>> 
>>