Skip to content
Avanet

Configure Sophos Firewall Data Anonymization

Sophos Firewall

Data anonymization encrypts identifying information in Sophos Firewall logs and reports. This includes usernames, IP addresses, MAC addresses, and email addresses in particular. An authorized administrator can reveal this information again for a legitimate analysis.

The safe process is short:

  1. Document the purpose, affected outputs, and approval process.
  2. Prepare two personal administrator accounts as authorizers.
  3. Turn on the feature under System services > Data anonymization and select both authorizers.
  4. Use a controlled test event to verify that the Log viewer and search still work.
  5. Deliberately reveal the identity with an authorizer and perform a negative test of unauthorized access.
  6. Add exceptions only for justified individual cases.
  7. Check CSV exports and actually generated PDF reports separately.

⚠️ Data Anonymization is not data deletion and does not guarantee protection for every external data path. Remote syslog, Sophos Central, CTR, Advanced Shell files, and backups are checked separately. An export is only shared after the actual file has been checked for sensitive identities.

What Data Anonymization protects

Sophos describes the feature as encryption of identities in logs and reports. It specifically lists:

  • usernames;
  • IP addresses;
  • MAC addresses;
  • email addresses.

This reduces unnecessary exposure during everyday analysis and reporting. For example, a NOC can investigate an issue by time, rule, and action without immediately seeing every user or client identity. Controlled disclosure remains possible for a legitimate security or privacy case.

The feature still does not replace access rights, retention rules, or protected transport. An anonymized report can still contain firewall names, URLs, rule names, timestamps, and security events. This information can also be confidential.

What is not assumed across the board

The current Sophos help confirms the effect for logs and reports and the ability to reveal information in the Log viewer. However, it does not describe every possible output path in the same level of detail. The on-box setting is therefore not automatically extended to the following data paths:

  • remote syslog or SIEM;
  • Sophos Central Firewall Reporting;
  • Consolidated Troubleshooting Reports and individual support logs;
  • files under /log in the Advanced Shell;
  • backups and configuration exports;
  • emails that have already been sent or stored PDF and CSV files.

Remote syslog continues to require the dedicated protection and acceptance process described in Send Sophos Firewall syslog securely to a SIEM. Central reports are checked separately as described in Sophos Central Firewall Reporting.

Prepare authorizers and dual control

When the feature is turned on, administrators are selected as Authorizer. This role can reveal anonymized identities after authenticating again. Sophos recommends at least two authorizers. If the currently signed-in administrator is also registered as an authorizer, approval from at least one other authorizer is required.

Two personal accounts are therefore prepared before activation, for example:

  • privacy.authorizer1
  • privacy.authorizer2

These names are examples and are replaced with two administrator accounts that are clearly assigned to individuals. A shared team account would be unsuitable because disclosure, approval, and subsequent review could no longer be attributed to a person. Configure administrators and Device Access profiles securely explains how to set up personal accounts and restricted profiles.

The following points are also defined in advance:

  • the support, security, or privacy cases in which disclosure is permitted;
  • who requests and approves the analysis;
  • how the ticket, purpose, period, and affected identities are documented;
  • when an exception expires and is reviewed again;
  • which local recovery administrator remains available if an authorizer does not work.

Activation is stopped if only one working administrator is available or the second authorizer has not yet passed a positive test.

Turn on Data Anonymization

  1. Sign in to WebAdmin with a personal administrator account.
  2. Open System services > Data anonymization.
  3. Select Enable data anonymization.
  4. Select at least the two prepared authorizers.
  5. Select Apply.
  6. If the signed-in administrator is selected as an authorizer, provide the approval required by Sophos with the second authorizer.
  7. Reload the page and verify that the enabled setting is still shown.

The change is not combined with a change to administrator profiles, MFA, or log destinations. A single change is easier to verify and roll back.

Generate a controlled test event

The acceptance test uses a known pilot client, such as 10.20.30.25, and a clearly assigned test user such as privacy.test. The private IP address is an example. It is replaced with a real pilot client from the management or test network so that the generated event can be clearly identified in the local Log viewer.

The time, source, destination, service, and expected Firewall Rule ID are documented for the test. The pilot client then generates a short allowed connection whose rule has Log firewall traffic turned on. This distinguishes a working anonymization feature from a missing matching event.

If the event is completely absent, check the normal logging path first. Map Sophos Firewall services and log files helps with this. Data Anonymization does not repair disabled rule logging or a stalled Log viewer.

Perform positive and negative tests in the Log viewer

  1. Open Log viewer and select the relevant module.
  2. Limit the period and filters to the documented test event.
  3. Verify that the user and address fields appear anonymized.
  4. Run a free-text search using the visible anonymized information. Sophos confirms that search also works with anonymized information.
  5. As a registered authorizer, use the Data anonymization button and enter the account’s own authentication credentials.
  6. Verify that the expected identity becomes visible for the analysis.
  7. Close the authorized view and use a test administrator who is not registered as an authorizer to verify that the information cannot be revealed.

A successful authorizer test proves only this specific WebAdmin path. It does not yet prove that PDF, CSV, Central, syslog, or support archives use the same presentation.

Add exceptions only with justification

An exception prevents the selected identity from being encrypted in logs and reports. It can be defined for users, IP addresses, MAC addresses, or email addresses. This is not a more convenient search function, but a deliberate disclosure.

