Free Newsletter
Register for our Free Newsletters
Newsletter
Zones
Access Control
LeftNav
Alarms
LeftNav
Biometrics
LeftNav
Detection
LeftNav
Deutsche Zone (German Zone)
LeftNav
Education, Training and Professional Services
LeftNav
Government Programmes
LeftNav
Guarding, Equipment and Enforcement
LeftNav
Industrial Computing Security
LeftNav
IT Security
LeftNav
Physical Security
LeftNav
Surveillance
LeftNav
View All
Other Carouselweb publications
Carousel Web
Defense File
New Materials
Pro Health Zone
Pro Manufacturing Zone
Pro Security Zone
Web Lec
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
ProSecurityZone Sponsor
 
 
News

SaaS Vendor Negotiating Checklist

Fortify : 24 March, 2010  (Special Report)
Barmak Meftah of Fortify Software provides some advice on selection processes for choosing SaaS vendors with a checklist of facts and questions to ask prospective suppliers
In recent years, Software-as-a-Service (SaaS) has emerged as a viable application delivery method, and most enterprises are now including some SaaS software in their portfolios. SaaS saves IT infrastructure and maintenance costs, not to mention the hassle of initial deployment, integration and customization common with licensed software. Organizational functions such as sales, marketing, customer service, HR and others may request to subscribe to hosted software. If you have concerns around the security of cloud computing, you are certainly not alone.

SaaS brings with it a unique set of challenges for Chief Information Security Officers. The most important shift is looking at your software vendor not as a product company, but rather as a service provider. Sound vendor management practices dictate that any third-party software is at least as secure as in-house packages. Be certain you are trading lost visibility and control in exchange for auditable security assurances.

Forrester Research cautions companies considering using cloud-based services to gain a clear understanding of the security, privacy and legal consequences before contracting with any service provider. This guide will help you compare your organization's Risk Management and compliance priorities to the SaaS provider's security policies and procedures.

It's 8 a.m. Do you know where your data is?

Let's assume — for the sake of argument— that your data is currently isolated behind the walls of your enterprise where it's under your control. When you convert to SaaS, your data will be transported across the Internet to the SaaS vendor site. If their application is not secure, your critical business information will potentially be exposed to anyone who can take advantage of such a vulnerability.

Too many SaaS vendors see their services as a "black box." As their customer, you accept the services provided and trust the vendor to guard your information appropriately. Unfortunately, Internet security breaches are all too common. Customer and employee records, credit card numbers and other confidential data are subject to compromise through theft or accident at any time. SaaS vendors are not immune to these threats.

Unfortunately, some SaaS vendors who become aware of a security flaw in their service may not immediately patch it. If a security fix can be made on their server without a client patch being necessary, some vendors may never alert you that there was a problem at all. It is always possible that unpublicized bugs can be exploited in zero-day attacks before server-side fixes can be made.

Of course, many SaaS providers rise to the challenges of providing secure and reliable cloud-based services. However, as the person responsible for the security of your enterprise data, you need more than faith as assurance that they will follow through on their best intentions.

The CHECKLIST - when negotiating terms with a SaaS vendor:

• Review the vendor's service history, obtain customer references and ask them about their experiences with the vendor's concern for privacy, reliability and security vulnerabilities.
• Be certain that application and infrastructure security requirements are written into your contract with any SaaS provider. Include an audit clause whereby you or a third-party can periodically verify that the required controls are in place.
• Get a solid Service Level Agreement. An SLA requires that the vendor provide a specified level of system reliability. A good vendor will strive for performance that meets Six Sigma levels of service quality (eg, 99.9997% of security patches made within a set number of hours, not days, after public disclosure).
• Do not accept a policy of making silent fixes to their service. Demand notice from the vendor when security fixes are made. Specify in the SLA that you as the CISO are to be notified directly about these reports.
• Insist that the vendor's own software development process adheres to a robust software development life cycle model that includes tollgates that check for secure coding standards. Request that a description of the process be appended to the SLA.
• Carefully examine the vendor's policies for data recovery in the event you decide to terminate the service. Be certain that you know how long it will take to retrieve your data as well as how long it will take them to make it inaccessible online.
• Maintain strong encryption standards and key management for data transmission between your site and the vendor site.
• Be certain that your users are not the weak link in the security chain. Specify which web browsers can be used to access services, and stay on top of browser security issues and updates.
• Control domain access as well as where and when services can be accessed by your users.
• If possible, be certain that they must first login to your network to access corporate information on the SaaS vendor site.
• Always maintain ownership of domain names that you provide to clients. That way, if you terminate a vendor relationship, you will not have to retrain your clients on the correct URL to use to find you.

