Customizing the platform: tagging networks and inbound/outbound connections

[Anonymous]

Hi, this is the first of a few articles I'm going to publish on different topics and the first topic we are going to discuss is about customizing the platform to get more value out of it or to achieve complex use cases.

In this post I want to share some simple application rules intended to promote a standard naming convention and approach to "tag" inbound/outbound connections as well as to name our networks.

Understanding which connection is going in or out our network is key to better focus our investigation, running our reports, configuring our alerts and could apply nicely to both logs and packets (of course provided we have both source and destination IPs to work with).

Tagging our network is instead very important to better determine which service is impacted, evaluate the risk accordingly and prioritize our followup actions.

In order to use the content attached to this pos,t we need first of all we need to create the following custom meta keys:

• Source/Destination Network Class (net.src, net.dst): this is to identify if a session is coming/going to an IP internal or external to our organization (e.g. intranet, extranet)
• Source/Destination Network Name (net.name.src, net.name.dst): this is for (optionally) "tag" the source/destination network with a specific name (e.g. finance, workstation, etc.)
• Source/Destination Network Environment (net.env.src, net.env.dst): this is for (optionally) "tag" the source/destination network environment with a specific name (e.g. production, test, development, etc.)
• Direction (direction): this is for tagging the connection as inbound or outbound

Then the application rules provided will populate the net.src and net.dst meta accordingly with:

• intranet (if coming/going to a RFC 1918 IP)
• extranet (if coming/going to a NOT RFC 1918 IP)

And the direction meta with:

• intranet (intranet to intranet communication)
• external (extranet to extranet communication)
• inbound (extranet to intranet communication)
• outbound (intranet to extranet communication)

The meta net.name.src, net.name.dst, net.env.src and net.env.dst are not instead populated by the application rules but can be optionally be populated by a custom feed.

The application rules, the custom decoder and concentrator index files, sample feeds as well as screenshots are provided in attachment.

Disclaimer: please DO NOT consider what is described and attached to this post as RSA official content. As any other unofficial material, it has to be tested in a controlled environment first and impacts have to be evaluated carefully before being promoted in production. Also note the content I publish is usually intended to prove a concept rather than being fully working in any environments. As such, handle it with care.

[RSAAdmin]

Nice post Davide! It helped me to figure out how to add custom meta key/values.

No offence to you but I want to share this piece of information for people, like I used to be, who had no idea how to put that in place.

---------------------------------------------

