The beginning of July was a big week for data center outages with some notable Internet impact. I've written before about cloud resiliency and uptime in my 'Changing a tire while going 60mph' and 'Big, white puffy clouds can still evaporate' posts.
Amongst those outages was a Google App Engine interruption, which just goes onto the tally sheet as yet another failure of a supposed infallible cloud platform service. Ted Dziuba has some interesting viewpoints on the App Engine outage, and brings up a key element that makes all the difference with these types of outages: transparency. If something fails, people like to know why it happened (especially in light of all the resiliency/redundancy claims of the cloud) and what is being done so it doesn't happen again. Google's transparency was a basic statement that something bad happened with GFS, and that affected BigTable, which affected App Engine's DataStore, and they are going to fix it. Now, compare that level of detail to the information offered by Amazon during their S3 outage from July 2008 and February 2008. There is a notable difference. So a message to SaaS vendors: just because customers don't need to know the platform and implementation details behind your SaaS, doesn't mean they don't want to know...especially in light of a catastrophic failure. Telling customers what went wrong let's them enact their own post-mortem and due-diligence analysis processes to ensure they haven't shackled themselves to a SaaS vendor who is experiencing outages due to silly oversights that are likely to repeat as life goes on.
Actually, transparency and efficient communication regarding the outage event was also a key issue for some of the other outages last week. Jeremy Irish blogged about the fire at Fisher Plaza data center that left his systems offline for 29 hours. Apparently news of what exactly was happening, even for the first responders that were physically present at the building, was scarce and little effort was made to keep folks efficiently informed. Eventually they found out that it was a fire in a basement-level electrical room, which triggered the sprinklers and in turn ruined additional electrical equipment and generators, which ultimately caused significant damage to the power infrastructure.
Overall, Murphy and his laws are a fact of life and vendors (cloud, SaaS, or other) must do what is in their power to have contingency plans if you truly want to maintain availability and business continuity. And SaaS vendors, take note: just because you can hide the implementation and platform details of your service, doesn't mean you should hide the operational details of your service...especially during a service disruption.
Until next time,
- Jeff
Showing posts with label SaaS. Show all posts
Showing posts with label SaaS. Show all posts
Tuesday, July 7, 2009
Monday, March 23, 2009
New browser security model needed for SaaS?
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
Subscribe to:
Posts (Atom)
Posts
