GEEKONOMICS

ebizQ Interview: Is SaaS Going to Cost Us?

The following is an interview with Krissi Danielsson, Producer at ebizQ regarding the security of Sofware as a Service (SaaS). ebizQ Interview: Is SaaS Going to Cost Us?

What's your take on the commonly cited security concern of companies that fear SaaS due to having their data hosted outside their four walls?

Companies are rightly concerned for a number of reasons. The irony of SaaS is this: companies are moving to SaaS in large part because of the expense of securing, managing, and maintaining low-quality, dysfunctional, insecure software. But while the financial model has changed under SaaS, the security and quality concerns of “bad” software have not. In fact, security and quality concerns will most likely intensify.

First, the software engineering techniques used for single-instance software (like SaaS) are the same techniques used for multi-instance software (like word processors or operating systems). The engineering model has not changed. More importantly, neither have the market incentives for software manufacturers. Without proper incentives for making better software, software manufacturers simply will not. This means software manufactured under a SaaS model most likely is not any better than previous models. This has consequences.

Features sell. Period. Under the SaaS model, software manufacturers add features incrementally and on-demand to satisfy client requests as well as remain competitive. This sounds like a good thing to both buyers and manufacturers. It is not, at least not under the current market circumstances.

The market incentive for software manufacturers is to add as many features as possible because features are part of the beauty contest among software applications. Security is not. This means SaaS applications are guaranteed to have a continuous and relentless stream of ad-hoc features (over an above the rate at which features are added to their multi-instance cousins) each of which add more complexity to the application and the likelihood that one or more of those features contains a bug (at best) or a vulnerability (at worst).

Features then, are the distinguishing element among software manufacturers, SaaS or otherwise. So low-quality, feature-rich software tends to dominate, driving higher-quality, secure software from the market. There is really no such thing as a “final release” in SaaS, making SaaS a particularly dangerous form of software. Features, and therefore potential vulnerabilities, tend to dominate. As such, buyers will never be free from acting as crash test dummies for the manufacturer (and paying handsomely for the privilege).

Second, SaaS represents a single-point-of-attack for malicious entities such as cyber criminals and those engaged in cyber-espionage. All that juicy data aggregated into a single location accessible from anywhere in the world, is simply too great a temptation and too great an incentive for attackers. While the SaaS model mitigates cyber attackers to some extent by maintaining the application’s code base outside the immediate control of attackers, web applications are notoriously improperly engineered to begin with. Given the number of potential features, the number of potential user roles, and the number of people who may have access to the application, attackers have a broad area to attack; an area that has historically proven extremely lucrative. Feature-rich SaaS applications exacerbate this problem.

Finally, the issue of separate security domains works both for and against SaaS subscribers. Separate security domains for each SaaS subscriber are intended to keep each subscriber’s data separate. This is good because a compromise of a single subscriber’s domain does not lead (hopefully) to a complete compromise of all subscribers’ data. However, this security model also makes the security of the entire SaaS application opaque to any single subscriber. In other words, due to contractual restrictions, a single subscriber is not permitted to evaluate the security of the entire application because of the risk it imposes on all other subscribers. This means the software manufacturer can make any assertion about security they want (recall Oracle’s “unbreakable” campaign) with little, if any accountability should the manufacturer be mistaken. Under the separate security domains model, subscribers must take SaaS providers at their word regarding security. Even if a third party security vendor is used to evaluate the SaaS application, the report itself is usually highly sanitized (and highly subjective) and of questionable value to the subscriber in making a purchasing decision.

At bottom, data is protected by software. Without high-quality, secure software how safe do you think your data really is?

Do you think that SAS 70 II certification is adequate right now for ensuring the security of SaaS applications?

It depends. SAS like PCI DSS is managing a particular form of risk, but not managing the issue at hand. Low-quality, insecure software communicates a message of disorder into cyberspace. According the Theory of Broken Windows put forward by two criminologists Kelling and Wilson, small elements of disorder invite greater elements of disorder, which ultimately lead to more serious forms of crime.