net.src, net.dst and direction (you have to put net.src and net.dst if you want to get direction

1. Add meta keys

1.1 Add the following line to index-concentrator (Administration > Services > Log Decoder > Files >index-concentrator.xml)

     <key description="Source Network Class" level="IndexValues" name="net.src" valueMax="100" format="Text"/>

     <key description="Destination Network Class" level="IndexValues" name="net.dst" valueMax="100" format="Text"/>

     <key description="Direction" level="IndexValues" name="direction" valueMax="100" format="Text"/>

1.2 Add the following line to index-decoder (Administration > Services > Log Decoder > Files >index-decoder.xml)

     <key description="Source Network Class" level="IndexNone" name="net.src" format="Text"/>

     <key description="Destination Network Class" level="IndexNone" name="net.dst" format="Text"/>

     <key description="Direction" level="IndexNone" name="direction" format="Text"/>

2. Add the mecanism to populate the meta keys

2.1 Add App rules (Administration > Services > Log Decoder > App Rules)

     name=intranet rule="ip.src = 10.0.0.0/8 || ip.src = 172.16.0.0/12 || ip.src = 192.168.0.0/16" alert=net.src order=1 type=application

     name=intranet rule="ip.dst = 10.0.0.0/8 || ip.dst= 172.16.0.0/12 || ip.dst = 192.168.0.0/16" alert=net.dst order=2 type=application

     name=extranet rule="ip.src != 10.0.0.0/8 && ip.src != 172.16.0.0/12 && ip.src != 192.168.0.0/16" alert=net.src order=3 type=application

     name=extranet rule="ip.dst != 10.0.0.0/8 && ip.dst != 172.16.0.0/12 && ip.dst != 192.168.0.0/16" alert=net.dst order=4 type=application

     name=outbound rule="net.src = 'intranet'  &&  net.dst = 'extranet'" alert=direction order=5 type=application

     name=inbound rule="net.src = 'extranet'  &&  net.dst = 'intranet'" alert=direction order=6 type=application

     name=internal rule="net.src = 'intranet'  &&  net.dst = 'intranet'" alert=direction order=7 type=application

     name=external rule="net.src = 'external'  &&  net.dst = 'external'" alert=direction order=8 type=application

3. Apply the new config

3.1 Restart the Log Decoder service (Administration > Services > (check Log Decoder) > (select restart))

Explanation:

When we add meta keys, it adds a new kind of data we can associated with the event. In our case the italic is our meta keys.

ip.src	net.src	ip.dst	net.dst	direction

Then we add a rule which the log decoder will look up. Here is an example of how the meta value is generated.

1. The log decoder receive the raw event. Here is an example:

%ASA-6-232323: Teardown TCP connection 45454545 for service:4.4.4.4/11 to inside:192.168.11.11/24 duration 0:00:00 bytes...

2. The log decoder parse the content:

device.type	ip.src	net.src	ip.dst	net.dst	direction
ASA	4.4.4.4		192.168.11.11

3. Then our rules are applied, which fill in the meta values.

device.type	ip.src	net.src	ip.dst	net.dst	direction
ASA	4.4.4.4	extranet	192.168.11.11	intranet	inbound

----------------------------------------------------------------------------------------

net.name.src, net.name.dst, net.env.src and net.env.dst

1. Populate the .csv

1.1 Fill-up the file with your own info (see exemple under the file, you should be able to figure out)

2. Create a custom feed

2.1 ....

1. Add meta keys

1.1 Add the following line to index-concentrator (Administration > Services > Log Decoder > Files >index-concentrator.xml)

     <key description="Source Network Name" level="IndexValues" name="net.name.src" valueMax="1000" format="Text"/>

     <key description="Destination Network Name" level="IndexValues" name="net.name.dst" valueMax="1000" format="Text"/>

     <key description="Source Network Environment" level="IndexValues" name="net.env.src" valueMax="100" format="Text"/>

     <key description="Destination Network Environment" level="IndexValues" name="net.env.dst" valueMax="100" format="Text"/>

1.2 Add the following line to index-decoder (Administration > Services > Log Decoder > Files >index-decoder.xml)

     <key description="Source Network Name" level="IndexNone" name="net.name.src" format="Text"/>

     <key description="Destination Network Name" level="IndexNone" name="net.name.dst" format="Text"/>

     <key description="Source Network Environment" level="IndexNone" name="net.env.src" format="Text"/>

     <key description="Destination Network Environment" level="IndexNone" name="net.env.dst" format="Text"/>

2. Build up the list of meta values to insert under those meta keys

2.1 Fill-up the .csv file with your own info (see exemple under the file, you should be able to figure out)

3. Add the mecanism to populate the meta keys

3.1 Create a custom feed and select the .csv file

3.x  ...

Explanation:

When you create the custom feed, after log decoder has parse the content, it will lookup .csv file trying to find a match with "Index column" you specified in the custom feed.

Cheers!

[BrianHoward]

What would the xml file for the custom feed look like?

Here is what I have so far based on the csv examples in the attachment.

<FDF>

  <FlatFileFeed name="Network Sources" path="networks-src.csv" separator="," comment="#">

    <LanguageKeys>

      <LanguageKey name="netenvironment" valuetype="Text" srcname="net.env.src" dstname="net.env.dst" />

      <LanguageKey name="netname" valuetype="Text" srcname="net.name.src" dstname="net.name.dst" />

    </LanguageKeys>

    <Fields>

      <Field index="1" type="index" range="cidr" />

      <Field index="2" type="value" key="netenvironment" />

      <Field index="3" type="value" key="netname" />

    </Fields>

  </FlatFileFeed>

</FDF>

[Anonymous]

Hi Brian,

Your XML feed definition looks ok to me, you should see the data populated by the feed into net.env.src/net.env.dst and net.name.src/net.name.dst.

Thanks

[RSAAdmin]

Thanks for your post, I tried this and I can see entries now where IP.src or ip.dst meta doesn't exist in log but netname.src and netname.dst meta loaded as external. (netname.src and netname.dst is the meta name i gave for networks)

My app rule:

Extranet ip.src != 10.0.0.0/8 && ip.src != 172.16.0.0/12 && ip.src != 192.168.0.0/16

Extranet ip.dst != 10.0.0.0/8 && ip.dst != 172.16.0.0/12 && ip.dst != 192.168.0.0/16

[RSAAdmin]

Maybe this could help (not tested)

Extranet ip.src exist && ip.src != 10.0.0.0/8 && ip.src != 172.16.0.0/12 && ip.src != 192.168.0.0/16

Extranet ip.dst exist && ip.dst != 10.0.0.0/8 && ip.dst != 172.16.0.0/12 && ip.dst != 192.168.0.0/16

[Anonymous]

Hi, I'd agree with the solution provided by @jive33, that is refining the app rul to handle the exception when no IP is available which would otherwise result in a wrong match.

Thanks

[RSAAdmin]

It worked...Thanks!

But in certain logs we have ip.dst meta loaded with null values...how to exclude those in app rule?

[Anonymous]

Hi, do you mean you have a value in ip.dst which is "null"? This sounds strange since ip.dst is a IPv4 type so shouldn't allow null values. But assume you have a "null" value, you may want to add a ip.dst != null in addition to the other conditions.

[KEVINDIENST]

Using ip.src != null wouldn't validate successfully. If I put quotes around it then the App Rule GUI validated it.

Still unsure if that'll actually work or if the decoders will interpret the 'null' literally.

UPDATE: I just tested this and it is a little strange, I'd expect the app rule to actually function in two ways, it checks if the value of ip.src is not null, meaning it has a value, which implicitly means that ip.src exists. This isn't the behavior I'm seeing with this product however. I may have to check first if the meta exists, then if it isn't null and then the IP ranges. Will update if I get this successfully working.

FYI - The reason I need this verification is because we have logs from Windows Snare agents where we have ip.src/ip.dst meta created but there isn't anything actually in the meta key. Probably should open case with RSA and/or Snare.

UPDATE 07-22-2015: We've now had these app rules in place for some time and functioning except I've run into new 'challenges'. The checkpointfw1 and paloaltonetworks logs already populate the 'direction' tag with their interpretation of direction based off what interface the traffic is originating from and destined to and this becomes an issue if you want to use the data in an ESA alert. The reason is that now you have multiple 'direction' tags in the stream and when ESA receives it ESA only looks at the first value for conditional checks.

My options:

• Update the direction tag to use 'direction_custom' or something that won't already exist in a parser
• Change the ESA alert to set the condition for direction as an array (but still may not work as expected)
• Change my ESA alert condition entirely to look directly at the IP src and dst meta and exclude RFC1918 (in my use case I want to see external bruteforce attempts against common service types like SSH and RDP).

In this case I think setting the direction meta to something custom will be easier to implement and reduce likelihood of FP based off additional meta tags.