Fortra WAF Data Anonymization
This document includes the following sections. Click on the link to go to the corresponding section to learn more:
To save configuration changes or edits you make to any features and options, you must click Save on the lower-right of the section or page where you are making changes. Click apply changes on the upper-left corner of the page, and then click OK. Your changes will not be stored if you do not properly save your changes.
To go to the previous section, see DDoS and Resource Attacks Mitigation in Fortra WAF. To go to the next section, see About Alert Logic Managed Web Application Firewall (WAF).
The Fortra WAF Data Anonymization feature ensures that client-related log data is irreversibly obfuscated before being written to disk. This applies to all data, whether it is classified as Personally Identifiable Information (PII) or Protected Health Information (PHI), with specific exceptions. To protect the feature from accidental disabling, its configuration can be permanently locked.
Scope
The feature operates at a system-wide level, ensuring comprehensive anonymization across all instances. Sensitive data is anonymized before storage or transmission, enhancing security and compliance.
- Anonymization applies to the entire logical WSM instance (master + worker instances).
- All data is anonymized before being:
- Written to storage.
- Sent to the Alert Logic/Fortra backend.
Requirements coverage
By complying with GDPR de-identification standards, the anonymization process fulfills some of the strictest global regulations for data protection. This ensures robust compliance and extends to jurisdictions with similar requirements.
- The method satisfies GDPR de-identification requirements using the preferred method of data masking.
- GDPR requirements are among the strictest globally; satisfying them also ensures compliance with PII data protection laws that mirror or are subsets of GDPR.
- Because the data is irreversibly masked, GDPR does not apply to anonymized information.
Method
The anonymization process is designed to render data completely and irreversibly anonymous. This removes it from the scope of GDPR, as outlined in Recital 26, ensuring that anonymized data is no longer tied to identifiable individuals.
- Complete and irreversible anonymization of value elements in data.
- Moves data out of GDPR scope as per Recital 26:
- "The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable."
- Reference: https://www.privacy-regulation.eu/en/recital-26-GDPR.htm
Reversibility
Anonymization is implemented as a one-way process, ensuring it cannot be undone. Once the feature is enabled and locked, the data cannot be restored or de-obfuscated through standard methods.
- The operation is one-way and irreversible, applying to the entire WSM instance.
- Once enabled and locked, the change cannot be undone using available API or UI methods.
Risk coverage
The anonymization feature is designed to mitigate risks associated with standard operations and external data exposure. However, it does not protect against malicious actions by highly privileged users.
Risks covered
- Normal use.
- Data visibility (“eyes on”).
- Data leaving the appliance.
Risks Not Covered
- Rogue admin with root privileges and skills to modify code or install unauthorized software on the instance.
Feature trade-offs
While the anonymization feature significantly enhances data protection and GDPR compliance, it introduces certain functional limitations. These limitations affect features that rely on detailed client data.
- If source IP obfuscation is enabled (to comply with GDPR requirements):
- Controls based on the client source IP will not work.
- Application profiling/learning will be disabled if Data Anonymization is enabled.
Obfuscation method
The obfuscation process ensures that sensitive data is anonymized while preserving the semantic structure of requests. Specific data fields are exempted to maintain system functionality and efficiency.
- Digits (\p[N]) replaced with digit 9.
- Letters (\p[L]) replaced with letter A.
- Combinations replaced with letter H.
- Resulting string length is randomized.
- Client source IP is reduced to a class C, B, or A network (/24, /16, /8).
Request data exempt from obfuscation
- Strings matching reserved words in signatures.
- Request path.
- Request element names such as the HTTP method (verb) and version.
- Request parameter names/keys mapped for specific requests during parsing (but not their associated values).
- Request header names mapped for specific requests during parsing.
- Request header values exempt as per exemption list.
Log sources
Anonymization is applied across multiple log sources, each with tailored rules to ensure data protection. These rules limit the inclusion of sensitive data while maintaining necessary system logs.
Deny log
- Request data written to instance storage.
- Response data written to instance storage.
- Request data written to customer storage (e.g., S3 repository).
- Response data written to customer storage.
Access log
- Custom access log data format is unavailable (to prevent fields containing PII from being included).
- Source IP reduced to /24 network.
- URL components (path + query string/'GET parameters') are replaced with the path only.
Learn data
- Learning is disabled and cannot be re-enabled.
Error log
- Client requests are not included in error messages.
Configuring Data Anonymization
Data Anonymization is configured in System > Configuration.
The configuration applies to all instances in the logical WAF (Manager/Workers in High Availability/Auto-Scaling deployments) and all website security profiles.
|
Enable Data Anonymization Check box |
Check to enable data Anonymization. When enabled, log data will be irreversibly obfuscated before being written to disk. |
|
Source IP Masking Dropdown |
Source IPs are anonymized by applying a netmask. Options are:
|
|
Exceptions Input fields |
By default, all input elements that contain information specific to the client request are anonymized – regardless of the information being confidential or not. To preserve the semantic structure of the request and not sacrifice exploit/attack-related information, header and input parameter names, URL paths, and violation-specific strings are exempt from anonymization (see Obfuscation method). If additional named request elements are required to be exempt from anonymization, these can be added as exceptions in the exceptions table.
|
|
Log Data Export Check box |
Allow unredacted log data export. When enabled log data will be exported (e.g., S3 log exports) in its original form and prior to anonymization. |
Lock Data Anonymization
Once Data Anonymization is configured and enabled it should be locked down to prevent an admin user from disabling or reconfiguring it and consequently put WAF log data back in scope of privacy requirements.
|
Prevent data anonymization from being disabled Check box |
Lock enablement of Data Anonymization. |
|
Lock data anonymization configuration Check box |
Prevent Data Anonymization from being changed. It is strongly recommended that Data Anonymization configuration is validated before locking the configuration. For instance, enabling IP masking will disable source IP based controls and should therefore only be considered if absolutely required. If configuration is locked enabling source IP masking cannot be undone. |