Weaknesses in software are the broken windows of cyberspace. Small elements of disorder (software bugs), lead to greater elements of disorder (exploitation of vulnerabilities), which ultimately lead to more serious forms of crime (like cyber crime and cyber espionage).

Historically, software manufacturers have not been liable for these broken windows even though software applications have been, and are continually shipped with an unknown number of latent defects and vulnerabilities. SaaS is no different.

Software manufacturers share little, if any burden, when software leads to exploitation because of highly insular contract agreements. The fact that software manufacturers have designed highly configurable software merely complicates the problem. Not only must software buyers contend with patching insecure software, but must contend with a multitude of configuration options and the financial and legal consequences should they get any of it wrong. SAS and PCI DSS are simply manifestations of the dysfunction that plagues the information security industry. Expecting hundreds of millions of software buyers (of which SaaS providers are among) to frenetically patch and tirelessly configure their computer systems is barking madness. Software buyers are not the least cost avoiders when it comes to security; it is software manufacturers.

That said, compliance regimes have their place. Software buyers obviously share some culpability when it comes to protecting their systems. But companies end up managing the risk of non-compliance instead of the risk imposed by bad software which does not alter the nature of the problem in any meaningful way. In other words, software buyers are too busy mopping the floor (of audit requirements) to turn off the faucet (of bad software).

It surprises me that so many organizations, companies, and industries will willingly bear the considerable financial and legal burden of low-quality, insecure software, but largely refuse to hold manufacturers of such software to account.

So does SAS help SaaS? If non-compliance is our fundamental risk, then yes.

With the recent concerns being discussed about how phishing could pose a security risk to companies using SaaS applications, do you think companies should be concerned by this and what do you think companies can do to protect themselves?

Everyone must be concerned with phishing. The whole point of phishing is two fold:

• trick unsuspecting users into divulging sensitive information unknowingly to what appears to be a valid website, or…
• trick unsuspecting users to visit what appears to be a valid website, but is in fact, a website containing malware that exploits weaknesses in their desktop computer systems. This malware then turns the victim’s computer into a “bot” which siphons off the user’s sensitive and personal information without their knowledge.
  Both are troubling. One more than the other.

In the first instance, a large SaaS provider, like Salesforce.com, could simply have one or more of its employees tricked into giving out sensitive information, such as a password. This compromised password in turn might give access to sensitive information protected by the SaaS application.

In the second instance, an employee of a SaaS provider could have her machine infected with malware by mistakenly responding to what appears like a valid customer request. If this malware is professional grade (meaning that anti-virus will not have signatures to detect it), the compromised machine now gives the attacker access to everything the employee has access to, including all information the flows out of or into that machine. Until anti-virus vendors are made aware of the malware and can develop a signature, the malware itself could remain resident on the employee’s machine for months siphoning off information the entire time.

The second instance is most troubling of the two since the SaaS employees must communicate with customers – and potential customers – in the course of their everyday duties. This makes SaaS employees prime (and easily discovered) targets for cyber attackers. SaaS employees are also guaranteed to have some level of access to more sensitive areas of the SaaS application itself, or the network the SaaS application resides on. Compromising just one of these machines with professional grade malware is a lucrative proposition.

Phishing certainly takes advantage of unsuspecting users, but really phishing is about exploiting vulnerabilities in software itself. Botnets, which are large collections of bots (hijacked computers) that can number 100,000 or more, are all created by exploiting vulnerabilities in software. The largest botnet to date is something over 3 million computers. If combating phishing were just a user awareness issue, we might have a chance. Warning somebody about the dangers of walking down a dark alley is pretty simple. Likewise, warning somebody about the dangers of giving out personal or sensitive information (like a password) is also pretty straight forward. But when a user is tricked into visiting a website that looks for all intents and purposes to be valid, or is in fact valid, but has been infected by an attacker with malware (as was the case with the Circuit City customer service website), user awareness only takes us so far. It helps. But it doesn’t help with the problem of insecure software which is how phishing ultimately gains a foothold in our computer systems.

Short of extensive user awareness programs and fixing bad software, one possible response to the problem of phishing is to create private email systems where user email addresses cannot be harvested (and therefore not targeted) by outside entities. Without access to the private email system, an attacker, even if she can harvest the private email, cannot communicate with other private email users. This provides a trusted conduit for both companies and consumers.

