SaaS: Data Security – Should I be concerned?

By Subraya Mallya - May 2009 | Topics - Compliance, SaaS

One of the key concerns associated with Software-as-a-Service (SaaS) is and will be data security. The fact that your business data goes out of your network and resides in the software vendor’s data center should warrant concern. But with upfront due diligence and ongoing oversight, you should be able to get you past your inhibitions in adopting SaaS applications and benefit from all the agility, costs benefits that come with it.

The first mention of SaaS application, as a possible technology choice, is sure to make your IT and the CFO/Risk officer perky. A single breach and the consequential data loss can cost companies millions of dollars in penalties/damages. This does not include the unquantifiable damage to the company’s reputation. Regulatory mandates like Sarbanes Oxley (SOX)-404, HIPAA and PCI-DSS have strict requirements on how customer, financial, employee, partner data should be governed and protected. Moving to a SaaS application does not preclude you, the company, from those responsibilities.

Given that, how does a company considering a SaaS application conduct a good assessment of the risks involved before jumping in ?

Let us start with the premise.

Companies store data in servers and databases each kept from unauthorized users under strict access control. Additionally, the data itself is regulated by who can see what and what, if any, operations can they perform on the data. The operations could be manual or via an application that manages it.

In SaaS, your data will reside in the databases and servers owned by the service provider. If your SaaS vendor happens to use third party cloud based infrastructure services then your data might reside in the data center of the Cloud Infrastructure provider. As a customer, you get to add, update, delete data from within the SaaS application, subject to the business rules and security policies implemented in the application. Unlike in the case of an on-premise application, your IT organization will not retain access to the servers, databases, storage, backups and the network. That responsibility would now rest with the service provider.

So, then is my data safe?

In order to safeguard your data that would reside in the service provider’s database, here are somethings, you must ask the software vendor as part of the RFP/evaluation process.

  1. Keep the bad guys away: Given that the vendor’s data center is where all your critical data resides, it is imperative that you understand the physical perimeter security they have in place for their data center. Reviewing the process in place to govern who gets access them and how is the trail of access managed is also critical.
  2. Can they come in through the internet?: Knowledge of existence of a particular service and its location is not a secret. Everyone knows how to access Salesforce.com or Netsuite. You go to the vendor’s site and look for the Customer Login or Client Login button/tab. Given that what are some of the processes vendor has in place for preventing Denial of Service Attacks, Spoofing (remember the Salesforce.com incident!).
  3. Authentication/Sign-On: Most SaaS vendors these days support and delegate Sign-On using SAML(Security Assertion Markup Language) or  OAuth standards. This will allow you to configure the entry point to the application/data for your company through a trusted site – like your enterprise portal which is accessed through VPN. With such a configuration you are now essentially shutting off public access to your share of the application and in-charge of  provisioning and revocation of access from your corporate  Single Sign-On identity management.
  4. Encryption Policies: Making data secure in the data center is the first step. Another challenge is to make sure data is safe in-transit. As you access data from the application, data is traveling over the wire back and forth. Having strong encryption of data on the wire is paramount. 128bit SSL encryption is common these days, but some vendors are now starting to provide stronger encryption. Check what your vendor supports. In fact, while you are at it also check what they support for the on-disk encryption so your data in storage and backups are encrypted.
  5. Test the Tester:Verify the quality process being used to conduct security tests. Specifically check for tests conducted to identify vulnerabilities due to Cross-site Scripting, Cross-site Request Forgery, Cookie Management, Mass Update of Access Control, iFrame embedding, URL manipulation, Overzealous Logging.
  6. Multi-tenancy/Data Slicing: Multi-tenancy provides the economies of scale that SaaS vendors seek, to provide low subscription costs. But this also means your data will be co-mingled with other customers in a single database. With all the rapid product development cycles, if the tenancy data separation architecture is not robust, this might expose your data to your competitors or fellow tenants. So it is important to understand the way data separation is implemented.  Have your architects verify the  architecture to understand the multi-tenancy architecture better. Specifically check for the quality tests conducted to prevent SQL Injection. Code flaws that allow SQL Injection would end up allowing access to wrong slice of data.
  7. Audit Trail: Discuss the audit trail functionality in the application. Given that you will be doing a trial of the application prior to making a decision, verify the same. While excessive audit logging could hinder the functioning of the application, you as a customer, should have the ability to enable and disable logging for specific activities/events in the application. Specifically, I would look for audit trail capabilities around – user login/logouts, access control changes, password changes, data export/import features, running reports, access of critical areas like Credit Card information, employee details, SSN etc.
  8. Network Security: Network weakness is one of common ways for malicious users to get access to information. Typical issues found in networks would be improper SSL configuration, lack of robust session management and open ports. Once the hacker gets access, they can hijack active sessions and gain access to user credentials and critical information.
  9. Backup/Recovery: In the quest for 99.99% availability, it is conceivable that vendors build redundancy and replicate data just in case of a crash. This means copies of your data could be residing in multiple data centers, in some case in multiple geographies. So if you are in a regulated industry and comply to data security guidelines that prevent your data being hosted outside the country or a certain geography, you should get that clarified upfront.
  10. Certification: First of, ask for a SAS-70 Type II audit certificate, preferably conducted in the last 6 months and ensure it is an ongoing practice, every 6-12 months. Don’t think of this as insurance policy. SAS-70 is a generalist guideline and it is not a mandate. The certification, by itself, does not guarantee that everything is perfect. You will still need to go through the controls that were evaluated to provide that certification. The web is littered with instances where companies, supposedly certified, having data breaches. If the application you are using include managing Credit Cards or Health Care data then you should also ask for the specific certification like PCI-DSS and HIPAA.
  11. Preventive Measures: As part of your evaluation process, request for the documented architecture and policies for Intrusion Detection System (IDS) and Intrusion Prevention Systems (IPS). In addition, also ask for a recent run report of the IDS system – it might be difficult to get this but would not hurt asking. Review this with your corporate security team and ensure they meet your corporate mandate. If you are a small business and do not have a corporate IT security team, hire a CISA certified consultant and review the report with them. Even better, insist on a penetration test to be conducted by your team. You can hire third party services or a third party software to conduct a round of penetration testing.
  12. Governance: Request for a change management and access management report of who in the vendor’s organization has access to the data. The idea here is not to check the specific individuals but how rigorous the process is. If the vendor has SAS-70 Type II certification, this is something they would have documented already. With the dynamic environment, in which most SaaS vendors operate, there will be a lot of churn in the people. It is important to make sure the vendor has process in place to ensure their past employees, contractors do not retain access after leaving the organization.
  13. Understand the data management: To provide 99.9%, almost interrupted, high performance service levels, SaaS vendors will end up replicating your data (or backing up) to multiple data centers. It is important to understand that process and access control around the replicated data.

