CheckPoint Target User Name/Destination User Name displays ***Confidential*** not the actual name.

Upgrade to CheckPoint R75 caused the Target User Name/Destination User Name to display ***Confidential*** not the actual user name.    Per our Checkpoint Admins no authentication setting have changed to modify how ArcSight pulls the event data.

Has anyone undergone an upgrade to R75 and had a similar affect on the connector event flow for Target USer Name / Destination User Name?  Anyone have any thoughts on how this occurred and what needs to be checked / corrected to fix the data flow?


  • Hi Larry,

    The only way to address this from the ArcSight side of things is to take a look at the raw events that the connector is receiving. Maybe if you can determine that the event flow is coming in as ***Confidential*** you could have your CheckPoint administrators take another look? If you find that the RAW events contains the true target/destination user name and that the connector parsing is some how populating the fields with ***Confidential*** then I would open a support ticket as this is not expected behavior.

    For enabling raw events please see the following link (you will have to authenticate with your ArcSight support forum user)



  • Reviewed raw data.  Raw Data contains the "***Confidential***" statement for Checkpoint VPN events only - connector parses this into Target User Name and Destination User Name.   Per ArcSight Support this is a Checkpoint setting, however, they were not able to assist in identifying what setting needs to be changed to allow an opsec compliant device tha ability to see the VPN user ID within the VPN logs.

    Our Checkpoint Admins are bouncing it to ArcSight, ArcSight is bouncing it back to the Checkpoint Admins.  Neither group has been able to provide any guidance as of yet for what needs to be modified to allow access to the actual user name.

    Raw Data Example:

    time@=29Aug2011 17:45:33@&action@=keyinst@&orig@=3142250704@&i/f_dir@=inbound@&i/f_name@=daemon@&has_accounting@=0@&src@=1057980336@&dst@=3142250704@&srckeyid@=0xe68e6ee7@&dstkeyid@=0x5baf880e@&peer gateway@=1057980336@&scheme:@=IKE@&IKE:@=Quick Mode completion@&CookieI@=225c204a617b57af@&CookieR@=ef88fe6b0fd33f36@&msgid@=f814d2d8@&methods:@=ESP: 3DES SHA1@&IKE IDs:@=subnet: (mask= and host:*** Confidential ***@&fw_subproduct@=VPN-1@&vpn_feature_name@=IKE

    Any guidance is appreciated.

    Thank you

  • Hi Larry,

    Please tell whether your issue has solved. Currently, I am experiencing the same problem. anyway to get the proper username as in checkpoint instead of ***confidential***


  • Hi guys

    We faced same problem last week. Checkpoint releases a fix for this issue. Install "fw1_wrapper_HOTFIX_FOXX_HF_HA20_106.tgz" and enjoy...

  • HI all,

    Did the problem resolve after installing hotfix mentioned above.. I am facing same issue in R75.76



  • Verified Answer

    Yes.  The patch addressed the displaying of ***Confidential*** in the username.

  • I resolved same problem after installing following hotifx.(my check point version is R75.47)

    > fw1_wrapper_HOTFIX_FOXX_HF_HA47_019

  • I resolved same problem after installing following hotifx.(my check point version is R75.47)

    > fw1_wrapper_HOTFIX_FOXX_HF_HA47_019

  • In actual CheckPoint Releases (77.20) after changing the LEA Permissions you have to cpstop; cpstart on the CheckPoint mgmt. Install Policy is not enough.

    To see the Request URL it's not enough - you have to create an new LEA permission Profile and allow the URL's!

    Please disable everything else you don't need in this Profile.

  • I ran into a similar problem last month with a URL Filtering event whereby a "Request URL" field was returning "*** Confidential ***" instead of the name of the accessed website.  I was using the "ArcSight version1" OPSEC Certificate.  My CheckPoint environment is R77.20

    So I did a bit, then a lot, of troubleshooting.

    My tests confirmed that the problem is caused by the CheckPoint Log Management Server: even though the LEA Permissions of the ArcSight Connector's OPSEC Certificate correctly specify that the Connector should be given access to all log fields, the Log Management Server ignores the certificate's settings and hides some fields anyway.

    The only OPSEC Cert setting that partially works is to use Vendor = "User Defined" and LEA Permisions of "show all log fields".  This Certificate never gets the "*** Confidential ***" for any event-type, but it still has a weakness: it does not request as many parameters as the "ArcSight version1" or "ArcSight version3" Certificates.  Hence the "User Defined - show all log fields" Cert might still miss some information that you need.

    As an example, for the URL Filtering event I noticed that the "ArcSight version1 - show all log fields" Cert requested 37 parameters but the Log Management Server returned "*** Confidential ***" for 14 of them.  For the same event the "User Defined - show all log fields" only requested 32 parameters and received useful content for all of them.  Some of the missing 5 fields (ie 37 minus 32) seem like useful information that should be made available to the Connector.

    It's as if the CheckPoint Developers put the following faulty pseudocode into the CheckPoint Log Management Server:

    $allow_opsec_client_to_read_all_fields = FALSE;

    $max_fields_available[for_a_url_filtering_event] = 37;

    IF ( $cert_vendor_label = "User Defined" ) AND ( $cert_lea_permissions = "show all log fields" ) THEN

         $allow_opsec_client_to_read_all_fields = TRUE;

         $max_fields_available[for_a_url_filtering_event] = 32;


    I tried practially every variant in the "LEA Permissions" tab to see if any of them (other than the "User Defined - show all log fields") would get around the issue but none worked - they ALL got the "*** Confidential ***" result for various fields.  Some of them even requested less than other certificates.

    For some event-types all the OPSEC Certificates behaved exactly the same eg "VPN-1 & Firewall -1" and "Anti Malware" events.  So if your environment only gets these types of event you will not notice any difference regardless of the OPSEC Certificate settings you configure.

    As stated earlier, the problem is completely a CheckPoint issue - their Log Management Server is not behaving correctly.  My research suggests that the bug has been around for several years (at least since 2011 when this thread was created).  So far CheckPoint has been issuing lots of patches over the years but they only address the symptoms: a user reports that he/she cannot see "parameter X" for an event-type so CheckPoint provide a patch that only makes "parameter X" available for that specific event-type.

    The CheckPoint Developers need to correct the Log Management Server so it properly reads the security settings of the presented OPSEC Certificate, especially since the OPSEC Certificate was generated within the CheckPoint ecosystem.  I'm currently working with CheckPoint to help them understand the problem and determine a time-frame for the permanent fix.  I'll provide a future update to let you know the outcome.

    In the meantime if you want a quick-fix for your platform then I would (personally) recommend that you use the "User Defined - show all log fields" OPSEC Cert setting.  The only drawbacks with changing your cert are that

    1. this cert may miss some information you ultimately need;
    2. you will incur an outage in ArcSight for what is really a CheckPoint bug; and
    3. when CheckPoint fix the bug you will then have another ArcSight outage when reapplying the original "ArcSight" Certificate.

    If you can hold out until CheckPoint fix their code then you don't need to do anything in ArcSight.