Geekonomics Nominated for a 2007 Jolt Award

Geekonomics has been nominated as a finalist for a Jolt Award for 2007. The Jolt Excellence Awards are the Oscar of the software industry and "recognize the most innovative, trend-making, ahead-of-the-curve products. Jolt-award winners are the software products, books and websites that developers should be using today."

To quote the Jolt Awards website directly:

Our prestigious Jolt Judges are recognized as forward-looking gurus, who provide insight into the latest and most promising industry trends. They define who is ahead of the curve, honoring products that are universally useful; that are simple, yet rich in functionality; that redefine their product space; or solve a nagging problem that has consistently eluded other products and books. Our judges and their decisions is one of the major reasons the Jolts are so coveted.

I'm honored by the nomination and very happy that Geekonomics is included among the finalists. Thank you to everyone who took the time in the nomination process.

Book Review: Stephen Few

Stephen Few wrote a wonderful review of Geekonomics on his blog Visual Business Intelligence:

Geekonomics - Don't let the cute title fool you; this is serious stuff

An excerpt from Stephen's blog reads as follows:

Every once in a while I encounter someone’s work whose sanity of argument, integrity of passion, and elegance of expression convinces me in an instant that I have found a comrade. Recently reading the new book Geekonomics by David Rice was such an encounter.

Rice is a prophet, and like most true prophets, what he is saying is something you won’t like hearing. Geekonomics warns against the dangers of software. That’s right—software—which we rely upon every day to a rapidly increasing degree. Rice is no crackpot or self-proclaimed guru looking to make a quick buck with this book. His warnings are akin to those of Alan Cooper in The Inmates are Running the Asylum and my own as well. While Cooper and I rail against software’s inexcusable dysfunctionality, however, Rice points out very real dangers that threaten the world. Most software is bad, not just because it is much harder to use and far less effective than it ought to be; it is also insecure, which invites danger. The more we rely on software, the more vulnerable we are to the whims of those who would do harm.

...

Geekonomics is not only an important book, it is also a good book. Rice is smart and thoughtful, and he knows how to write. If you rely on software (and who doesn’t?), you should read this book. If you produce software, you should read this book. You might not like what you read, but you need to hear it, and we all need to do something about it.

Thank you for your gracious review Stephen. Comrades, we are indeed.

Naughty or nice? How secure is such a database?

A good friend of mine, James Tarala, passed along this humorous story regarding the security of Santa's database from The Register (the comments are almost as funny as the article). You gotta love data protection laws...

Santa putting children's information at risk, warn experts.

Now, the real question: Is Santa, living at the North Pole, judgment proof?

Where did my $180B go?!? Cost is not always measured in dollars.

There was a critical analysis over at Spire Security Viewpoint regarding the $180B number cited as the cost of insecure software in a Dark Reading article as well as within Geekonomics. But cost is not always measured in dollars. This will be a recurring and unaviodable discussion. Here is my response in its entirety.

Great post. You’ve hit upon what I anticipated to be the most frustrating part of writing (and reading) Geekonomics and something I've been clear about both in the Dark Reading article as well as in other venues: the numbers about the real cost of insecure software are soft. As such, I spend little effort defending this number.

It is an area I knew, deep down, that would be most controversial and most distracting aspect of the book. Unfortunately so. As I state in Geekonomics, “The real cost of something is not always measured in money. The real cost of something is what you have to give up in order to get it.”

Insecure software communicates an unmistakable message of disorder into cyber space: no one is in control of software. Not manufacturers. Not consumers. And certainly not governments. Lack of order imposes a cost. So the real cost is not a dollar amount; it is in the threat to national and economic security. Vulnerabilities in software are being exploited, and rampantly so. To focus primarily on the dollar amount, is helpful, but misses the point. That said, I put the number out knowing the possibility for distraction and you are being more than reasonable to challenge the number’s accuracy.

