Re: [cti] RE: [Non-DoD Source] Re: [cti] RE: [EXT] Re: [cti] Possible Changes to Observed Data

["Jane Ginn @ OASIS" <jg@ctin.us>]

Gary:

The proposal you outline on your PowerPoint makes a lot of sense. As we
move forward with the Infrastructure object, and see overlapping
malicious infrastructure (or even Tool objects) this will be a way to
surface those relationships. As I understand your proposal, this will
allow us to pivot on the Observed Data object, which will be very useful
during a hunting expedition.Â

For the Malware object I can see us using it to characterize multiple
uses of the same malware. If we take the recent Mueller Indictment of
the 12 GRU operatives as an example, we saw that the threat actors used
the X-Agent Malware on the DCCC (Victim 1), and then again on the DNC
(Victim 2). And, we saw that the X-Tunnel Malware was used to
exfiltrate documents from each of the separate victims.Â

As an analyst, I want to be able to see the multiple uses of X-Agent on
the different victims. One way to see that overlap would be to use the
parent_nodes property that you suggest for the Observed Data object. It
would allow me to "see" the connection (on a Graph) representation,
without being overwhelmed by all of the related nodes. For example, if
76 'hosts' within Victim 1 were infected with X-Agent, I don't want to
be swamped with all of the infected hosts when I'm searching for
connections to other related Campaigns on Victim 2. I may only want to
see Patient Zero or a specific Cyber Observable such as a binary or
executable file. This would help me filter out the noise and use
deductive logic to draw a relationship between the two separate Campaigns.Â

Jane


On 8/21/2018 11:47 AM, Katz, Gary CTR DC3/TSD wrote:
> To Sarah's point, I would like to provide an overview of how Cyber Observables could be updated to support the new use cases.  These updates were based upon a discussion with Ivan and Jeff prior to being turned into a power point.  The power point was developed with the idea that someone would be speaking to the slides, so I apologize if anything is obtuse.  By making a couple of changes to the Cyber Observable object, we should be able to accommodate new use cases.  Obviously, as we continue to refine Infrastructure Malware, and Incident we will need to confirm that these changes do support their use cases but it looks like this would be a solution to meet Option 1.
>
> Comments or questions welcome.
>      -Gary
>
> -----Original Message-----
> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Trey Darley
> Sent: Thursday, August 16, 2018 8:43 AM
> To: Kelley, Sarah E. <skelley@mitre.org>
> Cc: cti@lists.oasis-open.org
> Subject: [Non-DoD Source] Re: [cti] RE: [EXT] Re: [cti] Possible Changes to Observed Data
>
> On 16.08.2018 12:07:33, Kelley, Sarah E. wrote:
>> Since the whole reason weâre contemplating changing how observed data 
>> works is so that it fits for new use cases like malware and 
>> infrastructure, Iâd like to suggest that we should hold off on making 
>> a decision on how to change observed data until we know that it will 
>> actually work with these new proposed objects. Since we pushed malware 
>> from CSD01, and infrastructure was never in it, I think we should hold 
>> off on making any changes to the observed data object until we can 
>> work through these objects at the same time. Otherwise we could wind 
>> up making changes now that ultimately will need to be changed again if 
>> they donât work for malware/infrastructure, etc.
>>
> That would be my preference, Sarah. We should back out the changes to Observed Data and issue draft-03.
>
> As an editor, I understand the pressure to resolve comments and get drafts out for review promptly. However Bret's suggested changes to Observed Data were accepted into draft-02 without being adequately discussed. (Neither Ivan Kirillov nor myself were consulted; as the Cyber Observable co-chairs, at the very least this should have
> happened.)
>
> In fact, we *should* have discussed this on a TC working call. As you rightly point out, the TC needs to validate that these changes to Observed Data are adequate to address the needs of Malware and Infrastructure.
>
> There are still a fair number of folks out on summer vacation. I recommend that we dedicate the entire working calls 11 & 18 September to discussing this with a larger audience. (The week of 03 September being US Labor Day holiday period, we'll likely have lower participation on the 04 September working call.)
>
> As Ivan and I are the Cyber Observable co-chairs and as we led the work on Malware, we will happily lead this discussion. If the TC elects to go this route, Ivan and I will work with together the TC membership to assemble a set of questions which will allow us to validate that the changes we make to Observed Data are fit-to-purpose for Malware and Infrastructure, and that they do not negatively impact STIX Patterning.
>
> --
> Cheers,
> Trey
> ++--------------------------------------------------------------------------++
> Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
> ++--------------------------------------------------------------------------++
> --
> "You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away."
> --Antoine de Saint-ExupÃry

-- 
R. Jane Ginn, MSIA, MRP
Secretary, Cyber Threat Intelligence Technical Committee (CTI TC)
OASIS
jg@ctin.us
+1(928)399-0509