Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Configure log file Encryption and log field Anonymization


Many log files are written on a Web Gateway and especially end user relevant data (like the access.log) is considered personal data. In many geographies (especially the European Union) it is required to apply special protection to this data. Many corporations also have their own guidelines to protect the data of their employees from unauthorized access.

Skyhigh Security Web Gateway (SWG) provides you with several options to protect these log files. The configuration is very flexible and allows you to make individual changes to different logs as well as to different appliances in your worldwide cluster.

Encryption: This option allows you to encrypt your log files and make sure that in case someone gains access to your SWG appliance, the logs are not readable. Encryption also prevents unauthorized administrators from reading the log files without permission.

Anonymization: This option allows you to replace "user identifiable" data in the log files with encrypted data. As an example, the username and client IP address (those two fields are the most common) could be replaced in your access log.

Normal log file (not anonymized)

#time_stamp "auth_user" src_ip status_code "req_line" "categories" "rep_level" "media_type" 
bytes_to_client bytes_from_client "user_agent" "virus_name" "block_res" "application_name" 
[08/Aug/2014:15:29:41 +0000] "SWelschen" 407 "CONNECT HTTP/1.1" "" "-" "" 4197 179 "Internet Explorer" "" "81" 

Anonymized fog file ("auth_user" and "src_ip" fields encrypted)

#time_stamp "auth_user" src_ip status_code "req_line" "categories" "rep_level" "media_type"

bytes_to_client bytes_from_client "user_agent" "virus_name" "block_res" "application_name"

[08/Aug/2014:15:29:41 +0000] "<anonymous1>/j1TQd/DN+rlitgC/KWfXg==</anonymous>"<anonymous1> J9HxwI1ybORuyZprRFnsZw== </anonymous>407 "CONNECT HTTP/1.1" "" "-" "" 4197 179 "Internet Explorer" "" "81" 

4-Eyes Principle

The "4-Eyes Principle" refers to a practice where data is protected with two different passwords. Those two passwords are given to two different people and only when those two come together can the data be decrypted (two people = 4 eyes). In many organizations this principle is applied to sensitive data where two different parts of the organization (separation of duties) are involved. For example for a log file protected by two passwords, one could be given to the IT admin and the other to an HR representative.

SWG allows you to apply all possible combinations to log files as well as anonymization of user data: -

  • No password set (default)
  • One password set (simple protection to restrict unauthorized access)
  • Two passwords (Full compliance with regulations and company policy on separation of duties)


Enable Encryption

  1. Navigate to Policy >> Settings >> File System Logging and select the log file you wish to encrypt
  2. In the settings details you should first set the appropriate passwords (at least one is recommended!).
  3. Afterwards you can enable encryption by simply setting the option for "Encrypt the log file".

Notice that you will not be able to import encrypted log files into Skyhigh Security Web Reporter or Skyhigh Security Content Security Reporter without decrypting them first.

Decrypt a log file

To decrypt an encrypted log file you need to utilize the tool "LogFileDecrypter" on the command line of your SWG. The decryption tool by default displays the result of the decrypted log file directly to the command line. Therefore it is recommended to redirect the output into a new file.

Decryption Example for the access.log:

/opt/swg/bin/LogFileDecrypter --decrypt /opt/swg/log/user-definedlogs/access.log/access.log > /opt/access-decrypted.log


Enable Anonymization

To enable anonymization, you will need to modify the default log line being written to your log file. We will be using the access.log as the example in this document.

  1. Navigate to Policy > Log handler > Default > Access Log and as a first step make a copy (Copy and Paste button above the "Write access.log" rule) of the existing access.log rule. Disable the copied rule for now.
  2. Open the copied rule and rename it to "Write access.log (anonymized).
  3. The next step is to replace the property "Authentication.Username" with the anonymized version. To do that, open the Event "Set User-Defined.logLine" and then double click on the line that shows "Authentication.Username"
  4. In the new window, change the Parameter property to "FileSystemLogging.MakeAnonymous". Make sure to select the Settings from the drop down. In our example, the correct setting would be "Access Log Configuration" as we are anonymizing the access.log.
  5. Also make sure that at least one password is set in this Settings container. For the "4-Eyes principle", you need to set two passwords.
  6. Now click on the "Parameters" button for the MakeAnonymous property and select the property Authentication.Username
  7. Several "OK" clicks later you should be able to see the new part of your log line. The username is now being anonymized. You can apply the same steps as above to the Client.IP field as well. The result should look similar to the screenshot below.
  8. The final step is to activate the new logging rule and disable the original one. Make sure that you ONLY have one of the two enabled at a time as they both write into the same log file.

Deanonymize a log file

To deanonymize an log file you need to utilize the tool "LogFileDecrypter" on the command line of your SWG. The decryption tool by default displays the result of the deanonymized log file directly to the command line. Therefore it is recommended to redirect the output into a new file.

Deanonymization Example for the access.log:

/opt/swg/bin/LogFileDecrypter --deanonymize /opt/swg/log/user-definedlogs/access.log/access.log > /opt/access-deanonymized.log

Anonymizing in the Cloud

To anonymize usernames in the cloud a ruleset must be included in your synchronization. This ruleset should be placed in the Policy > Rulesets towards the very top of your rulesets.

  • Was this article helpful?