This should give you a good set of upfront checks before you decide on a SaaS vendor. Remember, Security is not a one time thing. It is a ongoing process. You keep at it regularly – Measure, Monitor and Adapt, and only then can you be sure you data is secure.

Portability/Switching Cost

With SaaS you have the ability to switch to another vendor if your SaaS vendor measure up  to their commitments in SLA or is at risk of becoming defunct, you have the opportunity to switch. No infrastructure, resource investment overhangs. But don’t expect for switching to be as easy as switching your cellphone service. You still have the all important data residing with the vendor. With a little bit of smarts during initial contract negotiation, might get you your data free or for a nominal cost, you still have to ensure that your data is deleted clean from the vendor’s database and servers after you leave. A breach at your previous vendor and learning that your old data was part of the data loss is not something you would want to hear.

Bake it into the Contract

To make this a IT priority and a scheduled activity, here are terms you should incorporate into your Contract.

  1. Have your vendor furnish a SAS-70 Type II certificate every 6 months or a year (depending on your comfort level)
  2. Conduct a penetration testing exercise every 4-6 months from your end. If you are happy with the third party agency employed by the vendor to conduct a penetration test then save yourself some money and ask for that report to be made available to you. Vendors like Qualys provide you with a service that you can avail for conducting these tests.
  3. Have your vendor furnish IDS/IPS logs to be available upon request or through the Self-Service Administration portal.

Parting Shot

You know I am big SaaS fan, so now for you SaaS naysayers out there – chew on this.

If it makes you feel any better, these are the very same checks and processes that your internal IT has to follow. So not going with SaaS does not preclude you from these processes. With SaaS, since this is asked of the vendor and since it goes through the scrutiny of many customers like you, the chances are their process would be much more hardened resulting in your data being more safer. As un-comforting as it might seem, last I checked, the majority of data thefts happened from the inside of an enterprise as this survey done by a UK firm states – 33% of employees would steal data .

Back to Top
%d bloggers like this: