Note: To start this email, it took me a little bit of time to find the previously proposed refactoring so I could comment on it [1]. Would it make sense to start a spec type document so that these conversations can be tracked there? IMO something like
the twigs document but for CybOX (or even do these in the twigs document, then decide the tearline between STIX/CybOX later on would be fine). Just so long as we have text that we are continually updating as progress toward a spec I think we will be in good
shape.
Presuming we go with the optional /32, I would offer this text as a start:
Field Name: ipv4_address
Type: string
Description: An IP address or CIDR block denoting either a single IP address or a range of IP addresses, respectively. The accept syntax defines a required IP address (e.g., 1.2.3.4) with an optional subnet mask (e.g., /32). Omitted subnet masks MUST be
interpreted as “/32”.
Thank you.
-Mark
I think is a good way forward
Sent from my iPhone
This also makes great sense to me…
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
I rather agree with Alex that a lot of these Objects are created by hand today and likely will be for the foreseeable future, so I'm OK with specifying that if no CIDR block is found,
the IP Address is implicitly /32 (or /128 for IPv6). However, this is something we’ll need to make very clear in the specification and documentation. Are there any other thoughts on this?
People will be creating these objects by hand. However, if the standard allows for the lack of /32 to mean an individual IP address I think that’s
great.
Had the group ever considered the addition of a CIDR-specific object?
I think it is completely reasonable for the UI tool to add a /32 to an address. People should not be creating these objects by hand. Further, I also think it is also reasonable to to say that if no /32 is found, then it
is just an IP address and the standard should allow for that. Hopefully, long term, all tools will just do that for the user behind the scenes, but until then, I think it is okay for the standard to just allow it.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I thought I’d provide some context of how everyday threat intelligence analysts share IP addresses. On one fairly popular email list with ~650 active
participants, there were about 5,370 messages that contained tens of thousands of indicators of compromise (IOCs). In these messages:
· Analysts
shared individual IP addresses 4,695 times
· Analysts
shared a CIDR block 124 times
· Of
these 124 times, only 6 times were they referring to an individual IP address
· Of
these 6 individual CIDR blocks with /32, they were only one analyst ever referred to an IP this way
I continue to believe that, while it’s certainly a fine way to represent an individual IP address, most analysts don’t think to add it at the end
when they’re talking about an individual IP. My personal preference would be for the language to assume that if an IP address object doesn’t have a slash in the address or a CIDR property that it is assumed to be an individual IP address and neither the user
nor the tool needs to know to write /32 at the end of it.
I’m not intentionally trying to start a flame war, but I do continue to believe that (at least as long as people are still developing
the tools that use CybOX / STIX) we will have humans making it or consuming it manually / by hand.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important
terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.
If you are not the intended recipient, please delete this message.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important
terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not
the intended recipient, please delete this message.
|