>Along with the whole DomainName is in the URI Object, yet FQDN and Top Level Domain are in the DomainName Object (that one has always puzzled me!).
That’s something we should revisit soon; my hope is that we can run through the “simple” Objects (URI, DomainName, etc.) in one go and make any necessary changes there.
>As for the additional objects, I would say that ASN should be recorded in the separate object. Using relationships will allow us to use one AS object and relate the IP addresses within that AS to the
AS number easily.
I agree, and it’s worth noting that we already have an AS Object [1] that captures AS Name, Number, and some other properties.
>I do think that we need a way of tracking the Assigned IPv4 and IPv6 addresses compared to AS number as well, such as assigned by Regional Internet Registries (https://www.apnic.net/publications/research-and-insights/by-rir).
I’m not sure if I’m understanding this correctly; are you suggesting that we add the ability to associate an IPv4/IPv6 address with its assigning RIR?
>The rest of the objects listed (ATM, IPv4 Netmask and IPv6 Netmask) don’t need to be moved to CybOX 3 right now. If there is a need for them in the future then we can add them in a dot release.
Agreed!
[1] http://stixproject.github.io/data-model/1.2/ASObj/ASObjectType/
Regards,
Ivan
From: Terry MacDonald <>
Date: Monday, February 22, 2016 at 2:43 PM
To: Ivan Kirillov <>, "" <>
Subject: RE: Common CybOX Object Refactoring
Hi Ivan,
Address object:
I really like the separating into different objects. In training that I’ve done in the past it’s invariably been the first question – why are email
addresses in the same object as IP addresses? Along with the whole DomainName is in the URI Object, yet FQDN and Top Level Domain are in the DomainName Object (that one has always puzzled me!).
As for the additional objects, I would say that ASN should be recorded in the separate object. Using relationships will allow us to use one AS object
and relate the IP addresses within that AS to the AS number easily.
I do think that we need a way of tracking the Assigned IPv4 and IPv6 addresses compared to AS number as well, such as assigned by Regional Internet
Registries (https://www.apnic.net/publications/research-and-insights/by-rir). This is important for discovering bulletproof hosting environments whose entire infrastructure aand
IP address rangers can be blocked as they are full of maliciousness.
The rest of the objects listed (ATM, IPv4 Netmask and IPv6 Netmask) don’t need to be moved to CybOX 3 right now. If there is a need for them in the
future then we can add them in a dot release.
File Object:
It looks very logical. I’m not a host forensics guy, but I do like it.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
From:
[mailto:]
On Behalf Of Kirillov, Ivan A.
Sent: Tuesday, 23 February 2016 2:36 AM
To:
Subject: [cti] Re: Common CybOX Object Refactoring
I’d like us to get to consensus on the Address and File Object refactoring; I’ve highlighted some of the open questions and current consensus below. If there
are no additional thoughts/comments by the end of the week, then I’d suggest that consensus has been reached.
Address Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Address-Object-Refactoring
Open questions:
Should Email Address be a separate Object, or should it instead be a property of a different Object (e.g., User Account)?
Current consensus: Email Address should be a separate Object, for purposes of sharing individual email addresses
(e.g., as associated with a Threat Actor)
File Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring
Open questions:
Are there any additional properties that belong in the base set of properties or basic set of file system properties?
Current consensus: no additional properties have been raised.
Which default extensions should be included with the Object?
Current proposed list:
File Metadata
EXT3 File
NTFS File
Image File (based on existing Image File Object)
PDF File (based on existing PDF File Object)
Archive File (based on existing Archive File Object)
PE Binary File (based on existing Windows Executable File Object)
Regards,
Ivan
From:
Ivan Kirillov <>
Date: Tuesday, February 9, 2016 at 11:52 AM
To: "" <>
Subject: Common CybOX Object Refactoring
Sending this to the broader CTI list since it’s part of the STIX/CybOX Indicator tranche.
Here’s a summary of the status of the refactoring of the most commonly used CybOX Objects (based on CTI-stats). Please let us know if you don’t agree with
the consensus status for Address and File, and also if you have any input on their open questions.
Address Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Address-Object-Refactoring
Consensus largely reached
Open questions:
Should Email Address be a separate Object, or should it instead be a property of a different Object (e.g., User Account)?
Artifact Object
Not discussed yet
May require some changes
Domain Name
Not discussed yet
Likely requires very little in the way of changes
Email Message
Not discussed yet
May require some changes; we’re considering creating a base “Message” Object for use in Email Message as well as SMS Message
File Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring
Consensus largely reached
Open questions:
Are there any additional properties that belong in the base set of properties or basic set of file system properties?
Which default extensions should be included with the Object?
Current proposed list:
File Metadata
EXT3 File
NTFS File
Image File (based on existing Image File Object)
PDF File (based on existing PDF File Object)
Archive File (based on existing Archive File Object)
PE Binary File (based on existing Windows Executable File Object)
Hostname
Not discussed yet
Likely requires very little in the way of changes
HTTP Session
Not discussed yet
May require some significant refactoring, related to the refactoring of Network Connection
Link
Not discussed yet
Likely requires very little in the way of changes
Memory
Not discussed yet
May require some changes
Mutex
Not discussed yet
Likely requires very little in the way of changes
Network Connection
Not discussed yet; proposal forthcoming
May require significant refactoring
PDF File
Not discussed yet
May require some changes; likely to be included as an extension of the File Object
Port
Not discussed yet
Likely requires very little in the way of changes
URI
Not discussed yet
Likely requires very little in the way of changes
WhoIS
Not discussed yet
May require some changes
Windows Executable File
Not discussed yet
May require some changes; see https://github.com/CybOXProject/schemas/issues?q=windows+executable+file+is%3Aopen
Windows Registry Key
Not discussed yet
Likely requires very little in the way of changes
Accordingly, I would propose grouping and timeboxing the refactoring discussions as such:
Network Object Refactoring – Network Connection and HTTP Session
2 weeks
Messaging Object Refactoring – Email Message and SMS Message
1 week
Other Atomic Network Object Refactoring – Domain Name, Hostname, Port, URI, and Link
1 week
Host Object Refactoring – Windows Executable File, Windows Registry Key, PDF File, and Mutex
1 week
Other Object Refactoring – WhoIS and Artifact
1 week
Regards,
Ivan
