cti-cybox message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-cybox] IPv4 and IPv6 Address Objects
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Jordan, Bret" <bret.jordan@bluecoat.com>
- Date: Wed, 31 Aug 2016 08:19:51 -0300
Actually - when trying to write this example, I have run into another issue WRT patterning and our decision for some list properties to be able to continue multiple types simultaneously, along with the "always deref" decision.
Take the network-connection src_ref type. How would I write a pattern comparing this against a MAC address?
You can't simply do this:
network-connection-object:src_ref.value = '42:29:82:8d:b5:a9'
.. because there is no way for me to declare that the type is a IPv4 address and not something else
It is like you *always* have to write the type...
network-connection-object:src_ref.type = 'ipv4-address-object' AND network-connection-object:src_ref.value = '1.2.3.4'
... this will be quite cumbersome...
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
"Jordan, Bret" ---08/30/2016 08:15:28 PM---Can we see how pattern would be affected by this? Thanks,
From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Terry MacDonald <terry.macdonald@cosive.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "Mates, Jeffrey CIV DC3DCCI" <Jeffrey.Mates@dc3.mil>
Date: 08/30/2016 08:15 PM
Subject: Re: [cti-cybox] IPv4 and IPv6 Address Objects
Sent by: <cti-cybox@lists.oasis-open.org>
Can we see how pattern would be affected by this?
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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."
On Aug 30, 2016, at 17:01, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:
I would much rather keep these separate. If you comvine them with some kind of "address type" property, it will make patterning very cumbersome vs just having discrete objects. I don't really see how having discrete objects for these two has a downside.
--
Sent from my mobile device, please excuse any typos.
Jordan, Bret --- Re: [cti-cybox] IPv4 and IPv6 Address Objects ---
There is not really anything from an address perspective that you would extend this with that would not be the same for both. I could see if we were talking about a different protocol other than IP.
I mean you are not going to include anything from the packet headers... The only thing I could think of is if you wanted to say you got the address in IPv4 from DHCP or in IPv6 from stateless or stageful auto-config
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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."
On Aug 30, 2016, at 15:41, Terry MacDonald <terry.macdonald@cosive.com> wrote:
We may extend those objects in the future, so it potentially makes sense to keep these separate to allow that to happen. We gain flexibility by keeping them separate.
Cheers
Terry MacDonald
Cosive
On 31/08/2016 08:55, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
Well for IPv4 and IPv6 the address field is just a string. So when you unmarshall the data in to your struct, it does not really matter you will have the same amount of processing either way. Right now you have to unmarshall the object before you can figure out the "type" anyway. So no difference.
If we were going to have protocol specific fields in the object, then I would agree with you. But given how they are identical and I can not see us adding much to them over time, I question which way makes more sense.
This would be attune to the labels that we do all over the place in STIX. Now I am not advocating that we have this be a general purpose Address object... I think it should be an IP object..
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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."
On Aug 30, 2016, at 14:38, Mates, Jeffrey CIV DC3\DCCI <Jeffrey.Mates@dc3.mil> wrote:
I think it had to do with the fact that we were trying to avoid the generic
CybOX 2 Address Object that could store an email address, IPv4 or IPv6
address with the type determined by a separate field.
I also don't think that JSON has anything like the XSD choice, so it
wouldn't be possible to have dedicated ipv4 and ipv6 tags that are mutually
exclusive in a larger address object. So you would need something like:
{"type":"IP","format":"ipv6","address":"1234::5678"}
While this format is human readable it adds an additional step to machine
validation. This is because unlike other object types you would need to
read in a format tag, which would then determine your parsing rule for your
address tag rather than just reading in the tag you wanted to validate.
Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335
-----Original Message-----
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Tuesday, August 30, 2016 4:27 PM
To: OASIS CTI TC CybOX SC list
Subject: [Non-DoD Source] [cti-cybox] IPv4 and IPv6 Address Objects
I find it interesting that we have two identical objects, one for IPv4 and
IPv6. This was probably discussed at length in the past, but I am curious
to know the rational for having two objects vs just having an "IP" object
with a label of ipv4 or ipv6.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO Blue
Coat Systems 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."
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]