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.
Sign up for CIO Asia eNewsletters.