A defensible case might be a technical service identity that an automated operational process must distinguish in clear text. Even then, the exception needs:

  • a documented purpose;
  • the smallest possible identity scope;
  • an owner;
  • an expiry or review date;
  • a positive test of the exception and a negative test of an identity that remains anonymized.

The documented procedure is:

  1. Add the specific exception under System services > Data anonymization.
  2. Select Apply.
  3. Enter the username and password of an authorizer.
  4. Select Save.
  5. Generate a new test event and check the actual presentation.

After successful authentication, the selected identities are not encrypted. A broad network range, a complete user group without an individual justification, or a permanently open exception is not used as a default.

Check PDF and CSV files in practice

The WebAdmin view is only one part of the acceptance test. Outputs may later be stored outside the firewall, sent by email, or copied into a ticketing system.

Check a scheduled PDF report

For local email reports, do not wait until the next regular run after turning on the feature. Run the schedule with Generate now and inspect the PDF that is actually received. Schedule Sophos Firewall reports and send them by email describes the complete delivery and validation process.

At least the following points are checked:

  • user, IP, MAC, and email fields;
  • intended exceptions;
  • URLs, rule names, and other sensitive content;
  • recipients, mail transport, and mailbox retention.

A PDF generated earlier does not become new acceptance evidence after a later setting change. A fresh file is generated for the test.

Check a Log viewer CSV export

The Log viewer can export the current view as CSV. The current Sophos help confirms the export but does not separately describe the anonymization scope of the file. A small export of the controlled test event is therefore opened and checked field by field.

This export path is only used in production after both anonymized identities and intended exceptions appear correctly. The file is then stored securely or deleted. A filename without an identity does not prevent the content from containing sensitive data.

Validate HA and external data paths

In an HA cluster, Data Anonymization is checked again after a controlled failover. A new test session is generated on the node that is now active, and the Log viewer process is repeated. An existing WebAdmin session or a test only on the former primary is not sufficient evidence.

Remote syslog, Central Reporting, CTR, and Advanced Shell logs are treated as separate data paths:

  1. Define the destination and responsibility.
  2. Generate a controlled test event.
  3. Check the output that is actually received or downloaded.
  4. Document access, retention, and secure deletion.

If an external data path still contains clear text, this is not concealed with a broad exception or by turning off local logging. Instead, access and transport for the affected system are hardened, or the export is stopped until the privacy requirement has been resolved.

Troubleshoot systematically

Identities still appear in clear text

First, verify that Enable data anonymization is still active and that the visible event was generated after the latest change. Then check the exceptions for users, IP addresses, MAC addresses, or email addresses. An event can contain several identities; an exception for the source IP does not automatically explain a visible username.

Next, reset the Log viewer, generate a new test event, and check the view again. Old PDFs, browser downloads, or screenshots are not reliable evidence of the current setting.

An authorizer cannot reveal an identity

Verify that the personal account is actually selected as an authorizer and that its own current authentication credentials are being used. If the signed-in administrator is itself an authorizer, plan for the necessary approval by another authorizer.

Administrator profiles, MFA, and login source are not changed at the same time. If disclosure still fails despite the correct selection and a successful normal login, document the time, browser, account, and visible message. Do not remove authorizers until a second tested access path and a recovery path are available.

A PDF or CSV file differs from the Log viewer

Assess the paths separately. For PDF, document the report type, generation time, and Generate now. For CSV, record the module, filters, and export time. For Central, syslog, or support archives, do not promise local anonymization; check the actual target file or platform.

Do not restart reporting or logging services and do not delete report data solely because an output is presented differently. First create a reproducible test with a new file.

Roll back safely

Document the previous settings before the pilot. If the new configuration does not meet the agreed operational requirements, restore the previous state under System services > Data anonymization with an authorized change. Then check a new log event, the authorizer view, a CSV export, and a PDF if required.

Remove exceptions first or restore their previous scope. Files that have already been exported continue to exist separately and must be handled according to the applicable retention and deletion rules. Rolling back the firewall setting does not remove copies from mailboxes, SIEM, tickets, or support cases.

Operational checklist

  • purpose, owner, and approval process documented
  • two personal authorizers passed a positive test
  • local recovery administrator available
  • Enable data anonymization active and confirmed after a reload
  • controlled log event visible in anonymized form
  • authorizer disclosure passed and unauthorized access failed
  • exceptions are narrow, justified, and have a review date
  • fresh PDF and Log viewer CSV checked
  • syslog, Central, CTR, and shell logs assessed separately
  • HA failover accepted with a new event
  • files already exported protected and handled according to retention

Frequently asked questions

Does Data Anonymization delete personal data?

No. Sophos describes the feature as encryption of identities in logs and reports. An authorized administrator can make the information visible again after authentication. This is not the same as deletion or irreversible anonymization.

Are remote syslog and Sophos Central automatically anonymized?

The current feature description does not expressly confirm this for these data paths. A controlled event is therefore used to check what is visible at the actual syslog destination, in Central, in the CTR, or in a downloaded file.

Is one authorizer enough?

The interface allows one or more authorizers, but Sophos recommends at least two. If the signed-in administrator is also an authorizer, at least one other authorizer is required for approval. Two personal, tested accounts are therefore used for lockout-safe operation.