Performing an audit of the application security access request handling and the recertification processes
Part 2 of 2
By: Mitchell H. Levine, CISA - Audit Serve, Inc.
The first part of this article focused on the user access recertification. The last part of this article focuses on the role based recertification and the security request handling process.
Performing an Audit of the Role Recertification Process
The role based recertification is missing from most organization validation process because it requires an analysis of the underlining menu and access components to which are tied to the roles which are assigned to individual users.
The need to perform a resource role based recertification is based on whether the security administrators have the ability to change the mapping of access components to roles. If the roles cannot be changed by the security administrator then a case could be made that a recertification does not need to be performed. The exception would for organizational changes which restructure the roles and responsibilities in which roles changes would be required to foster the proper level of separation of duties. If security administrators have the ability to make changes to the mapping of resource components assigned to roles, then an audit trail would be required to identify the details relating to the changes being made which require an independent function to review the changes to ensure they are supported by an authorized resource role change request.
During an audit, a review should be performed of the effectiveness of the role review which includes an inspection of the security listing which are used to support the review process. In many cases, these security listings or screen lookups are not available to provide the traceability to the actual access functions which are provided by a specific resource role component.
Due to the complexity of the resource roles which are tied to business processes, this type of review should be performed as part of an integrated audit.
Performing an Audit of the Security Request Handling Process
When assessing the security access request process, the starting point is to review the methods used to define the security resource access components which are being assigned to individual users.
It would be expected that a security access request form is used to assign access to application components. The audit needs to assess whether all of the resources components (e.g., resource profiles and privileges) are specified on the form. This would require a reconcilement of all of the available resources profiles and privileges to ensure they are included in the security request form. Depending on the complexity of the application security design, it might not be feasible to include all resources on the security request form which would require alternate approaches discussed later in this article.
Reliance on the use of free-format fields to specify the application level security access requirements is not an acceptable practice. Also, the use of the model off approach in which the ID or name of another user is the basis of establishing a new user’s access is not an acceptable practice because individual in which the ID is modeled off of may be granted access permissions which are beyond their presumed job function (e.g., backup for other job function).
Typically, organizations utilize a security access form which specifies the resource functions that can be selected. Unless these resource functions are defined using known business functions, the authorized approver of the security request form will not be able to understand the security access which is actually being granted to an individual user. The best approach is to list the job functions that can be requested. This would then used by the security administrator which processes the security request to translate the exact the security permissions which are needed to support the requested job function. This approach (i.e., referred in the industry as the entitlement matrix approach), also streamlines the recertification process because the individuals responsible for the review would only need to validate the individual job function and not all of the underlining security permissions that the user has been granted. The process for validating the job functions to the underlining security permission would then be recertified security administration area.
There are areas within organizations which still accept free-format requests via email which should only be considered if there are only a few access levels which can be assigned which can be clearly defined in an email. Utilizing this approach is difficult to audit which is dependant on the retention of the emails.
Performing a review of the security access request process requires an auditor to assess the overall design of the process and escalate issues which may require the complete re-engineering of this functional area. In many cases, the application security design itself may be found inadequate because there is not sufficient granularity to ensure the proper segregation of duties.
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. 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 2009, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.