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 .

Thoughts shared by readers (6)

  1. Steve Says:

    It is unrealistic to expect a SaaS company to expose its IDS/IPS logs to a customer. Like you said, 30% of their employees would steal the data and this kind of information is exactly what an intruder would like to get his/her hands on. Third party evaluation is the best medicine so the process audit is shared, not the process content.

    I agree with the general assertion that these principles must be followed in any case – and that they are less likely to be followed internally, especially in small-medium sized businesses

  2. Subraya Mallya Says:

    Thanks Steve. I agree in a multi-tenant scenario it puts the SaaS vendor in a tight spot when it comes to sharing IDS logs since it will include the data from all the customers co-mingled in it. But there are many vendors who have bifurcated customers into different webservers and different DB while sharing a single code base and in such cases it should be possible to get the IDS/IPS logs. Also I feel with more customers insisting on such needs, it puts the onus on SaaS vendors to improve their service and think about customer challenges as they mature their offerings.

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

  3. Sohail Abrahim Says:

    Some very good points here, Subraya. Data security is one of the top concerns of consumers considering SaaS solutions. Rightfully so, with many SaaS vendors hosting their software on third-party servers and all consumer data transferred over the internet. The thing to remember is, each SaaS vendor offers various features and services, with advantages and disadvantages. Like most big purchases, it’s important to compare and shop. The SAS-70 certificate is a crucial requirement. Be wary of vendors who don’t have that. Finding the right SaaS vendor that perfectly fits your needs and wants can be a difficult, if not stressful, task.

  4. Subraya Mallya Says:

    Sohail
    Thanks for reinforcing my thoughts.

  5. Julian Cook Says:

    When your business data goes out of your data center and out of your control, you shouldn’t only be concerned with data security but also data availability. I work for an ISV called RainStor that launched a cloud archive service a few months ago. We’ve focused on delivering application retirement services initially, however, we’ve also been asked by customers, partners, commentators, analysts etc. etc. how our cloud archive service can be used for “SaaS data escrow”.

    Data escrow allows companies to protect and insure the data that resides within their SaaS applications by keeping a copy with a neutral 3rd party. There are many and various reasons for considering SaaS data escrow including concerns about vendor viability, unplanned service outages and potential data loss or corruption. Many businesses are also keen to ensure that they’re complying with their own data governance standards or want improved reporting and business analytics against their SaaS data

    We’re keen to understand in more detail why and how companies might use cloud archive services to keep a copy of the data within their SaaS applications so we’re running a survey. The survey is available at http://tinyurl.com/kl5l86 and the results are available to anyone who participates.

  6. Subraya Mallya Says:

    Thanks Julian. I agree with the need for customers to ensure the data is available as and when they need it. This could be for a variety of reasons like consolidated reporting across multiple cloud offerings or across cloud and on-premise applications, data governance and more importantly business continuity, in the event the SaaS vendor goes under. I go even further and advice companies to use cloud based services as an escrow to also maintain source code (in cases where they do have that language in their contract).

    Subraya Mallya

Trackbacks For This Post (6)

  1. PrudentCloud Says:

    #PrudentCloud: #SaaS:Data Security: Should I be concerned? http://bit.ly/NZH0R

  2. Subraya Mallya Says:

    #PrudentCloud: #SaaS:Data Security: Should I be concerned? http://bit.ly/NZH0R

  3. PrudentCloud Says:

    #PrudentCloud: SaaS: Data Security – Should I be concerned? http://bit.ly/NZH0R

  4. Audit Certification Accountability | Business and Technology Strategies for Software-as-a-Service (SaaS), Governance Risk and Compliance (GRC), Open Source| PrudentCloud Says:

    […] elaborate tools and processes in place – certification or otherwise. Check my earlier post SaaS Data Security – Should I be concerned? for some ideas on mitigating these risks. The concepts apply to an internal IT organization as […]

  5. SaaS: Legal Issues explained | Business and Technology Strategies for Software-as-a-Service (SaaS), Governance Risk and Compliance (GRC), Open Source| PrudentCloud Says:

    […] will be raised by customers during contract negotiation. Customers are getting more educated on the Data Security concerns and the necessary process and infrastructure needs around Data Security to meet their […]

  6. SaaS – A Compliance Nightmare? | Strategies for Software-as-a-Service (SaaS), Governance Risk and Compliance (GRC), Open Source| PrudentCloud Says:

    […] If you look through majority of the public instances of data leaks or compliance violations, you will see most of them involved employees of the companies. That should encourage companies to look at SaaS solutions. But as part of your initial contract and subsequent relationship with the SaaS vendor insist on transparency of the controls implemented . […]

We would love to hear your thoughts. Please leave a comment

Note: Please review our Comment Policy

You must be logged in to post a comment.

Back to Top

Discover more from PrudentCloud

Subscribe now to keep reading and get access to the full archive.

Continue reading