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 don't try to find malicious code; we simply take away its ability to harm 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, getting rid of 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 our policies, like hyperlinks in office documents, which we call 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, making up about 95% of all detected ransomware. For organizations, deploying CDR protection means they don't have to rely solely on next-generation antivirus or threat intelligence databases, which can take an average of 18 days to catch new threats. While sandbox technology can help identify new malware, it often slows down usability, sacrificing business productivity. This is because sandboxes rely on correctly identifying malicious processes and assuming attackers will launch suspicious software while the file is in the sandbox, which isn't always the case. Waiting 18 days to identify new threats poses significant risks to businesses' IT infrastructure.

Next generation antivirus software and sandboxes require understanding of a threat in order to defend against it. Glasswall CDR rebuilds every file to its 'known-good' manufacturer's specification, without the need to have specific threat knowledge - eliminating the risk of malware being hidden within the file’s structure. 

The Glasswall CDR Process

Glasswall's CDR technology takes files through our patented four-step process to rebuild each file back to its manufacturer’s 'known-good' specification. During each phase, the file gets analyzed. The results from each phase feed into the next one, keeping them separate. After these four phases finish, the Glasswall Embedded Engine creates a clean file without threats. It also gives a report explaining what risks were found and how they were removed.

Step 1 - Inspect 

The Glasswall Embedded Engine first inspects the file to understand its structure and component sizes. It creates a tree-like structure similar to a document object model (DOM) in HTML, expanding compressed elements automatically. If it finds another file type within the document, it treats it separately, creating additional tree structures. For instance, if an MS Word document contains an embedded JPEG image, each file is processed independently. After this process, the Glasswall CDR Engine generates a detailed analysis report of the file structures.

Step 2 - Rebuild

In the next phase, the process iterates over the generated tree from the previous inspection cycle. An iterator starts from the root structures and validates each structure it encounters. Validation checks if the data matches the manufacturer's known good standards specified in documents like ISO32000 for PDFs. If the data doesn't match the standard, the file fails validation. The Glasswall CDR Engine attempts to repair the file to meet the specification; or alternatively, it records an issue in the analysis report, indicating that a new file cannot be safely regenerated.

There are thousands of structures within a document:

E.g. the SttbTtmbd byte level structure contains a list of embedded fonts within the MS Word .doc file. The SttbW6 structure specifies what the embedded font is, where it is located and how it is stored.

In Glasswall's validation process, if file structures don't meet the specification, default values are inserted to validate embedded fonts. Remediation addresses structures that don't conform to the published specification. Hidden structures or those not specified in the known good specification aren't regenerated in the final file version. This may include caches, part-saves, and unreferenced data blocks.

Step 3 - Clean 

The next processing phase sanitizes the document using configurable content management settings via Policy Management. The previous inspection phase has already uncovered all the structures within the document, so when a structure is encountered, the policy settings apply one of the following actions:

Allow

The structure remains in the processed document and is logged in the analysis report as an allowed item.

Disallow

The structure is logged in the analysis report as an issue item. The document is marked non-conforming and is not regenerated.

Sanitize

The structure is surgically removed from the managed document. The removal is logged in the analysis report. This is achieved by not tagging the structure for regeneration. The Glasswall Embedded Engine applies configurable content management policies to PDF, MS Office files, SVG, WebP and GeoTiff.

Step 4 - Deliver 

In the final phase, semantic checks are performed on the document to maintain visual integrity and ensure usability. Checks examine the document's structures, comparing them to the manufacturer's published specification to validate their relationships. Any broken references resulting from remediation or sanitization are repaired during this process.

After validating the expected data structures, the stream is written to the new file version. The file is regenerated based on its data structures, with the engine traversing the tree and writing out the file accordingly.

The safe, usable file is then delivered to the end user along with a detailed report outlining the changes made to ensure it meets the required manufacturer's specifications. If the file cannot be processed, the reason is explained to the user. All of this occurs within the Glasswall Embedded Engine, typically in less than a second.

Learn more

• Supported File Types
• Policy Management
• Glasswall CDR FAQs
• About Embedded Engine
• About Glasswall APIs