Highlighted
Absent Member.
Absent Member.
435 views

Translated Address (Asset Modeling)

HI ArcSight Community,

Just wanted to ask about the translated address field, if we can supply this information in the asset modeling part.

For instance, there is a hits in the IPS that the attacker is 2.2.2.2 (for example)., looking at the target, the IP is 192.168.1.5 (DMZ IP).

I checked the FW and the attacker 2.2.2.2 has only communication to 11.11.11.11 (for example) which is the public IP of 192.168.1.5

Now, how can I relate 192.168.1.5 with 11.11.11.11 as its translated IP? How can I define this in the network modelling part?

Thank you in advance for the help.

Sincerely,

Alvin

0 Likes
4 Replies
Highlighted
Fleet Admiral
Fleet Admiral

Hi Alvin,

By default have ur Target(Internal) and Target Translated Address(Public) based on the base events.For devices like dns,proxy, web server,.... that will vary and captured in base events itself. And same for the ports too(Ex: 443,80,53..all default ports will remain same in both fields but the nonstandard ports will only vary)

When u define ur asset.. u are mapping the Zone/Location and Categories which are in DMZ as separate Group in asset right u will get those fields captured in different event fields.

So what are trying to achieve and what is the problem u facing now to achieve that?

0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Balahasan,

I believe you are trying to say that if the raw events has value and mapped as translated address, then we can get those, right? This is basically dependent of the generated logs, right?

Looking at the IPS, only target address has value which is the DMZ IP. Looking at the fw, both the Target address and the translated address are the public IP.. This mean no consistency on the logs.

This is the reason why I wanted to mapped this in the asset model level.

I will try what you have mentioned to separate the DMZ assets and I will feedback you.

Thank for the help.

0 Likes
Highlighted
Fleet Admiral
Fleet Admiral

Hi Alvin,

Ideally yes. If u have enabled Proxy, PAT or NAT in firewall which are placed in Perimeter the logs generated itself carry this mapped information else nothing.. So ArcSight will obvious try to map it with its CEF and if no Translated address found it will be empty.

And there is an option on Smart connectors for Translated Zone URI Mapping, I don't how this works coz I haven't tried but if u r working on test setup try it out and find out wat it does as per the Documentation, Map ur DMZ Zone as Default for tat Connector

0 Likes
Highlighted
Absent Member.
Absent Member.

We've been playing with this for about 2 years now and have a solution that works for us....not a perfect solution, but it works.

For 1-1 NAT, we create two assets, and then link the two assets with the alternate interface function.  We also enforce naming, so that it's semi-obvious if you read the asset name/host name that it's related.

For dynamic n-1 NAT, we use an asset with a name something clever like "external wireless NAT".

After that it's much bludgeoning of analysts to get them to remember that if the sensor is outside the NAT limit, they have to look at firewall logs and use translated addresses to see internal traffic.

Since event arrival time is not overly deterministic, I'm not sure there is a way for data from one connector (firewall) to update data from another connector (external ids) in any way where you can be SURE everything gets sorted out right.

Hope this helps

Don

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.