Create osint Profile

[jonrau-at-queryai]

Related Issue:

#988

Description of changes:

• Added osint object.
• Added osint Profile based on osint object.
• Added signatures object, an array of signature objects.
• Added subdomains object, an array of subdomain used to enumerate DGA-generated domains.
• Added whois object.
• Added contact and array-typed contacts object for use with whois object.
• Added is_self_signed Boolean attribute to certificate object.

Several dozen attributes were added to dictionary to support whois and contact.

[pagbabian-splunk]

Aside from this being really well worked out, it is also quite a substantial amount of STIX / TI specific information, with some naming questions here (some attributes are stix_ prefixed, a few are not but in their definitions they cite STIX).

I also feel there is enough to merit a "platform" of sorts where it can be package up within a core extension. I know that our core extensions today are "OS platform" extensions and STIX isn't exactly the same thing, but we can have OCSF extensions just like we can have vendor extensions. External standards can be modeled this way, keeping attributes in their own dictionary. The notation would already scope by extension name (e.g. stix/xx). Same can be done for d3fend, which we are considering for a Remediation category. Otherwise, the core dictionary will get very large and there will be a lot of external standards specific naming mixed in.

[jonrau-at-queryai]

Aside from this being really well worked out, it is also quite a substantial amount of STIX / TI specific information, with some naming questions here (some attributes are stix_ prefixed, a few are not but in their definitions they cite STIX).

I also feel there is enough to merit a "platform" of sorts where it can be package up within a core extension. I know that our core extensions today are "OS platform" extensions and STIX isn't exactly the same thing, but we can have OCSF extensions just like we can have vendor extensions. External standards can be modeled this way, keeping attributes in their own dictionary. The notation would already scope by extension name (e.g. stix/xx). Same can be done for d3fend, which we are considering for a Remediation category. Otherwise, the core dictionary will get very large and there will be a lot of external standards specific naming mixed in.

@pagbabian-splunk I agree on the overall approach. I feel we should go ahead and remove the stix_ related information from this and instead rework this object to be open_source_intelligent (or osint) as it'll pertain to only technical factors instead and be much simpler without STIX in scope.

review addressed

[floydtree]

Thanks for getting in all the feedback! I think we are almost there. I have added a few line specific comments, but in general, if we want this profile to be usable by event classes in the framework we need to add it to those classes. Currently, if you run the server locally, you'll notice the profile won't even be visible in the profiles page, since it's not registered with any class.

Having said that, I would expect this profile to be available for all the classes. If that's your intention as well, then you'll need to add it to the base_event definition - similar to how cloud, datetime are added. Happy to discuss further.

[floydtree]

Awesome, looks perfect now. Thanks.

[zschmerber]

Great work on this!