Rational Survivability

Simulação da participação de um Firewall entre uma LAN e uma WAN Français : Schéma d’un pare-feu entre un LAN et un WAN (Photo credit: Wikipedia)

“Should/Can/Will Virtual Firewalls Replace Physical Firewalls?”

The answer is, as always, “Of course, but not really, unless maybe, you need them to…” 🙂

This discussion crops up from time-to-time, usually fueled by a series of factors which often lack the context to appropriately address it.

The reality is there exists the ever-useful answer of “it depends,” and frankly it’s a reasonable answer.

Back in 2008 when I created “The Four Horsemen of the Virtualization Security Apocalypse” presentation, I highlighted the very real things we needed to be aware of as we saw the rapid adoption of server virtualization…and the recommendations from virtualization providers as to the approach we should take in terms of securing the platforms and workloads atop them.  Not much has changed in almost five years.

However, each time I’m asked this question, I inevitably sound evasive when asking for more detail when the person doing the asking references “physical” firewalls and what it is they mean.  Normally the words “air-gap” are added to the mix.

The very interesting thing about how people answer this question is that in reality, the great many firewalls that are deployed today have the following features deployed in common:

1. Heavy use of network “LAG” (link aggregation group) interface bundling/VLAN trunking and tagging
2. Heavy network virtualization used, leveraging VLANs as security boundaries, trunked across said interfaces
3. Increased use of virtualized contexts and isolated resource “virtual systems” and separate policies
4. Heavy use of ASIC/FPGA and x86 architectures which make use of shared state tables, memory and physical hardware synced across fabrics and cluster members
5. Predominant use of “stateful inspection” at layers 2-4 with the addition of protocol decoders at L5-7 for more “application-centric” enforcement
6. Increasing use of “transparent proxies” at L2 but less (if any) full circuit or application proxies in the classic sense

So before I even START to address the use cases of the “virtual firewalls” that people reference as the comparison, nine times out of ten, that supposed “air gap” with dedicated physical firewalls that they reference usually doesn’t compute.

Most of the firewall implementations that people have meet most of the criteria mentioned in items 1-6 above.

Further, most firewall architectures today aren’t running full L7 proxies across dedicated physical interfaces like in the good old days (Raptor, etc.) for some valid reasons…(read the postscript for an interesting prediction.)

Failure domains and the threat modeling that illustrates cascading impact due to complexity, outright failure or compromised controls is usually what people are interested in when asking this question, but this gets almost completely obscured by the “physical vs. virtual” concern and we often never dig deeper.

There are some amazing things that can be done in virtual constructs that we can’t do in the physical and there are some pretty important things that physical firewalls can provide that virtual versions have trouble with.  It’s all a matter of balance, perspective, need, risk and reward…oh, and operational simplicity.

I think it’s important to understand what we’re comparing when asking that question before we conflate use cases, compare and mismatch expectations, and make summary generalizations (like I just did 🙂 about that which we are contrasting.

I’ll actually paint these use cases in a follow-on post shortly.

/Hoff

POSTSCRIPT:

I foresee that we will see a return of the TRUE application-level proxy firewall — especially with application identification, cheap hardware, more security and networking virtualized in hardware.  I see this being deployed both on-premise and as part of a security as a service offering (they are already, today — see CloudFlare, for example.)

If you look at the need to terminate SSL/TLS and provide for not only L4-L7 sanity, protect applications/sessions at L5-7 (web and otherwise) AND the renewed dependence upon XML, SOAP, REST, JSON, etc., it will drive even more interesting discussions in this space.  Watch as the hybrid merge of the WAF+XML security services gateway returns to vogue… (see also Cisco EOLing ACE while I simultaneously receive an email from Intel informing me I can upgrade to their Intel Expressway Service Gateway…which I believe (?) was from the Cervega Sarvega acqusition?)

Related articles

• Incomplete Thought: Virtual/Cloud Security and The Potemkin Village Syndrome
• Software Defined Networking (In)Security: All Your Control Plane Are Belong To Us…
• SiliconAngle Cube: Hoff On Security – Live At VMworld 2012

Cloud Computing Image (Photo credit: Wikipedia)

If you’ve been paying attention to the rash of security startups entering the market today, you will no doubt notice the theme wherein the majority of them are, from the get-go, organizing around deployment models which operate from “The Cloud.”

We can argue that “Security as a service” usually refers to security services provided by a third party using the SaaS (software as a service) model, but there’s a compelling set of capabilities that enables companies large and small to be both effective, efficient and cost-manageable as we embrace the “new” world of highly distributed applications, content and communications (cloud and mobility combined.)

As with virtualization, when one discusses “security” and “cloud computing,” any of the three perspectives often are conflated (from my post “Security: In the Cloud, For the Cloud & By the Cloud…“):

In the same way that I differentiated “Virtualizing Security, Securing Virtualization and Security via Virtualization” in my Four Horsemen presentation, I ask people to consider these three models when discussing security and Cloud:

1. In the Cloud: Security (products, solutions, technology) instantiated as an operational capability deployed within Cloud Computing environments (up/down the stack.) Think virtualized firewalls, IDP, AV, DLP, DoS/DDoS, IAM, etc.
2. For the Cloud: Security services that are specifically targeted toward securing OTHER Cloud Computing services, delivered by Cloud Computing providers (see next entry) . Think cloud-based Anti-spam, DDoS, DLP, WAF, etc.
3. By the Cloud: Security services delivered by Cloud Computing services which are used by providers in option #2 which often rely on those features described in option #1.  Think, well…basically any service these days that brand themselves as Cloud…

What I’m talking about here is really item #3; security “by the cloud,” wherein these services utilize any cloud-based platform (SaaS, PaaS or IaaS) to delivery security capabilities on behalf of the provider or ultimate consumer of services.

For the SMB/SME/Branch, one can expect a hybrid model of on-premises physical (multi-function) devices that also incorporate some sort of redirect or offload to these cloud-based services. Frankly, the same model works for the larger enterprise but in many cases regulatory issues of privacy/IP concerns arise.  This is where the capability of both “private” (or dedicated) versions of these services are requested (either on-premises or off, but dedicated.)

Service providers see a large opportunity to finally deliver value-added, scaleable and revenue-generating security services atop what they offer today.  This is the realized vision of the long-awaited “clean pipes” and “secure hosting” capabilities.  See this post from 2007 “Clean Pipes – Less Sewerage or More Potable Water?”

If you haven’t noticed your service providers dipping their toes here, you certainly have seen startups (and larger security players) do so.  Here are just a few examples:

• Qualys
• Trend Micro
• Symantec
• Cisco (Ironport/ScanSafe)
• Juniper
• CloudFlare
• ZScaler
• Incapsula
• Dome9
• CloudPassage
• Porticor
• …and many more

As many vendors “virtualize” their offers and start to realize that through basic networking, APIs, service chaining, traffic steering and security intelligence/analytics, these solutions become more scaleable, leveragable and interoperable, the services you’ll be able to consume will also increase…and they will become more application and information-centric in nature.

Again, this doesn’t mean the disappearance of on-premises or host-based security capabilities, but you should expect the cloud (and it’s derivative offshoots like Big Data) to deliver some really awesome hybrid security capabilities that make your life easier.  Rich Mogull (@rmogull) and I gave about 20 examples of this in our “Grilling Cloudicorns: Mythical CloudSec Tools You Can Use Today” at RSA last month.

Get ready because while security folks often eye “The Cloud” suspiciously, it also offers up a set of emerging solutions that will undoubtedly allow for more efficient, effective and affordable security capabilities that will allow us to focus more on the things that matter.

/Hoff

Related articles by Zemanta

• [Webinar] Cloud Based Security Services: Saving Cloud Computing Users From Evil-Doers (rationalsurvivability.com)
• The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse… (rationalsurvivability.com)
• DDoS – A Moose On Cloud’s Table Or A Pea Under The Mattress? (rationalsurvivability.com)
• Six Year Old Rationalizes the Cloud (rationalsurvivability.com)
• Cloud Computing Security: (Orchestral) Maneuvers In the Dark? (rationalsurvivability.com)
• Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure (rationalsurvivability.com)
• You Can’t Secure The Cloud… (rationalsurvivability.com)
• Security and the Cloud – What Does That Even Mean? (rationalsurvivability.com)

• Building/Bolting Security In/On – A Pox On the Audit Paradox! (rationalsurvivability.com)
• Security As A Service: Virtual Patching for Cloud Environments (canadacloud.biz)
• Security As A Service Is More Than A Virtual Security Gateway (securecloudreview.com)
• The Inevitability of Security-as-a-Service (securecloudreview.com)

My friend and skilled raconteur Chris Swan (@cpswan) wrote an excellent piece a few days ago titled “Building security in – the audit paradox.”

This thoughtful piece was constructed in order to point out the challenges involved in providing auditability, visibility, and transparency in service — specifically cloud computing — in which the notion of building in or bolting on security is debated.

I think this is timely.  I have thought about this a couple of times with one piece aligned heavily with Chris’ thoughts:

• Revisiting virtualization and cloud stack security — Back to the future (baked in or bolted on)

Chris’ discussion really contrasted the delivery/deployment models against the availability and operationalization of controls:

1. If we’re building security in, then how do we audit the controls?
2. Will platform as a service (PaaS) give us a way to build security in such that it can be evaluated independently of the custom code running on it?

Further, as part of some good examples, he points out the notion that with separation of duties, the ability to apply “defense in depth” (hate that term,) and the ability to respond to new threats, the “bolt-on” approach is useful — if not siloed:

There lies the issue – bolt on security is easy to audit. There’s a separate thing, with a separate bit of config (administered by a separate bunch of people) that stands alone from the application code.

…versus building secure applications:

Code security is hard. We know that from the constant stream of vulnerabilities that get found in the tools we use every day. Auditing that specific controls implemented in code are present and effective is a big problem, and that is why I think we’re still seeing so much bolting on rather than building in.

I don’t disagree with this at all.  Code security is hard.  People look for gap-fillers.  The notion that Chris finds limited options for bolting security on versus integrating security (building it in) programmatically as part of the security development lifecycle leaves me a bit puzzled.

This identifies both the skills and cultural gap between where we are with security and how cloud changes our process, technology, and operational approaches but there are many options we should discuss.

Thus what was interesting (read: I disagree with) is what came next wherein Chris maintained that one “can’t bolt on in the cloud”:

One of the challenges that cloud services present is an inability to bolt on extra functionality, including security, beyond that offered by the service provider. Amazon, Google etc. aren’t going to let me or you show up to their data centre and install an XML gateway, so if I want something like schema validation then I’m obliged to build it in rather than bolt it on, and I must confront the audit issue that goes with that.

While it’s true that CSP’s may not enable/allow you to show up to their DC and “…install and XML gateway,” they are pushing the security deployment model toward the virtual networking hooks, the guest based approach within the VMs and leveraging both the security and service models of cloud itself to solve these challenges.

I allude to this below, but as an example, there are now cloud services which can sit “in-line” or in conjunction with your cloud application deployments and deliver security as a service…application, information (and even XML) security as a service are here today and ramping!

While  immature and emerging in some areas, I offer the following suggestions that the “bolt-on” approach is very much alive and kicking.  Given that the “code security” is hard, this means that the cloud providers harden/secure their platforms, but the app stacks that get deployed by the customers…that’s the customers’ concerns and here are some options:

1. Introspection APIs (VMsafe)
2. Security as a Service (Cloudflare, Dome9, CloudPassage)
3. Auditing frameworks (CloudAudit, STAR, etc)
4. Virtual networking overlays & virtual appliances (vGW, VSG, Embrane)
5. Software defined networking (Nicira, BigSwitch, etc.)

Yes, some of them are platform specific and I think Chris was mostly speaking about “Public Cloud,” but “bolt-on” options are most certainly available an are aggressively evolving.

I totally agree that from the PaaS/SaaS perspective, we are poised for many wins that can eliminate entire classes of vulnerabilities as the platforms themselves enforce better security hygiene and assurance BUILT IN.  This is just as emerging as the BOLT ON solutions I listed above.

In a prior post “Silent Lucidity: IaaS – Already a Dinosaur. Rise of PaaSasarus Rex”

As I mention in my Cloudifornication presentation, I think that from a security perspective, PaaS offers the potential of eliminating entire classes of vulnerabilities in the application development lifecycle by enforcing sanitary programmatic practices across the derivate works built upon them.  I look forward also to APIs and standards that allow for consistency across providers. I think PaaS has the greatest potential to deliver this.

There are clearly trade-offs here, but as we start to move toward the two key differentiators (at least for public clouds) — management and security — I think the value of PaaS will really start to shine.

My opinion is that given the wide model of integration between various delivery and deployment models, we’re gonna need both for quite some time.

Back to Chris’ original point, the notion that auditors will in any way be able to easily audit code-based (built-in) security at the APPLICATION layer or the PLATFORM layer versus the bolt-on layer is really at the whim on the skillset of the auditors themselves and the checklists they use which call out how one is audited:

Infrastructure as a service shows us that this can be done e.g. the AWS firewall is very straightforward to configure and audit (without needing to reveal any details of how it’s actually implemented). What can we do with PaaS, and how quickly?

This is a very simplistic example (more infrastructure versus applistructure perspective) but represents the very interesting battleground we’ll be entrenched in for years to come.

In the related posts below, you’ll see I’ve written a bunch about this and am working toward ensuring that as really smart folks work to build it in, the ecosystem is encouraged to provide bolt ons to fill those gaps.

/Hoff

Related articles

• From the Concrete To The Hypervisor: Compliance and IaaS/PaaS Cloud – A Shared Responsibility (rationalsurvivability.com)
• Incomplete Thought: Why Security Doesn’t Scale…Yet. (rationalsurvivability.com)
• I’ll Say It Again: Security Is NOT the Biggest Barrier To Cloud… (rationalsurvivability.com)
• Hack The Stack Or Go On a Bender With a Vendor?
• Incomplete Thought: Why Security Doesn’t Scale…Yet,
• What’s The Problem With Cloud Security? There’s Too Much Of It…,
• Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are…
• Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…

A lot of fuss has been made about run-away VM sprawl in enterprises who are heavily virtualized due to the ease with which a VM can constructed and operationalized.

I’m not convinced about the reality versus the potential of VM Sprawl, meaning that I have no evidence from anyone facing this issue to date.  I wrote about this a while ago here.

As virtualization and the attendant vendors push more from enterprise virtualization to enterprise Clouds, what I’m actually more concerned with is SaaSprawl.

This scenario describes how enterprises will deal with managing what could amount to dozens of “CloudSourced” SaaS vendors as companies edge toward Cloud adoption by cherry picking applications for externalization using SaaS as the platforms, technologies and standards catch up to allow those pesky workloads that used to run internally, to do the same externally…

Outsource email, security, CRM, ERP, Legal/HR, Purchasing, Desktop apps — all from different vendors, each with different contracts, SLA’s, data integration issues, security concerns, audit constraints, regulatory compliance hiccups.

What we likely could end up with is another illustration of a “squeezing the balloon” problem; trading off CapEx for what I call OopsEx — realizing what might amount to substituting one problem for another as you trade reduced upfront (and on-going) capital investment for what amounts to on-going management, security, compliance and service-level management issues in the long term.

Thoughts?

There I was in the middle of a half moon yoga pose when the thought hit…

I was on a Telepresence the other day with @jamesurquhart and a couple of other colleagues and we were discussing the notion of Cloud services and multitenancy again.

I brought up a well-known Cloud provider who serves thousands (if not tens of thousands) of unique customers.  I argued that based upon what I was told by system architects, the service was never really designed with multitenancy in mind.  James argued to the contrary maintaining that he has had numerous discussions with the same architects and was convinced my point was invalid.

This got me thinking as to how, if we were talking to the same architects, we came away with a diametrically opposed understanding.

It should be noted that this vendor does not use server/OS virtualization in their offering and since multitenancy is often (improperly) associated directly with server/OS virtualization, we recognized that this wasn’t our disconnect.

Then it dawned on me (well today, during Yoga.)  I was talking about the notion of application multitenancy and James was talking about the database/datastore aspects of multitenancy!  The front-end versus the back-end versus the entire stack…

So of course from James’ perspective, the architects definitely built the database, schemas and table structures to support isolated, discrete and “secure” multitenancy.

However from my perspective, the application itself — a single application — isn’t “multitenant” insomuch as it is multi-user.  The application provides a common programmatic entry point (however customized in presentation) to a specific dataset to which James was referring.

Aha!  Seems simple and somewhat silly, but it never occurred to me that we were just thinking from different ends of the stack; this time I was top-down and James was bottoms-up.  Funny as James is the app. guy and I am the Infrastructure bobblehead.  Stupid siloed thinking on my part distracted me from what I know is a larger system architecture artifact that is easy to spot if I had only taken the goggles off.

This is important because when we apply Cloud definitions to SaaS providers wherein the required characteristics “require” multitenancy (see my post here,) many if not most SaaS offerings fail to meet the criterion.  If we think along the lines of not just qualifying the ‘application’ but expand ‘software’ in SaaS to more broadly include the entire stack including the database, it passes the sniff test.

I have to tell you that this was, despite my own taxonomy diagrams which point out this very fact, a block in my vision which was causing me angst.

So, remember, when we’re talking about SaaS, just because the application front-end may not smell of multitenancy, the underlying platform and database probably will — especially if it’s going to scale to elastic cloud levels.

Silly little lightbulbs go off in the most interesting of times.

/Hoff

"Cloud Providers Are Better At Securing Your Data Than You Are…"

To some, this is a contentious point while to others it seems entirely logical.

I must tell you that I've witnessed this very assertion as it has been raised more times in the last few days than I can count.

Before I get into any more juicy bits regarding this topic, I wonder if you wouldn't mind popping over and reading a blog post I wrote in August, 2007 titled "On-Demand SaaS Vendors Able to Secure Assets Better than Customers?" 

Come to think of it, you can read the follow-on post to that one which clearly indicated my point when Salesforce.com and Monster.com (you know, those so-called "Cloud" providers) were breached.

Forgot about those breaches, did you?  Oh, that must have been because they were SaaS providers and not Cloud providers at the time.  Gotcha.

As you read these posts, first do so within the context of what we've come to know as software as a service (SaaS.)  Then kindly re-read it and substitute 'SaaS' with 'Cloud,' won't you?

Thanks.

I have more, but I'll wait till you're done.

/Hoff

Something interesting just occurred to me as my (now) four year old and a couple of her friends were huddled around one of the computers in my office playing a Dragon Tales coloring game while my seven and eleven year old were in their respective rooms playing with the virtual pets in their virtual worlds of Webkinz.

Why is the fact that my kids are huddled around their Mac Mini’s on a cold day playing computer games in any way remarkable?  Because all of them were playing games which are hosted and presented via the Internet; no software except a browser required on this end.

So? 

Well, the really interesting thing was that my wife reminded me that we haven’t purchased ANY children’s software titles in the last two years because all of the games, learning applications and reference materials are all on-line.  Software as a, well, service.  And mostly free to boot!  The same usually can’t be said in the, um, "adult" realm.

This sounds like the kiddy version of GoogleApps.  How long until you don’t even have to buy a DVD for your XBox, PS3 or Wii…as high speed feeds continue to rise, it’s not that large of a stretch…

I think it’s a very interesting perspective on the more "mainstream" adoption of SaaS and a rather interesting way of monetizing it.  In the case of Webkinz, while the virtual world — replete with currency, domiciles, and social services — is free, one has to purchase a physical doll which has attached to it a "secret code" that one uses to register your pet in Webkinz World.  You then give it a name and choose a sex and start building rooms.

It’s basically second life for kids — without the job fairs (yet.)  My wife has now informed me that she’s going to get her own doll to play with the kids online.  I wonder if we’ll actually ever speak to one another in person any more!? 

Scratch that, she’s at this moment registering a bulldog named Waldo.

I’m hoping they start making 5’11 blonde Swedish nurse Webkinz soon…

…which reminds me, given the fact that since all this kid’s software is now on-line, how long until someone compromises it for unseemly reasons?   An interesting attack vector, no doubt.  I think I’ll call it SaaD – Software as a Disservice?

/Hoff

Back in August I wrote a post debating against the notion that SaaS vendors were apparently, by definition, "…able to secure assets better than customers." 

My position on the "quality" levels of security from SaaS vendors was reasonably straightforward.  I’ll summarize it here:

Not one to appear unclear on where I stand, I maintain that the SaaS
can bring utility, efficiency, cost effectiveness, enhanced
capabilities and improved service levels to a corporation depending
upon who, what, why, how, where and when the service is
deployed.  Sometimes it can bring a higher level of security to an
organization, but so can an armed squadron of pissed off armed Oompa
Loompa’s — it’s all a matter of perspective.
…
So just to be clear, I believe in SaaS.  I encourage its use if it
makes good business sense.  I don’t, however, agree that you will
automagically be *more* secure.  You maybe just *as* secure, but it
should be more cost-effective to deploy and manage.  There may very
well be cases (I can even think of some) where one could be more
or even less secure, but I’m not into generalizations.

This is all a matter of context; what sort of data is stored, what value does it hold, who can access it and what assessment of risk has been performed to determine the impact to the company should it fall into the wrong hands? 

Many times the "security" of the SaaS service comes right down to basic security practices such as access control.  For example, I’ve seen multiple times that SF.com login accounts of salesfolk that went to competitors were left enabled after separation, potentially exposing the forecast, pipeline, customer service records and customer details of the entire customer base.  That’s not the SaaS vendor’s fault, but is a potential issue systemic to the model.

As the adoption of SaaS increases driven by compliance, outsourcing, or efficiencies of a leveraged business model, we’re going to have to pay more attention to what it means to have our data spread out beyond those supposedly impenetrable perimeter boundaries we’ve spent all that time and money on.

Again, that means more than reviewing a SAS-70 or taking the vendor’s word that they are secure.  It means making sure your policies extend and are applicable "outside the castle."  It means potentially engaging a third party to test the assertions the company makes about their posture.

A great example are two recent debacles from SaaS vendors Salesforce.com and Monster.com. Brian Krebs from the Washington Post recently did a great job illustrating the issues that a breach from an SaaS vendor causes; there’s a "secondary market" for breach data and once the information is loose, the lost trust can mean lost business:

A database of e-mail addresses and other contact information stolen from business software provider Salesforce.com
is being used in an ongoing series of targeted e-mail attacks against
customers of several Salesforce.com business clients, including SunTrust and Automatic Data Processing Inc. (ADP), one of the nation’s largest payroll and tax services providers.
…
In August, job search giant Monster.com‘s resume
database was breached by hackers, exposing confidential data on 1.3
million job seekers. The attackers then used the contact information
from that database to send users targeted e-mails that appeared to come
from Monster.com. Recipients were directed to click on a link in the
message, which tried to install malicious software through Web browser
security vulnerabilities.

Salesforce.com and Monster.com provide valuable SaaS functions to corporations globally and it illustrates the fragile mantle of trust upon which we tread.  There exists a tenuous balance when outsourcing applications and information processing/storage to a third party.

Some folks argue that any information entrusted to a third party business partner or vendor (email addresses included) are "private" while others might suggest that if you’ve decided to outsource this function beyond the realm of your ability to protect it, any information outside the castle should be considered public and dealing with its exposure should be something you’re prepared for.

This comes down to a maintaining a posture of what I call Information Centricity and an appropriate level of information classification paired with the assessment of risk assuming something ‘bad’ happens to it.

As a free piece of advice to SaaS vendors and customers alike, comments like this are not a good way of handling the press regarding a breach:

Salesforce.com’s Bruce Francis, the company’s vice
president of corporate strategy, declined to say whether any
customer-specific data was stolen, and refused to answer direct
questions about the alleged incident, saying that doing so would not be
in the best interests of its customers. He did, however, stress several
times that "phishing is a fact of life for any company that does
business on the Internet these days."

/Hoff

Update:  Bill Brenner just did a nice write-up on this same topic and was kind enough to reference/quote me and the RS Blog.  You can read his piece here.  I also got some interesting feedback from Bob Warfield over at the SmoothSpan blog ( a fantastic SaaS reference) which I will ask if I can reprint.

In response to my post regarding the CapGemini/GoogleApps relationship, in which I espoused the benefits of the upcoming service offering, Alan Shimel obviously forgot to take his meds as he referenced some bizarre military campaign reference in his post titled "Yesterday’s Argument, Tomorrow’s Solution."

I really tried to keep up with Alan’s logic in this post, but try as I might, I could not make heads or tails from Alan’s arguments in which seemed to contradict himself and ultimately make the same argument I did in my post.

As far as I can tell, Alan is suggesting that I’m out of touch with the realities of market economics and that security, privacy and compliance have no impact on the adoption of SaaS:

One of the classic mistakes that armies on the losing side make is
fighting the next war with the last wars weapons and tactics.  I am
afraid Mr Hoff is guilty as charged in talkingGoogle/CapGemini deal.  In case you have not heard, CapGemini will offer Google Apps to the one million strong corporate desktops that it services. 

Firstly, this announcement is less than 12 hours old.  I hardly see how I’m on the "losing" side of anything? I’ve been suggesting that Google is in a position to encroach upon and own multiple markets currently monopolized by titans.  Alan’s already disagreed with me on Microsoft vs. Google once before, but that’s not what this is about.  I really don’t understand what the heck he means by my supposed "guilt" in "taking the losing side."

Chris
does a nice job of explaining how CG will make money on this and some
of the advantages of Google Apps. However, Chris seems to side on the
camp of those who think that SaaS based, centrally managed applications
and the data that goes with it, will present compliance and security
concerns that could slow adoption. 

Um, yeah!  Want some electricity for that cave you’re living in!?  You’re not seriously suggesting that privacy, security and compliance do not hinder the adoption of technology and services are you, and more specifically, centrally-hosted applications and data?

I say poppycock to that.

I guess you are.

I heard the same thing about Qualys storing vulnerability data 5 years
ago and over the intervening time have seen that argument melt away
except for maybe in the federal government space.  In fact Qualys has
now become the tester of choice for PCI compliance in many cases.  But
beyond that, the whole issue of outsourcing application hosting brings
me back to my days at Interliant, an early entrant into the ASP
market.  We hosted Lotus Notes, PeopleSoft and other enterprise level
applications. As well as managed security (mostly checkpoint firewalls,
which was sold to Akiva).

Just so I understand this, Alan is ignoring the history of my blog and then attempts to shore up his point by citing the poster child of Security SaaS for the last 6 years or so, Qualys.  For those of who who read my blog regularly,
you already know that (1) I am a huge proponent of SaaS, and (2) I was
a Qualys customer and advisory board member.  Alan obviously doesn’t
recognize either of those points.

To wit, storing scrubbed and encrypted vulnerability data (as Qualys does) is
quite different than storing unparsed, unencrypted sensitive corporate data which is intended to be collaboratively shared. 

The issue has not melted away, Alan…in fact, it’s the impetus of probably half of the security industry’s income statements, including yours.

One thing that we learned the hard way at Interliant is that people will not outsource applications which they consider critical and core
to the business.  So for instance, if they were an accounting firm,
they would probably not outsource the hosting and management of their
accounting software.  However, critical, non-core applications are good
candidates for outsourcing.  I think for the most part, this is exactly
where the Google Apps fall.  I think the success of hosted CRM like
Salesforce.com also shows that people are willing to outsource
critical, non-core applications.

So there’s been no movement in the adoption of SaaS from your experience 6 years ago at Interliant?  Look, SaaS is certainly on the uptake and it’s bringing new and interesting avenues to market for services that range from hosted apps to security, but it’s far from ubiquitous and it’s certainly got its fair share of scale, security and privacy concerns to deal with.

Poppycock away all you like, but riddle me this, how is it that you do not
consider email, spreadsheets, presentations and documents "…critical
and core to the business?"  I dare you to turn off your email fora week and tell me it’s not critical.

Now the fact that it is Google
after all, raises in my mind anyway, two other issues. One is the
privacy of my data from Google.  Is Google going to use that to hone
the ad words they serve up to me?  The other is that as Google
continues to grow, will it suffer from Microsoft like "evil empire"
syndrome, where people attach dark aspirations to everything they do.
I guess we will have to see how this plays out.

You just contradicted yourself and reinforced the exact point I made!  So now you’re concerned about privacy and hosted data?  That’s what my post was about entirely.

SaaS does and will absolutely continue to drive privacy concerns, especially for the very reasons at the end of your argument you make such a big point about highlighting.  I even talked about this in this post here titled "On-Demand SaaS Vendors Able to Secure Assets Better than Customers?"

I can’t figure out what point Alan’s making here; he seems to agree and disagree with my posting in the same post.

/Hoff

Coming (securely?) soon to a managed enterprise desktop near you, GoogleApps.  As discussed previously in my GooglePOP post demonstrating how Google will become the ASP of choice, outsouring and IT Consultancy CapGemini
announced it is going to offer Google’s Apps as a managed SaaS desktop option to its corporate enterprise customers, the Guardian says today:

Google has linked up with IT consultancy and outsourcing specialist
CapGemini to target corporate customers with its range of desktop
applications, in the search engine’s most direct move against the
dominance of Microsoft.

CapGemini, which already runs the
desktops of more than a million corporate workers, will provide its
customers with "Google Apps" such as email, calendar, spreadsheets and
word processing.

…

"Microsoft
is an important partner to us as is IBM," said the head of partnerships
at CapGemini’s outsourcing business, Richard Payling. "In our client
base we have a mix of Microsoft users and Lotus Notes users and we now
have our first Google Apps user. But CapGemini is all about freedom,
giving clients choice of the most appropriate technology that is going
to fit their business environment."

Google’s applications such as
its Google Docs word processing and spreadsheet service allow several
people to work on one document and see changes in real time.

"If
you look at the traditional desktop it is very focused on personal
productivity," said Robert Whiteside, Google enterprise manager, UK and
Ireland. "What Google Apps brings is team productivity."

…If you’re wondering how they’re going to make money from all this:

CapGemini will collect the £25 ($50) licence fee charged by Google for its applications, which launched in February.

It
will make further revenues from helping clients use the new
applications, providing helpdesk services and maintenance. It will also
provide help with corporate security, especially for applications such
as email, as well as storage and back-up services.

CapGemini
expects customers to mix and match products, providing some users with
expensive Microsoft tools and others with cheaper and lower-spec Google
Apps.

You can check out the differences between the free and for-pay versions here.

Besides being a very good idea from an SaaS "managed services" perspective, it shows that Google (and global outsourcers) see a target market waiting to unfold in the corporate enterprise space based upon the collaboration sale.

What’s really interesting from a risk management perspective, continuing to ride the theme of Google’s Global Domination, is that Google’s SaaS play will draw focus on the application of security as regulatory compliance issues continue to bite at the heels of productivity gains offered by the utility of centrally hosted collaboration-focused toolsets such as GoogleApps.

Interestingly, Nick Carr points out that GoogleApps’ "outsourced" application hosting capability hasn’t caught on with the large corporate enterprise set largely due to "enterprise readiness," security and compliance concerns, a suggestion that Steve Jones, a Capgemini outsourcing executive who oversees the firm’s work with software-as-a-service applications, maintains is not an issue:

"[Carr] asked Jones about the commonly heard claim that Google Apps, while
fine for little organizations, isn’t "enterprise-ready." He scoffed at
the notion, saying that the objection is just a smokescreen that some
CIOs are "hiding behind." Google Apps, he says, is "already being used
covertly" in big companies, behind the backs of IT staffers. The time
has come, he argues, to bring Apps into the mainstream of IT management
in order to ensure that important data is safeguarded and compliance
requirements are met. Jones foresees "a lot of big companies"
announcing the formal adoption of Apps.

Remember, these applications and their data are hosted on Google’s infrastructure.  Think about the audit, privacy, security and compliance implications of that; folks that utilize ASP services are perhaps used to this, but the question is, what can Google do to suggest it’s hosting model is secure enough, after all, Hoff’s 9th law represents:

Since Google’s app. suite isn’t quite complete yet, Microsoft’s not entirely in danger of seeing it’s $12 Billion office empire crumble, but it’s got to start somewhere…

/Hoff