SSL gets an SEO promotion in rank from Google. Business loses its mind.

#SSL Forget #infosec benefits and #webperf implications, SSL just did an end-run around IT and went straight to the business. With fewer than 1/3 of organizations securing apps with SSL, that could be a problem. If the business isn't panicking, it should be.   

Google is taking a stand on security, and using the power of placement to get the word out: SSL is important. Given that fewer than one-third of all web apps are secured with SSL despite its benefits, strong-arm business tactics may be just what the security doctor ordered.

Google is taking a stance on security and has made SSL a piece of their ranking algorithm. As we are aware search engine ranking remains one of the single most important components of any organization’s branding efforts and online presence.

    -- HTTPS as a ranking signal, August 6, 2014

in its announcement regarding the inclusion of SSL (or TLS) in its ranking algorithms, Google also noted some best practices to get folks started in their journey to a more secure web presence. Most focus on the strength of the certificate keys you should use (2048 at least) and app development tips that can make the transition between HTTP and HTTPS less disruptive, such as using relative URLs.

But even so, what isn't mentioned is the administrative nightmare imposed by turning on SSL (or TLS) on every app server in the data center. It's not just the short term go out and get them (which aren't cheap, by the way) and get them deployed, it's also the impact long term on managing expirations as well as figuring out how all the services in the network between the end-user and the app - like that IDS and IPS, your anti-virus and anti-fraud, your WAF, etc... - are going to perform their tasks blindly. Without a solid strategy moving forward, simply turning on SSL on an application disrupts not only operations but a whole lot of security and business-related services.

One of the ways in which this journey can be made much less disruptive is by taking advantage of strategic transition points along an application's data path where SSL can be applied (and thus also managed) centrally. This point logically occurs at the point at which the application is virtualized for purposes of scale and reliability. In other words, at the load balancer or application delivery controller (ADC).

 

By using an ADC or an application proxy as a natural protocol gateway (something that can transition easily between two protocols like HTTP and HTTPS, or vice versa) the disruption of enabling SSL everywhere (which is a Very Good Thing^TM by the way) on every app server can be effectively eliminated.

The reality is that your load balancer (LB) or ADC or application proxy (AP) is, for all intents and purposes, The Application as far as the end-user is concerned. It is at the LB or ADC or AP that an application is "virtualized" and presented to the outside world. When an end-user connects to www.myapp.com they are almost certainly connecting not to the app, but to a load balancing service or an ADC or an application proxy.

This provides a strategic opportunity for organizations to centralize capabilities like enabling SSL or supporting next-generation protocols like SPDY or HTTP 2.0 without incurring the costs and headaches associated with upgrading and updating each and every one of the hundreds (or thousands) of servers that provide the resources for that application.

But the argument is no longer going to be focused on the technical merits or even the security benefits. The SSL argument has just gone business, because search engine ranking is a significant component of today's business. With SSL part of that ranking equation, the business is going to see competitive advantage in getting "out there" first with SSL to help boost their search rankings before their competitors. IT can be the hero this time by using a strategic point of control to get it done, and get it done fast.

That means you're going to need a game plan, and you're going to need it sooner rather than later.