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 Fusion (formerly 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 define the approval boundary

When the feature is turned on, one or more administrators are selected as Authorizer. This assignment authorizes de-anonymization; in the Log viewer, an authorizer must provide authentication credentials. Sophos recommends at least two authorizers. If the currently signed-in administrator is also registered as an authorizer, Sophos requires approval from at least one other authorizer.

An important planning boundary follows: this does not establish technically enforced dual control for every disclosure. The SFOS 22.0 help only confirms authorization and renewed authentication in the Log viewer. If your policy requires two people for every analysis, enforce that organizational process as well and validate it separately from product authentication.

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.

Authorizer is not a separate Device Access profile. Profiles provide role-based access to the web admin console and API using None, Read-only, or Read-write; a local user is created under Authentication > Users with the type Administrator and a profile. Sophos does not state a minimum profile for Data Anonymization. Rather than claiming one, verify before the change that both intended accounts can actually reach the required page and the Log viewer.

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.

Stop activation if only one working administrator account is available or the normal WebAdmin sign-in of the second intended authorizer has not passed a positive test. Its authorizer function can only be tested after assignment.

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, obtain the approval of at least one other authorizer when the interface requests it.
  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

In SFOS 22.0, open the view through Log viewer in the upper-right corner of WebAdmin. In SFOS 23.0, this entry is called Logs and policy test. Perform the following checks 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 identities are not disclosed. The exact failure may vary with permissions; success only means that the test administrator receives no clear-text identity.

A successful authorizer test proves only this specific WebAdmin path. It does not yet prove that PDF, CSV, Sophos Fusion, 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.

Define the boundaries for HA, backups, and external data paths

The SFOS 22.0 Data Anonymization page makes no feature-specific statement about HA synchronization or backup contents. Neither is therefore presented as guaranteed. In an existing HA cluster, a new test event after a planned failover is a useful operational acceptance test, but Sophos does not document it as a prerequisite for this feature.

Sophos generally confirms that a backup contains the entire firewall configuration and is encrypted. Restoring it replaces the current configuration, deletes the backup stored on the firewall, and restarts the firewall; restoring an older state loses later changes. Without further evidence, this does not establish how historical anonymized identities are handled. After a restore, check the setting, authorizers, exceptions, and a new log event again.

For HA restores, the backup is restored to the current primary and then synchronized to the auxiliary; the restart takes place without failover and causes downtime. A backup without HA configuration disables HA. A backup restore is therefore not a lightweight rollback method for Data Anonymization alone.

Remote syslog, Sophos Central Firewall 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, its Device Access profile permits the required access, and its own current authentication credentials are being used. If the signed-in administrator is itself an authorizer, account for the approval from another authorizer described by Sophos; do not assume an additional second approval for every Log viewer action unless the interface requests it.

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 Sophos Fusion, 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

Before the pilot, record three states under System services > Data anonymization: Enable data anonymization, the authorizer list, and every exception. If the change does not meet the agreed operational requirements, return exactly these values to the recorded state in an authorized change and select Apply. A backup restore is disproportionate for this because it replaces the configuration, restarts the firewall, and may interrupt HA.

Sophos documents no separate reset function and does not say whether turning the feature off changes the presentation of identities already stored. Validate the return path with a new log event, the authorizer view, a CSV export, and a freshly generated PDF if required; make no claim about historical entries without inspecting them.

Restore exceptions to 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, Sophos Fusion, CTR, and shell logs assessed separately
  • HA behavior checked with a new event when a cluster exists
  • authorizers and exceptions recorded before a restore; restore not used as the default rollback
  • 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 Fusion 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 Sophos Fusion, 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, approval from at least one other authorizer is required. However, the help does not establish mandatory second approval for each individual Log viewer disclosure. Two personal, tested accounts are still used for resilient operation.