Re: [cti-cybox] Network Connection Object TCP Extension

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

TCP flags and ICMP type/code have actual known CTI use cases (we look at them at least).. that's why they ended up being included vs. all other headers. If there are actual use cases "in the wild" for the other headers we should bring them up... otherwise not sure why we should include them... we can always add them later.

-
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


Terry MacDonald ---08/31/2016 05:58:12 AM---Not necessarily the whole header right now, but we need to leave things so they can be extended if t

From: Terry MacDonald <terry.macdonald@cosive.com>
To: Bret Jordan <bret.jordan@bluecoat.com>
Cc: OASIS CTI TC CybOX SC list <cti-cybox@lists.oasis-open.org>
Date: 08/31/2016 05:58 AM
Subject: Re: [cti-cybox] Network Connection Object TCP Extension
Sent by: <cti-cybox@lists.oasis-open.org>

---

Not necessarily the whole header right now, but we need to leave things so they can be extended if the community wants them to in the future. I guess the point is that we need to think about the future to some degree, allowing for future expansion, not locking things down now and removing the chance for future enhancements like this.

Cheers
Terry MacDonald
Cosive

On 31/08/2016 10:44, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

Do we really want to rebuild or capture the entire IP/TCP header in CybOX?  Does that really make sense when there are other solutions that arguably do this much better?  I think CybOX should capture the high level things that are important that meet the 80-90% use case and leave those other nitty-gritty things for another solution. 

I could see this network connection just having a hex encoded libpcap or libpcap-ng data blob if you really wanted to to capture the packet, datagram, or frame headers. 


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:45, Terry MacDonald <terry.macdonald@cosive.com> wrote:


I think we should keep them apart, but maybe with additional TCP fields in them like mss, tos, maybe even a boolean field for fragmented, and maybe a list of TCP options in there too.

Cheers
Terry MacDonald
Cosive


On 31/08/2016 08:46, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
Given that the 90-95+% use case for the network connection object will be TCP and UDP, the src/dst port information was moved to the base object instead of having a UDP extension and a TCP extension.  However, when this was done two fields were left in the new somewhat errant TCP extension. Namely the src/dst "flags"

I would propose that it does not make sense to have this TCP extension with just 2 properties that are flags, when the port information was merged down to the base object.  

So I see two proposals to this issue:

1) We also merge down the TCP flags and leave them as optional, similarly to what we did with the port information. 

2) We rename the TCP Extension to be TCP/UDP Extension and put the port information back in it.  


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."