Cloudhouse Deployment Awareness Briefing Paper

26/11/2019 Cliff Hobbs   ID: 407839


The purpose of this article is to make Customers of Cloudhouse Compatibility Containers™ aware of their obligation and responsibilities regarding the deployment and on-going support of legacy applications within their Compatibility Containers.

The background to this is that legacy applications were designed for deployment against previous generations of environment and systems. Today’s platforms are significantly more secure and hardened, compared with those of the past. However, running legacy applications on today’s platforms may require some compromise of native features of the modern platform as frequently these legacy applications are not able to leverage all of these benefits without significant refactoring.

Customers need to be aware of these compromises, and this article details examples which may be relevant to your organisation and deployment.


Please read this document and discuss it with your account manager or directly with Cloudhouse if you have additional queries.

Cloudhouse expects you to familiarise yourself with how your legacy applications running within our Compatibility Containers are deployed within your environment. We also expect you acknowledge that these deployments are deemed secure and acceptable within your organisation.

Shared Responsibilities

Deployment of legacy applications on today’s platforms may present an increased area of security threat compared with a modern native application. This threat is relative to today’s overall security position for modern and up to date applications on today’s platforms.

Legacy applications currently deployed on legacy environments present the highest level of risk today. Re-platforming a legacy application within a Cloudhouse Compatibility Container and running it on today’s modern platforms significantly enhances the historic legacy security position, albeit not matching 100% the security of a modern native application. 

Therefore, there are a set of shared responsibilities across Cloudhouse and the Customer to sustain an acceptable security level, discussed below.

Cloudhouse Responsibilities

Cloudhouse is committed to maintaining its Compatibility Container technology against future versions of the Windows operating platform. We are continuously testing against historical, current, and future (insider) builds of the Microsoft platforms.

Security for our customers is of paramount importance to us. We work closely with Microsoft and other parties to ensure the security and integrity of our product. As part of our support service, should we discover or be made aware of a security threat which may compromise a Customer’s Container, we will advise the Customer of this threat and make remedial recommendations. 

Customer Responsibilities

The Customer is solely responsible for the configuration and deployment of the target operating system. The primary protection vehicle for protecting a legacy application running on today’s platforms will be the correct and sustained deployment and maintenance of the operating system.

To use a Cloudhouse Compatibility Container, a customer is implicitly accepting the product may potentially, depending on the legacy application's configuration, present several ‘sharp edges’ which increase the security risk when compared to modern applications.

To maintain this level of risk for the legacy application, the Customer is required to run and maintain an operational security maintenance schedule. This should include appropriate security updates of the operating platform and regularly checking for and deploying updated versions of the Cloudhouse Compatibility Container software as required.

Downgrade Configuration Options

Certain legacy applications may require the Data Execution Prevention (DEP) feature of modern Windows operating systems to be disabled. DEP may be required to be disabled for legacy Windows XP, or pre-Windows Server 2003 SP1 applications or for applications built using Visual Studio 2008, etc. Trying to run these applications on today’s platforms results in an access violation.

Cloudhouse Compatibility Containers have a configurable feature that enables an application to opt-out of DEP so that it can run on the desktop or server without operating system-wide changes.

By default, DEP remains enabled, and a specific configuration setting is required to opt-out when packaging a legacy application.

Logging and Diagnostics

Cloudhouse Compatibility Containers have configurable options for logging and diagnostics. By default, logging is off. However, for troubleshooting purposes logging may be enabled.

When logging is enabled, log records are written to a plain text file in a specific subdirectory. The log file may contain detailed, unencrypted sensitive information about the legacy application — for example, path and file names, credentials as parameters, etc.

Customers should ensure they only use logging as intended, and they delete all logging materials in a timely manner. They should also consider who has access to the log files while they exist. 

Packaging Security Risks

The Cloudhouse packaging process requires access to the legacy application and its environment. Full details of the application, its configuration and deployment,  will be needed to configure a Cloudhouse Compatibility Container successfully.

Packaging with installation media on a clean environment will generate a manifest of materials to include in the Compatibility Container based on the installation program/mechanism.

Reverse packaging (where no installation media is available), will scan an existing legacy environment to detect and establish the materials to be packaged into the Compatibility Container. By its nature, this reverse packaging process is not as prescriptive as media-based packaging. Consequently, the Compatibility Container may include excess materials.

Cloudhouse recommends analysing and reviewing the contents of the Compatibility Container post packaging to ensure that only the required elements of the target legacy application are within the Container.


Reverse packaging a deployed legacy application may result in credentials, parameters, paths, file names, etc. being captured and stored in plain text within the Compatibility Container's configuration files. Checks should be made to ensure these are removed.

Anti-Virus and Malware

Several anti-virus (AV) vendors have approved the Cloudhouse Compatibility Container run time. Consequently, the Compatibility Container may be given a higher repudiation score and evade AV detection.

Customers must ensure their packaging environments are clean and malware-free. Cloudhouse recommends scanning all Compatibility Containers for AV and malware before deployment. The risk is that the AV engine may not detect malware packaged into a Compatibility Container.

Cloudhouse Product Updates

To sustain their security profile, Customers must ensure they adhere to their support contract taking and deploying security-based Container updates as required.

Cloudhouse will alert Customers with a support and maintenance contract if they detect a security vulnerability in a Customer’s deployed container. 

Customers should contact for information on how to update pre-existing Compatibility Containers.

Was this article helpful?

Table of Contents

    Can't find what you're looking for?

    Contact Support