Subject: Re: [mile] Document reviews

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 11 Apr 2014 21:13:01 +0000

Thanks Tim.

I am just following up on this.

> draft-ietf-mile-iodef-guidance-02:
> Sections 3 and 4 look like they will be useful once complete. I am quite interested in the Restrictions section (section 4.6)
Working on it. First need to address some low hanging fruit for -03.

> Are there any reports of the interworking done in section 5.2 that can be referenced?
Unfortunately no.

> It would be useful to list the modules in section 5.4 that are available and whether they are open source
Fixed. It will be in the -03 version.

> Having example IODEF data in Appendix A is good
Thank you.

Panos

From: mile [mailto:[email-masked]] On Behalf Of Tim Freestone
Sent: Friday, January 03, 2014 11:57 AM
To: [email-masked]
Subject: [mile] Document reviews

Hi,

I have reviewed the following 2 documents:

-          The Incident Object Description Exchange Format v2 (draft-ietf-mile-rfc5070-bis-02)

-          IODEF Usage Guidance (draft-ietf-mile-iodef-guidance-02)

-
See my comments below. Note that I don't have any CSIRT experience or background and am looking at IODEF more from a security point of view in terms of how we can help to ensure the data transmitted is valid and so not leaking sensitive information or letting in malicious data which could compromise the CSIRT.

draft-ietf-mile-rfc5070-bis-02:
Section 1.4: 5th bullet typo - complementary
Section 2.6: Should this be "A hexadecimal byte is encoded..."?
Section 3.2: Incident Class. The  Indicator-set-id attribute does not appear in the diagram
Section 3.8: For the Additional Data Class which allows any data to be transferred - may want some mechanism to prevent the contents of the data from being executed automatically?
Section 3.11.1: Reference Class. The diagram does not show the 4 attributes for this Class
Section 3.12: Assessment Class. The diagram only shows 2 of the 4 attributes for this class
Section 3.13.1: History Item Class. The diagram does not show the indicator-set-id or indicator-uid attributes
Section 3.14: EventData Class. The diagram does not show the indicator-set-id attribute
Section 3.14.2:  typo "related" -> "relate"
Section 3.15: Expectation Class. The diagram does not show the indicator-uid or indicator-set-id attributes
Section 3.18.1: Counter Class. The diagram shows 5 attributes, but the words indicate there are 3 attributes and then describe 4 (leaving out "meaning")
Section 3.18.2: Address Class. The diagram does not show the indicator-uid attribute
Section 3.19: Service Class - typo "a a"
Section 3.19: Service Class. The diagram does not show the indicator-uid or indicator-set-id attributes
Section 3.21.1: RecordData Class. The diagram does not show the indicator-uid or indicator-set-id attributes
Section 3.21.2: RecordPattern Class. The text indicates 4 attributes, but describes 6
Section 7: Examples have the IODEF-Document Version as 1.0 not 2.0
Section 7: Is it worth including an example with some of the new fields for this version?
Section 8: The IODEF Schema indicates that Service Class has been extended by email address, email subject and x-mailer, but these are not described in the text (section 3.19)
Section 8: The Service Class schema shows elements for Email Subject and X-Mailer as well as EmailDetails which is the same set of elements?
Section 12.2: Reference [18] could be RFC 6545 and Reference [19] could be RFC 6546 now?
General: The extensibility in the data model increases the risk of data leakage or inbound malicious data through the extensions mechanism. Is it possible that over time, profiles defining what can and can't be sent will be defined for use between CSIRTS to ensure that only the expected data is transferred?

draft-ietf-mile-iodef-guidance-02:
Sections 3 and 4 look like they will be useful once complete. I am quite interested in the Restrictions section (section 4.6)
Are there any reports of the interworking done in section 5.2 that can be referenced?
It would be useful to list the modules in section 5.4 that are available and whether they are open source
Having example IODEF data in Appendix A is good

Kind Regards,
Tim Freestone, Solutions Architect
Deep-Secure Ltd.
Direct    +44 (0)1684 212 703
Mobile  +44 (0)7884 588 757
Office    +44 (0)1684 217070
Email      [email-masked]<mailto:[email-masked]>
Address  1 Nimrod House, Sandy's Road, Malvern, WR14 1JJ
www.Deep-Secure.com<http://www.deep-secure.com/>

[Description: cid:[email-masked]]

[Description: Description: twitter_32]<https://twitter.com/DeepSecureLtd>  [Description: Description: linkedin_32] <http://www.linkedin.com/company/709740?trk=pro_other_cmpy>    [Description: Description: youtube_32] <http://www.youtube.com/user/DeepSecureTV/>

The information contained in this e-mail message, and any attachment thereto, is confidential and may not be disclosed without our express permission. If you are not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message, or any attachment thereto, in whole or in part, is strictly prohibited. If you have received this message in error, please immediately notify us by telephone, fax or e-mail and delete the message and all of its attachments. Thank you.