Re: [mile] Working Group Last Call for draft-ietf-mile-sci

Hi Ian!

It's fabulous to hear about your implementation experience.  Thanks for taking the time to sharing it in such a thorough way.  

I'd like to respond to your "IODEF Extension Suggestions for alerts.doc", recommendation by recommendation.

(2.2.1) Add a summary description to EventData

Makes sense.  Perhaps something like /IODEF-Document/Incident/EventData/SummaryDescription

(2.2.2) Reference Element

I could use a little more detail in understanding the situation you're describing.  Specifically, I'm not sure what you mean by "... an EventData  may be reference in more than one Incident".  Do you envision a need for an IODEF document to completely reuse a given EventData sent in a previous IODEF document? Or is the situation that you want to reference the same EventData twice in a single IODEF document?

(2.2.3) Reported Element

To clarify, /IODEF-Document/Incident/ReportTime is when the incident was reported.  However, you're pointing out the various sensors that produce information for the EventData may have different reporting times.  You'd like to be able to store that in addition to the StartTime of the activity.  Correct?

(2.2.4) Status Attribute
(2.2.5) Status Reason or Dismiss Reason

Could you make a concrete proposal of what you'd like to see in these two?

(2.3.1) Surname and Title

Agreed. Contact is definitely missing a Title.  It should be considered for addition.

(2.3.2) Reference

Agreed.  Contact is definitely missing network account.  It should be considered for addition.

(2.3.4) Department

Agreed.  Contact is definitely missing department information.  It should be considered for addition.

(2.4.1) Location Element

Is the location of the impact dictated by a host described by a System class?  I ask because I'm wonder whether EventData/Flow/System/Node/Location could help.

(2.4.2) Assets/Zone

Asset Number = Agreed.  It should be considered for addition in System.
Business Owners = Agreed.  It should be considered for addition into System perhaps with a Contact class and a new @role
IP Address Range = Do you mean the netblock in which a given asset is fielded?  If so, could you simply put two <Address> classes in a given <Node> -- one would be the <Address category=ipv4-addr> and the other would be <Address category="ipv4-net"> for the netblock.

Roman

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Ian Hardman
Sent: Monday, July 15, 2013 12:19 PM
To: mile@ietf.org
Subject: Re: [mile] Working Group Last Call for draft-ietf-mile-sci

Kathleen has ask me to forward these documents to you.

These documents contain a summary based on alert handling, but there are a number of other areas we would like see implemented.

The main issue we have when synchronising incidents, when particular objects/XML elements are either:
        repeated through the XML exchange (typically with people) or
        there has been no change since it was last sent

We believe all the XML Elements need some method of referring to the objects/elements without having to supply the whole object again.  For example:

o)  party A sent information regarding an incident to party B.
o) it was later found out a known threat source was influencing a threat agent
o) information need to be resent with just the packet stating that that known threat source was now influencing the threat agent.

Then viz
o) it was later found out a known threat source was no longer influencing that threat agent
o) information need to be resent with just the packet stating that that known threat source was no longer influencing the threat agent.

There may be something in the specification we have not picked up on but we add attributes to say where we are just referencing object and the process.

Anyway see what you think and any help in standardising data interchange will be much appreciated.

Thanks,

Ian

-----Original Message-----
From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com]
Sent: 15 July 2013 13:28
To: Ian Hardman
Cc: Neil Hare-Brown; mile-chairs@tools.ietf.org
Subject: RE: [mile] Working Group Last Call for draft-ietf-mile-sci

Hi Ian,

I should have gone through all of the materials before sending my first email.  The presentation looks great for the workshop on the 26th and will be really helpful for people to understand what has been done for your use case.

For a draft, any extensions you have created that you think could be of broader use, like the alerting would be good to submit as a draft to MILE creating an extension.  The extension could be off the SCI draft or direct to IODEF.  For altering, if you want that off the SCI draft, you may need to ask Take to create a branch where that is appropriate, or use the EventReport with a special tag or something?  I would ask that you provide this feedback as soon as possible on list since the draft is in last call for about another week.  If you do want to get in a draft and present it at the MILE meeting (get a slot on the MILE agenda too).

Your document also includes some recommended changes to IODEF.  Could you post those to the list and also to the tool Roman started using to track IODEF issues?  We can get the working group to weigh in on them and should be able to fix it in RFC5070-bis.

Please let us know if you have any questions.

Thank you!
Kathleen

-----Original Message-----
From: Ian Hardman [mailto:Ian.Hardman@blackthorn.com]
Sent: Monday, July 15, 2013 4:26 AM
To: Moriarty, Kathleen
Cc: Neil Hare-Brown
Subject: RE: [mile] Working Group Last Call for draft-ietf-mile-sci

Kathleen,

There are a number of points that we would like see implemented to aid data transfer between hosts.

I have attached a document which contains a summary based on alert handling, but there are a number of other areas we would like see implemented.

The main issue we have when synchronising incidents, when particular objects/XML elements are either
        repeated through the XML exchange (typically with people) or
        there has been no change since it was last sent

As you can tell this can lead to large XML file, particular when you are looking at files (RecordData).  This was also brought up in the BCS meeting.  How we implemented it,  is to pass the unique id of the element and/or the unique external reference of the element and passing an attribute to say "no change".  Maybe it is already included and we haven't seen it.  Either way it would be good to get a standard on this.

I am not too sure how we should be submitting these ideas, or should we just discuss it in Berlin?

Many thanks.

Ian

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Brian Trammell
Sent: 09 July 2013 07:02
To: MILE IETF
Subject: [mile] Working Group Last Call for draft-ietf-mile-sci

Greetings, all,

This is the Working Group Last Call for draft-ietf-mile-sci, IODEF-extension for structured cybersecurity information.

The last call starts now, and ends Saturday 27 July, just before the IETF 87 meeting in Berlin.

Please read the latest revision of the draft, http://tools.ietf.org/html/draft-ietf-mile-sci-08, and send your comments to the mailing list; we'd also appreciate a comment if you're fine with the draft as is.

Many thanks, and best regards,

Brian

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile

This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately, and do not disclose the contents to another person, use it for any purpose, or store, or copy the information in any medium. Please also destroy and delete the message from your computer.