Glasswall Halo FAQs

1. The file is sent to the REST API.
2. The file is stored on a persisted volume within the cluster.
3. A message is sent to the engine service to process the file.
4. The engine service receives the message to process a file.
5. That file is read from the persisted volume and is then processed by the Glasswall engine.
6. The clean file and analysis report are then stored in the persisted volume.
7. A message is sent to the report extractor so the engine report can be generated.
8. A message is then sent back to the API from the engine service.
9. The API receives the message from the engine and reads either the clean file, report, or both from the persisted volume and generates the correct response to the client.
10. A message is then sent to the report extractor from the API.
11. The report extractor receives this message and generates a report from the analysis file and the API.
12.  Metric data is then generated.
13. Finally the original file, clean file, and analysis report are deleted from the persisted volume.

Glasswall Halo supports a wide range of file types including PDFs, Office documents (Word, Excel, PowerPoint), images, and more. It ensures that all processed files are safe and retain their original functionality.

Original files, clean files, and analysis reports are stored in a persisted volume backed by either Azure File Share (Azure) or Amazon Elastic Block Store (AWS).

Reports can be stored in Azure Blob Storage (Azure), S3 (AWS), or a persisted volume.

Glasswall Halo can be deployed in a Kubernetes environment, leveraging Helm charts for easy setup and configuration. Detailed deployment instructions are provided in the documentation. You may also deploying via an OVA.

An error report is returned to the user.

Original files, clean files, and analysis reports are stored until the report generation is complete.

A maximum of 5 levels of nested archives are supported by Glasswall Halo.

The following archive types are supported in Glasswall Halo: Zip, Tar, Zip, 7Zip, Rar.

Allow - 0

Sanitise- 1

Disallow - 2

Within the error response, Glasswall Halo returns a "code" which indicates a particular scenario. 

Error codes will start with the HTTP response code and include a number to indicate the specific error. For more information please refer to our API documentation.

Yes, the current configuration includes contingency for workloads that are more challenging than the average file. Whilst it may be possible to increase the replicas count and to observe improved performance, the consequence might be increased errors if the concurrent load depleted the available memory.

This is possible and would therefore allow the replicas count per node to be amended without necessarily experiencing any scarcity of compute resources. An obvious downside of assigning more workloads to a single node is the size of the blast radius should a node fail. Increasing the node count may achieve the same objective with less risk.

The CDR process needs to create an intermediate representation of the original file. This may be much larger that the original file. We have assigned reserve values to ensure that multiple large files can be processed.

Glasswall provides the customer with the entitlement to process a number of files or an amount of data each day. Today Glasswall does not impose a technical limitation on overconsumption of the license entitlement. However, over-consumption would represent a contractual violation of the licencing agreement. Glasswall will be introducing a license management layer into Glasswall Halo which imposes limitations of use according to the license entitlements.

Today there is no limitation on the number of Engine calls that may be made in a given time frame, beyond the base configuration that is provided in the Helm Charts. In the future, a license management mechanism may throttle throughput to pro-rate hourly capacity with the daily peak capacity that has been purchased.

1 GB. There may be examples of files that are impossible to CDR without allocating very large amounts of memory. CDR in general requires that an intermediate representation of a file is created. The memory required for the model can be a number of times larger than the original file. Depending on the structure of the underlying file, memory requirements may vary.

Glasswall is the world's premier CDR solution provider. Glasswall is very cautious about the use of 3rd party software dependencies general. We employ a mixture of static analysis, software composition analysis and infrastructure as code automated scanning to ensure that the 3rd party components that we use, do not introduce security flaws. Most software development today, incorporates 3rd party libraries into software applications and Glasswall is no different in this regard. We are however explicit about what these dependencies are and have zero tolerance for insecure software.

Glasswall generates SBOMs for the services that comprise the Halo deployment. These can be made available on request.

Yes that is correct.

Glasswall Halo is designed to be run in a secure environment, therefore none of your data is sent to Glasswall. Glasswall reserves the right to request summary log information to verify license conformance but data does not leave the environment without intervention by the system owner.

In the future, most of the services will use a hardened Alpine base image. Where possible we implement CIS (Centre for Internet Security) guidelines for hardening. Alpine provides a small Linux distribution with a minimised attack surface which is attractive from both a performance and security perspective.

When Halo is overloaded with huge number of API requests the queue will be built up with the messages and 429 status code will be seen. The messages will be eventually consumed by the system and it will come back to normal state. If it takes long time to process the messages in the queue and if you wish to bring the system back to normal state and also ok with loosing messages in the RabbitMQ queue, purge the queue to delete all messages in the queue.

kubectl exec -ncdrplatform -it rabbitmq-server-0 -c rabbitmq -- rabbitmqctl purge_queue engine-request-queue

Monitoring tools integrated with Kubernetes provide insights into the system’s performance, resource usage, and health. Regular maintenance and updates are managed through Kubernetes, ensuring the system remains secure and efficient.

Glasswall Halo employs encryption, secure communication protocols, and strict access controls to protect data. Additionally, the CDR process itself ensures that no malicious content passes through.

Glasswall provides comprehensive documentation, support services, and training materials to help with the implementation and management of the solution. Support channels include online resources, customer support teams, and community forums.

The latency for file processing depends on the file size, complexity and type. However, Glasswall Halo is designed to process files quickly to ensure minimal delay in data transmission.

Kubernetes allows Glasswall Halo to automatically scale based on the load. Using KEDA it can add or remove instances of the CDR service to handle varying amounts of file traffic efficiently.

Learn more about Keda