Articles / On Hardware Deployment to Cloud

on 10 Apr 2018

Modern deployment of information technology (IT) systems in a typical enterprise almost always leans in the direction of full virtualization. This approach usually makes good sense, because software is more adaptable than hardware, and with the agility required to support DevOps and other rapid lifecycles, moving hardware into and out of data centers is usually more expensive and lengthy than deploying and maintaining software. So, yes - the enterprise needle continues to move toward software.

That said, there are exceptions. One might argue, for instance, that embedded roots-of-trust are best implemented in hardware, perhaps partly due to the less transient nature of a trusted platform module (TPM) versus a corresponding piece of potentially mutable operating system code. Similarly, one might also argue that certain forms of multi-factor authentication proof are best implemented in something tangible like a physical key or other entity.

Perhaps the most common area where designers tend to prefer hardware involves applications with high performance requirements. Support for distributed denial of service (DDOS) security is a well-known example where the need to process high capacity tends to warrant hardware-based tools to keep websites up and running. An additional emerging use-case where hardware bias can help ensure a good user experience involves support for secure remote browsing.

The idea of secure remote browsing is that man-in-the-middle processing between the browser and a content-rich website can be used to prevent unwanted scripts and executables from having access to the local resources of the session-originating endpoint. Stated more simply: Remote browsing security tools can catch all those nasty content scripts from sites like cnn.com before they can invade and target your PC through the browser.

The challenges to secure remote browsing are basically two-fold: First, carefully crafted security separation is required to ensure that the targeted content does not seep through the filtering gateway. This requires great attention to the direction of information flow between the browser and the website. And second, the need exists to render the web experience in an efficient manner so that users cannot detect any differences in their content experience.

As suggested above, vendors can certainly opt to implement both these requirements in software – and many have, with great success. Menlo Security and Symantec are good options. But if an enterprise chooses the virtual solution because of any presumed bias toward a shorter deployment and support lifecycle, then this might deserve rethinking. Hardware solutions, along the lines of the Garrison dual-ARM design, have impressed me with their scale and surprisingly cloud-friendly deployment and support.

Consider this: Deployment of any modern secure remote browsing tool – whether hardware or software – can be roughly partitioned into three lifecycle components: First, there will be an engineering analysis and planning phase, during which security, capacity, performance, and cost requirements must be factored into a design. Vendor selection activity in this phase will be no different for hardware or software, so direct comparison is moot.

Second, there will be a (hopefully short) deployment stage, during which the selected product is procured, tested, staged, deployed, and then connected to whatever ecosystem tools are in place. The local SIEM, for instance, is likely to be well-positioned to collect logs and other telemetry from the remote browsing tool. Software deployments will typically require fewer steps and a lighter deployment process than their corresponding hardware solutions.

And third, there will be a (probably lengthy) maintenance lifecycle, during which the deployed product is monitored, maintained and administered. A major disadvantage of any software-based remote browsing deployment is the burden inherited by all software during usage. That is, each time a relevant software security vulnerability is announced, the code must be parsed and potentially patched. Hardware solutions tend to be much less trouble in this regard.

Source selection of remote browsing solutions certainly must address local ecosystem, budget, architecture (probably hybrid), and team experience. These are always standard considerations in selecting the best security tools for a given enterprise. But care must be taken to identify and remove any default bias that might exist against hardware solutions for secure remote browsing. Such bias prevents the security and performance gains possible only with hardware.

My advice is to include a hardware-based secure remote browsing tool in your overall vendor procurement analysis – and a great one to include is the Garrison solution. It appears to me to provide all the fine benefits of hardware efficiency for great content experiences, while matching up well with more traditional virtualized equivalents. Good luck with your source selection. Lots of great choices!