Somewhere in the muddle of hype and deflation are the “real” numbers. From my conversations with journalists and industry experts, the cost of insecure software is somewhere above $100 billion (US only); this much we know (or at least this number was felt to be “about right.”). So $180 billion is not unreasonable, but it is a reach to state this number, or any number on the subject, with any level of confidence. Talking about, and getting reliable numbers on insecure software is like talking about sexually transmitted diseases: we can see the effects but very few actually admit to, or are even aware of, their contribution to the problem. Similar to the stigma associated with sexually transmitted diseases, there is also a bevy of circumstances in the software market that cloud both the collection and reporting of numbers. This is a shame. And the reality. The greater upset perhaps is not so much that $180B may be soft, but that we have no idea by how much.

But there is a glimmer of hope that only appeared after Geekonomics went to print. The Department of Justice received a report from RAND Corporation last year from an in-depth study on cyber crime across 8,000 companies. This report is not public, but should be made public by DOJ early in 2008. This is good news. RAND promised that the participating companies would get sanitized data about their individual industries outside of what was in the public report (which was the incentive RAND used to promote participation in the first place). This potentially means that anonymity, and the subsequent freedom from stigmatization, might indeed provide more reliable numbers, if only from a limited subset. But given that a 2003/2004 CIO report (just prior to the time period of collection for the RAND data) showed that only 12 percent of surveyed companies (approx. 5,000) had a reliable way of quantifying their losses due to exploitation, hope might need plenty of salt.

Your analysis is a welcome addition to the discussion. Thanks so much.

Operating Systems aren't any more secure than the idiots using them (Part 2)

I've added this "Part 2" section as another follow-up to the discussion over at tssci-security.com. Roger responded to a number of points. This post is response to some of the comments Roger provided. Overall, a great discussion. There's more from Roger after my post. This was a loooooong discussion, but again, what discussion about software security isn't?!?

Roger, you and I are certainly of the same mindset on some of these topics. I want to address some of the items you wrote about above, but I confess, it will not be complete.

Roger said, “If I look at some of the proposed measures, from your point of view you can just achieve adequate security if the code is available – which most Open Source applications prove to be wrong.”

I agree. The “openness” of software has not proven itself to offer greater security. This does not mean I am against open source, simply that the numbers have not entirely supported the assertion that open-source is better than closed-source. Openness *can* help, but it is no guarantee. Have some open source companies exhibited the ability to address security better than other software manufacturers? Yes. Absolutely. But this is a company issue, not an open/close-source issue. There are hundreds of open source projects that have simply not responded adequately to consumer’s security needs. The desire, ability, and capability to address security needs are largely an economic issue that is company-specific; that is, do open source projects/companies have the resources and the incentives to adequately address security? The answer is not nearly as clear as open/closed-source evangelists would like us to believe.

Roger said as a response to my comments regarding “the nuts behind the keyboard,” “Well, this is a more than unfair accusation. Part of the reason why this blog comments are here is just me saying that this is unfair and I do not like it.”

Amen. The notion that users are “idiots” is prevalent within the IT industry in general and the IT security industry in particular. For instance, there are many terms used to refer to users. “ID10T”. Also, PEBCAK, Problem Exists Between Chair and Keyboard. And, of course, PICNIC, Problem in Chair, Not In Computer. And finally, UCOM, User Can’t Operate Machine.

But the notion extends beyond just the IT industry. In a recent article I believe in CSO magazine, bank executives were stating, anonymously of course, that “users are dumb” in regards to how and to what extent (i.e., not at all) users protect their computers from exploitation. This is an increasingly pervasive sentiment and a troubling one.

But the fact that user’s turn off firewalls is another red-herring. Why do they need firewalls in the first place? Largely because of insecure design and implementation of whatever the firewall is trying to protect. In general, firewalls as well as a majority of other similar security protections are a network response to a software engineering problem. These security protections do nothing to solve the problem why software is, and why it largely remains, vulnerable.

Roger also responded to my question about the security of a system relying on the intellectual strength of users, “Because the consumer has a gazillion of not controllable option to mis-configure the Browser, the applications and the OS as everything is multi-purpose. This is the big, big difference between a car and software – and it is product agnostic.”

This is where we disagree. To answer, let me do some set up. First, is software more complex than a vehicle? Yes. Undoubtedly. Second, based on this complexity, will users need to be better informed and educated to “drive” safely on the Internet? Sure, but the question that remains is just how much more must users learn to “drive” safely on the Internet?

The current answer, I believe, is: users must have an exceptional, even an extraordinary level of knowledge in order to protect themselves. They are in fact expected to think and act like the engineers who designed these systems. This is unrealistic. So, which of the following is least implausible? Expecting people in developing nations who, based on statistics are largely disadvantaged educationally, or, as Roger said, living in slums, must now become the equivalent of first-world security experts in order to protect their computers (which first-world computer users cannot seem to do either by the way)…OR…imposing some level of educational requirement (the equivalent of a cyber-driver’s license) to “drive” the global network no matter where you live? I certainly don’t have an answer.

The “let’s not hurt the already-disadvantaged” sentiment is laudable and I share Roger’s concern for the problems of developing nations. This is a hard problem.

That said, a product that is so complex that neither the manufacturer nor the consumer can apparently protect it sufficiently is troubling. To imply that “hey, that’s just the way we designed the OS (as multi-purpose) and the market has to live with that,” is unacceptable. It is also largely unprecedented (or has been corrected where there might be precedent). As a public policy issue it is down right dangerous.

When there are services/products that are beneficial to humanity, but pose substantial risk to society, such as zoos (risk: wild animals escaping their enclosures), nuclear reactors (risk: melt downs, transporting HAZMAT), and even toasters (risk: electrocution), the maker/provider has eventually become subject to strict product liability. That is, yes, these things are beneficial to society (as an operating system undoubtedly is) but the risk is so great should something go wrong that the individuals who choose to engage in making/producing this product must be held accountable for any foreseeable and unforeseeable circumstances. In the case were users are also culpable as well as the manufacturer, the user is liable under contributory negligence. Everyone shares the burden comisserate with their responsibility.

This is a public policy issue, and an important one. Presumably, a multi-purpose OS would run on just about anything; making the radius of risk should the OS have a defect/vulnerability quite extensive.

Strict product liability encourages manufacturers to build systems that are better focused for intent, better engineered for use, and better designed for safety/security. Users also share the burden under contributory negligence. This is not the current state in the software market. Users bear the entire burden should anything go wrong with their computer system, manufacturing defect or not.

So the biggest question of all is, is software so special that it should not abide by, or adhere to, good public policy?

I like Roger’s thoughts on getting together for a chat. Roger is a wonderful thinker and I welcome the opportunity.

Operating systems aren’t any more secure than the idiot using it (Part 1)

Marcin Wielgoszewski lead a great dicsussion about operating system security being overly dependent on user skill. Here is my post in its entirely:

Awesome discussion on an unfortunate topic. Marcin, great job. I'd like to add a few comments that may be redundant, but nonetheless valuable (hopefully) from what I covered in Geekonomics (http://www.geekonomicsbook.com).

There may certainly be idiot drivers, but on the whole the car’s safety rating is agnostic; that is, the car is “safe” no matter who the driver might be. Whether the driver drives *safely* is another matter entirely.

In the software market however, the security (analogous to safety in vehicles) of the operating system largely depends on the user; that is, is the system configured correctly to protect the software itself from exploitation. This is far too brittle a model; it doesn’t scale reliability, and how in the world are 500 million users supposed to get all their configurations correct? Configuration, in large part, is a red herring that distracts from the issue.

So to say that an “operating system is only as secure as the idiots using it” is not only accurate it touches on something that is wildly unfair.

Drivers do not need to configure their vehicle’s crumple zones, side impact bars, or seat belts (besides adjusting) to receive protection. These are safety feature IN ADDITION TO good and safe design of the vehicle, not REPLACEMENTS FOR the lack of good and safe design. Compare this with your typical computer system. The user must configure almost everything (ACLs, firewalls, etc) including the roadway (the router) not, as with vehicles, in addition to good and secure design of the operating system, but largely as a replacement for the lack of good and secure design. This isn’t fair. As a matter of public policy, it is unjust.

In 1950s and 1960s America, the car companies could freely, and without danger of appearing hypocritical, point to drivers and say, “see, it’s the nut behind the wheel that is causing all these roadway fatalities. It’s not us.” When in fact, it was to a large degree a manufacturing issue. Sure, drivers had SOME culpability for roadway fatalities, but not ALL culpability as the manufacturers made it appear.

In today’s software market, the same situation exists as it did in 1950s and 1960s America. Software consumers are “the nuts behind the keyboard,” the “idiots” as they are deemed. It is software consumers that are blamed extensively for not configuring their “vehicle” correctly. But this doesn’t make sense. Why in the world should we blame users for manufacturing defects that could not possibly be their fault? Why should the security of an operating system depend on the intellectual strength of the user when the safety rating of a car is agnostic to whoever the driver might be? According to my elderly mother, plenty of idiots are on the road today, but you’ll note that the U.S. has held steady the number of roadway fatalities at roughly 40,000 per year despite over an 80% increase in traffic since the 1980s. More “idiots” are driving – and driving longer distances – than ever before, but the safety of vehicles remains agnostic to both potential and latent idiocy.

Certainly, if someone drives drunk, they are culpable, but culpability is bounded. What if the wheel falls off their car at highway speeds (or their fuel injection system crashes as it did with GM and Prius vehicles).? Are the users to blame for manufacturing defects? In the software market, culpability is unbounded. Software consumers are blamed for any failure to protect their systems, manufacturing defect or not. Why should software consumers be liable for manufacturing defects in software products? The lack of consumer protection and the imbalance of culpability in the software market are truly astonishing. To expect 500 million+ users to configure their systems correctly in order to receive suitable protection is not only unjust, it is barking madness.

Thanks for the opportunity to post, Marcin. Cheers.

Insecure Developers Must Pay Taxes?!?

This was the title of a post on a Dutch discussion group in response to the idea of a "vulnerability tax" covered in an article on Dark Reading. Wow. This is an example of a statement's meaning becoming "lost in translation." The entire site is in Dutch and I translated the page.

The response on the website was heated, to say the least. And rightly so. My response went something like this which I wrote in English since my Dutch is rather poor (actually, non-existent). I have a feeling that translational issues will remain however.

Hi. I'm David Rice. And no, I wasn't drunk when I wrote about vulnerability taxes, nor was I on XTC. I hope to high heaven that I'm not an idiot either.

Wow. The translation for this did not come out as expected. I can understand why everyone is so upset. "Insecure Developers Must Pay Taxes," is only partly accurate.

The idea behind a "vulnerability tax" is the same idea behind taxing carbon emissions. Manufacturing inevitably creates pollution. The answer is not to stop manufacturing as this makes everyone worse off. So we tax pollution to offset the cost of its damage. This rewards "greener" companies since they pass on less tax to the consumer. Massive carbon emitters must pay higher taxes and therefore their product/service is more expensive. The market is left to determine how much tax (and therefore how much pollution) it is willing to tolerate.

The same idea is applied to software. Creating "perfect software" is not possible. Vulnerabilities are inevitable. But this does not mean we cannot do anything about it. The answer is not to stop using software as this makes everyone worse off. Taxing manufacturers of insecure software rewards those companies that produce less vulnerabilities making their product less expensive since less tax is passed on to the consumer.

The problem with cars is not that they are so expensive. It is that they are not expensive enough to drive. So they fill the atmosphere with carbon. The same problem exists with software. The problem is not that software is so expensive. The problem is that software is not expensive enough. And so it "fills" cyberspace with "pollution." Why complain about Vista costing EUR 1000 when it is extraordinary expensive to protect it from exploitation? All that time and effort, firewalls, anti-virus, intrusion detection systems...that's a lot of cost both in the private cost you pay to try to get it right as well as social costs everyone pays when you get it wrong.

I hope this clears some things up. Thank you for your heated discussion.

So that's the gist of my response. I didn't copy my response before posting so the original words are lost. I'm not even sure the site moderator will post my response since it was in English. One can only hope. If my response does actually get posted, I will replace the above quote.