Given current economic conditions, it makes logical sense that financial enterprise will turn to Software as a Service (SaaS) offerings for cost saving and efficiency. For most any process -- from customer resource management and human resources to Web application features for product enhancement -- there's likely a SaaS provider. But as businesses follow the trend into the cloud, the onus will be on SaaS vendors/providers to ensure more stringent security standards. No sector needs more confidence in those standards than the financial-services sector. If the recent Heartland Payment Systems Inc. breach didn't drive this point home for you, nothing will.
Maybe you're about to jump headlong into SaaS territory, or perhaps you've already made the leap. But before you close the deal, approve the contract and sign the dotted line, what scrutiny did you give the provider's security practices? With promises of transparency, scalability and performance, what mention did they make of confidentiality, integrity and availability?
SaaS vendors: Physical, network and application security
There are some crucial elements an organization needs to review as they consider SaaS products. Someone providing SaaS on your behalf is also supposed to be providing you and your customers with physical, network and application security. Take it down to the simplest common denominator: What is the value of your data? As a financial service, few would contend that there is no more valuable data than what you keep for your customers. You owe it to those customers to ensure that their information is safe; thus your SaaS vendor owes it to you in equal measure.
Consider this scenario: A SaaS provider manages all online transactions for a financial service, perhaps it's a mortgage lender, a brokerage or a bank. It has thousands of customers, and ...
To continue reading for free, register below or login
To read more you must become a member of SearchFinancialSecurity.com
a numerous other banks use the same SaaS vendor. Should that SaaS vendor have just one chink in their armor, perhaps a Web application flaw, a lapse in network security, or a physical security indiscretion, its clients and their customers all share the same risk. An enterprise is only as strong as its weakest link, and if someone else is managing that link for you, you have some questions to ask before marrying your business to theirs.
Questions to ask your SaaS vendor/provider
Here are seven questions to consider asking a SaaS vendor. The list is neither complete nor comprehensive; rather, it is intended as a starting point for SaaS safety:
1) How does the vendor respond to reported vulnerabilities? Is there a clearly defined escalation path customers or reporting parties can follow to ensure that vulnerabilities are repaired? A vendor should respond swiftly, openly, and provide a clear escalation path to vulnerabilities.
2) Does the vendor employ a Secure Development Lifecycle standard? Does it weave security into the very fabric of its coding and implementation practices? If a vendor does not answer yes to both of these questions, then it's time to revisit the proposed relationship.
3) How often, and by whom, is the security posture of the SaaS product reviewed? To what extent are the appropriate compliance frameworks (PCI, SOX, HIPAA) kept in mind, as well as Web application security standards (input validation, encoding output, preventing request forgery and information disclosure)? The SaaS product's security posture should be reviewed quarterly by a legitimate, objective third-party assessor with all appropriate compliance frameworks in mind.
4) Does the provider conduct its security practices beyond the scope of mere compliance checklists? While industry requirements like PCI DSS provide a reasonable starting point, security practices built in as a consistent baseline make meeting compliance requirements all that more easy. A vendor shouldn't practice "checklist" security, but rather consider security as innately important.
5) What are the breach disclosure practices? Should a breach occur will the vendor be immediate and transparent in its response? Any breach affecting customer's personally identifiable information should be discussed openly and immediately, with a resource website made available for customers to review options and expectations.
6) What are the vendor's operational security practices? Will it ensure all systems and hardware are maintained at current patch levels? Will it ensure all confidential data is transported via secure protocols, and kept cryptographically sound while at rest? Operational security should be inherent to a SaaS providers' business, and integrated at the core. All confidential data should be transported and stored via encrypted methodology.
7) Finally, will it remain open to discussion of all these questions at regular intervals and provide a dedicated security liaison? A vendor should be glad to discuss security issues with you at any time.
Scrutiny of SaaS security vendors lags
Quite simply, SaaS vendors should be held to higher standards than traditional product providers. Boxed software products, network equipment, operating systems, and even physical security products all fall under existing vulnerability management frameworks. While SaaS vendors make use of all these traditional products on your behalf, their core product may not be under such watchful eyes. SaaS vendors may need to meet certain industry compliance requirements, but scrutiny of SaaS security is not up to par with the security of their traditional product counterparts.
In closing, it may be a worthy effort to review your SaaS contract language and consider additions that enhance your security posture as you prepare to purchase services. The proper balance of strong security and SaaS can boost confidence in the financial-services sector, provide more safety and value for consumers, and build relationships founded in trust that can last many years.
About the author:
Russ McRee is a security analyst, researcher, and founder of holisticinfosec.org, where he advocates a holistic approach to the practice of information assurance. He also writes toolsmith, a monthly column for the ISSA Journal, and has written for numerous other publications.
