Subject: Re: [mile] IODEF predicate logic

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 22 Apr 2014 21:14:53 +0000

Hi Roman,

As I am making the updates for version -03, I thought to answer your questions in "**" using "pk>" below:

** What's the semantics of multiple EventData classes into a parent EventData?

pk> To answer it I added 
	"An EventData class that contains multiple EventData classes
		depicts an Event that consists of smaller events. For the parent 
		event to take place, or the the children EventData events SHOULD
		take place."

** What is the difference between annotating a System to be a watchlist-source or watchlist-destination?  In the example XML snippet below, an expression of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created.  How would have using "watchlist-destination" have changed the expression?  Is it that things marked as source warns of inbound connections to a network?

pk> Source and Target mean checking the source or destination of that host. So, they are not just addresses, but they are distinguishing between IP.src and IP.dst.

** Can one create a Flow with a System@category="source" and System@category="watchlist-source"?  If so, what would that mean?

pk> No. To explain it I added 
	"There SHOULD NOT be more than 
		one "source" or "watchlist-source" and one "target" 
		or "watchlist-target" System Nodes per Flow."

** Can one create an EventData with two Flows, one Flow has several System@category="watchlist-source" and another exclusively of several System@category="source"?  If so, what would that mean?

pk> I added the text 
	"An EventData class with multiple 
		Flows means that all the information defined in the 
		flows need to exist for the event described to take place."
	So, both Flow would need to be seen for the event to take place. That is you would need to see a Flow with the "source" and a Flow with either of the "watchlist-sources".

** Do these expressions only apply to the IP address, or other things that can be indicators too?  For example, say I had:

<Flow>
<System category=" watchlist-source">
     <Node>
         <Address>IP1</Address>
         <Service ip_protocol="6"><Port>80</Port></Service>
     </Node>
</System>
<System category=" watchlist-source"><Node><Address>IP2</Address>...</System>
</Flow>
 
Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP1 OR 80) OR IP2)"?  "((IP1 AND 80) OR IP2)?  What I'm asking is what is the parsing rule of multiple indicators in a given Node?

pk> They apply to the whole node. Thus your XML would mean
	((IP.src==IP1) && (src_port=80)) || (IP.src==IP2)

> Different Flow
> classes
> 		that consist of different System classes (with watchlist-source
> 		or destination as attributes) follow AND logic in their parent
> 		EventData Class. "
> in order to make it clearer. Makes more sense?

** The double use of different confuses me also.  Do you mean "Distinct Flow classes with the same parent EventData classes are ANDed together", aka parsing rule (b) from above?

pk> I re-wrote the whole logic to simplify it. The -03 version will be out soon and I encourage you to check it to make sure it makes sense.

Panos

-----Original Message-----
From: Moriarty, Kathleen [mailto:[email-masked]] 
Sent: Monday, December 09, 2013 11:19 AM
To: Roman D. Danyliw; Panos Kampanakis (pkampana); [email-masked]
Subject: RE: IODEF predicate logic

Panos,

I am re-sending this summary of previous questions to the list on the logic included in the IODEF-Guidance so you and others don't have to dig it up.  I think when you include examples, it would be helpful to make sure these questions are addressed with the updated description and logic.  An explanation around each example would be helpful in this section to help implementers with consistency between implementations.

Thanks!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, August 05, 2013 8:02 AM
To: Panos Kampanakis (pkampana); [email-masked]
Subject: Re: [mile] IODEF predicate logic

Hi Panos,

Response inline ...

> -----Original Message-----
> From: Panos Kampanakis (pkampana) [mailto:[email-masked]]
> Sent: Thursday, August 01, 2013 2:56 PM
> To: Roman D. Danyliw; [email-masked]
> Subject: RE: IODEF predicate logic
> 
> Hi Roman,
> 
> Thank you for the comments. I answer them below. ">>>" is in front of 
> your questions.
> 
> >>>  In your email below you used the terminology  "multiple 
> >>> indicators on
> one folder" which I hadn't read before.  Did you mean multiple 
> indicators in a single IODEF document?
> 
> Yes
> 
> >>> Isn't that  reversed, "When an IODEF **System** consists of two or 
> >>> more
> **Node** classes with the category attribute set to watchlist-source 
> or watchlist-destination ...", since Node sub-element of System?
> However, this isn't consistent with the -00 draft since System can 
> only contain exactly 1 node.
> 
> You are right, it wasnot clear. I will rephrase it to something like " 
> When a Flow Class that consists of multiple Systems with
>    watchlist-source and watchlist-destination attributes (watchlist of
>    Systems) the System information should be ORed for the Flow Class
>   described... "
> Looks better?

I'm still having a little bit of trouble.  To reason about it, I listed the interpretation of the example below into a series of parsing rules:

(a) Multiple Systems in a given Flow are combined together into single expression where each IP is OR-ed
(b) Multiple Flow classes in a given EventData are combined into a series of expressions each AND-ed together

Is that right? This leads me to ask the following questions:

** What's the semantics of multiple EventData classes into a parent EventData?

** What is the difference between annotating a System to be a watchlist-source or watchlist-destination?  In the example XML snippet below, an expression of "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)" was created.  How would have using "watchlist-destination" have changed the expression?  Is it that things marked as source warns of inbound connections to a network?

** Can one create a Flow with a System@category="source" and System@category="watchlist-source"?  If so, what would that mean?