Tough questions to ask your SaaS vendor:

Use the following questions to determine if the SaaS vendor you are evaluating has a solid security program in place.

1. Who has access to my data?

When you use a hosted SaaS application, your data will almost certainly be exposed to programmers, testers, quality assurance teams and possibly others. The vendor should have methodologies and protections in place to ensure the privacy of your information.

Bad answer - "We treat the security of your data as our #1 priority, but it's difficult to specify all those who have access to it. We're sure it's a very short list."

Good answer - "Database administrators and operations people have access to your data. We keep logs of all their activity and they always work in pairs. We mask production data for use in test environments. We occasionally
do need senior programmers to work on production systems in order to resolve problems. In those cases, we have them work in pairs as well."

2. What prevents a programming error that could show my data to a different customer?

A basic tenant of SaaS is multi-tenancy, in which network resources are shared across customers. This means your critical information is on the same servers as other people's data. Designing and enforcing proper access controls is a significant challenge with SaaS, so the vendor should demonstrate that a lot of effort has been spent here.

Bad answer - "Our programmers are really smart. This could never happen."

Good answer - "We designed a system so that even when programmers make mistakes, your data is safe. We host your data on the same server with other customers, but let me show you how the service is designed so our permissions system makes it impossible for one user to see another user's data."

3. Show me the report from your last penetration test.

Most SaaS vendors hire third-party penetration testers now and then, and most pen testers will find something to report. The most important thing is that the vendor responded appropriately to anything that the test uncovered.

Bad answer - "We generally don't share these with customers. Rest assured that security patches will continue to be made automatically. We can demo our live Update log."

Good answer - "We have an external security company test our system a few times a year. Here is their latest report. You'll notice they found some problems. If you're interested,I can show you how we addressed those."

4. Show me the report from your last code review.

Code reviews find bugs that are hard to spot any other way. If the vendor is PCI compliant, they have to do code reviews.

Bad answer - "We do code reviews all the time, but nobody ever writes anything down."

Good answer - "Here's the report. You'll see lots of references to our internal coding standard. I can get you a copy of that too."

5. Do you give programmers security training?

Ideally, everyone involved in the software development process should get security training, but if the programmers aren't being trained at a minimum, the vendor is in real trouble.

Bad answer - "I'm pretty sure they are required to read the OWASP Top 10. So, yes, our programmers all know about security."

Good answer - "We use computer-based training to make sure all programmers get a full day of software security training when they first join the company. Our security team focuses on professional development to help people stay current."

6. Do you use code you didn't write? How do you know it's secure?

The vendor should be able to detail any third-party code suppliers: what they're doing to make sure that code is secure, and what they do when a vulnerability is discovered. If a security vulnerability gets fixed in an open source library, how long is it before they deploy the fix?

Bad answer - "We only deploy bug-free code. We're not sure which open source libraries we're using — it changes a lot."

Good answer - "Our suppliers are contractually obligated to meet our security standards. We only use open source components that are approved by our security team."

7. How do you monitor the software running on your production systems?

When the time comes for a new release, do the developers just throw it over the wall to the operations team? Is the code treated as a black box, or do they have insight into how their live systems actually behave?

Bad answer - "Our ops team has an intrusion detection system. If any of the machines run out of disk space, we figure out why."

Good answer - "We've built monitoring and defense capabilities into our application. We have a specialized system to diagnose coding problems that show up in the application logs. We also build profiles of user behavior, so if somebody steals a username and password and starts poking around in your account, we'll notice the unusual activity."

8. What sort of security tests do you perform before a software release?

The SaaS market is not exempt from a focus on software quality, and good tests are critical for security assurance. A good testing regimen combines the smarts of people who understand how software breaks with automation tools that churn through large numbers of test cases.

Bad answer - "Sure, we do unit tests."

Good answer - "Our standard regression tests include tests for all security features, e.g., password lockout, password reset, entitlements. We also look for security bugs using software-oriented vulnerability assessment tools."

Software is secure only when it's built that way. A company such as Fortify has a Software Security Research Group which supports developers by identifying common types of coding errors, thus helping developers and software security practitioners recognize problems as they build their software. Bugs and vulnerabilities are fixed before customers are exposed to the product.

By working with an application security company you as a security professional will be bang up to date on the latest security vulnerabilities and defenses against them. You should work with them to get the tools you need — including security bulletins, white papers, Webcasts and videos — so that you understand the issues surrounding SaaS security for today's distributed software portfolios.
Bookmark and Share
 
Home I Editor's Blog I News by Zone I News by Date I News by Category I Special Reports I Directory I Events I Advertise I Submit Your News I About Us I Guides
 
   © 2012 ProSecurityZone.com
Netgains Logo