As the age of Software as a Service (SaaS) becomes realized, we are finding that this new way of doing business can sometimes be at odds with previous methodologies and processes. Note that this is not particularly insightful as stated since it is derivative of the fundamental definition of disruptive innovation. But the trick with SaaS is that, on the surface, we have the notion of enacting the same standard processes we enact on any other given day (i.e. running software); the only perceived difference is that the software is running external to the enterprise instead of internal to it. Most people do not see that as a significantly different context—running software is running software, whether inside or outside the organizational boundaries.
What people often fail to immediately see is that there is more at play here. Namely, history has given us operational models that are sensitive to the location of where the software is running. The web browser, exemplified by Internet Explorer, is a great example. IE's security model segregates different destinations into appropriate security zones. Each security zone is configured to a different risk profile. The traditional zones include explicitly trusted destinations, intranet destinations, and the rest of the Internet. Under this model, the Internet security zone is risk-averse while the intranet and trusted security zones are more lax.
SaaS challenges this established model of security zones since it involves taking software functionality typically operating internal to the organization (in the intranet security zone) and moving it external to the organization (in the Internet security zone). The same software functionality is now acting under an entirely different risk profile since it is located in a different zone, and that can impact the functionality and/or the user experience.
Let us look at a particular situation applicable to the Zscaler offering. Organizations traditionally host their HTTP proxies within their organizational boundaries. Those proxies operate in the intranet security zone; within this zone, the browser (IE) is willing to automatically authenticate to the proxies using native Windows authentication. The result is that the authentication process is transparent to the user, and everything just works. Now consider what happens when those proxies are moved outside the organization as part of a SaaS: the proxies fall into the Internet zone—and the browser does not natively perform transparent authentication in that zone. In fact, it requires significant browser re-configuration (and arguably some non-ideal loosening of security restrictions) before the browser will once again exhibit this behavior outside the intranet zone. Administrators have grown complacent with automatic HTTP proxy authentication within the organization; we would even venture to call the feature ubiquitous. So imagine the administrators' surprise when this seemingly fundamental HTTP proxy behavior is upset when shifting to a SaaS-provided HTTP proxy. Absolutely nothing about the technology has changed—the only difference is the browser-enforced security model relating to where the resource is located.
So what needs to happen? Vendors need to review and refresh their security models to ensure they are compatible with the SaaS paradigm of transferring once-internal resources out onto the Internet and into the cloud. Fortunately most SaaS services acting as a normal HTTP web site destination can be accommodated by explicit inclusion on the trusted destinations list; SaaS-provided HTTP proxy services are at a much larger loss because that mechanism does not directly apply to proxies. In fact, the proxy configurability and support offered by most web browsers often suffers from legacy networking assumptions and feature atrophy. Internet Explorer in particular introduced the (now) standard crop of proxy capabilities in IE 5 (WPAD and PAC support, circa 1999); we are now one decade later and there have been no additions to IE's proxy configurability or feature support since then. Other browsers have normalized to the same feature set as well, offering no new innovation in that area. I believe that the last ten years have brought about many process changes that warrant revisiting the role that HTTP proxies play in the enterprise, how the web browser should relate to those roles, and how SaaS can affect legacy assumptions of those roles.
So web browser vendors, please hear my plea: after ten years, it is time to blow the dust off of your security models and proxy configurability to ensure they are in-line with the latest SaaS and technology offerings and expectations.
Until next time,
- Jeff
What people often fail to immediately see is that there is more at play here. Namely, history has given us operational models that are sensitive to the location of where the software is running. The web browser, exemplified by Internet Explorer, is a great example. IE's security model segregates different destinations into appropriate security zones. Each security zone is configured to a different risk profile. The traditional zones include explicitly trusted destinations, intranet destinations, and the rest of the Internet. Under this model, the Internet security zone is risk-averse while the intranet and trusted security zones are more lax.
SaaS challenges this established model of security zones since it involves taking software functionality typically operating internal to the organization (in the intranet security zone) and moving it external to the organization (in the Internet security zone). The same software functionality is now acting under an entirely different risk profile since it is located in a different zone, and that can impact the functionality and/or the user experience.
Let us look at a particular situation applicable to the Zscaler offering. Organizations traditionally host their HTTP proxies within their organizational boundaries. Those proxies operate in the intranet security zone; within this zone, the browser (IE) is willing to automatically authenticate to the proxies using native Windows authentication. The result is that the authentication process is transparent to the user, and everything just works. Now consider what happens when those proxies are moved outside the organization as part of a SaaS: the proxies fall into the Internet zone—and the browser does not natively perform transparent authentication in that zone. In fact, it requires significant browser re-configuration (and arguably some non-ideal loosening of security restrictions) before the browser will once again exhibit this behavior outside the intranet zone. Administrators have grown complacent with automatic HTTP proxy authentication within the organization; we would even venture to call the feature ubiquitous. So imagine the administrators' surprise when this seemingly fundamental HTTP proxy behavior is upset when shifting to a SaaS-provided HTTP proxy. Absolutely nothing about the technology has changed—the only difference is the browser-enforced security model relating to where the resource is located.
So what needs to happen? Vendors need to review and refresh their security models to ensure they are compatible with the SaaS paradigm of transferring once-internal resources out onto the Internet and into the cloud. Fortunately most SaaS services acting as a normal HTTP web site destination can be accommodated by explicit inclusion on the trusted destinations list; SaaS-provided HTTP proxy services are at a much larger loss because that mechanism does not directly apply to proxies. In fact, the proxy configurability and support offered by most web browsers often suffers from legacy networking assumptions and feature atrophy. Internet Explorer in particular introduced the (now) standard crop of proxy capabilities in IE 5 (WPAD and PAC support, circa 1999); we are now one decade later and there have been no additions to IE's proxy configurability or feature support since then. Other browsers have normalized to the same feature set as well, offering no new innovation in that area. I believe that the last ten years have brought about many process changes that warrant revisiting the role that HTTP proxies play in the enterprise, how the web browser should relate to those roles, and how SaaS can affect legacy assumptions of those roles.
So web browser vendors, please hear my plea: after ten years, it is time to blow the dust off of your security models and proxy configurability to ensure they are in-line with the latest SaaS and technology offerings and expectations.
Until next time,
- Jeff