** Can one create an EventData with two Flows, one Flow has several System@category="watchlist-source" and another exclusively of several System@category="source"?  If so, what would that mean?

** Do these expressions only apply to the IP address, or other things that can be indicators too?  For example, say I had:

<Flow>
<System category=" watchlist-source">
     <Node>
         <Address>IP1</Address>
         <Service ip_protocol="6"><Port>80</Port></Service>
     </Node>
</System>
<System category=" watchlist-source"><Node><Address>IP2</Address>...</System>
</Flow>
 
Would the expression be "(IP1 OR 80 OR IP2)"? "(IP1 AND 80 AND IP2)"? "((IP1 OR 80) OR IP2)"?  "((IP1 AND 80) OR IP2)?  What I'm asking is what is the parsing rule of multiple indicators in a given Node?

> >>><EventData> ...
> <Flow>
>   <System category=" watchlist-source"> <Node><Address>IP1</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP2</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP3</Address>...
> </System> </Flow> <Flow>
>   <System category=" watchlist-source"> <Node><Address>IP4</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP5</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP6</Address>...
> </System> </Flow> </EventData>
> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"?
> 
> Yes. If an company saw IP1 or 2 or 3 only  they should not think they 
> are seeing the indicator.
>
> >>> Is this AND logic applied across different Flow classes or any 
> >>> other
> indicator in the EventData class parent outside of the Flow parent of 
> the given System class of interest?
> 
> Yes, I will rephrase it to " The content in
> 		the EventData Class the Node belongs to should be combined with
> 		the watchlist of Systems using AND logic. 

It's the use of Node here that still confuses me since a Node is inside a System.  Could you express this sentence as a parsing statement like above?

> Different Flow
> classes
> 		that consist of different System classes (with watchlist-source
> 		or destination as attributes) follow AND logic in their parent
> 		EventData Class. "
> in order to make it clearer. Makes more sense?

The double use of different confuses me also.  Do you mean "Distinct Flow classes with the same parent EventData classes are ANDed together", aka parsing rule (b) from above?

Roman
 
> Panos
> 
> 
> 
> -----Original Message-----
> From: Roman D. Danyliw [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 5:54 AM
> To: Panos Kampanakis (pkampana); [email-masked]
> Subject: RE: IODEF predicate logic
> 
> Hi Panos!
> 
> Could you describe a little more about what you had in mind with the 
> predicate logic?  In your email below you used the terminology 
> "multiple indicators on one folder" which I hadn't read before.  Did 
> you mean multiple indicators in a single IODEF document?
> 
> In seeking clarity in Section 4.4 of draft-ietf-mile-iodef-guidance-01 
> I had a few questions.  Citing this section ...
> 
> > [I-D.ietf-mile-rfc5070-bis] defines two new category attributes in 
> > the System Class.  These are watchlist-source and watchlist- 
> > destination and they serve for watchlist indicator groupings.  When 
> > an IODEF Node consists of two or more System Classes with various 
> > watchlist-source and watchlist-destination attributes (watchlist of
> > Systems)
> 
> Isn't that  reversed, "When an IODEF **System** consists of two or 
> more
> **Node** classes with the category attribute set to watchlist-source 
> or watchlist-destination ...", since Node sub-element of System?
> However, this isn't consistent with the -00 draft since System can 
> only contain exactly 1 node.
> 
> [snip]
>     <xs:element name="System">
>       <xs:complexType>
>         <xs:sequence>
>           <xs:element ref="iodef:Node" maxOccurs="unbounded"/> ...
> 
> > the System information should be ORed with the information in the 
> > Flow Class.
> 
> Could you clarify what it means to be OR multiple Systems in the flow class?
> For example, with a snippet as follows,
> 
> <EventData> ...
> <Flow>
>   <System category=" watchlist-source"> <Node><Address>IP1</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP2</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP3</Address>...
> </System> </Flow> <Flow>
>   <System category=" watchlist-source"> <Node><Address>IP4</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP5</Address>...
> </System>
>   <System category=" watchlist-source"> <Node><Address>IP6</Address>...
> </System> </Flow> </EventData>
> 
> Is the watchlist defined as "(IP1 OR IP2 or IP3) AND (IP4 OR IP5 OR IP6)"?
> 
> > In other words, either System description should be considered as a 
> > watchlist indicator.  The rest of the content in the EventData Class 
> > the Node belongs to should be combined with the watchlist of Systems 
> > using AND logic.
> 
> Is this AND logic applied across different Flow classes or any other 
> indicator in the EventData class parent outside of the Flow parent of 
> the given System class of interest?
> 
> Roman
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Panos Kampanakis (pkampana)
> Sent: Monday, July 15, 2013 4:02 PM
> To: [email-masked]
> Subject: [mile] IODEF predicate logic
> 
> Hello everyone,
> 
> In the past people have asked how IODEF can combine multiple 
> indicators in one IODEF definition. For example a question can be, if 
> there are more than two malicious addresses, how they can be added in 
> one definition and what is the logic behind how they are combined?
> 
> draft-ietf-mile-rfc5070-bis-00 introduces some watchlist fields that 
> allow for multiple indicators on one folder. In
> draft-ietf-mile-iodef-guidance-01 I have added section
> http://tools.ietf.org/html/draft-ietf-mile-iodef-guidance-
> 01#section-4.4 that describes how the predicate logic works.
> 
> Comments and thoughts are welcome.
> 
> Rgs,
> Panos
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile