Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

From: <[email-masked]>
Date: Thu, 5 Dec 2013 08:59:54 -0600

Thank you Kathleen.

I think some of the head-scratching stems from the fact that there is
very little out there to explain the "framework" efforts like MACCSA and
CDXI. That's especially problematic when trying to put them side by side
against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and this
WG. To clarify - each of those latter items I just mentioned has a
public website with lots of information on the work, links to
repositories of running code, major commercial entities involved
(several publicly announcing their involvement, like Microsoft with
regards to STIX), and most importantly to me, other national CSIRTs
actively participating. CDXI and MACCSA, as far as I can tell, have been
discussed for years but I have yet to see how they actually work or who
is actually using them in an operational environment, or even in a
testbed. You could throw NEISAS in the latter category as well, I
suppose.

I'm concerned that putting white paper frameworks up against actual
specifications and working software that people use every day can only
lead to more confusion in an arena where - as you and I have noted time
and again - there is already more than sufficient bewilderment.

I don't understand your second paragraph. It has always been my
understanding that all of the sharing models, specifications and working
software in this arena have been based on actual use cases. Many of
those use cases are documented or even explicit in the names of the
efforts themselves.

 - Tom Millar

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870 

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Moriarty,
Kathleen
Sent: Wednesday, December 04, 2013 5:41 PM
To: Chernin, Michael A.; [email-masked]
Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

Thanks Tom & Aaron for sharing your feedback.  These are helpful
discussions.

I can assist on the MACCSA question for those not familiar as it is not
in itself a format, but rather a framework that references and includes
other efforts.  It actually covers quite a bit from identity and access
management through to sharing formats and protocols referencing work
from several international standards bodies as appropriate.  This was
done to show that standards existed and could be combined to provide the
necessary coverage without having to invent anything new.  The work that
proceeded MACCSA involved about 18 nations who had requirements for
international standards (IETF, ISO, ITU, etc.) and the ability to update
and evolve referenced standards as needed in the future.  I think there
are over 30 nations involved now.  In addition to the MILE work, the
MITRE work is mentioned and will be included more directly when it moves
to a standards body.  It is mentioned and described in the current
version.  Last time I looked at the MACCSA framework, it did not compare
the formats as that is not the purpose of the framework.  Many large
efforts like the NATO CDXI for example, are looking IODEF, STIX, as well
as OpenIOC to use what they need, where they need it.  MACCSA is putting
all of the pieces together.

In terms of comparisons, I see the formats as suitable for different use
cases and think the report comes at a very good time as Aaron points
out.  Even within a use case, sharing between different entities could
vary greatly and thus the requirements for exchange could vary.  Privacy
and information leakage concerns could limit what is used for sharing
with certain parties and it may be desirable to just support a minimum
baseline of what should be exchanged in those situations.  For other
exchanges (even in the same sharing model), richer data sets and
information may be very important (Aaron's 4th bullet - I would say STIX
is the most robust as capable depends on your use case and requirements.
Not everyone can handle that much information as they are lacking
analyst resources to deal with threat actors, campaigns, etc.).  That's
part of the reason I think use cases based sharing models are very
important as well as having options to choose formats and protocols that
meet your requirements.

Thanks again for all of your efforts on this report Romain!

Best regards,

Kathleen

From: mile [mailto:[email-masked]] On Behalf Of Chernin, Michael
A.
Sent: Wednesday, December 04, 2013 4:58 PM
To: [email-masked]
Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

Thanks for the report Romain. I will second Mr. Millar that sections 1-3
provide valuable information regards to the barriers to sharing.

My concerns start in section 4, where the Data Exchange formats are
compared. At our current sharing maturity level, people are doing a lot
of research on specification selection, and during this time
specification perception holds a lot of value. I am concerned about the
primary image (Figure 6) used to open section 4. My input is below:

·         It's easy to imagine a standard/specification that can do
everything. While there is an asterisk next to MACCSA stating that it's
in the definition phase, the way it spans the entire chart gives it a
superior perception to other more defined specifications like IODEF and
STIX. 

·         I am unable to locate a definition for Network and File
observable columns on the chart. All the specifications compared have
key coverage differences in these areas.

·         Critical areas that both STIX and IODEF excel at, like email,
are missing as a column entirely

·         Key observable columns that STIX excels at are missing
entirely:  Actors, Campaigns, TTP, Targeting, Windows objects, Unix
objects, Privileges, Package Manager Data, User Account Data, DNS, etc.
These missing columns make STIX appear less capable. If you add those
columns in, than a completely different story is told and STIX appears
the most capable. 

Thanks

Aharon

DTCC Non-Confidential (White)

_____________________________________________________________ 
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to whom they are addressed. If you have received this email in error,
please notify us immediately and delete the email and any attachments
from your system. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no
liability for any damage caused by any virus transmitted by this email.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 5 Dec 2013 10:56:51 -0500

Hi Tom, 

Thank you, this is a good discussion and your points are well taken!  CDXI and MACCSA could be separated out to show they fit into complimentary buckets.  It should not take a PhD to understand this stuff, but when we get it right (hopefully soon) no one will have to know what any of these acronyms are, it will just work.

A white paper on CDXI was published through IEEE, so it may not have been read as much due to the fee, not sure.  CDXI is open in terms of the formats and protocols used in their framework.  Luc has presented on it externally, I had the opportunity to see him present at RSA Europe in October and the work is excellent.  His presentation was extremely well-received.  Maybe he can share some of the public information on this list?

As for use cases, I agree a lot of the work has been focused on use cases, but think some efforts have done better at the sharing model development than others.  I think there are valuable lessons we can all learn as we build out the space further to increase the success.  I spent some time writing my thoughts on the topic to help in a white paper and several blogs that are intentionally neutral on formats/protocols as I think your sharing model and requirements should be well-defined prior to any selection.  Answers could vary within a sharing model as well.  Here are a few links for those that are interested in a deeper explanation of my use cases comment:

RSA White paper:
http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for-threat-intell-sharing.pdf 

RSA Blogs:
https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-share-and-who-should-get-it/ 
https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectively/ 
https://blogs.rsa.com/standards-matter-information-sharing/

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 05, 2013 10:00 AM
To: Moriarty, Kathleen; [email-masked]; [email-masked]
Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect

Thank you Kathleen.

I think some of the head-scratching stems from the fact that there is very little out there to explain the "framework" efforts like MACCSA and CDXI. That's especially problematic when trying to put them side by side against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and this WG. To clarify - each of those latter items I just mentioned has a public website with lots of information on the work, links to repositories of running code, major commercial entities involved (several publicly announcing their involvement, like Microsoft with regards to STIX), and most importantly to me, other national CSIRTs actively participating. CDXI and MACCSA, as far as I can tell, have been discussed for years but I have yet to see how they actually work or who is actually using them in an operational environment, or even in a testbed. You could throw NEISAS in the latter category as well, I suppose.

I'm concerned that putting white paper frameworks up against actual specifications and working software that people use every day can only lead to more confusion in an arena where - as you and I have noted time and again - there is already more than sufficient bewilderment.

I don't understand your second paragraph. It has always been my understanding that all of the sharing models, specifications and working software in this arena have been based on actual use cases. Many of those use cases are documented or even explicit in the names of the efforts themselves.

 - Tom Millar

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Wednesday, December 04, 2013 5:41 PM
To: Chernin, Michael A.; [email-masked]
Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

Thanks Tom & Aaron for sharing your feedback.  These are helpful discussions.

I can assist on the MACCSA question for those not familiar as it is not in itself a format, but rather a framework that references and includes other efforts.  It actually covers quite a bit from identity and access management through to sharing formats and protocols referencing work from several international standards bodies as appropriate.  This was done to show that standards existed and could be combined to provide the necessary coverage without having to invent anything new.  The work that proceeded MACCSA involved about 18 nations who had requirements for international standards (IETF, ISO, ITU, etc.) and the ability to update and evolve referenced standards as needed in the future.  I think there are over 30 nations involved now.  In addition to the MILE work, the MITRE work is mentioned and will be included more directly when it moves to a standards body.  It is mentioned and described in the current version.  Last time I looked at the MACCSA framework, it did not compare the formats as that is not the purpose of the framework.  Many large efforts like the NATO CDXI for example, are looking IODEF, STIX, as well as OpenIOC to use what they need, where they need it.  MACCSA is putting all of the pieces together.

In terms of comparisons, I see the formats as suitable for different use cases and think the report comes at a very good time as Aaron points out.  Even within a use case, sharing between different entities could vary greatly and thus the requirements for exchange could vary.  Privacy and information leakage concerns could limit what is used for sharing with certain parties and it may be desirable to just support a minimum baseline of what should be exchanged in those situations.  For other exchanges (even in the same sharing model), richer data sets and information may be very important (Aaron's 4th bullet - I would say STIX is the most robust as capable depends on your use case and requirements.
Not everyone can handle that much information as they are lacking analyst resources to deal with threat actors, campaigns, etc.).  That's part of the reason I think use cases based sharing models are very important as well as having options to choose formats and protocols that meet your requirements.

Best regards,

Kathleen

From: mile [mailto:[email-masked]] On Behalf Of Chernin, Michael A.
Sent: Wednesday, December 04, 2013 4:58 PM
To: [email-masked]
Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

Thanks for the report Romain. I will second Mr. Millar that sections 1-3 provide valuable information regards to the barriers to sharing.

My concerns start in section 4, where the Data Exchange formats are compared. At our current sharing maturity level, people are doing a lot of research on specification selection, and during this time specification perception holds a lot of value. I am concerned about the primary image (Figure 6) used to open section 4. My input is below:

·         It's easy to imagine a standard/specification that can do
everything. While there is an asterisk next to MACCSA stating that it's in the definition phase, the way it spans the entire chart gives it a superior perception to other more defined specifications like IODEF and STIX. 

·         I am unable to locate a definition for Network and File
observable columns on the chart. All the specifications compared have key coverage differences in these areas.

·         Key observable columns that STIX excels at are missing
entirely:  Actors, Campaigns, TTP, Targeting, Windows objects, Unix objects, Privileges, Package Manager Data, User Account Data, DNS, etc.
These missing columns make STIX appear less capable. If you add those columns in, than a completely different story is told and STIX appears the most capable. 

Thanks

Aharon

_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 11 Dec 2013 10:17:59 -0500

Hello, Trey.

I believe this is the right link to the CDXI paper.  Luc is on the list, so he may chime in if he sees this.  A search for "CDXI Dandurand" turns up previous presentations he has given as well if that is helpful.

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6568369&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6568369

The paper turned up in the first page of links from Google with those search terms and has the title, "Towards Improved Cyber Security Information Sharing".

Best regards,
Kathleen

-----Original Message-----
From: Trey Darley [mailto:[email-masked]] 
Sent: Wednesday, December 11, 2013 8:36 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

Hi, Kathleen -

Have you got a link to the IEEE CDXI whitepaper handy? IEEE is great but their site nav / search...not so much. Thanks!

Cheers,
Trey
--
Trey Darley
Minister of Foreign Affairs
Brussels > Cupertino Seattle London Hong Kong Washington D.C.
Plano San Francisco Singapore Munich Paris Splunk > because specialisation is for insects

On 05.12.13 16:56, "Moriarty, Kathleen" <[email-masked]> wrote:

>Hi Tom,
>
>Thank you, this is a good discussion and your points are well taken!
>CDXI and MACCSA could be separated out to show they fit into 
>complimentary buckets.  It should not take a PhD to understand this 
>stuff, but when we get it right (hopefully soon) no one will have to 
>know what any of these acronyms are, it will just work.
>
>A white paper on CDXI was published through IEEE, so it may not have 
>been read as much due to the fee, not sure.  CDXI is open in terms of 
>the formats and protocols used in their framework.  Luc has presented 
>on it externally, I had the opportunity to see him present at RSA 
>Europe in October and the work is excellent.  His presentation was 
>extremely well-received.  Maybe he can share some of the public 
>information on this list?
>
>As for use cases, I agree a lot of the work has been focused on use 
>cases, but think some efforts have done better at the sharing model 
>development than others.  I think there are valuable lessons we can all 
>learn as we build out the space further to increase the success.  I 
>spent some time writing my thoughts on the topic to help in a white 
>paper and several blogs that are intentionally neutral on 
>formats/protocols as I think your sharing model and requirements should 
>be well-defined prior to any selection.  Answers could vary within a 
>sharing model as well.  Here are a few links for those that are 
>interested in a deeper explanation of my use cases comment:
>
>RSA White paper:
>http://www.emc.com/collateral/emc-perspective/h12175-transf-expect-for-
>thr
>eat-intell-sharing.pdf
>
>RSA Blogs:
>https://blogs.rsa.com/information-sharing-done-right-whats-useful-to-sh
>are
>-and-who-should-get-it/
>https://blogs.rsa.com/information-sharing-how-do-we-share-data-effectiv
>ely
>/
>very little out there to explain the "framework" efforts like MACCSA 
>and CDXI. That's especially problematic when trying to put them side by 
>side against activities like STIX, TAXII, CybOX, CIF, AbuseHelper, and 
>this WG. To clarify - each of those latter items I just mentioned has a 
>regards to STIX), and most importantly to me, other national CSIRTs actively participating.
>CDXI and MACCSA, as far as I can tell, have been discussed for years 
>but I have yet to see how they actually work or who is actually using 
>them in an operational environment, or even in a testbed. You could 
>throw NEISAS in the latter category as well, I suppose.
>
>understanding that all of the sharing models, specifications and 
>working software in this arena have been based on actual use cases. 
>Many of those use cases are documented or even explicit in the names of 
>the efforts themselves.
>
> - Tom Millar
>
>done to show that standards existed and could be combined to provide 
>the necessary coverage without having to invent anything new.  The work 
>that proceeded MACCSA involved about 18 nations who had requirements 
>for international standards (IETF, ISO, ITU, etc.) and the ability to 
>update and evolve referenced standards as needed in the future.  I 
>think there are over 30 nations involved now.  In addition to the MILE 
>work, the MITRE work is mentioned and will be included more directly 
>when it moves to a standards body.  It is mentioned and described in 
>the current version.  Last time I looked at the MACCSA framework, it 
>did not compare the formats as that is not the purpose of the 
>framework.  Many large efforts like the NATO CDXI for example, are 
>looking IODEF, STIX, as well as OpenIOC to use what they need, where 
>they need it.  MACCSA is putting all of the pieces together.
>
> 
>
>In terms of comparisons, I see the formats as suitable for different 
>use cases and think the report comes at a very good time as Aaron points out.
> Even within a use case, sharing between different entities could vary 
>greatly and thus the requirements for exchange could vary.  Privacy and 
>information leakage concerns could limit what is used for sharing with 
>certain parties and it may be desirable to just support a minimum 
>information may be very important (Aaron's 4th bullet - I would say 
>STIX is the most robust as capable depends on your use case and requirements.
>important as well as having options to choose formats and protocols 
>that meet your requirements.
>
> 
>
>Thanks for the report Romain. I will second Mr. Millar that sections 
>1-3 provide valuable information regards to the barriers to sharing.
>
> 
>
>*         It's easy to imagine a standard/specification that can do
>*         I am unable to locate a definition for Network and File
>*         Critical areas that both STIX and IODEF excel at, like email,
>*         Key observable columns that STIX excels at are missing
>confidential and intended solely for the use of the individual or 
>entity to whom they are addressed. If you have received this email in 
>error, please notify us immediately and delete the email and any 
>attachments from your system. The recipient should check this email and 
>any attachments for the presence of viruses. The company accepts no 
>_______________________________________________
>mile mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mile

---

From: Trey Darley <[email-masked]>
Date: Wed, 11 Dec 2013 13:36:21 +0000

Hi, Kathleen -

Have you got a link to the IEEE CDXI whitepaper handy? IEEE is great but
their site nav / search...not so much. Thanks!

Cheers,
Trey
--
Trey Darley
Minister of Foreign Affairs
Brussels > Cupertino Seattle London Hong Kong Washington D.C.
Plano San Francisco Singapore Munich Paris
Splunk > because specialisation is for insects

On 05.12.13 16:56, "Moriarty, Kathleen" <[email-masked]> wrote:

>stuff, but when we get it right (hopefully soon) no one will have to know
>what any of these acronyms are, it will just work.
>
>A white paper on CDXI was published through IEEE, so it may not have been
>read as much due to the fee, not sure.  CDXI is open in terms of the
>formats and protocols used in their framework.  Luc has presented on it
>externally, I had the opportunity to see him present at RSA Europe in
>October and the work is excellent.  His presentation was extremely
>well-received.  Maybe he can share some of the public information on this
>list?
>
>learn as we build out the space further to increase the success.  I spent
>some time writing my thoughts on the topic to help in a white paper and
>several blogs that are intentionally neutral on formats/protocols as I
>think your sharing model and requirements should be well-defined prior to
>any selection.  Answers could vary within a sharing model as well.  Here
>are a few links for those that are interested in a deeper explanation of
>my use cases comment:
>
>RSA White paper:
>WG. To clarify - each of those latter items I just mentioned has a public
>website with lots of information on the work, links to repositories of
>running code, major commercial entities involved (several publicly
>announcing their involvement, like Microsoft with regards to STIX), and
>most importantly to me, other national CSIRTs actively participating.
>CDXI and MACCSA, as far as I can tell, have been discussed for years but
>I have yet to see how they actually work or who is actually using them in
>an operational environment, or even in a testbed. You could throw NEISAS
>in the latter category as well, I suppose.
>
>software in this arena have been based on actual use cases. Many of those
>use cases are documented or even explicit in the names of the efforts
>themselves.
>
> - Tom Millar
>
>management through to sharing formats and protocols referencing work from
>several international standards bodies as appropriate.  This was done to
>show that standards existed and could be combined to provide the
>cases and think the report comes at a very good time as Aaron points out.
>Not everyone can handle that much information as they are lacking analyst
>resources to deal with threat actors, campaigns, etc.).  That's part of
>the reason I think use cases based sharing models are very important as
>well as having options to choose formats and protocols that meet your
>requirements.
>
> 
>
>attachments for the presence of viruses. The company accepts no liability
>for any damage caused by any virus transmitted by this email.
>
>

---

From: Trey Darley <[email-masked]>
Date: Wed, 11 Dec 2013 15:23:06 +0000

Hi, Kathleen -

Thanks! I mistakenly assumed that searching on ieee.org included search results for ieeexplore.ieee.org. Google-fu ftw!

Cheers,
Trey

________________________________________
From: Moriarty, Kathleen [[email-masked]]
Sent: Wednesday, December 11, 2013 16:17
To: Trey Darley; Dandurand Luc ([email-masked])
Cc: [email-masked]
Subject: RE: [mile] New ENISA report: Detect, SHARE, Protect

Hello, Trey.

Best regards,
Kathleen

-----Original Message-----
From: Trey Darley [mailto:[email-masked]]
Sent: Wednesday, December 11, 2013 8:36 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [mile] New ENISA report: Detect, SHARE, Protect

Hi, Kathleen -

Cheers,
Trey

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 11 Dec 2013 14:19:40 -0800

Hi.

That was the IEEE paper I downloaded from the IEEE site (I am a member).  That and the presentation you reference from search of 'CDXI Dandurand' were useful for me to get a good synopsis of CDXI.

- merike