Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 5 Aug 2013 20:38:06 +0000

Hello!

Per the earlier announcement in [1], this note initiates topic discussion #1 on the 5070bis scope discussion.  A power-point formatted version of this text can be found in slides 4 and 5 of [2].  If you have a feelings on the matter, please provide input by August 26th.  To repeat, the intent here is to assess interest in including the information listed below in the 5070bis data model.  Opinions to add it in or explicitly avoid it are welcome.  In the case of the former, proposals are welcome but not required.

(1) How much cyber intelligence information should be represented?
**(a)** Description of the source and target of the event
**(b)** Description of the technical pattern of a given tactic used in an attack (e.g., indicators or signatures)
**(c)** Description of the actors perpetrating the attack?
**(d)** Description of the capabilities and  intent of the actors?

(2) What other indicator data fields should be add?
**(a)** File information (e.g., size, attributes, ACLs, ADS, PE information)
**(b)** Process information (e.g., pids, chains, loaded libraries)
**(c)** Mutex names
**(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, network settings)
**(e)** Email (e.g., arbitrary headers, structure of contents)
**(f)** Currently already support From, Subject, X-Mailer
**(g)** HTTP (e.g., arbitrary headers)
**(h)** Currently already support URL and UserAgent
**(i)** TLS Certificate or certificate chains
**(j)** External signatures languages (e.g., Yara, snort, Bro)

(3) Explicitly express a relationships between indicators? e.g., "(From: Email1 and Email1) OR (X-Mailer)"

(4) Absence of an indicator?

(5) Valid time to apply the indicator (EventData/StartTime and EndTime?)

