Network Traffic Object - Denied Access vs. Allowed

[ikiril01]

Jason pointed out that we currently can't characterize whether some network traffic was denied/blocked access or allowed in the Network Traffic Cyber Observable Object.

[gtback]

I wonder if this above the scope of the network traffic object itself. It seems more like metadata about how the traffic was handled. Also, can "blocked" potentially be applied to more than just network traffic?

[ikiril01]

Yeah, I agree - this seems to be firewall/IDS related metadata that probably doesn't belong at the level of the Network Traffic object itself.

[JasonKeirstead]

So, I somewhat disagree. A flow being blocked is an attribute of the flow itself, not of a firewall or anything else. IE - even if we had some way to model firewall rules, it would not solve this use case. This use case is required to properly model a lot of malware on a windows machine - you need to be able to model if the request outbound from the host was successful or not. In this case there may not even be a firewall.

[JasonKeirstead]

Use case: Excessive denied SMB traffic from a host, indicative of malware scanning the network for open shares.

[gtback]

So what I'm hearing is that you (somewhat) agree 😁

I tend to think of Cyber Observables as representing chunks of bytes which you can put a clear boundary around, and properties of those observables as being things that can be determined by analyzing just things inside that boundary, and that no reasonable person would disagree with.

To be honest, things like File.is_encrypted stretch that definition slightly, and make me slightly uncomfortable. In the absence of a key, encrypted data should be indistinguishable from random data. But sometimes there are headers outside the "encrypted" part of a file that support the assertion that the file is encrypted. Plus, in combination with encryption_algorithm and decryption_key, a reasonable person would agree the file was encrypted if they could obtain "semantically meaningful" (which itself is a loaded definition) data after performing the decryption.

I'm trying to figure out how you would determine that a flow was blocked based on the bytes that constitute the flow, plus other properties you could put on the network traffic object (for verification, not just the assertion it was blocked). Maybe something in IPFIX like flowEndReason (I don't know really anything about IPFIX)?

Or maybe my characterization of Cyber Observables doesn't match that of others in the TC, and the consensus is we should allow more "interpretive" properties or properties that rely on external data.

[JasonKeirstead]

I don't think Observables being "chunks of bytes" is accurate. Observables is anything that can be observed, at all. It doesn't have to be bytes.

This is going to be especially relevant as we get into Actions... Actions are not sequences of bytes.

Look at Registry key entries - those are not "sequences of bytes". They are metadata in a storage medium.

Digital signatures - you can't tell if a signature is valid based on the bytes inside it alone.

It is also relevant here. I should not have to determine if the flow is blocked or not based solely on the bytes of the flow. I can look at many other things to determine that.

[gtback]

My "chunks of bytes" characterization is biased by my experience mostly being host-based and less network-based (and all of it being pretty dated at this point); the more relevant aspect is about what is observed as "part of" the object and what is observed "about" the object.

I'm having trouble articulating why I feel like a flow being blocked doesn't belong on the Network Traffic object. Maybe it's just that I feel like properties of Cyber Observable objects should only be used for intrinsic properties, and that "blocked" is more an extrinsic property.

[ikiril01]

I mostly share @JasonKeirstead's perspective here - I think if we were to couch Observables as only chunks of bytes, even things like filenames (which are just properties associated with the storage of a chunk of bytes on a filesystem or filesystem-like container) may be considered extraneous.

I think any properties we consider adding to Cyber Observable Objects should be 1) commonly documented/used and well understood, 2) directly support relevant CTI use cases, and 3) not be duplicative of other capabilities (especially Actions).

So in this case, I'm still in agreement with @gtback that this feels like an "extrinsic" property that deals with the state of the network traffic rather than the traffic itself. In addition, I'm wondering if this is something that would be better handled by Actions - e.g., a "send network traffic" Action that was unsuccessful because the traffic was blocked.

[treyka]

We definitely need this capability but first we need to finalize the concept of Actions in Observables and Patterning.