🤖 AI

AnonShield: Scalable On-Premise Pseudonymization for CSIRT Vulnerability Data

The paper introduces AnonShield, a high-throughput, on-premise pseudonymization system that leverages GPU-accelerated NER and streaming processing to achieve up to a 738x speedup in processing vulnerability data while maintaining high accuracy, thereby enabling compliant and scalable data sharing for CSIRTs.

Original authors: Cristhian Kapelinski, Douglas Lautert, Beatriz Machado, Diego Kreutz, Isadora Garcia Ferrão

Published 2026-06-16

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Cristhian Kapelinski, Douglas Lautert, Beatriz Machado, Diego Kreutz, Isadora Garcia Ferrão

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a security team (called a CSIRT) that acts like a giant digital detective agency. Every day, they scan their computer networks to find "bugs" or weaknesses (vulnerabilities). These scans produce massive reports that are like detailed crime scene photos.

The problem is that these photos contain sensitive information. They don't just show the bug; they also show the names of the buildings, the specific room numbers, and even the names of the people who live there. If the team wants to share these photos with outside experts to get help, or use them to train AI, they have to blur out those names first. This process is called pseudonymization.

The paper introduces a new tool called AnonShield to do this blurring job. Here is how it works, explained simply:

The Problem: The "Slow and Risky" Old Way

Previously, trying to blur these massive reports was like trying to clean a giant warehouse with a toothbrush.

Too Slow: The old tools (like the previous version, AnonLFI v2.0) took over 92 hours to process a single large file. That's like spending four full days just cleaning one room.
Too Risky: Some tools tried to do the work by sending the data to the "cloud" (outside servers). This is like mailing your secret crime photos to a stranger to get them blurred. It breaks the rules of data privacy because the data leaves the building.
Too Clumsy: Other tools were like a blunt hammer; they would accidentally blur important technical details (like the name of the bug itself) along with the sensitive names, making the report useless for analysis.

The Solution: AnonShield

AnonShield is like upgrading from a toothbrush to a high-speed industrial vacuum cleaner that runs entirely inside your own building.

1. The Super-Fast Engine (GPU Acceleration)
Think of the old tool as a single worker reading a book page by page. AnonShield hires a whole team of workers (using a powerful graphics card, or GPU) who can read and blur thousands of pages at the same time.

The Result: A job that used to take 92 hours now takes less than 10 minutes. That is a speedup of nearly 738 times.

2. The Smart Filter (Context-Aware)
Imagine you are editing a story. You need to blur the names of the people, but you don't want to blur the names of the monsters or the weapons, because the story is about fighting those monsters.

AnonShield is smart enough to know the difference. It recognizes specific cybersecurity terms (like "CVE" or "CPE" codes) and knows to keep them clear while blurring the sensitive names.
It uses a "schema-aware" setting, which is like having a checklist. If the checklist says "Blur everything in the 'Host Name' column," it does that instantly without even needing to read the text, making it even faster.

3. The "Magic Ink" (Pseudonymization)
Instead of just blacking out a name (which destroys the data), AnonShield replaces it with a unique, unbreakable code (like a secret alias).

If the name "Server-1" appears 100 times in the report, AnonShield changes it to the same code (e.g., "X-999") every single time.
This keeps the data useful: Analysts can still see that "X-999" was attacked three times, even though they don't know it was "Server-1."
Only the team leader with the secret key can turn the code back into the real name.

4. The "No-Cloud" Promise
Everything happens right there on the computer where the data lives. No data is ever sent to the internet. This keeps the organization safe from hackers and keeps them compliant with privacy laws (like GDPR).

The Results

The researchers tested this tool on a massive dataset of over 70,000 records (about 550 MB of data).

Speed: They went from days of waiting to minutes.
Accuracy: The tool was incredibly precise. It successfully found and blurred 96.7% of the sensitive information (Recall) while keeping the data useful for analysis (F1-score of 94.2%).
Reliability: It handled messy file formats (like PDFs with images) and huge spreadsheets without crashing.

In Summary

AnonShield is a tool that allows security teams to share their vulnerability reports safely and quickly. It acts like a super-fast, smart editor that lives inside your own computer, replacing sensitive names with secret codes so the data can be used for analysis or AI training without ever revealing who or what was actually scanned. It turns a 4-day job into a 10-minute task.

Technical Summary: AnonShield

Problem Statement

Computer Security Incident Response Teams (CSIRTs) face a critical operational challenge: the need to share vulnerability scan data (from tools like OpenVAS and Tenable) for analysis, machine learning pipelines, and synthetic data generation while maintaining strict compliance with data sovereignty and privacy regulations (GDPR, LGPD). These reports contain sensitive Personally Identifiable Information (PII), network identifiers (IPs, hostnames), and credentials alongside technical findings.

Existing solutions fail to meet the specific requirements of large-scale CSIRT deployments:

Cloud-based tools (e.g., Google Cloud DLP, Amazon Comprehend) violate data sovereignty by requiring data transmission to external endpoints.
On-premise generic tools (e.g., Microsoft Presidio) lack recognizers for cybersecurity-specific entities (CVEs, CPEs, cryptographic hashes), leaving vulnerability profiles exposed.
Previous research iterations (AnonLFI v1.0 and v2.0) suffer from scalability issues. AnonLFI v2.0, while supporting hierarchical formats (XML/JSON) and OCR, requires over 92 hours to process a 550 MB dataset (70,951 records) due to memory-intensive DOM parsing and lack of hardware acceleration, rendering it impractical for operational use.

