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.
Comments