Customer obligations and responsibilities of using Cloudhouse software

Applies to: Cloudhouse Application Compatibility Packages/Compatibility Containers

Customers using Cloudhouse's software have the obligations and responsibilities detailed in this article regarding the deployment, on-going use, and support of legacy applications within their Cloudhouse Application Compatibility Packages/Compatibility Containers™.

Legacy applications were designed for deployment against previous generations of environments and systems. Today's platforms are significantly more secure and hardened, compared to 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 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.

Note

Feel free to contact us if you have any queries regarding this article.


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

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 Microsoft's 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, if we discover or become aware of a security threat which potentially compromises a Customer's Container, we will advise Customers of this along with remedial actions (see Cloudhouse Urgent Security Update Support Process for more details).

Customer responsibilities

Customers are 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 legacy applications, Customers are required to run and maintain an operational security maintenance schedule. This schedule 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 need to be disabled for legacy Windows XP, or pre-Windows Server 2003 SP1 applications or for applications built using Visual Studio 2008, amongst others. 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 legacy applications.

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 folder. The log file may contain detailed, unencrypted sensitive information about the legacy application — for example, path, file names, credentials as parameters, etc.

Customers should ensure they only use logging as intended, and delete all logging materials promptly. 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 the installation media is unavailable), scans 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 Compatibility Container.

Note

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 to remove these should be made.

Anti-Virus and Malware

Several anti-virus (AV) vendors have approved the Cloudhouse Compatibility Container runtime. 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 Compatibility 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 Compatibility Container. 

Customers should contact Support@Cloudhouse.com for information on how to update pre-existing Compatibility Containers.

Was this article helpful?

Can't find what you're looking for?

Contact Support