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.
Like this:
Like Loading...
