Check Point ASIM Firewall parser incorrect assumption that `CommunicationDirection` maps to `NetworkDirection`

[JPvRiel]

Cannot correctly use this to set network direction given it there is seldom any context if the interface (ifname) is an external vs internal interface.

• CommunicationDirection seems to be Micrsoft's obscured remapping from deviceDirection in the CEF extensions (guessing what Microsoft maps where from extensions in the CommonSecurityLog table is not fun / black-box?).
• deviceDirection is in fact the ifdir (interface direction), so this is a direction from the perspective of an interface?
• But there is often not enough context to know if a given interface is on an internal or external zone?
• Therefore misleading NetworkDirection mappings can result.
  • E.g. "inbound" from the interface perspective where the interface is on an internal zone could actually be "outbound" traffic from a network perspective?

As per

Azure-Sentinel/Parsers/ASimNetworkSession/Parsers/vimNetworkSessionCheckPointFirewall.yaml

Line 310 in 0776c20

CommunicationDirection == "0", "Inbound",

In the case block:

                NetworkDirection = case(
                                    isnotempty(NetworkDirection), NetworkDirection,
                                    inzone == "Internal" and (outzone == "Internal" or outzone == "Local"), "Local",
                                    (inzone == "Internal" or inzone == "Local") and outzone == "External", "Outbound",
                                    inzone == "External" and (outzone == "Internal" or outzone == "Local"), "Inbound",
                                    CommunicationDirection == "0", "Inbound",
                                    CommunicationDirection == "1", "Outbound",
                                    ""
                                    ),

CommunicationDirection which Microsoft presumably mapped from the CEF Extension field deviceDirection assumes this the "Network" direction and maps it directly. At least it only does that if better choices couldn't be matched, but it could end up incorrect regardless.

As per other references:

Log Exporter CEF Field Mappings and Description of Fields in Check Point Logs

• deviceDirection is the exported name from an original field ifdir.
• ifdir was in the list described as "Disclaimer - These fields are only used for Check Point internal purposes" implying it shouldn't be relied on.

Given checkpoint does log the ifname, it seems ifdir means which direction is the traffic arriving through the interface. However, the problem is a firewall can have multiple interfaces and the Extensions in CEF don't seem to tag/label if the interface is external or not.

To double check the issue, I was able to find CheckPoint events where the ifdir / deviceDirection = 0 (inbound) meanwhile conn_direction = Outgoing was set so it's very possible these fields can contradict given they are for different perspectives (interface vs network zones).

[v-tsawant]

Hi @JPvRiel , Thanks for flagging this issue, we will investigate this issue and get back to you with some updates. Thanks!

[vakohl]

@JPvRiel great find. Thankyou

Here's what I'm thinking to make updates in parser:

NetworkDirection = case(
isnotempty(NetworkDirection), NetworkDirection,
inzone == "Internal" and (outzone == "Internal" or outzone == "Local"), "Local",
(inzone == "Internal" or inzone == "Local") and outzone == "External", "Outbound",
inzone == "External" and (outzone == "Internal" or outzone == "Local"), "Inbound",
""
)

And

// Note: CommunicationDirection is based on deviceDirection from CEF, which reflects traffic direction relative to a device interface,
// not necessarily the security boundary. It's preserved in AdditionalFields for reference but not used to set NetworkDirection.
| extend AdditionalFields = bag_pack("CommunicationDirection", tostring(CommunicationDirection))