Methodology: The AnonShield Framework

AnonShield is a high-throughput, on-premise pseudonymization system designed to process vulnerability data locally. It replaces sensitive entities with deterministic pseudonyms (HMAC-SHA256 slugs) to preserve referential integrity across reports without exposing the original data.

The framework operates through five sequential stages:

Input Processing: Supports heterogeneous formats (XML, JSON, JSONL, CSV, TXT, LOG, PDF, DOCX, XLSX). Large files are handled via streaming I/O (using ijson for JSON and SAX for XML) to avoid full in-memory loading.
Entity Detection (NER): Utilizes a hybrid approach combining:
- GPU-accelerated Transformer Models: Configurable models like Davlan/xlm-roberta-base-ner-hrl or the cybersecurity-focused attack-vector/SecureModernBERT-NER.
- Custom RegEx Patterns: 21 patterns covering IPs, URLs, hashes, certificates, CVE/CPE identifiers, and credentials.
- LRU Caching: Amortizes repeated lookups across records.
Pseudonymization: Entities are replaced with HMAC-SHA256 slugs computed using an operator-defined secret key. The slug length is configurable (0–64 hex characters), and the entity type is preserved as a prefix (e.g., [IP_ADDRESS_48624b5cdc]).
Persistence: A local SQLite database stores the mapping between original entities and slugs, enabling controlled re-identification by administrators holding the key and database.
Output: Structured formats preserve schema and structure with only values replaced. Unstructured formats (PDF, DOCX, images) are processed via OCR or text extraction and output as plain text.

Key Architectural Features:

Schema-Aware Configuration: A mechanism (anonymization_config) allows per-field policies (e.g., force_anonymize, fields_to_exclude) to bypass NER overhead for known fields, significantly boosting performance.
Multiple Strategies: Users can select between:
- Standalone: Highest throughput, bypasses Presidio entirely.
- Hybrid/Filtered: Balances accuracy and performance by restricting recognizers to cybersecurity-relevant entities.
- Presidio: Maximizes recall but may introduce false positives from domain-irrelevant patterns.

Key Contributions

Scalable Architecture: A system capable of processing operational-scale vulnerability datasets (up to 550 MB, ~71k records) on-premise with near-linear complexity.
Comprehensive Evaluation: A comparative analysis of four strategies (standalone, hybrid, presidio, filtered) against previous generations (AnonLFI v1.0/v2.0) and commercial tools, using datasets ranging from heterogeneous testbeds to real-world operational data.
Accuracy Validation: A statistical evaluation using a specialist-annotated sample (67 records, 13 entity types) to measure Precision, Recall, and F1-Score.

Experimental Results

The evaluation utilized four datasets (D1–D3), including a 550 MB operational dataset from CAIS/RNP (D2) containing 70,951 vulnerability records.

Performance (Throughput & Latency):

Speedup: AnonShield reduces processing time for the 550 MB operational dataset from an estimated >92 hours (AnonLFI v2.0) to under 10 minutes (453 seconds), achieving a 738× speedup.
Scalability: AnonShield demonstrates near-linear complexity ( $\alpha \approx 1$ ). In contrast, AnonLFI v2.0 degrades superlinearly due to DOM parsing.
Optimization: Enabling schema-aware configuration for CSV data reduced runtime further to 12.55 seconds (34,341 KB/s), a 46.9× gain over full NER inference.
Hardware Independence: Even on CPU-only hardware, AnonShield achieves a ≥535× speedup over AnonLFI v2.0, confirming gains are architectural rather than solely hardware-dependent.

Accuracy:

Metrics: The Filtered and Hybrid strategies achieved an F1-score of 94.2% and Recall of 96.7%.
Comparison: This represents a significant improvement over AnonLFI v1.0 (F1: 23.7%) and v2.0 (F1: 54.0%).
Error Analysis: False Negatives were primarily deterministic (unrecognized organization names in attribution strings and structural artifacts like port numbers in free text). False Positives were significantly reduced in Filtered/Hybrid modes by suppressing domain-irrelevant recognizers (e.g., misclassifying version strings as dates).

Significance and Claims

The paper posits that scalable, on-premise pseudonymization of vulnerability data is operationally feasible without sacrificing analytical utility. By achieving high throughput and high recall, AnonShield enables:

Compliant Data Sharing: Facilitating the use of vulnerability data in downstream LLM pipelines and synthetic data generation while adhering to GDPR and LGPD.
Operational Viability: Moving from impractical processing times (>92 hours) to near real-time capabilities (<10 minutes) for large-scale enterprise environments.
Context-Aware Security: Recognizing that cybersecurity identifiers (CVEs, CPEs) are sensitive in specific contexts, the system allows for fine-grained control over what is pseudonymized, addressing a gap left by generic PII tools.

The authors acknowledge current limitations, including reliance on specific OCR libraries for image-only PDFs and the inherent difficulty of publishing raw vulnerability data even after pseudonymization (due to the risk of narrowing an attacker's search space). Consequently, they position pseudonymization as a complementary step to synthetic data generation for external sharing, while remaining essential for internal LLM-assisted analysis.