What is Glasswall CDR?
Glasswall CDR: Understanding Content Disarm and Reconstruction
CDR (Content Disarm and Reconstruction) uses a unique method to keep organizations and individuals safe from file-based threats. Instead of trying to detect threats like most cybersecurity solutions, Glasswall CDR follows a Zero Trust approach. This means that only files that have been checked and cleaned by Glasswall are considered safe, because all potential threats have been removed. We do not attempt to identify malicious code; instead, we remove its ability to affect the document.
Every file that goes through the Glasswall Embedded Engine is treated as potentially harmful. The engine examines the file and rebuilds it according to the original specifications from its manufacturer, removing any dangers hidden in the file's structure.
Fixing deeper problems within the file's structure is called remediation. We also remove content that could be harmful according to policy, such as hyperlinks in Office documents, which is referred to as sanitization.
Why is CDR better than regular antivirus and sandboxing techniques?
According to recent reports, ransomware has been a significant factor in data breaches, with 24% involving ransomware attacks, as found in the Verizon 2023 Data Breach Investigations Report (DBIR). The Sophos report The State of Ransomware 2023 further highlights the prevalence of ransomware incidents, with 66% of organizations experiencing them in 2023. Most ransomware samples are detected in Windows-based files, accounting for approximately 95% of all detected ransomware.
Deploying CDR protection means organizations do not have to rely solely on next-generation antivirus software or threat intelligence databases, which can take an average of 18 days to detect new threats. While sandbox technology can help identify previously unknown malware, it often introduces delays that negatively impact productivity. Sandboxes rely on attackers executing malicious behavior while the file is being analyzed, which is not always guaranteed. Waiting days to identify new threats presents significant risks to enterprise IT environments.
Next-generation antivirus software and sandboxes require an understanding of a threat in order to defend against it. Glasswall CDR rebuilds every file to its manufacturer's 'known-good' specification without requiring prior threat knowledge, eliminating the risk of malware being hidden within a file’s structure.
The Glasswall CDR Process
Glasswall’s CDR technology uses a patented four-step process to rebuild each file back to its manufacturer’s 'known-good' specification. Each phase analyzes the file independently, with results passed into the next stage. Once processing is complete, the Glasswall Embedded Engine produces a clean, usable file and a detailed report explaining what risks were identified and how they were addressed.
Step 1 – Inspect
The Glasswall Embedded Engine inspects the file to understand its structure and component sizes. It builds a tree-like structure, similar to a document object model (DOM) in HTML, automatically expanding compressed elements. If embedded file types are discovered, they are processed independently. For example, if a Microsoft Word document contains an embedded JPEG image, each file is analyzed separately. This phase generates a detailed structural analysis report.
Step 2 – Rebuild
During the rebuild phase, the engine iterates over the structures identified during inspection. Each structure is validated against the manufacturer’s published specifications, such as ISO 32000 for PDF files. If a structure does not conform, the engine attempts to repair it. If repair is not possible, the issue is recorded and the file may be deemed non-regenerable.
Documents can contain thousands of individual structures.
For example, the SttbTtmbd byte-level structure contains embedded font information within a Microsoft Word .doc file. The SttbW6 structure defines the font type, location, and storage method.
If structures do not meet specification requirements, default values may be inserted to allow validation. Structures that are hidden, unused, or not part of the known-good specification — such as caches, part-saves, or unreferenced data blocks — are not regenerated in the final output.
Step 3 – Clean
The cleaning phase applies configurable content management policies using Policy Management. Because all structures were identified during inspection, policies can be enforced deterministically. Each structure is handled in one of the following ways:
Allow
The structure is retained in the regenerated file and logged as allowed in the analysis report.
Disallow
The structure is logged as an issue. The document is marked non-conforming and is not regenerated.
Sanitize
The structure is surgically removed from the document and logged in the analysis report. This is achieved by excluding the structure from regeneration. The Glasswall Embedded Engine applies these policies to PDF, Microsoft Office, SVG, WebP, and GeoTIFF files.
Step 4 – Deliver
In the final phase, semantic checks ensure the document remains visually accurate and fully usable. Structural relationships are validated against the manufacturer’s specification, and any broken references introduced during remediation or sanitization are repaired.
Once validation is complete, the engine writes the regenerated file by traversing the validated structure tree. The clean, usable file is delivered to the end user along with a detailed report describing all changes made. If a file cannot be safely processed, the reason is clearly reported. This entire process typically completes in under a second.