More and more businesses are migrating internal functions to cloud-based SaaS applications but what assurance do you have over their security - and should you penetration test it yourselves?
Throw a rock in the Internet these days and you’ll hit a SaaS application. They are everywhere and they’re fantastically useful. For all sizes of business they represent a cost-effective way to manage internal business processes, be it traditional stalwarts like Sales, Accountancy or Customer Relationship Management through to more specialised activities such as Business Analytics or Compliance Management.
But with any software comes the risk of security-related bugs, so it is logical - or mandated in some cases - that businesses considering or already using SaaS platforms will want to gain some kind of assurance over the confidentiality, integrity and availability of the data they place in them.
Sadly many SaaS vendors still feel that a “secure” hosting facility and an SSL certificate is sufficient evidence that your data is safe with them.
“A SaaS vendor’s data centre and SSL cert means very little. Ask about processes and testing”
Start to ask about management processes, customer data isolation, their development methodology or their security testing programme and the responses are often less fully formed or, worst case, you get the “that’s confidential and we cannot disclose it” line. I don’t know what’s worse about that response, that they might think it’s a valid reason or that they think you’ll not see straight through it.
Now I don’t expect any third party company to divulge internal and potentially sensitive information but there are ways to ensure their customers (potential or current) can gain enough assurance over their approach without compromising their own security but that’s a blog post for another day, instead I want to focus on security testing.
The basic case for performing penetration testing of a SaaS application is the same as any other kind of security assurance work. There may (or may not) be controls in place to defend against different types of threats but, as with any software implementation, bugs can exist and controls might not work as expected. This is why we test it, to understand if flaws exist and how that affects its security.
It’s not yours
However, it’s a third party application which changes three distinct elements in terms of security testing.
Responsibility
Firstly, it’s not your app. What if the penetration testing company finds some issues? You can’t fix them anyway, you don’t have the code or access to deploy the fix. All you can do is report it to the SaaS vendor and manage their responses until you can get a fix. I’ll come back to this.
Authorisation
Authorisation to test has to come from the SaaS vendor, it’s their app and potentially their data at risk too. It is also highly likely they are hosting their app on someone else’s cloud infrastructure, such as Amazon Web Services or Rackspace, who will also need to be part of the authorisation chain. To test without authorisation could put the penetration testing vendor at risk of prosecution and no reputable company would do this.
Other customers
The platform is almost certainly being shared by other customers, after all, it’s this leveraging of cloud computing that makes it cost effective to offer the service in the first place. If one customer commissions a penetration test (and let’s assume it’s authorised by the SaaS vendor) against the platform it is potentially putting the data of other customers at risk. Is this covered in their terms and agreements? What assurances do other customers have that any data exposed through a penetration test will be dealt with safely?
The case against testing it yourself
Shouldn’t the SaaS vendor be penetration testing their own app? Well yes, absolutely, in our opinion they should and before you consider commissioning a test yourself we recommend you discuss this with the vendor. A good SaaS vendor may be able to supply redacted reports. We are going to cover what to look for in one of these reports in a separate post but you should be able to get a good feel for the vendor’s security approach just by reading one or two of these.
If the vendor has never commissioned a penetration test themselves, ask them why not. Perhaps they have other assurance processes in place, such as a bug bounty. Ultimately though, we thoroughly recommend detailed discussion with the SaaS vendor first to understand their current security assurance activity.
The case for testing it yourself
At the end of the day it is your risk and your company needs to go through a level of due diligence they are happy with before they store data with a third party. Moving vendors is a time-consuming and costly exercise so it’s preferable not to do it too often.
Even if your vendor is testing it themselves, the two don’t have to be mutually exclusive.
If your SaaS vendor can supply you the output from recent penetration testing engagements, this might satisfy your requirement but you may have a penetration testing company you trust and use regularly (/waves) who can provide independent assurance on top of this. After all, security testing third party applications is hardly new.
Consider the infrastructure side of the penetration testing house and what do most tests comprise? Security testing third party applications. It might be Microsoft’s Active Directory or Apache Tomcat or SAP but it’s still a third party app and if the bug was not previously known then our clients are reliant on a vendor to fix it.
Ok, the number of vulnerabilities identified during the average penetration test that relate to a previously undisclosed vulnerability in a third party commercial product is relatively small but it’s essentially the same issue.
Depending on the SaaS platform itself, there may also be configuration improvements your organisation can make. For example, many platforms are now offering two-factor authentication. The vendor is not going to pick this up in a penetration test but we would. If there are security features available that are not enabled, it is certainly something we’d recommend evaluating.
It’s up to you
Ultimately the responsibility for choosing a secure third party vendor falls to your organisation. If you are going to entrust company or personal data to this vendor you will need to ensure you have taken adequate steps to ensure the security of that data. Security testing forms just one part of that overall assurance piece but can be a very valuable one. Any vendor who takes security seriously will be willing to have an open dialogue with you about their approach and it is then up to you to decide if you would like to put it to the test.
At 4ARMED we regularly test SaaS platforms on behalf of both SaaS vendors and their customers. We also perform cost-effective vendor due diligence reviews that can help your management make informed decisions about third party risk. If any of these services may be useful to your business, get in touch with us today.
