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.