Software-as-a-service vendors carry the responsibility of taking care of their customers’ data. They must protect it from corruption, loss, and theft. From architecture to operations, it takes careful planning to build a good, scalable SaaS offering. Yesterday, at an RSA panel, Veracode CTO Chris Wysopal brought up a related issue I hadn’t previously considered: the discovery & disclosure of SaaS vulnerabilities.
Most software vendors perform some type of security audit and vulnerability analysis using a combination of code reviews, static and dynamic analysis tools, automated and manual penetration tests, etc. Vulnerabilities are prioritized as a function of impact of exploit, likelihood of exploitability and other factors such as cost of fix. High priority vulnerabilities are fixed. Lower priority vulnerabilities are deferred. There are two problems with this approach. First, there is the issue of undiscovered vulnerabilities in the software. Then, there is the issue of the known vulnerabilities that the software ships with.
That’s where the independents come in: security outfits, aficionados, hackers, organized criminals, etc. If the bad guys get to a vulnerability first, it’s bad news. If the good guys get to it first, they’d usually notify the vendor so that the software can be patched. Both groups are attacking the software to break it. It’s a race.
How does the situation change with SaaS?
It’s best to start with an email example. Take Microsoft Exchange vs. gmail. If you’re looking for vulnerabilities in Exchange, you’d get a server and mess with it. Given enough time you can even reverse-engineer key components and look for vulnerabilities that can lead to exploits. Since gmail is hosted, you couldn’t get access to the code. Some type of penetration testing the is the only approach to discovering vulnerabilities in gmail.
So, on the surface, SaaS seems more secure in the sense that the bad guys have a limited attack toolset. There is an additional dimension, however. When you launch an attack against gmail, Google can, in theory, know about it. If you’re a legit security outfit in the Valley, how long do you think it’ll take Google to figure out that it was you who was scanning their servers or creating fake HTTP requests and bock you? On the other hand, if you’re some Russian criminals using zombies you may be able to attack gmail for months from different locations. In other words, in a SaaS world, the bad guys have an advantage in discovering new vulnerabilities (unless the good guys switch to using bad guy tactics, which carries risks for them).
It seems that in addition to taking care of their customers’ data, SaaS vendors have the added responsibility of engaging the good guys and allowing them to do their job of vulnerability discovery. Otherwise, the bad guys will always be a step ahead.
HighContrast 
Pingback: SaaS Brings Increased Responsibilities : Lance Tracey
Simeon — Thanks for bringing up an extremely important topic for SaaS vendors. As the CEO of LucidEra (a company providing a complete Business Intelligence On Demand solution), a lot of my waking hours are spent ensuring that out customers’ data is safe and secure. There are two important points I’d like to add:
1) At a minimum, every SaaS vendor should engage the “good guys” by hiring a team of “good guy” hackers to perform penetration testing. There are several firms (sometimes called “white hat hacker” firms) that for a fee they will attack your system and give you an audit report of the results. At LucidEra, we have hired firms like this and set up a clone of our production environment for them to attack (with dummy data, so no real customer data will be compromised), and then we make the audit report available.
2) There is a trend with traditional software vendors to take their software and host it so they can take part in the trend towards on-demand software. The problem is that their software was designed to have the kind of security that’s appropriate for software that is going to be installed in a customer’s data center, behind the customer’s firewall. But, the security requirements for software delivered as a service to thousands of separate customers simultaneously are very different and much more stringent. Trying to retrofit on-premise software to make it secure in an on-demand world is very complicated and risky. That’s why at LucidEra we built a brand new Business Intelligence platform from the ground up, and the security requirements that are unique to the SaaS world are core to the design.
Ken, valid points. Totally agree with (2). Re: (1), it’s necessary but not sufficient. Manual pen testing doesn’t have sufficient coverage to ensure solid vulnerability analysis.
Pingback: Amazon Web Services Outage: Causes And Remedies « HighContrast