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 this process. With SaaS, since this is asked of the vendor and 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 is the 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 .

• Choosing a SaaS vendor and
• Technology Considerations.

In this post I will go into the governance considerations you should include in your evaluation of a SaaS vendor.

In this day and age of increasing governance and regulatory compliance mandates, the evaluation of your abilities to support the governance requirements, audits are always tested. With SaaS applications in your portfolio it assumes a higher degree of importance.

SaaS can really help the cause when it comes governance, if sufficient legwork is done upfront. On the one-hand, having SaaS application in your IT portfolio relieves you of some of your IT responsibilities. The vendor assumes responsibility of the upgrades, patching, backups, recovery. The fact that the application is outside the realms of your IT boundaries also means that it is out of the reach of all the unauthorized employees. That said, the data sits in a remote data center with employees from the SaaS vendor accessing it and you have scant visibility.

So here are some governance checks to be done as part of your evaluation of the SaaS vendor

• Access Control: Considering that the application is hosted by the vendor, by definition, your team will not have access to the technology infrastructure. Check the policies the vendor has in terms who accesses the data center and how secure it is. Also check who in the vendor team has access to the application. The application should provide an audit trail of every time some one accessing the application.
• Security: Evaluate the various aspects of security in the product. Starting with
  • password encryption,
  • application security model (data and role-based),
  • encryption of data transfer between user’s browser to the server across multiple tiers and in some cases multiple vendor cloud services
  • Security on the servers (the access, configurations, logs)
  • Data center security
  • Physical premise security
• Data Separation: One of the biggest mental hurdles companies have in adopting SaaS is the fact that their data resides outside their control and the fear that it might be within the reach of wrong people.  While the former is true it is no different than having your personal online bank or brokerage account. When you combine that with the fact that your data could be co-mingled with that of your competitor makes customers that much more finicky.  SaaS companies should be able to share with you the policies used for data segregation and architecture used to implement it. With technologies like Virtual Private Databases (VPD), separate databases-shared-code models would be underpinning their multi-tenancy architecture. Around privacy, have your security experts verify that none of the customer/tenant information like ID, code in URLs, hidden variables are exposed in the user interface. They could provide access to data you should not be seeing.
• Change Management is one of the critical things to evaluate in a SaaS provider to gauge the maturity of the vendor. Most vendors begin with ad-hoc processes and institute mature governance processes as the company grows. As part of the evaluation process insist on reviewing the following
  • Change Management policy document
  • Change Log from a change effected
  • Communication of changes to customers.
• SOX, SAS-70, PCI-DSS, HIPAA, GLBA: Managing information,  access and usage across the entire on-premise IT portfolio is a challenge enough.  With SaaS, it becomes a little more challenging. You store information regarding assets, leases, contracts, employees, payments, vendors, to name a few, in a database outside your firewall  maintained on infrastructure managed by third party. That is enough to give sleepless nights to any CIO/VP of IT. So to give yourself assurance that your data is being accessed by authorized people, ensure the application provides ability to capture and review audit trails.  The ability to generate reports on the access log, audit trails should be a critical part for you to close the sale. If you see shortcomings in these areas and get commitments for those features in the product – tie milestones and payments to that feature delivery.
• Intrusion Detection: With more applications being deployed on the internet, Intrusion Detection Systems have become a  quintessential part of any IT infrastructure. In a SaaS world it assumes a larger importance. Given that the infrastructure is hosted by a third party, it is critical you insist on an implementation of a IDS and follow-up process to proactively check for potential areas of vulnerability. A standing process for regular inspection of the servers, routers, hardware for “hardening” is something you should ensure.
• Disaster Recovery: Most vendors, to begin with, will not have Disaster Recovery. With competing priorities, budget constraints it is bound get tougher to spend on DR. But this is something you should ensure your vendor can support. Pay attention to the RPO and RTO commitments and the location of the DR site. Having two DR sites in the same electric grid (or fault line in SF Bay Area) does not really amount to a effective Disaster Recovery plan. If not available, capture that in the contract as a necessary milestone that will be measured for payments, renewals.
• Availability: While going with a SaaS solution relieves you of the active maintenance of the Application, the availability of it will still be your ultimate responsibility. Ideally, the vendor should have and share monitoring reports to support the conformance to SLA. Some vendors even share this information publicly on their site.
• Scheduled Maintenance: Pay special attention to the schedule downtime windows that might be defined on the contract. Most vendors have weekly maintenance windows that require the application to be down for the part/majority of the weekends. While that in itself is not a problem for most parts of the year, don’t forget to identify blacklists for certain weekends like month ends, quarter ends, year ends so you can do what is necessary for the book closing activities in your company.
  
• Data Portability: One of the allures of SaaS is that there is no large upfront investment so if things don’t work per your needs or satisfaction, you can cancel the contract and move to another vendor. And the SaaS vendor themselves would tell you this to convince you and close the sale.  While SaaS does provide you with quick ramp up option, getting your data back, if and when you choose to move away from a SaaS solution, is altogether a different proposition. If the SaaS vendor is a multi-tenancy based solution, sharing a single database, it will be even more tougher. So I recommend incorporating terms in the contract to ensure you have the data ownership in the event of termination without breaking the bank. You will have to pay some professional services but it should be reasonable. If you are lucky besides the snapshot of the data you should also be able to get copies of log files, audit trails, application access logs for you to be able to support regulatory compliance mandates.
• Data Retention: There are two things you need to cover in Data Retention.
  • While you are still a customer, you would want to ensure your SaaS vendor has the necessary retention policies to retain the essential information log files, audit trails, historic transaction data in the application to support your regulatory compliance obligations.
  • When you cease to be a customer and you have canceled the contract and reclaimed your data, you should make sure the vendor does not retain your data and risk exposing your company in any potential data leaks in future.

Incorporating a stringent SLA goes a long way in acheiving all these things once you adopt a SaaS solution.

Hope this helps you in your efforts to conduct a effective RFP process to procure a SaaS solution. SaaS is a big change happening in the technology arena and we are still in the first innings. There are  at least 8 more to go.

Download the entire SaaS Buyer Guide (PDF 169KB)