Many of the worst security problems arise when formerly good assumptions change. Robin Roberts summed it up this way - "security systems are built up on assumptions, but you cannot after the fact go back and query the system about the assumptions that were made when it was built."
Tal Klein and colleagues came across an interesting piece of malware which amounts to - when SaaS met Zeus. Banks, of course, are used to coping with malware like this. They have won and lost many battles, but they're actively engaged and ratchet down controls on a daily basis. However, SaaS apps that we increasingly rely on, were never designed for anything remotely like Zeus and other advanced, targeted malware.
Its not just a design problem, its a use case problem. Banking use cases are pretty straightforward, you do your banking and then go on about your day and back to work. But SaaS is increasingly, your work. Its open all day, sales people live their whole workday in their CRM, developers live in Github. Bank apps are - closed, open and use, and close again lifecycle. SaaS apps are come in in the morning, fire up SaaS apps, leave open all day and then (maybe) close when you leave. There is a lot of attack surface there.
What's the risk? Hard to say. The example in Tal Klein's post is harvesting contacts, that does not sound as bad as draining bank accounts, but the part that's worrisome is what else is potentially available.
Where does this go next? Its hard to imagine how SaaS vendors can deliver a bank level of security, and harder still to imagine their customers accepting it. The more compelling piece here is the implied weakness in the shared responsiblity model. As Tal Klein says " this isn't a Salesforce vulnerability", there is only so much that a SaaS vendor can do, so even if their controls are upgraded, their customer's security posture is the key determining factor in warding off this attack. Which leads to the heart of the matter, most customers look to SaaS as a way to offload responsibility, but they also need to remember their own systems can be the target.
SaaS security review projects compare SaaS vendors' capabilities using CSA or homegrown checklists, the focus is on the vendor, but what about the consumer's own resiliency to CSRF, Forced browsing and other attacks that use that preestablished mutual trust? Cloud security assessment are not a one way street, both the consumer and the provider's posture and their combined behavior must be factored in.
Trusting trust is not a new problem.There is a difference being trusting and trustworthiness. SaaS assessments look at the trustworthiness of the SaaS vendor mostly in isolation, but the question to ask is whether the end to end system is trustworthy? And practically speaking what can cloud consumers do harden their systems.
Comments