Sept 2024 pass at OCSF/DEFEND mappings

[ryantxu1]

Adding a few D3FEND mappings to OCSF.

Objects changed:

• registry_value
• account
• container
• database
• fingerprint
• group
• http_cookie
• job
• script

Noticed a minor typo in http_header

[netfl0]

A script can manifest as a file or a string-based commandline argument in the case of powershell.

Curious if OCSF is wanted to make such a distinction.

consider this shadowcat example:

D3FEND CAD Shadowcat example

[davemcatcisco]

Just to clarify, the file-less script case is more than just a string-based command line:

• It may be read by an interpreter from stdin.
• It may be embedded within a container document, e.g. VBA macro in a Word document or Excel sheet.
• It may be dynamically executed as a sub-script of another script, e.g. a sub-script that results from deobfuscation, a sub-script that is downloaded, etc.

[pagbabian-splunk]

I would check with @davemcatcisco who authored the script class and object.

[netfl0]

@davemcatcisco would be happy to hear your thoughts. Please see the CAD example above.

[davemcatcisco]

As you can see, I wrote the above comment two weeks ago but then forgot to submit the review until now. I'm just pointing out that a file-less script execution can happen in a lot of ways beyond a PowerShell command line.

I'm afraid I'm not sure what you mean when you say you're curious if OCSF wants to make a distinction. Can you clarify?

[netfl0]

looks good save for a potential distinction OCSF might want to make regarding scripts as cmd line args. They might have already discussed this somewhere but it was not jumping out at me.

[floydtree]

Thanks for doing this! A general question, based on your review of the objects you updated, do you see a need to add more attributes in any of the objects? Any pertinent gaps in an OCSF object when compared to it's d3fend counterpart?

[netfl0]

Thanks for doing this! A general question, based on your review of the objects you updated, do you see a need to add more attributes in any of the objects? Any pertinent gaps in an OCSF object when compared to it's d3fend counterpart?

There is quite a bit more we can do, in general we're looking to incorporate "data properties" from OCSF into D3FEND, since they are precisely what the community needs. This was an intentional and planned on our part.

We want to synchronize "object properties" between OCSF and D3FEND but that is going to require further discussion and modeling.

[ryantxu1]

There are a few instances where there are related D3FEND and OCSF objects, but the definitions don't align perfectly. Do we want to still relate those with "See also in D3FEND..." or something similar?

D3FEND	OCSF
d3f:Authorization	Authorization
d3f:HardwareDevice	Device Hardware Info
d3f:DomainRegistration	Domain Contact
d3f:SystemFirewallConfiguration or d3f:Firewall	Firewall Rule

[jonrau-at-queryai]

There are a few instances where there are related D3FEND and OCSF objects, but the definitions don't align perfectly. Do we want to still relate those with "See also in D3FEND..." or something similar?

D3FEND OCSF
d3f:Authorization Authorization
d3f:HardwareDevice Device Hardware Info
d3f:DomainRegistration Domain Contact
d3f:SystemFirewallConfiguration or d3f:Firewall Firewall Rule

If it's pertinent enough, I think it's worth the callout. I did domain_contact for the larger osint object (and Profile/Discovery event) and would find that valuable.

Overall the more specific examples or further reading we can do for descriptions and captions, the better it is overall, both producers and consumers alike.

[pagbabian-splunk]

These all look good using the current form of relationships to d3fend artifact definitions. However now that we have references and source metashema, we are looking at either using those mechanisms or using a specific ontology meta schema keyword(s) that have been proposed by @netfl0 . We would then convert these to using the keywords, and back port the existing linkages.