A checklist for SaaS vendors
My current company has just two in-house applications, which run in a closet-size data center: source code management and a bug tracking system. Even those operations might be moved to a SaaS provider, as has been done for other things that now rely on more than 40 corporate-sanctioned and cloud-based applications. Many of the applications were put into service years before my arrival, and I’m just now getting around to evaluating the security risk of each of them. My top priority is the applications that process the most sensitive data for the company, such as Salesforce and ADP, which manage customer information, sales forecasting, personnel data and payroll.
I recently met with our IT department to discuss vendor management. We agreed that no new corporate applications will be allowed without first identifying risks by assessing the vendor and its service or application. To help with this, I created a spreadsheet for capturing answers to security-related questions. Such standardized information-gathering (SIG) questionnaires are nothing new, of course, so I was able to review SIG and other vendor questionnaires that I found on the Internet and pull out what I felt were the most important security questions and controls. I then applied weighted calculations to them.
For example, if the application processes sensitive data, I placed a higher weight on encryption than I would for an application that does something relatively innocuous like calculate tax or foreign currency conversions. For those tax and currency applications, I deemed items such as “restore point objectives” and “restore time objectives” to be less important and therefore in need of a lower weight than items such as applications that store business-critical data, such as those used by finance and sales, or even sites we use to store corporate documents, such as Google Docs and Box, where data backup and disaster recovery are critical risk factors. The resulting scores will be useful in choosing product and establishing compensating controls. For example, if an application that processes sensitive data isn’t compatible with our single sign-on solution but nonetheless offers the ability to control access in other ways, we might decide to use the application anyway, possibly doing something like restricting access by IP address as a compensating control.
We recently upgraded our PCI compliance, so for any applications or service providers that process credit card data or touch on our PCI compliance in any other way, I have revised requirements. The vendor might have to provide a current attestation of compliance or a contractual statement that it is responsible for the security of our data. These requirements have already come in handy. A content delivery network (CDN) provider we were considering would have been in scope for PCI because it decrypts network traffic and inspects that traffic for application security issues, and our network traffic may contain credit card data. As it turned out, that vendor was not PCI-compliant, and so it was out of the running.
As we start to evaluate the risk of existing applications and services, there is a good chance that some that have been in use for many years will have security issues that are just too difficult to address, and changing vendors might negatively affect our business too much. For these cases, we will evaluate the security controls that are in place and make sure that we are taking advantage of any built-in configuration settings. Many SaaS-based applications may not have all the security bells and whistles contained in my security checklist, but they typically have settings such as password complexity, session timeouts, multifactor authentication and other controls that may serve as a compensating control for weaknesses in other areas.
My checklist is still a work in progress, but it’s a step in the right direction to get a handle on existing and new corporate-sanctioned SaaS applications and services. My goal is to make this checklist easy to use so that even a non-security employee could complete the checklist with minimal assistance. We’ll see how that goes.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.