RE: [cti] RE: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

From
Kumar, Subodh <>
Date
2018-05-11T17:41:35+00:00
ID
Thread
RE: [cti] RE: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report
Thanks Ivan for the comments. I am making sure with my legal division, if and how to share this data externally. Will possibly be able to get some information
 early next week. I will connect back with you during middle of next week.

 

Subodh Kumar │ Executive
 Director |  Technology
│ Cybersecurity & Technology Controls
│ J.P. Morgan Chase & Co. │
 575 Washington Boulevard, Jersey City, NJ, 07310 │ T: +1
 201 595 7299 │ 

 

From: Kirillov, Ivan A. []

Sent: Friday, May 11, 2018 10:50 AM

To: Kumar, Subodh <>; 'Bret Jordan' <>; '' <>

Subject: Re: [cti] RE: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

 

Hi Subodh,

 

> I  had a chance to review the document and perform a dry run of FireEye MAS analysis data.

 

Great – thanks for the review! :-)

 

> Examples show “static_analysis_data” as a key but the property table shows “static_analysis_resutls” & “dynamic_analysis_results” as fields. Am I reading this
 wrong?

 

I think we forgot to update the examples, but it should indeed be “static_analysis_results” and “dynamic_analysis_results”. I’ve since updated our examples, so
 they should be correct now.

 

> Is there a reason it was dropped when CyBox was included in STIX specifications?

 

Unfortunately we had to make some difficult choices as far as which objects to include in STIX 2.0 due to time constraints, and as such DNS Query wasn’t included.
 However, I think there’s a good chance that it will make it into STIX 2.1 (I know IBM and some others would like to see it included). Our current draft of what this could look like is found here [1], so if you get a chance to review it that would be much appreciated.

 

> If all cybox objects could be collectively written in one section under “observable_data”, and
All observation/environment/results that reference observables, just make a reference to it, the implementation becomes cleaner. It is also easier to manage programmatically.

 

Interesting! I can also see this being easier to manage programmatically, since you’ll know that any object references will point to “observable_data”. It will
 also enable object re-use, e.g., if multiple dynamic analysis results find some of the same artifacts. I think we should definitely consider this as a worthwhile change.

 

> I have the following in attached example.

 

Unfortunately, it looks your attachment got stripped out. Could you try sending it to me directly – I would be interested in taking a look.

 

[1]
https://docs.google.com/document/d/1PHRpmizbMGOwAu_TwRj5ofwnUEOIoM__vIDCDZGf4Sk/edit#heading=h.zgo83h5kp26a

 

Regards,

Ivan

 

From: "Kumar, Subodh" <>

Date: Thursday, May 10, 2018 at 1:04 PM

To: Ivan Kirillov <>, 'Bret Jordan' <>, "''" <>

Subject: RE: [cti] RE: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

 

Hi Ivan

I  had a chance to review the document and perform a dry run of FireEye MAS analysis data. I have a few observations, one recommendation, and a sample that I
 am attaching.

 

Examples show “static_analysis_data” as a key but the property table shows “static_analysis_resutls” & “dynamic_analysis_results” as fields. Am I reading this
 wrong?

Dns_query as a cybox object has been dropped from STIX 2.0 specs part 4, but I dound this very valueable. I could not represent a dns query and result in STIX
 2.1 without that object wihout losing the meaning. Is there a reason it was dropped when CyBox was included in STIX specifications?

 

Recommendation: my thought:

If all cybox objects could be collectively written in one section under “observable_data”, and

All observation/environment/results that reference observables, just make a reference to it, the implementation becomes cleaner. It is also easier to manage programmatically.

 

I have the following in attached example:

 

Sightings
àsighiting of ref
à malware ref

Sighting
à observed data refs
à observable data

 

Malware
à samples (Can this just be a reference)
à observable data

Malware
à Analysis_tools (Can this just be a reference)
à observable data

Malware
à Analysis_environment (Can this just be a reference)
à observable data

Malware
à results
à Observables data

 

Observable_data
à observables

 

I am attaching a FireEye sample converted (it may get rejected although it does not have any confidential data but perimeter rules may just drop this).

Thanks

Subodh Kumar │ Executive
 Director |  Technology
│ Cybersecurity & Technology Controls
│ J.P. Morgan Chase & Co. │
 575 Washington Boulevard, Jersey City, NJ, 07310 │ T: +1
 201 595 7299 │ 

 

From: Kirillov, Ivan A. []

Sent: Monday, April 16, 2018 4:47 PM

To: Kumar, Subodh <>; 'Bret Jordan' <>; ''
 <>

Subject: Re: [cti] RE: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

 

Hi Sudobh,

 

You can find it in the STIX 2.1 Working Draft 01, here:

https://docs.google.com/document/d/1bkMmU1PxlwlAwjrMmyWV147rvLcRs2x62FicHbpH2gU/edit#heading=h.cabdb5lryb9q

 

Regards,

Ivan

 

From: <> on behalf of "Kumar, Subodh" <>

Date: Monday, April 16, 2018 at 2:43 PM

To: 'Bret Jordan' <>, "''" <>

Subject: [cti] RE: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

 

Thank Bret! I was expecting that based on the 2.1 work scope that I had read. My apologies, but I could not get to the 2.1 document.
 Can you point me there? I would like to minimize the customization, while keeping this as a mechanism to always extend STIX model.

 

Subodh Kumar │ Executive
 Director |  Technology
│ Cybersecurity & Technology Controls
│ J.P. Morgan Chase & Co. │
 575 Washington Boulevard, Jersey City, NJ, 07310 │ T: +1
 201 595 7299 │ 

 

From: Bret Jordan []

Sent: Monday, April 16, 2018 4:36 PM

To: Kumar, Subodh <>;


Subject: Re: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

 

Subodh,

 

You should look at the changes we have made to the STIX 2.1 Malware object. I think this should get you more than 80-90% of the way.

 

Bret

From:
 <>
 on behalf of Kirillov, Ivan A. <>

Sent: Monday, April 16, 2018 7:48:39 AM

To: Mr. Subodh Kumar; 

Subject: [EXT] Re: [cti] Need to integrate MAEC and STIX into single report

 

Hi Subodh,

STIX 2.0 supports the inclusion of custom properties on all objects [1], so I would say that this is a completely legitimate way to associate a STIX Malware Object with MAEC data. However, I would just suggest changing the property name to "x_jpmorgan_maecreference"
 to better align with the suggested requirements for custom properties (see section 7.1.1).

[1] https://docs.google.com/document/d/1dIrh1Lp3KAjEMm8o2VzAmuV0Peu-jt9aAh1IHrjAroM/edit#heading=h.8072zpptza86

Regards,

Ivan Kirillov

MITRE

On 4/15/18, 9:40 PM, " on behalf of Mr. Subodh Kumar" <
 on behalf of > wrote:

    I am working on transforming Reversing Lab's malware report into STIX. Since malware section of STIX is not very detailed in STIX 2.0, I am using MAEC to describe details of malware.

    

    I have to connect STIX information with MAEC information, so that the software reading STIX package should be able to navigate STIX parts and MAEC part to capture all the information regarding malware.

    

    What is the recommended way to integrate MAEC information into STIX?

    

    My approach - 

    Added MAECReference number to malware object:

    

    malware: {

    .....

    MAECReference: "MAEC-nnn-nnn-nnnn"

    }

    

    MAEC: { id: "MAEC-nnn-nnn-nnnn"

    ...

    }

    

    Ingore the id for MAEC, it is a made up id.

    

    Is this a legit way? Can we use MAECRefernce as a custom attribute to accomplish this objective?

    

    Looking forward to guidance.

    Thanks

    Subodh

This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not
 the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not
 the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.