Make them measurably more secure. If a would-be Cloud/Software-as-a-Service (SaaS) customer is concerned about security, and they should be since their business is on the line, then security should be the vendors concern as well. Unless the Cloud/SaaS vendor is able to meet a customer’s minimum requirements, they risk losing the business to a competitor who can.
This market dynamic encourages the proper alignment of business interests and establishes a truly reasonable minimum security bar. The other significant benefit of Cloud/SaaS business model is that multi-tenant systems are at least as secure as the most demanding customer. Security investments meant to satisfy one customer directly benefits the rest.
Compliance on the other hand is designed to compensate for times when normal market forces fail to provide an adequate alignment of interests. For example, organizations that are in a position to protect data are not responsible for the losses. The payment card industry found itself in one of those situations when it came to cardholder information.
Unfortunately compliance, specifically PCI-DSS, in practice is implemented in a much different way than the aforementioned market forces. Apparently a checklist approach is most common where strategic planning is generally not an incentive. The result of which is performing a bunch of “best-practices” that may or may not affect a better outcome because “security” is not the primary goal. Satisfying audit requirements is.
The interesting thing about SaaS is the last word, “service.” Customers are buying a service and not a product with a lopsided, zero liability end-user licensing agreement (EULA). Customers may demand vendors provide assurances by passing third-party vulnerability assessments, encrypting their data, onsite visits, or taking on contractual liability in the event of a breach or service degradation, etc. This all before signing on the dotted line. This requires vendors implement safeguards customers may not be able to do for themselves without incurring significant expense. These are serious considerations to be made before outsourcing sales force automation, enterprise resource planning, email hosting, and so on.
Sure there are Cloud/SaaS vendors with equally customer-unfriendly EULA and no SLAs or security guarantees to speak of, but I am confident this only opens the door for healthy competition. Customers WANT security, the question is are they willing to pay a premium for it. If so, Cloud/SaaS vendors who view security as a strategic way to differentiate could find themselves as the new market leaders. I believe this form of competition is doing a lot more to improve website security than how PCI is typically applied. At least, so far this has been my experience.
6 comments:
IMHO application security will only become a compettitive advantage when there is some way of comparing the security of cloud providers. Strict criteria needs to be established in order to compare providers and retained centrally so that a google search for provider + security + incident is not the only way of comparison.
Actually, in some ways I'd suggest that the opposite is true. SaaS has the potential to make a application security worse not better.
First off a couple of comments on your points. I'd agree that customers will mention that they want "security" from their SaaS providers, but in my experience they rarely know specifically what they want and it could well pass as
Customer : "are you secure"
SaaS vendor : "of course we are we use 'military grade' encryption"
Customer : " great, now back to this cheap service you're telling me about"
What's needed to help this is an accepted definition of what a secure web service looks like and for that to get integrated into the contract, but I'd guess that the SaaS vendors won't be hugely in favour of that, as it would impose costs onto them.
One reason I think SaaS could actually reduce security is accessibility to testing. Where a customer has control of their environment they can allow appropriate security testing/code review. Where they're using SaaS, they almost definitely can't insist on code review, and in many cases I've seen their contract won't allow for them to request a pen. test of the live site.
The best they can hope for is sight of the SaaS vendors report from their testing (if they ask) and even then my experience is that many third party service providers don't like handing those out
Of course, all this depends on how large a customer you are of course, or how good your contract is, but for small companies who don't have good expertise in web app. security the likelihood is that they'll just accept what the vendor offers in the way of security assurances and leave it at that, which leaves little incentive for the vendor to improve security beyond the bare minimum of buzzword compliance...
You clearly missed the "cloud" where you only focus on SaaS in the cloud.
Consider PaaS and IaaS when making "informed" security presentations such as what you have blogged.
Possibly, you haven't heard of PaaS or IaaS, or did you just neglect the most two difficult security implementations to protect in the cloud?
@Matthew, thanks for the comment. Im not confident a "Strict criteria" for rating and comparing security through providers will happen, nor will it need to. Customers, at least some, will have their own criteria for testing and security assurance that they'll pay for out of pocket. It is my believe that these efforts will directly lead to increased security, moreso than PCI-DSS.
@Roy, sure... we can say most may not have a clue when it comes to security and will play out just as you said -- however there will be other customers on the system who do (have a clue) and will test the systm for themselves. If the SaaS vendors denies a request, they risk losing the business.
Secondly, even if testing and control is limited in some way, the effects of this can be tempered by contractual terms (liability and SLA). While not all customers will get the same terms, the bigger and more important ones will. So when the vendors takes these liabilities into consideration of their overall risk models, the benefits will indirectly filter down to the rest of their clients.
In a multi-tenancy system, your right the system only has to be as secure as the most demanding customer -- but, that might be good enough and better than what PCI-DSS would provide.
@Anony, possibly I should have a said outsourced and you wouldn't be so focused on semantics.
@jeremiah. You're right in that larger customers will be in a position to force good requirements for security into their contract clauses (although requires good engagement between infosec and purchasing which historically may not be good in organisations who are new to this kind of problem)
Although when you mention multi-tenancy systems (which a lot of SaaS implementations are), it reminds me of another problem I've encountered several times with testing SaaS.
The provider has on many occaisions refused the right to test based on the risk of disclosure of other tenants data and the fact they have no contract with the testing company.
Which in a way makes a lot of sense. Say Tenant A hires a group of testers and doesn't do good due diligence on their security/ethical requirements.
They test a SaaS vendor with a multi-tenancy implementation in live, get access to customer data through an authZ flaw (one of the more commmon issues in my experience) and then download the database from the system, including the data of other customers.
the SaaS vendor is then in a tricky position, as they have no contract with the testers requiring confidentiality.
Now in an ideal world they wouldn't have had the flaw in the first place, but then hey, if everyone was good at Web App Sec. there wouldn't be so many jobs for testers!
Im just listening,thanks
Post a Comment