Regards,
Roman

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html
[2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 5 Aug 2013 18:00:21 -0400

Hi Roman,

Thank you for starting the scoping discussion.  I look forward to the feedback.  I have a few clarifying questions that may help people respond.

For 2(i), I believe this is handled right now since the W3C digital signature schema can be included.  Is something missing for TLS certificate or certificate chains?

For the other questions, are you asking if more content than what is represented already should be included?  For instance, 1a - are you asking if there is a need for additional elements or attributes on the existing elements that can already be used to describe source and target?

And on #4 - this is to provide a way to show that an indicator was not there to include in XML document, right?

Thank you,
Kathleen

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Roman D. Danyliw [[email-masked]]
Sent: Monday, August 05, 2013 4:38 PM
To: [email-masked]
Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hello!

Regards,
Roman

[1] http://www.ietf.org/mail-archive/web/mile/current/msg01146.html
[2] http://www.ietf.org/proceedings/87/slides/slides-87-mile-4.pdf
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 6 Aug 2013 16:41:55 +0000

Hello!

> -----Original Message-----
> From: Moriarty, Kathleen [mailto:[email-masked]]
> Sent: Monday, August 05, 2013 6:00 PM
> To: Roman D. Danyliw; [email-masked]
> Subject: RE: 5070bis-scoping discussion #1: Cyber Intelligence - respond by
> Aug 26
> 
> Hi Roman,
> 
> Thank you for starting the scoping discussion.  I look forward to the feedback.
> I have a few clarifying questions that may help people respond.

Thanks for the questions.  They'll help those who didn't hear the slide voice-over from Berlin.  The slides themselves weren't descriptive enough.
 
> For 2(i), I believe this is handled right now since the W3C digital signature
> schema can be included.  Is something missing for TLS certificate or certificate
> chains?

Agreed.  2(i) isn't up for discussion.  It's here.

> For the other questions, are you asking if more content than what is
> represented already should be included?  For instance, 1a - are you asking if
> there is a need for additional elements or attributes on the existing elements
> that can already be used to describe source and target?

Exactly.  Per slide #4 of [2], there is a continuum of cyber event and intelligence information to include.  The data model currently supported only the first two.  The desire is to elicit any missing data elements from any of these four categories; an endorsement that we need to have some subset of these four categories; or a statement that we shouldn't worry about having data elements from some subset of these four categories.
 
> include in XML document, right?

Yes.  I had intended it to mean the "NOT" operator in some logical expression.  All of the predicate logic discussion (http://www.ietf.org/mail-archive/web/mile/current/msg01145.html) to date has used only AND and OR logic.  The WG has discussed the need to conveying indicators that should be matched successfully.  This question was asking about the ability to convey "NOT this_indicator" -- the absence of this indicator is the indicator.

Roman

> Per the earlier announcement in [1], this note initiates topic discussion #1 on
> the 5070bis scope discussion.  A power-point formatted version of this text
> can be found in slides 4 and 5 of [2].  If you have a feelings on the matter,
> please provide input by August 26th.  To repeat, the intent here is to assess
> interest in including the information listed below in the 5070bis data model.
> Opinions to add it in or explicitly avoid it are welcome.  In the case of the
> former, proposals are welcome but not required.
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 7 Aug 2013 03:43:59 +0000

Hi Roman,

Comments in line, search for PK>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, August 05, 2013 4:38 PM
To: [email-masked]
Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hello!

(1) How much cyber intelligence information should be represented?
**(a)** Description of the source and target of the event
PK> Yes, I think we can provide that already.
**(b)** Description of the technical pattern of a given tactic used in an attack (e.g., indicators or signatures)
**(c)** Description of the actors perpetrating the attack?
PK> A summary description in text would beneficial. But I don't think such description would make a difference for an automated content consumer
**(d)** Description of the capabilities and  intent of the actors?
PK> A summary description in text would beneficial. But I don't think such description would make a difference for an automated content consumer

PK> I think that would bloat the IODEF data model.
PK> I think that would bloat the IODEF data model. 
PK> not sure we need them
PK> I think that would bloat the IODEF data model.

(3) Explicitly express a relationships between indicators? e.g., "(From: Email1 and Email1) OR (X-Mailer)"
PK> I am not sure what changes in IODEF that would entail

(5) Valid time to apply the indicator (EventData/StartTime and EndTime?)
PK> that will be useful I think

PK> In general, I do not think that expanding IODEF to be an all-inclusive data model is within the scope of this work. I was under the impression that the bis doc would adopt some changes in IODEF that came for real-world exercises. IODEF should still be simple and functional and be able to describe real-world incidents in a simple manner. But adding things like process ids I think expands its scope extensively and I am not sure this WG will be able to provide an all-inclusive solution. I think for more advanced descriptions there is the SCI draft that could leverage other outside languages.

PK> Rgs 
PK> Panos

Regards,
Roman

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 9 Aug 2013 14:13:57 -0400

Hi Roman,

My chair hat is off and comments are in-line.

Others please chime in with your views whether you agree or not with answers so far.

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Panos Kampanakis (pkampana) [[email-masked]]
Sent: Tuesday, August 06, 2013 11:43 PM
To: Roman D. Danyliw; [email-masked]
Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hi Roman,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, August 05, 2013 4:38 PM
To: [email-masked]
Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hello!

(1) How much cyber intelligence information should be represented?
**(a)** Description of the source and target of the event
PK> Yes, I think we can provide that already.
KM> I am not aware of requests for additional information to be represented above what is there.

**(b)** Description of the technical pattern of a given tactic used in an attack (e.g., indicators or signatures)
**(c)** Description of the actors perpetrating the attack?
PK> A summary description in text would beneficial. But I don't think such description would make a difference for an automated content consumer
KM> I agree with Panos.  When I asked the question of one group, they said they didn't get enough of this data to worry about a standard format, text should be okay for now.

KM> +1

(2) What other indicator data fields should be add?
**(a)** File information (e.g., size, attributes, ACLs, ADS, PE information)
**(b)** Process information (e.g., pids, chains, loaded libraries)
PK> I think that would bloat the IODEF data model.
KM> I agree, SCI could be used or if there is interest, would the forensic extension be helpful and should that be revived to keep the core data model smaller?
**(c)** Mutex names
**(d)** Device state (e.g., ARP or routing table, disk geometry, BIOS, network settings)
PK> I think that would bloat the IODEF data model.
KM> I think you can already include ARP information?  Would some of this just be extensions through recordItem perhaps - if people say they need it and not inthe core data model?

**(e)** Email (e.g., arbitrary headers, structure of contents)
KM> This can be done through RFC5901 or by using SCI and including ARF, right?  I think that may be sufficient unless others feel strongly.
**(f)** Currently already support From, Subject, X-Mailer
**(g)** HTTP (e.g., arbitrary headers)
**(h)** Currently already support URL and UserAgent
**(i)** TLS Certificate or certificate chains
PK> not sure we need them
KM> f-i were requested to meet soem specific use cases of commonly shared items.  Our CIRC wanted them.

**(j)** External signatures languages (e.g., Yara, snort, Bro)
PK> I think that would bloat the IODEF data model.
KM> Would this just be through RecordItem or AdditionalData extensions anyway, so is bloat an issue?  I think these should just be handled through the extensibility mechanisms

(3) Explicitly express a relationships between indicators? e.g., "(From: Email1 and Email1) OR (X-Mailer)"
PK> I am not sure what changes in IODEF that would entail
KM> Can't we do that through the predicate logic already without needing to put in the words?  This should be machine readable to be useable/get adoption anyway.  We don't have a way to say a value provided contains, starts or ends with, etc. is that needed? 

(4) Absence of an indicator?
KM> Would like to hear other opinions on the usefulness of this.

KM> +1

PK> In general, I do not think that expanding IODEF to be an all-inclusive data model is within the scope of this work. I was under the impression that the bis doc would adopt some changes in IODEF that came for real-world exercises. IODEF should still be simple and functional and be able to describe real-world incidents in a simple manner. But adding things like process ids I think expands its scope extensively and I am not sure this WG will be able to provide an all-inclusive solution. I think for more advanced descriptions there is the SCI draft that could leverage other outside languages.
KM> I agree with Panos.  For some of the items, would RecordItem and AdditionalData be the right extension mechanisms to allow that data to be exchanged and in other cases that require data models, SCI could help.

PK> Rgs
PK> Panos

KM> Thank you, Kathleen

Regards,
Roman

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 19 Aug 2013 09:01:26 -0400

List members:

This poll to scope IODEF v2.0 is open until August 26th.  Please provide comments and opinions to guide the work.

Thank you!
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Moriarty, Kathleen [[email-masked]]
Sent: Friday, August 09, 2013 2:13 PM
To: Panos Kampanakis (pkampana); Roman D. Danyliw; [email-masked]
Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hi Roman,

Thanks,
Kathleen

Hi Roman,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Monday, August 05, 2013 4:38 PM
To: [email-masked]
Subject: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Hello!

PK> Rgs
PK> Panos

KM> Thank you, Kathleen

Regards,
Roman

---

From: Alexandre Dulaunoy <[email-masked]>
Date: Mon, 19 Aug 2013 15:44:24 +0200

> This poll to scope IODEF v2.0 is open until August 26th.  Please provide comments and opinions to guide the work.

Dear All,

Is there somewhere an overview of all the "Cyber Intelligence" standards
and especially where IODEF fits? Especially looking at the current
evolution of Cybox (CAPEC, MAEC, STIX, TAXII), OpenIOC, Sandbox format
(GFI, Cuckoo JSON), MISP[] XML[2], it might be worth to check where
IODEF v2.0 could be. As we are currently looking to the additional
formats to support for export/import in MISP, we were wondering if IODEF
was a candidate or not.

Thank you very much,

Cheers.

[1] https://github.com/MISP/MISP
[2]
https://github.com/MISP/MISP/blob/develop/INSTALL/format/misp_xml_format.dtd

- -- 
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
[email-masked] - www.circl.lu

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 20 Aug 2013 10:48:15 +0000

Hi Alexandre.

I haven't seen an general overview of all the Cyber Intelligence options available where their use and differences are described. The truth is that there are multiple overlaps between many of these standards and it depends on the context they are describing.

I will let others express their opinions also, but IMO, what options someone goes with depends on the usecase he is trying to solve. For example for Cisco vulnerability definitions there is nothing we have been able to come up with except SCAP. There are many more malware and host intelligence options that Cybox and MAEC are more suitable. As for IODEF, I believe that its simplicity in describing common indicators makes it a good candidate for communications between incident response team. For example grouping event data together to describe command and control server, or common traffic indicators or spam emails for example are its bread and butter. Now, the updates in IODEF add more functionality which is predicate logic, DNS, phishing and malware file info. Yes, most of these could be described by other options like STIX. IODEF is one simple enough option where further details about the malware where the behavior or more details of the malware itself are not needed. IODEF also has https://datatracker.ietf.org/doc/draft-ietf-mile-sci draft that explains how other standards can be incorporated in it. So, IODEF can incorporate more standards for further indicator details in its body. Unfortunately there is no mutually-exclusive area where one standard can be applied and others can't, as far as I know.

Rgs,
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandre Dulaunoy
Sent: Monday, August 19, 2013 9:44 AM
To: [email-masked]
Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

* PGP Signed by an unknown key

Dear All,

Is there somewhere an overview of all the "Cyber Intelligence" standards and especially where IODEF fits? Especially looking at the current evolution of Cybox (CAPEC, MAEC, STIX, TAXII), OpenIOC, Sandbox format (GFI, Cuckoo JSON), MISP[] XML[2], it might be worth to check where IODEF v2.0 could be. As we are currently looking to the additional formats to support for export/import in MISP, we were wondering if IODEF was a candidate or not.

Thank you very much,

Cheers.

--
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg [email-masked] - www.circl.lu

* Unknown Key
* 0x44E6CBCD(L)

---

From: Anton Chuvakin <[email-masked]>
Date: Tue, 20 Aug 2013 11:09:14 -0700

> I haven't seen an general overview of all the Cyber Intelligence options available where their use and differences are described. The truth is that there are multiple overlaps between many of these…

Can somebody briefly explain what IS "cyber intelligence"?

-- 
Dr. Anton Chuvakin
Site: http://www.chuvakin.org
Twitter: @anton_chuvakin
Work: http://www.linkedin.com/in/chuvakin

---

From: Patrick Curry <[email-masked]>
Date: Wed, 21 Aug 2013 08:25:30 +0100

I suggest cyber intelligence is the acquisition of information to inform your Collaborative Cyber Situational Awareness (CCSA) upon which decisions are made. For more on CCSA, see MACCSA and speak to Kathleen. 
Regards
Patrick

Sent from my iPhone

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 21 Aug 2013 08:06:54 -0400

Roman,

Does CERT/CC have a good definition for cyber intelligence?  It may be useful to add a definition to RFC5070-bis.

I hear it described in terms of a progression that starts with data (could include raw logs), then moves to information (context added and is more useful), then to cyber intelligence (actionable information).  I am sure there are better definitions though.  Anyone?

As Patrick mentioned, I am happy to help if anyone wants to learn more on MACCSA.

Thanks,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Patrick Curry [[email-masked]]
Sent: Wednesday, August 21, 2013 3:25 AM
To: Anton Chuvakin
Cc: [email-masked]
Subject: Re: [mile] 5070bis-scoping discussion #1: Cyber Intelligence

Sent from my iPhone

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 21 Aug 2013 12:52:21 +0000

Hello!

We (SEI, CERT/CC) define cyber intelligence as "[t]he acquisition and analysis of information to identify, track, and predict cyber capabilities, intentions, and activities that offer courses of action to enhance decision making."  [1].  To form cyber intelligence, one must (1) gather the data; (2) apply technical (functional) analysis of some sort (e.g., network forensics, malware reverse engineering) to answer the "what" and "how"; and finally (3) apply the strategic (all-source) context to technical/functional analysis to answer the "who" and why".

To loop this discussion back to the beginning of this thread, the question for the working group is to decide how much of the "who" and "why" should be represented in the data model as an enumerated or free-form data elements; as an extension, or not at all (although one can't prevent an extension).  The original question was framed as a list of data types that should be included or not.  How to do it can be described later.

> **(b)** Description of the technical pattern of a given tactic used in 
> an attack (e.g., indicators or signatures)

Roman

[1] http://www.sei.cmu.edu/library/assets/whitepapers/citp-summary-key-findings.pdf.

> From: "Moriarty, Kathleen" <kathleen.moriarty at emc.com>
> To: Patrick Curry <patrick.curry at federatedbusiness.org>, 
> Anton Chuvakin <anton at chuvakin.org>
> Cc: "mile at ietf.org" <mile at ietf.org>
> Date: Wed, 21 Aug 2013 08:06:54 -0400
> Roman,
>
> Does CERT/CC have a good definition for cyber intelligence?  It may 
> be useful to add a definition to RFC5070-bis.
>
> I hear it described in terms of a progression that starts with data 
> (could include raw logs), then moves to information (context 
> added and is more useful), then to cyber intelligence (actionable 
> information).  I am sure there are better definitions though.  Anyone?
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Patrick Curry
> I suggest cyber intelligence is the acquisition of information to inform your
> Collaborative Cyber Situational Awareness (CCSA) upon which decisions are
> made. For more on CCSA, see MACCSA and speak to Kathleen.
> Regards
> Patrick
> 
> Sent from my iPhone
> 
> >> I haven't seen an general overview of all the Cyber Intelligence
> >> options available where their use and differences are described. The truth
> is that there are multiple overlaps between many of these standards and it
> depends on the context they are describing.
> >

---

From: Jerome Athias <[email-masked]>
Date: Sat, 24 Aug 2013 11:01:46 +0000

Hi,

I shared a document as an effort to map various
formats/specifications/standards
Download Attachment<http://making-security-measurable.1364806.n2.nabble.com/attachment/7580434/0/Incident_DataModels_Mapping.xlsx>
I would be happy to share and collaborate on updates.

Best regards
Jerome Athias

2013/8/19 Alexandre Dulaunoy <[email-masked]>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlISITQACgkQCeLNSUTmy82snACfZWeI6udUg2adiNsxueZgev/Z
> 8WUAn0yaZxZPYBncn9iXr4aiI9RluxRy
> =br8P
> -----END PGP SIGNATURE-----