Subject: [mile] 5070-bis scoping discussion #4: workflow

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 24 Sep 2013 14:19:36 +0000

Hello!

Per the announcement in [1], this note initiates topic discussion #4 on the 5070bis scope.  Please refer to discussion #1 [2], #2 [3], and #3 [4] in the archive.  This is the last of the discussion threads.  For those expecting this call yesterday as was planned, sorry for the delay.

Discussion #4 is intended to clarify what additional work to the data model is required to support specific work-flows.  The power-point formatted version of this text can be found in slides 10 of [4].  If you have a feelings on the matter, please provide input by noon of October 8th.  Opinions to add something or explicitly avoid it are welcome.  In the case of the former, proposals are welcome but not required.

(12) How should indicator matches be returned?  There has been much discuss on which indicators to represent.  With the Expectation class and the Incident@purpose the reason for sending the document is conveyed.  Should specific support be provided to convey that a particular indicator matched.  If so, how?

(13) How should document updates be sent?  Understanding of an event will evolve over the course of an investigation.  Is there a desire to support, change or provide additional guidance on how a sender should transmit an update to a previously sent IODEF document?

Regards,

Roman

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html

[2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html

[3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html

[4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html

[5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf

---

From: John Field <[email-masked]>
Date: Thu, 26 Sep 2013 13:04:58 -0400

All,

RE: number 13...

>>(13) How should document updates be sent?  Understanding of an event will
evolve over the course of an investigation.  Is there a desire

>> to support, change or provide additional guidance on how a sender should
transmit an update to a previously sent IODEF document?

Update messages raise a number of interesting questions.  Based on my
experience implementing this in a POC last year, I would suggest we keep it
very simple.  The semantic for updating an IODEF document should be a
simple replace operation.  If an endpoint receives a message for an
IncidentID that it has already seen before, then that message would
completely supersede the prior one.

Supporting partial updates to an IODEF message will greatly increase the
complexity (and cost of implementation, testing, and deployment, etc.)
considerably, so I would avoid this if at all possible.

Having said that, it's possible that incidents *may* require a partial
update, but indicators would definitely seem to have a more natural
"replace" semantic.

If there is a need for partial update, then the RecordData and RecordItem
elements are perhaps the place to focus.  As an incident unfolds, perhaps
more information becomes available….if one receives an update, and there
are some new RecordItem elements that did not appear in the original
document, then I should probably add these to the original incident, and
retain the earlier RecordItem elements.   If we need to specify CRUD
actions on a per-RecordItem basis, i.e. delete a specified RecordItem from
the earlier report (but retain other RecordItems) then that would likely
require that we leverage the “ext-dtype,” “meaning,” or “formatid”
attributes of that element/type.  This would enable a sender to add more
RecordItems to an earlier report, remove an incorrect RecordItem, or update
an existing RecordItem in an earlier report.

However, all this logic is significantly increasing the complexity on the
receiving side.  So, instead, I would suggest that the sender just send an
IODEF message that contains all of the most current information and the
latest message completely supersedes the previous one.  Let the sender and
the receiver (separately) deal with any issues of versioning history
locally.

Thanks,

John

P.S.  (It’s worth noting that none of this is unique to cyber security
information.  All message-based distributed systems face these same
questions of how to deal with issues like dropped messages, duplicates,
messages received out of order, semantics for updates or partial updates,
etc.)  The difficulty in ensuring that partial update changes have been
synchronized in a distributed system is one reason we have seen
architectures evolve to more RESTful approaches.  The client may get the
latest representation of the resource (IODEF document) at any time simply
by asking for it.  The provider does not try to take responsibility of
ensuring that all peers that may have received a prior representation of
the resource are kept are up to date, because that is a very expensive
requirement to satisfy.

On Tue, Sep 24, 2013 at 10:19 AM, Roman D. Danyliw <[email-masked]> wrote:

>  Hello!****
>
> ** **
>
> Per the announcement in [1], this note initiates topic discussion #4 on
> the 5070bis scope.  Please refer to discussion #1 [2], #2 [3], and #3 [4]
> in the archive.  This is the last of the discussion threads.  For those
> expecting this call yesterday as was planned, sorry for the delay.****
>
> ** **
>
> Discussion #4 is intended to clarify what additional work to the data
> model is required to support specific work-flows.  The power-point
> formatted version of this text can be found in slides 10 of [4].  If you
> have a feelings on the matter, please provide input by noon of October
> 8th.  Opinions to add something or explicitly avoid it are welcome.  In the
> case of the former, proposals are welcome but not required.****
>
> ** **
>
> (12) How should indicator matches be returned?  There has been much
> discuss on which indicators to represent.  With the Expectation class and
> the Incident@purpose the reason for sending the document is conveyed.
> Should specific support be provided to convey that a particular indicator
> matched.  If so, how?****
>
> ** **
>
> (13) How should document updates be sent?  Understanding of an event will
> evolve over the course of an investigation.  Is there a desire to support,
> change or provide additional guidance on how a sender should transmit an
> update to a previously sent IODEF document?****
>
> ** **
>
> Regards,****
>
> Roman****
>
> ** **
>
> [1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html****
>
> [2] http://www.ietf.org/mail-archive/web/mile/current/msg01147.html****
>
> [3] http://www.ietf.org/mail-archive/web/mile/current/msg01182.html****
>
> [4] http://www.ietf.org/mail-archive/web/mile/current/msg01189.html****
>
> [5] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf****
>
> ** **
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>
>

-- 

John P. Field | Security Architect | Pivotal

Direct: (908) 962-3394 | [email-masked]

**
*goPivotal.com <http://www.goPivotal.com>*