Being an information security pro means learning how to deal with headaches. As if worrying about securing data within a corporate network isn't enough of a headache, securing data when it's in somebody else's network is even more complicated. In a nutshell, that's the security issue surrounding hosted software, so-called cloud computing or Software as a Service (SaaS).
At first glance, SaaS might seem like a glorified version of third-party outsourcing. Many companies send data out to third parties, particularly those that process credit cards, but SaaS is a bit different: The third party hosts the software and manages the deployment and infrastructure. Instead of purchasing and installing software, a company links up with the SaaS provider, often via the Internet. SaaS is usually business driven for reasons such as availability, ease of management and cost-cutting.
Some well-known SaaS providers are Google Inc. and Amazon.com Inc., which offer applications as services through their networks. Other examples are Salesforce.com Inc., which offers customer relationship management (CRM) software online and Qualys Inc., which offers on-demand security monitoring and scanning of all things, including those mandated by PCI DSS itself.
SaaS and compliance
Basically, the same security concerns companies already have within their own networks -- securing networks, hardware, applications and data -- apply for companies outsourcing their data with SaaS. However, when compliance with government regulations like Sarbanes-Oxley (SOX), Gramm-Leach-Bliley (GLBA) and HIPAA, and industry standards like the Payment Card Industry Data Security Standard (PCI DSS) is thrown into the mix, things can get messy.
Before SaaS, compliance success could typically be boiled down to a few key tasks: identify users and access privileges; identify sensitive data, where it's located and how it's encrypted; and document all of this for auditors and regulator...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
s. SaaS makes these processes more complicated. Theoretically, an enterprise has full control of its data, but in reality it may be difficult for a customer to discern where its data resides on a network controlled by its SaaS provider, or a partner of that provider.
Managing SaaS and PCI DSS
SaaS affects compliance with numerous regulations, but perhaps the best benchmark is PCI DSS, which has explicit provisions for what it calls "service providers," SaaS or otherwise. Requirement 12.8 of PCI requires service providers to be compliant and contractually acknowledge their responsibility for protecting the client's cardholder data, and goes even further in a brief appendix devoted entirely to hosting providers.
Requirement A.1 of Appendix A has four sub-provisions. Let's look at each one in a bit more detail. Section A.1.1 requires that each client of the hosting provider only have access to its own cardholder data environment. This should be one of the first questions a company asks when engaging a SaaS vendor.
The key question to ask is: How does the SaaS provider's system architecture prevent unauthorized exposure of data to other parties using the same service? Providers are in the business of servicing many customers. That means precious data could be sitting on the same servers as someone else's data, maybe even that of a competitor.
Closely related to data segregation is Appendix A.1.2, which calls for access controls on data held by the service provider. The controls should only allow the customer access to its own data and protect that data from unauthorized access by other parties. Access controls at SaaS providers can be handled either by the provider itself, or connect to the client's identity and access management system.
If the SaaS provider handles access, then authentication credentials like user IDs and passwords are actually stored on the provider's servers. Though most SaaS providers claim this is secure, be wary. A breach at the provider could expose not only data, but also authentication credentials. Having the provider handle authentication also requires careful management of user accounts. Access has to be revoked for users leaving the company, which is easier when done in-house by the company's own identity and access management system.
The preferred method is to have direct integration with the company's directory services, whether Active Directory or LDAP, for authentication to the SaaS service. This option is now available from many SaaS providers.
The next area of concern, covered by Appendix A.1.3, is logging and audit trails, which are mandated by Requirement 10 of PCI. Log management and SIM tools, which have become quite sophisticated for monitoring corporate networks, can't be used for watching someone else's network, like that of a potential SaaS provider.
Logs and audit trails are also often needed for investigating incidents. This is covered in Appendix A.1.4, which requires the provider to "provide for timely forensic investigation" if it suffers a breach.
Since the SaaS provider's logs are internal and not necessarily accessible externally or by clients, monitoring (let alone investigations) is difficult. Since access to logs is required for PCI compliance and may be requested by auditors and regulators, make sure to negotiate access to the provider's logs as part of any service agreement.
Web applications and breaches
Besides these PCI-specific points, other items to consider are Web application security, insider breaches at the provider and the location of data.
Since many connections between companies and their SaaS providers are through the Web, providers should be asked about the security of their Web applications, including whether they follow OWASP guidelines for secure application development. This mirrors Requirement 6.5 of PCI, mandating compliance with OWASP coding practices.
Providers should also be prepared to answer questions about how they handle breaches among their own staff, as well as questions about where data is located. In the far-flung global world of many large IT networks, data could be sitting on the SaaS provider's services in places as distant as Singapore, Brazil or the U.K. This affects not only jurisdictional issues in cases of breaches, but also adds local compliance and legal issues in different countries to the already heavy burden here in the U.S.
As cloud computing grows in popularity, compliance issues become an increasingly critical consideration. SaaS arguably puts data at greater risk, since it hands over IT security control to someone outside of the company's carefully controlled network. But by minding these tips and applying best practices, an enterprise's data can be kept secure regardless.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and is the author of The Little Black Book of Computer Security, Second Edition, available from Amazon. He hosts a radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
