Subject: [mile] MAEC in SCI

From: <[email-masked]>
Date: Fri, 27 Jan 2012 11:49:05 -0600

I suggest we look at including MAEC in SCI. I believe the appropriate place for most of what MAEC is intended to express falls under the IODEF Method class at the top level, but individual instances of malicious code expressed using MAEC with full details of network/file observables and such are better reserved for EventData child classes.

Would there be a way to explain how MAEC (or other malware languages) can be used in either location depending on the nature of what is being expressed? MAEC at the top level Method class would be concerned with common attributes of malware being used in a campaign, perhaps - MAEC in children of EventData would be concerned with individual malware samples captured and analyzed.

Making any sense?

 - Tom Millar, US-CERT

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

---

From: <[email-masked]>
Date: Sat, 28 Jan 2012 15:16:35 -0500

Tom,

> Making any sense?

Definitely - the Taipei meeting discussion of IANA considerations for the SCI draft
indicated that a single SCI specification could be appropriate to multiple extension
classes in, so it's great to have an actual example of that!
	
> Would there be a way to explain how MAEC (or other malware languages) can be used in either location
> depending on the nature of what is being expressed? MAEC at the top level Method class would be
> concerned with common attributes of malware being used in a campaign, perhaps - MAEC in children of
> EventData would be concerned with individual malware samples captured and analyzed.

Yes.  If the MAEC usage explanation is put into the mile-sci draft, then the IANA
registry entry for MAEC (in the new SCI registry to be created by the mile-sci draft)
would contain a reference to the mile-sci RFC, and that reference would enable people
to find the explanation of how to use MAEC with each applicable extension class.

For the future (RFCs can't be changed after publication), an informational RFC could be
used to contain such an explanation for an additional SCI specification (or specifications),
and that RFC would be referenced from the corresponding IANA registry entry.  It might be
a good idea to add text to the mile-sci draft to suggest (or even require) an
informational RFC to explain usage distinctions when a single SCI specification is
applicable to multiple extension classes.

In contrast, putting that sort of explanation directly into an IANA registry is not a
good idea. I just happen to be in the midst of working with IANA to clean some other
IANA registries; as part of that cleanup, IANA wants to take out an explanation of
how something works.  FWIW, IANA views their function as administrative, not technical.

Does that sound reasonable?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, January 27, 2012 12:49 PM
> To: [email-masked]
> Subject: [mile] MAEC in SCI
> 
> I suggest we look at including MAEC in SCI. I believe the appropriate place for most of what MAEC is
> intended to express falls under the IODEF Method class at the top level, but individual instances of
> malicious code expressed using MAEC with full details of network/file observables and such are better
> reserved for EventData child classes.
> 
> Would there be a way to explain how MAEC (or other malware languages) can be used in either location
> depending on the nature of what is being expressed? MAEC at the top level Method class would be
> concerned with common attributes of malware being used in a campaign, perhaps - MAEC in children of
> EventData would be concerned with individual malware samples captured and analyzed.
> 
> Making any sense?
> 
>  - Tom Millar, US-CERT
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile