Performing an Audit of a SaaS Deployed Application
Part 2 of 2 
By: Mitchell H. Levine, CISA - Audit Serve, Inc.

This second part of this article will focus on the other areas which should be included in an audit of a SaaS deployed application. The first part of the article focused on the design of the environment to support the business.

Test Environment

Depending of the business function supported by the SaaS deployment application, site customization may only consist of changing the manner in which input fields function. This would be common for a typical “out-of-the-box” Salesforce.com deployments. For this type of environment, the need to test changes is not required. In this case, changes are made directly to the production environment. However, almost all SaaS deployed applications involve some degree of functional processing in which the proposed change would want to be simulated or tested before the change is deployed to production. This represent more of typical SaaS deployed application which is the reason most SaaS vendors provide a “Sandbox” environment which is used for testing changes and to conduct training. A Sandbox environment is typically not locked down to prevent one user from disrupting another user’s test. In addition, a Sandbox environment does not mirror the production data since the SaaS vendor does not typically provide test refresh services from production.

This lack of testing capabilities provided by the typical SaaS application deployment would represent an audit issue. However, the need to have a locked test environment which mirrors production may not be necessary based on the SaaS deployment within your organization. However, if there is integration with the SaaS system with your organizations internal system, then a separate SaaS test environment would need established to support the integrated testing which would be required. SaaS vendors would be willing to provide a test environment which meets these requirements but it may be a very expensive proposition.

Security Design & Administration

The capabilities of the security design needs to evaluated to determine whether it provides the necessary granularity to enforce the separation of duties required within your organization. The ability to alter and view data is typically provided in hierarchical group structures in which users are assigned to a particular group and the higher they are with the structure allows them to view and alter data for those individuals and data components that fall beneath them in the organizational structure.

Some SaaS vendors provide limitations in which a user can only be assigned to one particular hierarchal group structure. They provide workarounds to allow the necessary access which translates to hardcoded sharing rules which typically are not visible in a security access report. The overall ability to view access capabilities of an individual is a limitation in many SaaS vendor offerings which necessitates testing in the “sandbox” environment to understand the access capabilities of an individual user. For most SaaS applications, organizations are left with the task of developing their own reports in order to display the access entitlements assigned to individual users.

The function of performing security administration and configuration changes are typically defined as distinct privileges which are assigned to individual users. However, these privileges in many cases cannot be restricted to the scope of access required by the user but instead provide global access. This limitation may require these functions to be centralized instead of decentralized depending on the willingness of organization to deploy detective control review processes assuming sufficient audit trails are available.

Since SaaS deployments are typically Internet facing in which users of an organization are not required to authenticate to their internal network, special emphasis needs to be in place regarding the userid termination process.

Conclusion

The first audit of a SaaS deployment typically involves the identification of missing controls in which there are inherent weaknesses that an organization would possibly need to accept. If a pre-implementation audit would have been performed prior to the purchase of the SaaS application, in which these inherent weaknesses would have been disclosed, an organization may not have purchased the SaaS product.

__________________________________________________________

Mitchell Levine is the founder of Audit Serve, Inc. Audit Serve performs PCI Assessment and Remediation Project Management consulting services. Audit Serve also conducts Integrated & IT Audits, SOX Control Design & Testing and Penetration Testing. Email Mr. Levine at Levinemh@auditserve.com if you would like to discuss your organization's specific project requirements in order to establish a proposal of services. 
 

Copyright 2008, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.